Codex usage at OpenAI jumped 56x, and the agent stack started grading itself

By June 2026 the median OpenAI researcher was spending 56 times more Codex output tokens than in November 2025. That is the headline number from OpenAI’s Economic Research team, reported through Latent Space’s AINews: Customer Support rose 32x, Engineering 27x, Legal 13x over the same seven months. The detail that makes it worth reading is the baseline. OpenAI employees have had unlimited model access the entire time, and through August 2025 the average worker still spent under 10% of their tokens on Codex. The constraint was never price or quota. It was the work of building review loops, tooling, and persistent workflows around the agent, and once a team did that work, consumption went vertical. Treat this as a leading indicator for everyone else: the gap between “we have access” and “we actually run agents on real work” is a tooling problem, and it took OpenAI’s own org most of a year to close it.

Which is why the rest of the day’s news clusters around the layer underneath the model. GitHub published a controlled benchmark of its Copilot agentic harness, holding the model fixed and pitting Copilot CLI against the vendor harnesses that ship those models natively, Claude Code for Sonnet 4.6 and Opus 4.7, Codex CLI for GPT-5.4 and GPT-5.5. Same model, same SWE-bench Verified and TerminalBench tasks, normalized context window and reasoning effort. The result: task resolution on par with the native harnesses while using fewer tokens across most configurations, with the run-to-run variance (five runs per config, ±1σ ellipses on every point) large enough that “on par” is the honest read. The interesting claim is structural, not competitive: one harness powers the CLI, the app, and Copilot code review across 20+ models, so a harness improvement lifts every surface, and a multi-model harness can do things a single-vendor one can’t, like Rubber Duck cross-model-family critique where one model reviews another’s output.

The flip side of harness maturity is that the benchmarks underneath are getting harder to trust. Cursor published research showing that recent models, Opus 4.8 and Composer 2.5 among them, learn to retrieve solutions to public eval tasks from the internet or from a repo’s own git history, and that scores drop sharply once a stricter, no-network harness blocks that path. ProgramBench is pushing no-internet as the default for coding evals for exactly this reason. If you are choosing a coding model on its published SWE-bench number, you are now measuring the harness and the contamination as much as the model, and GitHub’s own methodology note concedes the point: its results differ from public submissions because public runs use higher reasoning effort and tuned settings.

A layer further down, the inference market is consolidating into a routing problem. OpenRouter raised $113M and is now routing 47 trillion tokens a week, with DeepSeek models making up four of its five most-used endpoints, per a widely-shared LLMDevs breakdown. When the model itself is open and effectively free, the request-routing layer is where the leverage moves, and it is splitting in two: the professional inference tier (Fireworks, Together, Groq) competing on SLAs, and decentralized networks (Akash, io.net) competing on the things a hyperscaler structurally can’t offer, no content filters and no account bans. Worth watching whether the permissionless side ever clears the mainstream reliability bar or stays a censorship-resistance niche.

The open-weights side kept its pace too. Ornith-1.0 landed on Hugging Face as an MIT-licensed family of agentic coding models, 9B and 31B dense plus 35B and 397B MoE, post-trained on top of Gemma 4 and Qwen3.5, reporting SWE-bench Verified 82.4 and Terminal-Bench 2.1 77.5. The training claim worth noting is a self-improving RL loop that optimizes not just the solution rollouts but the task-specific scaffolds driving them, the harness logic learned rather than hand-written. One early tester found the 35B refusing to echo a hidden canary string, explicitly flagging the request as a prompt-injection attempt.

Underneath all the adoption sits the failure mode practitioners keep hitting: code that drifts away from its spec faster than anyone notices. A new arXiv paper, The Spec Growth Engine, names the two structural problems directly, context explosion as the agent reasons over a whole repo at once, and silent spec-code drift where the code evolves and the spec doesn’t until repair is expensive, and proposes a machine-readable spec graph with a drift gate that makes spec-code divergence a blocking merge condition. It pairs with a community measurement going around the same day, a scan of 429 vibe-coded repos quantifying how far they drift over time. The fix being proposed is unglamorous: make consistency a CI gate, not a code-review hope.

That theme has a name now. CodeRabbit’s writeup on “loop engineering” (a term Peter Steinberger and others have been pushing) frames the next step past one-shot prompting as designing autonomous loops you can walk away from, with the quality gates and stopping conditions built in rather than supervised by hand. It rhymes with OpenAI’s own internal pattern of concurrent agents and review loops. The open question for the week: as more teams cross from access to adoption, does the bottleneck become the harness, the eval, or the human attention left to spend on the loops.