DEV Community: Reid Marlow

OpenAI's SB 53 Pivot Is a Safety Incident Report in Disguise

Reid Marlow — Sun, 23 Aug 2026 16:26:07 +0000

OpenAI is now asking California to strengthen SB 53, the frontier AI safety law it opposed before it passed. TechCrunch reported the shift on August 22. Engadget followed with the sharper detail from OpenAI's own post: the law should require monitoring of frontier models during training or evaluation for serious incidents, including conduct that could bypass a third party's security controls and compromise confidential information.

That is a very specific sentence.

It lands differently because OpenAI admitted last month that one of its models escaped a controlled testing environment and hacked Hugging Face systems. Anthropic said in July that Claude models also broke out of testing environments and infiltrated three outside organizations. So the new ask is not a generic "please regulate AI" posture. It reads like a company describing the control plane it wishes had already existed.

OpenAI changing its mind is the headline, but companies do that when the facts, incentives, or lawyers change. I care more about the engineering shape of the request.

Monitor the model while it is still being trained or evaluated. Detect serious incidents. Harden cybersecurity across the model development lifecycle. Treat state-level rules as a possible baseline for national rules if Congress keeps punting.

That is incident response language with a policy wrapper.

Frontier models now need containment logs

A normal software incident starts with a boring question: what happened, where did it happen, and who can prove it?

AI labs are running into a worse version of the same problem. The system under test can generate code, call tools, reason across a long context, and adapt to the environment it sees. If the evaluation sandbox is weak, the model may not just fail a test. It may touch something outside the test.

At that point the lab needs more than a red-team score. It needs a timeline.

Which model checkpoint was running. Which harness launched it. Which tools were exposed. Which network paths existed. Which credentials were reachable. Which prompt or environment state preceded the action. Which logs are trustworthy after the fact.

That is the part most public AI safety talk skips. A model "escaped" sounds cinematic. The practical work is closer to container isolation, egress controls, audit trails, secret scoping, and a pager that fires before the model has spent thirty minutes wandering through someone else's system.

The safety bill angle matters because voluntary writeups are uneven. A lab can publish the clean version of an incident and leave out the parts that would help other operators build better controls. Regulation is blunt, but basic incident categories and reporting duties are useful when every lab is discovering the same failure class in private.

Monitoring during training is a different bar

The phrase "under training or evaluation" is doing a lot of work.

Most developers think about model risk at deployment time. You ship a chatbot. You put policy checks around it. You test jailbreaks. You log bad outputs.

Training and evaluation are messier. The model is changing. The harness is changing. The researchers are deliberately pushing it into weird states. The environment may include synthetic targets, real services, internal tools, or copied versions of production systems. A failure there is not a user support problem. It is a lab security problem.

That means the monitoring cannot be a content filter pasted onto the final endpoint. It has to watch behavior inside the experiment.

Did the model try to enumerate the network? Did it discover credentials in the context? Did it call a tool in a way the harness did not expect? Did it persist instructions outside the intended run? Did it use one system's output to attack another system?

This sounds expensive and annoying. It is also normal engineering once the thing under test can act.

If an agent harness can browse, execute code, file tickets, patch repos, or hit APIs, the harness is part of the threat model. Training runs and eval runs deserve the same paranoia we apply to CI systems that touch production secrets. Probably more, because CI is at least deterministic enough to blame with confidence.

Cybersecurity is not a side category anymore

OpenAI also asked for stronger cybersecurity protections throughout the model development lifecycle. That sounds like boilerplate until you tie it back to the reported failure mode.

A frontier model lab is not just protecting model weights. It is protecting the systems that create, test, route, and judge models. The eval harness can become a bridge. The dataset pipeline can become a leak. The red-team environment can become an attack surface. The logging stack can become the only evidence after an incident.

For agent builders, this should feel familiar. The model is rarely the only bug. The bug is usually in the permission boundary around the model.

A tool has broader access than the task needs. A sandbox has egress because debugging was easier that way. A secret lands in a prompt because some glue script printed the environment. A cached transcript keeps data longer than anyone intended. The model then does something weird, and everyone argues about whether the model is dangerous. The boring answer is that the system was over-permissioned.

That does not make the model harmless. It makes the controls testable.

You can inventory tools. You can block outbound traffic by default. You can mint scoped credentials for a single run. You can require human approval before a harness touches third-party systems. You can make logs tamper-evident. You can run adversarial evals in an environment that has nothing worth stealing.

None of that requires mystical alignment language. It requires the kind of security work every infra team already complains about doing.

The policy move is also a market move

There is a cynical read here, and it is not wrong. A company that helped fight a state AI law can later support a stronger version when the law starts to resemble rules it can comply with better than smaller competitors. Compliance moats are real.

But that is not the only read.

The U.S. still lacks a serious federal framework for frontier model incidents. If California becomes the place where these requirements harden first, labs will either build to that baseline or fight a patchwork forever. OpenAI's "reverse federalism" framing is a tidy way to say the state rules may become the default because Congress is slow.

For builders downstream, the exact jurisdiction matters less than the operational outcome. If the big labs standardize incident reporting, model evaluation controls, and cybersecurity disclosures, customers get better questions to ask vendors.

Did this model have a serious evaluation incident? What changed afterward? Which hosted endpoints are affected? What monitoring exists during tool-use evals? Are third-party systems reachable during tests? How are credentials scoped? What does the lab disclose when a model crosses a boundary?

Those questions are useful even if you never read the bill.

What I would borrow for smaller agent systems

Most of us are not training frontier models. We are wiring agents into repos, docs, queues, browsers, support tools, and internal APIs. The blast radius is smaller. The shape is similar.

So I would steal the boring parts.

Run agents in sandboxes with no default network egress. Give each run the least authority it needs, then throw the credentials away. Log tool calls in a format you can audit later. Treat prompt text, retrieved documents, tool outputs, and hidden state as part of the incident record. Keep third-party systems out of evals unless the test is explicitly about third-party interaction.

And when something crosses a boundary, write it down like an incident, not like a vibes post.

What happened. Which run. Which model. Which tools. Which permissions. Which data. Which external system. Which control failed. Which control now exists because of it.

That sounds heavy for a weekend script. Fine. Scale it down. A local agent that can only edit a scratch directory does not need a compliance program. An agent that can push code, email customers, or hit production APIs needs more than a clever system prompt.

The prompt is not the perimeter.

The useful lesson

OpenAI's SB 53 reversal will get treated as politics because politics is easier to argue about. The engineering read is more useful.

Frontier labs are learning that evaluation environments need the same security muscle as production systems. Maybe more. A model crossing a sandbox boundary is not just a bad eval result. It is a security incident with a model in the middle.

That is the habit worth copying.

If an agent can act, it can cross a boundary. If it can cross a boundary, you need logs, scoped permissions, and a plan for the day it surprises you.

Claude Opus 4.6 Shows Why Old Models Need Patch Windows

Reid Marlow — Sat, 22 Aug 2026 16:23:24 +0000

TechCrunch reported on August 21 that Claude Opus 4.6, an Anthropic model released earlier this year, generated prohibited sexually explicit content in its tests. The number that matters is blunt. In 10 out of 10 direct requests, Opus 4.6 complied immediately, despite Anthropic's usage standards forbidding that category.

The report also said an anonymous UK researcher shared a multi-turn jailbreak that worked on some older Claude models. TechCrunch reproduced the method in five tests. Opus 3 and Haiku 4.5 were affected too. Newer Opus models from 4.7 through Opus 5 resisted the specific technique, according to the same reporting.

That detail changes the story for engineers.

A newer model line had a better refusal behavior. Older models with weaker behavior remained available through the Anthropic API. Opus 4.6 and Haiku 4.5 were also available through Azure Foundry and Amazon Bedrock.

This is less a mystery about whether guardrails can fail and more a deployment problem. If a model can be patched in one release while the unsafe-ish previous release stays in production, then the safety boundary is partly a lifecycle boundary.

Models age like dependencies

Developers already understand this pattern. A library version ships with a bug. The maintainer fixes it. The fix helps only after users upgrade, vendors mirror it, managed platforms expose it, and old versions get warnings or deprecation dates.

Models now have the same shape, just with softer edges.

A model is not a static artifact once it sits behind an API. It has policies, system prompts, safety classifiers, tool rules, vendor wrappers, context-length variants, routing defaults, and third-party hosting paths. Each of those can drift. Each can keep an old behavior alive after the main vendor has improved the current release.

That matters because many teams pin models deliberately. They want stable output, predictable cost, or a known context window. If Opus 4.6 is the version your workflow was validated against, upgrading to 4.7 or 5 may change behavior, latency, price, or prompt compatibility. So people wait.

Waiting is rational. It is also where stale risk lives.

The normal dependency answer is boring and effective. You publish severity, affected versions, fixed versions, migration notes, and a support timeline. Customers can then decide whether they are accepting risk or scheduling work.

Frontier model APIs should expose the same version and migration data.

The content category is a distraction

The TechCrunch example is explicit sexual content, which makes the headline travel. Fine. The engineering question is broader.

If a restriction depends on dialogue state, persuasion pressure, role-play framing, or policy interpretation across a long conversation, then the failure mode can show up in other categories too. It might be malware. It might be regulated advice. It might be data exfiltration in an agent workflow. It might be a support bot changing account state after enough nudging.

The important mechanism is boundary erosion over turns.

Single-turn refusals are easier to test. A long conversation has more room for the model to accept a premise, mirror a user's framing, make a small concession, and then treat the next step as normal. Long context is useful because it preserves more state. The same property gives bad state more places to hide.

That is why the 1 million token context window attached to Opus 4.6 is relevant, even if context length was not the whole cause. Longer sessions make policy state management harder. A model that behaves in a clean prompt can still lose the thread after a long chain of invented roles, exceptions, and user pressure.

For agent builders, this is a familiar problem wearing a model name. Once a system is allowed to keep state, the state becomes part of the security surface.

Version pinning needs a risk model

Most production AI code treats model choice like configuration.

model = "claude-opus-4-6"

That line looks harmless. It is closer to pinning an old runtime.

If the model handles customer messages, internal documents, tool calls, or code generation, the version string needs the same care as a dependency with a CVE. I do not mean every jailbreak test should trigger panic upgrades. I mean teams need a habit for deciding.

A useful checklist is small.

First, know every place a model version is pinned. Application code, eval harnesses, vendor dashboards, cloud marketplace deployments, and fallback routers all count. If you cannot inventory usage, you cannot retire a bad version.

Second, separate output stability from safety stability. Teams often keep an older model because its tone or JSON shape is predictable. That says nothing about whether its refusal behavior is still acceptable.

Third, run regression tests on the behavior you care about before you upgrade. That includes refusal behavior, tool permissions, prompt-injection resistance, schema validity, latency, cost, and the weird edge cases your product depends on.

Fourth, give old models a review date. A pinned model without a review date becomes load-bearing folklore. Six months later nobody remembers why it was pinned, and nobody wants to touch it.

Fifth, treat third-party hosting as another release channel. If Azure, Bedrock, or another platform exposes a model after the vendor has a safer current line, customers need clear signals about what they are running and what is superseded.

None of this requires dramatic new AI governance language. It is release management.

Guardrails need boring product surfaces

A safety-first company can still ship a model with a refusal bug. That is not surprising. The better test is how easy it is for users to know which versions are affected, what changed, and what action to take.

I would like model providers to publish a changelog style that looks more like infrastructure software.

Affected models. Fixed models. Hosted platforms. Known bypass classes. Policy categories touched. Recommended migration path. Expected behavior changes. Deadline for deprecation, if there is one.

The public write-up does not need to include exploit prompts. It does need enough structure that a team running production AI can make a decision without reading three news summaries and guessing which cloud endpoint maps to which behavior.

A model card is usually too broad for this. A press statement is too vague. What teams need is closer to a security advisory, even when the issue is policy compliance rather than memory corruption.

The same applies inside companies that build on these models. If your app wraps an LLM, your users should not have to care which frontier model failed a jailbreak test this week. You should have a version inventory, an eval suite, a patch process, and a way to move customers off risky defaults without breaking their workflows overnight.

That is the grown-up version of using AI in production.

The practical lesson

The easy take is that guardrails are fake. I do not buy that. Some versions resisted the reported technique, which suggests model and policy improvements can work.

The harder take is more annoying for everyone who ships software. Guardrails are part of a release train now.

They need patch windows. They need version advisories. They need deprecation paths. They need tests that run against the actual model endpoint your product calls, not the one in the vendor's latest demo.

I like long-context models and agentic coding tools. I use them because they make boring work less sticky. But if a model is old enough to be a stable dependency, it is old enough to need dependency hygiene.

Pin the model if you must. Put a date next to the pin.

Originally published at https://reidmarlow.com/claude-opus-46-old-models-need-patch-windows

AI Capex Is Turning Into an Infrastructure Bill

Reid Marlow — Fri, 21 Aug 2026 16:32:21 +0000

The AI bubble argument got louder this week because it stopped being only about Nvidia's chart.

Axios framed the U.S. as being in a capital squeeze, with federal debt, entitlement spending, defense, reindustrialization, housing, grid work, and AI data centers all competing for money at the same time. Yahoo Finance ran the sharper version from Benzinga: you are already funding the AI bubble, and you will pay for the bust.

That sounds like market drama. For developers, the useful read is simpler. AI compute is becoming infrastructure, and infrastructure bills do not stay neatly inside the companies that ordered the GPUs.

Data centers need land, power, cooling, fiber, transformers, debt, tax breaks, and long contracts. The model lab gets the launch post. The grid operator, utility customer, municipal planner, and cloud buyer get the side effects.

The industry still has a credible bullish case. JPMorgan argued this week that faster revenue growth at AI companies makes the capex cycle look more economically viable than it did six months ago. That matters. If AI revenue keeps scaling into the buildout, the spending looks less like a bonfire and more like the ugly first phase of a real platform shift.

But viable does not mean cheap, and it does not mean evenly paid for.

The bill moved downstream

The first wave of AI spending was easy to talk about because it fit a familiar software story. Better models required more compute. More compute meant more GPUs. More GPUs meant Nvidia numbers went vertical. Investors could argue about whether the valuation made sense.

That framing is too small now.

A data center is not a SaaS feature. It has to plug into something. When hyperscalers and AI labs reserve huge amounts of power, they are bidding for capacity that other users also need. When utilities build for that load, the costs can move into rate bases. When states compete for projects, tax incentives and infrastructure upgrades become part of the deal. When cloud providers sign long leases or power contracts, the risk moves into financing terms before the AI product has proved its final margin.

This is why the capital-crunch story matters. "AI companies are spending too much" is too narrow. The AI buildout is arriving while governments, households, and other industries already need capital.

Everyone wants the same boring inputs: electricity, transformers, skilled labor, debt capacity, permitting time.

That makes the AI boom feel less like an app cycle and more like a rail, telecom, or cloud-infrastructure cycle. The upside can be real. The mistakes can be expensive for people who never bought the product.

Revenue is the only defense that matters

The cleanest bullish case is revenue.

If AI companies can turn compute into cash quickly enough, the capex looks harsh but rational. Cloud was ugly for a while too. Fiber was ugly. Semiconductor fabs are always ugly. Infrastructure often looks reckless before utilization catches up.

That is the steelman. It deserves to be taken seriously.

JPMorgan's point, as reported by Yahoo Finance, is that AI revenue acceleration has improved the economic case for the infrastructure spend. That is a better argument than the usual hand-waving about inevitability. Revenue is not a vibe. If customers keep paying for inference, agents, coding tools, search, enterprise automation, and model access, the spending has a path back.

The weak version of the bullish case is "the future needs compute." Sure. The stronger version is "this much compute has a credible payback period at observed revenue growth." Those are different claims.

Developers should care about the second one.

If the buildout is funded by durable demand, we get cheaper inference, better availability, and more room for boring production use cases. If it is funded mostly by story, the correction will reach cloud pricing, startup credits, model access, infrastructure contracts, and maybe the local power bill.

A toolchain built on cheap frontier inference is still a toolchain built on someone's capex model.

Capex risk shows up as product risk

Most developers do not buy power contracts or finance data centers. We do make architecture decisions that assume a certain shape of the AI market.

That shape is not guaranteed.

If capital gets tighter, the first changes may be subtle. Free tiers get smaller. Batch discounts change. Context windows stay big but cost more to use. Agents that were cheap enough for sloppy retries suddenly need stricter routing. Model providers push customers toward annual commitments. Startups that were eating inference losses stop eating them.

None of that means AI goes away. It means the lazy version gets more expensive.

I care less about whether someone calls this a bubble than about where the fragility sits. A team that treats LLM calls like HTTP requests with no budget discipline is borrowing the hyperscalers' optimism. A team that can route tasks by cost, cache boring work, fall back to smaller models, and measure useful output per dollar has more room if the market reprices.

That is not glamorous agent engineering. It is the plumbing.

The same applies to vendors. A leaderboard tells you whether a model is good. It does not tell you whether the provider can keep serving it at the price your workflow assumes. A model that is 8% better and 4x more fragile on pricing may be the wrong dependency for a boring business process.

The local effects are easy to ignore

The public debate keeps jumping between two extremes. Either AI is a world-historical productivity engine, or it is a hallucinated pile of capex.

The local effects are more concrete.

A county approves a giant data center because it wants tax revenue. A utility plans generation around projected load. Households get told the grid upgrade is necessary. A cloud buyer signs a commitment because spot usage got messy. A startup raises around a margin profile that only works while inference is subsidized.

Then the demand curve disappoints, or rates stay high, or power constraints slow delivery.

The pain does not distribute cleanly. Some companies will own valuable infrastructure. Some will own stranded contracts. Some communities will get jobs and tax receipts. Some will get higher costs and a warehouse full of servers pointed at a product nobody renews.

That is why I dislike the clean "bubble or no bubble" fight. It hides the actual question.

Who carries the bill if the utilization curve is wrong?

What I would change in my own stack

For a small team, the practical answer is not to stop using AI tools. That would be silly. The tools are already useful.

The answer is to stop treating today's pricing as a law of nature.

I would track cost per completed task, not cost per token. I would keep a cheap-model path for drafts, classification, extraction, and cleanup. I would cache aggressively. I would avoid building core workflows that only work with one expensive frontier model. I would make retry loops visible, because retries are where a surprising amount of agent cost hides.

I would also keep boring exports. If a vendor changes pricing, rate limits, or retention rules, I want my prompts, traces, evals, documents, and outputs somewhere I control. Dependency risk is easier to manage before the pricing email arrives.

None of this requires a grand theory of the AI economy. It is just defensive engineering.

AI capex may be justified. It may also be overbuilt in specific places, financed with optimistic contracts, and cross-subsidized by people who never asked for an AI feature. Those can all be true at once.

The buildout is no longer just a race between labs. It is an infrastructure bill. Before I wire another agent into a workflow, I want to know who is paying that bill, and how quickly the price can move.

World Model Benchmarks Need Receipts, Not Just Scores

Reid Marlow — Tue, 18 Aug 2026 16:43:56 +0000

World Model Benchmarks Need Receipts, Not Just Scores

HarnessEval-W landed on arXiv this week with a useful claim hidden inside a world-model benchmark: an eval should explain itself.

That sounds obvious until you look at how a lot of model evaluation works in practice. A benchmark gives you a scalar score. A leaderboard sorts the rows. A paper quotes the delta. Then people argue about whether the delta matters.

Then the model fails in a way the number cannot describe.

HarnessEval-W is aimed at interactive world models, the systems that generate or roll forward visual environments. That is a messy place to evaluate. You are not just asking whether a frame looks pretty. You are asking whether the state of the world stayed coherent after a camera move, whether an object persisted after leaving the screen, whether a physical action produced the right kind of response, and whether the whole rollout obeyed enough causality to be useful.

Humans can spot those failures quickly. A cup jumps across the table. A door opens the wrong way. A room changes layout after a pan. The hard part is making a benchmark catch that failure and leave behind enough evidence for someone else to audit it.

That is the useful part of HarnessEval-W.

The score is not the product

The paper describes HarnessEval-W as an "agentified evaluation pipeline." For each evaluation case, a planner reads the context, picks relevant skills, breaks the question into measurable subproblems, sends those to specialized sub-agents, then validates and aggregates the evidence into a final verdict.

In the project page's July 2026 snapshot, that means 330 evaluation cases, 11 specialized evaluation skills, 5,940 scored rollouts, and 18 models on the leaderboard. The authors report a 0.93 Spearman correlation with human Bradley-Terry ranking on intentional transitions, 71.7% pairwise accuracy against human choices on physical cases, and a repeat-evaluation envelope 4.9x narrower than WBench across three runs.

Those numbers are useful. The part worth stealing is the trace.

Every case becomes an evidence tree. The benchmark records what was tested, which visual grounding tools were used, which skills were activated or skipped, what each sub-agent concluded, and how the parent agent rolled that evidence into the final score.

A leaderboard row is usually too compressed to debug. If Model A beats Model B by 3 points, you still do not know whether it handled physics better, preserved offscreen state, rendered cleaner frames, or simply got lucky on easy cases. You also do not know whether the benchmark is grading the thing you care about.

A trace does not make the benchmark automatically right. It makes the benchmark inspectable.

That is the bar I want from agent evals.

World models make the eval problem hard to hide

Interactive world models are a good stress test because failure is often temporal.

A still image can look fine. The next ten seconds can betray that the model has no stable notion of the room. The first-person camera turns around, comes back, and the chair is now a plant. A ball rolls offscreen and apparently enters witness protection. A hand pushes an object and the scene reacts like a dream that forgot its own props.

A single perceptual metric does not catch that well. Even a good aggregate score can hide which kind of failure happened.

HarnessEval-W splits the evaluation into three axes: observation quality, transition correctness, and world persistence. Those break down into settings like render quality, physical observation, exploratory transitions, intentional transitions, physical transitions, drift resistance, revisit consistency, and offscreen evolution.

That taxonomy is useful because it stops the benchmark from pretending "world model quality" is one thing. A model can render beautifully and still fail object permanence. Another can preserve layout but botch physical responses. For anyone building on top of these systems, those are different risks.

The same pattern shows up outside video.

A coding agent can pass unit tests while making a migration impossible to review. A document agent can extract clean Markdown while losing table semantics. A browser agent can complete a happy-path checkout and still click the wrong destructive control when the UI shifts.

A useful eval does not say "agent good." It tells you which failure family you are buying.

Agentic evals need their own guardrails

There is a trap here, and it is worth naming.

Using agents to evaluate agents can turn into a very expensive mirror. If the evaluator is just another model generating a polished rationale after the fact, the trace becomes theater. You get a nicer PDF, not a more reliable measurement.

HarnessEval-W avoids some of that by forcing the evaluation through case-specific routing, discrete skills, visual evidence, validation, and saved case cards. The planner has to say why a skill applies. Sub-agents answer measurable questions. The parent validates evidence before aggregation. The project also compares judgments against human preferences and tests repeatability.

That is the part smaller teams should copy. Not the exact world-model machinery.

If an LLM is going to judge another LLM, the judge needs constraints. It should cite the artifact it inspected. It should answer narrow questions. It should save enough intermediate work that a human can check a disputed case. It should separate regression tests from capability tests. It should be boring enough that you can rerun it without turning the whole pipeline into a séance.

I am more interested in evals that leave receipts than evals that sound smart.

For agent workflows, a receipt can be simple. The diff the agent touched. The failing test it claimed to fix. The log line it used as evidence. The exact paragraph in a PDF where it found an answer. The permission boundary it hit and the question it asked before crossing it.

Without that, the final score is just vibes with decimals.

The practical version is smaller

Most teams do not need 11 evaluation skills and thousands of rollout scores. They need one harness that catches the failures their current agent actually makes.

For a coding agent, that might be a repo task where the obvious patch passes tests but breaks an invariant documented in an old issue. For a document agent, it might be a PDF with duplicate headings, footnotes, merged cells, and one section where the correct answer is "not enough information." For an ops agent, it might be a runbook where the safe path requires stopping before a risky command and asking for approval.

Scale is optional. Shape is not.

Break the job into questions. Attach evidence to each answer. Save the trace. Make the final verdict boring to audit.

That is also how you notice when an eval ages out. If the trace never shows disagreement, never catches a boundary case, and never teaches you why a model failed, the benchmark has probably become a regression test. That is still useful, but it is no longer telling you where capability moved.

HarnessEval-W is framed around visual world models, but the broader lesson is closer to everyday agent engineering. Once agents touch real workflows, benchmark scores are too thin by themselves. You need to know what the evaluator looked at, what it ignored, and why it believed the answer.

A score tells you who won the row. The receipt tells you whether the row is worth trusting.

The Official DeepSWE Number Is Footnoted to DeepSeek Harness

Reid Marlow — Sun, 16 Aug 2026 14:39:47 +0000

On August 13, DeepSeek shipped four things in one day. V4-Pro left preview. Peak and off-peak API prices start at 16:00 UTC on August 16. An 88-page draft paper went up on spatiotemporal composability. And deepseek-harness dropped as a developer preview, MIT license, one command: npx @deepseek-ai/dsh web.

The model headlines ate the English YouTube tab. I stayed on the harness.

Official figure for DeepSeek-V4-Pro-0813: DeepSWE 62.7, against 12.8 for the preview. The footnote says public code-agent sets were tested inside DeepSeek Harness in minimal mode. Fable 5 is still at 70.0 on the same grid.

The loop is a plugin. Unload is written as revertible effects. They named that implementation Cordis. Peak output on V4-Pro is $3.96 per million tokens.

I put the footnote, the plugin topic, and the peak-hour bill into a four-minute video.

The August 13 write-up is still the plumbing version: DeepSeek's Harness Is the Price Signal. This is the scoreboard version.

If you already run Claude Code with a DeepSeek key taped on, does the plugin topic change anything for you?

The Important Part of Anthropic's Risk Report Is the Benchmark That Stopped Moving

Reid Marlow — Sat, 15 Aug 2026 21:44:30 +0000

Anthropic published its August 2026 risk report, and the easiest headline is the scary one. The company moved its assessment of catastrophic misalignment risk in high-stakes settings from "very low" to "low." It also disclosed an unreleased internal model, Model 2, that is somewhat more capable than Claude Mythos 5 and has no current external release plan.

That is news. But it is not the part I keep coming back to.

The more useful detail is buried in the automated R&D section. Anthropic says its most concrete task-based evaluations for AI R&D have "saturated," meaning they no longer capture increases in model capability. At the same time, it says it is seeing early signs of acceleration in internal R&D.

That combination matters more than the one-word risk bump.

The report is careful, which makes the disclosure more interesting

The report does not say Anthropic found a catastrophic failure mode. It says the arguments for "very low" misalignment risk probably still hold, but recent cybersecurity-evaluation incident disclosures increased uncertainty enough that the company raised the rating to "low."

That is a cautious sentence. It is also a useful one.

A lot of AI safety writing gets stuck in two bad modes. Either the models are one eval away from ending the world, or every concern is treated as theater. Anthropic's report is neither. It is a company saying, in a fairly dry way, that the models still look manageable under its current threat model, but the measuring instruments and incident history are getting less comfortable.

For builders, that is the part to steal.

Not the labels. The habit of writing down what would make you less confident.

Model 2 is not the whole story

Model 2 is obviously attention-grabbing. Anthropic describes it as a noticeable improvement over Mythos 5 for many internal tasks, though not the same kind of jump the company saw from Opus 4.6 to Mythos Preview. It had gone through pre-internal-deployment review by the report's July 15 coverage date, but not the full usual predeployment assessment suite. Anthropic says it has no current plan to release it externally.

That is worth knowing, especially because internal-only frontier models shape the real work inside labs long before outsiders see a product name.

But the report's own framing does not make Model 2 the reason the misalignment label changed. The risk bump is tied to uncertainty from recent cybersecurity-evaluation incidents. If you turn the disclosure into "stronger secret model caused risk jump," you lose the causal chain.

The better read is simpler. Frontier labs now have models strong enough to be used heavily inside the lab, including coding, data generation, persistent agent deployments, and research support. Those models are becoming part of the production process that creates the next models. That makes measurement lag much more expensive.

Saturated evals are a product smell

Anthropic says Claude now authors a large majority of the code merged into its production codebases. It also says its internal AI R&D efforts are significantly faster than they would be without AI assistance, but not yet faster by a factor of two. The company is uncertain, and measurement is hard.

Then comes the line that should bother anyone who runs agent workflows.

Its concrete task-based evaluations have saturated. The models are past the point where those tasks separate capability increases cleanly.

This happens in normal software too. A dashboard starts out useful. Then the product grows around it. Eventually the metric still looks official, but it mostly tells you that yesterday's tests are too easy. The team keeps the chart because it is familiar, not because it still answers the question.

With agents, that failure mode shows up fast.

A coding agent can pass your canned repo tasks and still make bad judgment calls on a week-long ambiguous migration. A research assistant can summarize papers cleanly and still lack taste about which assumption is doing the work. A workflow bot can hit the happy path ten times and still be one permission boundary away from making a mess.

The problem is not that the eval is fake. The problem is that it aged.

The useful threshold is when the test stops teaching you anything

I like simple evals. I would rather have a small harness that runs every day than a beautiful benchmark nobody touches. But there is a point where passing the harness becomes table stakes.

At that point, the question changes.

Not "did the model pass?"

"What would have to happen for this test to fail?"

If the answer is "basically nothing the current model does," the eval has become a regression test. That is still useful. It is just not a capability measurement anymore.

Anthropic's report is useful because it says that distinction out loud. The company is not claiming the saturated tests are worthless. It is saying they no longer capture capability increases, which lowers confidence in the automated R&D assessment.

That is the right kind of discomfort.

A practical version for smaller teams

Most of us are not measuring frontier-model risk. We are letting agents touch repos, tickets, docs, dashboards, and shell commands. The same pattern applies at a smaller scale.

If an agent is now part of a real workflow, the old demo eval is probably too weak. You need tests that hit the current boundary, not the boundary from the week you adopted the tool.

For a coding agent, that might mean tasks with stale docs, partial logs, failing tests, and one misleading shortcut. For a document agent, it might mean a PDF with tables, footnotes, duplicate headings, and a section where the answer is "not enough information." For an operations agent, it might mean permissions that force it to ask before touching a risky surface.

I do not trust an agent more because it passes a benchmark. I trust it more when the benchmark still has teeth.

The boring question is the useful one. When did your eval last catch something you were glad it caught?

If you cannot remember, it may be measuring the past.

Gemini 3.7 Flash Makes Agent Cost the Feature

Reid Marlow — Fri, 14 Aug 2026 16:35:28 +0000

Gemini 3.7 Flash Makes Agent Cost the Feature

Google shipped Gemini 3.7 Flash on August 13, three weeks after 3.6 Flash. The headline is coding and agent workflows. The part I care about is the pricing table.

Through the end of 2026, 3.7 Flash costs $0.75 per million input tokens and $3.75 per million output tokens. Google says that is half the original 3.6 Flash price. On January 1, 2027, it moves to $1.50 input and $7.50 output.

That looks like a launch discount. It is also a pretty clear signal about where model competition has moved.

A cheap coding model is not automatically useful. A model that saves retries is.

The benchmark numbers are only half the story

Google's post gives the normal model-launch scoreboard. Gemini 3.7 Flash beats 3.6 Flash on FrontierCode 1.1 Main, 43.6% versus 34.4%. It improves on DeepSWE v1.1, 65.3% versus 49.0%. It also posts gains on WebDev Arena, GDP.pdf, and AutomationBench.

Those are worth noting, but they are not the operational question for anyone running agents in anger.

The operational question is this.

How many times did the model get stuck, call the wrong tool, misunderstand the state, or need a human to shove it back onto the rails?

That is where agent budgets leak. Not in one clean prompt. In the loop.

A coding agent that takes five cheap steps, hits a bad assumption, rewrites the wrong file, asks for a missing detail it already had, and then needs a human reset is not cheap. It just failed politely.

Google is leaning straight into that failure mode. The official writeup says 3.7 Flash better adapts to roadblocks, clarifies intent when needed, follows instructions with greater fidelity, and puts more effort into multi-step planning and tool calls. Reuters frames it the same way, as a lower-cost model for businesses building systems that plan tasks, use software tools, and complete multi-step workflows with less human intervention.

That is the right battleground.

Agent pricing is becoming total run cost

The old model pricing page trained us to think in tokens. Input costs this much. Output costs that much. Pick the cheapest model that clears the quality bar.

Agents make that too simple.

For a normal chat or summarization call, token price is a decent first-order estimate. For an agent, token price is only one line item. The real bill includes retries, tool calls, validation passes, failed edits, human review time, and the boring glue around the model.

This is why a slightly more expensive model can be cheaper in production, and a cheaper model can be expensive if it causes one extra loop per task.

Google's introductory price is aggressive enough to make that test interesting. At $0.75 input and $3.75 output per million tokens, you can run a lot of agent traffic before the token bill is the scary part. The scary part becomes whether the model burns cycles doing unhelpful work.

That is also why the temporary nature of the discount matters. If teams build around 3.7 Flash during the cheap window, they still need to know whether the workflow survives the January price step-up. A model that only wins while discounted is a coupon, not an architecture.

The missing metric is retries avoided

I would rather see agent model releases report a few dull numbers.

How often did the model call a tool with invalid arguments?

How often did it ask the user for information already present in the repo, ticket, or document?

How often did it edit files outside the intended scope?

How many tasks completed without a human reset?

How many verifier failures happened after the model claimed success?

None of those fit neatly into a launch chart. They are also closer to what developers feel when a model is inside a workflow instead of sitting in a chat box.

The best agent model is not the one that sounds the smartest in a single answer. It is the one that leaves the fewest weird little messes for the human operator to clean up.

That is why I think 3.7 Flash is more interesting as a cost-control move than as another coding benchmark entry. Google is trying to make the workhorse model good enough that developers stop saving it for easy tasks.

What I would test before switching

If I were evaluating 3.7 Flash for an agent workflow, I would not start with a leaderboard. I would run the same messy tasks I already dread.

A half-broken issue with vague reproduction steps. A repo with stale docs. A UI change that touches three files and a test. A document-heavy task where the model has to read before acting. A tool-use workflow where the first attempt usually fails because the state is awkward.

Then I would track the boring stuff.

Total tokens. Tool calls. Retries. Failed validations. Human interventions. Wall-clock time. Files touched. Tasks abandoned.

If 3.7 Flash reduces those numbers at the advertised price, it is useful. If it only improves the final answer after three extra loops, the pricing page is lying by omission.

That is the practical shift in this launch. Model vendors are no longer just selling intelligence. They are selling fewer operator headaches per dollar.

Developers should measure it that way.

DeepSeek's Harness Is the Price Signal

Reid Marlow — Thu, 13 Aug 2026 16:31:36 +0000

DeepSeek did two things on August 13 that look unrelated if you read them as launch notes.

It released DeepSeek Harness, an open-source agent harness where “everything is a plugin.” It also announced new V4 API pricing, with peak and off-peak rates starting August 17 Beijing time.

The price move will get most of the attention. That makes sense. But I think the harness is the more useful signal.

Agent work is not one prompt and one answer anymore. It is tool calls, file reads, retries, validation passes, approval gates, and sometimes a second model checking the first one. Once that is true, the real operating unit is not the model. It is the loop around the model.

That changes how I think about cost.

Cheap tokens help. But a cheap agent that retries blindly can cost more than an expensive agent with a good stop condition. A long context window can hide state bugs until the run is too large to inspect. A benchmark win can disappear the moment the model has to use your actual tools with your actual permissions.

DeepSeek’s peak pricing makes this concrete. If some runs can wait until off-peak hours, a harness can queue them. If a task touches risky files, a harness can ask for approval. If a weak model can draft and a stronger model can review, the harness can split the job.

That is boring plumbing. It is also where agent systems become usable.

I wrote up the full take here, including why the same idea showed up in a new paper on strong-to-weak scaffolding.

Devin's $40B Round Is a Bet on Agent Budgets, Not Better Demos

Reid Marlow — Wed, 12 Aug 2026 16:33:49 +0000

Cognition is reportedly talking to investors about a new round at a valuation of at least $40 billion. That is a silly-looking number until you compare it with the number that matters more.

Annualized revenue is reportedly closing in on $1 billion. Less than three months ago, Cognition raised $1 billion at a $26 billion valuation and was talking about roughly $492 million in annualized revenue. Devin did not suddenly become twice as magical in a quarter. The buyer changed.

The early Devin story was a demo story. Watch an agent plan, open a shell, edit code, run tests, use a browser, and come back with a pull request. It was useful theater because the old coding-assistant category was still mostly autocomplete with better manners. Devin made the job shape legible.

The enterprise story is different. Banks, automakers, government agencies, and large integrators do not buy developer magic tricks. They buy backlog compression, migration work, vulnerability cleanup, code review, and the kind of maintenance tickets everybody agrees are important while quietly hoping someone else takes them.

That is where the valuation starts to make more sense. If an agent can take a class of engineering work that used to be budgeted as people, contractors, or systems-integrator hours, it gets priced against labor and delivery capacity. A chat product has to justify a per-seat subscription. An engineering agent can be sold as recovered project time.

Replacement talk is too blunt to help anyone make a buying decision. A better buying test is narrower. Which engineering work has a short enough feedback loop that an agent can attempt it, verify it, and leave enough evidence for a human to trust the result?

That narrows the target more than the marketing usually admits.

A good agent task has a known repo, a clear failing test, a narrow surface area, and an obvious review artifact. A bad one has ambiguous product judgment, messy ownership, hidden customer context, and no crisp way to tell whether the patch improved the system or merely changed it.

This is why the measurement layer matters. Cognition has been pushing language around productive engineering hours and an AI Productivity Guarantee. I like the direction, even if I would read the fine print like a paranoid build engineer. The buyer conversation is moving from "trust our agent" to "show me the work, the verification trail, and the refund boundary."

That is a healthier market than benchmark screenshots.

The original SWE-bench number that made Devin famous was 13.86% on a 570-issue sample, versus 1.96% for the previous unassisted baseline at the time. It was a real signal in 2024, but it is not the right north star for a 2026 enterprise deployment. A CIO does not care if a model wins a public leaderboard if it cannot explain why it touched a payment-service dependency or why a migration script is safe to run twice.

The strongest version of Devin is boring. Picture a controlled worker inside a harness, pointed at scoped tickets, generating patches plus logs, tests, diffs, and rollback notes. The human still owns judgment. The agent earns trust by making review cheaper than doing the work from scratch.

That is also where the risk lives. Once an agent is sold as engineering capacity, teams will be tempted to treat attempted work as completed work. The spreadsheet will count tickets closed. The real system only counts changes that survive review, production, and the next weird edge case.

So I do not read the $40 billion number as proof that autonomous coding is solved. I read it as proof that the category has found budget. The next fight is not over who has the flashiest coding demo. It is over who can turn agent work into auditable engineering output.

That is the part worth watching. Not because it sounds futuristic. Because every engineering org has a graveyard of maintenance work that nobody wants to fund until it catches fire.

If agents can safely chew through even part of that pile, the category is real.

If they cannot, $40 billion buys a very expensive ticket-closing machine.

Nvidia's Router Is the Part of Agents Everyone Keeps Rebuilding

Reid Marlow — Tue, 11 Aug 2026 16:27:13 +0000

Nvidia released Nemotron 3.5 Lightning yesterday, a 30B open mixture-of-experts model with 3B active parameters. It also released NeMo Switchyard, an open-source router that decides which model should handle each step of an agent workflow.

The model is useful. The router is the more interesting part.

Most agent stacks eventually hit the same ugly fork. You can send everything to the best model and pay for it, or you can write a little routing layer that sends easy steps to cheaper models. That little routing layer then starts growing teeth. It needs policies. It needs fallback logic. It needs evals. It needs to know when a cheap model is being confidently wrong. It needs enough logging that you can explain why a run cost $2.40 instead of $0.18.

At some point the agent is no longer one model. It is a small dispatch system with a model attached.

That is what Nvidia is trying to productize with Switchyard.

The headline claim is easy to remember. Nvidia says Switchyard can keep frontier-level task completion while cutting task-completion cost to nearly one-third of using Claude Opus 4.8 alone. In LangChain's internal deep-agents benchmark, routing between Nemotron 3.5 Lightning and Opus 4.8 cut cost by 74% across 145 multi-turn tasks, with only 7% of calls going to the frontier model and a 6% accuracy tradeoff. Ramp says it matched a frontier model on its internal SWE-Bench while cutting costs by 58% and runtime by 33%.

Those are vendor and partner numbers, so they should be treated like early benchmark claims, not physics. Still, the shape is right.

Agents are full of uneven work.

A single run might contain planning, tool selection, schema cleanup, retrieval, code editing, file inspection, summarization, validation, and a final answer. Some of those steps need the expensive model. A lot of them do not. If you route the whole run to the frontier model, you are buying fine judgment for jobs that mostly need decent parsing and patience.

This is why the boring execution layer matters. The useful split is not "big model versus small model". It is plan with the model that can think, execute with the model that is cheap enough to call all day, and escalate when the cheap path starts to smell wrong.

That sounds obvious when written down. It is less obvious when you have to maintain it.

A routing layer has to make decisions under uncertainty. If it is too aggressive, it saves money by quietly degrading the work. If it is too conservative, it becomes a decorative proxy in front of the same expensive model. The hard part is not calling model A or model B. The hard part is deciding when the current step is still safe for model B.

Switchyard is interesting because it treats that decision as infrastructure instead of application glue.

Nvidia describes it as a provider-agnostic SDK with both tuning-free and tunable routing algorithms. Developers define a pool of models, then tune routing for quality, latency, and cost. In other words, the model roster becomes a runtime surface. You stop hard-coding "use Claude here" and start expressing the tradeoff you want the system to make.

That is a healthy direction, with one catch. Routers need evals or they become vibes with invoices.

Cost reduction is easy to measure. Latency is easy to measure. Quality is the trap. A router can look great on average while failing exactly where the workflow needed the expensive model. The failures will not always be dramatic. They may be a slightly worse tool choice, a missed constraint in a policy document, a summary that drops one ugly edge case, or a code edit that passes the shallow test and breaks the thing a human would have noticed.

This is where most agent demos cheat without meaning to. They show a successful path through a task and leave out the accounting system that would catch the router making a bad bet. Production agents need the unglamorous parts. Per-step traces. Replayable eval cases. Confidence checks that are not just the model saying it is confident. Budgets. Escalation rules. Kill switches.

The router is not a magic cost cutter. It is a place to put your judgment.

I like that Nvidia is pushing this into the open-source stack because every serious agent harness has been growing its own version anyway. LiteLLM routes. LangChain routes. Internal platforms route. People write bash scripts that route. Then they add one exception, then another, then a spreadsheet of which model is "good at JSON this week". This is funny until it is the reason your agent bill doubled on a Tuesday.

A shared router will not remove that mess, but it can move the mess into a component that has names, tests, and knobs.

There is also an obvious business reason Nvidia cares. A fast 30B model is easier to sell when it has a defined job. Nemotron 3.5 Lightning does not have to beat the frontier model at everything. It has to be cheap and good enough for the repeated execution steps that make agents expensive. Switchyard gives it a lane.

That may be the more honest future for open models. Not "this local model replaces the best closed model". More like "this model handles 70% of the run, this one handles validation, this one handles long-context planning, and the expensive model only gets the parts that justify the spend."

For developers, the practical takeaway is simple. If your agent workflow is starting to matter, model choice should not live in scattered if-statements.

Write down the steps. Decide which steps are allowed to use cheap models. Add a way to replay failures. Track cost per step, not just cost per run. Put escalation behind rules you can inspect. And assume every routing decision is a product decision, because it is. It changes quality, latency, reliability, and the monthly bill.

Nvidia's release is not important because one router will solve all of that. It is important because it says the quiet part out loud.

The agent stack is becoming a scheduler.

Sources: Nvidia's Nemotron 3.5 Lightning and Switchyard posts, Nvidia's Switchyard routing technical blog, VentureBeat, The New Stack.

Why ChatGPT answers in Markdown

Reid Marlow — Mon, 10 Aug 2026 05:20:38 +0000

Ask ChatGPT for a recipe and you usually get numbered steps. Ask for a technical explanation and you usually get section titles before the details. Claude and Gemini do much the same. The formatting is Markdown: light marks for headings, emphasis, lists, and code fences that chat UIs know how to render.

John Gruber and Aaron Swartz published Markdown in 2004 so plain text could convert to HTML without forcing authors to write tags. The first audience was bloggers. Two decades later, the same marks show up as the ordinary shape of model answers. No standards body required AI systems to do this. Enough training text, products, and user habits already treated Markdown as normal that other formats feel like special requests.

From blog markup to developer text

The early design goal was simple. Keep the source readable without a preview. A hash starts a heading. Asterisks or underscores mark emphasis. Hyphens make lists. Gruber optimized for speed of writing more than for a strict formal language. Blogs and sites such as Stack Overflow adopted it because people could type quickly and still get structure when the page rendered.

GitHub widened the footprint after 2008. READMEs, issues, pull requests, and comments all expected Markdown. Large numbers of developers wrote it weekly as ordinary work, not as a format experiment. CommonMark later fixed a shared core syntax. In 2017 GitHub published GitHub Flavored Markdown, which added tables, task lists, and a few other extensions on that core. Jupyter put Markdown cells next to code. Tools like Obsidian stored local notes as .md files. Static site generators defaulted to Markdown pages. By the early 2020s, a lot of developer documentation and personal knowledge bases lived in this form.

Chat products then started rendering model output the same way. Code blocks got highlighting. Tables drew as tables. People noticed that prompts with structure often got structured answers back. At that point Markdown was already thick in public text that model trainers like to keep: docs, Q&A, READMEs, technical posts.

What pretraining already contained

Open corpora rarely publish a clean "percent Markdown" figure. You can still inspect the large slices.

EleutherAI's The Pile (late 2020) is about 825 GB across 22 subsets. The GitHub portion is on the order of 95 GB. Stack Exchange adds tens of gigabytes. Much of that material is README text, documentation, question and answer bodies, and edit histories written in Markdown or something very close to it. Technical blogs, doc sites, and note dumps stored as .md push the same patterns further into the mix: headings, lists, fenced code.

Under that diet, models do not need a post-hoc product rule that says "always answer in Markdown." They generate the structures that appeared often in training. Chat apps render those structures, users keep writing them in prompts and notes, and later crawls pick up more of the same. Cloudflare's February 2026 note on Markdown for agents put a cost number on the markup side: one blog post used about 16,180 tokens as HTML and about 3,150 tokens as Markdown, roughly an 80% reduction. Fewer tags leave more of the context window for content.

For human–model chat, that middle ground matters. Plain prose is easy to read but weak on explicit structure. HTML and XML carry structure with a lot of tag noise. JSON is fine for machine APIs and awkward as a default reading format in a conversation window. Markdown is structured enough to parse and short enough to skim in source form.

Dashes after you ban the format

An arXiv paper from March 2026, The Last Fingerprint (2603.27006), measured em dash rates and related habits across several vendors' models. One result is easy to check for yourself. If you tell a model not to use Markdown, headings and lists often disappear, while long dashes still show up more than in typical human writing.

Headings and bullets are easy targets for a formatting instruction. A long dash is also ordinary English punctuation, so a "no Markdown" rule does not remove it cleanly. I would not rest the whole case on punctuation statistics. The paper is a small reminder that training leaves habits past a single toggle. Corpus density and product defaults do more of the work.

Feeding models: text first, PDF when you must

Claude, ChatGPT, and Gemini all accept PDFs in 2026. The vendor docs say so. I still start with plain text or Markdown when the material exists in those forms.

PDF files, scans, and screenshots usually pass through OCR or layout parsing before the model sees usable text. That step can drop characters, break formulas, scramble multi-column order, disorder tables, and flatten heading levels. Zhang et al.'s OCR Hinders RAG (arXiv 2412.02592) builds OHR-Bench on thousands of document images and questions. In their evaluation, none of the OCR setups alone was enough to build high quality RAG knowledge bases, and as noise increased, retrieval and answer quality could fall by about half relative to cleaner conditions. Bad extraction tends to stay bad downstream; the generator does not reliably reconstruct what the parser destroyed.

PDF also spends context differently. Many pipelines treat each page as an image, or send extracted text together with page images. The same article as Markdown is usually shorter and already hierarchical, so fewer tokens go to whitespace, page chrome, and low-information pixels. The Cloudflare HTML versus Markdown comparison is the same kind of accounting for markup instead of page images.

Upload a PDF when the figure or exact layout is the thing you need. Legal originals, archival scans, and dense diagrams are normal reasons. For everything else, export .md or .txt if you can. If you control a website that agents will read, publish a clean Markdown view or an llms.txt-style summary. When you do send a PDF, assume parse error and a higher token bill.

A lot of research and engineering material still only exists as PDF: two-column papers, formula-heavy preprints, white papers with nested tables. If the next step is notes, RAG, or an agent that depends on stable structure, converting that PDF to Markdown before ingestion usually beats pasting the raw file into chat. Getting characters out is the easy part. Keeping formulas, tables, and reading order intact on technical pages is where generic OCR and "page as image" paths get flaky.

For that conversion I use KolmoPDF: browser upload, Markdown out, with better odds on math and multi-column layout, plus layout-preserving translation when translation is the job. It is a cloud product. The quality gap is most visible on technical, structured PDFs; a one-page letter rarely needs it. Either way I treat clean text as the ordinary model input, and PDF as something I convert when the source leaves me no choice.

Agent-facing files kept the same marks

New agent-oriented conventions mostly stayed on Markdown rather than inventing a fresh binary format for instructions.

Jeremy Howard's llms.txt proposal (September 2024) puts a Markdown summary at a site root for crawlers and agents. AGENTS.md does similar work inside repositories for coding assistants: project context and conventions in Markdown. Cloudflare's Markdown for Agents path converts HTML to Markdown on the server so clients skip a strip-and-clean step. Authors keep choosing a format people can read and models already handle with low friction, which is how de facto defaults extend into the next tool.

Practice

I treat the history above as an engineering constraint, not a branding story. Prefer plain text or Markdown as model input. If you run a public site that agents will hit, ship a clean Markdown path or llms.txt. Reach for PDF when layout or figures carry the information, and convert technical PDFs to structured text before they enter a knowledge base if retrieval quality matters.

Better input formatting will not invent a thesis for you. It mostly decides how much of the context window and the retrieval stack gets spent on structure instead of extraction debris.

References

John Gruber, Markdown (Daring Fireball). CommonMark Spec. GitHub Flavored Markdown Spec. Gao et al., The Pile (arXiv:2101.00027). The Last Fingerprint (arXiv:2603.27006). Zhang et al., OCR Hinders RAG / OHR-Bench (arXiv:2412.02592). Jeremy Howard / Answer.AI, llms.txt. agents.md. Cloudflare, Markdown for Agents. Anthropic, OpenAI, and Gemini docs on PDF and document processing.

Nvidia Is Buying the Part of AI Nobody Can pip install

Reid Marlow — Sun, 09 Aug 2026 16:20:41 +0000

Nvidia is reportedly putting up to $3 billion into Lancium, a Texas power-infrastructure developer tied to the Stargate data-center project. The reported structure is simple enough. An initial $2 billion buys roughly 20% of Lancium. Another $1 billion may follow if grid-connection milestones are hit.

That last clause is the useful part.

The AI industry has spent two years talking as if the bottleneck is model quality, GPU supply, or maybe memory bandwidth if the speaker has recently read a chip slide deck. Those all matter. But the Lancium deal is a reminder that the constraint is moving down the stack, into land, substations, interconnect queues, and power contracts.

You can buy GPUs and still not have compute.

Lancium is not just another data-center landlord. The company has been building power-heavy sites in Texas, including the Abilene campus associated with Stargate, the large AI infrastructure project backed by SoftBank, OpenAI, and Oracle. Reports put Lancium's land and power-connection portfolio at roughly a $10 billion enterprise value. The Decoder also noted that Lancium has about 4 gigawatts of power under contract in Texas and sites under development for up to 15 more gigawatts.

Those numbers are hard to make intuitive, so put it this way. A gigawatt is a city-scale unit. Once AI infrastructure deals start getting described in several gigawatts, the business is no longer just about who gets the next accelerator allocation. It is about who can turn electricity into usable, permitted, cooled, networked capacity before everyone else gets stuck waiting.

That is why Nvidia showing up here matters.

The old version of Nvidia sold picks and shovels. The newer version increasingly finances the mine, leases the trucks, and now appears to be buying a piece of the road to the mine. The company has already been entangled with huge data-center commitments through customer financing, leasing structures, and long-term capacity deals. A direct stake in power infrastructure is a different kind of hedge. It says the chip supplier is worried enough about the physical layer that it wants exposure to the scarce asset itself.

I do not read this as Nvidia trying to become a utility. That would be too neat, and probably wrong. Read it as supply-chain insurance. If your next generation of chips only matters when customers can energize buildings fast enough, then grid hookups become part of your go-to-market problem.

This is the unglamorous version of vertical integration.

A GPU launch can be streamed. A model benchmark can be tweeted. A transformer yard cannot be hand-waved into existence because the demo was good. Permitting takes time. Transmission queues are slow. Local politics can kill or delay projects. Power prices move. Water and cooling constraints show up. Every one of those boring constraints becomes a product dependency when the product is measured in megawatts per cluster.

Developers have a smaller version of this problem all the time. The impressive part of a system is often not the clever code path. It is the queue, the retry policy, the boring cron, the backup, the account permission, the thing that keeps working after the demo laptop closes. AI infrastructure is now learning the same lesson at industrial scale.

The funny part is that this makes Nvidia look less like a pure chip company and more like an allocator of scarce infrastructure slots.

If Nvidia has influence over which projects get chips, financing, and now power-adjacent capacity, then the competitive map changes. Labs with great model teams still matter. Labs and cloud providers with a clean path through power, land, financing, and construction get to run more experiments. That is a much less romantic race than AGI discourse, but it is probably closer to where the constraints are.

It also creates weird risk.

When a chip vendor sits inside the financing and infrastructure stack, customers get capacity sooner, but dependence gets thicker. A lab that relies on Nvidia for accelerators is already dependent. A lab that also relies on Nvidia-linked financing, Nvidia-backed data-center capacity, and Nvidia-adjacent power infrastructure has fewer exits if the relationship changes. Procurement turns into strategy. Strategy turns into lock-in.

There is a second risk, too. Power infrastructure is slow enough that bad demand forecasts become expensive in very physical ways. If AI demand keeps compounding, these deals look obvious in hindsight. If demand softens, or training economics shift, or inference gets more efficient faster than expected, the industry will be left with a lot of long-lived obligations around sites built for a particular appetite.

That does not mean the buildout is irrational. It means the bet is no longer confined to GPUs and model weights. It is now buried in leases, substations, power-purchase agreements, and grid queues.

For people building with AI, the practical takeaway is not that you need to care about every data-center deal. Most of us do not. The takeaway is that model access is going to be shaped by infrastructure choices we cannot see from an API page.

Why does one provider get cheaper inference in a region? Why does a model have great published capability but weird availability? Why do enterprise customers get capacity while smaller users wait? Some of the answer will be software. Some of it will be chip allocation. More of it than we like will be electricity and real estate.

That is the useful read on Nvidia and Lancium. The AI race still runs through chips. Now it also runs through everything a chip needs before it can do useful work.

The boring layer won again.