On June 15, Anthropic moved programmatic and agent traffic off the flat consumer subscription and onto metered credits priced per token. That closed an arbitrage a lot of teams were running without saying it out loud: point a coding agent at a flat-rate plan, let it churn for hours, pay a fixed monthly fee no matter how many tokens it burned doing it. A stuck retry loop used to be free. Now it shows up on the meter.
Sizing one agent fleet
Take a five-agent coding pipeline running continuous background tasks: file reads, test loops, patch-and-retry cycles. At roughly 200K tokens of context churn per agent-hour, five agents running 20 hours a day land around 20M tokens daily, close to 600M tokens a month. That monthly number, more than the model name on the config file, is what should pick your billing path.
Below that volume, metered subscription credits are still the right default. You’re not running enough tokens to justify managing a provider account, a fallback model, or infrastructure. Somewhere past it, the math flips, and it flips in a specific order: subscription credits lose first, then raw frontier API, then even the cheaper open-weight API tier, until self-hosting a GPU wins outright.
Where the flat-rate math breaks
A five-agent fleet at 600M tokens a month isn’t a hypothetical stress test. It’s a normal Tuesday for a team that lets agents run unattended overnight. The expensive case is a tool call that times out: the agent doesn’t recognize the failure and retries the same 40K-token context window every 90 seconds for six hours before anyone checks the dashboard. On a flat plan that costs nothing extra. On metered credits it’s a six-hour bill for output nobody wanted. Metered pricing turns agent reliability into an economic problem on top of an engineering one.
Once volume clears that threshold, raw API access to a frontier model is the next thing to get expensive, because you’re paying for a dense or lightly-sparse model’s full compute on every token regardless of whether the task needed it.
Open-weight agent models change the active-param math
Kimi K2.7 Code, GLM-5.2, and DeepSeek V4 Flash are priced several times below frontier closed models on the model price pages as of this writing, and the reason is active parameters. K2.7 Code carries 1059B total parameters but only 32B active per token. Your inference bill tracks active params, so at the API tier it behaves and prices like a much smaller model while still drawing on a much larger one for capability.
That same property makes self-hosting these models deceptive.
The capacity trap in MoE agent models
Active params drive cost; total params drive capacity. K2.7 Code’s 32B active footprint suggests a single GPU. Its 1059B total footprint says otherwise: at roughly 1.1 GB per billion parameters in FP8, the weights alone need over 1,100 GB, before KV cache headroom. Even at aggressive INT4 quantization you’re near 600 GB of weights plus another 25% for KV, which rules out a single-GPU deployment and most dual-GPU ones. You need a cluster sized for total parameters, evaluated against the H200 or MI300X pages for a card with enough memory per unit to make the cluster count reasonable, not the H100 SXM page sized as if 32B active meant a 32B-sized deployment.
Teams that skip this step quote themselves a GPU budget for a 32B model, then discover they needed capacity for a 1059B one.
Provider choice beats model choice at the API tier
Before you even get to self-hosting, check whether you’re overpaying for the model you already picked. Qwen3 235B A22B shows a spread of over 20x between its cheapest and priciest hosting provider on the model price pages, for identical weights. At mid-range monthly volume, picking the wrong provider for the right model costs more than picking the wrong model.
The volume threshold that picks your path
Under roughly 50-100M agent tokens a month, stay on metered subscription credits: the operational overhead of managing API keys and fallback providers isn’t worth it yet. Between there and a few hundred million tokens, move to raw API access on an open-weight agent model like K2.7 Code, GLM-5.2, or V4 Flash, and shop providers before you shop models, since the spread between providers can dwarf the spread between models. Past several hundred million tokens a month sustained, run the numbers in the calculator against a rented cluster sized for total parameters rather than active ones, and check the GPU price pages for marketplace tiers on H100 SXM or MI300X, where community pricing runs 70%+ below secure on-demand, if your agent workload can tolerate no SLA.
What this can’t tell you is your own retry rate. A fleet that hits its target on the first pass at 600M tokens a month and one that loops three times before succeeding are running the same agent code at very different real costs, and only your logs know which one you have.