Most writing about LLM cost argues over the headline per-token rate. For a real production platform, that number barely matters. What decides the bill is the shape of the workload and the model underneath it.
Here’s an anonymized look at a real customer. We won’t name them or their niche, and the numbers below are rounded and kept in ranges to keep it that way. But the structure is exactly as it runs in production.
The customer
A multi-tenant AI platform — one product, many end customers, each getting AI features built on top. It routes several billion tokens a month through a small set of open-source models (Qwen, MiniMax, MiMo) behind one OpenAI-compatible endpoint.
The interesting part isn’t the volume. It’s the shape. Their input-to-output ratio is enormous — on their busiest model, well over 100:1. They feed large context in and get short, structured answers back. That’s a very different cost profile from a chatbot generating long replies, and it changes which lever matters.
Shape decides the bill
A platform’s traffic isn’t random. It reuses the same large prompts constantly — a shared instruction block, the same tool definitions, per-tenant context like a knowledge base or policy doc, multi-turn agents re-sending the conversation so far. Across thousands of end users hitting the same templates, the workload is overwhelmingly input, lightly output.
The practical upshot: for this customer, the output rate — usually the scary number — is almost a rounding error. The bill is an input-side game. So the two things that actually move it are (1) how cheap the input side is and (2) which model is doing the work.
Model choice is the real lever
This is where open source wins decisively. The frontier open-weight models — Qwen, DeepSeek, GLM, Kimi, MiniMax — now produce output of comparable quality on these tasks (extraction, classification, agentic tool-use, RAG answers) at 4–5× lower per-token prices than a GPT-4-class or Claude-class frontier API.
Stack that against an input-heavy workload and the gap compounds. The same traffic, run on a frontier US-lab API, would cost multiples more for output that isn’t meaningfully better on this kind of task. Run on the right open-source model, this customer operates in production at roughly a third of what frontier pricing would cost for the same traffic — tens of thousands of dollars a month that stays in the business.
The honest caveat
This holds because of their shape: input-heavy, high-volume, well-matched to open-source models. If yours is different — short context, output-dominated, or a task where a frontier model genuinely pulls ahead — the math changes, and we’re not going to pretend otherwise. The point isn’t “everyone saves 65%.” It’s that your workload shape and model choice, not a leaderboard or a headline rate, decide your bill.
If you want the numbers for your own traffic, the cost calculator takes your token volume and shows the delta versus frontier pricing. And if you’re building a multi-tenant platform — where this shape is the norm — that’s exactly what Dynoyard is built for.