GPT-5.6 Sol costs $5.00 per million input tokens. GPT-5.6 Luna costs $0.20 — twenty-five times less. Their output-to-input ratio, despite that gap? Identical. Exactly 6.0x, on both.
That's not a coincidence, and once you see it, it changes what's actually worth comparing when you're evaluating LLM API pricing — because the number that stays constant turns out to matter more than the number that changes.
The Table, and the Pattern Hiding Inside It
Here's a real snapshot of current LLM API pricing across nine model tiers:
I added that fourth column myself — no pricing page shows it directly, but it's sitting right there once you divide output by input. And once you calculate it across all nine rows, two things become obvious that the input and output columns alone don't tell you.
Finding One: The Ratio Is a Provider-Level Design Choice, Not a Per-Model Accident
Look at the three GPT-5.6 tiers. Sol, Terra, and Luna are priced 25x apart from cheapest to most expensive. That's a massive spread — clearly reflecting real differences in capability and compute cost. And yet the ratio between their output and input prices doesn't move at all: 6.0x, 6.0x, 6.0x, across every tier.
The same holds inside DeepSeek's range-based pricing. DeepSeek-V4 Flash's price varies by time of day — $0.22 to $0.44 for input, $0.66 to $1.32 for output — but the ratio between those two numbers is exactly 3.0x at both the low end and the high end of the range. Whatever's driving the peak/off-peak price swing, it's scaling input and output proportionally, not changing the relationship between them.
This tells you something useful: the output/input multiplier isn't really a property of a specific model tier. It's closer to a pricing policy the provider applies consistently across their whole product line. Once you know DeepSeek prices output at roughly 3x input, you can reasonably expect that relationship to hold whether you're looking at Flash, Pro, or whatever they release next — even though the absolute price will differ.
Finding Two: The Multiplier Itself Varies Meaningfully Across Providers
Here's where it stops being just a curiosity and starts being something worth checking before you commit to a model. Lay the multipliers next to each other:
DeepSeek and Qwen: 3.0x
GLM: ~3.5x
MiniMax: ~4.0x
Kimi: 5.0x
GPT-5.6 (all three tiers): 6.0x
That's a real spread — the highest multiplier in this table is exactly double the lowest. Which means: for the exact same input price, an output-heavy task can cost meaningfully different amounts depending purely on which provider's multiplier you're under, independent of the absolute price level you started comparing at.
Concretely: if two models happen to have similar input pricing but one runs a 3x multiplier and the other runs a 6x multiplier, a task that's mostly output — long-form generation, detailed explanations, verbose structured responses — will cost roughly twice as much on the 6x provider, even though the input price looked comparable when you first glanced at the table.
Why This Matters More Than It Looks Like It Should
Most people evaluating "LLM API pricing" compare the input column, or the output column, or sometimes both side by side — but rarely compute the relationship between them, because it requires an extra step the pricing page doesn't do for you. That extra step turns out to carry real information: it tells you how sensitive a given model's real-world cost is to your specific input/output balance, separate from how cheap or expensive it looks on the surface.
A model with a low multiplier is comparatively more forgiving if your workload skews output-heavy. A model with a high multiplier rewards input-heavy workloads and penalizes output-heavy ones more steeply — meaning the same model can look like the better deal or the worse one purely depending on what you're building, even when nothing about the headline price changed.
How to Actually Use This When Comparing Models
A few concrete things worth doing with this, beyond just knowing it exists:
Calculate the multiplier for every model you're seriously considering. It's one division per row, and it tells you something the input and output columns don't show independently: how the model's cost behaves specifically for output-heavy work, relative to input-heavy work.
Weight your comparison by your actual input/output ratio, not just the multiplier alone. A high-multiplier model is only a real problem if your workload is genuinely output-heavy. If you're mostly sending long context in and getting short structured answers out, the multiplier matters far less than the input price does.
Use a provider's known multiplier to sanity-check pricing on a tier you haven't looked at closely. If a provider consistently prices output at roughly 3x input across the tiers you have checked, and a new tier's ratio looks wildly different, that's worth a second look before assuming the number is right — pricing pages do occasionally have typos or stale figures.
Remember this doesn't replace calculating your actual cost. The multiplier tells you the shape of a model's cost curve, not the absolute number you'll be billed. A 6x multiplier on a very low base price can still be cheaper in absolute terms than a 3x multiplier on a much higher one — the ratio is one input to the decision, not the whole decision.
Where This Connects to a Bigger Pattern
Once you've worked out which models have a cost shape that fits your actual input/output balance, the natural next step is testing the strongest candidates against your real prompts — since a favorable ratio on paper still needs to be verified against your specific task. That's a lot more practical when trying a new model doesn't mean a fresh integration each time. Standardized, OpenAI-compatible access across multiple providers is part of why this kind of detailed, multiplier-aware comparison is something you can actually act on rather than just calculate once and forget. RouteAI is one example offering access to several of the models in the table above, including DeepSeek, Qwen, and Kimi, through one interface — worth mentioning specifically because checking whether a favorable ratio on the pricing page actually holds up for your real workload is exactly the kind of test that's worth running before committing, and easier to run when switching between candidates doesn't require rebuilding your integration each time.
The Actual Takeaway
Every provider on this table prices output as a clean, deliberate multiple of input — not a coincidence, and not something that changes much within their own product line, whether you're looking at their cheapest tier or their most expensive one. What does change, meaningfully, is which multiple a given provider has chosen: from 3x at the low end of this table to 6x at the high end, a real 2x spread that has nothing to do with which model is cheaper on the surface.
Before trusting an LLM API pricing comparison based on the input or output column alone, it's worth doing the one extra division that most tables leave out. It won't tell you which model is cheapest. It'll tell you which one is cheapest for what you're actually building — which is a different, and more useful, question.
TL;DR: LLM providers price output as a fixed, deliberate multiple of input — and that multiple stays constant across a provider's own tiers (GPT-5.6's three tiers are all exactly 6.0x, despite a 25x price spread) and even across time-based price ranges (DeepSeek stays at 3.0x whether at off-peak or peak rates). But the multiplier itself varies meaningfully between providers, from 3x (DeepSeek, Qwen) to 6x (GPT-5.6) in this dataset — meaning output-heavy workloads can cost roughly twice as much on a high-multiplier provider versus a low-multiplier one, even at similar input prices. Calculate this ratio for any models you're seriously comparing, and weight it by your actual input/output balance rather than treating it as a standalone ranking.
Here's the tool I referenced in this post: www.fastrouteai.com
Top comments (0)