Simon Willison flagged a chart this week from inside OpenAI’s own research org, and it’s one of the more honest data points I’ve seen about how agentic coding tools actually get adopted — because it’s internal telemetry, not a vendor case study. It tracks daily AI spend per researcher, and the shape of the curve says more than any adoption-rate survey could.
Through February 2026, daily spend per researcher sat near zero. Through spring it crept up — roughly $50/day by April, $150/day by June — then plateaued around $150-165 through most of July. Then, in late July, it broke upward sharply, reaching approximately $600 per researcher per day by late August. Willison’s read, which lines up with the timing, is that the inflection correlates with internal access to what became GPT-6 Astra. Not a mandate. Not a new policy. A model crossing a usability threshold that the previous ones hadn’t.
If you’re a Tech Lead who has spent the last year trying to get your own team to actually use agentic tooling instead of nodding along in the all-hands, this curve is worth studying more closely than the model announcement itself.
The plateau is the interesting part, not the spike
Everyone’s instinct is to talk about the spike. The plateau is more useful. Four months — February through June — of flat, low spend despite presumably having access to perfectly capable models the whole time (GPT-5-class models were in production well before this period) tells you adoption isn’t primarily a capability problem once you’re past a baseline. It’s a trust and workflow-fit problem. Researchers weren’t spending more because the previous models weren’t clearing whatever bar makes someone reach for the agent by default instead of as a novelty.
This matches what I’ve seen rolling out agentic coding tools on real teams: you get an initial curiosity bump, it plateaus at “the people who already liked this stuff,” and then it sits there — sometimes for months — until either the tool crosses a capability threshold or something forces a workflow change. Budget for that plateau. If your adoption chart looks flat three months after rollout, that’s not necessarily a failed rollout; it might be an accurate read of where the tool actually is relative to the workflow.
What a 4x jump in six weeks actually implies operationally
Going from ~$150/day to ~$600/day per researcher isn’t a linear scaling of the same usage pattern — that’s a change in what the tool is being used for. A few operational implications, all things I’d be checking if I saw this curve on my own team’s dashboard instead of OpenAI’s:
Cost governance has to be event-driven, not quarterly. If your finance/eng cost review cadence is quarterly and your actual spend curve looks like this, you find out about the 4x three months after it happened, once the invoice lands. A simple daily-spend-per-seat dashboard with an alert threshold catches the inflection while it’s still explainable (“the new model shipped Tuesday”) instead of when it’s a line item someone has to justify after the fact.
# minimal daily-spend-per-seat tripwire, no ML required
def check_spend_inflection(daily_spend: list[float], window: int = 14, threshold: float = 2.0):
"""Flag when recent average spend exceeds `threshold`x the prior window's average."""
if len(daily_spend) < window * 2:
return None
recent = sum(daily_spend[-window:]) / window
prior = sum(daily_spend[-2*window:-window]) / window
if prior > 0 and recent / prior >= threshold:
return {"multiplier": round(recent / prior, 2), "recent_avg": recent, "prior_avg": prior}
return NoneA sharp adoption curve is a capacity-planning event, not just a cost event. If usage shape changes that fast, your rate limits, API quotas, and any shared infra (proxy layers, credential brokers, logging pipelines) sized for the plateau period will get stressed exactly when you least want a surprise outage. Re-check headroom whenever you see the early signs of an inflection, not after it’s fully arrived.
The spend number alone tells you nothing about ROI — but the shape tells you about trust. $600/researcher/day is meaningless without knowing what didn’t happen because of it: bugs shipped, cycle time, research iteration speed. But the shape of the curve — flat, then a step change tied to a specific model release — is itself a signal independent of ROI: it means the previous tooling wasn’t the blocker, the capability bar was. That’s a useful thing to know before you spend a quarter on change-management training when the real gap is model capability, or vice versa.
The gap between “available” and “adopted”
The part of this I keep coming back to: OpenAI’s own researchers — plausibly the most agent-fluent, least tool-averse population you could find anywhere — took roughly five months to move usage meaningfully, and the thing that moved it wasn’t training, mandate, or incentive. It was the tool clearing a bar.
That’s a useful corrective if you’re an engineering leader currently frustrated that your team’s adoption of Claude Code, Cursor, or whatever your standard agent is looks flat despite investment in onboarding and internal champions. The lesson isn’t “give up on change management” — the champions and onboarding matter for capturing the adoption once the tool is actually good enough, and they compress the lag between capability crossing the bar and usage catching up. But don’t mistake a flat curve for a people problem before you’ve ruled out a tool-capability problem. The most agent-native team on the planet sat at a plateau for four months waiting on the model, not the training.
If you’re tracking your own team’s agent adoption, the actionable version of this is simple: plot daily spend or usage per engineer over time, and instead of asking “why isn’t adoption higher,” ask “does this look like a plateau waiting on capability, or a plateau despite capability.” Those require completely different fixes, and the OpenAI curve is a reminder that the first case is more common than most rollout postmortems assume.
Sources: