← All Digest Entries

Daily Digest — June 29, 2026

June 29, 2026 Daily

[AI] The Government Is Now in the Model Release Business

Source: Morning Brew · TLDR · Semafor

The story: The US government forced Anthropic’s Mythos model offline earlier this month. On Friday, Commerce allowed Anthropic to restore Mythos access to “certain trusted partners.” The same day, OpenAI released GPT-5.6 to 20 government-approved recipients via Amazon Bedrock. OpenAI’s own statement pushed back: this process “should not become the long-term default. It keeps the best tools from users, developers, enterprises, cyber defenders, and global partners who need them.” Meanwhile, Zhipu AI’s GLM-5.2 — which matches Mythos on some benchmarks — is publicly available worldwide, including to US businesses. Austria formally invited Anthropic to relocate to the EU, offering “legal certainty, market access, capital, and a set of values that suits this company.”

My take: The US government just inserted itself as a gatekeeper into the frontier model release process, and the immediate result is a policy own-goal visible from space. The models being restricted are the ones American businesses, developers, and cyber defenders need. The models filling the gap face no such restrictions.

GLM-5.2 is open source and globally available. DeepSeek is globally available. The analyst note in Morning Brew is correct: banning AI models while continuing to sell semiconductor chips to China enables China to build competitive models. You’re restricting the output while subsidizing the input.

The “trusted partners” model is worse than full release or full restriction. It creates a two-tier AI market — large enterprises and government contractors get Mythos, everyone else gets whatever Chinese lab shipped last week. That’s not a safety outcome. That’s incumbency protection dressed as national security.

OpenAI’s pushback is self-interested but also correct. The honest version of the argument: if frontier AI is genuinely dangerous, the right response is safety infrastructure — evals, red-teaming, deployment guardrails — not access controls that apply only to US labs. Safety through restriction is security theater when the restricted models have open-weight equivalents that anyone can run locally.

Austria’s pitch is the tell. When a European country is recruiting your company because your own government is making it hard to operate, you have a policy problem. Anthropic won’t move. But the fact that the offer is credible enough to make news says something about where the US–EU AI policy gap currently sits.

The thing worth watching: Fable 5 is still restricted. Fable was publicly available for three days before the government pulled it and it was briefly the most powerful model in public hands. The administration is now managing a release cadence for private companies. That’s new, and it sets a precedent that will outlast this particular policy dispute.


[ENG] The Harness Is the Product

Source: Ahead of AI · Sebastian Raschka · TLDR

The story: Sebastian Raschka published a detailed tutorial on local coding agents using Qwen3.6 35B-A3B, Ollama, and Qwen-Code as alternatives to Claude Code and Codex subscriptions. The benchmark finding that mattered most: token usage is driven by the harness, not the model. Claude Code used roughly 578k input tokens but only 4.5k output tokens across 25 turns on the same task where Codex used a fraction of that. The difference isn’t that Claude writes more — it’s that the harness accumulates more context across turns, feeding previous messages, tool calls, command outputs, and file contents back into the prompt on every round. A second finding: Qwen3.6 35B performs better in Codex than in its own native Qwen-Code harness, scoring 5/5 vs 3/5 on a tool-reasoning benchmark.

My take: The coding agent market isn’t a model race. It’s a harness race. And the harness choices have a 10x cost multiplier embedded in them that most teams haven’t priced in.

The Claude Code vs Codex token gap is the clearest illustration. Same model, same task, 10x the input tokens in Claude Code. Not because Claude is thinking harder — because the harness is more aggressive about context accumulation. At $3-15 per million output tokens and 3-5x that for input on some providers, a harness that over-accumulates context isn’t just slower. It’s materially more expensive at scale. The cost engineering implication from two weeks ago lands here: the optimization layer should sit at the harness level, not just the model level.

The Qwen3.6-in-Codex finding is counterintuitive but important. The assumption that models are optimized for their native harness didn’t hold on this benchmark. Codex’s tighter context management produced better task outcomes with the same weights. Which suggests the benchmark isn’t measuring the model — it’s measuring the harness’s ability to keep the agent on task without drowning it in accumulated history.

This maps directly to SE Intel’s eval architecture. The faithfulness eval caught exactly this pattern: Claude dropped a retrieved “WinterCG” fact in roughly 50% of runs not because it didn’t retrieve it, but because the accumulated prompt context was noisy enough to push the relevant chunk out of effective attention. The fix was a grounding rule, but the underlying issue is context management — what goes into the prompt, in what order, at what point in the conversation. That’s a harness decision, not a model decision.

The local agent stack also closes the cost loop in a way relevant to the cost optimization thesis from Friday. At 30-40 tok/sec on a Mac Mini M4 with a 35B MoE model, the local option is now within striking distance of GPT-5.5 through a Pro subscription — at zero marginal token cost. The gap between “local is a toy” and “local is viable for production-adjacent workflows” closed faster than expected.


[BUSINESS] SpaceX’s Telecom Gambit

Source: Morning Brew · TLDR · Ars Technica · Financial Times

The story: SpaceX told IPO investors it’s considering launching a retail Starlink mobile service that would compete directly with Verizon, AT&T, and T-Mobile. COO Gwynne Shotwell raised the idea on the IPO roadshow. SpaceX has 65 MHz of spectrum; the three incumbents combined hold roughly 1,020 MHz. Analysts estimate building the required terrestrial infrastructure would cost billions. The company’s bond prospectus describes ambitions to “compete to be the preferred connectivity experience to our customers no matter where they are located, whether in rural, suburban or urban areas.”

My take: This is almost certainly a negotiating lever, not a launch plan. The spectrum math makes a competitive retail buildout nearly impossible in the near term. But the threat alone changes the negotiation.

SpaceX currently earns revenue from T-Mobile and others by letting them supplement their rural coverage with Starlink satellite access. The revenue-share terms aren’t public, but the structure gives the telecoms pricing power — SpaceX needs the distribution. Announcing on an IPO roadshow that you might build your own terrestrial retail network tells every telecom partner that SpaceX is willing to become a competitor if the revenue-share terms aren’t good enough. That’s a credible threat because SpaceX now has public-market capital and a proven infrastructure buildout machine.

The pattern is the same one Meta used for years with app developers: your platform is valuable until we decide to build what you built, at which point your leverage evaporates. SpaceX is applying that logic to its telecom partnerships. The incumbents’ response will be better revenue-share deals, not a competitive buildout race they’d likely lose.

The infrastructure landlord thesis from earlier this week extends here. SpaceX is already the landlord for AI compute (Colossus deals with Anthropic, Google, Reflection), orbital AI compute (Starmind), and satellite internet (Starlink). Adding wireless connectivity as a threat surface — even if never executed — makes SpaceX a more powerful counterparty in every negotiation it’s in. You don’t have to build the cellular network. You just have to make the telecoms believe you might.


[ENG] OpenAI Ships Private MCP Tunnel

Source: OpenAI Developers · Denys Kurylenko

The story: OpenAI shipped Secure MCP Tunnel — a way to connect private MCP servers to ChatGPT and Codex without exposing them to the public internet. The architecture is outbound-only: customers run a small open-source client inside their private network that establishes an outbound HTTPS connection to OpenAI. The client receives MCP requests, forwards them to the local server, and returns responses through the same connection. The MCP server never accepts inbound traffic. A companion feature called Harpoon extends the same model to private REST APIs — customers register labeled targets on the tunnel client, and OpenAI-side callers invoke those labels without the underlying API becoming public. The tunnel client is open-source so enterprise security teams can audit the code running inside their perimeter.

My take: This is the right architecture for enterprise MCP adoption, and it directly validates SE Intel’s Zero Trust framing.

The problem it solves is real. The most valuable MCP servers are the ones nobody wants to expose: internal CRMs, proprietary knowledge bases, customer data systems, compliance tooling. Every other solution to this problem — public endpoint, third-party tunnel, VPN peering — either weakens the security boundary or adds a new vendor to the trust chain. Outbound-only HTTPS with a customer-run client keeps the boundary intact. The server stays private. The client is inspectable. The connection is controlled.

The open-source client is the trust unlock for enterprise. A closed-source tunnel running inside a customer’s perimeter is an impossible security review. An open-source client that teams can read, audit, and verify is a different conversation. That’s not a small detail — it’s the difference between a product security teams approve and one they block at the firewall.

Harpoon is the more interesting primitive. MCP is the right abstraction for AI tools, but most enterprise data doesn’t live in MCP servers yet. It lives in REST APIs behind the same firewall. Harpoon extends the tunnel model to registered REST targets without making them broadly accessible — customers control what labels exist, what methods are allowed, and what the tunnel client is permitted to forward. That’s a scoped network bridge, not a VPN.

For SE Intel, this is the path for the MCP server in AGENTS.md. The MCP server is built, protocol-verified, and waiting to connect to Claude Desktop. The Secure MCP Tunnel pattern is exactly how that connection should work in a multi-tenant production context: the MCP server stays inside the customer’s environment, the tunnel client handles the OpenAI-facing path, and no private org data crosses a network boundary it wasn’t supposed to cross. The isolation architecture from Cycle 1 Week 1 extends naturally here — per-org tunnel endpoints, scoped tool access, the same JWT verification already in place.