September 14 Cuts Agent Capacity While the Meter Was Miscounting
Two independent measurement failures land in the same fortnight: an entitlement change no price list records, and vendor token accounting that quietly overcharged as much as half a quota.
The entitlement was the lever
Nothing in the price list moved: no dollar list price changed. Every budget model keyed to cost-per-seat now understates cost per unit of completed work, and a team without a tokens-per-completed-task denominator has no instrument capable of detecting the next adjustment. I expect more entitlement changes on roughly this cadence. Agentic coding inference economics are unresolved, and the entitlement is the cheapest lever a vendor holds.
The exposed workloads run weekly with no human in the loop: nightly eval sweeps, repo-wide refactors, LLM-as-judge scoring runs, synthetic data generation. Those are also the lowest-difficulty tasks in the portfolio, which is where substitution is viable. Any eval sweep or agent backfill calendared past September 14 should be re-planned against base × 1.25 rather than current measured capacity.
The vendor meter drifted 10–50%
The second failure lands on anyone reconciling spend against vendor dashboards. Unwind AI reports OpenAI resetting paid Codex and ChatGPT Work quotas after fixing token-burn bugs across image compaction, memory workers, subagents, rolling summaries, and MCP result handling, defects that silently consumed 10–50% of customer quota. That is a calibration failure in the only counter most teams have. The control is an independent per-run token ledger reconciled nightly against vendor-reported usage, with the discrepancy tracked as a monitored quantity instead of discovered at a quarterly true-up.
The substitution decision, with numbers
Terminal-Bench 4.0, a widely watched agentic benchmark, publishes resolution rate, tokens, and dollars together. Per Unwind AI's read, ranking by cost per resolution point reverses the order:
| Model | Resolution | Tokens | Run cost | $ per resolution point | Blended $/M tokens |
|---|---|---|---|---|---|
| Opus 5 | 51.8% | 6.5B | ~$6.0K | ~$116 | ~$0.92 |
| Fable 5 | 44.5% | not reported | > GLM-5.3 | — | — |
| GLM-5.3 | 41.8% | 8.7B | ~$2.7K | ~$65 | ~$0.31 |
Two readings matter. First, Fable 5's 44.5% overlaps GLM-5.3's 41.8% inside the published error bars at higher cost. A 2.7-point gap you cannot resolve statistically is not a product feature, and it hands procurement a defensible "that difference isn't real." Second, the cheap model burns 34% more tokens to get there. The thing that figure doesn't tell you is latency and context-window pressure, which never shows up on the invoice. In a context-constrained agent loop the per-token discount erodes faster than the dollars-per-task ratio implies.
The honest framing is best open-weights model per dollar for this task class, tested on in-house traces rather than a public suite. GLM-5.3 is fine-tunable through Tinker, so a task-specialized adapter trained on your own agent traces is a plausible way to beat a generalist frontier model on a narrow distribution. That is the substitution that absorbs a capacity cut.
A 25% limit increase arriving as a 50% boost expires nets out to a cut. Agent spend that cannot be expressed as tokens-per-completed-task will hide the next one too.
What to do
Instrument per-workflow token burn broken out by repo and task class before September 13, and stand up an independent ledger reconciled nightly against vendor-reported usage.
Re-plan every eval sweep, batch scoring job, and agent backfill scheduled after September 14 against base × 1.25 capacity, with a documented fallback model per workflow.
Run a two-week bake-off of a fine-tuned open-weights model against your incumbent on your own task suite this sprint, reporting cost-per-resolved-task and bootstrapped 95% confidence intervals.