Two-tier model families now split explicitly into a cheap “Air” workhorse and a full “Pro” flagship, and the marketing story is always the same: use Air for volume, save Pro for the queries that need it. That story assumes the tier discount applies evenly across the tokens you send and the tokens you get back. On a coding agent it usually doesn’t, and the ratio you run determines whether Air saves you anything at all.
What an agent loop bills you for
A chat request sends a short prompt and gets a short answer, so an even discount and a lopsided one produce the same bill. An agent loop doesn’t work that way. Every step resends the accumulated transcript: the original task, every prior tool call, every file diff, every stderr line the agent read back. The model then emits something small: a patch, a shell command, a one-line explanation. By turn 30 of a multi-file refactor it’s routine to carry six figures of input tokens into a call that produces a few hundred tokens of output. A repo-wide refactor session at that point might send 180K tokens of context to produce a 400-token patch. That imbalance is structural to how agent loops work, not a quirk of one provider.
Pricing on this site, and on every provider page behind it, separates input and output rates for a reason: the two cost different amounts to serve, and providers set margins on each independently. So if Air’s advertised discount over Pro is concentrated in the output rate, an agent workload barely touches it, because output is a rounding error in the token count. The discount you read on the marketing page and the discount your traffic collects can differ by an order of magnitude. The gap stays invisible until you compute the blend.
The active-param clue
You can reason about why the split happens even without KAT-Coder’s exact numbers by looking at a tier pair the site does track in full: GLM-4.5 runs 355B total params with 32B active, and GLM-4.5 Air cuts that to 106B total with 12B active. Active params drive the compute cost of generating each output token, so a roughly 2.7x cut in active params buys a real, structural discount on decode. Prefill, reading the input, benefits less from that same cut, because providers batch and cache large contexts aggressively regardless of model size. That’s the mechanical reason a smaller tier’s headline discount tends to be bigger on output than on input. If KAT-Coder Air v2.5 follows the same pattern relative to Pro v2.5, an input-heavy agent trace inherits the smaller half of that discount, not the bigger one.
Provider spread dwarfs tier spread anyway
Before optimizing which tier to run, check whether you’re on the right provider for either one. As of this writing, several open models tracked here, including Qwen3 235B A22B, show more than 20x spread between the cheapest and priciest provider serving the identical weights. That’s not a tier difference, that’s the same model priced wildly differently depending on who’s hosting it. A KAT-Coder Air deployment on an expensive provider can cost more per agent step than KAT-Coder Pro on a cheap one. Picking the tier before pulling live rates from the model directory gets the optimization order backwards.
The rule
Pull a week of real transcripts from your coding agent and compute the actual input-to-output token ratio, not an assumed one. Agent implementations vary a lot in how aggressively they trim old context, so guessing gets you the wrong crossover point. Then take both tiers’ current input and output rates into the calculator and run your real ratio through both, across at least two providers each. If the blended savings from Air over Pro come in under roughly 15-20% at your ratio, the integration cost of running two model configs, routing logic, prompt tuning, eval coverage for both, isn’t worth carrying for that margin. Stay on Pro and get your discount from picking the cheaper provider instead. If Air still clears 40%+ at your real ratio, that’s the discount worth wiring in.
What this can’t tell you is whether KAT-Coder Air’s discount split actually mirrors GLM’s active-param pattern; that’s an inference from an analogous open family, not a confirmed number for this specific pair. Check both tiers’ live input and output rates directly before committing either config to production.