From 8 requests to 12,000 a week: how a new frontier model takes over a fleet

From 8 requests to 12,000 a week: how a new frontier model takes over a fleet

Published

Read Time:

When a frontier lab ships a new model, every engineering team has the same conversation. Someone wants to switch everything to it immediately. Someone else wants to wait for other people to find the problems. Usually the result is a config change weeks later, made on vibes, rolled out to everyone at once.

We got to watch a different version of that story play out in our own traffic. Claude Opus 5 entered the Weave router's roster in late July. Here's its adoption curve, week by week, with no human ever flipping a switch for the fleet:

Week of

Opus 5 requests

Sessions

Jul 20

8

1

Jul 27

3,673

177

Aug 3

4,763

230

Aug 10

9,056

618

Aug 17

12,330

244

Five weeks from eight requests to twelve thousand, ending at 10.8% of all router traffic. The curve isn't a step function and it isn't an S-curve drawn by a product manager. It's a bandit policy earning confidence.

How the ramp actually works

The router's decision engine is a policy over clusters of work. Requests get classified into task shapes, and within each cluster a set of model "arms" competes based on observed outcomes: did the session succeed, did it spiral, what did it cost, how fast was it. A new model starts as an arm with a prior built from offline evaluation, then live traffic sharpens or erodes that prior.

Week one is the prior being cautious: eight requests is the policy sniffing the new arm. By week two the early outcomes had validated the prior in the clusters where Opus 5 was expected to win, and traffic jumped three orders of magnitude. The weeks after that are the boring, healthy part: share creeping up as the policy finds the boundary of where the new model is actually worth its price, rather than everywhere.

Note the week of Aug 17: requests kept climbing while distinct sessions dropped. The router wasn't spraying Opus 5 across more users; it was concentrating it into longer, heavier sessions, the deep multi-file work where it earns the premium. That's the kind of allocation decision no config file expresses.

What keeps a ramp safe

A bandit exploring in production sounds alarming until you look at what's fenced off. Our decision logs over the same 30 days show the guardrails carrying a lot of weight:

  • 12.4% of requests were user-forced. Someone explicitly pinned a model and the router obeyed. New model or not, an explicit choice is never overridden.

  • 8.4% were hard-pinned for title generation and 4.2% for classifiers. Commodity internal work runs on designated cheap models and is never used as an exploration playground.

  • Ongoing sessions stay on their pinned model (switching mid-session forfeits the prompt cache), so a new arm ramps through fresh sessions, not by yanking live ones.

So the surface where a new model can actually explore is a controlled slice: fresh sessions, non-pinned traffic, clusters where it has a credible prior. That's why the fleet can absorb a frontier model in weeks without anyone getting a surprise.

The part we didn't expect to love

The decision logs also record why each routing choice was made, and reading them during the ramp is genuinely illuminating. One recurring entry: subagent sessions being bootstrapped through the low-cost cluster even when the parent session asked for "high" capability. In practice that means when an Opus 5 session spawns a subagent to go explore the codebase, the router quietly runs that errand on deepseek-v4-flash for a fraction of the cost, and hands the findings back to the expensive model.

That division of labor emerged from the policy's economics, not from anyone designing an "intern pattern." But it's exactly how a good tech lead uses a strong senior engineer: don't send them to grep the codebase, send someone fast and cheap, let the senior engineer think.

The general lesson

Model adoption at fleet scale doesn't have to be a bet-the-quarter migration or an eternal wait-and-see. Treated as a routing problem, a new frontier model is just a new arm with a prior: it earns traffic where it proves out, gets contained where it doesn't, and the whole fleet converges on the answer in weeks with receipts at every step.

The next frontier release will get the same treatment. Eight requests in week one, and we'll see where the curve goes.

Wooly mascot smiling while holding a pencil and a document

Make AI Engineering Simple

Effortless charts, clear scope, easy code review, and team analysis

Published

Abstract white ribbon twisted into a knot
Abstract white ribbon twisted into a knot
Abstract white ribbon twisted into a knot
Abstract white ribbon twisted into a knot

Give your teams the data they need to build the products you want.

Trusted by engineering teams from startups to Fortune 500