Six Kinds of Models

Text, image, video, speech synthesis, speech recognition, and embeddings. Input, output, and billing units differ.

In everyday speech, "LLM" usually means the text model. But the product you're building will likely touch several kinds at once. Their capability boundaries differ — and their billing units differ completely. That second difference is what breaks budgets.

Signs you'll recognize:

• You estimated costs from text-model experience, and the speech feature's bill is off by ten times.
• You want "auto-edit uploaded videos" and don't know which kind of model to look for.
• You heard "embeddings are expensive" — they're actually the cheapest of the six.

What the six kinds are

Text models. Text in, text out — the familiar kind. Billed by token, one price for input and a higher one for output (output usually costs several times more). The workhorse behind most AI features. openai-models

Image models. Give a description (and optionally a reference image) and get an image back. Billed per image; higher resolution costs more, in a stepwise way — one resolution notch can multiply the unit price.

Video models. Text or image in, a video clip out. Billed per second — the one thing that sets them apart from every other kind. A dozen seconds of video can cost as much as hundreds of text calls. Budget this line separately, always.

Speech synthesis (TTS). Text in, audio out. Billed per character, not per token, so text-model math doesn't transfer. Voice cloning and emotion control usually cost extra.

Speech recognition (ASR). Audio in, text out. Billed per audio duration — what you say doesn't matter. A silent recording and a dense conversation cost the same if the duration is the same.

Embeddings. Text in, a string of coordinates out. They generate nothing; they turn "meaning" into distances you can compute. This is the foundation of semantic search and knowledge bases — and the cheapest of the six, usually one to two orders of magnitude below text models.

The billing unit is the point

You can guess the capability differences. The billing-unit differences are what actually hurt.

Look at the bars in the figure: for "one model call," costs span two orders of magnitude. Embeddings are cheapest, video is most expensive, with several rungs in between.

That leads to a practical rule: when estimating costs, you must calculate the six kinds separately — one mental model doesn't work. Building an "upload recording, transcribe, summarize, generate a cover image" feature means adding ASR's duration fee, the text model's token fee, and the image model's per-image fee. Use the wrong unit anywhere and the whole budget is off. Vendors' price sheets only quote their own units, so be careful when comparing across providers. claude-pricing

There's also a detail people overlook: non-text models often have hard concurrency and duration limits. A video generation can take tens of seconds to minutes. That's not just a cost problem — it's a product-design problem. You need a real waiting experience, not a spinner.

Real products are assembled

Real products rarely use one kind of model. Take a concrete example: a "meeting minutes" feature.

The recording goes to ASR first (billed by duration); the transcript goes to a text model for summarization and action-item extraction (billed by token); if you want semantic search, you split the minutes and run them through embeddings into a store (billed by token, but cheap); and if the product wants a shareable card, you call an image model once more (billed per image).

Four kinds of models, four billing units, four independent failure paths. Only when you break them apart can you estimate the cost and risk of each segment.

The same goes for selection: these four segments can come from different vendors; you don't have to bind them to one. Pick ASR for accuracy and Chinese-language performance, pick the text model that measures well on your kind of task, pick embeddings for cheapness and stability. How to wire them all together is another topic.