When your LLM bill drops 40 percent month to month, the natural reaction is to claim credit for whatever optimization you shipped last sprint. The problem is that usage changes, pricing changes, and architecture changes all move the number, and a dashboard that only shows the total without splitting them apart leads teams to thank the wrong lever. A framework borrowed from cloud FinOps applies directly to LLM spend, and teams that adopt it early avoid the guessing game that plagued AWS cost management for years.

Three Axes, One Bill

Every change in LLM spend breaks down into three independent categories. Usage changed: you sent more or fewer tokens. Pricing changed: your cost per token shifted because of a discount, a markup, or a billing policy. Architecture changed: the gateway, routing, or caching layer altered how the workload reached the model. Most real cost movements are a mix of two or all three. The discipline is measuring each one in isolation before attributing the total.

Cloud FinOps figured this out a decade ago. A lower AWS bill could mean fewer instance hours, a Savings Plan kicking in, or a rightsizing project. Teams that confused them made bad next-quarter bets. LLM spend is going through the same curve, with more moving parts between the user prompt and the invoice line item: model choice, cache hit rate, provider markup, batch discounts, per-org rate limits, and gateway routing all pull on the number.

Axis 1: Usage

Usage is the change in how much work your application asks the LLM to do, measured before any pricing or architecture decisions. More or fewer end users, longer or shorter prompts from growing RAG context windows, chattier system prompts, new features that add or remove LLM calls. The measurement is straightforward: compare input plus output tokens month to month, not dollars. If token count changed but cost per token did not, the entire delta is usage.

The common mistake is crediting a lower bill to optimization when fewer users showed up. That is a churn signal, not an efficiency signal. The monthly question worth asking: what would this bill have been at last month's cost per token? If the answer is close to this month's total, usage moved. If it is far off, usage is flat and something else did the work.

Axis 2: Pricing

Pricing is what changed about how you buy tokens, not what tokens you bought. This axis lives in contracts, procurement, and provider conversations that most engineering teams never see. A committed-use discount kicked in. Provisioned throughput replaced on-demand rates. A gateway markup got added or removed. Cache-hit billing changed: Anthropic charges 10 percent of base for cached input, OpenAI dropped cached-input rates in mid-2026, DeepSeek moved to peak and off-peak pricing in August 2026. Batch API discounts offer 50 percent off if you can wait.

The measurement: compute effective dollars per million input tokens and dollars per million output tokens for the same model at the same request pattern across months. If usage is flat and the effective rate changed, the entire delta is pricing. The common mistake is giving engineering credit for a bill drop that was really finance negotiating a committed-use tier. Both teams are right, and both are underselling. Without splitting them, one team's story becomes official and the real driver gets missed.

Architecture

Architecture is what the gateway, routing, and caching layer changed in how the workload got served before it reached the model. Cache hit rate moved. Cheaper-model routing kicked in. A prompt that used to hit a premium model now hits a cheaper one on the same-tier arbitrage rule. Retry policy tightened. Failover happened to a secondary provider with different costs. Multiple small requests merged into one batch. MCP tool-use loops resolved in one round trip instead of three.

Measurement requires gateway logs: per-request records of model chosen, cache hit or miss, retry count, and failover events. For a fixed workload and fixed contract terms, compare effective cost per request across months. If the token bill dropped but request count and unit rates are flat, the architecture in front of the model changed. The common mistake is treating a cache-hit-rate improvement as an architectural win when the customer's prompt pattern happened to shift toward more repetitive requests. That is usage pretending to be architecture.

A Worked Example

Two teams, both sending 100 million Sonnet 5 tokens per month with a 5-to-1 input-to-output ratio. Team A pays retail directly to Anthropic: about $2,000 per month. Team B has a 10 percent committed-use discount, routes through a flat-fee BYOK gateway at $25 per month, and maintains a 30 percent prompt cache hit rate. Team B's total is roughly $1,295 per month.

Same model, same workload, 35 percent unit cost difference. Breaking it down: about $200 of the gap comes from pricing (the 10 percent commit on 90 percent of traffic), about $500 from architecture (the cache hit rate and routing), and zero from usage (identical traffic). The $25 gateway fee is negligible compared to the routing savings it enables. If Team B's dashboard only says "we spend 35 percent less," they cannot answer which lever to pull if Team A ever tries to close the gap.

The Monthly Discipline

Every monthly LLM cost review should answer three questions in order. What did usage do (token count, request count month to month)? What did pricing do (effective dollars per token by model month to month)? What did architecture do (effective cost per request at fixed usage and contract terms month to month)? The three numbers should add up to the total dollar change. If they do not, something is quietly moving that nobody named: a default model changed, a new feature launched without telling finance, a retry storm during a provider outage bloated the bill.

Teams that build this reflex early develop something the teams that skip it lack: an accurate story about why the LLM bill did what it did. That is what makes future budgets defensible and future optimizations credible. The vocabulary comes first. The dashboards, gateway choice, and vendor contracts follow from having the language to say which axis moved.