Six Model Types

Text, image, video, speech synthesis, speech recognition, embeddings — six billing units, not six capability tiers. Budgets break here, not there.

Your product will rarely touch just one kind of model. Recordings need transcribing, documents need summarising, screens need illustrations, and your own material needs to be searchable — each of those sits on a different kind. You can probably guess how their capabilities differ. What wrecks budgets is something else: every kind bills on its own unit, and the units do not convert.

After reading, you should be able to answer:

• What unit does each of the six kinds bill on, and why can't you convert between them?
• Why does "embeddings are expensive" not hold up?
• How many separate bills does one feature carry, and why mustn't they be averaged?

The same "one model call" spans two orders of magnitude

Start with the conclusion that hurts most: "one model call" is not a cost figure at all. The cheapest kind, embeddings, and the most expensive, video, differ by two orders of magnitude for a single run; the kinds in between sit along that line with several rungs between them.

The gap does not come from capability. It comes from the unit: each kind charges with its own ruler, and there is no conversion table between rulers. Vendor price sheets likewise recognise only their own units, so to compare across vendors you first have to line the units up. Skip that and the comparison you get back is wrong.

Hence a practical discipline: cost the six kinds one at a time; a single mental model will not do. This is not a matter of being slightly off. Get any one unit wrong and the whole budget is void.

Six kinds, six units that do not convert

1. Text models. Text in, text out — the familiar kind. Priced by token, with input and output priced separately and output usually the dearer tier. The workhorse behind most AI features. openai-models
2. Image models. Hand one a description and it produces an image. Priced per image. Raising the resolution does not raise the price smoothly; it moves in steps — double the edge length and the bill can multiply several times over, because the pixel count grows faster still.
3. Video models. Feed in text or an image and it produces a clip. Priced per second, by time rather than by how much it produced — as with speech recognition. A one-minute finished clip often costs as much as a whole day of your text calls put together. In any budget, this line has to stand on its own.
4. Speech synthesis. Text in, audio out. Charged per character, with no relation to tokens, so text-model arithmetic does not carry across. Voice cloning and emotion control are normally priced on top.
5. Speech recognition. Audio in, text out. Charged by the length of the audio, not by how much was said: transcribing a three-minute piano piece and transcribing a three-minute interview cost the same, even though the first contains no words at all.
6. Embeddings. Text in, a string of coordinates out. They generate no content; their job is translating meaning into coordinates whose distances can be measured, and semantic search is built on top of them. They are also the cheapest of the six — running a batch of material through embeddings usually costs a fraction of having a text model read the same batch. claude-pricing What they actually do in a system is Vectors and Similarity.

With the six units laid out, one easily missed awkwardness has somewhere to land: a real feature usually carries several bills at once.

One feature usually stands on four bills at once

Take support-call QA. Turning one call into a usable QA record usually runs like this.

The recording goes first to speech recognition for a transcript, costed by audio length. The transcript goes to a text model to judge whether the agent breached any rule and who the breach should be attributed to, costed by token. Each QA record is then run through embeddings into a store, so that later you can search for "past disputes similar to this one"; again costed by token, but at a far lower unit price. And if the material is also going to train staff, with the findings turned into a flowchart, that is one more call to an image model, costed per image.

Four kinds of model, four units, four paths that can each go wrong. Only by taking them apart can each segment's cost and risk be pinned down. Squeezing them into one "a few cents per run" figure merges four unlike things into a single number — and when it rises, you cannot say where.

Different units also fail differently. One character wrong in the transcript is a text error. A judgment pointed the wrong way is a conclusion error. An error at the indexing stage shows up days later as a bad search result. The three need entirely different remedies, which is why "which segment costs more" and "which segment must not be wrong" are separate questions and must be answered separately.

Pick per segment: the four need not come from one vendor

If each segment is its own bill, it can also be its own choice: pick speech recognition for accuracy and for how it handles accents and dialects; pick the text model that measures well on your task; pick embeddings for stable, low prices — what they are judged on is retrieval hit rate, not intelligence.

The price of splitting is integration and operations: several sets of APIs, quotas, and rate-limit policies for you to reconcile. So it depends on scale. With one or two features and modest traffic, binding to a single vendor and keeping the complexity down works out better. Split the segments once cost has genuinely become a problem. The trigger is the share of the bill, not a cleaner-looking architecture.

Two more bills beyond the unit price

The first is waiting. Non-text models tend to carry hard limits on concurrency and on how long a job may run: a video generation may take tens of seconds, even minutes. That is not only a money question; it is a product-design question. The wait needs a proper answer — can you hand back a draft, can the user leave and return — rather than a spinner to stare at.

The second is where failures land. In a four-segment pipeline, a failure anywhere surfaces to the user as the same "it didn't work." So each segment needs its own logs and its own retry, rather than the pipeline being one black box. How to do that is Attribute Cost Down to Every Step — once the units are separate, the bill can be split.