What AI products are built with: models, frameworks and data, by the numbers

We track 991 makers' products that show which model API they call — from the maker's own words, a subprocessor list, a customer story or the product's website. That's the sample below: live AI products, from indie launches to funded startups.

OpenAI is the default; almost a quarter use more than one model

OpenAI API734 · 74%Claude251 · 25%Gemini API99 · 10%OpenRouter61 · 6%Groq39 · 4%Azure OpenAI23 · 2%LiteLLM21 · 2%Mistral AI15 · 2%

OpenAI's API appears in 734 of them, Claude in 251, Gemini in 99. But 204 products (21%) use two or more model providers directly, and 85 reach models through a gateway such as OpenRouter or LiteLLM. Picking one model forever is no longer the norm. The usual reasons: cheap requests go to cheap models, and a second provider covers outages or tasks the first does worse.

The momentum isn't where the installed base is. Against the typical package we track, Claude's SDK downloads grew 4.1× as fast over the last year, Gemini's 6.5×, OpenRouter's 4.8× — and OpenAI's 1.6×.

Frameworks: LangChain has the installed base, the TypeScript tools have the growth

LangChain32 · 76%LlamaIndex4 · 10%Mastra4 · 10%OpenAI Agents SDK1 · 2%AI SDK1 · 2%LangGraph1 · 2%

Among the 42 AI products that show an agent framework, LangChain dominates. The download trend says something else: LangChain's grew 1.0× as fast as the median package — in line with the registry — while Mastra's grew 3.6× and the Vercel AI SDK's 2.7×. The AI SDK is downloaded millions of times a week but rarely visible from outside a product: it's a library, so it shows up in code, not on websites.

The rest of the stack looks like any web product

For their database, the 269 AI products that show one mostly chose a backend platform or managed Postgres:

Supabase123 · 46%Firebase39 · 14%MongoDB35 · 13%Neon33 · 12%ClickHouse15 · 6%PostgreSQL14 · 5%

And they host where web apps host — Amazon Web Services first, then Cloudflare:

Amazon Web Services148 · 44%Cloudflare98 · 29%Google Cloud Platform64 · 19%Microsoft Azure35 · 10%Railway22 · 7%Render22 · 7%

Vector search and observability: visible only when they're big

Only 41 of the 991 show a vector database, and 35 an LLM observability tool. That's far below how many use them: both run behind the product, where no website check can see them, and makers rarely mention them. Among those we can see, Pinecone leads vector search — but its SDK's downloads grew 0.7× as fast as the median package, while pgvector's grew 1.2×, which suggests more builders keep vectors next to their data in Postgres.

Pinecone26 · 63%Qdrant10 · 24%Weaviate4 · 10%Chroma1 · 2%turbopuffer1 · 2%

A tool missing from these counts isn't unused — it's unobserved. Each tool's page shows its usages by kind of source.

What this means if you're starting now

• Put model calls behind one function or an SDK that switches providers; a fifth of these AI products already run more than one model.
• A gateway (OpenRouter, LiteLLM) is worth it once you use two providers or need fallbacks.
• Start vector search in Postgres (pgvector) unless you have millions of vectors or need heavy hybrid search.
• Add LLM tracing before launch. It can't be seen from outside, so the counts here say little about who uses it — but it's the only way to see what each user costs you.