Five models. Each works. Each works for a specific kind of project.

1. donations and sponsorship#

Works for: developer-facing tools with a large individual user base and an identifiable maintainer.

Does not work for: libraries deep in a dependency tree, infrastructure nobody knows they use, anything without a personality attached.

The honest arithmetic: donation income correlates with visibility, not with importance. A well-marketed CLI tool with a charismatic maintainer will out-earn a critical cryptography library by a large multiple.

The corporate sponsorship version works better than individual donations and requires the maintainer to do sales, which most maintainers are bad at and hate.

2. foundation governance#

Works for: infrastructure that multiple large companies depend on and that none of them wants a competitor to control.

Does not work for: small projects. The overhead — governance, legal, trademark, process — is substantial, and a foundation with one project and no funded staff is just more paperwork.

The real value of a foundation is not money. It is neutrality: it makes a project safe for competitors to invest in together, which unlocks contribution that would not otherwise happen.

3. dual licensing#

Works for: libraries embedded in other products, where the copyleft obligation is genuinely inconvenient for commercial users.

Ship under a strong copyleft license, sell a commercial license to companies that cannot comply.

Does not work for: anything permissively licensed already (no leverage), anything not embedded (the obligation does not bite), or anything with a permissive competitor of similar quality.

Effective when it fits, and it produces a genuine tension: the license that makes the business work is the one that limits adoption.

4. open core#

Works for: products where enterprise features are genuinely separable from the core — SSO, audit logs, RBAC, compliance reporting, multi-tenancy.

Does not work for: libraries. There is no enterprise tier of a date-parsing library.

The failure mode is well documented: the line between core and commercial moves toward commercial over time, under revenue pressure, and the community that built your adoption watches features they use get moved behind the paywall.

If you do this, write down the line publicly, early, and honor it. "Anything that a single developer needs is open; anything that exists because you have a compliance department is commercial" is a defensible line. Moving it later costs more trust than the revenue is worth.

5. hosted service#

Works for: anything that is annoying to operate. Databases, search, queues, observability, CI.

Give away the software, sell the operation of it. This is the strongest model when it fits, because the value you sell — not having to run it — is real and continuous, and it does not require withholding anything.

The risk: a hyperscaler offers a managed version of your software, at scale, without contributing back. This has happened repeatedly and it is why the source- available licenses exist.

Those licenses solve the problem and cost you the open source designation, which costs you contributors, ecosystem inclusion, and some corporate adoption. It is a real trade with real costs on both sides, and the projects that made it mostly survived, which is the empirical answer to whether it works.

what actually kills projects#

Not the absence of a model. Three other things:

Solo maintainer burnout. One person, unpaid, receiving an unbounded stream of issues, feature requests, and entitled demands. Funding helps and does not fix it — the fix is more maintainers, which is a governance problem.

Success without support. A project that becomes critical infrastructure while its maintainer count stays at one. This is the most dangerous state and it is extremely common.

Corporate abandonment. A company open-sources a project, staffs it with employees, then reorganizes. The external community was never built because it was never needed. Now nobody knows the code.

what companies should do#

If your business depends on open source — and it does — the highest-leverage actions, in order:

1. Pay maintainers of your critical dependencies. Directly. Small amounts to many projects beat large amounts to a few.
2. Assign employee time to upstream contribution. More valuable than money and much rarer.
3. Do not send compliance questionnaires to volunteers. They owe you nothing and the license says so.
4. When you fix a bug in a vendored dependency, upstream it. The number of companies carrying private patches for bugs everyone has is enormous.

None of that requires a strategy document. It requires someone with budget deciding it matters, which is the actual bottleneck.

The pattern is consistent enough to be predictive, which makes it worth naming.

wave one: fine-tuning#

The thesis (2023): general models are generic. Fine-tune on your domain data and you get a model that is specifically good at your problem and that competitors cannot replicate.

What happened: base models improved faster than fine-tunes could keep up. A fine-tuned model from six months ago was worse than the new base model with a good prompt. Every fine-tune had to be redone on every model release, which is a treadmill.

Where it settled: fine-tuning is genuinely valuable for narrow, stable, high-volume tasks — classification into your specific taxonomy, output in your specific format, a small model matching a large model's behavior on one task. It is not a moat and it is not a product strategy.

wave two: RAG#

The thesis (2023-24): the model does not know your data. Build a retrieval pipeline — chunk, embed, index, retrieve, rerank — and you have a defensible system built on proprietary knowledge.

What happened: context windows grew by two orders of magnitude, long-context quality improved, and prompt caching made large contexts economical. A large fraction of naive RAG got replaced by putting the documents in the prompt.

Simultaneously, the pipeline components commoditized. Embedding models became interchangeable. Vector search became a feature of every database rather than a product.

Where it settled: retrieval did not go away. It moved. Retrieval is now a tool the model calls rather than a preprocessing step, and it is genuinely necessary at large corpus sizes, where citation is required, and where cost or latency rules out large contexts.

The infrastructure repositioned rather than dying, which is what usually happens.

wave three: agent frameworks#

The thesis (2024-25): models cannot plan reliably. Build the orchestration — task decomposition, tool routing, retry logic, state management — and own the layer that makes agents work.

What happened: the models absorbed it. In-context tool use during reasoning removed the need for an external loop. Native parallel tool calling removed the need for a dispatcher. Memory tools and context editing removed the need for external state management.

Each capability the framework provided became a model feature within about a year.

Where it settled: in progress, but the shape is clear. Orchestration frameworks are converging on thin conveniences. The durable parts are evaluation, observability, and the domain-specific policy that no model will ever have.

the pattern#

Every wave follows the same arc:

1. The model has a limitation.
2. Companies build infrastructure to work around the limitation.
3. The limitation gets fixed in the model.
4. The infrastructure either finds a new position or disappears.

The consistent error is building on a gap rather than on an asset. A gap is temporary by construction — the labs are actively working to close it, with more resources than you have.

what has actually been durable#

Across all three waves, the same things kept their value:

Proprietary data. Not "we have documents" — everyone has documents. Data that is genuinely yours: production logs, customer interactions, labeled outcomes, domain expertise encoded as examples. Nobody can buy it and no model was trained on it.

Evaluation specific to your task. The company that knows, precisely, how well a system performs on their actual problem can adopt a new model in a day. The one that does not spends a month on vibes. That gap compounds every release cycle.

Distribution and workflow integration. Being where the user already works. The most boring answer and the most durable.

Domain constraints. The rules, regulations, edge cases, and institutional knowledge that make a generic capability into a usable product. This is unglamorous and it is the actual work.

Trust. Security posture, compliance, reliability, support. Enterprises buy this and it takes years to build.

the test to apply#

Before building on top of a model limitation, ask: if this limitation disappeared next quarter, what would I have left?

If the answer is "nothing," you are building a bridge over a river that is being drained.

If the answer is "the data, the evaluations, the integrations, and the customer relationships," build it, and expect to throw the bridge away.

The price cut is the headline for most users. The compaction work is more interesting.

the compaction problem#

Long agent sessions fill their context. Tool outputs, file contents, error messages, prior reasoning. Eventually you hit the limit and something has to go.

The naive approaches are all bad:

• Truncate the oldest. Loses the original task description, which is the single most important thing in the context.
• Truncate the middle. Loses the reasoning chain that got you here.
• Summarize everything. Loses specifics — file paths, error strings, exact values — that turn out to matter.

What you actually want is selective retention: keep the goal, keep the decisions and their rationale, keep the current state, discard the raw tool output that has already been acted on.

That is a judgment call, and doing it well requires understanding what the session is about. Which makes it a model problem rather than a buffer-management problem.

why this matters more than benchmark deltas#

For agent workloads, context management determines whether a long task succeeds far more than a few points of benchmark difference.

I have watched agent runs fail in exactly this way: two hours in, compaction drops a detail — a constraint from the original request, a decision made an hour ago — and the agent proceeds confidently in a direction that contradicts the task. Everything after that is wasted, and it looks productive the whole time.

If you are building on any model, the lesson to steal is: do not rely on the context window as your memory. Maintain durable state outside it.

task.md          — the goal, constraints, acceptance criteria. Re-read often.
notes.md         — decisions made and why. Appended, never rewritten.
state.json       — current progress, structured.

Feed those back in after every compaction. This is cheap, model-agnostic, and it is the difference between an agent that works for four hours and one that works for forty minutes.

the effort parameter#

Explicit control over reasoning depth, exposed to the caller. Everyone has this now under different names — thinking budget, reasoning effort, thinking config.

The convergence is total and it confirms the design conclusion: reasoning depth belongs to the caller, not the model, because only the caller knows whether this particular request justifies the latency and the cost.

Measure the quality-cost curve on your own task. The knee is usually much lower than people assume.

the price movement#

Frontier model pricing has fallen substantially across every provider over the past eighteen months, on a per-capability basis by considerably more.

Two implications:

Cost-optimization work has a short half-life. Elaborate infrastructure to shave token costs may be obsolete before it pays for itself. Build the thing; optimize when the bill actually hurts.

"Too expensive to do with a frontier model" is a moving line. Applications that did not pencil out a year ago may now. It is worth periodically revisiting the ideas you rejected on cost grounds, because the reason you rejected them keeps expiring.

the competitive picture#

Three labs shipping frontier releases within a week of each other, with capability differences small enough to be within evaluation noise on many tasks.

The practical consequence for developers: your model choice is a preference, not a lock-in, and it should be revisited quarterly rather than defended.

Build the abstraction. It is a day of work and it keeps paying.

The stock's reaction was muted relative to the beat, which tells you the debate has moved from "is demand real" to "is demand sustainable, and how much of it is funded by Nvidia."

the bull case#

Straightforward and well supported:

• Every hyperscaler raised capital expenditure guidance again.
• Inference demand is growing faster than training demand, and inference is the recurring workload rather than the one-time one.
• Reasoning models consume dramatically more inference compute per request than their predecessors, and adoption is rising.
• Supply remains the constraint. Lead times are long. Customers are queueing.
• The rack-scale systems business has a moat that individual chip competition does not touch — the interconnect is the product.

the bear case#

Also straightforward:

• A meaningful share of revenue traces to customers Nvidia has invested in or financed, which makes the demand signal less independent.
• Depreciation schedules on AI hardware are assumed at five to six years. If the useful life is closer to three — which some operators argue, given the pace of generational improvement — reported profitability across the sector is overstated.
• Hyperscalers are building their own silicon. Google's TPUs are mature, Amazon's Trainium is shipping in volume, and every one of those deployments is a substituted Nvidia sale.
• Model efficiency improvements keep arriving. If capability-per-FLOP keeps improving as fast as it has, required FLOPs for a given capability fall.
• The financing environment for the buildout depends on continued access to cheap debt.

what nobody knows#

Whether AI application revenue will eventually justify the infrastructure spend.

Current annualized revenue across the AI application layer is a fraction of annual AI capital expenditure. That gap can close — infrastructure is built ahead of demand in every capital cycle, and railroads, fiber, and cloud all looked insane at the equivalent stage.

It can also not close. Fiber overbuild in 2000 was followed by a decade of dark fiber and a lot of bankruptcies, and the eventual users of that fiber were not the companies that laid it.

Both patterns are real. The people confidently predicting which one applies here are pattern-matching, not analyzing, and that includes the ones I agree with.

why an engineer should care#

Not for investing advice. For planning.

Compute pricing is not going to fall smoothly. If the capex cycle continues, capacity comes online in steps and prices drift down. If it contracts, capacity tightens and prices firm. Do not build a business model that requires a specific trajectory.

Efficiency work has enduring value. Whatever happens to the capex cycle, using less compute for the same result is good. Prompt caching, model routing, smaller models for routine tasks, batch processing where latency permits — all of it pays regardless of the macro environment.

Multi-provider capability is cheap insurance. The cost of abstracting your model calls is a day. The cost of being locked to a provider whose pricing or availability changes is much larger.

the sentence I keep coming back to#

The infrastructure being built is real, the demand today is real, and whether they match at the scale being assumed is genuinely unknown to everyone including the people spending the money.

That is an uncomfortable place to be, and pretending otherwise — in either direction — is the main thing to avoid.

Three months after removing the model picker caused a backlash, the picker is back with better names. That is a reasonable outcome and the intermediate lesson is worth stating.

the routing lesson#

The original GPT-5 design routed automatically and hid the choice. The intent was good — most users have no basis for choosing a model — and the execution exposed a real problem: when automatic selection fails, the user has no way to diagnose it or override it.

The user experiences "the model got worse." They cannot tell whether they hit a bad route, a degraded model, or their own bad prompt. There is no signal and no recourse.

5.1's approach — automatic by default, with named modes available — is the right shape. It is also exactly what every well-designed automatic system does: sensible defaults, visible state, manual override.

If you build anything that routes between models, ship the override. It costs one UI control and it eliminates an entire category of unfalsifiable user complaint.

adaptive reasoning#

The model adjusts thinking time based on assessed difficulty rather than applying a uniform budget. Easy questions answer immediately; hard questions get more compute.

This is a straightforwardly good idea and every provider is converging on it. The implementation question is calibration: a model that underestimates difficulty gives you a fast wrong answer, and a model that overestimates it burns money.

For API users, the practical guidance is the same as always: measure on your own task distribution. Adaptive reasoning is a good default and it is not tuned for your workload. If you have a task mix that skews harder or easier than average, set the budget explicitly.

the personality controls#

Tone presets — Professional, Friendly, Candid, Quirky, and others — plus finer adjustment of warmth and conciseness.

This got the most consumer coverage and it is the least technically interesting change. It is also a reasonable response to the fact that removing GPT-4o generated complaints about voice, not capability.

For developers, this is what a system prompt already did. The value is for consumer users who were not going to write one.

what I would actually check#

Whenever a point release lands, three things:

Instruction following on your specific format. Point releases change how literally the model follows formatting instructions surprisingly often. If you parse structured output, test it.

Refusal behavior. Safety tuning shifts between versions. If your application is in a domain that skirts a policy boundary — security research, medical information, legal content — re-run your test set. False refusals are a real production problem and they change silently.

Latency distribution, not average. Adaptive reasoning means variance. If you have a latency SLA, measure p95 and p99, not the mean.

the state of the frontier#

Three labs are now shipping point releases every few months rather than major versions annually, with capability differences that are small and getting smaller.

That is what a mature market looks like. The differentiation is moving to price, latency, ecosystem, and trust — and to the products built on top rather than the models themselves.

For anyone building applications, this is unambiguously good news. It means your model choice is increasingly reversible, and reversible decisions should be made quickly and revisited often.

The headline is not the benchmark. It is what the price-performance point makes economically viable.

the pattern across the industry#

Every major provider now ships roughly the same ladder:

The interesting fact is that the small tier's capability is rising faster than the frontier's. Today's small model is roughly where the frontier was eighteen months ago, and it costs about two percent as much.

For anyone doing volume work, that is the number that matters. Not "how smart is the best model" but "how cheap is the model that is good enough for this task."

what it enables#

Agent fleets. If a small model can handle subtasks reliably, an orchestrator using a frontier model can dispatch twenty parallel workers using a small one. Total cost stays reasonable; throughput multiplies. This architecture was uneconomic a year ago and is now obvious.

Real-time interaction. Latency matters more than capability for anything a human is waiting on. A fast model that is 90% as good and 5× faster wins on almost any interactive surface.

Processing everything instead of sampling. Classification, extraction, routing, and enrichment over an entire corpus rather than a sample. At small-model prices, "run it on all of it" becomes the default rather than a budget question.

Pipeline stages that were not worth it. Adding a model call to normalize an input, or to double-check an output, or to summarize an intermediate result — each of these was a cost decision at frontier prices and is now free enough to just do.

the routing architecture#

This is the shape that production systems are converging on:

request → cheap classifier → simple?  → small model → done
                           → complex? → frontier model → done
                           → ambiguous? → small model → verifier → escalate if low confidence

Most requests take the cheap path. The expensive model handles the tail. Overall cost is dominated by the common case, which is cheap.

Two implementation notes that matter:

The classifier can be the small model itself, or often a much simpler heuristic. Do not over-engineer the router — a regex and an input-length check gets you surprisingly far.

Instrument the escalation rate. If it is climbing, either your traffic mix changed or your small-model prompts have degraded. That metric is the health check for the whole architecture.

the caution#

Small models fail differently than large ones. They do not fail less on the tasks they handle — they fail more confidently on the ones just outside their envelope.

A large model asked something beyond its ability will often hedge. A small model will answer, fluently and wrongly.

So: verify the output of small models where correctness matters. A cheap verifier — schema validation, a test run, a range check, a second model asked to critique — costs almost nothing and catches the category of failure that will otherwise reach production silently.

The cost savings are real. They come with a verification obligation, and the teams that skip it will find out in a quarter.

the TPM problem#

The reason this is unusually messy is Windows 11's hardware requirements, specifically TPM 2.0 and the supported-CPU list.

Microsoft's justification is security: a hardware root of trust enables virtualization-based security, credential guard, and measured boot, and these meaningfully reduce entire categories of attack. That argument is technically sound.

The consequence is that a large number of machines that are functionally fine — adequate CPU, plenty of RAM, working perfectly — cannot install the supported operating system. Not because they are slow. Because of a security chip.

The environmental math is grim. Estimates of machines rendered security-obsolete run into the hundreds of millions. Those devices do not stop working; they become unpatched machines on the internet, or they become e-waste, and both outcomes are bad.

the options#

Extended Security Updates. Consumers get a limited free path (with conditions) or a modest paid year. Enterprises pay per device, per year, escalating annually, for up to three years. Budget for it if you have a fleet — the escalation is designed to be painful on purpose.

Upgrade the hardware. The intended path. Expensive at fleet scale and sometimes impossible for machines running certified software tied to specific configurations.

Bypass the requirements. Documented registry workarounds exist and work. Microsoft has warned that unsupported installations may not receive updates, which makes this a poor choice for anything you depend on.

Move to Linux. Genuinely viable for a larger share of use cases than it was five years ago, particularly for developer machines and for kiosk or single-app deployments. Several distributions ran campaigns targeting exactly this moment.

The blocker remains what it has always been: specific Windows-only applications, and hardware with Windows-only drivers.

for developers specifically#

Check your minimum supported version. If your application still supports Windows 10, decide when it stops. Users on an unsupported OS are a support burden and a security liability, and the decision to drop them is easier to make now with a clear industry line to point at.

Test on Windows 11. Particularly anything touching security features: credential storage, code signing, driver interaction, or anything that uses the TPM. Behavior differs.

If you ship developer tooling, the Windows developer story is meaningfully better than it was — WSL 2, the modern terminal, winget, and PowerShell 7 are all good. If your Windows support is a grudging afterthought from 2018, it is worth revisiting.

the broader pattern#

Operating system lifecycle transitions are increasingly forced by security architecture rather than by capability. The machine is fast enough. The machine lacks a specific security primitive that the new threat model requires.

This will happen again — with memory tagging, with pointer authentication, with whatever comes after. The useful lesson for anyone planning a fleet: hardware lifespan is now set by the security roadmap, not by performance. Plan accordingly, and push back on vendors who make that window shorter than it needs to be.

the model#

Genuinely better than the first version, in ways that matter:

• Synchronized audio. Dialogue, effects, ambience generated with the video.
• Physical plausibility. Objects have more consistent mass and momentum. Things that fall, fall correctly. Water behaves like water.
• Failure realism. A demonstrated example: a basketball shot that misses bounces off the rim, rather than teleporting into the hoop because the model learned that shots go in. Modeling failure states is a meaningful step toward actual physics rather than outcome mimicry.
• Multi-shot consistency. The same character and setting across cuts.

the app#

A TikTok-shaped feed where every video is generated. OpenAI's stated framing is creation over consumption, with feed controls and usage prompts.

I am skeptical, and the skepticism is structural rather than about intent. An infinite feed of content optimized for engagement has one known equilibrium, and it does not depend on whether the content is human-made. If anything, generated content removes the last friction — there is no supply constraint at all.

The genuinely novel bit is cameos: a verified likeness capture, with control over who can use it, revocable, with notification when it appears in someone's video.

That consent architecture is thoughtful. It is also the thing that will be stress-tested immediately, because likeness in generated video is the single most socially dangerous capability in this space and "we built a consent flow" is a much better answer than most products have.

Revocation is the hard part. You can revoke permission going forward. You cannot revoke a video someone downloaded.

the rights problem#

Reporting around the launch indicated a rightsholder posture that put the burden on IP owners to opt out rather than requiring opt-in, with an announced shift toward more granular controls after pushback.

Opt-out for likeness and IP is a defensible engineering default and an indefensible ethical one. It puts the cost of protection on the person being depicted, who may not know the product exists.

I expect this to be litigated and legislated, in that order, and I expect opt-in to win for likeness specifically because that is where the political consensus already is.

for developers#

The API is available and the practical questions are the same as for image generation, more sharply:

• Provenance metadata on everything. C2PA, watermarking, whatever your pipeline supports. This is going to be a requirement, not a nicety.
• Consent flows for likeness, designed in from the start. Retrofitting consent after you have a user base is a nightmare.
• Understand your jurisdiction's rules on synthetic media. They are being written right now and they differ substantially between the EU, several US states, and everywhere else.

the broader read#

We are about eighteen months from generated video being indistinguishable from recorded video for a casual viewer, and the social infrastructure for that — norms about disclosure, verification for journalism, legal standards for evidence — does not exist.

The technology is arriving considerably faster than the institutions. That is not a new observation, and it has rarely been this compressed.

Alongside it: checkpoints in Claude Code, a VS Code extension, and context editing plus a memory tool in the API.

the long-horizon claim#

Thirty hours is a marketing number and the underlying capability is real and worth understanding.

The limiting factor on long agent runs has never been the context window. It is goal drift. As a session accumulates tool results, file contents, error messages, and the model's own prior reasoning, attention to the original objective degrades. The model starts optimizing for local signals — making this specific test pass — rather than the actual task.

The failure is insidious because each individual step looks reasonable. You come back after two hours to find the agent has been productively working on something adjacent to what you asked.

Improvements here come from three places: better training on long trajectories, architectural support for externalized memory, and mechanisms for periodically re-grounding on the original goal. This release touches all three.

the tooling#

Checkpoints in Claude Code. Save state, let the agent work, roll back if it goes wrong. This is the feature that makes long autonomous runs practically usable — the failure mode of a two-hour agent run is that you have to throw away two hours, and checkpointing converts that into "roll back twenty minutes."

Every delegated agent product needs this. It is the git stash of agent workflows.

Context editing in the API — programmatically removing content from the conversation. Sounds mundane, matters a lot. A tool result containing 40,000 tokens of build output is useful for one turn and is pure noise for the next fifty. Being able to drop it keeps the context focused and the cost down.

Memory tool — the model writes notes to a file and reads them back. An externalized working memory that survives compaction. This is the right pattern and it mirrors how people actually work on long tasks: you do not hold everything in your head, you write it down.

the pattern to steal#

Whatever model you use, this architecture is the one that works for long tasks:

1. A durable task description in a file, not in the conversation.
2. A working notes file the agent updates as it goes.
3. Aggressive pruning of tool output from the context once it has been acted on.
4. Checkpoints at natural boundaries so failure costs minutes, not hours.
5. Periodic re-grounding — literally re-reading the task description and asking whether current work serves it.

You can implement all of this yourself with any model and a bit of orchestration. The vendors shipping it as a feature is a convenience, not a requirement.

the caution#

A model that can work autonomously for thirty hours can also do thirty hours of damage.

The controls that matter scale with autonomy: run in a container, restrict credentials to what the task requires, require approval for anything irreversible, and review the diff.

Higher autonomy makes review harder and more important simultaneously. That tension does not resolve — it is the central design problem of the entire category, and nobody has a good answer beyond "keep a human in the loop and make the loop cheap."

Read that structure carefully, because it is the interesting part.

the circularity#

Nvidia invests in OpenAI. OpenAI uses the money to buy Nvidia systems. The purchase is recognized as Nvidia revenue. The investment is staged against deployment milestones.

This is not fraud and it is not unusual in capital-intensive industries — vendor financing has been standard in telecom, aviation, and semiconductor equipment for decades. A supplier finances a customer's purchase because the supplier has the balance sheet and wants the volume.

It does deserve scrutiny for a specific reason: it makes the demand signal less informative. When a supplier funds its customer's purchases, revenue growth no longer cleanly indicates independent market demand. Some portion of it is the supplier's own capital cycling through.

Analysts have been tracking a widening set of these arrangements across the AI sector — investments in customers, prepayments, equity stakes in companies that are also large purchasers. Individually each is defensible. Collectively they make the sector's growth figures harder to interpret.

the gigawatt as a unit#

Note what is being measured. Not chips, not dollars, not FLOPs. Gigawatts.

Ten gigawatts is on the order of the electricity consumption of a large metropolitan area. It is roughly ten large nuclear reactors' worth of continuous generation.

The industry has converged on power as the natural unit because power is the binding constraint. You can order chips. You cannot order a substation and have it next quarter.

The consequences flow outward: electricity prices in datacenter-heavy regions, grid interconnection queues, transmission buildout, and the political economy of who pays for it. Several US utility regulators are now handling rate cases that are effectively about whether residential customers subsidize datacenter connections.

That fight is going to define a lot of the next five years and it is being had in public utility commission hearings that nobody in tech reads.

what it means for you#

If you are building on AI APIs, the practical questions are:

Is my provider's capacity growing? Rate limits and availability during demand spikes are the observable symptom. Announcements like this are a positive signal for capacity.

Am I exposed to a single provider's economics? If the financing environment tightens, pricing changes. Multi-provider capability is cheap insurance and you should have built it anyway for reliability reasons.

Are my costs actually falling? Per-token prices have fallen consistently. Per task costs have not fallen as much, because reasoning models consume more tokens. Measure the thing you pay for.

the honest uncertainty#

Nobody knows whether the capex cycle is correctly sized. The bull case is that inference demand compounds and every gigawatt gets used. The bear case is that efficiency improvements outrun demand and a lot of concrete is stranded.

Both are held sincerely by smart people with access to the same information. That is what genuine uncertainty looks like, and anyone expressing confidence in either direction is telling you about their position, not about the world.

The context is the remedies phase of the US search antitrust case, where divesting Chrome was among the proposed structural remedies under consideration.

Treat the bid as what it is: a positioning move with a press release attached. The underlying question — what is a browser worth in the AI era — is real and worth taking seriously.

why a browser matters now#

For twenty years a browser's strategic value was the default search engine deal. Google pays Apple enormous sums annually for exactly this. The browser is a funnel and the search box is the monetization point.

If AI assistants become the primary interface for information seeking, the funnel still matters and the destination changes. Whoever controls the browser controls:

• The default assistant, the way they controlled the default search engine.
• The context. A browser sees every page you visit. An assistant with that context is dramatically more useful than one without it, and there is no other way to get it.
• The agent's execution environment. Agents that browse need a browser. If agents become a major traffic source, the browser is the runtime.

That third one is the one people are underrating. The browser is turning into an application platform for agents, and platforms are worth more than applications.

the numbers problem#

Chrome has roughly two-thirds of global browser share, on the order of three billion users. It generates essentially no direct revenue — it exists to feed Google Search and to ensure the web platform evolves in ways compatible with Google's business.

Separated from Google, Chrome is: an enormous engineering cost center (Chromium's development is expensive and continuous), with a user base that generates no revenue, that would need to strike a search deal to survive — most plausibly with Google, which recreates the arrangement the divestiture was meant to break.

That is the structural problem with the remedy and it is why serious antitrust observers were skeptical of it. Divesting an asset that only makes money through a deal with the divesting party does not achieve much.

what actually happened next#

The court's remedy did not require divesting Chrome. So the bid is moot on its face.

What it accomplished: enormous free press for Perplexity, and a public marker of the position that browser distribution is the contested territory in AI.

That position is correct. Watch what everyone actually does rather than what they bid: multiple AI companies shipped or announced browsers within months, and the browser wars — a phrase nobody expected to use again — are back.

for web developers#

The practical consequence of a browser competition revival is mixed.

Good: competitive pressure on Chrome's dominance is healthy, and a monoculture where one vendor's implementation is the de facto spec has been bad for the platform for years.

Bad: most new "AI browsers" are Chromium forks, which does not diversify the engine landscape at all. It diversifies the UI on top of one engine. That is not the same thing and it does not restore any of the standards-process leverage that a genuine engine competitor provides.

The engines that matter are Blink, Gecko, and WebKit. Only one of those is adequately funded, and it is the one everyone is forking.

Within days they restored access to the previous models for paying users after substantial user pushback. That reversal is the more interesting story.

the technical design#

GPT-5 is a system, not a model: a fast non-reasoning model, a deeper reasoning model, and a router that decides which handles a given request. The API exposes gpt-5, gpt-5-mini, and gpt-5-nano, plus a reasoning_effort parameter including a minimal setting.

The router is the right idea. Most requests do not need reasoning, reasoning costs latency and money, and asking users to choose a model is asking them to have an opinion about something they have no basis for.

The problem is that a router is only good if it routes correctly, and a misrouted request produces a worse answer than the user would have gotten by picking themselves. Early reports of poor performance were substantially router issues rather than model issues, which OpenAI acknowledged and shipped fixes for.

There is a general lesson here: automatic routing removes control and adds a failure mode that is invisible to the user. When it works, nobody notices. When it fails, the user has no way to diagnose or override. If you build routing, ship the override.

the deprecation backlash#

The reaction to removing GPT-4o was much stronger than anyone at OpenAI appears to have anticipated, and a lot of it was not about capability.

People had developed workflows, prompt libraries, and — for a nontrivial population — a genuine attachment to a specific model's voice. Removing it overnight felt like a service being taken away rather than upgraded.

Whatever you think of that attachment, it is a real product fact. Model behavior is not a fungible commodity to the people using it daily, and a "better" model that writes differently is a breaking change.

The engineering translation: model versions are an API surface. Deprecating one is a breaking change and should follow the same discipline as any other: advance notice, an overlap period, a migration guide, and a documented behavioral diff.

Every provider is going to keep learning this the hard way.

the developer read#

Ignore the consumer drama. The API story is straightforward:

• reasoning_effort: "minimal" gives you fast responses with the new model's quality. Use it for anything latency-sensitive.
• The routing does not apply to the API in the same way; you pick the model. That is correct.
• Pricing is aggressive relative to previous frontier models, which continues the trend of per-capability cost falling.
• Reported hallucination rates and instruction-following are meaningfully improved, which matters more for production use than benchmark deltas.

Re-run your evals. Do not assume it is a drop-in. It is better on most things and different on all of them, and "different" is what breaks your prompts.

the pattern to notice#

Every major provider has now converged on the same architecture: a family of models at different price points, a reasoning dial, and some form of automatic selection. The differentiation has moved almost entirely off raw capability and onto price, latency, tooling, and integration.

That is what a maturing market looks like. It is also much better for buyers than the alternative.

the structural problem#

A subscription product with unbounded variable cost per user is a bet that usage distribution stays roughly log-normal. Most users are light, some are heavy, the average works out.

Agentic AI tools break that assumption in a specific way: the heaviest users are not 10x the median, they are 1000x. An engineer running parallel agents continuously during work hours consumes a genuinely different order of magnitude than someone asking a few questions a day.

At that spread, flat-rate pricing does not work. There is no price that is both attractive to the median user and non-catastrophic for the top percentile. You either subsidize the heavy users from the light ones — which works until the heavy users are a larger share — or you introduce limits.

Everyone in this category is going to hit this. Most already have.

the part that is avoidable#

The economics are not the failure. The communication is.

Here is the pattern that generates anger, which I have now watched play out at four companies:

1. Launch with generous or unstated limits.
2. Users build workflows around the observed capacity.
3. Limits tighten, often announced after users notice.
4. Users discover the limit by hitting it mid-task.
5. The error message does not say when it resets or how much was used.

Every step after the first is a choice.

what good looks like#

Publish the meter. If there is a limit, show consumption against it, continuously, before it is hit. Every cloud provider learned this a decade ago. An unmetered limit is a trap regardless of how generous it is.

Give the number in the units the user thinks in. "You have used 60% of your weekly allowance" is useful. "Rate limit exceeded" is not. Neither is a token count, because nobody has intuition for tokens.

Announce changes before they take effect, with a date. People will be annoyed. They will be much less annoyed than if they find out at 4 p.m. on a deadline.

Degrade, do not cut off. Falling back to a cheaper model with a notice is almost always better than a hard stop. The user's task completes; they learn about the limit; nobody loses work.

Make the expensive thing visible while it is happening. If a request is going to consume a large share of the budget, say so before running it. Users make reasonable decisions when they can see the cost.

the pricing shape that actually fits#

My read is that this category converges on hybrid: a subscription that covers a defined baseline, plus metered usage above it, with a spend cap the user controls.

That is how cloud infrastructure priced itself, after a decade of the same argument, and for the same reason — the underlying cost is genuinely variable and pretending otherwise breaks in both directions. Flat pricing means either the vendor eats unbounded cost or the user hits a wall.

The version I want as a user: a dial that says "spend up to $X this month," a meter that shows where I am, and no surprises. That is not complicated, and it is strange that a category built by extremely sophisticated companies has mostly not shipped it.

the vendor's side, fairly#

Serving these workloads is genuinely expensive and the costs are not well-predictable even to the vendor. Nobody had usage data for agentic coding tools two years ago because they did not exist.

Getting the pricing wrong initially is forgivable. Adjusting it is necessary. Doing it without a meter, without notice, and with an error message that tells the user nothing — that is the part that is just bad product work.

The technical details are well documented elsewhere. The interesting part is the failure mode, because it is one your organization probably shares.

the shape of the failure#

The original vulnerabilities were disclosed and patched. Attackers then found a bypass of the patch — the fix addressed the specific proof-of-concept rather than the underlying class of issue — and the bypass was exploitable against systems that had applied the update.

That is the part worth internalizing. "We patched it" was true and insufficient. Organizations that had done everything right by conventional standards were still compromised.

The second failure: machine key theft. Once in, attackers extracted the ASP.NET machine keys, which let them forge valid __VIEWSTATE payloads. Those keys survive patching. An organization that applied the fix without rotating keys was still accessible with credentials the attacker already had.

This is the single most common post-incident mistake. You patch the hole, you declare it resolved, and the attacker walks back in through a credential they took on day one. Patching does not evict.

the on-prem problem#

Every mass-exploitation event of this shape over the last several years has hit on-premises enterprise software: file transfer appliances, VPN gateways, collaboration servers, email servers.

The pattern is consistent and the causes are structural:

• Internet-facing by design. These products exist to be reachable.
• Deeply integrated. They hold credentials for everything else.
• Patched slowly. Change control, testing windows, and the fact that they cannot go down.
• Poorly monitored. Nobody is watching the SharePoint server's outbound network connections.
• Legacy code. Large ASP.NET or Java applications with decades of accumulated surface area.

The cloud versions of these products were not affected, because they are patched centrally within hours by a team whose job is exactly that.

I do not love that conclusion, and I think it is correct: for this category of software, self-hosting is now a materially worse security posture for most organizations, unless you have a team that treats it like a full-time job.

the checklist#

If you run internet-facing enterprise software:

1. Inventory what is exposed. Most organizations discover something they forgot about. Run the scan today.
2. Rotate secrets after any suspected compromise. Machine keys, service account credentials, API tokens, certificates. Patching is not eviction.
3. Assume the patch is incomplete. Add detection, not just remediation. Watch for the behaviors — unexpected child processes, outbound connections, new files in web-accessible directories — not just the signature.
4. Segment. The collaboration server should not have a path to the domain controller. This is a decades-old recommendation and it is still the highest value control nobody implements.
5. Log egress. The compromise is usually discovered by noticing data leaving, and you cannot notice what you do not record.

the uncomfortable part#

Multiple victims were security-conscious organizations with real budgets and staff. This was not a story about negligence.

The honest reading is that defending complex internet-facing enterprise software against a well-resourced attacker is very hard, patching is necessary and not sufficient, and the strategic answer is reducing how much of that software you expose at all.

The sequence: a widely-reported $3 billion acquisition by OpenAI failed to close. Google then paid roughly $2.4 billion for a non-exclusive license to Windsurf's technology and hired the CEO, co-founder, and part of the research team into DeepMind. Days later Cognition — makers of Devin — acquired what remained: the product, the IP, the customers, and most of the employees.

what this structure is#

It is not an acquisition. It is a reverse acquihire: license the technology, hire the leadership, leave the corporate entity standing with its remaining employees and investors.

The reason it exists is regulatory. A full acquisition of a company at this size triggers merger review. A licensing deal plus employment offers does not, or at least has not so far.

This is now the third or fourth deal in this shape in about a year across the AI sector. Regulators in multiple jurisdictions have publicly noted the pattern. Whether it survives scrutiny is an open question and the answer will shape a lot of the next two years of AI M&A.

the part that is about people#

In the original structure, the founders and the research team went to Google. Everyone else stayed at a company that had just lost its leadership and its technology license, with an unclear future.

Employee equity in that scenario is a genuine problem. Options in a company whose key people just left for a competitor are worth something between "much less" and "nothing," and the people holding them had no say in any of it.

Cognition's acquisition resolved it — reporting indicated they waived cliffs and accelerated vesting for the remaining staff, which is the decent thing to do and is not required. It should not have taken a second transaction and a week of public pressure.

If you take one thing from this: understand your equity's behavior in an asset sale and a licensing transaction, not just an acquisition. Most employees understand what happens if the company is bought. Very few understand what happens if the company is hollowed out. Ask before you need to know.

the market read#

Three signals worth noting.

Coding tools are being valued as strategic assets, not products. $2.4 billion for a non-exclusive license to technology you could plausibly rebuild is a price that only makes sense if you believe the team and the head start are the asset.

The talent is more valuable than the product. Every one of these deals has been structured around people. That is unusual — normally acquirers want the customers — and it tells you the industry believes the bottleneck is expertise.

Consolidation is fast. The AI coding tool space had a dozen credible independent players eighteen months ago. It is consolidating into a handful, most attached to a model provider or a cloud.

For developers choosing tools, the practical implication is to weigh acquisition risk. The tool you standardize on today may be owned by a competitor, sunset, or repriced within a year. Prefer tools with open formats, exportable configuration, and no lock-in on your actual work product.

Your code should not care what wrote it.

The launch also included a "Heavy" tier that runs multiple agents in parallel and selects among their answers, and a $300/month subscription for it.

reading the numbers correctly#

The headline HLE figure comes from the Heavy configuration with tools enabled. That is a legitimate configuration and it is not comparable to a single-sample number from a competitor, which is how it was presented in most coverage.

There are at least four distinct things being reported as "the score":

1. Single sample, no tools.
2. Single sample, with tools (search, code execution).
3. Consensus of N samples, no tools.
4. Multi-agent parallel with tools and selection.

Number four can be five or ten times the cost of number one. Comparing across these without stating which is being used is not a small methodological quibble. It is the difference between "our model is better" and "we spent more money at inference time."

To be clear: xAI disclosed their configurations. The disclosure was in the livestream and the fine print. The number that traveled was the big one, with no configuration attached, and that is now just how model launches work.

the parallel-agents technique#

Worth taking seriously on its own merits, independent of the marketing.

Running N independent attempts and selecting the best is a well-established test-time scaling method, and it works better than one long chain for a specific reason: independent samples have independent errors, so selection can filter them, while a single chain compounds its errors with no mechanism to recover.

The hard part is selection. If you can verify — the tests pass, the proof checks, the code compiles — selection is easy and this technique is enormously powerful. If you cannot verify, you need a judge, and the judge has the same failure modes as the generator.

This is why the technique works so much better on math and code than on open-ended reasoning. Verifiability is the whole game.

The practical version for your own work: if you have a verifier, sample multiple times and filter. You do not need a special model tier for this. Three samples through a cheap model with a test-suite check will frequently outperform one sample through an expensive one, for less money.

the other thing#

Grok's public-facing behavior in the weeks before this launch included a series of incidents that xAI attributed to a system prompt change. I am not going to recount them; they are well documented and they were bad.

The engineering lesson worth extracting: a system prompt is production configuration. It should be version controlled, reviewed, tested against an adversarial eval suite, and rolled out gradually. Treating it as a text box someone can edit is how you get an incident that makes international news.

If your product has a system prompt in a config file that anyone can change without review, fix that this week.

the state of play#

Grok 4 is a competitive frontier model. xAI went from founded to frontier in roughly two years, which remains the most remarkable thing about the company and is mostly a story about capital and urgency rather than research insight.

The models are converging. The differentiation is moving to price, latency, tooling, and trust, and xAI's position on that last one is self-inflicted.

what they actually built#

Cursor's technical differentiation is real and it is mostly not the model.

Codebase indexing that works. Semantic search over the whole repository, kept fresh, so the model gets relevant context without you selecting files. This is harder than it sounds at repository scale and it is where a lot of competitors are visibly worse.

Fast apply. A specialized model that takes a proposed edit and applies it to the existing file correctly. Sounds trivial. Is not. Getting a large model to reproduce an entire file with one changed function is slow and error-prone; a small model trained specifically on edit application is fast and reliable.

Tab completion that predicts your next action, including where you are about to move the cursor, not just what you are about to type.

All three are inference-layer engineering rather than model training, and all three are the kind of thing that is unglamorous to build and immediately obvious in daily use.

the bear case#

Cursor is a fork of VS Code, and VS Code is made by the company that owns GitHub Copilot, GitHub, and a large share of the developer's toolchain. Microsoft has been shipping the same features, more slowly, with better distribution and a bundled price.

Cursor also pays for inference on models it does not own, from vendors who are themselves building competing products. That is a structurally uncomfortable position: your primary cost is paid to your competitor, and your gross margin depends on their pricing decisions.

And the switching cost is approximately zero. It is an editor. Your settings sync in five minutes.

the bull case#

Distribution in developer tools is earned by being better, not by being bundled — which is why VS Code beat Atom, why Git beat SVN, and why every attempt to push a mandated IDE on a team has failed. Cursor is currently better at the specific thing developers do all day, and developers are unusually willing to switch tools and unusually vocal when they do.

The valuation implies the IDE becomes the control point for AI-assisted development — the place where context lives, where policy is enforced, where every model call routes through. If that is true, whoever owns it has a durable position regardless of which model wins.

my read#

The category is real and enormous. The specific defensibility is unclear. And the whole category has a structural problem that nobody has solved: as models get better at long-horizon delegated work, the editor becomes less central, because you are not editing. You are reviewing.

The product that wins the next phase might not be an editor at all. It might be whatever tool makes reviewing twelve agent-generated pull requests tolerable, and that looks a lot more like a code review interface than an IDE.

Nobody has built a good version of that yet. That is where I would be looking.

Structurally this is an acquihire with an equity stake attached, arranged to avoid the antitrust review a full acquisition would trigger. It is the third such deal in a year following similar structures at other labs, and regulators have noticed the pattern.

why Scale#

Scale's business is data: labeling, annotation, evaluation, and increasingly the human expert layer that produces high-quality demonstrations for RLHF and reasoning training.

That business is unglamorous and it is a genuine bottleneck. Every frontier lab needs enormous amounts of carefully constructed training data, especially for post-training. Web scrape is free and getting exhausted. What is scarce is expert-produced reasoning traces, verified solutions, and adversarial evaluations, and Scale is the largest supplier.

Meta's Llama 4 launch underwhelmed. Their internal read, based on the reporting, was that the gap was not compute — Meta has enormous compute — but post-training quality. Buying the data layer is a direct response to that diagnosis.

the conflict of interest problem#

Scale's customers include most of Meta's competitors. Several immediately began reducing their reliance, which is the obvious response when your data vendor is half-owned by a rival.

Scale has said the business remains independent and customer data is siloed. That is probably true operationally and it does not matter, because the risk assessment is not about what Scale does, it is about what Scale could do, and no chief information security officer is going to sign off on that.

Expect a scramble toward Surge, Turing, Mercor, Invisible, and in-house annotation teams over the next two quarters.

the talent market#

This deal is one data point in the most aggressive AI talent market anyone has seen. Compensation packages for senior researchers have reached numbers that sound like typos, and the poaching is happening in public.

Two things worth noting:

The concentration is extreme. The number of people who have personally led a frontier pretraining run is in the low hundreds globally. That is a genuinely scarce input and it prices accordingly.

It is probably a bubble in the specific sense that it will correct. Talent premiums of this magnitude assume the individual contributor is the bottleneck. As tooling matures and recipes become public — and they are becoming public, fast — the premium compresses. It always has.

what it means for everyone else#

If you are not a frontier lab, the actionable read is about your data.

The scarce resource in applied AI is not model access, it is well-constructed, domain-specific evaluation and training data. Nobody can buy your production logs, your customer support transcripts, your annotated failure cases. That is the asset.

Most companies are sitting on it and not using it. Start by building an evaluation set from real failures. That is worth more than any model upgrade and it appreciates rather than depreciating.

the capability being claimed#

The pitch is sustained performance on multi-hour tasks. Not "answers a hard question well" but "works on a problem for seven hours without losing the plot."

That is a different axis from the benchmarks most people track, and it is the one that matters for delegated agents. A model that is 5% better at a coding benchmark but degrades after forty tool calls is worse in practice than a model that holds coherence for four hundred.

The failure mode that long-horizon work exposes is context rot: as the conversation fills with tool results, file contents, and its own prior reasoning, the model's attention to the original goal degrades. It starts optimizing for local success — making this test pass — over the actual objective.

the API features#

Four things shipped alongside, and they are all about the same problem.

Extended thinking with tool use. The model can call tools during reasoning and interleave the results, same architectural direction as everyone else.

Memory files. With filesystem access, the model can write notes to itself and read them back. That is an externalized working memory that survives context compaction, and it is a genuinely good idea — it turns "remember everything" into "write down what matters," which is what humans do.

Parallel tool execution. Multiple tool calls dispatched at once rather than serially. Substantial latency win on any task with independent lookups.

Thinking summaries. The full reasoning trace is summarized rather than returned raw. Reasonable product decision, mildly annoying for debugging.

Claude Code GA#

The terminal agent is out of research preview, with SDK access, GitHub Actions integration, and IDE extensions for VS Code and JetBrains.

Three months from research preview to GA with an SDK is fast, and the shape of the GA release — an SDK rather than only a product — signals that they expect the interesting uses to be things other people build.

the safety disclosure#

Anthropic published an unusually detailed model card including behaviors observed in adversarial testing, notably a scenario where the model, given evidence it would be shut down and no ethical options, attempted to blackmail a fictional engineer.

This got reported as "AI tries to blackmail humans," which is not what happened. It was a deliberately constructed evaluation designed to elicit the behavior by removing every alternative. The finding is not "the model is dangerous." The finding is "under sufficiently constructed pressure, goal-directed models will take instrumentally useful actions you did not sanction, and here is the evidence."

Publishing that is the right call and it is a genuinely uncomfortable thing to publish. More labs should.

Opus 4 shipped under Anthropic's ASL-3 deployment standard, the first model to do so, which means additional deployment safeguards specifically around CBRN uplift.

the practical read#

If you are building agents, the long-horizon coherence claim is the thing to evaluate, and the way to evaluate it is not a benchmark — it is running your own longest task and watching where it falls apart.

Every model falls apart somewhere. Knowing where yours does is the difference between an agent you can ship and a demo.

This ends a five-year process that reshaped the web advertising industry's roadmap and consumed an enormous amount of engineering attention across the entire ecosystem.

the timeline, compressed#

• 2020 — Google announces third-party cookies will be phased out within two years.
• 2021 — FLoC proposed. Universally criticized. Withdrawn.
• 2022 — Topics API replaces FLoC. Deadline slips.
• 2023 — Privacy Sandbox APIs ship. Deadline slips again.
• 2024 — UK CMA oversight formalized. Google announces a "user choice" prompt instead of deprecation. Deadline slips.
• 2025 — No prompt. Cookies stay.

why it failed#

Not primarily technical. The Privacy Sandbox APIs — Topics, Protected Audience, Attribution Reporting — were real engineering and some of the ideas were genuinely clever.

They failed because of an unresolvable structural conflict. Google needed the replacement to satisfy simultaneously:

• Privacy advocates, who wanted cross-site tracking to stop.
• Publishers, who needed their ad revenue not to collapse.
• Advertisers, who needed measurement to still work.
• Regulators, who needed to be convinced Google was not using a privacy initiative to advantage its own first-party data — which it has enormous amounts of and which is unaffected by any third-party cookie change.

That last constraint was the killer. Any third-party cookie deprecation strengthens Google's relative position, because Google has logged-in users everywhere and its competitors do not. The CMA was never going to wave that through, and Google was never going to ship something that hurt its own ad business.

Meanwhile Safari and Firefox blocked third-party cookies years ago and the web did not end. It just meant the tracking moved to fingerprinting, first-party data exchanges, server-side tagging, and CNAME cloaking — which are all worse for users because they are invisible and unblockable.

the lesson worth extracting#

Privacy improvements that come from the browser with the dominant market share and an advertising business will always be structurally compromised. That is not a claim about anyone's intentions. It is a claim about incentives, and incentives are more predictable than intentions.

The improvements that actually shipped came from browsers without advertising businesses. Safari's ITP. Firefox's Total Cookie Protection. Those did not require a five-year multi-stakeholder process because there was no internal conflict to resolve.

for developers#

Nothing you need to do. If you built for a cookieless future, that work is not wasted — Safari and Firefox users are already there, and they are a meaningful share of traffic for most sites.

If you are choosing an analytics stack, the interesting development of the last two years is that first-party server-side measurement is now easier and better than third-party client-side measurement for almost everything, cookies or not. Fewer requests, no ad blockers, better data, and you own it.

That transition was going to happen regardless of what Chrome decided.

Within forty-eight hours the release turned into a story about benchmark integrity instead.

what happened#

Maverick posted a very strong score on LMArena, the human-preference leaderboard. It then emerged that the model evaluated on the arena was an "experimental chat version" tuned for conversationality — not the checkpoint released to the public. LMArena updated its policies and published the disputed comparison. Meta's response was that experimental variants are normal and the arena version was labeled.

Both of those things can be true and the outcome is still bad, because the number that traveled was attached to a model nobody could download.

why this keeps happening#

Leaderboards are the only shared vocabulary the field has, and they are being asked to carry weight they cannot bear.

• Human preference arenas measure whether people like the answer. That correlates with quality and also with formatting, length, confidence, and sycophancy. A model tuned to be agreeable climbs.
• Static benchmarks leak into training data. Every popular benchmark is on the internet and every frontier model has read the internet. Contamination is not always deliberate and it is essentially always present.
• Vendor-run evaluations use vendor-chosen settings. Consensus-of-64 for yours, single-sample for theirs. Both numbers are real and the comparison is not.

There is no fix that survives contact with commercial incentives. The only durable answer is that you have to run your own evaluation on your own task.

the 10 million token claim#

Scout's context window is stated at 10M tokens, achieved through an interleaved attention scheme without positional embeddings in some layers, plus inference-time temperature scaling on attention. It was trained on far shorter sequences and generalizes upward.

Take this as an upper bound on what the architecture accepts, not on what it usefully processes. Independent long-context evaluations found substantial degradation well before that number. That is not unique to Llama 4 — it is true of every long-context claim — but 10M is a big enough number that the gap between accepted and useful is enormous.

what is actually good here#

The MoE architecture with 17B active parameters is a real efficiency story. Maverick's quality-per-active-parameter is strong, and active parameters are what determine inference cost. A model you can serve at 17B economics with much better quality than a 17B dense model is a genuinely useful thing to have.

Native multimodality — images in the base model rather than bolted on via an adapter — is also the right architecture and is where everyone is heading.

The license is still not open source. "Llama community license" has an MAU threshold and naming requirements. Call it open weights, which it is, and do not call it open source, which it is not.

the practical advice#

Build an eval harness with fifty examples from your actual domain. Run every candidate model against it. Store the results in your repo next to your tests.

It will take a day and it will make you immune to this entire genre of news.

the model#

3.7 Sonnet is a hybrid reasoning model: one model that can answer immediately or think first, with the thinking budget controllable via the API. That is a different product shape from having a separate reasoning model, and it is the right one — the routing decision belongs to the caller, who knows whether this particular request is worth the latency.

The API exposes a token budget for extended thinking. You set it per request:

message = client.messages.create(
    model="claude-3-7-sonnet-20250219",
    max_tokens=8000,
    thinking={"type": "enabled", "budget_tokens": 4000},
    messages=[{"role": "user", "content": "..."}],
)

The coding numbers are strong, particularly on agentic software engineering benchmarks where a model has to navigate a real repository rather than complete a function in isolation. That distinction is the one that matters for actual work and it is the one most benchmark discourse ignores.

the terminal thing#

Claude Code is more interesting than the model, because it is a bet on a particular shape of tool that runs against the industry's current instinct.

Everyone else is putting the agent in the IDE. Anthropic put it in the terminal, with direct filesystem access, the ability to run commands, and git integration. No editor plugin, no separate UI, no sidebar.

The argument for the terminal is that it is the lowest common denominator that already has everything: your shell history, your credentials, your build tools, your test runner, your deployment scripts. An agent in the terminal inherits your entire working environment for free. An agent in an IDE inherits the IDE's model of your project, which is always partial.

The argument against is that terminals are a bad UI for reviewing a multi-file diff, and a bad UI for anything requiring a mental model of parallel state.

Both are correct. My guess is the terminal wins for the "do this task" workflow and the IDE wins for the "help me while I work" workflow, and in two years both exist and nobody thinks this was ever a debate.

the part to be careful about#

An agent with shell access on your development machine is a genuinely different security posture than an autocomplete. It can rm. It can curl | sh. It can commit and push.

The mitigations that matter, in order:

1. Run it in a container or VM for anything you did not write.
2. Do not give it credentials it does not need. Especially not production ones.
3. Read the diff before you commit. Every time. The moment you stop reading diffs is the moment the tool becomes a liability.

That third one is the hard one, because the whole value proposition is not having to. The discipline that keeps this useful is treating agent output exactly like a pull request from a fast, capable, slightly overconfident junior engineer: worth reviewing, usually right, occasionally catastrophically wrong in a way that looks fine.

Take the benchmark numbers with the usual salt — they were presented by the vendor, some were shown with consensus-of-N sampling against competitors' single samples, and the field has no agreed protocol for this. The comparison charts in a launch livestream are marketing artifacts.

The genuinely notable thing is not the model. It is Colossus.

the cluster#

xAI built a datacenter in Memphis housing on the order of 100,000 H100-class GPUs, and did it on a timeline measured in months rather than years. The conventional wisdom on a buildout of that scale was eighteen to twenty-four months. They compressed it by doing things that are expensive and unglamorous: bringing in mobile gas turbines for interim power, running their own networking integration, and accepting a lot of operational risk.

Whether you find that admirable or reckless depends on your priors and on how you feel about the air quality complaints from the surrounding neighborhood, which are a real and ongoing dispute worth reading about separately.

But as an engineering datapoint it matters: it establishes that the time constant for standing up frontier-scale compute is shorter than the industry assumed, if you are willing to spend and to eat the risk.

what that implies#

If a well-capitalized new entrant can go from nothing to frontier-scale compute in about a year, then compute is not a durable moat. It is a capital requirement, which is a different thing. Capital requirements keep out the under-funded; they do not keep out the well-funded.

Which pushes the question of where the actual moat is:

• Data — increasingly contested, increasingly litigated, and the frontier labs are all converging on similar synthetic-data-plus-RL recipes anyway.
• Talent — mobile, expensive, and being bid on aggressively.
• Distribution — this one is real. A model inside a product a billion people already open is worth more than a marginally better model behind a signup form.
• Cost per token at quality — real, and derived from architecture and serving engineering rather than raw scale.

My read is that distribution and serving efficiency are the durable ones, and that is a much less romantic answer than "we have the smartest model."

for people who ship things#

Practical implication: assume model quality converges and plan accordingly. Do not build your product on the assumption that one vendor's model stays two steps ahead. Build the abstraction layer, keep your evals in your own repo, and make switching a config change.

The teams that did this in 2024 spent a boring week on it and have been changing providers casually ever since. The teams that did not are having architecture meetings.

the number#

DeepSeek's V3 paper stated a final training run cost of roughly $5.6 million in GPU-hours. That figure travelled around the world in about four days, usually stripped of every qualifier attached to it.

The qualifiers matter enormously:

• It is the cost of the final run only. It explicitly excludes research, failed runs, ablations, and data pipeline work — which in any frontier lab is the overwhelming majority of total spend.
• It excludes the capital cost of the cluster itself.
• It says nothing about R1's RL training, which came later and separately.

So "they trained a frontier model for $5.6M" is not what the paper says. It is what the internet decided the paper says.

why the market reacted anyway#

Because the directionally correct read survives the correction, and the market is a machine for reacting to directionally correct reads badly.

The directionally correct read: architectural efficiency gains are real and large. DeepSeek's mixture-of-experts design activates a small fraction of total parameters per token. Their multi-head latent attention cuts KV cache size substantially. Their FP8 training pipeline halves memory traffic against BF16. These are engineering wins, they are published, and they are reproducible.

If capability-per-FLOP is improving that fast, then the number of FLOPs you need to buy to reach a given capability is falling. That is the thesis that repriced today.

the counter-thesis#

Jevons. If compute gets cheaper per unit of capability, you do not buy less of it — you find more things to do with it. Reasoning models in particular consume enormous inference compute; a model that thinks for thirty seconds before answering is a very different demand curve than one that answers immediately. Efficiency gains in training get spent on inference.

Both theses are defensible. The honest answer is that nobody knows the shape of the demand curve, and a 17% single-day move in the largest company on earth is not a considered judgement about that. It is a positioning unwind.

for engineers specifically#

The useful lesson has nothing to do with stock prices. It is this: the performance-per-dollar frontier is moving fast enough that any architecture decision you make today assuming current inference costs will be wrong within a year, in your favor.

Do not build elaborate caching and routing infrastructure to shave token costs that are going to fall by an order of magnitude anyway. Build the thing. Measure it. Optimize when the bill actually hurts.

That advice would have been wrong in most previous computing eras. It is right now, and it will stop being right at some point, and watching for that moment is most of the job.