Your Engineers Are Running Fable 5 on Merge Conflicts

One of our engineers ran a session last week called “Confirm rollout steps for meters table.” Twenty-two turns. Four hundred and twenty-seven API calls. About 30 hours from first call to last. Total cost: $100.66.

Roughly 91% went to Fable 5, nearly 9% to Opus, and five cents to Haiku.

I don’t know exactly which of those 427 calls needed the frontier model. When the default is Fable, everything gets Fable. You don’t make a model choice; you just work.

But think about an organization with 5,000 engineers. If AI coding sessions average $40 per engineer per working day, that’s roughly $44 million annually. If session telemetry shows that 25% of that work can move to models costing 60% less—with comparable completion rates—that’s $6.6 million in potential annual savings.

At enterprise scale, defaulting every task to the strongest model creates a hidden “frontier tax.” Paper Console exposes where expensive model usage may not be justified, giving organizations the evidence to investigate and optimize model allocation.

When the default is frontier, the math compounds

In April, Uber’s CTO told The Information that the company had burned through its entire planned 2026 AI coding budget in four months. Uber was running Claude Code and Cursor. The tools worked well enough that engineers wouldn’t stop using them. Consumption-based pricing converts “loved by the team” directly into “over budget by Q2.”

On June 1, GitHub switched Copilot to usage-based billing. Code completions stayed unmetered, but everything agentic, everything multi-step, started burning at per-model API rates. One developer reported going from $29 to $750 a month. A company with 80 engineers calculated their new monthly spend would equal the annual salary of a full-time engineer.

These aren’t outliers. A study covering 372 enterprises found that only 15% of companies forecast AI costs within 10% of actual. Nearly one in four miss by more than 50%. The miss isn’t random. It’s structural. When no one can see what’s happening at the session level, the budget conversation happens after the fact.

Merge conflict resolution doesn’t require the frontier model

“Merge conflicts” is shorthand for the thousands of contained, repetitive tasks happening across a large engineering organization every day: test scaffolding, rollout verification, formatting, repository searches, dependency updates, and yes, plenty of routine conflicts.

You can’t route what you can’t see.

The expensive decision isn’t that an engineer deliberately chose Fable 5 for a merge conflict. It’s that nobody chose. The default chose, and it makes that decision thousands of times a day.

If your team’s default is Fable 5 and you have 200 engineers running Claude Code, you’re paying Fable 5 rates for routine work. No one made that call. The default made it for them.

Haiku, in that session I mentioned, handled five calls and cost five cents. Five cents. The session cost $100.66. Those five Haiku calls were presumably simple enough that something in the session routing used the cheaper model, but 269 Fable calls happened anyway, for $91.60.

Whether Haiku could have handled some of those 269 Fable calls is worth investigating. But before that: can anyone on your team even pull up that question right now?

This isn’t an argument for taking powerful models away from engineers. It’s an argument for reserving their capacity for the work that benefits from it.

The problem is that most organizations can’t tell how much routable work exists. They can see the invoice. They don’t know which tasks ran on which models, what those sessions cost, or where frontier capacity produced frontier value.

That’s the frontier-default tax: not paying for powerful models when you need them, but paying for them indiscriminately because nobody can see enough to make a different decision.

What paper console surfaces

I can pull up that session in paper console and see exactly what I showed above: model usage by cost, broken down at the session level. Fable 5, 91%. Opus, nearly 9%. Haiku, less than 0.1%.

That per session view with specific dollar amounts is the starting point for a real conversation with your engineering director or CFO. Compare it to walking in and saying, “We think we might be over-provisioned.” The difference between those two conversations is an evidence base.

The session data shows which model each call ran on. Whether that model was the right one is a separate, more consequential question. That gap, across enough sessions, is where your potential budget savings are.

A team that can answer, “What was our model mix by session last week?” is in a completely different position than a team guessing. One team has a routing conversation. The other gets surprised by a Q3 reconciliation.

The question finance is already asking

GitHub’s billing change put a specific question on every engineering director’s desk: What are we actually paying for at the session level?

The 2024 question was: What tools do we have? Everyone bought licenses.

The 2026 question is different: Which sessions? Which models? Which tasks are costing what?

When the bill is attached to usage rather than seats, “We think we’re using it well” stops being an acceptable answer.

For a 200-person engineering organization, model routing is a budget optimization. For a 5,000-person organization, it may be worth millions.

The paper console shows you where to look.

Your frontier models should be doing frontier work.

Do you know whether they are? Start capturing your team’s session data with paper cli so you can see the numbers in paper console. Then you can have the conversation with your CFO before the invoice arrives.