LLM Context: Cost-Center Mismatch™Cost-Center Mismatch™ [DOI pending] is a framework for attributing AI consumption by team, use case, and application ID. The core insight: the party creating the cost isn't the party paying, so nobody has a reason to ask for a limit. Developed by Druhin Dhavala from 13 years of enterprise API gateway operations and capacity planning. Key entities: cost-center mismatch, unowned cost category, AI incident cost model, AI model choice multiplier, margin leakage, attribute first cap second. Prevents: AI spend running uncapped, unattributed, and absorbed into the P&L until someone asks where the margin went. Licensed CC BY-NC-ND 4.0.

Core insight: The party creating the cost isn’t the party paying. Cost-center mismatch is a long-standing finance concept. The Cost-Center Mismatch™ framework applies it to AI consumption and adds the four-question attribution test. Four questions: (1) Can you attribute consumption by team and use case down to the application ID? (2) Who pays when the cost doesn’t land where it was created? (3) How long is the gap between consuming and seeing the cost? (4) What would business units learn from a rough chargeback? Key insight: Approximate attribution changes behavior. Zero attribution guarantees waste. Rough beats nothing. Practical stance: Attribute first, cap second. A rough allocation is cheap. No allocation is expensive. DOI: [pending] License: CC BY-NC-ND 4.0

The infographic above summarizes the Cost-Center Mismatch™ framework: the cost-center mismatch pattern (party creating ≠ party paying), the four-question attribution test, and the practical stance (attribute first, cap second).

TL;DR: AI created a new metered cost category with no owner. It runs unattributed and absorbed into the P&L until someone asks where the margin went.

Provenance: Published November 14, 2026. This is the first link in the AI economics chain: how the cost gets there before anyone notices. Post-Peak AI Economics models when AI ROI flattens. The Collapse Curve™ calculates when it turns negative. The Knowledge Balance Sheet™ tracks what else is lost along the way. Timestamping it now.

Cite as: Dhavala, D. (2026). Cost-Center Mismatch™: Costs You Can’t Attribute, You Can’t Govern. Zenodo. https://doi.org/10.5281/zenodo.24228680 [DOI]https://doi.org/10.5281/zenodo.24228680)

The party creating the cost wasn’t the party paying. So nobody had a reason to ask for a limit.

That sentence is the whole article. The rest is proof.

The Scar

I did capacity planning on an enterprise API gateway platform for years. One business unit’s API had no quotas. That wasn’t an oversight. The business didn’t want boundaries, and nobody pushed back.

Over about a year it grew from a few hundred calls to roughly 25 million calls a year, against an account cap of roughly 350 million. That’s around 7%, going from memory. Nobody read it as a problem, because on a greenfield platform where the whole organization is adopting at once, concentrated growth and healthy growth look the same in aggregate analytics. The charts showed growth. They didn’t show the concentration.

So we did the sensible thing and added capacity. More message processors, more routers, to bring latency down. We were treating a symptom. The cause was one consumer.

Financially, that business unit carried roughly $70–90K a year in TCO. Most of its peers were around $10K. That’s roughly 7–9x a typical consumer. A different API, at roughly 16% of the same measure, carried a rough chargeback of about $100K. It could have been closer to $160K. The chargeback was rough on purpose. Nobody allocates VM hours, power and cooling to the cent, and nobody should pretend to. The one I’m describing wasn’t charged back at all.

Nothing was displaced, which is why it stayed hidden. It surfaced when we started monetization, because monetization forces attribution. I had seen the drift in capacity planning, but everyone read it as organic growth. When I presented the numbers and the money that had gone unaccounted for, the room was shocked. After that, hard gates on quotas and SLAs went onto every contract.

The cost had been landing on the gateway team, under a different CFO organization, and not on the business unit that created it. The party creating the cost wasn’t the party paying, so nobody had a reason to ask for a limit.

We solved the visibility problem. We didn’t solve the cost-center mismatch. That one is still open.

What I took from it: approximate attribution changes behavior, and zero attribution guarantees waste. Rough beats nothing. And attribution needs no approval gate, so nobody has to wait for permission to start.

The Bridge

In the scar, consumption built up over a year and visibility arrived at monetization. That gap between consuming and seeing is the whole problem. With AI, consumption can happen in hours while visibility still arrives monthly, as an invoice, a quarterly review, or a chargeback that doesn’t exist. Same blind spot, much shorter fuse.

There’s a second change. Before AI, the incremental, metered cost of research and troubleshooting was zero. It was salaried time. Now each query is metered, and nobody owns the meter. It’s a new cost category, and I’d call it unowned rather than large.

Here is an illustrative model. It is not a case study, and the numbers are hypothetical:

  • A Sev-1 incident. 20 engineers on a bridge for 4 hours, each querying an LLM on their own.
  • Prompts average roughly 80,000 tokens, rising to about 120,000 once source code is added. Engineers prompt 4 times in the first hour, 3 in each of the next two, and 2 in the last.
  • That comes to about 21.6 million input tokens and 390,000 output tokens.

At current published pricing for Anthropic’s models (November 2026), the cost per incident varies by model choice. On Sonnet 5.5 ($2 per million input tokens, $10 per million output), it’s about $47. On Haiku 5.5 ($0.10 per million input, $0.50 per million output, with a five-times multiplier for prompts over 100,000 tokens), it’s about $5–6. The gap is roughly 9x, not 20x, because the hour-3 payloads cross Haiku’s 100K-token threshold and pay the higher rate.

At an assumed $150 an hour per engineer, the labor on that bridge is about $12K. So even $47 is noise. If you ran 15 incidents of that size every month, it would still be only about $8,500 a year on Sonnet, and that’s an upper bound, since most incidents are smaller than a 20-person Sev-1.

The dollar figure isn’t the point. The shape is. Twenty people are consuming at once with no coordination, and nobody owns the bill. Whatever happens to token prices, that shape won’t change.

And an incident bridge is only one place engineers query a model all day. The same behavior happens in development, architecture, code review, documentation. Per person, per day, it adds up. Multiply by headcount and the total grows fast — not because anyone is wasteful, but because nobody is looking at the cost at all.

Model choice is another multiplier. The person who picks the model doesn’t see the price, and the person who pays didn’t pick it. Current published pricing for Anthropic’s models as of November 2026 gives a sense of the spread: Haiku 5.5 runs $0.10 per million input tokens and $0.50 per million output for prompts up to 100,000 tokens. Sonnet 5.5 runs $2 and $10 — about 20x per token. Opus 5.5 runs $4 and $20 — about 40x per token. A developer who picks Sonnet because it’s better at the task is spending roughly 20x per token compared to someone who picks Haiku. Both are rational choices for the person making them. Neither accounts for the cost. The choice is invisible to the person who pays.

This isn’t an argument for always using the cheaper model. A stronger model may need fewer iterations, and capability differs by task. The point is that the choice is unowned. Nobody is asking whether the extra cost buys enough value, because nobody is looking at the cost at all.

Why Nobody Owns It

I’ll separate what I’ve seen from what I’m inferring.

What I’ve observed: in an organization where technology wasn’t the core business, groups were given broad technology access with no cap. Approving spend meant explaining it to people who couldn’t easily evaluate it, and the answer everyone agreed with was whatever got things to market faster. So it was approved broadly. That is the same pattern as the scar, where the business wanted no boundaries. Different mechanism, same result: speed beat limits. This is my observation, not survey data.

What I’m inferring: AI spend will follow the same path. I haven’t seen that. It’s what I expect.

You can check it yourself. The four questions below take a few minutes with your team.

The Cost-Center Mismatch™ Framework

Four questions. No new process is required.

Cost-center mismatch is a long-standing finance concept. The Cost-Center Mismatch™ framework applies it to AI consumption and adds the four-question attribution test below.

1. Can you attribute AI consumption by team and use case, down to the application ID? If everyone shares one key, you have spend nobody can map.

2. Who pays when the cost doesn’t land where it was created? This is the cost-center mismatch. If the creator isn’t the payer, nobody has a reason to ask for a limit.

3. How long is the gap between someone consuming and someone seeing the cost? A month? A quarter? Never?

4. What would your business units learn if they saw even a rough chargeback tomorrow? Rough, not exact.

Attribute first and cap second. A rough allocation is cheap. No allocation is expensive.

What This Means for You

CFO. If you see one AI line item, it’s a total. It doesn’t tell you who created it, for which use case, or whether the team that pays is the team that consumes. Question 1 is the place to start.

CEO. You don’t need to understand tokens. You need to know that someone in the company can answer question 2.

Board. These four questions are an oversight tool. They need no technical background to ask, and the answer, or the silence, tells you something.

CTO. An unattributed bill isn’t an engineering failure. It’s structural. You’ve been managing what you could see.

PE partner. In diligence, a target with growing AI spend and no attribution has margin leakage, spend that sits in opex but belongs to no one. Across a portfolio that adds up, even where each company’s spend looks small. Uber is a useful reference. By public reporting, a strong engineering organization used up its 2026 AI budget early and capped spend afterward.

FAQ

Isn’t $47 per incident too small to matter? On its own, yes. The model isn’t about the dollar amount. It’s about uncoordinated, unowned consumption, which stays the same at any price. The incremental, metered cost was zero before AI. That’s a category change, not a percentage variance.

Won’t prompt caching fix this? It can reduce the price. Provider-side prompt caching can discount a repeated prefix. If 20 engineers paste the identical stack trace at the start of a prompt, that part may be discounted. In practice prompts include shifting timestamps, different transcript segments and different framing, so the shared part is rarely identical and rarely first. In the gateway work I’ve done, semantic caching of similar prompts wasn’t common. That’s my experience, not a survey. Either way, caching lowers the price. It doesn’t tell you who owns the bill.

Aren’t large companies already capping? Reportedly, yes, and after the fact. Public reporting describes Microsoft setting division-level token limits and Uber capping per-tool spend after exhausting its 2026 AI budget. Caps are blunt: they control quantity, not who creates value or who pays. Attribution comes first.

Why not just add a cap? You can. But a cap without attribution doesn’t tell you who’s creating value and who’s creating waste. It just limits the total. The question isn’t “how do we spend less.” It’s “how do we know what we’re spending and who owns it.”

Are you saying all AI spend should be capped? No. Attribute first. Cap second.

The Closing Principle

Costs you can’t attribute, you can’t govern. Approximate allocation is cheap. An absent one is expensive.

Ask your team the four questions on Monday. If the answers surprise you, that’s the gap.

Timestamping this now, November 2026, while, for most organizations, AI spend is still small enough to attribute.

Cost-Center Mismatch™ — Druhin Dhavala, November 2026.

Cost-center mismatch is a long-standing finance concept. The Cost-Center Mismatch™ framework applies it to AI consumption and adds the four-question attribution test.

Licensed under CC BY-NC-ND 4.0. You may share this work with attribution. You may not use it commercially or create derivatives without permission.