Updated 30 June 2026

Added a new section, "The tokens are already moving", on open-weight adoption: OpenRouter's traffic split and Meituan's MIT-licensed LongCat-2.0. A later pass the same day extended that section with the migration tooling now arriving (inference.net's eval-gated gateway) and the move toward teams post-training and owning their own open-weight models.

The question in the title is the one I keep circling, and I want to resist answering it too quickly. "Good enough" is a moving line. It depends entirely on the task, and the moment you state it as a slogan you have stopped looking at the evidence. So this is less a position than an audit: I had a thesis, the numbers complicated it from several directions, and the messier version turned out more interesting than the clean one I started with.

The thesis: for a large share of day-to-day programming, you no longer need a frontier model. Most of what an agent does on a working repository is not hard. Rename this, wire that, write the test, fix the obvious bug, port the function. A model that is merely intelligent enough clears that bar, and the floor of "intelligent enough" has dropped fast. What used to be the exclusive territory of or is now reachable by open-weight models you can rent for cents or run on your own hardware. The skill that matters is no longer picking the best model; it is picking the right one for each task.

The skill that matters is no longer picking the best model; it is picking the right one for each task.

That is the argument I believe. The rest of this piece is me trying to break it.

In this article. A test of the claim that has reached "good enough," and where it holds and fails.

  • The premise that's only half true: prices did not rise the way the story says.
  • The price per token is not the cost per task: why a flat rate card still means a bigger bill.
  • The subscription stops hiding the meter: flat coding plans give way to metered, -rate billing.
  • What the show: the floor rose; the ceiling rose faster.
  • The are already moving: the open-weight share of real traffic, and the volume-versus-revenue split underneath it.
  • Where good enough already covers the work: the tasks that no longer need the frontier.
  • Where the frontier still earns its rate: architecture, review, long-horizon work, and the burden a weak model hands back to you.
  • Routing is the new skill, and it's a senior one: matching model to task, and the judgement that takes.
  • The moat closes from a different direction: Microsoft's in-house models and the workplace squeeze.
  • The productivity question nobody has answered: the missing 10x engineer.
  • Which side of the line.
An abstract elevation profile of a jagged ridgeline crossed by a single horizontal line; most of the terrain sits below the line, with a few sharp peaks rising above it.
Below the line Most of the work, handled by good-enough models.
Above the line The hard peaks the frontier still owns.
"Good enough" is a line that has risen past most of the terrain; a few sharp peaks still stand above it. Author's illustration.

The premise that's only half true

The story everyone tells right now is that frontier tokens are getting more expensive, the labs are pushing toward metered API pricing, and the free ride is ending. Part of that is true. Part of it falls apart the moment you check the rate cards, and the part that falls apart is worth getting right: a thesis built on a wrong premise deserves to lose.

Start with , since the assumption I hear most often is that each new Opus costs more than the last. It doesn't. Claude Opus 4.8 holds the same $5 per million input and $25 per million output that has been the Opus rate card since Opus 4.5. Opus 4.6, 4.7, and 4.8 are all the same price. The headline number has not moved through three releases . What is new and steeply priced is Claude Fable 5, the first publicly released model in Anthropic's Mythos tier, which launched on 9 June 2026 at $10 per million input and $50 per million output, double the price of Opus 4.8 and, by most accounts, the most expensive generally available frontier model anyone ships . The "everything's getting pricier" story is, for Anthropic, really a story about a new tier opening above the old flagship. The old flagship costs what it always did.

is where the price-rise claim lands. The 23 April 2026 release of -5.5 doubled the per-token price of the GPT-5 line: input went from $2.50 to $5.00 per million, output from $15.00 to $30.00 . That is a real increase on the model most teams reach for, and it cuts the other way from Anthropic's flat Opus pricing.

Model Input ($/M) Output ($/M) Note
DeepSeek V4-Pro 0.435 0.87 open weights, permanent price
DeepSeek V4-Flash 0.14 0.28 open weights
MAI-Code-1-Flash 0.75 4.50 cheaper than Claude Haiku 4.5
Claude Opus 4.8 5.00 25.00 flat since Opus 4.5
GPT-5.5 5.00 30.00 2× the GPT-5.4 rate
Claude Fable 5 10.00 50.00 most expensive major model

Pricing sources [R1–R7]. Standard rates before caching, batch, or regional adjustments; MAI-Code-1-Flash rates are GitHub-listed and described as still being finalised.

The thing that makes the simple "prices are rising" narrative misleading is what is happening underneath the flagships. launched V4-Pro on 24 April 2026, discounted it 75% immediately, and then on 22 May made the cut permanent: $0.435 per million input, $0.87 per million output, one-quarter of the launch price . The reason it matters is structural: DeepSeek attributes the standing price to and data-centre efficiencies rather than a temporary promotion, which is why it removed the original expiry date rather than letting the rate revert . A discount expires; a structural cost reduction does not.

Two price stories at once

The frontier ceiling went up (GPT-5.5 doubled, Fable 5 opened a tier above Opus) while the usable floor collapsed (DeepSeek set a permanent reference price under a dollar per million tokens). "Tokens are getting more expensive" and "capable tokens are getting drastically cheaper" are both true, and they describe different parts of the market.

That makes the cost backdrop for the good-enough thesis stronger than the version that leans only on "the labs are raising prices." The real pressure is competitive: a permanent, frontier-adjacent open-weight price under a dollar hands every enterprise buyer a bargaining chip, and the closed labs know it. The likely response, as one analyst put it, is a gradual shift away from high-margin consumption pricing toward outcome- or value-based models, because per-token premiums are getting harder to justify for many workloads.

The price per token is not the cost per task

The rate card is one half of the cost story, and the smaller half. The other half is that a single task now burns far more tokens than it used to. The models think more before they answer, and the harnesses loop more before they stop. Hold the per-token price perfectly flat and the bill per finished task can still climb. That is exactly what has happened, and it is the part of the cost story the rate-card debate keeps missing.

Three things drive the climb. spend a hidden budget of thinking tokens before they produce a visible answer (a few thousand on an easy question, tens of thousands on a hard one), and those tokens are billed as output even though they never appear in the transcript . A single high-effort call on a long can run past twenty thousand before the model writes a line you keep. Agentic harnesses then multiply that: every turn re-sends the accumulating context (the , the loaded files, the conversation so far, the last tool result), so input grows turn over turn. And the context windows themselves have grown to a million tokens as standard, which is simply more room for the loop to fill.

The independent figures are stark. A study of eight resolving real issues (Bai and colleagues, April 2026) found agentic coding tasks consume on the order of 3,500 times the tokens of a single-shot reasoning query, an average of roughly four million tokens per resolved issue, dominated by re-sent input at about 150 input tokens for every output token . Gartner states the everyday version more conservatively: an agentic assistant spends five to thirty times the tokens of a standard chatbot for the same request . Both describe the same move from one-shot answers to long, tool-using loops.

Tokens per task, agentic vs chat Inference cost per token by 2030 Total token volume by 2030
5–30× ~90% lower ~24×
Gartner, Mar 2026 Gartner forecast Goldman Sachs

Tokens-per-task multiplier [R14]; inference-cost decline [R14]; token-volume growth [R15]; per-task agentic consumption [R13]. The 2030 figures are forecasts, not measured results.

Which is the paradox the whole industry is now staring at: the price of a token is falling fast (Gartner expects on a trillion-parameter model to cost over 90% less by 2030 ) while the number of tokens a task consumes is rising faster. The bill goes up anyway. Goldman Sachs Research projects total token consumption multiplying roughly twenty-four-fold by 2030 . The unit price keeps dropping; the invoice keeps climbing.

Cheaper tokens, bigger bills

Per-token inference keeps falling while tokens-per-task rise faster. The rate card is the number everyone watches; consumption is the number that empties the budget. Optimising the first while ignoring the second is how teams blew through their 2026 coding budgets by April.

The offset is real, and it deserves its due. Newer models are often more token-efficient than the ones they replace, which blunts the sticker shock. GPT-5.5 doubled its per-token price but uses roughly 40% fewer tokens to finish the same coding tasks, so the net cost per task rose about 20% rather than 100% . OpenAI made the point itself: GPT-5.5 is priced higher than GPT-5.4 but is more token-efficient, so the cost of reaching a given result rises less than the sticker suggests . Microsoft claims up to 60% fewer tokens for its -native . And prompt caching takes about 90% off the cost of the repeated context that dominates an agentic loop . Stack those and the climb slows.

It does not reverse. Net it out however you like and it lands in the same place: efficiency takes the edge off, cost per task still trends up for a given capability tier, and the aggregate bill (more developers, more , longer loops) climbs regardless. The rate card got the headlines; the consumption is where the money goes.

This next part cuts against my own thesis. The intuition behind "route the easy work to a cheap model" is that cheap tokens make cheap tasks. They don't always. The same eight-model study found that more tokens frequently buy nothing: accuracy peaked at a middling token spend and then degraded, because the extra tokens were a weaker model thrashing: re-reading the same files, re-trying the same dead ends, exploring instead of reasoning. One open-weight model in the set posted both the highest token cost and the lowest accuracy. Run-to-run variance on the same task reached thirty-fold, and the models could not predict their own cost in advance . A cheap per-token model that wanders can finish a task more expensive than a pricier model that goes straight there, and hand you a worse result for the money. Sometimes the premium model is the cheaper one.

That doesn't sink the good-enough case. On a well-specified, self-contained task the cheap model goes straight there too, and you keep the saving. But it moves the saving from automatic to conditional, and the condition is the quality of the specification and the supervision wrapped around the loop, which is to say the human.

The subscription stops hiding the meter

The clearest place to watch the cost-per-task climb reach ordinary developers is the monthly coding subscription, the thing that made AI assistance feel almost free. A flat fee works only while usage stays bounded, and agentic loops broke that assumption. The providers have started to say so out loud: GitHub now points out that a single handful of requests can cost more than a user's entire monthly plan .

GitHub's response has been the bluntest in the market. On 20 April 2026 it paused new sign-ups for Copilot Pro, Pro+, and Student outright, citing the strain of long-running agentic sessions . It pulled the Opus-class models from the $10 Pro tier and left Pro+ with only Opus 4.7, at a 7.5× request multiplier . Then on 1 June it retired the old premium-request buckets and moved every plan to usage-based "," priced at each model's listed API rate, one credit to the cent . A model that charges $30 per million output tokens now burns three thousand credits for a million tokens of output, drawn against an allowance that, on the $10 plan, is ten dollars of credits . The base prices did not move; what you get for them did. The old safety net of dropping to a cheaper model when your quota ran out is gone , and the annual plans are being wound down, their model multipliers raised on the way out until the subscription expires and the account falls back to Free .

What that adds up to is a quiet change of category. Copilot stopped being a subscription and became a metered utility whose meter reads at API rates. The comfortable arrangement, a fixed fee for a tool that kept getting better every quarter, is the thing that ended, and the bill for agentic coding got handed back to the keyboard. The uncomfortable question underneath it is one a lot of buyers are asking for the first time: was AI-assisted coding ever cheap because it was efficient, or only because the vendor was absorbing the difference?

I would be telling the story crookedly, though, if I made it sound like every provider is pulling back in lockstep. Anthropic and OpenAI sit in the same squeeze. Anthropic added weekly rate limits to Claude in August 2025 , and through the demand crunch of February to April 2026 its peak-hour sessions tightened enough that paying users were hitting walls mid-task . Then it reversed. Across May and June it doubled the five-hour limits, removed peak-hour throttling for Pro and Max, and lifted weekly caps by 50% through 13 July, stated as spare capacity and read by everyone as a move to stop engineers splitting their work over to Codex . OpenAI has been bumping Codex limits and added a $100 Pro tier to raise them further . The first-party coding plans are oscillating: the structural pull is toward metering, the competitive pull is toward staying generous a while longer. Copilot, holding the weakest hand in the model race, was simply the first to stop absorbing the cost.

"almost free" was a subsidy, not a property

The flat-rate coding plan held up while someone other than the user paid for the tokens. As that subsidy is metered back toward API rates (fastest at Copilot, more haltingly at Anthropic and OpenAI), the assumption that AI coding is nearly free is being tested against a real invoice, and that invoice is what forces the value question.

What the benchmarks show

Here the thesis takes its sharpest hit on capability.

The floor has risen astonishingly. By early 2026 the gap between the best open-weight coding models and the best proprietary ones had compressed to single digits on the benchmark most people cite. In June 2026, DeepSeek-V4-Pro-Max led at 80.6% on , with MiniMax M3 at 80.5% and .7 Max at 80.4%, within 0.2 points of each other . A year earlier those numbers would have topped every chart. The capability premium that closed models could once charge for routine coding has compressed to a margin you can measure in single percentage points.

But the ceiling rose faster. By raw capability in June 2026, the top model was Claude Fable 5 at 95.0% Verified; the best open-source model, DeepSeek-V4-Pro-Max, sat at 80.6% . On the harder, less saturated benchmark the spread is starker still: Fable 5 scores 80.3% on against 58.6% for GPT-5.5, while Opus 4.8 lands at 69.2% SWE-bench Pro on Anthropic's own . So at the very top, the distance between the frontier and everything else is not closing. It may be widening.

0102030405060708090100% resolvedClaude Fable 5Claude Opus 4.8DeepSeek V4-Pro-MaxMiniMax M3Qwen3.7 MaxOpen weightsProprietarySWE-bench Verified, June 2026 (% resolved)The open-weight floor sits within single digits of last year's frontier; the new frontier pulled away.

SWE-bench Verified figures [R7, R8]; SWE-bench Pro figures [R9, R10]. Benchmark scores reflect model and harness together (vendor-reported scores use each lab's own scaffold) and should be read as directional, not exact.

Read those two facts together and you have the whole argument in miniature. The frontier edge is real and, on the hardest problems, growing. And it does not matter for most of the work, because most of the work does not live anywhere near the edge. A model at 80% on SWE-bench Verified is wrong on roughly one in five real GitHub issues. But a renamed variable, a new endpoint that follows the three endpoints next to it, or a unit test for a pure function is nowhere near SWE-bench-hard. A competent junior clears it every time, and the open-weight models clear it every time too.

One caveat I will not wave away: benchmark numbers go stale within the month, and the top SWE-bench Pro scores are vendor-reported on each lab's own scaffold, which is exactly where contamination and harness differences inflate a number . The right move is the boring one: real-task evaluation on your own codebase before committing, because benchmark scores are useful only for filtering. I have stopped trusting any single leaderboard and started trusting a week of my own logs.

The tokens are already moving

The rising benchmark floor is one kind of evidence. Where the work actually goes is another, and it has moved faster than the leaderboards. On OpenRouter, the marketplace that routes requests across models, open-weight models passed roughly two-thirds of all tokens served in June 2026, up from about a third in January, and models of Chinese origin alone climbed to close to half the traffic, from under two percent a year earlier . One figure in the same data keeps the story honest: Anthropic draws about 12% of the tokens and roughly 46% of the revenue . Good enough is winning the volume; the frontier is still winning the money. That split is the whole thesis in two numbers.

The clearest single illustration arrived this week. For about two months a stealth model called Owl Alpha sat near the top of OpenRouter's usage charts and nobody outside the lab knew who built it. On 30 June 2026 Meituan, the Chinese services company, unmasked it as LongCat-2.0: a 1.6-trillion-parameter mixture-of-experts model with around 48 billion active, released under a plain MIT licence, trained end to end on domestic accelerators rather than Nvidia hardware, and priced under a dollar per million input tokens . On its own reported figures it edges GPT-5.5 on the hard SWE-bench Pro set, 59.5 against 58.6, while trailing Opus 4.8 and, by a wide margin, Fable 5 . Set that against the spread above and the pattern holds exactly: an open, cheap model has pulled level with a major proprietary flagship on hard engineering work while staying well short of the very top. People routed real work to it for weeks before they could name the company behind it.

None of this is frictionless. Sending production work to a model trained on another country's chips, under a licence and a data policy you did not write, is a governance decision as much as a price one, and the usual vendor caution applies harder to one you cannot subpoena. But the direction is not in question. The buyers have read the same benchmarks I have, and a growing share of them have decided the cheap tier clears the bar for most of what they do .

The names attached to the shift are getting bigger. Yuchen Jin, pointing at the demand is seeing, called "the open-source Claude moment" and predicted more teams will post-train their own models on top of open weights and own them outright . The tooling to make that switch safely is arriving on the same schedule: inference.net's gateway mirrors your live traffic to a candidate like GLM-5.2, builds from your own production data, and tells you when the cheaper model is holding up before you flip the model identifier in your code, a migration it pitches as a 90% cut to the token bill . Both are vendor pitches and read as such. But they point where the traffic already does, one step further: toward teams that own the cheap tier instead of renting it.

Where good enough already covers the work

Earlier this year I built a small Markdown-based personal information manager over a few weeks in January and February, and the pattern that emerged from that work is the one I keep seeing repeated. The novel logic, the part where the design decisions mattered, was a thin slice. The rest was glue: parsing files, wiring a route, formatting output, handling the error case, writing the test that proves the error case. Glue is the bulk of most applications, and glue is what a not-quite-frontier model does well.

For that category (and it is a large category) substituting Codex for Claude barely registers, and substituting either for DeepSeek, Qwen, GLM, or MiniMax often doesn't register at all. The output compiles, the tests pass, the diff reads cleanly. You would struggle to identify which model wrote it in a blind review. When the task is well-specified and self-contained, the intelligence premium buys you nothing you can measure.

The long tail is covered

Documentation tweaks, boilerplate, straightforward refactors, test scaffolding, format conversions, and following an established pattern across new files are all reliably within reach of cheap and open models. This is most of the volume of a working day.

The other thing that quietly moved the floor is the harness. A capable open-weight model behind weak scaffolding is frustrating; the same model behind a mature loop (good tool descriptions, careful context management, recoverable errors) does real work. The scaffolding closed enough of the gap that good enough became reachable far down the cost curve. I have argued the mechanics of that at length and won't repeat them here.

Where the frontier still earns its rate

Two kinds of work still reward the frontier, and a third that is really the first two stretched over time. I would not hand any of them to a cheaper model without watching closely. The cheap model can usually handle this work. When it fails, though, the failure tends to be expensive and quiet, and that changes the maths.

The first is architecture, the up-front decomposition where one good decision spares you a thousand bad downstream ones and one bad decision compounds quietly until it is expensive to undo. The second is review, where you want the model hunting the edge case your cheap builder waved through: the security mistake, the subtle concurrency bug, the thing that passes the tests and fails in production. On both, the frontier models still have an edge I can feel in daily use, and the SWE-bench Pro spread above is the measurable shadow of that feeling. The hardest fifth of problems is where the 95%-model earns its rate over the 80%-model.

The third is long-horizon autonomous work (the multi-hour, multi-file, mostly-unsupervised session) where small errors compound and a weaker model loses the thread. Independent testers put Fable 5's advantage squarely on hard, long-horizon technical work while it approaches parity with cheaper models on routine tasks , and the token research points the same way: on long, hard, coherent tasks the capable model is more accurate and wanders less, and wandering less is fewer tokens. The premium model can be the cheaper one for the right job.

There is a quieter cost to dropping a tier, and it is the one that gets overlooked. A less capable model needs more than a better harness to do good work; it needs a better-informed human beside it. It will carry a vague instruction further in the wrong direction before anyone notices. It will produce code that compiles and passes the shallow tests while missing the constraint nobody wrote down. The systems thinking a frontier model does silently (holding the whole design in view, sensing which edge case is the one that bites) does not vanish when you switch to a cheaper model. It moves to you. For a senior engineer who was going to hold that context anyway, that is a trade and often a good one. For a junior who reaches for the cheap model precisely because they cannot yet supply the missing judgement, it is a trap dressed as a saving. "Good enough" is a property of the model plus the person holding the other end, never the model alone.

The edge is narrow, not absent

"You usually don't need the frontier" is not "the frontier doesn't matter." For architecture, adversarial review, and long unsupervised runs, the gap is real and currently widening. The skill is knowing which of your tasks sit in that set, and admitting the set is smaller than your ego wants it to be, and that shrinking it further leans on your own judgement, not the model's.

Routing is the new skill, and it's a senior one

If good enough covers most tasks and the frontier still owns the hard ones, the developer skill that follows is obvious: route by difficulty. Spend the cheap, fast models on the bulk of the day, and spend the expensive intelligence in the two places it pays for itself: planning up front and review at the end. Keep an escape hatch: when a small model is visibly stuck in a loop, hand the mess to a big one, take the unblock, drop back down.

Routing badly is a cost risk as much as a quality risk, and the token research is the reason. A job sent to a model too weak for it does not fail cleanly and cheaply. It loops (re-reading, re-trying, exploring), and the loop is billed by the token, so the cheap model can return a worse answer and a bigger invoice at the same time. The whole saving depends on routing the hard task up before the weak model has burned a fortune discovering it was out of its depth.

Which is where the seniority comes in, because routing well rests on a question that is harder than it looks: is this task really hard? Answering it before the work starts is the same judgement that tells an experienced engineer where the bodies are buried in a codebase: which change looks small and isn't, which interface is load-bearing, which "quick fix" will surface three regressions. That knowledge is not evenly distributed, and it is exactly what a cheaper model cannot supply on your behalf. The decomposition makes the point sharper still: routing only works if you have broken the work into tasks you can route. Vibe your way into one sprawling, undefined session and there are no discrete tasks to match a model to. There is an amorphous blob that drags the whole thing up to the expensive tier by default. Plan first, break the work down, separate need-to-have from nice-to-have, and the routing falls out of the plan almost for free. The cost discipline and the engineering discipline turn out to be the same discipline, and both are senior habits.

The endpoint of this, as I have written before, is the harness doing the routing for you: sending the documentation tweak to a cheap model and the thorny refactor to a frontier one without you choosing each time. For most teams the best answer is already not one model but a that sends easy work to a cheap or open model and reserves a frontier model for hard edits. The judgement does not disappear; it moves up a level, into how you configure the routing and how well you have specified the work it routes. It is still your judgement. It is just spent earlier.

The moat closes from a different direction

The last force in this story has little to do with how good the models are, and a lot to do with where you work. It is the part of the argument I have grown most sure of over the past month.

Right now, a developer at a large company can often pick their model freely: Claude here, Codex there, whatever the task seems to want. I don't think that freedom survives. The reason is that the platform owners have started shipping their own models, priced and placed to keep you inside the house.

Microsoft made this explicit at Build 2026. It introduced MAI-Code-1-Flash, a coding model built from the ground up on enterprise-grade data without from third-party models, rolling out inside . The detail that matters is how it was trained: not on general code but on Copilot's production workflows: the actual file-editing tools, terminal integrations, and multi-step task loops developers use every day . The model learned to be good at the harness it lives in. And the pricing is a weapon: in GitHub Copilot's token-based billing, MAI-Code-1-Flash is priced cheaper than Claude Haiku 4.5, and it is already rolling out to around 10% of individual users, including anyone who picks "Auto" in the model picker . Most developers will get routed to it without choosing it.

Paired with MAI-Code-1-Flash is MAI-Thinking-1, Microsoft's first in-house reasoning model, a 35-billion-active-parameter mixture-of-experts model with a 256K , aimed squarely at reasoning and software-engineering tasks . The strategic intent is not subtle. Reporting on the launch read it as Microsoft making its dependence on OpenAI optional . A first-party model good enough for the median task lets Microsoft keep cutting Copilot's price and lean on bundling. The more traffic the in-house model carries, the narrower OpenAI's position inside Microsoft's own product becomes.

Set that beside the argument I made about workplace AI more broadly, that the incumbents win on distribution, context, and governance rather than model quality, and the developer case is just a specific instance of it. When the in-house model is good enough, the marginal benefit of letting every developer reach for an external frontier model has to be weighed against the security, governance, identity, and single-billing advantages of staying inside the digital workplace. For a regulated enterprise, that is not a close call for most of the work.

Good enough plus already-here

A first-party coding model that handles the median task, billed inside the platform you already trust for identity and compliance, does not have to beat Claude or Codex. It has to be close enough that the governance and cost advantages of staying put outweigh the capability gap. For most enterprise code, it already is.

The productivity question nobody has answered

The evidence that most resists the optimistic reading, including mine, is on productivity.

We have spent two years hearing about the 10x engineer, the 100x team, the developer who ships a quarter's worth of work in a week. I have not seen a rigorous, replicated study that shows it. What I have seen is the opposite, from the most careful experiment anyone has run. METR's randomised controlled trial of experienced open-source developers found that when allowed to use early-2025 AI tools, they took 19% longer to complete tasks. AI made them slower. The detail that should stop anyone selling certainty is the perception gap: the same developers forecast a 24% speedup beforehand and, after finishing, still estimated AI had sped them up by 20%, while the measured result was a slowdown . That gap is the part of this whole period I find hardest to shake. We have rebuilt our tooling, our budgets, and a chunk of our hiring around a speed-up that the people feeling it could not reliably tell apart from its opposite.

I am not going to over-claim from one study any more than I would from one vendor anecdote. It was 16 developers, on mature codebases they knew intimately, with early-2025 tooling that has since improved, and the result may not generalise to greenfield work or to weaker codebases or to the better harnesses of 2026. METR itself frames it as a snapshot. But it is a randomised controlled trial, which is more than the 10x claims have ever offered, and it lands on the exact case where I would least expect AI to help: a senior engineer who already holds the whole system in their head, where the overhead of prompting, reading, and correcting can plausibly exceed the time saved.

The evidence on who benefits is not one-sided, though, and I would be cherry-picking if I stopped at METR. Telemetry from Jellyfish across thousands of developers found close to the opposite slope: senior developers writing code about 22% faster with an assistant against roughly 4% for juniors . That sounds like a contradiction and isn't, because both point at the same variable from opposite ends: the people who gain most are the ones who already know what good looks like and can steer, correct, and reject, while the people the careful trial caught slowing down are also senior, slowed precisely because the tool kept offering plausible work they then had to check against a standard only they held. The 2025 report names the pattern directly, calling AI an amplifier of existing conditions that magnifies a strong team's strengths and a struggling one's dysfunctions . What gets amplified is the engineer and the system around them, never the model on its own.

That is also why the corporate mood has turned. The token bills came due, the productivity line stayed stubbornly theoretical, and companies started pulling back: capping budgets, clawing back licences, asking the question they should have asked first . Individual developers are running the same audit now that their own plans are metered: once the meter is visible, the question stops being whether the assistant is impressive and becomes whether it is worth the line item. I have written about the spend side of that reckoning separately. Here the point is narrower and more uncomfortable: if we cannot yet prove the productivity gain even when developers use the best models, then the cost of insisting on the best models for every task is real and the benefit is unproven. That is an argument for good enough, and not a flattering one: the premium simply has not earned its price across the board.

Which side of the line

So: are we approaching good enough? For most of what programming involves day to day, yes, we are there, and the open-weight floor rising to within single digits of last year's frontier is the clearest evidence of it. For architecture, adversarial review, and long autonomous runs, no, the frontier still owns those, and at the very top the gap is widening, not closing. The premise that frontier prices are uniformly rising is half wrong: Anthropic held the Opus rate card flat across three releases, OpenAI doubled its flagship, and the open-weight floor fell through the floor. The flat rate card hides a rising cost per task, because the models think more and the loops run longer. The flat subscription that hid that cost from individual developers is being metered back to API rates, fastest at Copilot. And the productivity dividend that would justify always reaching for the best model remains, after two years and at least one rigorous study, unproven.

The practical reading is short. Match the model to the task, which means breaking the work into tasks you can match. Reserve the frontier for the hard fifth and stop paying its rate for the easy four-fifths. Watch the cost per finished task rather than the price per token alone, because a cheap model that loops can cost more than a dear one that doesn't. Assume your platform's in-house model will quietly become your default whether you choose it or not, and decide on purpose whether that's fine. For most code, it will be. And remember that dropping a tier moves work onto the human beside the agent: a cheap model with a senior steering it is a different thing from the same model running unsupervised, and only one of them is good enough.

Good enough is not a destination the whole field arrives at on one date. It is a line that has already swept past most of the work and is still well short of the hardest parts. The skill is knowing which side of the line your current task sits on, and admitting that the line is further along than it was last quarter, that the part still beyond it is smaller and sharper than the marketing on either side admits, and that where you sit on it depends as much on who is holding the other end as on which model you picked.

Are We Approaching Good Enough? · June 2026 · An analysis piece. Methodology notes: benchmark figures reflect model and harness together and are directional, with the hardest scores vendor-reported on each lab's own scaffold; the 2030 figures are forecasts, not measured results; pricing is standard API rates before caching, batch, or regional adjustments; vendor performance and efficiency claims are flagged as such in the text. Full sources below.

References38
  1. 1llm-stats, "Claude Opus 4.8 launch: benchmarks and pricing", 2026. llm-stats.com ↗
  2. 2Anthropic, "Introducing Claude Fable 5 and Claude Mythos 5", Claude API documentation, June 2026. platform.claude.com ↗
  3. 3TechCrunch, "Anthropic's Claude Fable 5 is a version of Mythos the public can access today", June 9, 2026. techcrunch.com ↗
  4. 4Apidog, "GPT-5.5 Pricing: Full Breakdown of API, Codex, and Plans", April 23, 2026. apidog.com ↗
  5. 5The Register, "GPT-5.5 may burn fewer tokens, but it always burns more cash", May 8, 2026. theregister.com ↗
  6. 6Apidog, "DeepSeek V4-Pro 75% Price Cut Is Now Permanent", May 2026. apidog.com ↗
  7. 7Morph, "DeepSeek V4: architecture, benchmarks, pricing", June 2026 (cites the llm-stats SWE-bench tracker). morphllm.com ↗
  8. 8llm-stats, "SWE-Bench Verified Leaderboard", updated June 2026. llm-stats.com ↗
  9. 9Finout, "Claude Fable 5 and Mythos 5: Pricing, API Costs, and Benchmark Comparison", June 2026. finout.io ↗
  10. 10Morph, "SWE-bench Pro Leaderboard (2026)", June 9, 2026 (Scale SEAL standardized vs vendor-reported scores; scaffolding and contamination notes). morphllm.com ↗
  11. 11Shadow, "Is Claude Fable 5 Worth It? Pricing, Cost, and Breakeven Analysis (2026)", June 2026. shadow.inc ↗
  12. 12OpenAI, "Reasoning models", OpenAI API documentation. developers.openai.com ↗ Accessed 2026-06-12
  13. 13Bai et al., "Quantifying token cost in agentic software engineering" (study of eight frontier models on SWE-bench Verified), arXiv:2604.22750, April 2026. arxiv.org ↗
  14. 14Gartner press release, via HPCwire/AIwire, "Gartner Forecasts 90% Drop in LLM Inference Costs by 2030" (also the 5–30× tokens-per-task figure for agentic assistants), March 25, 2026. hpcwire.com ↗
  15. 15Goldman Sachs Research, "AI Agents Forecast to Boost Tech Cash Flow as Usage Soars" (24× token-consumption growth to 120 quadrillion tokens/month by 2030; inference cost down 60–70%/yr), May 2026. goldmansachs.com ↗
  16. 16CometAPI, "GPT-5.5 Pricing: How Much Does It Cost in 2026?" (~40% fewer output tokens for agentic tasks; ~20% effective cost increase), May 2026. cometapi.com ↗
  17. 17Microsoft AI, "Introducing MAI-Code-1-Flash", updated June 8, 2026. microsoft.ai ↗
  18. 18Microsoft AI, "Microsoft Build 2026: MAI keynote transcript" (MAI-Code-1-Flash priced below Claude Haiku 4.5, ~10% rollout and Auto-picker routing; MAI-Thinking-1 as a 35B-active-parameter MoE with 256K context), June 2026. microsoft.ai ↗
  19. 19CloudZero, "Claude Mythos pricing in 2026: Fable 5 costs, Mythos 5 costs" (prompt caching cuts input spend ~90%), June 2026. cloudzero.com ↗
  20. 20GitHub Blog, "Changes to GitHub Copilot Individual plans" (sign-ups paused April 20, 2026; tightened usage limits; a handful of requests can exceed the plan price), updated May 14, 2026. github.blog ↗
  21. 21SmartScope, "The Real Problem Behind GitHub Copilot's Individual Plan Tightening" (Opus removed from Pro; Pro+ retains only Opus 4.7 at 7.5×; premium-request model), April 2026. smartscope.blog ↗
  22. 22GitHub Blog, "GitHub Copilot is moving to usage-based billing" (June 1, 2026 transition to AI Credits priced at listed API rates; base prices unchanged; annual plans and multiplier changes). github.blog ↗
  23. 23GitHub community discussion #192948, "GitHub Copilot is moving to usage-based billing" (AI Credits = tokens at listed API rates per model; retiring annual plans). github.com ↗
  24. 24Digital Applied, "GitHub Copilot AI Credits Are Live: A Cost Playbook" (1 AI Credit = $0.01; a $30/M-output model burns 3,000 credits per million output tokens; cheaper-model fallback removed), June 2026. digitalapplied.com ↗
  25. 25PCMag, via Yahoo, "Anthropic: We're Glad You Like Claude Code, But Stop Reselling Access" (weekly rate limits effective August 28, 2025). tech.yahoo.com ↗
  26. 26J.D. Hodges, "Claude AI Usage Limits: What Changed in 2026" (tighter peak-hour sessions, February–April 2026). jdhodges.com ↗
  27. 27Apidog, "Claude Code Weekly Limits Just Jumped 50% Through July 13" (doubled 5-hour limits, removed peak-hour throttling, +50% weekly through July 13, 2026; framed as a defensive move against Codex), May 2026. apidog.com ↗
  28. 28CNBC, "OpenAI looks to take on Anthropic with $100 per month ChatGPT Pro subscriptions" (ChatGPT Pro tier raising Codex limits; resetting Codex usage limits as user counts grow), April 9, 2026. cnbc.com ↗
  29. 29Decode the Future, "Microsoft MAI-Code-1-Flash: Copilot's New Coding Model" (Build 2026 launch; framed as reducing reliance on OpenAI; cites CNBC, June 2, 2026). decodethefuture.org ↗
  30. 30byteiota, "AI Coding Productivity Myth: 19% Slower, Feeling 20% Faster" (reporting the METR randomised controlled trial, arXiv:2507.09089). byteiota.com ↗ · arxiv.org ↗
  31. 31Jellyfish, "We Analyzed 146,000 Jira Tickets for Copilot Users" (senior engineers reduced coding time 22% vs 4% for juniors), February 2025. jellyfish.co ↗
  32. 32Jellyfish, "AI as Amplifier: the 2025 DORA Report" (AI amplifies an organisation's existing strengths and weaknesses), November 2025. jellyfish.co ↗
  33. 33Yahoo Finance, "The token bill comes due: Inside the industry scramble to manage AI's runaway costs" (enterprises capping budgets and clawing back licences), June 2026. finance.yahoo.com ↗
  34. 34OpenRouter, "State of AI" public model-usage data, accessed June 2026 (open-weight models reached roughly two-thirds of tokens served in June 2026, up from about a third in January; models of Chinese origin rose to close to half of all traffic, from under 2% a year earlier; Anthropic accounted for about 12% of tokens but roughly 46% of revenue). openrouter.ai ↗ Accessed 2026-06-30
  35. 35Meituan LongCat, "Introducing LongCat-2.0", 30 June 2026 (1.6-trillion-parameter mixture-of-experts, ~48B active, 1M context, MIT licence, trained on domestic accelerators; previously served anonymously as "Owl Alpha" atop OpenRouter; self-reported SWE-bench Pro 59.5 against GPT-5.5's 58.6). longcat.chat ↗ · huggingface.co ↗ · venturebeat.com ↗ Accessed 2026-06-30
  36. 36Rest of World, "When Americans choose Chinese AI", 2026 (US developers and firms adopting low-cost Chinese open-weight models). restofworld.org ↗ Accessed 2026-06-30
  37. 37Yuchen Jin (@Yuchenj_UW), post on X, 29 June 2026 ("GLM-5.2 is the open-source Claude moment… more companies will shift toward post-training their own models on top of oss models and owning the weights"; cites the demand Databricks is seeing). x.com ↗ Accessed 2026-06-30
  38. 38Sam Hogan (@samhogan), post on X, 29 June 2026 (Inference Gateway: mirror live traffic to GLM-5.2, auto-generate evals from production data, switch when healthy; vendor claim of ~90% lower token bill, stack owned end to end), with inference.net Catalyst documentation. x.com ↗ · docs.inference.net ↗ Accessed 2026-06-30