Idrees Patel

For two years the binding constraint on AI infrastructure was chip supply. Allocation decided who could build.

That has changed, and the reason is a mismatch in clock speeds.

Chip supply chains scale in months. Grid infrastructure scales in years. Interconnection queues, transformer manufacturing and utility capital planning all run on multi-year cycles, and none of them accelerated to match the demand curve.

The practical consequence reverses the old procurement logic. A facility with confirmed power and a later chip delivery date comes online sooner than one with chips in hand and no substation access. Deployment timelines are now set by interconnection dates and equipment delivery schedules.

The Uptime Institute has identified power as the single defining constraint on data centre growth globally. Gartner projects power shortages will restrict 40% of AI data centres by 2027.

One structural shift made this worse than the training-era forecasts assumed. Training is bursty; inference is continuous. As workloads shifted toward serving rather than training, data centre load moved from intermittent peaks to sustained high-wattage draw — a fundamentally harder ask of a grid.

Key Takeaways

• Of roughly 16 GW of US data centre capacity targeted for 2026, only about 5 GW entered active construction. The gap is not funding and not chips.
• ERCOT’s large-load interconnection queue grew from 63 GW to 226 GW in a single year. Queue position, not procurement, now sets deployment dates.
• Power transformers average 128-week lead times and generator step-up units 144 weeks. Transformers are under 10% of project cost and close to 100% of the blockage.
• Tokens per watt improved roughly a millionfold across six GPU generations. Aggregate demand rose faster, because efficiency creates demand rather than absorbing it.
• Within a fixed power envelope, efficiency stops being a cost optimization and becomes the only remaining growth lever.

Quick Navigation

The Numbers Behind the Data Center Power Gap

The 2026 figures are stark enough that they need no framing.

Set the last two rows against each other. More than $650 billion of committed capital, and the binding constraint is a piece of electrical equipment with a two-and-a-half-year queue.

The demand curve underneath is not slowing. Goldman Sachs Research projects US data centre power demand rising from 31 GW in 2025 to 66 GW by 2027. The IEA projects global data centre electricity consumption rising from 415 TWh in 2024 to 945 TWh by 2030.

Individual sites now approach 1 GW, with rack densities exceeding 100 kW for the newest training clusters. These are industrial loads arriving at distribution grids designed for something else.

The 4 Data Center Power Limits, Ranked

Four distinct constraints get compressed into the phrase “power shortage.” They have different causes, different timelines and different workarounds, so separating them is the useful move.

• Limit 1 — Interconnection queue position. A regulatory and study-process constraint. You cannot connect until the utility has studied your load and the transmission upgrades it requires.
• Limit 2 — Electrical equipment. A manufacturing constraint. Transformers, switchgear and batteries have multi-year lead times that no amount of capital shortens.
• Limit 3 — Generation capacity. A physics and permitting constraint. Even with a connection and equipment, the electricity must exist.
• Limit 4 — Delivery losses inside the facility. An engineering constraint. Power that arrives at the fence does not all reach the accelerators.

Limits 1 and 2 bind hardest right now. Limit 3 becomes dominant if the first two ease. Limit 4 is the only one an individual operator fully controls.

Data Center Power Limits 1 and 2: Queues and Equipment

The interconnection queue is the constraint most often misdescribed as a shortage. Nothing is physically absent; the process is saturated.

ERCOT’s large-load queue growing from 63 GW to 226 GW in a year is not a demand signal so much as a congestion signal. Lawrence Berkeley National Laboratory data shows median interconnection times having doubled since 2008, and analysts assess FERC Order 2023 reforms as unlikely to resolve the underlying physical capacity deficit before 2029.

Some markets have simply closed. Dominion Energy has stated it cannot accommodate additional large-load interconnection requests in Northern Virginia through 2030 — the densest data centre market in the world, effectively full for four years. PJM, the largest grid operator in North America, has already failed to procure adequate capacity in a recent auction.

Typical waits run 3–7 years against a data centre build cycle of 2–3 years. The queue is longer than the construction project it gates.

Electrical equipment is a genuine physical shortage. Transformers at roughly 128 weeks and generator step-up units at roughly 144 weeks, with some large-transformer lead times quoted at four years as of May 2026.

Domestic production expansion from Hitachi Energy and Siemens Energy is projected to come online no earlier than 2028, which means the shortage persists for at least two more years on current trajectories.

Limits 3 and 4: Generation and Delivery Loss

Generation capacity is the constraint waiting behind the other two. Interconnection reform and transformer capacity would move the bottleneck rather than remove it, because the electricity still has to be generated.

This is where the multi-year nature of the problem becomes unavoidable. New generation — gas, nuclear, renewable with storage — takes years to permit and build. The conditional small modular reactor pipeline grew from 25 GW at the end of 2024 to 45 GW by April 2026, which signals intent rather than delivered capacity, since none of it is producing electricity yet.

Delivery losses are the limit operators can actually act on. NVIDIA’s own analysis notes that at gigawatt scale, up to 40% of power can be lost before it reaches compute — through cooling inefficiency, conversion losses and traditional overprovisioning.

That figure deserves to sit next to the interconnection numbers. A site fighting for four years to secure an extra 100 MW may have comparable headroom available inside its own fence, obtainable through cooling and power-delivery engineering rather than a utility negotiation.

There is a tension worth naming: running closer to thermal and electrical limits recovers capacity and increases fault risk. Recovering that 40% is an engineering programme with real reliability trade-offs, not free capacity.

Why Cheap Parts Block Expensive Data Center Power Builds

Here is the disproportion that makes this era strange, and the single most quotable fact in the whole picture.

The binding constraint set — transformers, switchgear, batteries — represents less than 10% of project cost and close to 100% of the blockage.

Capital is abundant. More than $650 billion of 2026 AI infrastructure spend is committed across four companies. Semiconductors are available. Land is available. What is scarce is the unglamorous electrical equipment that converts capital into energized megawatts.

Two things follow that change how you read industry announcements.

1. Announced capacity is not deliverable capacity. A press release describes intent. Only the fraction with secured interconnection and equipment on order describes a plant that will exist. Roughly one in three tracked projects is under construction.
2. Money cannot compress the timeline. In most markets, capital shortens delivery schedules. A 128-week transformer queue does not respond to a higher bid, because the constraint is manufacturing throughput rather than price discovery.

This is where the physical layer meets the economic one — the stack of dependencies from silicon up to serving is mapped in the AI compute stack.

Does Efficiency Solve the Data Center Power Problem?

The obvious rebuttal: chips are getting dramatically more efficient. Does that not resolve this?

The efficiency gains are real and enormous. NVIDIA reports roughly a millionfold improvement in tokens per megawatt across six architecture generations, from Kepler in 2012 to Rubin in 2026 — from roughly one token per megawatt to near 900,000.

Aggregate demand still grew faster.

Google’s disclosed token volume ran from roughly 9.7 trillion per month in May 2024 to 480 trillion by I/O 2025, 1.3 quadrillion by October 2025, and 3.2 quadrillion by May 2026 — about 7× year over year. China reported roughly 140 trillion daily token calls by March 2026, around 1,000× early-2024 levels.

This is Jevons paradox operating at industrial scale. When the cost per unit of useful output falls, total consumption of the input rises, because demand responds to price. Every order-of-magnitude improvement in token cost opens a demand class that did not previously pencil.

Efficiency gains do not moderate aggregate power demand. They enable it.

But the individual-operator conclusion is the opposite of the macro one, and this is the part worth internalizing.

NVIDIA frames it as: Revenue = Tokens per Watt × Available Gigawatts.

If your available gigawatts are fixed by an interconnection queue you cannot jump, then the second term is a constant and tokens per watt is your entire growth curve. A chip that doubles tokens per watt doubles your output within an unchanged power envelope.

That reframes efficiency from a cost optimization into the only available growth lever — which is precisely why accelerator leadership has shifted from raw FLOPS to performance per watt. The hardware side of that shift is covered in memory bandwidth and the limits of AI chips.

How Operators Are Routing Around Data Center Power

Four strategies are visible in 2026, with different risk profiles.

1. Behind-the-meter generation. On-site gas turbines, fuel cells or dedicated renewable plus storage, bypassing the interconnection queue entirely. Fastest route to energized megawatts and the reason hybrid power deals are rising sharply. The trade-off is that you have become a power generation company.
2. Geographic arbitrage. Building where interconnection is available rather than where latency is optimal. Viable for training and batch inference, less so for latency-sensitive serving.
3. Acquiring position rather than building it. Buying sites with existing interconnection rights, or brownfield industrial locations with legacy heavy-load connections. Turns a four-year queue into a transaction.
4. Squeezing the existing envelope. Liquid cooling, higher voltage distribution, reduced overprovisioning, and accelerator generations with better tokens per watt. The only strategy with no external dependency.

A useful way to read the market: the first three compete for a scarce external resource, and the fourth does not. Operators that treat efficiency as an infrastructure strategy rather than a procurement detail have an advantage that does not require anyone’s permission.

What Would Ease the Data Center Power Constraint

A constraint worth taking seriously deserves an honest account of what would relieve it. Four things could, on different timescales.

• Permitting and queue reform. Federal legislation achieving substantial permitting reform and cluster-study acceleration would compress the process side of Limit 1. Analysts rate this low-confidence, because process fixes cannot substitute for physical grid expansion — but the queue is partly administrative, so partly addressable.
• Transformer manufacturing capacity. Hitachi Energy and Siemens Energy expansions are projected to come online no earlier than 2028. Trade arrangements unlocking additional imports could move this sooner. This is the most predictable of the four, because factory build-outs have published timelines.
• Demand moderation. If token growth slowed materially, existing supply would catch up. Nothing in current data suggests this. Google’s disclosed volumes are running near 7× year over year, and there is no sign of the curve bending.
• A shift in the binding constraint itself. If interconnection and equipment ease, the constraint moves to generation, which has its own multi-year timeline. Relief in one layer relocates the bottleneck rather than removing it.

The realistic read is that the equipment constraint eases from roughly 2028 and the interconnection constraint persists to around 2029, with generation becoming dominant after that. This is a decade-shaped problem rather than a cycle-shaped one.

Two caveats belong on all of it. Forecasts in this area have a poor track record, and several figures here — announced capacity, queue volumes, projected demand — are estimates from parties with a commercial interest in the number being large. And the constraint is regional rather than national: a market with headroom and a market that is full share a country and almost nothing else.

What Data Center Power Limits Mean for Buyers

Most readers are not building data centres. Four consequences reach anyone buying compute.

• GPU rental prices will not fall the way chip prices do. Supply is gated by energized capacity rather than manufacturing output. Falling per-token costs have so far increased total spend rather than reducing it, and anyone forecasting cheaper GPU-hours from cheaper tokens has the causality backwards.
• Capacity commitments are worth more than they look. Reserved capacity is a claim on a genuinely scarce resource. Priced against a market where roughly half of announced 2026 capacity may not materialize on schedule, reservations look different.
• Utilisation matters more, not less. If capacity is scarce and priced accordingly, an idle GPU wastes something with a four-year replacement lead time. The economics of that are set out in what inference actually costs per token.
• Regional availability will diverge. With Northern Virginia effectively closed to new large loads through 2030 and ERCOT’s queue at 226 GW, where you can buy compute will increasingly depend on which grids have headroom. Treat region as a capacity question, not only a latency one.

Primary sources

• IEA — Energy and AI
• Lawrence Berkeley National Laboratory — Queued Up interconnection research
• NVIDIA — Scaling token factory revenue and performance per watt
• Uptime Institute

Capacity and queue figures reflect reporting as of mid-2026 and change quickly. Lead times vary by equipment class and supplier; ranges are shown where sources differ.

Frequently Asked Questions

Keep reading

Here are the latest posts from the blog.

Alibaba’s Zhenwu V900 and the Memory Wall Behind a 500,000-Card Cluster

September 25, 2026

Alibaba’s T-Head published a spec sheet for the Zhenwu V900 on September 22 with two numbers on it and one conspicuous absence. The numbers are …

Read more

GPT-6 Sol vs Claude Opus 5.5: What the 50% Cut Misses

September 24, 2026

On September 22, 2026, Anthropic cut the price of its flagship Opus tier. Ninety minutes later, OpenAI halved the price of two GPT-6 models. Both …

Read more

Employee-Level Evaluator Access: The Security Problem Nobody Priced

September 23, 2026

A frontier lab hands an outside reviewer a badge, a laptop and a workspace. The reviewer’s job is to find what the lab’s own teams …

Read more

Pacing the Frontier: What It Actually Does to AI Chip Demand

September 22, 2026

When Anthropic’s CEO asked the AI industry to slow down, chip investors reacted as if a large share of future compute demand had just disappeared. …

Read more

The seductive number is the hourly rental rate. An H200 rents for roughly $3.10 to $3.80 per GPU-hour from the cheaper providers, which works out to about $2,300 to $2,800 a month running continuously.

Set that against a five-figure API bill and the conclusion looks obvious.

The conclusion is usually wrong, and it is wrong for a specific reason: the GPU rate prices one input to a system that has several. Nobody bills you separately for the rest, so they do not appear on any invoice you can point at.

That is what makes this failure mode persistent. An API bill is a single line item that captures the entire cost of the capability. A self-hosting bill is a single line item that captures perhaps a third of it, with the remainder distributed across salaries, unused capacity and outages that never get attributed back to the decision.

The per-token arithmetic underneath all of this — what a token costs to serve, and why that differs from what you are charged — is covered in what inference actually costs per token.

Key Takeaways

• Published break-even points for self-hosting range from 2 million tokens per day to 11 billion tokens per month. Both figures are defensible, because each assumes a different comparison API that the article usually does not name.
• Against a frontier API, one H200 breaks even around 0.5 billion tokens per month. Against a budget API, break-even requires 33 billion — more than four times what that GPU can physically produce.
• Self-hosting does not have a break-even point. It has a break-even point against a specific alternative, and the spread between them is roughly 123×.
• The raw GPU rate covers 20–40% of true cost. Credible estimates of the full multiplier cluster between 2.5× and 3×, with a defensible range of 1.3× to 5×.
• A GPU at 10% utilisation costs ten times as much per token as the same GPU at full load. Utilisation moves the answer more than hardware choice does.

Quick Navigation

The 5 Hidden Layers of Self-Hosted LLM Cost

Five categories sit outside the GPU line and account for most of the gap.

Layer 1 — Engineering time. Somebody configures the serving stack, tunes batching, manages model weights, handles version upgrades, and debugs the memory error at 2am. On a loaded engineering salary, a fraction of one full-time role can exceed the GPU rental itself. Teams without GPU operations experience typically need consulting or managed support through the first quarter.

Layer 2 — Idle capacity. APIs cost nothing when nobody is using them. A rented GPU bills identically at 3am on a Sunday and at peak load on a Tuesday. Production traffic is never flat, and the trough is billed at the same rate as the peak.

Layer 3 — Redundancy. One GPU is a single point of failure. Production reliability means a second instance, which doubles the hardware line before you have served a single additional token. APIs include redundancy in the quoted price.

Layer 4 — The surrounding infrastructure. Load balancing, monitoring, logging, model storage, networking egress, and the observability stack that makes any of it debuggable. Raw GPU costs represent roughly 30–40% of true infrastructure investment.

Layer 5 — Model refresh. Open-weight models improve every few months. Evaluating, migrating and re-tuning against a new release is recurring engineering work. On an API, the provider absorbs it and you get the improvement in a version string.

None of these are exotic. All of them are routinely omitted from the comparison that drives the decision.

What the Self-Hosted LLM Cost Multiplier Really Is

Published estimates of the total multiplier vary, and the variance is narrower than you might expect.

Applied to an H200 at $3.50 per hour — roughly $2,555 per month raw:

The rest of this article uses 2.5× — $6,388 per month — because it sits in the middle of the credible range. Substitute your own multiplier; the structure of the argument does not change.

The 5× figure typically reflects deployments with dedicated engineering, redundancy and low utilisation. The 1.3× figure typically reflects a well-utilized single GPU run by a team that already had the skills. Both are honest; they describe different situations.

Why Self-Hosted LLM Cost Break-Evens Disagree

Here is the finding that motivated this article.

Search for the break-even point and you will find, from credible 2026 sources: 2–5 million tokens per day. 5–10 million tokens per month. 100–256 million tokens per month. 500 million tokens per month. 11 billion tokens per month.

That is roughly a 2,000× spread across published figures.

They are not contradicting each other. They are answering different questions and rarely saying so.

Self-hosting does not have a break-even point. It has a break-even point against a specific alternative.

An API bill scales linearly with volume. A self-hosted bill is fixed. Break-even is where the line crosses the constant, and the slope of that line is entirely determined by which API you picked as the comparison.

Any article stating a break-even without naming the comparison model has left out the variable that determines the answer.

The Comparison API Decides Your Self-Hosted LLM Cost

Run the arithmetic. Fixed self-hosted cost of $6,388 per month, divided by each API’s blended rate at a typical 1,000-in/500-out request shape.

A 123× spread in break-even volume, driven entirely by the comparison choice. Same GPU, same cost model, same arithmetic.

This resolves the published disagreement completely. Analyses reporting low break-evens compared against frontier models. Analyses reporting high break-evens compared against budget or open-weight hosted APIs. Both were right about their own question.

The practical implication is uncomfortable for the usual framing. The decision is rarely “self-host or use an API.” It is “self-host, or use the cheapest API that meets our quality bar.” Managed open-weight providers occupy that middle tier, and they are the comparison that actually threatens the self-hosting case.

When Break-Even Is Physically Unreachable

Two rows in that table are worse than expensive. They are arithmetically impossible.

A single H200 sustaining 3,000 tokens per second at 100% utilisation produces about 7.88 billion tokens per month. That is a generous ceiling — it assumes continuous high-batch operation with no idle time, which no production workload achieves.

Compare that ceiling to the break-even requirements:

Against a budget API, one GPU cannot break even at any volume, because the volume required exceeds what the hardware can physically emit. Adding GPUs does not help — it raises the fixed cost proportionally, so the ratio holds.

The throughput ceiling is not a tuning problem. It follows from bandwidth divided by bytes moved per token, as set out in memory bandwidth and the limits of AI chips.

This is the single most useful check available before a self-hosting decision, and it takes two minutes: compute your break-even volume, compute your hardware’s physical ceiling, and confirm the first is smaller than the second.

Utilisation and Self-Hosted LLM Cost

Every figure above assumes the GPU stays busy. That assumption fails routinely.

A GPU at 10% load inflates per-token cost tenfold, converting an asset into a liability billed by the hour.

Production traffic has daily peaks, weekend troughs and quiet nights. Unless you are backfilling the gaps with offline batch work, average utilisation on a dedicated instance is frequently below 30%.

Note how this compounds with the multiplier. At 2.5× hidden costs and 30% utilisation, your effective cost is roughly 8× the raw GPU rate. That is the number to compare against an API bill, and it is not what appears on the rental invoice.

The honest test for self-hosting has never really been about model quality or hourly rates. It is whether you can keep the GPU busy.

When Self-Hosted LLM Cost Actually Wins

Three situations where self-hosting is the right answer, and they are narrower than the discourse suggests.

High, predictable volume against premium models. If you genuinely need frontier-class quality and run above roughly 0.5 billion tokens a month with steady traffic, the arithmetic favors you. One worked scenario: $36,000 of hardware against $7,500–15,000 of monthly frontier API spend breaks even in six to seven months.

Data residency and regulatory constraints. Healthcare under HIPAA, financial services under SOC 2, government contracts, and any deployment where data cannot leave your infrastructure. Here cost is not the deciding variable, and self-hosting can be correct at any volume.

Latency floors an API cannot meet. Network round-trip becomes material in a tight interactive loop. Local inference removes it.

Outside those three, the arithmetic usually points the other way. One analysis put it starkly: at 50 million tokens per day, a budget API cost around $2,250 per month while the same workload self-hosted on four A10G GPUs cost $5,175 — the “cheaper” route costing 2.3× more.

The sensible default sequence: start on APIs, move to a managed open-weight provider as volume grows, and consider owning hardware only when volume is predictable and the comparison at your quality bar still favors it. The layers this decision sits on top of are covered in the AI compute stack.

The Hybrid Option Most Comparisons Ignore

The debate is usually framed as a binary. It rarely is one in practice, and the middle options change the arithmetic more than any hardware choice.

Managed open-weight APIs. Providers serving Llama, Qwen, Mistral and similar models sit between frontier pricing and owned hardware, with blended rates commonly quoted around $0.09 to $0.44 per million tokens. You get open-weight economics without operating anything.

This tier is the reason so many self-hosting business cases collapse under scrutiny. Teams compare owned hardware against a frontier API, find a favourable result, and never test it against the managed provider serving the exact same open model they intended to host.

Complexity-based routing. Send roughly 70% of queries to a budget tier, 20% to mid, and 10% to frontier. Reported savings run above 80% with limited quality impact, because the hard queries still reach the strong model. This changes your blended rate, which changes your break-even, which may remove the case for self-hosting entirely.

Split by workload rather than by volume. Self-host the steady, predictable baseline where utilisation stays high. Burst to an API for peaks. This directly targets the utilisation problem — the fixed asset serves the flat portion of the curve, and the variable-cost provider absorbs the spikes that would otherwise sit idle between them.

Self-host only what needs it. Data residency requirements often apply to one workflow, not the whole product. Running a single regulated pipeline on owned hardware while everything else uses APIs is usually cheaper than treating one constraint as a mandate for the entire stack.

The sequencing that follows from all of this is unglamorous and reliably correct: prove the product on APIs, move to managed open-weight as volume grows, then own hardware only for the specific workloads where the arithmetic still favors it after you have named the real comparison.

Calculating Your Own Self-Hosted LLM Cost

Six steps. An afternoon’s work, and it beats any published break-even figure because it uses your numbers.

1. Name your comparison API. Not the most expensive one. The cheapest that clears your quality bar. This single choice moves the answer by two orders of magnitude.
2. Compute your blended rate. Take your actual input-to-output ratio and apply it to that API’s pricing. Headline input price will understate your bill by 1.4× to 2.7×.
3. Estimate your multiplier honestly. 1.3× if you have GPU operations skills in-house and will run one well-utilized instance. 3× or more with redundancy, dedicated engineering and variable load.
4. Check the physical ceiling. Bandwidth divided by bytes per token, times your expected utilisation. If break-even exceeds this, stop — the decision is already made.
5. Model your real utilisation curve. Not peak capacity. The average across a week including nights and weekends.
6. Re-run quarterly. Prices moved twice in the last six weeks alone on the API side, and GPU rates move with supply. A model built in February is stale by August.

One thing worth stating plainly: if the calculation comes out close, choose the API. A narrow margin does not survive the first outage, the first model refresh, or the first month someone leaves the team.

Primary sources

• Anthropic pricing
• OpenAI API pricing
• DeepSeek API pricing
• vLLM documentation

All break-even figures above are computed from the stated formulas using a $3.50/hour GPU rate and a 2.5× multiplier, and are shown in full so readers can substitute their own inputs. Published multiplier estimates vary; the range is shown rather than a single value.

Frequently Asked Questions

Keep reading

Here are the latest posts from the blog.

Alibaba’s Zhenwu V900 and the Memory Wall Behind a 500,000-Card Cluster

September 25, 2026

Alibaba’s T-Head published a spec sheet for the Zhenwu V900 on September 22 with two numbers on it and one conspicuous absence. The numbers are …

Read more

GPT-6 Sol vs Claude Opus 5.5: What the 50% Cut Misses

September 24, 2026

On September 22, 2026, Anthropic cut the price of its flagship Opus tier. Ninety minutes later, OpenAI halved the price of two GPT-6 models. Both …

Read more

Employee-Level Evaluator Access: The Security Problem Nobody Priced

September 23, 2026

A frontier lab hands an outside reviewer a badge, a laptop and a workspace. The reviewer’s job is to find what the lab’s own teams …

Read more

Pacing the Frontier: What It Actually Does to AI Chip Demand

September 22, 2026

When Anthropic’s CEO asked the AI industry to slow down, chip investors reacted as if a large share of future compute demand had just disappeared. …

Read more

There is one structural argument for this control, and it is worth stating precisely because everything else follows from it.

Input filtering must recognize the attack. Egress control does not.

A classifier watching for injection has to identify a payload it has never seen, phrased in a way its training did not anticipate, possibly in a language or encoding it does not handle well. Attackers iterate against it directly.

A blocked outbound request does not care. It fails whether the injection was a crude override instruction or an elegantly camouflaged paragraph of domain-appropriate prose. The control operates on what the attack was trying to accomplish rather than how it was written.

That property is rare in security, and it is why egress control keeps appearing at the top of practitioner recommendations rather than in the middle of a checklist.

The taxonomy of what you are defending against — eight distinct injection classes, only one of which arrives through the input box — is covered in prompt injection classes and what stops each.

Key Takeaways

• Egress control is the only prompt injection defence that works without recognising the attack. Input filters must identify a payload; a blocked outbound request fails regardless of how clever the injection was.
• Most implementations block one channel and call it done. There are at least seven, and the commonly-open ones include DNS, markdown image rendering, and query strings to allowlisted domains.
• Amazon Bedrock AgentCore’s Code Interpreter sandbox mode permitted unrestricted outbound DNS despite isolation claims, enabling bidirectional covert command-and-control, with no patch available as of March 2026.
• Markdown image exfiltration needs no tool call at all. The render is the attack, and it happens in the user’s browser rather than the agent’s sandbox.
• Egress control does not defeat destructive writes, fraudulent transactions, or misinformation. Those never leave the building.

Quick Navigation

The Lethal Trifecta and Which Leg to Cut

Simon Willison’s framing from June 2025 has become the field’s standard screening test, and it holds up.

An agent becomes an exfiltration weapon when three properties coexist:

1. Access to private data
2. Exposure to untrusted content
3. An ability to communicate externally

Each is individually benign. A system with all three can be turned by a single injected instruction.

Remove any one and the chain breaks. The question is which one you can actually remove.

Private data access is usually the point of the agent. Take it away and the product stops being useful.

Untrusted content exposure is also usually the point. An agent that reads email, browses the web, or processes documents is exposed by design.

External communication is the leg that most often turns out to be incidental. Many agents have network reach because containers have network reach by default, not because the task requires it.

Willison’s own conclusion is that removing the exfiltration ability is the preferred cut. That is the correct instinct — and the rest of this article is about why “block egress” is considerably harder than it sounds.

The 7 Exfiltration Paths Egress Control Must Cover

Here is the inventory. Most implementations cover the first two and stop.

The gap between rows 2 and 3 is where most real incidents live. A team adds a domain allowlist, tests that attacker.com is blocked, and reasonably concludes egress is controlled.

It is not. Five channels remain open, and several of them do not pass through the agent’s network stack at all.

Egress Control Channels Most Teams Block

The first two are worth covering briefly because they are the baseline, and because the standard configuration has known gaps.

Channel 1 —Direct HTTP from tool calls. The agent invokes a fetch or HTTP tool with an attacker-supplied URL. A default-deny policy with a task-specific allowlist handles this.

The standard pattern also blocks private ranges to prevent lateral movement, and specifically blocks the cloud metadata endpoint at 169.254.169.254, which is a favored credential-theft target.

Channel 2 — Non-allowlisted domains. Same mechanism, and the place where implementation detail matters more than teams expect.

Wildcard allowlists are the common failure. A policy permitting *.google.com has been bypassed by a hostname structured as attacker-host.com\x00.google.com — the null byte causes the sandbox’s parser and the resolver to disagree about where the hostname ends.

Two rules follow. Prefer exact hostnames over wildcards. And place enforcement below the agent harness — at an OS-level network namespace or a forward proxy at the container boundary — because a policy enforced inside the harness only covers tools the harness mediates. This is layer two of the four-layer model in sandbox isolation and the layers that contain failure.

Egress Control Channels Most Teams Miss

These five are where the work actually is.

Channel 3 — Query strings to allowlisted domains. The allowlist decides whether a request reaches a destination. It says nothing about what the request carries.

A prompt-injected fetch of a legitimate allowlisted target still encodes user data in the URL path or query string. If the attacker controls any page on an allowlisted domain, or can read that domain’s access logs, the data has left.

Channel 4 — Markdown and HTML image rendering. This is the one that surprises people most, because it bypasses the agent’s network stack entirely.

The agent emits a markdown image reference with sensitive data base64-encoded into the URL. The chat interface renders it. The user’s browser makes the GET request. Data arrives at the attacker’s server.

No tool call. No MCP server. No registered capability. The render is the attack. Your agent sandbox can be perfectly sealed and this channel still works, because the request originates from the client.

The variants worth testing are broader than markdown images: HTML img tags, CSS background-image, HTML5 media elements, hyperlinks with auto-preview, iframes and video. NVIDIA’s garak includes an XSS probe family covering these.

Channel 5 — DNS. Even a strict HTTP allowlist usually permits DNS resolution, because without it nothing works.

Researchers at BeyondTrust’s Phantom Labs demonstrated that Amazon Bedrock AgentCore Code Interpreter’s Sandbox network mode permitted unrestricted outbound DNS queries despite documentation describing complete isolation. The result was a fully bidirectional covert command-and-control channel capable of exfiltrating S3 contents, Secrets Manager credentials, PII and financial data. No patch was available as of March 2026.

DNS tunnelling is decades old. What is new is agent platforms marketing network isolation while leaving it open.

Channel 6 — Redirect chains. A static allowlist checks the first hostname. A trusted domain that returns a 3xx redirect to an attacker-controlled host bypasses the check unless the agent refuses to follow redirects.

Channel 7 — Non-harness subprocesses. An egress policy implemented in the agent framework covers tools the framework mediates. A subprocess that opens a raw socket or bundles its own HTTP client goes around it.

This connects to a related failure worth naming: allowlisted commands can be execution primitives. CVE-2026-22708, disclosed against Cursor, let an attacker poison the execution environment so that allowlisted commands such as git branch delivered arbitrary payloads. Separately, git -c core.hooksPath= or a git alias configured to shell out turns a git-only allowlist into arbitrary code execution.

As one analysis of that class put it, the allowlist made the attack easier rather than harder, because it auto-approved precisely the commands the attacker needed.

Where Egress Control Fails in Practice

Beyond the seven channels, three structural limits deserve honest treatment.

Covert channels below the URL layer. Academic work on agent egress reference monitors catalogues carriers that no domain allowlist addresses: data hidden in HTTP headers to allowlisted endpoints, timing side channels, least-significant-bit encoding in generated images, and audio-band encoding in synthesized speech. These are low-bandwidth and impractical for bulk theft. They are entirely adequate for credentials.

Enforcement placed above the sandbox. A domain-allowlisted network proxy is only as good as the isolation beneath it. One disclosed 2026 case chained a DLL sideloading issue with an undocumented flag to escape a Windows agent sandbox that ran an isolated VM with per-session unprivileged users, seccomp filtering, and exactly such a proxy. The proxy was correct; the boundary under it was not.

TLS inspection is expensive and brittle. Inspecting request contents rather than just destinations requires terminating TLS, which is operationally costly and fails in ways that are difficult to debug.

The practical conclusion is not that egress control fails. It is that a single-layer domain allowlist is a starting point rather than a solution.

What Egress Control Does Not Defeat

This is the qualification the headline claim needs, and skipping it would be dishonest.

The lethal trifecta models prompt-injection-driven exfiltration. It does not model the whole of agent security. Several serious outcomes never require anything to leave the building.

Destructive writes. An injected instruction that deletes records, drops a table, or corrupts a dataset is fully executed inside your perimeter. Egress control is irrelevant.

Fraudulent transactions. An agent with payment or transfer authority, redirected to move funds within permitted systems, is using authorized paths for an unauthorized purpose.

Misinformation to the user. An injection that causes the agent to give a false answer, misrepresent a document, or recommend a harmful action has already achieved its goal at the point of output.

Lateral movement inside the network. Blocking outbound internet does not stop an agent reaching internal services it should not touch. That requires network segmentation, not egress filtering.

Confused deputy against internal systems. An injected agent invoking a privileged internal tool on the attacker’s behalf never crosses the perimeter.

There is also a deeper point about why scope alone does not save you. In documented cases, the agent had permission for every individual step — reading the document, reading the customer data, making an outbound request. Grant that it needed each permission for its actual job and the attack still works, because it misuses paths the agent was right to have.

The breach came from the path the data took on the way out, not from excess access. That is the strongest argument for egress control and simultaneously the clearest statement of its scope.

The Real Cost of Egress Control

Strict egress allowlisting conflicts directly with agent utility, and pretending otherwise leads to policies that get disabled in week three.

Research and browsing agents cannot work through a tight allowlist. An agent whose job is to investigate arbitrary topics needs to reach arbitrary domains. You can restrict it to a curated index, and you have then built a different product.

Every new integration is allowlist maintenance. Scaling that across a fleet of agents is real operational overhead, and the pressure to add wildcards to reduce it is exactly how *.google.com policies happen.

Network controls fail in hard-to-debug ways. An agent that silently cannot reach a dependency produces confusing failures that look like model errors.

Two mitigations make this tractable.

Sealed tool endpoints. Rather than letting the agent author network calls, give it functions. A broker process holds the credential, makes the actual call against a fixed schema, enforces a per-tool egress allowlist, and returns only the parsed response. The agent never composes a URL, so URL-based exfiltration channels close structurally.

Trust-on-first-use secret binding. Rather than curating an allowlist manually, bind hashed secrets or canary tokens to the endpoints where they were first legitimately used, then alert and block on deviation. This removes most of the manual curation burden — and it depends on each agent having a distinct, traceable identity, as set out in why shared credentials are the real exposure.

How to Verify Egress Control Actually Works

Configuration is not verification, and the gap between them accounts for a striking share of documented failures.

Consider the pattern in the disclosed lab containment incidents of mid-2026. Environments documented as isolated were not. Prompts told models there was no internet access while the network stack said otherwise. In one case a model spent substantial effort searching for a route out and found one through infrastructure nobody had classified as an egress path.

Nobody had tested the claim. They had written it down.

Four tests, each doable in under a day.

Attempt egress from inside. Open a shell in your agent’s runtime and try to reach the internet by every method available — HTTP to an arbitrary host, DNS lookup of a domain you control, a raw socket. Anything that succeeds is a channel.

Use a canary domain with logging. Register a host, point it at a logging endpoint, and inject a benign instruction into a document your agent processes telling it to fetch that host with a marker string. If your access log records a hit, the path is open.

Test the render surface separately. As described above, generate each image-tag variant with unique URLs. This test exercises the client, not the agent, and it is the one teams skip because it does not feel like a network control.

Enumerate what counts as egress. Package installation is egress. A build step pulling from a registry is egress. A proxy cache is egress. In documented incidents, package registries were the exit route, not an oversight in the firewall.

Two operational notes make verification durable rather than a one-off. Instrument denied attempts and treat them as a signal, because a permissive configuration produces silence and silence reads as safety. And re-test after every dependency or infrastructure change, since egress paths are usually inherited rather than chosen.

The standard to hold yourself to: you should be able to state which of the seven channels are closed, how each is enforced, and when each was last tested. Anything less is a documented intention.

Building Egress Control That Holds

Seven steps, ordered by leverage.

1. Default deny, then allowlist exact hostnames. No wildcards. Block private ranges and the cloud metadata endpoint explicitly.
2. Enforce below the harness. OS-level network namespaces or a forward proxy at the container boundary. A policy inside the framework misses subprocesses.
3. Proxy every image URL in agent output. Rewrite to your own proxy with an allowlist, or strip. This is the pattern most production AI products converge on, and it closes the render channel.
4. Add a Content Security Policy with an img-src allowlist at the rendering layer as a second control on the same channel.
5. Restrict DNS. Route through a controlled resolver, log queries, and alert on high-entropy or high-volume lookups. Do not assume a sandbox blocks DNS because it claims isolation.
6. Refuse redirects on agent-initiated fetches, or re-validate the destination after each hop.
7. Test your own product for the render channel. Generate output containing each variant — markdown image, HTML img, CSS background, media elements, hyperlink autopreview, iframe — with unique URLs pointing at a host you control, render each surface, and watch your access log. Anything that arrives is an open channel.

That last step takes an afternoon and routinely finds something.

Primary sources

• Simon Willison — The lethal trifecta for AI agents
• Cloud Security Alliance — AI sandbox DNS exfiltration research note
• OWASP Top 10 for LLM Applications
• NVIDIA garak XSS probe family

Channel coverage assessments reflect commonly observed configurations rather than measured survey data. Verify each channel against your own deployment.

Frequently Asked Questions

Keep reading

Here are the latest posts from the blog.

Alibaba’s Zhenwu V900 and the Memory Wall Behind a 500,000-Card Cluster

September 25, 2026

Alibaba’s T-Head published a spec sheet for the Zhenwu V900 on September 22 with two numbers on it and one conspicuous absence. The numbers are …

Read more

GPT-6 Sol vs Claude Opus 5.5: What the 50% Cut Misses

September 24, 2026

On September 22, 2026, Anthropic cut the price of its flagship Opus tier. Ninety minutes later, OpenAI halved the price of two GPT-6 models. Both …

Read more

Employee-Level Evaluator Access: The Security Problem Nobody Priced

September 23, 2026

A frontier lab hands an outside reviewer a badge, a laptop and a workspace. The reviewer’s job is to find what the lab’s own teams …

Read more

Pacing the Frontier: What It Actually Does to AI Chip Demand

September 22, 2026

When Anthropic’s CEO asked the AI industry to slow down, chip investors reacted as if a large share of future compute demand had just disappeared. …

Read more

Agent observability makes an agentic system legible after the fact. State, decisions, tool calls — captured, replayable, auditable.

The vocabulary is borrowed from distributed systems: traces, spans, W3C Trace Context. The bending happens when you apply it to language model calls, because those are non-deterministic.

That single property breaks most of what traditional observability assumes.

In a conventional distributed system, the same input produces the same path. You debug by finding the divergence from expected behavior. With an agent, two runs of the same request may legitimately take different routes — different tools, different order, different number of steps.

So the question shifts. Not “did this behave as specified” but “what did it actually do, and can I reconstruct why.”

That reconstruction requirement is why this article exists. It is the shared dependency underneath every AI control worth having, and it is the one most commonly assumed rather than built.

Key Takeaways

• Agent observability is the unstated dependency underneath every other AI control. Detection, attribution, incident response, compliance evidence and cost attribution all fail without it. The OpenTelemetry GenAI semantic conventions are widely described as standardized. They are not. As of 21 August 2026 the dedicated conventions repository marks them Development with no official release. Two of the most visible LLM observability brands were acquired within a single quarter. Instrument to the convention, not to a vendor. A tool that logs prompt and response pairs is shipping log search. Real agent observability emits spans with tool calls, correlation IDs and full reasoning chains. In the disclosed lab containment failures of mid-2026, two of three affected organisations had not detected the activity at all.

Quick Navigation

Why Agent Observability Breaks Old Assumptions

Four specific assumptions fail when you move from services to agents.

Fixed call graphs. Traditional tracing assumes a service topology you can draw. An agent decides its own path at runtime, so the trace shape is an output rather than a design artefact.

Errors as the signal. In conventional systems, failures throw exceptions. An agent can complete successfully while doing entirely the wrong thing. A 200 response tells you nothing about whether the action was correct or authorized.

Latency as the metric. Response time matters, but token consumption, tool-call count and reasoning depth matter more for both cost and correctness.

Sampling by volume. Standard practice samples a percentage of traffic to control cost. For agents, the interesting traces are the rare ones — the long chains, the unusual tool sequences, the sessions where something went sideways. Uniform sampling systematically discards them.

The practical consequence: an observability stack that works well for your microservices will produce confident-looking dashboards about your agents while missing the failure modes that actually matter. This is the distinction between systems that generate output and systems that take actions.

The Four Signals Agent Observability Must Emit

The OpenTelemetry GenAI conventions define a minimum span shape. Grouped by what they let you answer, four signals matter.

Signal 1 — Model calls. Which model, which provider, which operation. The canonical attributes are gen_ai.provider.name, gen_ai.operation.name, gen_ai.request.model and gen_ai.response.model. Requested and served model can differ under routing, and that difference is worth capturing.

Signal 2 — Token usage. gen_ai.usage.input_tokens and gen_ai.usage.output_tokens, per call. This is the foundation of cost attribution, and per-call granularity is what allows cost per completed task rather than cost per month — the distinction that makes inference cost per token actionable.

Signal 3 — Tool calls. gen_ai.tool.name, plus arguments and results. Each tool invocation becomes a child span. This is the security-relevant signal: it is where an agent’s intentions become actions against real systems.

Signal 4 — Agent and correlation context. gen_ai.agent.name, gen_ai.agent.description, and W3C Trace Context correlation IDs binding the chain together across services and across agents.

The fourth signal is the one most implementations skip, and it is the one that makes the other three useful. Without correlation context you have a pile of individually well-formed spans and no way to reconstruct the sequence.

Agent-specific conventions covering tasks, actions, memory and agent-to-agent communication were drafted in 2025 and moved into experimental status through 2026. Framework-specific conventions for CrewAI, AutoGen, LangGraph and Semantic Kernel remain in active development.

The Agent Observability Standard Is Not Finished

This correction matters if you are planning around the standard, because a great deal of published material overstates its maturity.

The GenAI Special Interest Group has developed these conventions since April 2024. The semantic-conventions repository cut v1.40.0 in February 2026. In June 2026 the project moved GenAI, provider-specific and MCP conventions into a dedicated repository so they could version independently.

That repository marks the GenAI conventions as Development, and as of 21 August 2026 it has no official release. The gen_ai.* namespace remains experimental.

Two things follow, and they point in opposite directions.

Adopt anyway. OpenTelemetry itself graduated within CNCF in May 2026, which removes the project-maturity objection even if this particular namespace is unstable. Major vendors have already implemented — Datadog added native support in v1.37, Grafana collects LLM traces in Loki. The conventions are the closest thing to a neutral vocabulary that exists.

Pin your versions. Treat the conventions as a versioned contract rather than a stable API. Attribute names in an experimental namespace can change, and silent data breakage — where your dashboards keep rendering while the underlying field stops populating — is the failure mode to guard against.

The churn is concentrated at the edges: multimodal content, agent graphs, and MCP. Core model-call and token attributes are comparatively settled.

The Sorting Test for Agent Observability Tools

The term is widely misused, and there is a short test that sorts the market.

A tool that logs prompt and response pairs is shipping log search. That is a legitimate product and it is not agent observability. It cannot show you what tools were called, in what order, on whose authority, or where a chain went wrong.

Real agent observability emits OpenTelemetry-compatible spans with the GenAI conventions applied, supports multi-step trace reconstruction, and correlates across services.

Three questions to ask a vendor:

Do you emit OTel-compatible spans, or import them only? Import-only means you are locked in at the layer where portability matters.

Can I reconstruct a full agent chain, including sub-agent delegation? Multi-agent systems break most trace models, and this is where the gap shows.

What happens to my data if I switch backends? If the answer involves re-instrumenting your application, you instrumented to a vendor rather than a standard.

The platform landscape as of 2026 includes LangSmith from the LangChain team, Arize AI with its open-source Phoenix project, evaluation-first Braintrust, and AWS Bedrock AgentCore Observability. Datadog pulled LLM workloads into its existing APM footprint.

Why Every Control Assumes Agent Observability

Here is the argument that motivated this article. Take any AI control you have read about this year and follow it to its dependency.

Prompt injection defence assumes you can see what entered the model’s context and which tool call followed. Without per-call traces, a successful injection is indistinguishable from normal operation.

Containment. In the disclosed lab incidents of mid-2026, two of three affected organisations had not detected the activity at all. The evidence that reconstructed those events came from the labs’ own evaluation logs, not the victims’ monitoring — a pattern set out in how five labs lost containment.

Identity and attribution. Distinct agent identity only produces value if actions are logged against it. A perfect identity architecture with no trace layer answers “who could have done this” and never “who did,” as covered in why shared credentials are the real exposure.

Least privilege. Scoping permissions requires knowing which permissions are actually exercised. Teams without tool-call telemetry over-grant because they cannot see what would break.

MCP security. OWASP includes insufficient logging in its Top 10 precisely because most clients and servers log almost nothing by default.

Red teaming. Measuring attack success rates requires observing outcomes across many attempts. Without traces, you are counting your own attempts rather than measuring the system.

Compliance evidence. Contemporaneous, tamper-evident logs are the strongest available evidence tier. Policies and documentation rank below them.

Cost control. Cost per completed task requires per-trace token attribution. A monthly bill tells you what you spent, not whether it was productive.

The pattern is consistent. Research indicates roughly 47% of deployed agents are actively monitored, which is the constraint underneath the AI agent security gap. Every control in the list above is being recommended into environments where roughly half the agents emit nothing.

Agent Observability Costs You Have to Plan For

Three costs surprise teams, and each has a standard mitigation.

Storage volume. A single agent task can generate dozens of spans with full prompt and completion payloads. Traces are large compared to conventional application logs, and volume scales with reasoning depth rather than request count.

The mitigation is tiered retention: keep full payloads briefly, keep span metadata and structure far longer. Structure without payload still reconstructs the chain.

Evaluation cost. Running LLM-as-judge scoring over production traffic means paying for inference twice. Common practice samples 10–20% of traffic for evaluation, which balances quality coverage against spend.

Privacy exposure. Prompts and completions routinely contain personal data. Sending them to a third-party observability backend creates a data-protection question your instrumentation decision has already answered by default.

The mitigation is to sanitize at source — automated scrubbing inside the instrumentation wrapper, before the span leaves your process. Scrubbing at the backend means the data already crossed the boundary.

One design note worth stating plainly: sample for evaluation, not for observability. Evaluate a subset; trace everything. Dropping traces to save money removes exactly the rare sessions that justify having the system.

The Vendor Consolidation Problem

In January 2026 ClickHouse acquired Langfuse. In April, Cisco announced its intent to acquire Galileo. Two of the most visible LLM observability brands changed hands in a single quarter.

Neither acquisition is inherently bad for users. Both illustrate a structural risk.

Observability instrumentation is expensive to change. It touches every code path that calls a model or a tool. If your spans are emitted in a vendor-proprietary shape, switching backends means re-instrumenting the application — which in practice means you do not switch, and your negotiating position erodes accordingly.

The defence is straightforward and worth stating as a rule: instrument to the standard, treat the vendor as a detail.

Emit OpenTelemetry spans with GenAI conventions applied. Export via OTLP. Choose a backend that ingests that natively rather than one that requires a proprietary SDK. Then a backend change is a configuration change.

This argument gets stronger, not weaker, from the conventions being experimental. An unstable open standard you can version-pin is a better foundation than a stable proprietary schema you cannot leave.

What Agent Observability Cannot Do

A control worth having is worth stating the limits of, and three of these matter for planning.

Observability is detection, not prevention. A trace records that an agent deleted the records. It does not stop the deletion. Teams that instrument thoroughly and then treat the dashboard as a safeguard have bought visibility into harm rather than protection from it. Enforcement belongs at the gateway, in permission scoping, and in approval gates.

A complete trace does not mean a correct one. The hardest agent failures produce clean telemetry. Every span succeeds, every tool call returns 200, and the aggregate outcome is wrong — a specification-gaming failure where the agent pursued its objective through a route nobody intended. Nothing in the trace is flagged because nothing failed. Recognising this requires evaluating outcomes, not inspecting spans.

Volume defeats human review. An enterprise processing millions of agent actions cannot manually inspect traces. Without automated evaluation, anomaly detection and shape-based alerting layered on top, comprehensive tracing produces an archive nobody reads. The archive is still valuable after an incident; it does very little before one.

There is also a measurement subtlety worth naming. Instrumentation changes what it measures — capturing full prompt and completion payloads on every span adds latency and cost to the request path, and aggressive instrumentation of a latency-sensitive agent can degrade the experience you were trying to protect.

The workable position is layered. Trace comprehensively for reconstruction and evidence. Evaluate a sample for quality. Alert on behavioural shape rather than error status. And keep enforcement in a separate layer that does not depend on anyone reading a dashboard in time.

Building Agent Observability That Lasts

Six steps, ordered by dependency.

• Instrument every layer, not just the model call. Spans for LLM invocations, retrieval steps and tool calls. Attributing latency or cost to a step requires a span for that step. Auto-instrumentation packages exist for OpenAI, Anthropic, LangChain and LlamaIndex.
• Propagate correlation IDs across agent boundaries. W3C Trace Context is the mechanism. Without it, a multi-agent system produces disconnected traces and delegation chains cannot be reconstructed.
• Attribute every span to a distinct identity. Not a shared service account. This is what converts a trace into evidence.
• Define a single schema source of truth. One module holding every span name, attribute and metric, with no raw telemetry literals elsewhere in the codebase. A drift-detection test then catches divergence automatically.
• Sanitise before you store. Scrubbing belongs in the instrumentation wrapper, not the backend.
• Alert on shape, not just failure. An agent that suddenly takes twelve tool calls where it usually takes three has not errored. It has changed behavior, and behavioural drift is the signal that matters when success responses can accompany wrong actions.

A useful readiness check: pick a task your agent completed last week and reconstruct it end to end — which model, which tools in what order, how many tokens, who authorized it, what it touched. If you cannot, every control built on top of that agent is running on an assumption.

Primary sources

• OpenTelemetry semantic conventions repository
• OpenTelemetry GenAI documentation
• W3C Trace Context
• CNCF — OpenTelemetry graduation

Convention status reflects the dedicated GenAI conventions repository as of August 2026 and is changing actively. Verify current release status before relying on attribute stability.

Frequently Asked Questions

Keep reading

Here are the latest posts from the blog.

Alibaba’s Zhenwu V900 and the Memory Wall Behind a 500,000-Card Cluster

September 25, 2026

Alibaba’s T-Head published a spec sheet for the Zhenwu V900 on September 22 with two numbers on it and one conspicuous absence. The numbers are …

Read more

GPT-6 Sol vs Claude Opus 5.5: What the 50% Cut Misses

September 24, 2026

On September 22, 2026, Anthropic cut the price of its flagship Opus tier. Ninety minutes later, OpenAI halved the price of two GPT-6 models. Both …

Read more

Employee-Level Evaluator Access: The Security Problem Nobody Priced

September 23, 2026

A frontier lab hands an outside reviewer a badge, a laptop and a workspace. The reviewer’s job is to find what the lab’s own teams …

Read more

Pacing the Frontier: What It Actually Does to AI Chip Demand

September 22, 2026

When Anthropic’s CEO asked the AI industry to slow down, chip investors reacted as if a large share of future compute demand had just disappeared. …

Read more