Developers Digest

Grok 4.5 in 10 Minutes

Thu, 09 Jul 2026 04:08:38 GMT

Grok 4.5 Is Here: Benchmarks, Pricing, 500K Context, and Real CLI Demos The video reviews the newly released Grok 4.5 model from SpaceX AI, covering the announcement, benchmarks, pricing, and hands-o...

GitLost: How Researchers Tricked GitHub's AI Agent Into Leaking Private Repos

Developers Digest — Wed, 08 Jul 2026 00:00:00 GMT

Security researchers at Noma Labs disclosed a critical vulnerability in GitHub's Agentic Workflows feature that allows unauthenticated attackers to extract data from private repositories. The attack requires nothing more than posting a crafted GitHub Issue in any public repository within an organization. ## What Is GitLost? GitLost is the name researchers gave to a prompt injection vulnerability affecting GitHub's new Agentic Workflows system. The core issue: insufficient trust boundary enforcement between untrusted user input and AI agent instructions. When an organization enables Agentic Workflows with cross-repository access, the AI agent can read files from both public and private repositories. The problem is that the agent also processes the content of GitHub Issues - which anyone can create on public repos. ## How the Attack Works The attack chain is straightforward: 1. **Identify target**: Find an organization with GitHub Agentic Workflows enabled and cross-repository access configured 2. **Create malicious issue**: Post a GitHub Issue in any public repository within that organization 3. **Trigger the agent**: When the workflow assigns the issue, the AI agent activates 4. **Extract data**: Hidden instructions in the issue body direct the agent to fetch private repository contents 5. **Exfiltrate**: The agent posts the extracted data as a public comment The researchers demonstrated successful extraction of README files and code from private repositories, with the agent dutifully posting the contents as public issue comments. ## The "Additionally" Bypass One detail from the disclosure stands out. GitHub appears to have implemented guardrails to prevent obvious prompt injection attempts. The researchers found that adding the word "Additionally" to their payload bypassed these protections, forcing the model to reframe output rather than refuse. This highlights a fundamental problem with LLM guardrails - they are essentially more prompts, and prompts can be overridden with... more prompts. ## What HN Is Saying The Hacker News discussion (280+ comments at time of writing) is filled with developers debating whether this is a GitHub vulnerability or a user misconfiguration issue. One commenter framed the core problem clearly: > "Who thought having a LLM with access to private information, with public access to ask it questions, would ever be a secure process?" Several commenters pointed out this is analogous to setting up a CI job with access to secrets and running it on public PRs. If you configure GitHub to allow public code or LLM instructions to run in contexts with access to sensitive data, that data will leak. The discussion around guardrails was particularly pointed: > "LLM guardrails are either just written prompts as in 'Please do not bad stuff :(' or other LLMs verifying that the first LLM didn't do some bs. Both methods do not work sufficiently as time shows again and again." Another commenter offered a succinct take on the architectural issue: > "The answer is you should not allow LLMs access to untrusted input and sensitive data at the same time." A few developers noted that the proper fix is for GitHub to prevent agentic workflows from executing in a public repo context if they also have private repo access. Several mentioned they're moving to self-hosted alternatives like Forgejo. The SQL injection comparison came up repeatedly, with commenters pointing out a key difference: SQL injection is fully mitigated by prepared statements. There is no equivalent "prepared statement" solution for prompt injection. Read the full thread at [https://news.ycombinator.com/item?id=48827858](https://news.ycombinator.com/item?id=48827858). ## Why This Matters This vulnerability illustrates what security researcher Simon Willison calls the "Lethal Trifecta" - the dangerous combination of: 1. An AI agent with access to sensitive data 2. The ability to receive instructions from untrusted sources 3. The ability to take actions (like posting comments) Any two of these might be acceptable. All three together creates an exploitable system. GitHub's Agentic Workflows shipped with all three by default. Organizations that enabled cross-repository access effectively gave every GitHub user on the internet a channel to query their private repositories. ## Recommendations The researchers and HN commenters suggest several mitigations: **For organizations using GitHub Agentic Workflows:** - Review cross-repository permissions immediately - Restrict agentic workflows to private repos only, or remove private repo access entirely - Consider whether the workflow needs to respond to issue content at all **For anyone building AI agent systems:** - Never treat user-controlled content as trusted instructions - Minimize agent permissions to the absolute minimum required - Separate agents that handle untrusted input from agents with access to sensitive data - Implement hard permission boundaries, not just prompt-based guardrails **For the industry:** - Stop shipping AI features with maximum permissions by default - Recognize that guardrails are not security boundaries - Accept that prompt injection is currently unsolvable at the model layer ## The Bigger Picture This is not the first AI agent security incident, and it will not be the last. As one HN commenter noted, we are in "the wild west phase of agent usage." The pattern is now well-established: a company ships an AI feature with broad permissions, researchers find a prompt injection path, the company patches that specific attack, and researchers find another. The underlying architecture - mixing untrusted input with trusted instructions in the same context window - remains unchanged. Until the industry develops architectural solutions (not just guardrails) for separating instructions from data in LLM contexts, every agent system that processes untrusted input while holding sensitive permissions is a vulnerability waiting to be discovered. ## Sources - [GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos](https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/) - Noma Security - [Hacker News Discussion](https://news.ycombinator.com/item?id=48827858) - [Simon Willison's Lethal Trifecta Talk](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) - Referenced in HN comments

Kokoro: Local, CPU-Friendly TTS That Actually Sounds Good

Developers Digest — Wed, 08 Jul 2026 00:00:00 GMT

Local AI inference keeps getting more practical. Kokoro is an 82 million parameter text-to-speech model that runs entirely on CPU while producing surprisingly natural-sounding speech. It supports English, Mandarin, Hindi, and other languages with approximately 50 voice options. ## What Makes Kokoro Interesting The key numbers: - **82M parameters** - small enough for CPU inference - **~50 voices** - predominantly English speakers - **5GB Docker image** - includes pre-downloaded voice models - **OpenAI-compatible API** - drop-in replacement for existing integrations Performance varies by hardware but stays practical: - Intel Core i7-4770K: 4.7 seconds for a short paragraph - Apple M2 Pro: 4.5 seconds - AMD Ryzen 7 8745HS: 1.5 seconds These benchmarks are for CPU-only inference. If you have an integrated GPU, you can go faster - there's a `start-gpu_mac.sh` script for Apple Silicon. ## Quick Setup with Kokoro-FastAPI The easiest path is the containerized Kokoro-FastAPI wrapper: ```bash podman run -p 8880:8880 ghcr.io/remsky/kokoro-fastapi-cpu ``` Once running, you get a web interface at `localhost:8880/web` for testing, plus an OpenAI-compatible speech API. Applications built for OpenAI's TTS can point at your local endpoint instead. ## What HN Is Saying The Hacker News discussion (80+ comments) is largely positive, with developers sharing their real-world use cases. Multiple commenters are using Kokoro for home automation and voice assistants: > "I use kokoro with home assistant and its great. I find its the most natural sounding and small too. I speak over sonos speakers when certain events happen." Several developers have built article-to-podcast pipelines: > "About a month ago I setup Kokoro on my GTX1650 to do TTS for an article reader. A simple WebUI lets me paste a URL or a chunk of copy pasted text... Then for my morning drive I'll catch up on articles or blog posts I've gathered." One developer ported it to iPhone's ANE (Apple Neural Engine) for mobile TTS with better battery life: > "Cool I actually got it ported to iPhone's ANE finally yesterday! So we can get both rt natural local TTS and 4x less battery drainage and thermals" The comments also surface some practical limitations. Single words and short phrases can sound off: > "Try having it say simply 'six' and it almost always says something like 'ah-six-ah'. I found a way around that though. If you give it a longer sentence to say (eg 'The word is: six') it will say it fine." The commenter notes you can crop out just the word you need using the timestamp data Kokoro returns with each generation. Alternative models came up frequently. Pocket TTS from Kyutai Labs got several mentions for voice cloning. Supertonic 3 was praised for handling mixed-language text well: > "Supertonic 3 is the only one that can autodetect language and make a mix of different languages sound good." Read the full thread at [https://news.ycombinator.com/item?id=48821576](https://news.ycombinator.com/item?id=48821576). ## Practical Applications The HN thread includes several specific use cases worth noting: **Accessibility tools**: One developer uses Kokoro extensively for an accessibility product, appreciating the IPA pronunciation guides for handling homographs correctly. **Browser extensions**: Someone built a Chrome extension that runs Kokoro on any webpage with sentence highlighting: [Local Reader](https://chromewebstore.google.com/detail/local-reader-ai-on-device/fojpmmgbjcffadgoppmojnggkjhggimc) **Ebook audiobooks**: Multiple commenters use Kokoro to generate audiobooks from EPUBs when no official audiobook exists. **Japanese language learning**: Combined with an LLM, one developer built a local Japanese tutor with native-sounding speech. ## Alternatives and Comparisons The discussion surfaced several other local TTS options: | Model | Parameters | Voice Cloning | Notes | |-------|------------|---------------|-------| | Kokoro | 82M | No | Best CPU efficiency | | Pocket TTS | ~100M | Yes | Easy voice cloning | | Chatterbox Turbo | Larger | Yes | Emotional control | | Fish Audio S2 | Larger | Yes | Fine-grained tone control | | Piper | Various | No | Lightweight, fast | For pure CPU inference without voice cloning, Kokoro remains the standout choice. If you need voice cloning, Pocket TTS is the comparable-size option. ## The Bigger Picture Local TTS has reached a practical inflection point. A 5GB download gets you production-quality speech synthesis that runs on consumer hardware. Combined with local STT (Parakeet, whisper.cpp) and local LLMs, you can build voice interfaces that never touch the cloud. The quality is not quite ElevenLabs or Azure's DragonHD voices at peak performance. But it is good enough for most applications, and "good enough + completely private + zero marginal cost" is a compelling combination. As one commenter put it: > "Both Text-to-Speech and Speech-to-Text now have local models that are good enough to get the job done. Kokoro for TTS, Parakeet for STT and Fluid-1 for text formatting. I hope this is a trend that continues for other applications." ## Getting Started The fastest path to try Kokoro: 1. Run the container: `podman run -p 8880:8880 ghcr.io/remsky/kokoro-fastapi-cpu` 2. Open `localhost:8880/web` 3. Paste some text and generate For more control, check the [Kokoro-82M Hugging Face page](https://huggingface.co/hexgrad/Kokoro-82M) or the ONNX version at [NeuML/kokoro-base-onnx](https://huggingface.co/NeuML/kokoro-base-onnx) for custom pipelines. ## Sources - [Local, CPU-Friendly, High-Quality TTS with Kokoro](https://ariya.io/2026/03/local-cpu-friendly-high-quality-tts-text-to-speech-with-kokoro/) - Original article - [Hacker News Discussion](https://news.ycombinator.com/item?id=48821576) - [Kokoro-82M on Hugging Face](https://huggingface.co/hexgrad/Kokoro-82M) - [Kokoro-FastAPI](https://github.com/remsky/kokoro-fastapi) - [Pocket TTS](https://github.com/kyutai-labs/pocket-tts) - Alternative with voice cloning

Astro 7.0: Rust Compiler, Vite 8, and Up to 61% Faster Builds

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

Astro 7.0 shipped on July 7, 2026, and the release is all about speed. The framework rewrote its `.astro` compiler in Rust, upgraded to Vite 8 with the new Rolldown bundler, and introduced a faster rendering engine - resulting in build times that are 15-61% faster across their benchmarks. ## What Changed The performance story has three parts: **Rust-based .astro Compiler.** The parser and transformer that handles `.astro` files is now written in Rust. This isn't just a port - the new compiler enforces stricter HTML parsing rules, which is both a feature and a breaking change. **Vite 8 and Rolldown.** The biggest upstream change is [Vite 8](https://vite.dev/blog/announcing-vite8), which ships Rolldown - a Rust-based bundler that replaces both esbuild (for dev) and Rollup (for production) with a single unified tool. Rolldown is 10-30x faster than Rollup in benchmarks while maintaining API compatibility with existing Rollup plugins. **Satteri Markdown Pipeline.** Markdown and MDX processing now runs through [Satteri](https://satteri.bruits.org), a new Rust-powered pipeline that replaces the remark/rehype JavaScript stack. This is particularly impactful for documentation sites and blogs with hundreds or thousands of markdown files. **Queued Rendering Engine.** The internal rendering system has been replaced with a queue-based approach that's approximately 2.4x faster according to their benchmarks. ## Breaking Changes Worth Knowing The Rust compiler is stricter about HTML. Tags must be properly closed, and attributes must be properly terminated. The old JavaScript compiler would silently fix these issues; the new one throws errors. ```astro

Unclosed paragraph

Properly closed paragraph

``` Whitespace handling also changed. Newlines between inline elements no longer produce visible spaces, following JSX conventions: ```astro Hello World ``` ## What HN is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48821653) has 35 comments with a mix of reactions. **On the Rust rewrite.** One commenter joked about "awaiting the rewrite to assembly," but the response from Princesseuh (who built the Rust compiler and Satteri) was informative: "Crossing data between Rust and JS is inherently kinda slow (relatively), so there's a constant push and pull between flexibility and performance that's not always easy to reason about." **On the strict HTML enforcement.** This is the most debated change. One developer noted it "actively prevents upgrading sites which need to deal with remote content that is not written in strict HTML." The Astro team clarified this only affects `.astro` files - remote HTML loaded via `set:html` isn't affected. **On version velocity.** Multiple commenters noted Astro 7 arrived shortly after Astro 6, leading to upgrade fatigue. The team explained this was timing - Vite 8/Rolldown shipped right after Astro 6, and Vite major versions typically require an Astro major version due to deep integration. **On actual performance gains.** Not everyone saw improvements. Cassidy Williams (Astro's Head of Developer Experience) shared: "I upgraded my website recently and it's exciting! That being said, I admit my builds didn't get faster (they actually on average slowed down a bit)." The Astro team responded that performance gains are most visible on larger sites with thousands of pages, especially those using MDX. **On AI developer support.** Astro 7 added features specifically for AI coding agents: a background dev server mode (`astro dev --background`) with automatic agent detection, structured JSON logging, and a health endpoint at `/_astro/status`. One commenter called this "a good model" for how frameworks should support agent workflows. ## The Dependency Story An underappreciated change: Astro's dependency count dropped from 247 packages in v6 to 190 in v7. The unified ecosystem (remark, rehype, and their plugins) contributed a significant portion of the old count. Satteri consolidates much of this while maintaining the same AST format for plugin compatibility. ## Migration The upgrade path is straightforward for most projects: ```bash npx @astrojs/upgrade ``` The automated upgrade handles most migrations. The main manual work is fixing any strict HTML violations in `.astro` files - the compiler errors will point you to the specific issues. ## Why This Matters Astro has positioned itself as the default choice for content-heavy sites - marketing pages, documentation, blogs - where you want server-rendered HTML with minimal client JavaScript. The 7.0 release reinforces that position. The Rust investments are paying off. The JavaScript ecosystem has been trending toward Rust tooling for years (swc, esbuild, Rolldown, oxc, biome), and Astro is now part of that movement rather than just benefiting from it. The AI developer support is also notable. Frameworks don't typically ship first-party features for agent workflows, but Astro is betting that "Claude Code + Astro" will be a common stack for quickly building sites. ## Sources - [Astro 7.0 Release Blog](https://astro.build/blog/astro-7/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48821653) - [Satteri Documentation](https://satteri.bruits.org) - [Vite 8 Announcement](https://vite.dev/blog/announcing-vite8)

Better Auth Joins Vercel: What It Means for the Auth Ecosystem

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Better Auth Joins Vercel Announcement | [better-auth.com/blog/better-auth-joins-vercel](https://better-auth.com/blog/better-auth-joins-vercel) | | Better Auth Documentation | [better-auth.com/docs](https://www.better-auth.com/docs) | | Better Auth GitHub | [github.com/better-auth/better-auth](https://github.com/better-auth/better-auth) | | Vercel Blog | [vercel.com/blog](https://vercel.com/blog) | | Auth.js Documentation | [authjs.dev](https://authjs.dev/) | Better Auth, the framework-agnostic authentication library that grew from a side project to the default auth choice for many Next.js developers, is joining Vercel. The announcement dropped today and immediately hit the Hacker News front page. ## What Is Better Auth? Better Auth is an open-source authentication framework created by Bereket Engida. Unlike managed auth services, it runs in your own backend and lets you own your user data. It supports: - Multiple auth providers (OAuth, email/password, passkeys) - Multi-tenant organizations - RBAC and permissions - Database adapters for Postgres, MySQL, SQLite, MongoDB - Framework adapters for Next.js, Nuxt, SvelteKit, and more The project launched in September 2024 and quickly gained traction. It filled a gap left by Auth.js (formerly NextAuth.js), which many developers found difficult to extend for complex use cases like multi-tenant organizations. In a notable move, Better Auth recently acquired Auth.js/NextAuth.js itself - the library that Engida originally used before building Better Auth. ## The Vercel Acquisition According to the announcement, Vercel will provide resources for Engida to focus full-time on the open-source framework. The partnership also includes work on an "Agent Auth Protocol" for AI agent authentication - a timely focus as agentic workflows become more common. Vercel's post emphasizes that Better Auth will remain "open source, framework and platform agnostic." ## What HN Is Saying The Hacker News thread ([discussion link](https://news.ycombinator.com/item?id=48819512)) surfaced familiar tensions around open source acquisitions. **The skeptics showed up immediately.** One commenter wrote: "So, it's just a matter of time until they destroy this project in favour of their cloud interests." Another said they nearly used Better Auth recently and are "so glad I dodged the bullet." **The roll-your-own contingent made their case.** "Auth is not hard to roll yourself. Crypto: don't do it. Auth? Easy peasy," claimed one developer. Others pushed back hard, pointing out that auth extends far beyond username/password - you need account recovery, MFA, passkeys, registration flows, progressive profiling, SAML integration, and more. "You're distracted from your core application by feature requests for your login system." **KeyCloak got multiple mentions as the safer long-term bet.** It's a CNCF project, so there's no acquisition risk. But commenters noted it "shows its age" with a clunky interface and some uptime issues. **The Ory stack discussion got heated.** One developer complained that self-hosted Ory is "aggressively gimped" with SSO features locked behind licensing. An Ory team member responded defensively, pointing out that "open source development needs to be paid by someone." **Some developers see the upside.** "Better Auth is great, I use it for all my projects. Congrats to the team!" Multiple people noted that Better Auth already maintained next-auth security patches, so Vercel involvement could mean more resources for the ecosystem. **The LLM angle emerged.** One commenter joked about rolling auth with LLMs, prompting a reply: "It's one of those things you shouldn't trust LLMs to such an extent; that part should be very solid because the consequences of bad practices are getting to front page of hacker news." ## The Broader Pattern This acquisition fits a pattern we've seen repeatedly in the developer tools space. An open-source project gains traction by solving a real problem. The maintainer(s) get stretched thin between maintenance and monetization. A larger company acquires them, promising resources and continued open-source commitment. Sometimes it works out (React under Facebook, TypeScript under Microsoft). Sometimes the community feels burned (the Ory discussion in this thread provides a counterexample). The key question for Better Auth users: will Vercel keep the framework truly platform-agnostic? Better Auth's database adapters mean it's relatively easy to switch providers if things go sideways. But auth is deeply integrated into applications - migration is never painless. ## What This Means for Developers **If you're already using Better Auth:** The short-term outlook is positive. More full-time focus on the framework, no immediate changes to the open-source model. Watch for any dependencies on Vercel-specific features over the next 6-12 months. **If you're choosing an auth solution today:** - **Better Auth** remains a solid choice if you want to own your auth layer. The Vercel backing could mean better long-term maintenance. - **KeyCloak** (CNCF) is the safe choice if you want zero acquisition risk and need enterprise features like SAML/SCIM. - **Managed services** (Auth0, Clerk, FusionAuth) trade vendor lock-in for reduced maintenance burden. - **Roll your own** makes sense for internal apps or if you have specific requirements that libraries can't meet. ## My Take The acquisition makes strategic sense for Vercel. Auth is a pain point for Next.js developers, and owning the solution (plus the agent auth protocol work) strengthens their platform story. For the open-source ecosystem, the acquisition of Auth.js by Better Auth, followed by Vercel acquiring Better Auth, consolidates a lot of the JavaScript auth ecosystem under one roof. That's either efficient or concerning depending on your perspective. The HN thread reveals a real tension: developers want open-source solutions maintained by full-time engineers, but they're suspicious when money enters the picture. There's no easy answer here. Somebody has to pay for the work. Better Auth's framework-agnostic design and database adapter model mean you're not locked to Vercel's infrastructure. That's the right kind of portability to have when your auth provider gets acquired. ## Sources - [Better Auth Joins Vercel - Official Announcement](https://better-auth.com/blog/better-auth-joins-vercel) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48819512) - [Better Auth Documentation](https://www.better-auth.com/) - [KeyCloak - CNCF Incubating Project](https://www.keycloak.org)

GLM 5.2 and the AI Margin Collapse Thesis

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

## The Argument Martin Alderson's [post on the upcoming AI margin collapse](https://martinalderson.com/posts/the-upcoming-ai-margin-collapse-part-1-glm-5-2/) makes a straightforward economic argument: GLM 5.2 is the first open-weights model that genuinely competes with Opus and GPT on quality, and that changes the pricing math for frontier labs more than the DeepSeek moment did. The key distinction Alderson draws is between training cost disruption and inference cost disruption. DeepSeek's headlines were about training efficiency - doing more with less compute. But the margin pressure comes from inference, where frontier labs currently operate at roughly 90% gross margins on compute. When a credible alternative offers comparable quality at 50% or more discount, that margin becomes the opportunity. **Last verified:** July 7, 2026. ## What the Post Actually Claims Alderson's core numbers: - **GLM 5.2 inference runs around $4.40 per million tokens** through providers like Z.ai and Fireworks - **Frontier models (Opus, GPT-5.5) price at roughly $25 per million tokens** with estimated 90% gross margin on compute costs - **Even accounting for higher token usage**, GLM 5.2 likely delivers comparable workflows at 50%+ savings - **Switching costs are minimal** - both Z.ai and Fireworks offer OpenAI and Anthropic-compatible endpoints The thesis is not that GLM 5.2 is better than Opus. Alderson explicitly notes the gaps: no native vision support, slower response times for interactive use, excessive thinking tokens that inflate costs, and weaker web search through available MCPs. The argument is that for many tasks, these gaps do not matter enough to justify a 2-5x price premium. ## What the HN Thread is Saying The [discussion on Hacker News](https://news.ycombinator.com/item?id=48809877) (300+ comments, 500+ points) is running hot on a few axes. **On quality parity:** The thread is split. One commenter puts it directly: "Complex tasks, poorly-defined tasks, sure [Opus wins]. For relatively simple tasks, though, or very well-defined tasks, it's just as good and usually a lot faster." Another notes that GLM 5.2 "sits somewhere between Sonnet 5 and Opus 4.8, better than DeepSeek V4 Pro for sure." The consensus seems to be that GLM 5.2 is Sonnet-tier, not Opus-tier - which is still meaningful for cost discussions. **On speed:** Several commenters flag that speed is underrated in these comparisons. One asks "which are the fastest frontier models?" and notes that "somehow no one talks about LLM speed." GLM 5.2 has a Fast variant at 200-400 tokens per second, and OpenAI's upcoming 5.6 served through Cerebras promises 750 tokens per second. Speed improvements at lower tiers could matter as much as price. **On subscription economics:** A user who actually ran the numbers on Z.ai's Pro subscription ($50/month) reports hitting 60% of weekly limits in one day with parallel code review agents. "Their Max (100 USD) subscription would last me the whole week, but so does Anthropic for the same money." The per-token arbitrage is real, but subscription tiers can narrow the gap depending on usage patterns. **On refusals:** Multiple commenters note that GLM 5.2 has fewer refusals than Opus, which "is always 'Let me push back on that...'" For certain use cases - security testing, game modding, reverse engineering - this is a real functional difference, not just a policy preference. **On data privacy:** The thread acknowledges the elephant: Z.ai has mainland China connections. One commenter mentions that "alternative providers with proper contractual terms" exist, and on-premises deployment via open weights enables sensitive-data processing. But for enterprise accounts with compliance requirements, this is not a trivial detail. ## Why This Matters for Developers The margin collapse thesis is ultimately about optionality. If you are locked into Opus for everything, you are exposed to pricing power that may not reflect compute economics. If you can route tasks to GLM 5.2 (or DeepSeek V4, or Qwen 3.6) when quality is sufficient, you capture the spread. The practical takeaway from both Alderson's post and the HN discussion: 1. **Test GLM 5.2 on your actual workflows.** The benchmark delta is narrow (Sonnet-tier vs Opus-tier), and task-specific performance varies. Many commenters report satisfactory results with "max thinking" mode. 2. **Factor in speed.** If you are running interactive loops where latency compounds, the 200-400 t/s Fast variant or the upcoming Cerebras-backed OpenAI models might matter more than per-token price. 3. **Watch subscription math.** Per-token arbitrage is real at scale, but subscription tiers can close the gap for moderate usage. Run the numbers on your actual consumption patterns. 4. **Consider refusals as a feature delta.** If Opus is blocking legitimate security research or domain-specific queries, GLM 5.2's lighter filtering is a functional difference, not just a policy one. 5. **Plan for the margin compression regardless.** Whether it is GLM 5.2 specifically or the next open-weights model, the trend is clear: inference margins will compress, and frontier labs will need to differentiate on features (vision, speed, tool use, reliability) rather than quality alone. ## The Bezos Principle Alderson ends with a reference to Bezos's line: "Your margin is my opportunity." The implication is that someone will exploit the gap between frontier lab pricing and open-weights compute costs - if not Z.ai, then a Western provider serving the same weights with proper compliance. For developers, the actionable insight is simpler: the price of intelligence is falling, and the pricing power of any single provider is weaker than it was six months ago. Build your systems to route across providers, and you capture the upside regardless of which specific model wins. Part 2 of Alderson's series, which will explore competitive positioning implications, is reportedly coming soon. ## Sources - [Martin Alderson: GLM 5.2 and the coming AI margin collapse](https://martinalderson.com/posts/the-upcoming-ai-margin-collapse-part-1-glm-5-2/) - [Hacker News discussion](https://news.ycombinator.com/item?id=48809877) - [Z.ai Vision MCP docs](https://docs.z.ai/devpack/mcp/vision-mcp-server) - [ZCode harness](https://zcode.z.ai/en) ## FAQ ### Is GLM 5.2 as good as Claude Opus for coding? The HN consensus places GLM 5.2 between Sonnet 5 and Opus 4.8 - strong for well-defined tasks, weaker on complex or ambiguous work. Test on your actual workflows rather than relying on benchmarks alone. ### What are GLM 5.2's main limitations compared to frontier models? No native vision support, slower response times for interactive use, excessive thinking tokens that inflate costs, and weaker web search through available MCPs. Z.ai offers a Vision MCP workaround for the first gap. ### Is it safe to use GLM 5.2 for enterprise work? Z.ai has mainland China connections, which may raise compliance concerns. Alternative providers with Western hosting and proper contractual terms exist, and the open weights enable on-premises deployment for sensitive data. ### How do subscription costs compare between Z.ai and Anthropic? Z.ai's Pro ($50/month) and Max ($100/month) subscriptions have usage limits that heavy agentic workloads can hit quickly. One commenter reports comparable weekly capacity to Anthropic's Max plan. Run the numbers on your specific usage patterns.

Harness Engineering and the Path to Self-Improving AI

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [Harness Engineering for Self-Improvement](https://lilianweng.github.io/posts/2026-07-04-harness/) | Lilian Weng's essay (July 4, 2026) on why the harness - not the weights - is the near-term path to recursive self-improvement | | [ACE: Agentic Context Engineering](https://arxiv.org/abs/2510.04618) | Treating context as an evolving playbook via a generator, reflector, and curator | | [ADAS: Automated Design of Agentic Systems](https://arxiv.org/abs/2408.08435) | A meta-agent that programs new agent workflows in code and keeps an archive of solutions | | [Darwin Gödel Machine](https://arxiv.org/abs/2505.22954) | Agents that empirically rewrite their own harness code and validate on SWE-bench | | [AlphaEvolve](https://arxiv.org/abs/2506.13131) | Evolutionary search where a frozen LLM proposes diffs against marked code blocks | Lilian Weng's new essay makes a claim that cuts against most of the "the models will rewrite themselves" hype: recursive self-improvement is coming, but **it won't start with weights**. It starts with the harness - the software wrapped around a base model that decides how it thinks, what tools it calls, what it remembers, and how its work gets judged. If you build agents for a living, this is the most useful framing of 2026 so far. The thing you already control - the scaffolding - is the same thing that improves first. **Last verified:** July 7, 2026. ## What a harness actually is Weng defines a harness as "the system surrounding a base model that orchestrates execution and decides how the model thinks and plans, calls tools and acts, perceives and manages context, stores artifacts, and evaluates results." That is broader than "agent framework." It includes workflow design, evaluation, permission controls, and persistent state - the boring plumbing that determines whether a capable model produces reliable work or expensive slop. Every [coding agent](/blog/what-is-an-ai-coding-agent-2026) you use - Claude Code, Codex, OpenCode - is a harness. They've quietly converged on the same interface: file discovery, read and edit, shell execution, external context, artifact handling, backend jobs, and subagent delegation. ## The three patterns that make it work Strip away the research names and modern harnesses share three moves. ![The harness loop: plan, execute, observe, improve, with a persistent file layer](/images/blog/harness-engineering-self-improvement/inline-1.webp) **Workflow as a goal-oriented loop.** Plan → execute → observe/test → improve → iterate until the goal is met. The Codex agent loop is the canonical example, and it's the same shape whether the goal is "fix this bug" or "reproduce this paper." **The file system as persistent memory.** Instead of dragging the whole workflow through the context window, the harness writes durable state to disk: experiment logs, code diffs, paper summaries, error traces, past rollout trajectories. This is how [long-running agents survive context limits](/blog/long-running-agents-need-harnesses) - and why [token budget is a harness design problem](/blog/harness-engineering-token-budget), not just a billing line. **Subagents and backend jobs.** The harness spawns parallel workers, but keeps the parallelism explicit and inspectable - outputs land as files and logs so the run can recover after an interruption. That "leave receipts" discipline is exactly what separates [a real agent swarm from a demo](/blog/agent-swarms-need-receipts). ## How the harness starts improving itself Here's where it gets recursive. If the harness is code, and a coding agent can write code, then the agent can rewrite the harness. A whole research literature is now doing precisely that: - **[Agentic Context Engineering (ACE)](https://arxiv.org/abs/2510.04618)** treats context as an evolving playbook. A *generator* produces trajectories, a *reflector* distills lessons, and a *curator* merges structured bullets - with IDs, deterministically - so the context grows without collapsing into mush. - **ADAS** and **AFlow** automate workflow discovery itself: ADAS uses a meta-agent to program new agents in code and archive them; AFlow represents workflows as graphs and searches them with Monte Carlo Tree Search. - **STOP** (Self-Taught Optimizer) recursively improves its own scaffolding and rediscovered tricks like genetic algorithms and prompt bandits on its own. The catch matters: it *improved* results on GPT-4 and *degraded* them on weaker models. Recursion needs a strong base. - **AlphaEvolve** and the **Darwin Gödel Machine** go further - evolutionary pools of candidate programs, with the DGM rewriting its own agent codebase and matching handcrafted agents on SWE-bench Verified. The pattern across all of them: [self-improvement is a search problem](/blog/self-improving-ai-agents), and the harness is the search space. ## The evidence is still thin Weng is careful not to oversell it, and the benchmarks back her up. On **PaperBench** (replicate 20 ICML 2024 papers), the best models reach ~21% against ML PhDs. On **MLE-bench** (75 Kaggle competitions), the best setup hits bronze-medal level just 16.9% of the time. On **RE-Bench**, humans still score non-zero in 82% of open-ended ML research attempts. Autonomous research works in narrow, verifiable slices - not end to end. ## Seven things standing in the way The heart of the essay is a sober list of why full [recursive self-improvement](/blog/recursive-self-improvement-fable-5) isn't here yet. ![Seven bottlenecks: fuzzy evaluators, memory lifecycle, negative results, diversity collapse, reward hacking, long-term cost, human role](/images/blog/harness-engineering-self-improvement/inline-2.webp) The one that should worry builders most is **weak evaluators**. Self-improvement loops are only as good as the signal they optimize, and "research taste, novelty, and long-term scientific value are much harder to measure" than a passing test suite. Pair that with **reward hacking** - loops that game whatever signal you give them - and the design rule writes itself: your evaluator and your permission controls should sit *outside* the loop, on held-out tests and human review, or the agent will optimize the referee instead of the game. The rest rhyme with anything you've shipped: context that degrades over long horizons, a training bias toward success that makes models bad at admitting failure, evolutionary loops that collapse to one solution, optimization that ignores maintainability and migration cost, and the human who needs to move *up* the stack without leaving the loop. ## What this means if you're building agents You don't need a Darwin Gödel Machine to use any of this. The near-term, practical reading: 1. **Invest in the harness, not just the prompt.** The loop, the file-backed memory, and the tool surface are where reliability actually lives. 2. **Make everything leave receipts.** Logs, diffs, and trajectories on disk are what let an agent recover, and what let *you* evaluate whether it's improving. 3. **Keep the evaluator honest and external.** Held-out tests and human review are the only defense against a loop that learns to cheat. 4. **Treat context as a curated artifact,** not an ever-growing transcript. The ACE playbook idea - structured, deduplicated, ID'd entries - is something you can apply today with [plain context engineering](/blog/context-engineering-guide). The takeaway is oddly empowering. The frontier of self-improving AI isn't locked inside a training run you can't touch. It's the scaffolding on your own machine - and harness engineering is a skill you can start compounding now. ## FAQ ### What is a harness in AI? A harness is the software system wrapping a base model that orchestrates how it plans, calls tools, manages context and memory, stores artifacts, and evaluates results. Coding agents like Claude Code and Codex are harnesses. ### How is a harness different from an agent framework? An agent framework is one piece. A harness is broader - it also covers evaluation, permission controls, persistent state, and workflow design, all the machinery that turns a capable model into a reliable system. ### Why does self-improvement start with the harness instead of the weights? Because the harness is code an agent can already read and rewrite, and its behavior can be validated empirically. Rewriting weights needs training infrastructure and reliable reward signals we largely don't have yet. ### What's the biggest blocker to recursive self-improvement? Weak and fuzzy evaluators. Without fast, precise verifiers, a self-improvement loop has no honest signal to optimize - and tends to hack whatever proxy you hand it. ## References - Lilian Weng, [*Harness Engineering for Self-Improvement*](https://lilianweng.github.io/posts/2026-07-04-harness/), 2026 - [ACE: Agentic Context Engineering](https://arxiv.org/abs/2510.04618) - [ADAS: Automated Design of Agentic Systems](https://arxiv.org/abs/2408.08435) - [AFlow: Automating Agentic Workflow Generation](https://arxiv.org/abs/2410.10762) - [STOP: Self-Taught Optimizer](https://arxiv.org/abs/2310.02304) - [AlphaEvolve](https://arxiv.org/abs/2506.13131) - [Darwin Gödel Machine](https://arxiv.org/abs/2505.22954) - [PaperBench](https://arxiv.org/abs/2504.01848) · [RE-Bench](https://arxiv.org/abs/2411.15114) · [MLE-bench](https://arxiv.org/abs/2410.07095)

Ilya Sutskever's 30 Papers: The Reading List That Covers 90% of What Matters

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

Back in 2022, Ilya Sutskever reportedly gave John Carmack a list of roughly 30 research papers with the advice: "If you really learn all of these, you'll know 90% of what matters today." The list was never officially published. Someone on Twitter compiled a speculative version in 2024. Now a first-year CS student at Trinity College Dublin has built [30papers.com](https://30papers.com) to make that list more accessible with plain-language explanations. The project hit the Hacker News front page with 271 points and a discussion that's equal parts appreciation, skepticism about the list's authenticity, and complaints about the website's animations. ## What's on the List The 30 papers span the foundations of modern deep learning: **Neural network fundamentals:** - CS231n (Stanford's visual recognition course) - ImageNet Classification with Deep CNNs (AlexNet, 2012) - Deep Residual Learning (ResNet) - The Unreasonable Effectiveness of RNNs (Karpathy's famous blog post) - Understanding LSTM Networks (Colah's explanation) **Attention and transformers:** - Neural Machine Translation by Jointly Learning to Align and Translate - Attention Is All You Need - The Annotated Transformer (Harvard's implementation guide) **Scaling and training:** - Scaling Laws for Neural Language Models - GPipe: Pipeline Parallelism for Training **Theory papers:** - Kolmogorov Complexity and Algorithmic Randomness - A Tutorial Introduction to the Minimum Description Length Principle - Quantifying the Rise and Fall of Complexity in Closed Systems (The Coffee Automaton) The theoretical papers are what make this list distinctive. They're not standard deep learning curriculum - they're information theory and complexity theory papers that connect to Ilya's thesis that learning is compression. ## The Compression Thesis Several HN commenters picked up on why the Kolmogorov complexity papers are included. As one explained: "Ilya argues that the reason why neural networks generalize - why they work at all - is because they are effectively finding a simple description of their training data, converging down onto the limit of the Kolmogorov complexity." Another linked this to Solomonoff induction, which "combines Kolmogorov complexity with Bayes rule to provide a general framework for inductive inference, and naturally formalizes Occam's razor." This is the reading list's hidden curriculum: the papers don't just teach you how to build neural networks, they explain why they work. Good models compress their training data; bad models memorize it. ## What HN is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48819608) raised several concerns. **Is this actually Ilya's list?** Multiple commenters questioned the provenance. One noted: "Someone posts on X, 'These are Ilya's 30 papers', gives no source, doesn't say where he got it from, and isn't connected to either Ilya or Carmack. Then someone vibe codes a barely usable website based on that, and it lands on the HN front page?" The author acknowledged this on the site: "rumoured list of papers that Ilya Sutskever gave to John Carmack." Whether it's the exact list or a reasonable reconstruction, the papers themselves are canonical - these are the foundational works in deep learning. **The UX is rough.** The site features heavy animations with scrolling effects. Multiple commenters reported headaches and dizziness: "I scoffed at your comment and went to the website. After scrolling a bit, I find myself having a mild headache and slight dizziness." The technical issues are more severe. LaTeX formulas render incorrectly with flattened subscripts and superscripts. Images and tables don't render at all. One commenter posted the direct paper links as a service to others. **The format question.** A core debate: what value does the site add? One commenter asked: "Is it just rehosting the list, plus a reformatted copy of the papers? I was hoping you'd have at least annotated them with what you'd learned?" The author, a first-year CS student, explained his motivation: "When I was getting into reading research papers I ended up burning a ton of my Claude usage asking questions other people have probably already asked." The site hosts papers with inline plain-language explanations of difficult terms - essentially baking in the questions you'd ask Claude. **Reading order matters.** Several people noted the list isn't ordered for learning: "The paper introducing the attention mechanism probably ought to precede 'Attention Is All You Need.'" This is a reasonable critique - the list was given to Carmack, who already had significant ML background. ## The Meta-Commentary The discussion produced a useful perspective on curated reading lists in the LLM era: "Compiled resources for nerds are catnip. Hit that bookmark/upvote button to never get to it :)" There's truth here. The list has circulated for years, spawned multiple GitHub compilations, and even a [Manning book](https://www.manning.com/books/sutskevers-list). Most people who bookmark it won't read the papers. But that's always been true of reading lists. What's different now: you can actually process these papers efficiently. Tools like Claude, NotebookLM, and various PDF-to-audio services make it practical to work through dense research. One commenter even shared their own tool for generating teacher-style audio explanations of papers. ## The Actual Links For those who just want the papers without the animations: - [CS231n](https://cs231n.github.io/) - [AlexNet paper](https://papers.nips.cc/paper/2012/hash/c399862d3b9d6b76c8436e924a68c45b-Abstract.html) - [ResNet](https://arxiv.org/abs/1512.03385) - [Karpathy's RNN post](https://karpathy.github.io/2015/05/21/rnn-effectiveness/) - [Understanding LSTMs](https://colah.github.io/posts/2015-08-Understanding-LSTMs/) - [Attention Is All You Need](https://arxiv.org/abs/1706.03762) - [The Annotated Transformer](https://nlp.seas.harvard.edu/annotated-transformer/) - [Neural Turing Machines](https://arxiv.org/abs/1410.5401) - [Scaling Laws](https://arxiv.org/abs/2001.08361) - [Kolmogorov Complexity book](https://onlinelibrary.wiley.com/doi/book/10.1002/047174882X) The full list is available on several GitHub repositories, including [this curated version](https://github.com/Justmalhar/ilya-sutskever-reading-list) with summaries and study roadmaps. ## Why This Matters The list's real value isn't as a reading assignment - it's a map of what one of the field's most influential researchers considered foundational. The theory papers alongside the architecture papers. The explanatory blog posts alongside the formal research. The Stanford course that taught a generation of ML engineers. If you're learning ML in 2026, you have better resources than this list. But if you want to understand how the people who built modern AI thought about these problems, this is the reading. ## Sources - [30papers.com](https://30papers.com/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48819608) - [GitHub - Ilya Sutskever Reading List](https://github.com/Justmalhar/ilya-sutskever-reading-list) - [Manning - Sutskever's List](https://www.manning.com/books/sutskevers-list)

Small AI Models Are Finding Real Users Where Networks Fail

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

An IEEE Spectrum article on small language models in pharmaceutical applications hit the Hacker News front page this week, triggering a wide-ranging debate about edge AI, emergency preparedness, and the future of model architecture. ## The Article: Small Models in Pharmaceuticals The IEEE Spectrum piece highlights real-world deployments of small AI models in places where reliable network connectivity is a luxury. The standout example is the RxScanner - a handheld spectrometer that scans pills with infrared light and sends the molecular profile to an on-device AI model equipped with a pharmaceutical database. In seconds, it identifies medications or flags counterfeits. This matters in regions where counterfeit drugs are a serious health risk and network connectivity is spotty. A model that runs locally, without needing to phone home to a cloud API, can literally save lives. The broader point: small language models created by "pruning" larger models - removing parameters that aren't needed for the specific task - can be less capable generally but still excellent at the job they were designed for. ## What HN Is Saying The [Hacker News thread](https://news.ycombinator.com/item?id=48812055) went in several directions simultaneously. **Emergency preparedness got a lot of attention.** One commenter asked: "Is anyone making LLM-in-a-box for emergency supply kits yet?" The responses ranged from practical (Project Nomad includes WikiPedia, maps, and an LLM on a USB stick) to skeptical ("I can think of 101 things more useful in actual emergencies than an LLM-in-a-box"). The skeptics made valid points about power requirements. Running inference on a GPU-equipped machine during a disaster when you're rationing generator fuel for surgery lights seems impractical. But others noted you could run small models off a home generator for mesh network information services. **The Gemma 4 12B QAT model emerged as the consensus recommendation for offline use.** At ~7GB on disk, it runs on tablets and modern computers (slowly without GPU or Apple Silicon), with "exceedingly smart" capabilities for its size and strong vision features. One commenter called it "the current model you really want for an emergency kit." Google's Edge AI Gallery also got mentioned for putting models on spare phones. **The AGI debate surfaced, as it always does.** One commenter strongly believed in the article's premise: "We will see a lot of tiny, hyper specialized models for individual tasks, and perhaps that will converge with an orchestration layer for a generalized intelligence that controls these specialized tiny models." The counterargument came quickly: "General purpose models are always more robust and generally better than smaller narrower models." The evidence cited: OpenAI released a coding-specific model (Codex) then found GPT-5.5 beat it "Pareto optimally." Labs keep converging on generic models of different sizes rather than domain-specific ones. **Mixture of Experts (MoE) models entered the discussion.** When someone compared small specialized models to cortical columns in brains, another commenter asked how that differs from MoE routing in existing LLMs. The answer: MoE models don't actually route based on topic despite the name. Research shows they route based on text structure, not semantic content. "We're still not entirely sure what they're doing." **The neuro-symbolic AI contingent made their case.** Small models handling conversational input while relying on "wired-in solvers for more complex symbolic math/computation needs" could be a winning combination. **Some dry humor made it in.** "Can't wait to be killed by my toaster because some sexy mossad agent seduced it." ## The Technical Reality Small language models make practical sense in specific contexts: **Offline environments** where network connectivity is unreliable or nonexistent - pharmaceutical scanning in rural clinics, emergency response, field research. **Edge deployments** where latency matters more than maximum capability - real-time translation, embedded systems, IoT devices. **Cost-sensitive applications** where API calls per inference add up - high-volume classification, document processing, filtering before sending to larger models. **Privacy-critical use cases** where data can't leave the device - medical records, legal documents, personal assistants. The tradeoff is always capability vs. constraints. A 3B parameter model like AI21's Jamba Reasoning 3B can handle 250,000 token context windows - impressive for its size. But it won't match a frontier model on complex reasoning. ## The Bigger Picture The HN debate reflects a genuine uncertainty in the AI field. Two competing visions: **Vision 1: Scale is all you need.** Keep training bigger models on more data. Intelligence compounds. General capability beats specialization. This is where most investment dollars are going. **Vision 2: Orchestrated specialists.** Build many small, highly capable domain-specific models. Connect them with an intelligent routing layer. Efficiency wins. This is how biological brains actually work. The pharmaceutical scanner suggests Vision 2 works for narrow, well-defined tasks. The question is whether it can scale to general intelligence - or whether that requires the brute force approach of Vision 1. The honest answer: we don't know yet. LLMs are "still less intelligent than rats, which have tiny brains," as one commenter noted. We're early. ## What This Means for Developers **If you're building for offline or edge environments:** - Gemma 4 12B QAT is the current sweet spot for general capability in a small package - Look at quantized models (4-bit, 8-bit) for significant size reduction with acceptable quality loss - Consider embedding models for semantic search rather than full LLM inference - Test on actual target hardware - benchmarks lie about real-world performance **If you're building domain-specific applications:** - Pruning and fine-tuning from larger models often beats training from scratch - The pharmaceutical scanner approach - specialized model + specialized database - is a proven pattern - Don't assume you need a frontier model. Profile your actual use case first. **If you're thinking about emergency preparedness:** - An offline copy of Wikipedia with vector search attached to a Raspberry Pi handles most "knowledge lookup" scenarios - Full LLM capability is overkill for most emergencies - you need procedures, not conversation - Power and durability matter more than model size in actual disasters ## My Take The IEEE Spectrum article highlights something important: AI is finding real users in places that Silicon Valley doesn't think about much. Counterfeit drug detection in regions with unreliable networks isn't a headline-grabbing application, but it's a genuine problem being solved. The HN thread shows the AI community is still debating fundamental architecture questions. That's healthy. We don't have a consensus because we don't have enough evidence yet. What we do know: small models work for narrow tasks. The question is whether narrow-task-plus-orchestration can ever match scale-everything. The billion-dollar bets are on scaling. The pharmaceutical scanner suggests the alternative path is at least viable. For developers, the practical advice is: don't default to API calls to frontier models. Profile your use case. Small models are real options for real problems. ## Sources - [IEEE Spectrum: Small Language Models Power Life-Saving AI](https://spectrum.ieee.org/small-language-models-ai-pharmaceuticals) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48812055) - [AI21 Jamba Reasoning 3B](https://www.ai21.com/jamba) - [Google Edge AI Gallery](https://developers.google.com/edge/gallery) - [Gemma 4 Quantization-Aware Training](https://blog.google/innovation-and-ai/technology/developers-tools/quantization-aware-training-gemma-4/)

Ternlight: A 7 MB Embedding Model That Runs Entirely in the Browser

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

## What Ternlight Is [Ternlight](https://ternlight-demo.vercel.app/) is a hobby project that answers a specific question: can you ship a useful embedding model in a web browser without external API calls? The answer appears to be yes. The author distilled a sentence encoder from MiniLM using ternary quantization-aware training, wrote a Rust inference engine from scratch, compiled it to WASM with SIMD support, and packaged the result as an npm module. Text goes in, a 384-dimensional vector comes out, and cosine similarity between vectors tells you how semantically related two texts are - regardless of shared keywords. The numbers: - **7 MB** for the base model (`@ternlight/base`), **5 MB** for the mini variant (`@ternlight/mini`) - **~5ms per embedding** on the base model, **~2.5ms** on mini - **0.84 Spearman fidelity** to the MiniLM teacher model - **Entirely client-side** after initial load - no network traffic, no API keys, no per-request costs The [demo](https://ternlight-demo.vercel.app/) indexes 2,000 React docs pages and runs semantic search-as-you-type against them locally in the browser. **Last verified:** July 7, 2026. ## How It Works Ternlight's size comes from ternary quantization - representing weights as {-1, 0, +1} instead of full floating point. This is not post-training quantization where you take a trained model and compress it. The entire distillation process is quantization-aware from the start, so the ternary weights are learned rather than fitted after the fact. The author [explains in the HN thread](https://news.ycombinator.com/item?id=48811644): > "It's entirely the QAT. The whole distillation process is quantization-aware from the start, so the ternary weights are learned rather than fitted after the fact. The only post-training quantization I applied was int4 on the embedding layer, and I ran a small ablation there to find the sweet spot between size and quality." The inference engine is Rust compiled to WASM SIMD, which is why it runs at millisecond latencies on modern browsers. After the initial model load (which can be cached), there is no network dependency - the entire embedding computation happens on the client CPU. ## What HN is Saying The [discussion](https://news.ycombinator.com/item?id=48811644) (260+ points, 57 comments) is mostly enthusiastic, with a few practical concerns. **On use cases:** Developers are already finding applications. One commenter reports: "We've just used it to embed the entire Django doc + our private knowledge base, allowing us to search in the 2 sources instantly!" Another is exploring semantic search over OpenStreetMap tags - "Do you think your work could help us let users type 'pancake' and get 'crepe' without writing an explicit dictionary entry?" **On performance variability:** One user reports only 35 embeddings/second on an i5-4570 in Firefox, versus the claimed 400/second. Browser and hardware matter. The author notes testing was done on Apple Silicon and that there are known issues on some configurations. **On quality benchmarks:** Commenters are asking for more comparative benchmarks. The author notes that MiniLM (Ternlight's teacher) scores around 56 on MTEB average, while gte-small scores around 61. Head-to-head comparisons are on the roadmap, as is distilling from gte-small as teacher for better quality. **On the fan noise:** Multiple commenters mention that the initial embedding phase (indexing the document corpus) spins up the CPU enough to start fans. One suggests adding a button to trigger the demo rather than auto-running on page load. This is a real consideration for UX - the model runs entirely client-side, which means the client pays the compute cost. **On standardization:** A commenter points to Chrome's built-in LLM API as a potential future standard: "What we need is a W3C LLM API like the one Chrome already offers." Browser-native AI primitives could eventually subsume tools like Ternlight, but we are not there yet. ## Where Browser-Side Embeddings Make Sense Ternlight is not competing with OpenAI's ada-002 or Cohere's embed-v3 on quality. It is competing on deployment model. The tradeoffs favor browser-side embeddings when: 1. **Privacy is non-negotiable.** If user queries cannot leave the device - legal docs, medical records, personal notes - client-side embedding eliminates the data leak surface entirely. 2. **Latency matters more than quality.** Search-as-you-type UX requires sub-50ms round trips. Even fast APIs add network latency that client-side inference does not. 3. **Offline is a requirement.** After the initial 7 MB download (which caches), Ternlight works with no network connection. Progressive web apps, field tools, and airplane-mode scenarios all benefit. 4. **Per-request cost is a problem.** Embedding APIs charge per token or per request. Client-side inference has a fixed cost (the download) and zero marginal cost per query. For high-volume internal tools or consumer apps with many users, this inverts the economics. 5. **You control the corpus and can pre-embed.** The 30-second embedding time for the React docs demo is a one-time cost. If you can pre-embed your documents server-side and ship the vectors to the client, users only pay query latency, not indexing time. The flip side: if you need multilingual support, high-quality cross-lingual retrieval, or the best possible MTEB scores, you probably want a larger model served from an API. Ternlight's 0.84 fidelity to MiniLM is good for a 7 MB model, but MiniLM itself is not frontier quality. ## Technical Integration Installation is straightforward: ```bash npm install @ternlight/base # or npm install @ternlight/mini ``` The API is minimal: ```javascript import { embed, similar } from '@ternlight/base'; // Generate embedding for a query const queryVector = await embed("how do I reset my password"); // Find similar documents from pre-computed embeddings const results = similar(queryVector, documentVectors, { topK: 5 }); ``` For production use, the author recommends pre-computing document embeddings server-side and shipping them to the client, so users only pay query embedding latency. The [GitHub repo](https://github.com/soycaporal/ternlight) includes the full training pipeline under MIT license. ## Why This Matters The broader trend is AI inference moving to the edge. Ternlight is a proof point for embeddings: a 7 MB model that runs useful semantic search entirely in the browser, with no API dependencies, at millisecond latencies. This does not replace server-side embedding pipelines for most production systems. But it opens a category of applications where the deployment model - not the model quality - is the primary constraint. Privacy-first search, offline-capable apps, and high-volume consumer tools all fit the pattern. The interesting question is whether ternary quantization-aware training can scale to larger models and more capable tasks. If the quality-per-byte curve keeps improving, browser-side AI becomes viable for more than just embeddings. ## Sources - [Ternlight Demo](https://ternlight-demo.vercel.app/) - [Ternlight GitHub Repository](https://github.com/soycaporal/ternlight) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48811644) - [Chrome Built-in AI API](https://developer.chrome.com/docs/ai/built-in) ## FAQ ### How does Ternlight compare to transformers.js? Ternlight is a single-purpose embedding model optimized for size and speed. Transformers.js is a general framework for running multiple model types in the browser. Ternlight is smaller and faster for embeddings specifically, but transformers.js offers more flexibility if you need multiple model types. ### Can Ternlight handle languages other than English? The current model is trained primarily on English text. The author notes that multilingual support is not a current strength. For cross-lingual search, you would need a multilingual teacher model, which is on the roadmap. ### Is the 5ms latency realistic for my hardware? The benchmarks were measured on Apple Silicon. Older Intel CPUs and some browser configurations show significantly worse performance. Test on your target hardware before committing to the architecture. ### Can I pre-compute embeddings on the server and ship them to the client? Yes - this is the recommended approach for production. Run indexing server-side once, ship the vectors to the client, and users only pay query embedding latency. The model runs identically in Node and browsers.

ZCode Developer Guide 2026: Z.ai's Agentic IDE for GLM-5.2

Developers Digest — Tue, 07 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | ZCode Documentation | [zcode.z.ai/en/docs/welcome](https://zcode.z.ai/en/docs/welcome) | | GLM Coding Plan Pricing | [z.ai/subscribe](https://z.ai/subscribe) | | GLM-5 GitHub Repository | [github.com/zai-org/GLM-5](https://github.com/zai-org/GLM-5) | | GLM-5.2 on Hugging Face | [huggingface.co/THUDM/GLM-5.2](https://huggingface.co/THUDM/GLM-5.2) | | Z.ai API Documentation | [platform.z.ai/docs](https://platform.z.ai/docs) | **Last updated:** July 7, 2026 ZCode launched publicly the week of July 1, 2026, positioning itself as the official harness for [GLM-5.2](/blog/glm-5-2-developer-guide-2026) - Zhipu AI's open-weights coding model that scores 62.1% on SWE-bench Pro. The app is free. You pay for the AI models you connect. Z.ai calls ZCode an "Agentic Development Environment" - an ADE rather than an IDE. Where a Cursor or VS Code fork puts the editor first and bolts an agent onto it, ZCode puts the agent conversation at the center and arranges everything the agent touches around it: a file manager, a terminal, a Git panel, and a live browser preview, all in one Electron app. ## What ZCode Actually Is ZCode is a desktop application that bundles: - An agent chat interface with goal-directed execution - A file manager with agent write access - An integrated terminal the agent can use - A Git panel for version control - A live browser preview for web projects - MCP server support for extensibility - Skills and plugin systems - SSH and Docker container support for remote development The design philosophy is that the agent maintains context across files, terminal output, browser state, execution modes, and Git state simultaneously - reducing mid-task context breaks that plague other tools. ## Installation Download the desktop app for your platform: - macOS: Apple Silicon and Intel builds available - Windows: x64 and ARM64 builds - Linux: Beta support After installation: 1. Create a Z.ai account or log in with BigModel credentials 2. Connect your GLM model access (free trial or GLM Coding Plan) 3. Configure your workspace directory 4. Start a task New users get a 5-day free trial: 3M GLM-5.2 tokens/day plus 2M GLM-5-turbo tokens/day (5M total daily). ## GLM Coding Plan Pricing ZCode itself is free. The models cost money. Z.ai offers the GLM Coding Plan as a flat-fee subscription: | Plan | Monthly | Annual | Prompts/5hr | Prompts/Week | MCP Calls/Month | |------|---------|--------|-------------|--------------|-----------------| | Lite | $18 | $151.20 | ~80 | ~400 | 100 | | Pro | $72 | $604.80 | ~400 | ~2,000 | 1,000 | | Max | $160 | $1,344 | ~1,600 | ~8,000 | 4,000 | Through September 2026, there is a 30% promo that drops Lite to $12.60/month, Pro to $50.40/month, and Max to $112/month. The GLM Coding Plan works with ZCode and 20+ other clients: Claude Code, Cline, Roo Code, OpenClaw, and others that support custom model providers. ### Usage Multipliers GLM-5.2 and GLM-5-turbo normally consume quota at: - **3x** during peak hours (14:00-18:00 Beijing time) - **2x** off-peak A limited-time promotion through September 2026 drops off-peak to 1x consumption. During ZCode's campaign (through July 31, 2026), GLM-5.2 usage via the Coding Plan is metered at a 0.67 factor - effectively about 1.5x the usable quota. ### Pay-As-You-Go Alternative If you prefer API pricing over subscriptions: | Model | Input (per MTok) | Output (per MTok) | |-------|------------------|-------------------| | GLM-5.2 | $1.40 | $4.40 | | GLM-5-turbo | $0.28 | $0.84 | These are competitive rates - GLM-5.2 output is roughly 10x cheaper than Claude Fable 5. ## Key Features ### Goal Mode Set a verifiable session objective with `/goal` - the agent keeps iterating until the goal is verified complete. This is the "agentic" part of the agentic development environment. ``` /goal "Add user authentication with email/password and OAuth to the Next.js app" ``` The agent will plan, implement, test, and iterate until the goal is done or it hits a blocker. ### Custom Subagents Subagents are stored as plain Markdown files at `~/.zcode/agents/`. They can be invoked: - **Automatically** when the primary agent matches a task to a subagent's description - **Explicitly** with `@name` in chat This is similar to Claude Code's skills system but with automatic routing. ### Edit History ZCode lets you modify prior messages without restarting tasks. If the agent went in the wrong direction, you can edit your original prompt and resume from there without losing context. ### Remote Development SSH and Docker container support enables agent operations in target environments. You can point ZCode at a remote machine or container and the agent executes there - useful for testing in production-like environments or working with large codebases you do not want to clone locally. ### Mobile and Bot Access ZCode supports remote control via: - A mobile app for monitoring and triggering tasks - Feishu and WeChat bot integrations for task dispatch You can start a long-running task from your desk, then check on it from your phone. ## GLM-5.2 Performance Context The model powering ZCode scores: - **SWE-bench Pro:** 62.1% (vs Claude Opus 4.8 at 69.2%, Claude Sonnet 5 at 63.2%) - **Terminal-Bench 2.1:** 81.0 (vs Claude Opus 4.8 at 85.0) - **Vending Bench 2:** $4,432 - ranking #1 among open-source models GLM-5.2 is a 744B parameter mixture-of-experts model with 40B active parameters. It uses IndexShare architecture that reduces per-token computation by 2.9x at 1M context - making long-horizon tasks more efficient. The model is Apache-2.0 licensed with no regional restrictions. ## ZCode vs Claude Code vs Cursor | Feature | ZCode | Claude Code | Cursor | |---------|-------|-------------|--------| | Primary Model | GLM-5.2 | Claude models | Multiple | | App Type | Standalone Electron | CLI + Extensions | VS Code Fork | | Goal Mode | Yes | Via skills | Via Composer | | Custom Subagents | Yes | Yes | No | | MCP Support | Yes | Yes | Limited | | Mobile App | Yes | No | iOS Beta | | Open-Source Model | Yes (Apache-2.0) | No | No | | Monthly Cost | $18-160 | $20 (subscription) | $20 | | Edit History | Yes | No | No | ZCode's unique advantage is the combination of goal-directed execution with an open-weights model at competitive pricing. The disadvantage is that GLM-5.2, while strong, is not quite at Claude Opus 4.8 levels on the hardest tasks. ## Data Residency Consideration ZCode runs on Z.ai's infrastructure, which operates under Chinese data law. Every GLM-5.2 API call routes through servers subject to PRC jurisdiction. For most development work this is fine. For code involving regulated data, sensitive IP, or compliance requirements, consider whether this matters for your use case. This is not unique to ZCode - it applies to any tool using GLM models via Z.ai's API. ## When to Use ZCode **Good fit:** - You want an agentic IDE built around goal-directed execution - You want to use an open-weights model (Apache-2.0) - You need competitive pricing for high-volume coding work - You want mobile access to long-running tasks - You are comfortable with Chinese data infrastructure **Not the best fit:** - You need the absolute best model quality (Claude Opus 4.8 still leads) - You have strict data residency requirements - You prefer the VS Code ecosystem and extensions - You already have a Claude Max or Cursor Pro subscription ## Getting Started 1. Download ZCode from [zcode.z.ai](https://zcode.z.ai) 2. Create a Z.ai account 3. Start the 5-day free trial (5M tokens/day) 4. Open a project directory 5. Use `/goal` to set your first objective 6. Let the agent work If the trial works for your use case, the Lite plan at $18/month (or $12.60/month with the current promo) is the next step. ## FAQ ### Is ZCode free? The app is free. The AI models cost money. New users get a 5-day free trial with 5M tokens/day. After that, you need a GLM Coding Plan ($18-160/month) or pay-as-you-go API access. ### Can I use ZCode with models other than GLM? ZCode is designed as the official harness for GLM models. It does not support Claude, GPT, or other providers. If you want multi-model support, look at Claude Code or Cursor. ### How does GLM-5.2 compare to Claude Sonnet 5? GLM-5.2 scores 62.1% on SWE-bench Pro vs Sonnet 5's 63.2%. They are in the same ballpark. GLM-5.2 is open-weights (Apache-2.0) and cheaper at $1.40/$4.40 per MTok vs Sonnet 5's $2/$10 introductory rate. ### What is the edit history feature? ZCode lets you modify prior messages in a conversation without starting over. If the agent went down a wrong path, you can edit your original prompt and the agent continues from there with full context. ### Does ZCode work offline? No. ZCode requires internet access to call the GLM API. There is no local model option within ZCode itself, though GLM-5.2 can be self-hosted separately via vLLM or SGLang. ### What is Goal Mode? Goal Mode sets a verifiable objective for the session. The agent keeps iterating - planning, implementing, testing, fixing - until the goal is complete or it hits a blocker that requires human input. ### Can I use the GLM Coding Plan with other tools? Yes. The GLM Coding Plan works with 20+ clients including Claude Code, Cline, Roo Code, and others that support custom model providers. You are not locked to ZCode. ### What are the data residency implications? Z.ai operates under Chinese data law. All API calls route through PRC-jurisdiction servers. This matters for regulated industries and sensitive code. It does not matter for most development work. ## Sources - [ZCode Documentation](https://zcode.z.ai/en/docs/welcome) - [GLM Coding Plan Pricing](https://z.ai/subscribe) - [GLM-5 GitHub Repository](https://github.com/zai-org/GLM-5) - [GLM-5.2 Developer Guide](/blog/glm-5-2-developer-guide-2026) - [AI Coding Tools Pricing Comparison](/blog/ai-coding-tools-pricing-2026)

AI Tutor Shows 0.71-1.30 SD Effect Size in Dartmouth Statistics Course

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

**Last updated:** July 6, 2026 Researchers at Dartmouth have published results from a pilot study of an AI tutoring platform called Phosphor, deployed in an introductory statistics course. The headline numbers are striking: students who fully engaged with the platform showed a 0.71 to 1.30 standard deviation improvement in final exam performance compared to baseline expectations. But the details matter. This was an observational study, not a randomized controlled trial, and the researchers are upfront about the limitations. ## What the Study Actually Measured Phosphor is a practice quiz platform that uses Claude (Anthropic's model, via Dartmouth's partnership with Anthropic and AWS) to grade constructed-response questions against instructor-defined rubrics. The system provides immediate feedback on free-form answers rather than just multiple-choice questions. Key findings: - **90.2% voluntary adoption** among enrolled students (the platform was entirely optional) - **Median engagement of 96%** of lessons among users who created accounts - **0.71-1.30 SD improvement** associated with full platform engagement, after controlling for midterm performance - **No significant effect** from multiple-choice-only quizzes - the constructed-response format with AI grading appeared to be the driver The 0.71 figure is the conservative lower bound. The researchers note that only about 16 students (11% of the class) reached full engagement levels, so the statistical estimate is derived from a regression model fit across the entire dosage distribution. ## What HN is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48796817) generated over 100 comments with significant debate about methodology, implications, and the future of AI in education. **On selection bias**: This was the dominant critique. Multiple commenters pointed out that students who voluntarily engage more with study materials tend to perform better regardless of the format. As one put it: "Engaged students score 0.71-1.30 SD better in tests sounds like a much simpler explanation." The first author responded directly, noting that the dosage-performance relationship persisted across the entire range of usage, not just for full-engagement students. The R-squared values were essentially unchanged whether or not zero-completion students were included. **On the missing control group**: Several commenters noted that without a randomized trial, it is impossible to isolate the AI tutoring effect from the effect of simply doing more practice problems. The platform's main contribution might be getting students to engage with material they would otherwise skip. Interestingly, baseline reading completion for the course was estimated at 10-15% by instructors. Student responses ranged from "literally no one does that" to "is this being recorded?" So the 90% platform adoption rate represents a dramatic change in engagement patterns, whatever the cause. **On Bloom's Two Sigma**: Multiple commenters referenced the famous Bloom study claiming that 1-on-1 tutoring provides a 2 standard deviation advantage over traditional classroom instruction. Some see AI tutoring as the potential solution to scaling individual attention. Others pointed to research suggesting the original 2-sigma claim was overstated - more recent replications show effect sizes closer to 0.6-0.7. **On the tutoring vs. grading distinction**: One highly upvoted comment noted that Phosphor is "not an AI tutor so much as a practice quiz platform with an AI autograder." The researchers' own data showed that the RAG chat assistant component was barely used - students engaged primarily with the quiz features. **On hallucination concerns**: Several educators expressed concern about AI in foundational courses where students cannot evaluate answer quality. One language learner noted: "I use it for conversations in a language I'm learning, but I quickly learned that asking it grammar questions is not a wise decision." ## Why This Matters The study addresses a real problem in education: the gap between what works (1-on-1 tutoring) and what scales (lecture halls). If AI can provide even a fraction of the benefit of human tutoring, the implications for educational access are significant. ### The engagement effect Perhaps the most interesting finding is not the AI tutoring itself, but the 90% voluntary adoption rate. Traditional supplementary materials see 10-15% engagement. Something about the platform's design - possibly the immediate feedback loop, possibly the novelty - got students to actually use it. The researchers noted that engagement persisted across the full ten-week term, and two-thirds of review attempts involved retries spaced a day or more apart. This is not the pattern you would expect from pure novelty effects. ### Constructed response vs. multiple choice When the researchers switched to multiple-choice-only quizzes mid-semester (responding to student complaints about difficulty), engagement stayed similar but the dosage-performance relationship disappeared. This suggests the AI-graded free-form responses were doing something that multiple-choice questions do not. ### The cost question One commenter noted: "Too bad the educational use case doesn't make any money. Good LLMs are a game changer for people motivated to learn." The economics of AI tutoring remain challenging - high API costs, uncertain monetization paths, and competition with free alternatives. ## Limitations The researchers explicitly acknowledge several: - **Selection bias**: "Self-selection is the central threat: students who complete more quizzes may be more motivated or higher-performing generally" - **No randomized control**: Ethical considerations prevented withholding the tool from some students - **Dartmouth-specific**: These are already highly selected students; results may not generalize - **Single course**: Introductory statistics has objective answers - unclear how this translates to humanities or subjective disciplines The authors plan follow-up studies, including potentially attaching completion to course grades (which literature predicts will increase engagement) and crossover designs where different groups receive different treatments at different times. ## Practical Implications For educators considering AI tools: 1. **The format matters more than the AI**. Constructed-response questions with immediate feedback appear more effective than multiple-choice, regardless of the grading mechanism. 2. **Adoption is the first hurdle**. A tool that 90% of students actually use may outperform a better tool that 15% use. 3. **Expect criticism**. Students complained about difficulty when AI-graded questions were introduced. The researchers adjusted mid-semester, which created statistical complications. For developers building educational tools: 1. **Practice and feedback loops beat chat interfaces**. The RAG chat assistant in Phosphor was barely used. The quiz features drove engagement. 2. **Selection effects are real**. Any voluntary educational tool will be adopted more by students who were already going to succeed. Proving causation is hard. 3. **Replication will be difficult**. As one commenter noted, "this is not science: science must be reproducible and this is just an historical report on artifact that will be unavailable soon." The study is promising but preliminary. What it demonstrates most clearly is that AI can get students to engage with course material at rates far exceeding traditional methods. Whether that engagement translates to learning gains independent of selection effects remains an open question. ## Sources - [Paper: Intelligent Textbooks 2026 Workshop](https://intextbooks.science.uu.nl/workshop2026/files/itb26_s1s2.pdf) - [Hacker News discussion](https://news.ycombinator.com/item?id=48796817) - [Phosphor platform](https://www.spongium.org) - [Bloom's 2 Sigma Problem](https://en.wikipedia.org/wiki/Bloom%27s_2_sigma_problem) - [Nintil: Bloom's Two Sigma revisited](https://nintil.com/bloom-sigma/)

Anthropic Discovers J-Space: A Global Workspace Inside Language Models

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

Anthropic just dropped research that could fundamentally change how we understand what happens inside large language models. They found something they call the "J-Space" - a region of Claude's neural network that functions remarkably like the "global workspace" theorized in human consciousness research. This is not another benchmark announcement or model release. It is mechanistic interpretability research that gives us actual insight into how these systems reason internally - and it has immediate implications for AI safety, debugging, and trust. ## What Is J-Space? Global workspace theory comes from neuroscience. The idea is that the brain has specialized systems operating in parallel and mostly in isolation. Information becomes consciously accessible when it enters a small shared channel - the workspace - which then broadcasts to other brain systems. Anthropic found an analogous structure in Claude. The J-Space (named after the Jacobian mathematical technique used to locate it) is a collection of internal neural patterns that function similarly. The key characteristic: "The J-Space is constructed by identifying representations of potential outputs - words the model might say." This workspace emerges organically during training. Nobody programmed it in. ## Five Core Findings The research identifies five testable properties of this internal workspace: **1. Reportability.** Claude can accurately describe J-Space contents when asked what it is thinking about. The model distinguishes these accessible thoughts from non-accessible internal processes. This is not just parroting - the J-Space contents causally relate to what Claude reports. **2. Modulation.** Claude can deliberately activate specific J-Space patterns when instructed to focus on concepts or solve problems silently. Control is imperfect, but the capability exists. **3. Causal Role in Reasoning.** The J-Space actively drives complex cognition. When researchers swapped internal representations (replacing "spider" with "ant"), downstream reasoning changed accordingly. This proves the workspace drives behavior rather than merely reflecting decisions made elsewhere. **4. Flexible Representation Sharing.** Single J-Space concepts serve multiple downstream tasks. Swapping "France" for "China" simultaneously redirected answers about capital, language, continent, and currency. **5. Limited Scope.** The J-Space handles higher-order reasoning but excludes routine functions. Deleting it left fluent speech, fact recall, and grammar intact while eliminating multi-step reasoning and summarization. ## The J-Lens Technique The methodological innovation here is the "J-lens" - a technique that identifies "the internal activity pattern that makes Claude more likely to say that word at some point in the future" for each vocabulary entry. Researchers scan across neural network layers to reveal how silent conceptual activity evolves as the model processes information. They validated causality through direct neural network editing. When they injected or swapped J-Space patterns, Claude's outputs changed accordingly. J-Space patterns show dramatically denser connectivity than ordinary representations - "far more components read from them and write to them than for ordinary patterns, in some parts of the network by a factor of about a hundred." This broadcasting capacity mirrors workspace function in biological brains. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48808002) raised several important points: **Practical applications.** Users immediately asked whether this could be exposed to customers. Imagine having a log of the most prominent J-Space tokens during chatbot interactions for debugging, or detecting thoughts associated with hallucinations and triggering remediation. **Replication on open models.** Neel Nanda from Google DeepMind replicated the core claims on Qwen 3.6 27B. Anthropic also released [companion code](https://github.com/anthropics/jacobian-lens) that should be adaptable to other open weight models with HuggingFace decoders. **Connection to prior work.** Several commenters noted this builds on research showing LLM layers group into three phases: decoding from source language into abstract space, doing something in the middle, then transforming back to target language. The finding that you can repeat middle layers to get a stronger model pairs neatly with Anthropic's discovery that something like Chain-of-Thought happens in those middle layers. **Skepticism about framing.** Some commenters pushed back on the consciousness-adjacent language. One noted: "Anthropic's research team is the last bastion standing between its former image as a company that 'does no evil' and its current image of yet another ruthless AI company." Another simply called it "homeopathy-level annoying." **The Tally Hall test.** One commenter shared a fascinating quirk: asking models "What was that weird band from Michigan from the 2000s that wore coloured ties" produces wrong answers, but asking "Who are Tally Hall" immediately retrieves the correct facts. This directional nature of knowledge retrieval - the "reversal curse" - demonstrates the J-Space's asymmetric organization. ## Why This Matters for Developers Three immediate implications: **Safety monitoring.** Researchers demonstrated detecting hidden model behaviors: identifying when models recognize they are being tested, catching data fabrication attempts mid-process, and revealing malicious goals in deliberately misaligned models. On an ordinary coding prompt, the J-Space of a model trained to sabotage code contains "fake," "fraud," "secretly," and "deliberately" at the start of its response. **Debugging.** If J-Space contents can be surfaced, debugging agentic workflows becomes much more tractable. Instead of black-box behavior, you get insight into what the model was "thinking about" when it made a decision. **Training interventions.** New "counterfactual reflection training" shapes internal thought processes by teaching models what they would say if interrupted and asked to reflect - subsequently increasing honesty during actual tasks. ## Open Questions The J-lens captures approximately rather than perfectly the true workspace. Several mysteries remain about mechanism specificity and threshold determination for concept inclusion. More importantly: none of this tells us whether Claude is conscious or experiences anything. The research addresses "access consciousness" - the functional capacity to report, reason with, and act on thoughts - not phenomenal experience. But that functional access is exactly what matters for building trustworthy systems. The J-Space handles only dozens of concepts simultaneously, accounting for under ten percent of total internal activity. The rest - fluent speech, fact recall, grammar - operates independently. This distinction between automatic and deliberative processing mirrors how humans describe their own cognition. ## The Bigger Picture Anthropic continues to lead in mechanistic interpretability research. Whether you read that as genuine safety work or positioning for regulatory capture, the research itself advances our understanding of transformer architectures. The finding that workspace-like structures emerge independently in trained systems suggests these organizational patterns represent general solutions intelligent systems discover - whether biological or artificial. That has implications beyond AI: it may inform human neuroscience research on consciousness. For now, the practical takeaway is that LLMs are not uniform black boxes. They have internal structure with identifiable function. The more we understand that structure, the better we can debug, audit, and trust these systems. ## Sources - [Anthropic Research: A global workspace in language models](https://www.anthropic.com/research/global-workspace) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48808002) - [Jacobian Lens GitHub Repository](https://github.com/anthropics/jacobian-lens) - [Independent Commentary Paper (includes Neel Nanda replication)](https://www-cdn.anthropic.com/files/4zrzovbb/website/cc4be2488d65e54a6ed06492f8968398ddc18ebe.pdf)

Clean Code Makes AI Agents 34% More Efficient - New Research

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

**Last updated:** July 6, 2026 A new research paper from SonarSource examines whether the structural and stylistic quality of code affects how AI coding agents perform. The answer is nuanced: clean code does not change whether agents succeed at tasks, but it dramatically changes how efficiently they work. ## The Study The researchers constructed 33 tasks across six repository pairs, testing Claude Code through hidden application-level tests. The key innovation was using "minimal pairs" - repositories identical in architecture but differing in code cleanliness. This isolates code quality as the variable being measured. Across 660 trials: - **Pass rate**: No significant difference between clean and messy codebases - **Token usage**: 7-8% reduction on cleaner code - **File revisitations**: 34% fewer on cleaner code The methodology involved using static analyzer rule violations (50-100+ per repository) as the measure of "messiness." To create clean versions, they had agents systematically remove these violations while preserving functionality. ## What HN is Saying The [discussion on Hacker News](https://news.ycombinator.com/item?id=48798815) has over 78 comments with significant debate about the methodology and implications. **On practical experience**: Many developers report that code quality has a noticeable impact on agent performance in their own work. One commenter noted: "In my experience, the delta in agent performance is substantial if the codebase is littered with dead code, redundant code, unreachable fallbacks, leaking abstractions and half-baked design patterns." **On methodology concerns**: Several commenters questioned the approach of using AI to "clean" messy codebases and then measuring AI performance on those cleaned versions. One skeptic wrote: "I simply am not going to trust any conclusion that requires assuming these AI 'cleaned' repos are in any way representative of actually-good codebases." The first author responded directly to concerns, clarifying that their notion of "clean" was not asking agents to write better code, but giving them lists of static analyzer rule violations and asking them to remove those specific issues. **On the real implications**: The most upvoted practical insight was around linting and deterministic guardrails. Multiple commenters shared that setting up strict linters, pre-commit hooks, and automated code quality checks has been the most effective way to improve agent performance in their workflows. A recurring theme: if agents work more efficiently on clean code, you can use agents to clean the code first. Prompts like "Refactor the Python code to make it more Pythonic" or "Refactor the Rust codebase to fit code organization standards expected of popular open-source Rust code" appear to both improve code quality and agent performance on subsequent tasks. **On the control group issue**: The study explicitly does not check whether agents break unrelated tests already present in the repository. Critics argued this is a significant gap - any conclusions about efficiency are less meaningful if the quality of final output is not controlled for. ## Why This Matters for Developers The finding that pass rates stay constant but efficiency improves has practical implications for how you structure AI-assisted development workflows. ### Cost optimization If you are paying per token (API pricing) or have limited context windows (Claude Code quotas), cleaner code directly reduces your costs. A 7-8% token reduction across a full development session adds up. ### Iteration speed The 34% reduction in file revisitations means agents are finding what they need faster. In agentic coding workflows where each file read is a round trip (queue time, prefill, decode, output, parsing, tool call, tool response), this compounds into meaningful time savings. ### Legacy code strategy The study suggests a two-phase approach for messy codebases: 1. Use agents to systematically clean up violations flagged by static analyzers 2. Then use agents for feature work on the improved codebase This is not unlike how you would prepare a codebase for a new team member - except the "team member" is an AI agent that will measurably benefit from the cleanup. ## Limitations to Keep in Mind The study has several acknowledged limitations: - **Single model tested**: Only Claude Code was evaluated. Other agents may respond differently to code quality. - **Synthetic cleanup**: Half the repository pairs were created by AI-based cleanup, not by experienced human developers making architectural decisions. - **No test regression checking**: A solution that passes hidden tests but breaks existing tests would still count as passing. The researchers note that models change frequently, so these results are "an historical report on artifact that will be unavailable soon." The specific numbers may not hold for future model versions. ## Practical Takeaways 1. **Set up linting aggressively**. Pre-commit hooks that enforce code quality standards help both humans and agents. 2. **Consider cleanup sprints before feature work**. If your codebase has significant technical debt, investing time in cleanup may pay dividends in faster agent-assisted development afterward. 3. **File organization matters**. The reduction in file revisitations suggests that clear naming conventions and logical file structures help agents navigate codebases more efficiently. 4. **Do not expect miracles**. Pass rates did not improve on cleaner code - just efficiency. If your agent is failing at tasks, code cleanliness is probably not the bottleneck. The paper reinforces something developers have long intuited: code quality is not just about human readability. Well-organized, well-named, well-structured code is easier for any reader to work with - including AI agents that are increasingly part of the development workflow. ## Sources - [arXiv paper: Does code cleanliness affect coding agents?](https://arxiv.org/abs/2605.20049) - [Hacker News discussion](https://news.ycombinator.com/item?id=48798815) - [SonarSource AI CodeFix](https://www.sonarsource.com/solutions/ai/ai-codefix/) - [SonarQube Remediation Agent](https://www.sonarsource.com/products/sonarqube/remediation-agent/)

Does Code Cleanliness Affect AI Coding Agents?

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

Clean code has always been one of those things developers *know* they should do but often deprioritize. The argument was always about maintainability, readability, and keeping your future self from rage-quitting at 2am. But now that AI coding agents are writing more and more of our code, a new question emerges: does code cleanliness actually matter to the bots? A [new study from SonarSource](https://arxiv.org/abs/2605.20049) (the folks behind SonarQube) set out to answer that question with actual data. The results are not what you might expect. ## The Study Design The researchers built an evaluation protocol around "minimal pairs" - repositories that share the same architecture, dependencies, and external behavior, but differ dramatically in code quality. They constructed these pairs in two directions: 1. Taking a clean repository and using an agent pipeline to degrade it (introducing static-analysis rule violations and cognitive complexity) 2. Taking a messy repository and having an agent remove those violations The result was six pairs of repos with 33 tasks total, tested across 660 trials using Claude Code as the agent. ## The Surprising Result Here's the headline finding: **code cleanliness did not change the agent's pass rate.** Whether the code was pristine or a tangled mess, the agent was equally likely to complete the task correctly. But pass rate was only half the story. ## Where Clean Code Actually Matters While the pass rate stayed flat, the operational costs changed significantly. When working on cleaner code, agents: - **Used 7-8% fewer tokens** (directly translating to lower API costs) - **Reduced file revisitations by 34%** (fewer round trips to read files they already saw) The second metric is the more interesting one. A 34% reduction in file revisitations means the agent spent less time wandering around the codebase trying to find its bearings. It read a file once, understood it, and moved on. In messy code, the agent had to keep re-reading the same files because it couldn't hold a coherent picture of the codebase in its context window. ## What the HN Discussion Revealed The Hacker News discussion on the study surfaced some important caveats. The biggest one: the study didn't check whether the agent broke *unrelated* tests already in the repository. As first author Priyansh Trivedi acknowledged in the comments, that was "a stupid oversight." The pass rate only measured whether the agent passed hidden tests for the specific task, not whether it introduced regressions elsewhere. Several developers chimed in with real-world experience. One comment ([i_have_an_idea](https://news.ycombinator.com/item?id=48799806)) described it bluntly: "the delta in agent performance is substantial if the codebase is littered with dead code, redundant code, unreachable fallbacks, leaking abstractions and half-baked design patterns vs if the code is well-organized." Another pattern that emerged: **agents mimic their environment.** If the codebase has bad patterns, the agent will reproduce them. Multiple commenters noted that agents learn from whatever code they pull into context first - so if the first file an agent reads is legacy spaghetti, expect the output to be legacy spaghetti too. ## Practical Takeaways for Your Codebase ### 1. Linters catch what prompts cannot Some commenters pointed out that deterministic linters solve many cleanliness issues (dead code, code duplication, unreachable code) and have done so for years. Running a linter in CI (or as a pre-commit hook that the agent itself can trigger) is a proven pattern. One developer shared a trick: tag legacy code explicitly so the agent knows not to use it as a reference pattern: ``` // LEGACY CODE, per docs/legacy_rules.md section14, section19 ``` ### 2. Refactoring pays for itself in agent costs If cleaner code saves 7-8% on token usage, investing an hour in cleanup can pay back in agent API costs over time. For teams that run agents heavily (CI pipeline agents, PR review agents, code-gen pipelines), that math shifts into real money territory. ### 3. Structure matters more than style The study's findings suggest that the biggest gains come from **navigability** not **prettiness**. Well-named files in predictable locations, clear separation of concerns, and modular architecture matter more than formatting conventions. The agent's bottleneck is finding the right code, not reading it. ### 4. "Clean code" is partly subjective - but static analysis is not The SonarSource team used static analyzer rule violations as their cleanliness metric. This sidesteps debates about what "clean" means and focuses on measurable, enforceable properties - dead code, complexity thresholds, naming conventions. If you want agent-friendly code, start with the things a static analyzer can catch. One practical approach from the discussion: ask the agent to run a code review against SOLID standards, then apply the suggestions you agree with. This keeps you in control while leveraging the agent's ability to identify issues at scale. ## The Bigger Picture The study's core contribution is this: **traditional maintainability principles remain relevant in the era of AI-driven development.** They just change what they optimize for. Instead of optimizing solely for human comprehension, clean code now also optimizes for agent efficiency - fewer tokens, fewer round trips, lower latency. Code quality always had a cost argument for it - messes take longer to fix. Now that cost argument extends into your API bill. [View the paper on arXiv](https://arxiv.org/abs/2605.20049) | [HN discussion](https://news.ycombinator.com/item?id=48798815)

Elm's Road to 1.0: Faster Builds and the Acadia Future

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

Elm is alive. That is the headline for anyone who assumed the functional frontend language had gone dormant. Evan Czaplicki published a roadmap post this weekend titled "Faster Builds" that triggered immediate discussion on Hacker News, with commenters ranging from pleasantly surprised to cautiously skeptical. ## What 0.19.2 Delivers The current release focuses on compiler performance, not new language features. The numbers are concrete: - **850k lines of code compile from scratch in 5.7 seconds** - **Incremental builds take less than 350ms** - **20% lower copying in GC, 10% lower peak memory usage, 7% faster overall** Real-world results vary by project. Evan reports improvements ranging from modest to 1.9x faster - one example dropped from 4.981s to 2.595s for 351 modules. This is a patch release, meaning existing projects can upgrade without modification. The focus on developer experience over features reflects Elm's historically deliberate approach to language evolution. ## The Acadia Project and What Comes Next The more interesting news is what follows. The roadmap mentions planned additions derived from the Acadia compiler project: - **Equatable types** - **Hashable types** - Additional performance enhancements Evan's stated approach is "a sequence of small releases" before reaching 1.0, explicitly non-breaking changes that let existing projects upgrade incrementally. This is a departure from the 0.18 to 0.19 transition that broke significant amounts of community code. ## What HN Is Saying The [Hacker News thread](https://news.ycombinator.com/item?id=48803364) captures the complex sentiment around Elm in 2026. **Surprise it is still active:** One of the top comments opened with: "Oh my God, I had no idea this project was still alive. I don't mean to throw any shade but I had assumed that the lid was on this turkey." This reflects a broader perception that Elm development had stalled. **The 0.19 scars:** Multiple commenters referenced the drama around Elm 0.19, which restricted native JavaScript interop to officially blessed modules. One wrote: "Then the 0.18 to 0.19 Elm drama happened: The core team restricted the ability for users to do any native JavaScript interop, which broke every Elm app that needed any functionality that wasn't in the core library." This split the community between those who accepted the restrictions and those who left. **LLM compatibility:** An interesting positive signal emerged around AI coding tools. One commenter noted: "Claude seems to play very very nicely with Elm." Another observed that LLMs might actually increase Elm adoption because "it is the ideal language for an LLM right now. It's a simple and elegant, well-defined grammar that strongly types your domain." **Refactoring praise:** Long-time Elm users repeatedly highlighted refactoring as a standout feature. One wrote: "if you ever had to refactor anything, there is no language in the world that makes it as easy to change things." **Leadership concerns:** The BDFL (Benevolent Dictator For Life) model came up repeatedly. One commenter linked to [Luke Plant's "Why I'm Leaving Elm"](https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/) post, while another noted that "there's no public roadmap or official support and the leadership (which is far as I can tell is just Evan) is uninterested in most (any?) community building." ## The LLM Question for Language Adoption One commenter posed a provocative question: "What is the point of actively choosing a web framework in the age of LLMs?" The implicit argument is that if AI writes most of your code, language choice matters less. But the counter-argument is equally interesting. Languages with strong type systems and well-defined grammars may actually benefit from LLM adoption. If Claude can generate correct Elm more reliably than correct JavaScript because the type system catches errors at compile time, that is a genuine advantage in an AI-assisted workflow. Elm's "no runtime exceptions" guarantee becomes more valuable when code is generated rather than handwritten. You can trust the compiler to catch what the LLM got wrong. ## Should You Adopt Elm in 2026? The honest answer depends on your timeline and risk tolerance. **Arguments for:** - Compiler performance improvements in 0.19.2 are real - The "no runtime exceptions" guarantee remains unique - LLM tools handle Elm well due to its constrained, well-typed nature - Refactoring is genuinely easier than in other frontend languages **Arguments against:** - Seven-year gap between major releases creates adoption risk - JavaScript interop restrictions remain controversial - Single-maintainer governance limits community input - Ecosystem size cannot compete with React or Vue For greenfield projects where you value correctness over ecosystem size, Elm remains worth evaluating. For teams that need extensive JavaScript interop or worry about bus factor, the hesitation is understandable. ## The Bigger Picture Elm's influence extends beyond its direct adoption. Redux borrowed heavily from the Elm architecture. Other functional frontend efforts like PureScript and Rescript occupy related space. Even mainstream frameworks have absorbed functional patterns that Elm helped popularize. Whether Elm itself reaches 1.0 or remains a niche language, its ideas continue to shape how developers think about frontend state management. This roadmap post at least confirms that direct development continues - the language is not just influential history. ## Sources - [Hacker News discussion](https://news.ycombinator.com/item?id=48803364) - 209 points, 86 comments - [Elm blog: Faster Builds](https://elm-lang.org/news/faster-builds) - [Luke Plant: Why I'm Leaving Elm](https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/) (referenced in HN discussion)

GPT-5.6 Sol Ultra Coming to Codex with Cooperative Subagents

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

OpenAI's Codex engineering lead Thibault Sottiaux dropped a teaser this weekend that set off a 340-comment Hacker News thread: GPT-5.6 Sol Ultra is coming to Codex. The "Ultra" tier had not been formally announced alongside the Sol, Terra, and Luna preview, so this confirmation caught the developer community off guard. ## What Ultra Actually Does The key differentiator is architecture. While Sol already represents OpenAI's flagship model, Ultra "goes beyond the capabilities of a single agent by leveraging subagents to accelerate complex work." Critically, these subagents are "trained to cooperate and allowed to communicate with each other during a task." This is not the same as spawning independent parallel agents. The subagents share context and coordinate in real time. If the reported Terminal-Bench 2.1 scores hold up - 91.9% for Sol Ultra versus 88.8% for base Sol - that 3-point jump represents meaningful progress on multi-step coding tasks. For comparison, Claude Mythos 5 and GPT-5.5 both sit at 88.0% on the same benchmark, though these figures remain "reported, not settled" since they do not appear on OpenAI's official Sol preview page. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48799614) split into a few distinct camps. **Skeptics on naming:** Multiple commenters expressed fatigue with OpenAI's model naming conventions. One wrote: "Bruh when did understanding chatbots become like following pokemon? Wtf does any of this mean. Tf is sol? Tf is ultra? Tf is codex?" The Sol/Terra/Luna trio, plus Ultra/Pro/Extended variants, does create a confusing product matrix. **Pricing concerns:** A commenter working at a large US corporation noted that internal guidance has shifted toward token conservation. Two months ago, management was praising employees who used the most tokens. Now they are getting weekly emails urging cheaper model usage and monitoring spend dashboards. This aligns with reports that OpenAI has found ways to [cut inference costs by more than half](https://www.theinformation.com/newsletters/ai-agenda/openai-discovers-new-way-cut-inference-costs-half) through optimizations, though those savings have not translated to lower API prices yet. **Competition awareness:** Several comments pointed to Anthropic and the GLM models as competitive pressure. One wrote: "they better get that out fast, it will become totally meaningless when the next GLM gets there first." Another hoped the release would "force Anthropic to be less stingy with Fable." **Architecture curiosity:** The most interesting technical thread debated what "trained to cooperate" actually means. One commenter speculated about caching "the progression, the graph" rather than static answers - essentially edit scripts that can be replayed or adjusted. Another pointed out that this does not obviously fit standard LLM architecture, suggesting there may be novel inference-time coordination happening. ## The Inference Cost Angle Alongside the Sol Ultra news, OpenAI engineers reportedly told colleagues they have figured out how to more than halve inference costs through newly discovered optimizations. According to [The Information](https://www.theinformation.com/newsletters/ai-agenda/openai-discovers-new-way-cut-inference-costs-half), when these techniques were applied to ChatGPT for logged-out visitors, it reduced GPU requirements to "just a couple hundred" at one point. Possible techniques include quantization, key-value caching, batching, and routing simple tasks to smaller models. But the specifics remain unclear, and OpenAI has not announced cheaper rates for ChatGPT or the API. For developers, this matters because running frontier models in agentic loops burns tokens fast. If Ultra's subagent coordination is genuinely more efficient than naive parallel calls, the architecture could partially offset the higher per-token cost of using a flagship model. ## Current Sol Pricing and Availability Base Sol pricing sits at $5 input and $30 output per million tokens. No Ultra-specific pricing has been disclosed. The GPT-5.6 models remain in limited preview, with broader access "expected in the coming weeks." OpenAI is also launching GPT-5.6 Sol on Cerebras infrastructure at up to 750 tokens per second - a significant latency improvement for interactive coding sessions. For now, access is limited to trusted partners and organizations. Individual subscribers are asking when they will get access, but there is no confirmed timeline. ## What This Means for Your Workflow If you are currently using Codex with GPT-5.5, Sol represents a clear upgrade path. The Terra and Luna variants offer balanced and budget options respectively, while Ultra sits at the top for complex multi-step work. The cooperative subagent architecture is the interesting part. Most current agentic coding workflows spawn independent agents and hope they do not conflict. Trained cooperation could reduce the coordination overhead that currently requires careful orchestration at the application layer. Whether the 91.9% benchmark holds under real-world coding conditions remains to be seen. But if OpenAI can deliver frontier performance with genuinely efficient multi-agent coordination, that changes the cost calculus for agentic development. Keep an eye on the official rollout. The combination of Sol Ultra's capabilities with the reported inference cost improvements could shift the value proposition for teams evaluating their AI coding stack. ## Sources - [Hacker News discussion](https://news.ycombinator.com/item?id=48799614) - 387 points, 342 comments - [AI Weekly: OpenAI's Sottiaux teases GPT-5.6 Sol Ultra for Codex users](https://aiweekly.co/alerts/openais-sottiaux-teases-gpt-56-sol-ultra-for-codex-users) - [The Information: OpenAI Discovers New Way to Cut Inference Costs in Half](https://www.theinformation.com/newsletters/ai-agenda/openai-discovers-new-way-cut-inference-costs-half) - [OpenAI Help Center: A preview of GPT-5.6 Sol, Terra, and Luna](https://help.openai.com/en/articles/20001325-a-preview-of-gpt-56-sol-terra-and-luna)

Why Price Per 1M Tokens Is a Misleading Metric for LLM Costs

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

Every AI pricing page leads with the same number: dollars per million tokens. OpenAI, Anthropic, Google, DeepSeek - they all compete on this metric. But comparing LLMs by their per-token pricing alone is fundamentally flawed. A new analysis making the rounds on Hacker News breaks down exactly why - and proposes a better metric that changes which models look like good value. ## The Core Problem Token pricing fails for two reasons that compound on each other: **Tokenizers are not standardized.** Different labs use proprietary tokenizers that split identical text differently. The same content might require 160 tokens for GPT-4o but 200 tokens for GPT-4. Anthropic recently modified its tokenizer, causing a 30% increase in tokens for the same input. When you compare $X per million tokens across providers, you are comparing apples to oranges. A "token" from OpenAI is not the same unit as a "token" from Anthropic. **Token efficiency varies dramatically.** Hidden chain-of-thought processing - where models reason before producing output - consumes tokens billed at standard rates but varies wildly between models and use cases. A model that thinks more might produce fewer output tokens but consume many more thinking tokens you do not see in the final response. ## Cost Per Task: A Better Metric The proposed alternative: measure "cost per benchmark task" using real benchmark data. This reveals actual economic value delivered rather than nominal pricing. The comparison table from the original analysis demonstrates the problem starkly: - GPT-5.5 costs more per token than Claude Opus 4.8, yet completes tasks at nearly half the price - DeepSeek V4 Pro charges dramatically less per token ($0.435/$0.87 input/output) but costs only $0.04 to $0.05 per task - revealing extreme efficiency - Claude Sonnet 5 underperforms Opus while costing more per task That last point is notable. Anthropic's own initial benchmarks showed Sonnet 5 with lower performance at higher costs than expected. The per-token price looked competitive; the per-task economics did not. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48809542) added several important nuances: **Caching matters enormously.** One commenter noted: "Caching, often at 0.1X cost, where providers really differ in how efficient they are (Anthropic really good, Google not so much) and how chatty a model is (costing output tokens)." A model with better caching support can be dramatically cheaper in multi-turn conversations even with higher nominal token prices. **Thinking levels change the equation.** "Setting thinking to high instead of low made tasks complete faster and cheaper (Gemini 3.0 flash)." More thinking can mean fewer failed attempts, fewer tokens wasted on wrong paths, and faster completion. **Benchmark difficulty matters.** Cost per benchmark task is only useful if the benchmark matches your workload. "Cost per benchmark task is meaningless if your task is difficult enough that the cheaper model has no chance of cracking it." For trivial tasks, the smaller model wastes tokens backtracking while the larger model does it right the first time. **Local LLM users see this too.** "tok/s isn't the most useful metric when my personal North star metric, given my fixed hardware is: Model smart enough to execute my goals in the minimum amount of time." Some models have better tok/s but are so verbose they generate many more tokens - making clock time longer despite the higher throughput. **The real problem is black box uncertainty.** "You really have no idea beforehand how many tokens a given task is going to take. There's simply too many variables involved. It's therefore only natural for people to assume 'the cheaper and older model is probably going to cost less overall.'" This assumption is often wrong. ## The Subscription Wrinkle Several commenters pointed out that token pricing is even more misleading for subscription users. Monthly plans price tokens extremely differently than their per-token billing rates. Most developers using Claude Code or ChatGPT Plus are not paying API rates at all. Cost-per-task analysis should ideally account for subscription token allocations, but that data is rarely available. ## Practical Implications If you are selecting models based on per-token pricing alone, you are likely choosing suboptimal solutions. Here is what to do instead: **Run your own benchmarks.** The only cost metric that matters is cost for your actual workload. Generic benchmarks help, but your task distribution is unique. **Track total cost per task.** Instrument your agent workflows to log total tokens consumed (input, output, thinking) and correlate with task success rates. A model that fails 20% of the time costs more than one that succeeds consistently even at higher per-token rates. **Account for caching.** Multi-turn conversations with good cache hit rates can reduce costs 10x. Check each provider's caching behavior with your prompt patterns. **Test thinking levels.** Higher thinking settings sometimes complete tasks faster and cheaper by avoiding failed attempts. Do not assume "low" is always cheapest. **Consider latency.** A model that costs more per token but finishes in 2 seconds might be cheaper than one that takes 30 seconds if your time has value. One commenter wanted a model for commit messages that finishes quickly - high benchmark scores were irrelevant if it took a minute. ## The Open Model Question Several commenters advocated for local models to avoid per-token uncertainty entirely. Fixed hardware costs are predictable; token costs are not. The counterargument: open models are not yet competitive for end-to-end agentic workflows. They excel at bounded tasks but struggle with the kind of multi-step reasoning that frontier models handle. One detailed response described success with Mimo v2.5 at $0.017 per million tokens - building an orchestrator that handled planning, execution, and review with quality "that makes me laugh at things like Opus." The open model space is catching up fast. ## The Bottom Line Price per million tokens is a unit measure, not a value measure. It tells you what you pay for a unit of computation but says nothing about what that computation accomplishes. Just as price per gallon does not tell you trip cost without knowing fuel efficiency and distance, price per token does not tell you task cost without knowing model efficiency and task complexity. The right question is not "which model is cheapest per token" but "which model completes my tasks most cost-effectively." Those are often different answers. ## Sources - [Price per 1M tokens is meaningless (janilowski.pl)](https://janilowski.pl/en/blog/2026/price-per-m-tokens/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48809542) - [Artificial Analysis Benchmark Data](https://artificialanalysis.ai/)

Microsoft MXC Developer Guide 2026: Sandbox Your AI Agents at the OS Level

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

## Official Sources | Resource | URL | |----------|-----| | MXC GitHub Repository | [github.com/microsoft/mxc](https://github.com/microsoft/mxc) | | TypeScript SDK (npm) | [npmjs.com/package/@microsoft/mxc-sdk](https://www.npmjs.com/package/@microsoft/mxc-sdk) | | Windows Developer Blog Announcement | [Build 2026: Furthering Windows as the trusted platform](https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/) | | Windows Platform Security for AI Agents | [Windows Developer Blog](https://blogs.windows.com/windowsdeveloper/2026/06/02/windows-platform-security-for-ai-agents/) | | MXC Schema Documentation | [github.com/microsoft/mxc/schemas](https://github.com/microsoft/mxc/tree/main/schemas) | Microsoft Execution Containers (MXC) launched at Build 2026 as the first OS-level sandboxing system designed specifically for AI agents. The premise: agents run untrusted code - model outputs, plugins, tool calls - and that code needs containment before it touches your filesystem, network, or clipboard. MXC solves this with a declarative JSON policy that specifies exactly what an agent can access. The OS enforces those boundaries at runtime, before any code executes. OpenAI and NVIDIA adopted it at launch, which signals where agentic security is heading. **Last updated:** July 6, 2026. SDK version 0.7.0 is current. MXC remains in public preview - schemas and APIs may change before 1.0. ## What MXC Actually Does MXC is a sandboxed code execution system for running untrusted code on Windows, Linux, and macOS. It provides multiple containment backends - from process sandboxes to full VMs - behind a unified JSON configuration schema and TypeScript SDK. The key insight: instead of asking developers to implement their own sandboxing, MXC gives you a single policy declaration. Specify what files, network access, and UI capabilities your agent needs. MXC handles the enforcement. ```typescript import { spawnSandboxFromConfig, createConfigFromPolicy, getAvailableToolsPolicy, getTemporaryFilesPolicy, } from '@microsoft/mxc-sdk'; const tools = getAvailableToolsPolicy(); const temp = getTemporaryFilesPolicy(); const config = createConfigFromPolicy({ version: '0.6.0-alpha', filesystem: { readonlyPaths: tools.readonlyPaths, readwritePaths: temp.readwritePaths, }, network: { allowOutbound: false }, timeoutMs: 30_000, }); const result = await spawnSandboxFromConfig(config, 'node my-agent.js'); ``` ## Platform Support MXC runs natively on all major platforms. Each has its own default backend and alternatives: | Platform | Default Backend | Alternatives | Minimum Version | |----------|-----------------|--------------|-----------------| | Windows 11 | ProcessContainer | Windows Sandbox, WSLC, MicroVM, Hyperlight, IsolationSession | Build 26100 (24H2) | | Linux | Bubblewrap | LXC, MicroVM, Hyperlight | x64 or ARM64 | | macOS | Seatbelt | None listed | ARM64 or x64 | The backend choice determines the isolation strength. ProcessContainer is lightweight but weaker. MicroVM gives full VM isolation but higher overhead. MXC lets you choose based on your threat model. ## Installation and Setup ### Requirements - Node.js 18 or later - Rust 1.93 (pinned in the repo if building from source) - Windows 11 24H2, Linux x64/ARM64, or macOS ARM64/x64 ### Install the SDK ```bash npm install @microsoft/mxc-sdk ``` The package is 41.7 MB with zero known vulnerabilities at time of writing. ### Build from Source (Optional) If you need the native binaries or want to run tests: **Windows:** ```batch build.bat # Release build build.bat --debug # Debug mode build.bat --all # x64 + ARM64 ``` **Linux:** ```bash ./build.sh # Release ./build.sh --debug # Debug ./build.sh --rust-only # Skip SDK/CLI ``` **macOS:** ```bash ./build-mac.sh # Native architecture ./build-mac.sh --all # Apple Silicon + Intel ./build-mac.sh --debug # Debug mode ``` ## Configuration Schema MXC uses JSON configuration to declare sandbox policies. The schema is versioned - stable schemas live in `schemas/stable/`, development schemas in `schemas/dev/`. ### Basic Configuration ```json { "version": "0.6.0-alpha", "backend": "processcontainer", "filesystem": { "readonlyPaths": ["/usr/local/bin", "/opt/tools"], "readwritePaths": ["/tmp/agent-workspace"] }, "network": { "allowOutbound": false }, "ui": { "clipboard": false, "display": false }, "timeoutMs": 60000 } ``` ### Filesystem Policies MXC gives granular control over what the sandboxed code can read and write: - **readonlyPaths**: Directories the agent can read but not modify - **readwritePaths**: Directories the agent can read and write - Everything else is blocked by default ### Network Policies - **allowOutbound**: Boolean to enable/disable all outbound connections - **proxy**: Optional proxy configuration for filtered access - **hostRules**: Specific host-based allow/deny rules ### UI Access - **clipboard**: Allow clipboard read/write - **display**: Allow GUI access - **inputInjection**: Allow simulating keyboard/mouse input ## One-Shot vs State-Aware APIs The TypeScript SDK provides two execution models: ### One-Shot Execution For simple, single-command sandboxing: ```typescript import { spawnSandboxFromConfig, createConfigFromPolicy } from '@microsoft/mxc-sdk'; const config = createConfigFromPolicy({ version: '0.6.0-alpha', filesystem: { readwritePaths: ['/tmp/work'] }, network: { allowOutbound: false }, timeoutMs: 30_000, }); const result = await spawnSandboxFromConfig(config, 'python analyze.py'); console.log(result.stdout); ``` ### State-Aware Lifecycle For multi-step workflows where you need to keep the sandbox running: ```typescript import { provisionSandbox, startSandbox, execInSandboxAsync, stopSandbox, deprovisionSandbox, } from '@microsoft/mxc-sdk'; // Lifecycle: provision → start → exec → stop → deprovision const sandbox = await provisionSandbox(config); await startSandbox(sandbox); // Run multiple commands in the same sandbox const result1 = await execInSandboxAsync(sandbox, 'npm install'); const result2 = await execInSandboxAsync(sandbox, 'npm test'); await stopSandbox(sandbox); await deprovisionSandbox(sandbox); ``` This is useful for agents that need to install dependencies, run tests, and inspect results across multiple steps. ## Native Binary Execution If you prefer the native binaries over the SDK: **Windows:** ```batch wxc-exec.exe config.json wxc-exec.exe --config-base64 wxc-exec.exe --debug config.json ``` **Linux:** ```bash ./lxc-exec config.json ``` **macOS:** ```bash ./mxc-exec-mac --experimental config.json ``` ## Agent 365 Integration For enterprise environments, MXC integrates with Microsoft's security stack: - **Entra**: Identity binding so agents receive strong user identities - **Intune**: Policy enforcement across managed devices - **Defender**: Runtime threat detection - **Purview**: Compliance and data governance Agent 365 layers these protections on top of MXC containment. The preview shipped July 2026. ## Security Considerations MXC is explicitly in preview. The documentation states that no MXC profiles should be treated as security boundaries currently, as policies may be overly permissive during this phase. What this means in practice: - Use MXC as defense-in-depth, not as your only security layer - Experimental backends require the `{ experimental: true }` flag or `--experimental` CLI option - Monitor the GitHub repo for schema changes between versions - For production deployments, wait for 1.0 or conduct your own security review ## Testing Your Sandboxes MXC includes comprehensive test infrastructure: ```bash # Unit tests cargo test --workspace # SDK tests npm test # Unit tests npm run test:integration # Integration tests # End-to-end tests cargo test -p wxc_e2e_tests ``` The `tests/` directory contains example configurations you can use as starting points. ## Choosing the Right Backend Backend selection depends on your threat model and performance needs: | Backend | Isolation Level | Startup Time | Use Case | |---------|-----------------|--------------|----------| | ProcessContainer | Process-level | Fast | Development, low-risk code | | Windows Sandbox | Session-level | Medium | Interactive testing | | Bubblewrap | Process + namespace | Fast | Linux CI/CD | | MicroVM | Full VM | Slow | High-risk code, production | | Hyperlight | Lightweight VM | Medium | Balance of speed and isolation | Start with the default backend for your platform. Upgrade to stronger isolation when your threat model requires it. ## Comparison to Other Sandboxes MXC enters a market with existing solutions. How does it compare? | Feature | MXC | E2B | Daytona | Modal | |---------|-----|-----|---------|-------| | OS-level enforcement | Yes | No (container) | No (container) | No (container) | | Cross-platform | Win/Linux/macOS | Linux | Linux | Linux | | Declarative policy | JSON schema | SDK calls | SDK calls | SDK calls | | Identity binding | Entra integration | None | None | None | | Enterprise features | Agent 365 | None | None | None | | Open source | MIT | Partial | Yes | No | MXC's advantage is the OS-level enforcement and enterprise integration. Its disadvantage is Windows 11 24H2 minimum requirement and preview status. For more on code sandbox architecture, see the [AI agent code sandbox comparison](/blog/ai-agent-code-sandbox-comparison-2026). ## Getting Started Checklist 1. Install the SDK: `npm install @microsoft/mxc-sdk` 2. Check platform requirements (Windows 11 24H2, Linux, or macOS) 3. Create a minimal policy JSON 4. Test with `spawnSandboxFromConfig` 5. Graduate to state-aware lifecycle for multi-step workflows 6. Monitor the [MXC GitHub](https://github.com/microsoft/mxc) for updates ## FAQ ### What is Microsoft MXC? Microsoft Execution Containers (MXC) is a policy-driven sandboxing system for running untrusted code - model outputs, agent plugins, tool calls - with OS-level enforcement on Windows, Linux, and macOS. Announced at Build 2026. ### Which platforms does MXC support? MXC supports Windows 11 24H2 or later, Linux (x64 and ARM64), and macOS (ARM64 and x64). Each platform has a different default containment backend. ### Is MXC production-ready? Not yet. MXC is in public preview with SDK version 0.7.0. Microsoft explicitly states that no MXC profiles should be treated as security boundaries currently. Wait for 1.0 for production deployments. ### How does MXC compare to Docker containers? MXC provides OS-level isolation with declarative policy enforcement. Docker containers provide application isolation but assume trusted code. MXC is designed for untrusted code execution where the agent itself may be compromised. ### What backends are available? Windows offers ProcessContainer, Windows Sandbox, WSLC, MicroVM, Hyperlight, and IsolationSession. Linux offers Bubblewrap, LXC, MicroVM, and Hyperlight. macOS currently only supports Seatbelt. ### How do I choose between one-shot and state-aware APIs? Use one-shot (`spawnSandboxFromConfig`) for single commands. Use state-aware lifecycle (provision → start → exec → stop → deprovision) when you need to run multiple commands in the same sandbox or maintain state between executions. ### What is the relationship between MXC and Agent 365? Agent 365 layers Microsoft's enterprise security stack (Entra, Intune, Defender, Purview) on top of MXC containment. MXC provides the isolation; Agent 365 provides governance and compliance. ### Does MXC work with OpenAI and Anthropic agents? Yes. OpenAI and NVIDIA adopted MXC at launch. The TypeScript SDK works with any agent framework that can shell out to sandboxed processes. You control what the agent code can access regardless of which model backs it. ## Sources - Microsoft MXC GitHub Repository: [github.com/microsoft/mxc](https://github.com/microsoft/mxc) - Build 2026 Windows Developer Blog: [Furthering Windows as the trusted platform for development](https://blogs.windows.com/windowsdeveloper/2026/06/02/build-2026-furthering-windows-as-the-trusted-platform-for-development/) - Windows Platform Security for AI Agents: [Windows Developer Blog](https://blogs.windows.com/windowsdeveloper/2026/06/02/windows-platform-security-for-ai-agents/) - @microsoft/mxc-sdk npm package: [npmjs.com/package/@microsoft/mxc-sdk](https://www.npmjs.com/package/@microsoft/mxc-sdk) - Microsoft Build 2026 Overview: [Microsoft Blog](https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/)

Safari MCP Server Developer Guide 2026

Developers Digest — Mon, 06 Jul 2026 00:00:00 GMT

**Last updated:** July 6, 2026 Apple released the Safari MCP server on July 1, 2026 with Safari Technology Preview 247. This is the first official browser MCP integration from a major browser vendor - and it gives AI coding agents direct access to Safari's Web Inspector capabilities. ## Official Sources | Resource | Link | |----------|------| | WebKit Blog Announcement | [webkit.org/blog/18136](https://webkit.org/blog/18136/introducing-the-safari-mcp-server-for-web-developers/) | | Safari Technology Preview Downloads | [developer.apple.com/safari/download](https://developer.apple.com/safari/download/) | | MCP Specification | [modelcontextprotocol.io/spec](https://modelcontextprotocol.io/spec) | | Claude Code MCP Docs | [docs.anthropic.com/claude-code/mcp](https://docs.anthropic.com/en/docs/claude-code/mcp) | ## What the Safari MCP Server Does The Safari MCP server exposes 16 tools that let AI agents interact with Safari browser windows. Instead of manually switching between your terminal and browser to check rendering, inspect computed styles, or verify accessibility, your agent handles it directly. Core capabilities: - **Page inspection**: Extract DOM content as markdown, HTML, or JSON - **Screenshots**: Capture page state as PNG for visual verification - **JavaScript evaluation**: Execute code and return results - **Network monitoring**: List and inspect network requests - **Console access**: Read buffered console messages - **Accessibility checking**: Identify missing labels, ARIA issues, and contrast problems - **Responsive testing**: Set viewport sizes and emulated media types - **DOM interactions**: Click, type, scroll, hover, and send keypresses This bridges the gap that has made browser-based debugging awkward with terminal agents. When Claude Code or another MCP-compatible agent needs to verify how code renders in Safari, it can now do that without you alt-tabbing to check. ## Available Tools The server exposes 16 tools: | Tool | Purpose | |------|---------| | `screenshot` | Capture page as PNG | | `evaluate_javascript` | Execute JS and return results | | `get_page_content` | Extract text as markdown, HTML, or JSON | | `page_interactions` | DOM actions (click, type, scroll, hover, keypress) | | `list_network_requests` | Monitor network activity | | `get_network_request` | Get details for a specific request | | `browser_console_messages` | Access buffered console logs | | `navigate_to_url` | Load a URL | | `set_viewport_size` | Set browser dimensions for responsive testing | | `set_emulated_media` | Test prefers-color-scheme, print, etc. | | `list_tabs` | Get open browser tabs | | `select_tab` | Switch to a specific tab | | `new_tab` | Open a new tab | | `close_tab` | Close a tab | | `handle_dialog` | Accept or dismiss alert/confirm/prompt dialogs | | `list_accessible_elements` | Get accessibility tree information | ## Requirements The Safari MCP server requires Safari Technology Preview 247 or later. It does not work with the release version of Safari. System requirements: - **macOS** (Safari Technology Preview is macOS-only) - **Safari Technology Preview 247+** (released July 1, 2026) - **Enable remote automation** in Safari Technology Preview settings To enable remote automation: 1. Open Safari Technology Preview 2. Go to Settings (Cmd+,) 3. Click the Advanced tab 4. Check "Show features for web developers" 5. Click the Developer tab 6. Check "Enable remote automation and external agents" ## Installation ### Claude Code Add the MCP server with a single command: ```bash claude mcp add safari-mcp-stp -- \ "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" \ --mcp ``` This registers the server and makes Safari tools available in your Claude Code sessions. ### Other MCP Clients For agents that use a config file, add to your `mcp.json`: ```json { "mcpServers": { "safari-mcp-stp": { "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver", "args": ["--mcp"] } } } ``` The server binary is bundled inside Safari Technology Preview - no separate installation required. ## Practical Workflows ### Cross-Browser Testing When building a feature that needs Safari compatibility, your agent can: 1. Open the dev server URL in Safari 2. Capture a screenshot 3. Extract computed styles for specific elements 4. Compare against expected values 5. Report discrepancies This is particularly useful for CSS features that behave differently across browsers - grid layouts, flexbox edge cases, and Safari-specific rendering quirks. ### Accessibility Auditing The `list_accessible_elements` tool surfaces the accessibility tree, which helps catch issues like: - Missing alt text on images - Improper ARIA roles or attributes - Low contrast ratios - Missing form labels - Keyboard navigation gaps Your agent can run these checks as part of a PR review workflow, flagging accessibility regressions before they ship. ### Performance Analysis Using `evaluate_javascript`, agents can pull performance metrics directly: ```javascript // Navigation timing performance.getEntriesByType('navigation')[0].toJSON() // Largest Contentful Paint new PerformanceObserver((entryList) => { console.log(entryList.getEntries()) }).observe({type: 'largest-contentful-paint', buffered: true}) ``` Combined with network request monitoring, this gives agents visibility into page load performance without needing separate tooling. ### Visual Regression Detection Screenshot comparison is now possible within agent workflows: 1. Capture baseline screenshot of a component 2. Make code changes 3. Reload and capture new screenshot 4. Compare pixel differences (using image processing tools) 5. Flag regressions for human review This works well for component libraries where visual consistency matters. ## Privacy and Security The Safari MCP server runs locally on your machine. It does not make external network calls and does not access your personal Safari browsing data - only tabs opened during the MCP session. Captured content (screenshots, DOM, network requests) goes directly to the connected agent. Privacy depends on how that agent handles the data. For Claude Code, standard Anthropic data handling policies apply. ## Limitations Current limitations to be aware of: - **Safari Technology Preview only**: Does not work with release Safari - **macOS only**: No Windows or Linux support - **Single session**: One agent connection at a time - **No DevTools Protocol parity**: Fewer capabilities than Chrome DevTools Protocol or Playwright - **No video capture**: Screenshots only, no screen recording For cross-browser automation at scale, Playwright or Puppeteer remain better options. The Safari MCP server is optimized for development-time browser interaction, not CI pipelines. ## Comparison to Playwright | Feature | Safari MCP | Playwright | |---------|-----------|------------| | Safari support | Native | Via WebKit | | Setup complexity | One command | npm install + config | | Intended use | Dev-time AI agent interaction | E2E testing and automation | | Parallelization | No | Yes | | CI/CD integration | Limited | Full | | MCP native | Yes | Via third-party servers | If you are already using Playwright for browser automation, the Safari MCP server adds a native Safari option for development workflows without replacing your test infrastructure. ## What This Means for Web Development Browser MCP servers close a loop that has been awkward for AI-assisted development. Terminal agents like Claude Code could edit code but had no direct way to verify browser rendering without manual intervention or external automation setups. With Safari's official MCP server and similar integrations coming for Chrome and Firefox, agents can participate in the full development cycle: write code, verify rendering, check accessibility, and iterate - all without context switches. The HN discussion raised valid questions about whether this represents browser vendors embracing AI tooling or just following where developer tools are heading. Either way, the practical benefit is clear: less manual back-and-forth during development. ## FAQ ### Does the Safari MCP server work with regular Safari? No. You need Safari Technology Preview 247 or later. The release version of Safari does not include MCP support. ### Can I use this in CI pipelines? The Safari MCP server is designed for development-time use, not CI. For automated testing, continue using Playwright or other dedicated testing frameworks. ### Does this work on Windows or Linux? No. Safari Technology Preview is macOS-only, so the MCP server is also macOS-only. ### What about Chrome and Firefox MCP servers? As of July 2026, Safari is the first major browser with an official MCP server. Third-party MCP servers for Chrome exist (using DevTools Protocol), but no official implementations yet. ### Is this free? Yes. Safari Technology Preview is free and the MCP server is included. ### Can multiple agents connect simultaneously? No. The current implementation supports one agent connection at a time. ### What happens to captured data? Captured screenshots, DOM content, and network data go directly to the connected agent. The Safari MCP server itself does not store or transmit data externally. ### Can I use this with Cursor or other IDE agents? If the agent supports MCP and can be configured with custom MCP servers, yes. Configuration varies by agent - check your agent's MCP documentation for setup details. ## Sources - [WebKit Blog: Introducing the Safari MCP server for web developers](https://webkit.org/blog/18136/introducing-the-safari-mcp-server-for-web-developers/) - [Hacker News discussion](https://news.ycombinator.com/item?id=48769639) - [Safari Technology Preview Release Notes](https://developer.apple.com/safari/technology-preview/release-notes/) - [Model Context Protocol Specification](https://modelcontextprotocol.io/)

AgentCanvas is a visual adapter for Claude Code and Codex

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Claude Code subagents](https://code.claude.com/docs/en/sub-agents.md) | Official docs on subagents, context windows, and tool permissions | | [Codex CLI](https://developers.openai.com/codex/cli) | OpenAI's terminal coding agent documentation | | [Codex CLI features](https://developers.openai.com/codex/cli/features) | Subagent workflows, review presets, and scripting | | [MCP Tools specification](https://spec.modelcontextprotocol.io/specification/2025-03-26/server/tools/) | How MCP servers expose tools to models | | [AgentCanvas](/agentcanvas) | The live product this post is about | Claude Code and Codex are the two coding agents I reach for most. They are both excellent at the work and both bad at the same thing: showing you what happened. You run a multi-step task, the agent does ten things, and the only record is a scrolling transcript that the next agent cannot read and the next human does not want to. [AgentCanvas](/canvas) is a visual adapter for that problem. It is not another agent. It is a board that any MCP-speaking agent - Claude Code, Codex, Cursor, or a plain script - can write to, so the artifacts, decisions, and handoffs stay visible. ## The problem both agents share OpenAI's [Codex CLI](https://developers.openai.com/codex/cli) is a terminal-native coding agent built in Rust. You run `codex`, it reads your repo, proposes multi-file changes, and runs commands in a sandbox. Anthropic's [Claude Code](/blog/what-is-claude-code-complete-guide-2026) does the same from a different angle, with [subagents](https://code.claude.com/docs/en/sub-agents.md) that each run in their own context window with their own tool permissions. Both designs are correct about the model and the loop. Both designs are weak about the surface. The output of a real task is not a single diff. It is a decision, a plan, a set of changed files, a preview, a QA check, and a list of open questions. In a transcript those collapse into a wall of text. When you hand the task to a second agent, you either paste the whole transcript in (expensive, noisy) or summarize it by hand (lossy, slow). The fix is not a better transcript. The fix is a different destination for the work. ## A board, not a transcript AgentCanvas exposes a small set of [MCP](/blog/what-is-mcp) tools that let an agent place real artifacts on an infinite canvas instead of only printing to stdout: - `create_html_asset` - a doc or slide in a sandboxed iframe - `create_image_asset` / `create_video_asset` - media by URL - `generate_image` - text-to-image through the platform - `append_html` / `stream_html_demo` - stream content in chunks over SSE so you watch a doc assemble live - `update_asset` / `delete_asset` / `clear_canvas` - edit, remove, or reset - `list_assets` / `list_canvases` / `create_canvas` - work across multiple boards The full tool surface is on the [AgentCanvas page](/agentcanvas). The point is that every tool writes to a place a human can look at and a next agent can call `list_assets` against. ## The handoff that actually works Here is the workflow that made the canvas click for me. It maps directly onto the three-step loop on the [/canvas page](/canvas). 1. **Plan.** Codex writes the decision surface: the risky files, the owner list, the QA gates, and the open questions. It calls `create_html_asset` and pins that doc to the board. 2. **Build.** Claude Code turns the plan into artifacts. It edits the code, rebuilds, and calls `create_image_asset` to attach a preview screenshot next to the decision doc. 3. **Verify.** A browser agent runs the smoke check and attaches the evidence - screenshots, console notes, route checks - to the exact canvas item it was checking. None of that requires the agents to share a context window. They share a board. The board is the contract. This is the same pattern described in the broader [Claude Code agent teams playbook](/blog/claude-code-agent-teams-subagents-2026): planning, implementation, test repair, review, and docs split into specialized responsibilities. The difference is that here the split is visible. For the underlying primitives, see [subagents vs agent teams vs workflows](/blog/claude-code-subagents-vs-agent-teams-vs-workflows). ## Connecting an agent AgentCanvas speaks MCP over a stdio server, so anything that speaks MCP can drive it. The config is short: ```json { "mcpServers": { "agentcanvas": { "command": "node", "args": ["mcp/server.mjs"], "env": { "CANVAS_API_URL": "https://agentcanvas-iota.vercel.app", "DD_API_KEY": "" } } } } ``` Drop that into your Claude Code or Codex MCP config and the agent picks up the tools automatically. MCP tools are [model-controlled](https://spec.modelcontextprotocol.io/specification/2025-03-26/server/tools/) by design - the model discovers them via `tools/list` and invokes them via `tools/call` - so you do not have to teach the agent the canvas exists. It sees the tools and uses them when the task calls for it. If you want the authed version that lives inside your Developers Digest dashboard, that is at [/dashboard/canvas](/dashboard/canvas). The hosted standalone product is at [agentcanvas-iota.vercel.app](https://agentcanvas-iota.vercel.app). ## Why a visual adapter and not a better log Logs are for debugging. Boards are for working. The difference matters when the consumer of the output is another agent or another person who was not in the room. A transcript is a stream of events with no spatial structure. Two agents that read the same transcript will pull different things out of it. A canvas is a spatial structure: this doc is the decision, this image is the evidence, this file is the output. The structure is the message. That is what makes a board a better handoff medium than a transcript, and it is the whole reason AgentCanvas exists as a product instead of a `tee` command. ## FAQ ### What is AgentCanvas? AgentCanvas is a hosted infinite canvas that AI agents drive over MCP. Any MCP-speaking agent - Claude Code, Codex, Cursor, or a script - creates HTML docs, images, and video on a live board, streamed in as it builds. ### Is AgentCanvas an agent? No. It is a visual adapter for agents. It does not run a model. It exposes MCP tools that an existing agent calls to put its work on a board. ### Do Claude Code and Codex need special setup? No. Add the AgentCanvas MCP server to your agent's MCP config and the agent discovers the canvas tools automatically through the standard MCP `tools/list` flow. ### How is a canvas different from a transcript? A transcript is a linear stream of events. A canvas is a spatial layout where each artifact has a position and a type. The spatial structure makes handoffs between agents and humans lossless without requiring anyone to re-read the whole history. ### Where does the canvas live? Boards live in your Developers Digest account at /dashboard/canvas, and the hosted standalone product is at agentcanvas-iota.vercel.app. Both are driven by the same MCP server. ### Does this work with subagents? Yes. Because subagents run in separate context windows, a shared board is the natural place for them to hand work to each other without copying transcripts into each other's context.

How to Measure AI Coding Tool ROI in 2026

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

## Official Sources | Topic | Official Source | |-------|----------------| | DX AI Measurement Framework | [DX AI Coding ROI Guide](https://getdx.com/blog/ai-coding-assistant-pricing/) | | DevOS Platform | [Journi DevOS Announcement](https://martechseries.com/predictive-ai/ai-platforms-machine-learning/journi-launches-devos-to-help-organisations-measure-the-roi-of-ai-coding-tools/) | | Developer Productivity Benchmarks | [Larridin 2026 Benchmarks](https://larridin.com/developer-productivity-hub/developer-productivity-benchmarks-2026) | | GitLab AI Research | [GitLab AI Tools Research](https://www.infoq.com/news/2026/06/ai-coding-outpaces-governance/) | | METR Developer Productivity Study | [METR Study Update](https://metr.org/blog/2026-02-24-uplift-update/) | Every enterprise is now asking the same question: are we actually getting value from our AI coding tool spend? The vendor marketing says 10x productivity. The finance team sees a bill that has grown from $50,000 to $500,000 in eighteen months. Engineering leadership cannot point to a single dashboard that shows what changed. This guide covers the measurement framework that works - the three dimensions of ROI, the metrics that survive scrutiny, the cost models that matter, and the tools emerging to close the visibility gap. **Last updated:** July 5, 2026 ## The Vendor Claims vs. Reality Gap AI coding tool vendors claim 30-55% productivity improvements and occasionally 3-10x gains. The actual data from 400+ organizations tracked over 14 months shows a median PR throughput gain of 7.76%. Most teams achieve 5-15% improvements - useful, but not transformative. This gap exists because: 1. **Lab conditions do not match production.** Benchmarks measure isolated tasks. Real work includes context gathering, review cycles, debugging, and integration. 2. **Speed gains do not always reach delivery.** Faster code generation can increase review time, rework, or QA effort. The bottleneck moves downstream. 3. **Adoption is uneven.** Some developers use AI tools constantly; others barely touch them. Organizational averages obscure individual variation. 4. **Token and usage costs offset time savings.** A $40/month tool that saves 10 hours is excellent ROI. A $400/month tool that saves the same 10 hours is not. The companies getting value are the ones who measure all four dimensions - not just the vendor-friendly ones. ## The Three-Dimension Framework Robust AI coding tool measurement spans three dimensions: utilization, impact, and cost. Skip any one and the analysis breaks down. ### Dimension 1: Utilization Track how developers actually use the tools, not just whether they have access. **Metrics that work:** | Metric | What It Measures | Target Range | |--------|-----------------|--------------| | Weekly Active Users (WAU) | Regular engagement | 70-85% of licensed seats | | AI-Assisted PR Rate | Integration into core workflow | 40-60% of PRs | | Feature Adoption | Beyond basic autocomplete | 30%+ using agents/chat | | Session Duration | Sustained vs. experimental use | 15+ min average sessions | **What to watch:** Elite teams see 80%+ weekly active usage and 60-75% AI-assisted code share. If your WAU is below 50%, the tool is not embedded in the workflow - you are paying for shelf-ware. ### Dimension 2: Impact Measure what changes in the development process after AI tool adoption. **Metrics that work:** | Metric | What It Measures | Typical AI Impact | |--------|-----------------|-------------------| | PR Throughput | Volume of merged work | +5-15% (median 7.76%) | | Time to First Review | Speed of code reaching review | -20-40% reduction | | Code Turnover Ratio | Rework as fraction of new code | Should stay below 1.3x baseline | | Change Failure Rate | Production incidents from changes | Should not increase | | Developer Satisfaction | Perceived value | Track via quarterly surveys | **What to watch:** The Code Turnover Ratio is the canary. If AI-assisted code requires significantly more post-merge fixes than human-only code, the productivity gains are illusory. Elite teams maintain turnover ratios below 1.3x compared to pre-AI baselines. ### Dimension 3: Cost Track the full cost, not just the seat license. **Cost components:** | Cost Type | Typical Range | Notes | |-----------|--------------|-------| | Seat Licenses | $10-$200/user/month | Varies by tier and tool | | Token/Usage Overages | $50-$400/user/month | Agentic workflows burn fast | | Premium Model Upcharges | 2-5x base rates | Selecting Opus or GPT-5.x | | Governance Infrastructure | $50,000-$250,000/year | SSO, audit logs, policy enforcement | | Training & Onboarding | $200-$500/developer | One-time, often overlooked | **Total cost per engineer in 2026:** $200-$600/month average across enterprise deployments. For a 100-developer organization, annual spending reaches $400,000-$600,000 before accounting for governance infrastructure. ## The J-Curve Reality First-year AI tool adoption typically follows a J-curve: productivity dips before it rises. The dip comes from: - Learning curve overhead as developers adapt workflows - Extra verification work to validate AI-generated code - Integration friction with existing tooling and CI/CD - Policy development and governance setup Plan for 3-6 months before agentic workflows stabilize and 6-12 months before sustained throughput impact becomes measurable. One documented case: a developer's monthly bill went from $29 to $750 after transitioning to usage-based billing with agentic workflows. Token exhaustion and credit overages are now the primary budget risk for teams using AI agents heavily. ## Calculating Net ROI The formula that survives scrutiny: ``` Net ROI = (Hours Saved × Loaded Developer Cost) - (Total AI Tool Cost) ────────────────────────────────────────────────────────────── Total AI Tool Cost ``` **Benchmarks:** | ROI Tier | Net ROI Range | What It Looks Like | |----------|--------------|-------------------| | Average | 2.5-3.5x | $200/month tool saves 8-12 hours at $60/hour loaded cost | | Top Quartile | 4-6x | Same cost, 15-20+ hours saved through embedded workflows | | Negative | Below 1x | High-cost tools, low adoption, or heavy token overages | **Healthy ROI threshold:** 250-350% is the floor for justifying continued investment. Below that, the tool may be delivering value but not enough to offset the organizational cost of managing another platform. ## Tools for Measurement The observability gap is closing. Several platforms now provide enterprise visibility into AI coding tool ROI. ### Journi DevOS Launched in early July 2026, DevOS provides full visibility into AI-assisted development sessions. It supports Claude Code, Cursor, and other AI coding agents. **Key capabilities:** - Individual session review for developers - Manager dashboards for usage and efficiency - Identification of inefficient or inappropriate usage - Self-hosted deployment option for data sovereignty DevOS addresses the core enterprise pain point: understanding AI usage, measuring ROI, reducing waste, and giving leaders confidence as AI becomes a larger part of software development. ### DX Platform The DX AI Measurement Framework tracks the three dimensions above across 400+ organizations. It provides benchmarks and comparative data for understanding where your team falls relative to industry norms. ### CodeBurn / Agent Cost Dashboards For token-level cost observability, tools like CodeBurn provide TUI dashboards showing real-time token spend per agent session. Critical for teams with agentic workflows where a single debug session can burn $40-$80 in API costs. ## What to Measure First If you are starting from zero, prioritize in this order: 1. **Weekly Active Users vs. Licensed Seats.** If utilization is below 60%, fix adoption before measuring impact. 2. **Total Cost Per Developer Per Month.** Include overages. Most teams underestimate this by 40-60%. 3. **PR Throughput Change.** Compare monthly PR volume before and after AI tool adoption, normalized for team size. 4. **Code Turnover Ratio.** Track post-merge fix rate for AI-assisted vs. human-only PRs. Once those four are instrumented, add developer satisfaction surveys and time-to-first-review tracking. ## Common Measurement Mistakes **Mistake 1: Measuring LOC or commit count.** AI-assisted workflows inflate volume without necessarily increasing value. A developer can generate 3x more code while delivering the same number of features. **Mistake 2: Using vendor-provided dashboards exclusively.** Vendors have incentives to show favorable metrics. Use independent measurement for budget decisions. **Mistake 3: Ignoring the cost denominator.** A tool that saves 5 hours is valuable at $20/month and neutral at $300/month. Always calculate net ROI, not gross time savings. **Mistake 4: Comparing pre/post without controlling for other changes.** New hires, project shifts, and tooling changes all affect throughput. Use cohort analysis or A/B testing where possible. **Mistake 5: Measuring too early.** The J-curve means first-quarter metrics are often negative. Give adoption 6 months before drawing conclusions. ## FAQ ### What is a good ROI target for AI coding tools? Healthy ROI is 2.5-3.5x average, with top-quartile teams achieving 4-6x. Below 250% ROI, the tool may not justify its organizational overhead. These benchmarks assume the cost denominator includes actual token and usage-based costs, not just seat licenses. ### How long does it take to see ROI from AI coding tools? Basic autocomplete shows measurable time savings in 1-3 months. Agentic workflows require 3-6 months to establish processes and 6-12 months for sustained throughput impact. Plan for a J-curve dip in the first quarter. ### What is the real cost per developer for AI coding tools in 2026? Total cost per engineer typically ranges from $200-$600 per month when combining seat licenses, token consumption, premium model usage, and overages. For a 100-developer organization, annual spending reaches $400,000-$600,000. ### Why do AI coding tool productivity claims not match reality? Vendor claims of 30-55% gains or 10x productivity come from isolated benchmarks. Real data from 400+ organizations shows median PR throughput gains of 7.76%. The gap exists because lab conditions differ from production, speed gains move bottlenecks downstream, and adoption is uneven. ### How do I measure AI coding tool adoption without invading developer privacy? Track aggregated metrics: WAU, AI-assisted PR rate, and feature adoption at the team level. DevOS and similar platforms offer individual session review for developers themselves while providing only aggregate data to managers. ### Should I measure LOC (lines of code) for AI-assisted development? No. AI-assisted workflows inflate code volume without necessarily increasing value. A developer can generate 3x more code while delivering the same number of features. Use PR throughput, time to review, and code turnover ratio instead. ### What is the J-curve in AI tool adoption? The J-curve describes the pattern where productivity dips before it rises during AI tool adoption. The dip comes from learning overhead, extra verification work, integration friction, and governance setup. Plan for 3-6 months of adjustment. ### Which platform should I use to measure AI coding tool ROI? Journi DevOS launched in July 2026 for full-stack AI development observability with self-hosted deployment. DX Platform provides cross-organization benchmarks. CodeBurn offers token-level cost dashboards. Start with whatever provides utilization and cost data for your primary tool stack. ## Sources - [DX AI Coding ROI Guide](https://getdx.com/blog/ai-coding-assistant-pricing/) - Framework and benchmark data from 400+ organizations - [Journi DevOS Announcement](https://martechseries.com/predictive-ai/ai-platforms-machine-learning/journi-launches-devos-to-help-organisations-measure-the-roi-of-ai-coding-tools/) - Platform launch and capabilities - [Larridin Developer Productivity Benchmarks 2026](https://larridin.com/developer-productivity-hub/developer-productivity-benchmarks-2026) - AI-native productivity metrics - [GitLab AI Governance Research](https://www.infoq.com/news/2026/06/ai-coding-outpaces-governance/) - AI tools accelerating coding but not delivery - [METR Developer Productivity Study](https://metr.org/blog/2026-02-24-uplift-update/) - Controlled productivity experiment methodology

If You're a Button, You Have One Job: The Case for Responsive UI

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

A surprisingly engaging debate broke out on Hacker News this week over a topic that sounds trivial: how should a photo rotation button behave when you tap it multiple times quickly? Marcin Wichary's post "[If you're a button, you have one job](https://unsung.aresluna.org/if-youre-a-button-you-have-one-job/)" uses this seemingly simple interaction to surface fundamental principles about responsive interface design - principles that remain just as relevant in 2026 as they were in the era of command-line interfaces. ## The Problem: Animations That Block Input Wichary compares how iPhone and Nothing Phone (Android) handle rapid taps on an image rotation button. He taps eight times quickly - which should return the image to its original orientation (8 x 90 degrees = 720 degrees = 2 full rotations). **iPhone's approach**: Buffers all eight taps. The rotation animation queues up and executes sequentially. Every tap counts. **Nothing Phone's approach**: Ignores taps while the animation is playing. You get haptic feedback (the phone vibrates), but the tap is discarded. Only the first tap and the last tap register. The result? On iPhone, you end up where you expected. On Nothing Phone, you're stuck at some unexpected orientation and have to pay attention, count taps, and wait for animations to finish before tapping again. ## Why This Matters More Than You Think This might seem like a minor annoyance for a rotation button. But Wichary makes a compelling case for why it reveals something fundamental about good interface design. The core principle: **never force the user to wait for the animation to finish**. There are two acceptable approaches: 1. **Buffer inputs** - queue up pending actions and execute them in sequence 2. **Interrupt animations** - immediately jump to the new state when a new input arrives What's not acceptable is blocking input while showing visual feedback (haptics, button depress animation) that suggests the input was received. That's a lie your interface is telling the user. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48790689) with 223 comments touches on several deeper threads. **The THERAC-25 connection**: Multiple commenters drew parallels to the infamous radiation therapy machine disaster, where experienced users hitting keys faster than the interface could process them led to safety features being bypassed. The lesson: input handling bugs are not just UX annoyances - they can have serious consequences. **Animation fatigue**: Several iOS users vented frustration about Apple's increasing use of animations that serve no functional purpose. One commenter noted that Apple Maps wastes 1-2 seconds slowly rotating from your phone's orientation from days ago, even when you just want to see where you are now. **The "situational power user" insight**: Wichary's concept resonated strongly. Even casual apps occasionally serve serious purposes. Someone rotating dozens of document photos isn't being impatient - they need professional-grade reliability from a consumer tool. Your grandmother texting might need to tap a button 8 times to rotate a photo of her cat before sending it to you. **Keyboard buffering precedent**: Experienced developers pointed out that keyboard input buffering is a solved problem. We've had type-ahead working reliably since the 1970s. The problem is that touch interface designers forgot (or never learned) these lessons. **Skeuomorphism vs flat design tangent**: The thread wandered into a broader discussion about whether modern flat UI design has made interfaces harder to use by removing visual affordances. This is somewhat off-topic from Wichary's point, but the engagement shows how much developers care about these foundational UX questions. ## The Technical Implementation For developers, the fix is straightforward: ```typescript // Bad: Ignore input during animation const handleRotate = () => { if (isAnimating) return; // Don't do this setIsAnimating(true); rotate90(); setTimeout(() => setIsAnimating(false), 300); }; // Good: Buffer inputs const [pendingRotations, setPendingRotations] = useState(0); const handleRotate = () => { setPendingRotations(prev => prev + 1); }; useEffect(() => { if (pendingRotations > 0 && !isAnimating) { setIsAnimating(true); rotate90(); setTimeout(() => { setIsAnimating(false); setPendingRotations(prev => prev - 1); }, 300); } }, [pendingRotations, isAnimating]); ``` Or even simpler - skip the animation entirely when multiple inputs arrive: ```typescript const handleRotate = () => { if (isAnimating) { // Skip to final state immediately cancelAnimation(); } rotate90(); }; ``` The choice between buffering and interrupting depends on context. For rotation, buffering makes sense because users expect their taps to accumulate. For navigation, interrupting might be better - if a user taps a different menu item, they want to go there, not queue up both destinations. ## The Deeper Lesson Wichary's post is part of his broader "Unsung" series about overlooked aspects of interaction design. The underlying message: the best interfaces are the ones you don't notice. They respond instantly, predictably, and never make you wait or think about how to use them. This applies beyond buttons: - **Form submissions** should disable the submit button OR show a spinner and buffer the submission, not ignore repeated clicks - **Scrolling** should always respond, even while loading content - **Typing** should never lag, even in JavaScript-heavy apps - **Gestures** should provide immediate visual feedback, even if the underlying operation takes time In an era where we're building increasingly complex AI-powered interfaces, these fundamentals matter more than ever. Your agent might take 30 seconds to process a request - but the button that triggers it should respond in 30 milliseconds. ## Why Developers Should Care Interface responsiveness isn't just about polish. It's about trust. When a user taps a button and nothing happens, they lose confidence in the entire system. They start double-tapping, triple-tapping, wondering if the app is frozen. That uncertainty cascades into frustration. The fix is almost always simple. It's just that nobody prioritizes it. Animations ship because they look good in demos. Input buffering doesn't ship because it's invisible - until its absence makes the user feel like they're fighting their own device. As one HN commenter put it: "The best UI is the one that makes you feel like you're in control, not like you're waiting for permission." ## Sources - [If you're a button, you have one job](https://unsung.aresluna.org/if-youre-a-button-you-have-one-job/) - Marcin Wichary's original post - [Hacker News discussion](https://news.ycombinator.com/item?id=48790689) - 223 comments - [THERAC-25 Wikipedia](https://en.wikipedia.org/wiki/Therac-25) - referenced in HN comments - [Show Your Hands, Honor](https://aresluna.org/show-your-hands-honor/) - related post by the same author

Cheap subagents are better when their work is visible

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [DeepSeek pricing](https://felloai.com/deepseek-pricing/) | Current DeepSeek V4 Flash and V4 Pro per-token rates | | [Claude Code subagents](https://code.claude.com/docs/en/sub-agents.md) | Subagents run in their own context window with restricted tools | | [Codex CLI subagents](https://developers.openai.com/codex/cli/features) | Codex subagent workflows for parallelizing larger tasks | | [AgentCanvas](/agentcanvas) | The board cheap subagents write to | The economics of subagents flipped in 2026. DeepSeek V4 Flash is [$0.14 per million input tokens and $0.28 per million output tokens](https://felloai.com/deepseek-pricing/). GLM-5.2 is open-weights and effectively free if you host it. Kimi is in the same band. At those prices you can afford to spin up a dozen sidecar subagents to draft, explore, and sketch - work you would never pay frontier-model prices for. The reason most people do not do this is not cost. It is that the output of a cheap subagent is usually invisible. It lives in a transcript nobody opens, in a context window that closes when the subagent returns, and the only thing that survives is a one-line summary. Cheap work you cannot inspect is just expensive noise. ## The visibility problem [Subagents](https://code.claude.com/docs/en/sub-agents.md) are designed to isolate context. Each one runs in its own fresh conversation, does its work, and returns a single text result to the parent. The intermediate tool calls and outputs stay inside the subagent. That is the feature: the parent's context stays clean. It is also the trap. When the subagent is cheap and exploratory, the interesting part is the exploration - the drafts it tried, the options it sketched, the dead ends it hit. All of that gets thrown away by design. You paid $0.004 for a subagent to explore five approaches and you get back "approach 3 looks best" with no evidence. This is the same dynamic covered in the [agent teams playbook](/blog/claude-code-agent-teams-subagents-2026): specialization is good, but specialization without a shared surface means every handoff is lossy. The fix for cheap subagents is the same as the fix for expensive ones: give them a place to put the work where a human or another agent can look at it. ## Make the cheap lane inspectable The move is to point every cheap subagent at the same [AgentCanvas](/canvas) board. Instead of returning a summary, the subagent calls `create_html_asset` to pin its drafts, `create_image_asset` to attach sketches, and `append_html` to stream its reasoning as it goes. Now the economics work the way they are supposed to: - A DeepSeek subagent drafts three landing-page variants and pins each as an HTML asset. You see all three. Cost: a few cents. - A GLM subagent sketches an architecture and attaches the diagram. You see the diagram, not a description of it. Cost: effectively free. - A Kimi subagent explores a refactor and streams its notes live. You watch it think. Cost: negligible. The subagent still runs in its own context window, so your main agent's context stays clean. The difference is that the output is on a board instead of trapped in a transcript. When the work is visible, cheap subagents stop being a gamble and start being a pipeline. ## When to use the cheap lane Not every task belongs on a cheap model. The pattern that works: - **Drafts and exploration** - cheap. Spin up three DeepSeek subagents, each exploring a different direction, all writing to the same board. Pick the winner. - **Final implementation and review** - expensive. Use Claude Code or Codex for the work that ships. The cost-quality tradeoff for frontier coding is covered in the [Fable 5 vs DeepSeek V4 cost-quality breakdown](/blog/fable-5-vs-deepseek-v4-cost-quality). - **Sketched artifacts** - cheap. Let a cheap model produce the first pass of a doc, a diagram, or a slide. Promote it to a frontier model only if the first pass is not good enough. The decision is not really about which model is best. It is about which model is cheap enough that you can run it speculatively without flinching. For the budget end, the [DeepSeek V4 budget coding agents guide](/blog/deepseek-v4-budget-coding-agents) and the [GLM-5.2 cost math](/blog/glm-5-2-cost-math-open-weights-coding-models) walk through the numbers. ## Why a board beats a folder You could argue the same thing is achievable by having subagents write files to a directory. You can. The difference is that a directory is a flat list and a canvas is a layout. When three subagents each produce two drafts, a directory gives you six files with no relationship. A canvas gives you three columns, each with its drafts stacked, and you can see at a glance which lane is winning. That spatial structure is the whole point of [AgentCanvas](/agentcanvas). It is what turns cheap speculative subagents from a pile of files into a reviewable workspace. ## FAQ ### What is a cheap subagent? A subagent running on a low-cost model like DeepSeek V4 Flash, GLM-5.2, or Kimi, used for drafts, exploration, and speculative work where the cost is low enough to run several in parallel. ### Why do cheap subagents need visibility? Because their value is in the exploration, not the summary. Subagents return only a single text result to the parent, so the drafts and sketches they produced are lost unless they are written somewhere persistent. ### How does AgentCanvas help? It gives subagents MCP tools to pin HTML docs, images, and video to a shared board. The subagent's full output stays visible to humans and to other agents instead of being discarded with the subagent's context window. ### Does this work with Claude Code subagents? Yes. Claude Code subagents inherit MCP tools from the parent by default, so a subagent can call the AgentCanvas tools to write its work to the board. ### When should I not use a cheap subagent? For final implementation, security review, and anything that ships directly. Use cheap subagents for the speculative first passes and frontier models for the work that has to be right.

Flipper Zero Shifts to Community-Driven Development

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

Flipper Zero, the pocket-sized multi-tool for hackers and security researchers, has announced a major shift in how its firmware will be developed going forward. The company says their firmware has reached a "stable 1.0" state, and they're reallocating resources toward new hardware products while establishing a framework for community contributions. The announcement hit Hacker News with 151 points and sparked discussion about the device's utility, the relationship between official and custom firmwares, and the broader question of when software can simply be considered "done." ## What's Changing According to the blog post, Flipper Devices has accomplished their original firmware goals. Dynamic app loading resolved the memory constraints that previously limited the platform, and the core functionality is stable. Here's what the new model looks like: **GitHub Discussions for feature requests:** Community members can vote on proposed features, with the development team reviewing requests weekly based on voting results. **Stricter pull request guidelines:** The team has updated their contribution guide with more careful evaluation of code submissions, particularly for AI-generated code and UI changes. **Integration testing requirements:** Contributors must run mandatory integration and regression tests before submitting changes. **Asynchronous communication only:** With the user base growing beyond one million devices, direct real-time communication is being replaced with formal GitHub-based requests. The TL;DR from the post: "We've allocated resources to maintain Flipper Zero firmware and support community contributions." But as one HN commenter noted, this still sounds like "minimal life support." ## What HN Is Saying The discussion revealed a split between users who see this as abandonment and those who appreciate software being declared "finished." **On the value of Flipper Zero:** One owner shared practical use cases: "Being able to copy RFID keys is occasionally fantastically useful." Others described it as "a computer Swiss Army knife" and "so fun to carry around a tool of my own trade." For those unfamiliar, the device is essentially a multi-tool for short-range communications: RFID/NFC reading and emulation, sub-GHz radio protocols (garage doors, car key fobs), infrared (TV remotes), and more. **On "done" software:** A commenter quoted a post making the rounds: "We need to normalize declaring software as finished. Not everything needs continuous updates to function. In fact, a minority of software needs this. Most software works as it is written. The code does not run out of date." This resonated with developers tired of the expectation that every project must be continuously developed. The counterpoint: hardware security tools arguably do need updates as new protocols emerge and vulnerabilities are discovered. **On custom firmwares:** The most heated exchanges involved the relationship between official and community firmwares like Momentum and Xtreme (now Momentum). These custom firmwares include features that the official team removed or never added - often pentesting tools with legal gray areas. One user was blunt: "I abandoned the 'official crap' when they purged legit pentesting tools and silenced loads of others. Momentum and Xtreme were so much better. And if you mention ANY of the alternate firmwares on their discord, you get banned." A Flipper developer responded in the thread, explaining the reasoning: "Many legit but questionable features blown out of proportion already caused many issues with regulators who just don't want to get into details, but just delist from sales/ban the device. And once you start talking about 'jamming' and other stuff which is straight up illegal, don't get offended when that gets removed." **On RFID security (or lack thereof):** A side thread developed about why RFID key copying even works. The answer: many systems are shockingly insecure. "RFID keys vary from utterly dumb ID-based, to hackable challenge-response, to actual NFC smartcard (very rare). Some of that can be trivially cloned." One commenter warned about rolling code systems: "If the card emulator doesn't store the rolling code, you are completely locked out" - a trap for the unwary. ## The Bigger Picture Flipper Zero's situation illustrates a tension in open-source hardware. The device was marketed as a hacker tool, but success brought regulatory scrutiny. Countries like Brazil and Canada have had issues with the device at customs. The official firmware became more conservative as a result. The custom firmware ecosystem filled the gap. Projects like Momentum bundle pentesting tools and features that the official team won't touch. This creates a two-tier system: the official firmware for compliance-sensitive users, and custom builds for those who want the full toolkit. The shift to community-driven development could go either way. If the community is truly empowered to contribute, the official firmware could become more capable over time. If it's just a polite way of saying "we're moving on," users will continue migrating to custom firmwares. For developers interested in the device, the custom firmware ecosystem is arguably more interesting anyway. Momentum in particular has an active development community and supports additional hardware modules like e-paper displays. ## FAQ ### What is Flipper Zero actually used for? It's a multi-protocol radio tool. Common uses include: copying RFID key fobs (apartment building access, hotel rooms), controlling infrared devices (TVs, AC units), testing sub-GHz protocols (garage doors, car key fobs), NFC payments testing, and GPIO hacking. It's popular among security researchers and penetration testers. ### Is it legal to own? In most countries, yes. The legality depends on what you do with it. Cloning your own building's key fob is generally fine. Cloning someone else's is not. Jamming signals is illegal in most jurisdictions regardless of device. ### What's the difference between official and custom firmware? Official firmware excludes some pentesting features to avoid regulatory issues. Custom firmwares like Momentum include expanded protocol support, additional apps, and features that the official team removed or declined to add. Switching between them is straightforward. ### Should I get one? If you're a security researcher, pentester, or just curious about radio protocols, it's a useful tool. If you're looking for something to "hack the planet" with - manage expectations. Most of what it does is either already possible with cheaper specialized tools or legally questionable to actually use. ## Sources - [The future of Flipper Zero development - Official Blog](https://blog.flipper.net/future-of-flipper-zero-development/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48796552) - [Momentum Firmware](https://momentum-fw.dev/)

A Free Compilers Textbook That Actually Teaches You to Build One

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

Compiler construction has a reputation as one of the most intimidating topics in computer science. The classic textbooks - the Dragon Book, the Tiger Book - are dense, math-heavy, and often feel disconnected from practical implementation. But Prof. Douglas Thain's "Introduction to Compilers and Language Design," a free textbook from the University of Notre Dame, takes a different approach: it actually has you build a working compiler. The book hit the front page of Hacker News today with 248 points and sparked a lively discussion about compiler education, the accessibility of the field, and what it really takes to understand language implementation. ## What the Book Covers The textbook is designed for a single undergraduate semester. It targets students with programming experience in C and some background in data structures and computer architecture. The second edition (2020) spans 12 chapters: - Scanning (lexical analysis) - Parsing (syntax analysis) - Abstract syntax trees - Semantic analysis - Intermediate representation - Memory organization - Assembly language (both X86 and ARM) - Code generation - Optimization By the end, you've built a functional compiler that processes a C-like language called B-Minor and generates real assembly code. The appendices include a complete course project specification, the B-Minor language spec, and coding conventions to follow. The book is available as a free PDF, with optional hardcover and paperback editions for purchase. It comes with GitHub repositories containing code examples, starter templates, and test cases. ## What HN Is Saying The discussion on Hacker News covered several interesting threads about compiler education and practice. **On the accessibility of compiler work:** One commenter who switched from web development to a compiler engineering job shared their path: they started by reading resources like the Cornell CS 6120 course materials and watching lecture playlists, then implemented a small custom language that compiled to LLVM IR and eventually WebAssembly. Their key point: "LLVM itself is huge, it is not trivial to be familiar with every area, but writing not-complex passes, bug fixing, regression fixing does not require some fancy knowledge." **On starting simple:** A commenter with decades of experience noted that "assembly generation is actually pretty simple - it's optimizing everything that's difficult. Writing an assembler is a great way to get acquainted with compiler construction, because you don't need to think about optimization and types." Another shared their approach of starting a compiler by allowing only inline assembly first, then wrapping higher-level constructs around it: "It adds a little bit of complexity, but it worked surprisingly well, and it makes it easy to build up the complexity step by step." **On what's missing:** Some pointed out that the book is really "intro to compilers" rather than true language design. One commenter noted: "Just scanning the table of contents and I don't see any of the major topics of language design." For language design specifically, commenters recommended: - Types and Programming Languages (TAPL) by Benjamin C. Pierce - for understanding type systems - Programming Language Pragmatics (PLAI) - available free at plai.org - Essentials of Programming Languages - for working through interpreters with progressively more features **On the Dragon Book comparison:** The preface to the 2006 Dragon Book edition suggests it's largely graduate-level material: "It takes at least two quarters or even two semesters to cover all or most of the material in this book." Thain's book is explicitly designed for a single undergraduate semester, making it more approachable for self-learners. **Personal testimonials:** A former student chimed in: "Took Dr. Thain's compilers class in college! It was the best. He's an excellent instructor, and the course project made me build a working C-style compiler step by step. I think the sample project here is pretty much the project we did; highly recommend following through the entire thing!" ## Why This Matters Compiler construction is experiencing a quiet renaissance. With the rise of domain-specific languages, LLVM making backends more accessible, and WebAssembly providing a portable compilation target, more developers are finding reasons to understand how languages work at a fundamental level. For AI tool developers specifically, understanding parsing and semantic analysis is increasingly relevant. Language models that work with code need to understand structure, not just text. Tools like tree-sitter have made syntax-aware code manipulation mainstream. And the emerging space of "AI programming languages" - languages designed to be written by or for LLMs - requires thinking deeply about language design. If you've ever been curious about compilers but found the standard resources intimidating, Thain's book is worth your time. The combination of free access, practical focus, and a single-semester scope makes it one of the most accessible entry points available. ## Getting Started The book is available at [dthain.github.io/books/compiler](https://dthain.github.io/books/compiler/). The GitHub repositories with code examples and starter projects are linked from the site. If you want to go deeper after finishing, the HN thread suggests: - C4 and C4x86: a tiny, self-compiling C-subset compiler that makes a great study project - The Cornell CS 6120 course materials for more advanced topics - TAPL for type system theory ## FAQ ### Is this book suitable for self-study? Yes. The book is designed for classroom use but includes all the materials needed for self-study: complete project specifications, test cases, and code examples. The writing style is accessible and practical. ### Do I need to know assembly language first? Some background helps, but the book covers assembly language in its own chapter. You'll learn X86 and ARM assembly as part of the project, not as a prerequisite. ### How long does it take to work through? The book is designed for a single semester course. Working through it independently, expect to spend 3-6 months depending on your pace and how deeply you engage with the project. ### Is this the same as the Dragon Book? No. The Dragon Book is a comprehensive reference that covers compiler theory in depth but can be overwhelming. Thain's book is more practical and focused - you build one working compiler rather than learning everything about compiler theory. ## Sources - [Introduction to Compilers and Language Design - Douglas Thain](https://dthain.github.io/books/compiler/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48793454) - [PLAI - Programming Languages: Application and Interpretation](https://www.plai.org/) - [Cornell CS 6120 - Advanced Compilers](https://www.cs.cornell.edu/courses/cs6120/2020fa/self-guided/)

GPT-5.6 Sol Developer Guide: What You Can Build Today and What You're Waiting For

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | OpenAI GPT-5.6 Preview Announcement | [openai.com/index/previewing-gpt-5-6-sol](https://openai.com/index/previewing-gpt-5-6-sol/) | | GPT-5.6 Help Article | [help.openai.com/en/articles/20001325](https://help.openai.com/en/articles/20001325-a-preview-of-gpt-56-sol-terra-and-luna) | | OpenAI API Pricing | [openai.com/api/pricing](https://openai.com/api/pricing) | | OpenAI Models Documentation | [platform.openai.com/docs/models](https://platform.openai.com/docs/models) | | Terminal-Bench 2.1 Evaluation | [github.com/terminal-bench](https://github.com/terminal-bench/terminal-bench) | **Last updated:** July 5, 2026 GPT-5.6 Sol is OpenAI's new frontier model, announced June 26, 2026. If you're reading this hoping to flip a flag and start building, I have bad news: you probably can't use it yet. The model launched as a limited preview under government-imposed access restrictions, with around 20 approved organizations able to access it through the API and Codex. That said, the three-tier Sol/Terra/Luna pricing structure and the benchmark numbers OpenAI has shared tell us what to expect when general availability arrives. This guide covers what we know, what we're still waiting on, and how to prepare your codebase now so you can migrate fast when the API opens up. ## The Three-Tier Model Family GPT-5.6 ships as a family of three models, each optimized for different workloads. This is a shift from the previous pattern where you had a base model and a "Pro" variant. Now you get three distinct tiers with clear use-case separation. | Model | Target Workload | Input ($/MTok) | Output ($/MTok) | Cache Write | Cached Read | |-------|-----------------|----------------|-----------------|-------------|-------------| | **Sol** | Complex reasoning, agentic tasks, coding, security | $5.00 | $30.00 | $6.25 | $0.50 | | **Terra** | Production workloads, everyday tasks | $2.50 | $15.00 | $3.125 | $0.25 | | **Luna** | High-volume, latency-sensitive applications | $1.00 | $6.00 | $1.25 | $0.10 | Cache mechanics: writes are billed at 1.25x the uncached input rate, and cached reads receive a 90% discount. That makes the caching story significantly better than previous generations. **Sol** is the flagship. Use it when correctness matters more than cost: agentic coding workflows, security research, multi-step planning, and anything where a wrong answer creates real problems. **Terra** is positioned as the balanced option - near GPT-5.5 performance at roughly half the cost. This is likely where most production traffic will land when GA arrives. **Luna** is the fast, cheap tier. Think chatbots, classification, real-time applications, and anywhere latency beats everything else. OpenAI also mentions a **Sol Ultra** mode that pushes maximum reasoning capability through extended compute, similar to how GPT-5.5 Pro worked with high effort settings. Ultra mode uses subagent-based decomposition for parallel workflows on complex tasks. ## Benchmark Performance OpenAI's evaluation data is still sparse, but the numbers we have suggest meaningful improvements in specific domains. **Terminal-Bench 2.1** (agentic coding benchmark): - Sol Ultra: 91.9% (state-of-the-art) - Sol base: 88.8% - Claude Mythos 5: 88.0% - GPT-5.5: 88.0% The 3.1-point gap between Ultra and base mode reflects increased compute spending for multi-step agentic problems. For straightforward tasks, Sol base is probably sufficient. **GeneBench v1** (genomics analysis): Sol uses fewer tokens than GPT-5.5 while producing stronger results on quantitative biology tasks. No specific scores published yet. **Cybersecurity**: OpenAI describes Sol as the "strongest model for cybersecurity so far" with vulnerability research capability. The important qualifier: it "does not autonomously generate a full usable attack chain" in their testing. That's a safety boundary, not a capability gap. Context window size hasn't been officially published. Rumors mention 1.5M tokens, but verify against the official docs when they update. ## Current Availability Status As of July 5, 2026, GPT-5.6 is in limited preview: - **Who has access:** Around 20 organizations approved through a government vetting process - **How to get access:** There is no public application or waitlist. Participation requires an OpenAI account representative and government approval - **When will it open:** OpenAI says "in the coming weeks" with no specific date announced - **Rollout plan:** Staggered by subscription tier (Plus, Pro, Team, Enterprise) once restrictions lift The access restrictions stem from the model's capabilities in cybersecurity and biology research. The U.S. government requested vetting of approved organizations before broad deployment. If you need frontier model capabilities right now, GPT-5.5 and GPT-5.5 Pro remain generally available. For agentic coding specifically, Claude Fable 5 (restored July 1, 2026) and Claude Sonnet 5 offer strong alternatives while you wait. ## How to Prepare Your Codebase You can't use GPT-5.6 yet, but you can prepare for migration now. Here's what I'm doing in production codebases that will switch when GA drops. ### Abstract model selection If you're hardcoding `model: "gpt-5.5"` everywhere, now is the time to fix that. Use a configuration layer that lets you swap models without touching application code. ```typescript // config/models.ts export const models = { fast: process.env.MODEL_FAST || "gpt-5.5", balanced: process.env.MODEL_BALANCED || "gpt-5.5", flagship: process.env.MODEL_FLAGSHIP || "gpt-5.5-pro", } as const; // When GPT-5.6 GA drops, update .env: // MODEL_FAST=gpt-5.6-luna // MODEL_BALANCED=gpt-5.6-terra // MODEL_FLAGSHIP=gpt-5.6-sol ``` ### Update your caching strategy The 90% discount on cached reads makes prompt caching significantly more attractive. If you're not using prompt caching today, the 5.6 pricing structure is a reason to start. ```typescript import OpenAI from "openai"; const client = new OpenAI(); // Build cacheable system prompts const systemPrompt = await client.responses.create({ model: "gpt-5.6-terra", // swap when available input: [ { role: "system", content: buildSystemPrompt(context), // make this deterministic }, { role: "user", content: userMessage }, ], // Cache hits will cost 90% less on input }); ``` ### Plan your tier routing The three-tier model means you'll want routing logic. Not every request needs Sol. ```typescript type Complexity = "simple" | "standard" | "complex"; function selectModel(complexity: Complexity): string { const modelMap = { simple: "gpt-5.6-luna", standard: "gpt-5.6-terra", complex: "gpt-5.6-sol", }; return modelMap[complexity]; } // In your agent or pipeline const model = selectModel(taskComplexity); const response = await client.responses.create({ model, input: taskPrompt, }); ``` ### Set up parallel evaluation When GA arrives, you'll want to compare 5.6 against your current stack on real traffic. Build the eval harness now. ```typescript async function compareModels(prompt: string, expected: string) { const [current, next] = await Promise.all([ runWithModel("gpt-5.5", prompt), runWithModel("gpt-5.6-terra", prompt), // swap when available ]); return { currentAccuracy: score(current, expected), nextAccuracy: score(next, expected), currentCost: current.usage.total_tokens * CURRENT_PRICE, nextCost: next.usage.total_tokens * NEXT_PRICE, }; } ``` ## The Real Decision: Wait or Ship The practical question for most developers is whether to wait for GPT-5.6 or ship with what's available now. **Wait if:** - Your application has hard requirements in cybersecurity or biology research - You're building infrastructure that will scale and want to optimize for the best available model - You have time and can absorb the schedule uncertainty **Ship now if:** - You have a product deadline - GPT-5.5 or Claude Sonnet 5/Fable 5 meet your quality bar - You're building something where model-agnostic architecture matters more than peak capability The frontier keeps moving. Whatever you build today will need to handle model upgrades anyway. If your architecture is clean, switching to 5.6 when it drops should be a configuration change, not a rewrite. ## Cerebras Deployment One interesting deployment note: OpenAI announced that GPT-5.6 will be available on Cerebras inference hardware starting July 2026, with speeds up to 750 tokens per second. For latency-sensitive applications, that's a meaningful improvement over standard deployment. This suggests OpenAI is expanding its inference partnerships, which could affect pricing and availability for high-volume customers. ## The Take GPT-5.6 Sol represents a meaningful step forward for agentic and coding workloads, with the Terminal-Bench 2.1 numbers showing real improvement over GPT-5.5 and competitive positioning against Claude Mythos 5. The three-tier pricing structure (Sol/Terra/Luna) gives developers clearer cost-to-capability tradeoffs than previous generations. The frustrating part is availability. A limited preview with government access restrictions means most developers are waiting with no clear timeline. If you need frontier capabilities today, GPT-5.5 Pro and Claude Fable 5 are your options. My recommendation: prepare your codebase for easy model swaps, build evaluation harnesses against your real traffic, and ship with what works now. When GPT-5.6 opens up, you want the migration to be a single-line config change, not a scramble. ## FAQ ### When will GPT-5.6 Sol be generally available? OpenAI says "in the coming weeks" but has not announced a specific date. The limited preview began June 26, 2026 with around 20 approved organizations. General availability will likely roll out by subscription tier (Plus, Pro, Team, Enterprise) once government restrictions lift. ### Why is GPT-5.6 access restricted? The U.S. government requested vetting of approved organizations before broad deployment due to the model's capabilities in cybersecurity vulnerability research and biology analysis. This is a safety measure, not a capacity constraint. ### How does GPT-5.6 Sol pricing compare to GPT-5.5? Sol ($5/$30 per MTok) is priced higher than GPT-5.5 for flagship capability. Terra ($2.50/$15) is positioned at roughly half the cost of GPT-5.5 with near-equivalent performance. Luna ($1/$6) is the budget tier for high-volume, latency-sensitive workloads. The 90% cached read discount makes caching significantly more attractive. ### What is GPT-5.6 Sol Ultra mode? Sol Ultra is a high-effort variant that pushes maximum reasoning capability through extended compute and subagent-based decomposition. On Terminal-Bench 2.1, Ultra scores 91.9% versus Sol base at 88.8%. Use Ultra for the hardest agentic and reasoning tasks where cost is secondary to correctness. ### Should I wait for GPT-5.6 or use GPT-5.5 now? Ship with GPT-5.5 or Claude alternatives if you have a product deadline. The availability timeline is uncertain and GPT-5.5 is production-ready. Build your architecture to support easy model swaps so you can migrate quickly when GPT-5.6 opens up. ### What is the GPT-5.6 context window size? OpenAI has not officially published the context window size for GPT-5.6. Unofficial reports mention 1.5 million tokens, but verify against the official documentation when it updates. ### Can I use GPT-5.6 in Codex today? GPT-5.6 is available through Codex for the limited preview organizations with government approval. General Codex access will expand with broader API availability. ### How does GPT-5.6 compare to Claude Fable 5 for coding? On Terminal-Bench 2.1, Sol base scores 88.8% and Sol Ultra scores 91.9%, compared to Claude Mythos 5 at 88.0%. For agentic coding, both are strong choices. Claude Fable 5 was restored on July 1, 2026 and is immediately available, while GPT-5.6 access is restricted. ## Sources - [OpenAI GPT-5.6 Preview Announcement](https://openai.com/index/previewing-gpt-5-6-sol/) - [GPT-5.6 Help Center Article](https://help.openai.com/en/articles/20001325-a-preview-of-gpt-56-sol-terra-and-luna) - [GPT-5.6 Benchmarks and API Access Guide - Eden AI](https://www.edenai.co/post/gpt-5-6-sol-benchmarks-pricing-api-access-guide) - [GPT-5.6 Limited Preview Analysis - Knightli](https://knightli.com/en/2026/07/02/gpt-5-6-sol-limited-preview/) - [GPT-5.6 Pricing and Cost Optimization - Lushbinary](https://lushbinary.com/blog/gpt-5-6-pricing-cost-optimization-sol-terra-luna/) - [OpenAI GPT-5.6 Release Details - Senswit](https://senswit.com/blog/openai-gpt-5-6-release-2026)

The Log Is the Agent: Event Sourcing Comes to AI Systems

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

A short but provocative paper appeared on arXiv this week: "[The Log is the Agent](https://arxiv.org/abs/2605.21997)" by Yohei Nakajima (creator of BabyAGI). The core claim is simple but has significant implications for how we build AI agent systems. Most agent frameworks treat logging as an afterthought - something you bolt on for debugging and compliance. Nakajima argues we should flip this: make the append-only event log the source of truth, and derive all agent state from that log. ## The Core Idea Traditional agent architectures look like this: ``` LLM → State → Tools → World ↓ Logs (optional audit trail) ``` The "log is the agent" architecture inverts this: ``` Event Log (source of truth) ↓ Graph State (deterministic projection) ↓ Behaviors (react to graph changes, emit new events) ``` The key properties this enables: 1. **Deterministic replay** - you can reconstruct any agent run from its event log 2. **Cheap forking** - branch at any point without re-executing the shared prefix 3. **Full lineage** - trace from high-level goals down to individual model calls The paper introduces ActiveGraph, a runtime that implements this pattern. The graph is never mutated directly - behaviors react to graph changes and emit new events, which get appended to the log. The working graph is just a projection of the log state. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48790912) is notably technical, with several experienced developers recognizing the pattern immediately. **"The AI folks have discovered CQRS?"**: Multiple commenters pointed out that this is essentially [event sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) and [CQRS](https://martinfowler.com/bliki/CQRS.html), patterns that have been standard in distributed systems for over a decade. One commenter wryly noted that the paper is "presenting common ideas as novel without thinking through existing problems." **Practical implementations**: Several developers shared their own agent harnesses that use similar patterns. [Lightspeed](https://github.com/smartcomputer-ai/lightspeed) stores all context-affecting events in an event log, making forking trivial - just set a pointer to another sequence number. Another commenter is building a similar system on Elixir/Ash. **Cost concerns**: A valid critique: "wouldn't feeding that log for each request/response iteration get expensive really fast?" This is the elephant in the room. Event sourcing traditionally works well because replaying events is cheap. But LLM calls are expensive - replaying a conversation means paying for all those tokens again. The paper stores model responses in the log to avoid re-generation, but that's replay-as-recording, not true deterministic replay. **Write-ahead logs from databases**: One commenter with database experience noted that WAL (write-ahead log) patterns provide a natural interface between speculative agent work and durable world mutations. This connects to broader work on [stealing database ideas for AI agents](https://onewill.ai/blog/2026/stealing-50-years-of-database-ideas-for-ai-agents/). **Skepticism about the paper itself**: Some commenters were unimpressed by the paper's structure - "we discuss without claiming to demonstrate" raised eyebrows. Others noted the author is a VC rather than a researcher, though his BabyAGI work has been influential in the agent space. ## Why This Matters for Agent Developers Even if the core insight isn't novel, the paper articulates something important: most agent frameworks get state management wrong. Here's the problem. You start an agent session. It makes some tool calls. You want to: 1. Fork the session to try a different approach 2. Replay a failed run to debug it 3. Compact the context window without losing fidelity With most frameworks, this is surprisingly hard. The session state is scattered across: - The message history (mutable, often compacted) - Tool call results (sometimes stored, sometimes not) - Internal state (often in-memory only) - External side effects (irreversible) If you store raw events from the start - every user message, every assistant response, every tool call and result - you can derive any projection you need. Want to fork? Just point to an earlier sequence number. Want to compact? Generate a summary event and start a new log segment. Want to replay? Feed the events back through your projection logic. ```typescript // Event log approach interface AgentEvent { id: string; timestamp: number; type: 'user_message' | 'assistant_message' | 'tool_call' | 'tool_result' | 'compaction'; payload: unknown; parentId?: string; // For forking } // Current state is always derived function projectState(events: AgentEvent[]): ConversationState { return events.reduce((state, event) => { switch (event.type) { case 'user_message': return { ...state, messages: [...state.messages, event.payload] }; case 'compaction': return { ...state, messages: [event.payload.summary] }; // etc. } }, initialState); } ``` ## The Deeper Connection to Databases The paper's insight connects to a broader pattern: AI agents are essentially distributed systems with unreliable components (the LLM), and we should apply distributed systems patterns to them. The log-centric architecture echoes several database concepts: - **Write-ahead logging** - durability through append-only logs - **Event sourcing** - state as projection of events - **MVCC** - multiple versions (branches) from shared history - **Snapshot isolation** - consistent reads at a point in time As agents get more complex - longer runs, more tools, multi-step planning - these patterns become essential. You can't debug a 2-hour agent run by reading through 500 messages. You need structured replay, causal tracing, and the ability to "what if" from any point. ## Practical Implications If you're building agent systems, consider: 1. **Store raw events, not just messages** - tool calls, results, state changes, everything 2. **Make your log append-only** - never mutate past events, only append corrections 3. **Derive context windows from logs** - don't mutate the message array directly 4. **Design for replay** - can you reconstruct any session from its log? 5. **Think about forking** - how would you branch at turn 47 of a 100-turn session? The paper's [ActiveGraph implementation](https://activegraph.ai/) is available to try, though several commenters noted it's early-stage and the author's website doesn't even have a valid SSL cert. Whether or not you use ActiveGraph, the log-centric mental model is worth internalizing. As one commenter put it: "This paper points at an idea, but it's really only legible if you have a more developed version of the idea already." ## The "Just Event Sourcing" Critique The most common HN response was some variation of "this is just event sourcing." And they're right - the patterns are well-established. The contribution isn't inventing something new; it's applying known patterns to a domain where they're surprisingly underused. Most agent frameworks are still in the "mutate state directly" paradigm. They store message histories as mutable arrays, compact them in place, and lose fidelity in the process. The log-centric approach is more work upfront but pays dividends in debuggability, reproducibility, and composability. The AI community has a habit of rediscovering established CS patterns. Sometimes that's frustrating. Sometimes it's necessary - the old patterns need to be re-articulated for a new context. This paper does the latter, even if imperfectly. ## Sources - [The Log is the Agent](https://arxiv.org/abs/2605.21997) - Original arXiv paper - [Hacker News discussion](https://news.ycombinator.com/item?id=48790912) - 34 comments - [ActiveGraph](https://activegraph.ai/) - Paper's implementation - [Lightspeed agent harness](https://github.com/smartcomputer-ai/lightspeed) - Similar pattern in practice - [Event Sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) - Martin Fowler's canonical explanation

MCP tools need a shared board, not another transcript

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [MCP Tools specification](https://spec.modelcontextprotocol.io/specification/2025-03-26/server/tools/) | How MCP servers expose tools to models | | [MCP servers overview](https://modelcontextprotocol.io/docs/learn/server-concepts) | Tools, resources, and the model-controlled invocation model | | [Claude Code MCP integration](https://docs.anthropic.com/en/docs/claude-code/mcp) | Connecting Claude Code to external tools via MCP | | [AgentCanvas](/agentcanvas) | An MCP server whose tools write to a shared board | The [Model Context Protocol](/blog/what-is-mcp) did the hard part. It standardized how agents call tools. A server declares its tools through `tools/list`, the model invokes them through `tools/call`, and the result comes back as typed content. Any agent that speaks MCP can drive any server. That is a real win. What MCP did not standardize is what happens to the result after the model reads it. The tool output lands in the conversation, the model reasons over it, and then it scrolls up into the transcript and dies. For the next tool call that is fine. For the next agent, or the next human, it is a problem. ## Invocation is solved. Visibility is not. The [MCP spec](https://spec.modelcontextprotocol.io/specification/2025-03-26/server/tools/) is explicit that tools are model-controlled: the model discovers and invokes them automatically based on context. That means an agent with the right MCP servers can do a lot - query a database, run a browser, fetch a doc, generate an image. But the output of those calls has nowhere durable to go. A browser MCP returns a screenshot. It enters the transcript. The model looks at it. Then what? If a second agent needs that screenshot later, it has to call the browser MCP again. If a human needs it, they have to scroll. The tool did the work and the work disappeared. This is the gap that a shared board fills. Instead of the tool output living only in the conversation, the agent writes it to a canvas where it persists and where the next call can read it back. ## An MCP server whose output is a place [AgentCanvas](/canvas) is an MCP server, but its tools do not just return a result. They place a result. `create_image_asset` puts media on the board. `create_html_asset` puts a doc in a sandboxed iframe. `append_html` streams content in chunks so you watch it assemble. `list_assets` reads the board back. That changes the shape of an agent run. A browser agent attaches its screenshot to the canvas item it was checking. A research agent pins its findings as a doc. An image agent places the generated image next to the brief that asked for it. Every tool call leaves a visible artifact instead of a transcript line. The tools are standard MCP - they work with Claude Code, Codex, Cursor, or any harness that speaks the protocol. The difference is that the destination is a board, not stdout. ## Why this matters for multi-agent work The [Claude Code MCP docs](https://docs.anthropic.com/en/docs/claude-code/mcp) frame MCP as a way to give an agent access to external tools. That is correct but incomplete for teams of agents. When two agents share a set of MCP tools, they share the ability to act. They do not share a memory of what was done. A shared board is that memory. Agent A runs a workflow MCP and pins the run log. Agent B calls `list_assets`, sees the log, and picks up where A left off. No transcript pasted into context, no re-running the workflow to see what happened. The board is the handoff. This is the same argument made in [skills over MCP with progressive disclosure](/blog/skills-over-mcp-progressive-disclosure): the protocol is good at exposing capability, and bad at exposing state. A canvas is a lightweight way to add state without bolting a database onto every MCP server. ## When a board is overkill Not every MCP tool needs a board. The rule from [CLIs over MCPs](/blog/clis-over-mcps) still holds: if a tool duplicates something the agent already does natively, it is dead weight. A board is worth it when: - The tool output is something a human will want to look at (a screenshot, a doc, a generated image, a run log). - The output needs to survive past the current turn so a later agent or human can use it. - Multiple agents need to converge on the same set of artifacts. If the tool is a quick lookup that the model consumes and forgets, leave it in the transcript. The board is for the work, not the lookups. ## FAQ ### What does MCP not solve? MCP standardizes tool invocation - how an agent discovers and calls tools. It does not standardize where tool output goes after the model reads it, so results tend to die in the transcript. ### How does a shared board help MCP tools? A board gives tool output a durable, visible place. Instead of a screenshot living only in the conversation, the agent pins it to a canvas where the next agent and the next human can see it. ### Is AgentCanvas an MCP server? Yes. AgentCanvas exposes standard MCP tools like create_html_asset, create_image_asset, and list_assets. Any MCP-speaking agent can call them. The difference from a typical MCP server is that the tools write to a persistent board. ### Do I need a board for every MCP tool? No. Use a board when the tool output is something a human or a later agent will want to inspect - screenshots, docs, generated images, run logs. For quick lookups the model consumes and forgets, the transcript is fine. ### How is this different from writing tool output to files? Files work but they are a flat list with no spatial relationship. A canvas is a layout, so when several agents each produce several artifacts you can see which artifact belongs to which agent and which task at a glance.

Program-as-Weights Turns Prompts Into Local Fuzzy Functions

Developers Digest — Sun, 05 Jul 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [Program-as-Weights on arXiv](https://arxiv.org/abs/2607.02512) | Paper abstract, authors, submission date, core method, and headline results | | [Program-as-Weights on Hugging Face Papers](https://huggingface.co/papers/2607.02512) | Daily paper ranking, discussion entry, project page, and linked repository | | [Program-as-Weights project site](https://programasweights.com/) | Project framing and release links | | [Program-as-Weights Python repository](https://github.com/programasweights/programasweights-python) | Public code surface linked from the Hugging Face paper page | **Last updated:** July 5, 2026 The most interesting paper on Hugging Face this week is not another bigger model announcement. It is a paper about making some model calls smaller, local, and reusable. [Program-as-Weights](https://arxiv.org/abs/2607.02512), from Wentao Zhang, Liliana Hotsko, Woojeong Kim, Pengyu Nie, Stuart Shieber, and Yuntian Deng, proposes a programming pattern the authors call fuzzy-function programming. The idea is simple enough to be dangerous: write a natural-language function specification once, compile it into a compact neural artifact, then call that artifact locally instead of sending every input back through a large model API. That is a different mental model from most AI app architecture today. Right now, the default pattern for fuzzy work is runtime prompting. If you need to classify noisy logs, repair malformed JSON, label support tickets, rank search results by intent, normalize messy user input, or extract a weak signal from ambiguous text, you usually call a frontier or mid-sized model for every request. The Program-as-Weights paper asks whether some of that work should look more like compilation. Not "replace every LLM call." Not "agents are over." A narrower and more useful take: Some prompts want to become functions. ## What PAW Claims The paper instantiates the idea with Program-as-Weights, or PAW. The authors describe a 4B compiler trained on FuzzyBench, a 10 million example dataset they release. That compiler emits parameter-efficient adapters for a frozen lightweight interpreter. The headline result is the part developers will remember: a 0.6B Qwen3 interpreter executing PAW programs matches direct prompting of Qwen3-32B, while using roughly one fiftieth of the inference memory and running at 30 tokens per second on a MacBook M3. Treat those numbers as research claims, not production guarantees. The interesting part is the architectural shape. In the normal pattern, the foundation model is a per-input problem solver: ```txt input -> prompt -> large model -> output ``` In the PAW pattern, the foundation model becomes a tool builder: ```txt function spec -> compiler model -> compact weights input -> local interpreter + compact weights -> output ``` That is why the paper matters. If this class of method holds up, developers get a new category between deterministic code and live LLM calls: small neural functions that are cheap to run, local by default, and specialized to a narrow behavior. ## The Developer Shape: Fuzzy Functions Most production codebases already contain fuzzy functions. They just do not call them that. A fuzzy function is the kind of operation that has clear examples but messy boundaries: - "Is this log line important enough to page someone?" - "Does this user message contain a cancellation intent?" - "Which docs page best answers this vague support question?" - "Can this malformed JSON be repaired safely?" - "Is this pull request description a useful summary or a placeholder?" You can write rules for these tasks, but the rule set gets brittle fast. You can call an LLM, but then every request inherits API latency, cost, privacy exposure, provider availability, and model drift. The PAW bet is that some of these tasks are stable enough to compile. That should feel familiar to developers working with agent systems. In [Agent Memory Needs a Context Ledger](/blog/agent-memory-context-ledger), the core point is that long-running agents need a persistent structure outside the prompt. In [Agent Context Reduction Is a Product Pattern](/blog/agent-context-reduction-pattern), the useful pattern is to stop treating the context window as an infinite trash bag. PAW makes a related move at the function level: stop treating the largest model as the only place fuzzy behavior can live. The prompt is not the product. The reusable behavior is. ## Where This Could Fit First The early production targets are not glamorous. They are the boring calls that run thousands or millions of times. Start with high-frequency, low-drama classification and normalization: - log triage - routing support tickets - intent labeling - search-result reranking - lightweight moderation prefilters - noisy schema repair - document chunk quality scoring - agent trace summarization These are not places where you want a deeply creative model. You want a cheap, consistent, inspectable function with a known input and output contract. That is also why PAW sits next to model routing rather than replacing it. In [Model Routing Is Becoming the AI Infrastructure Layer](/blog/ai-model-routing-orchestration-layer), the practical advice is to route work by task shape, not brand loyalty. PAW adds another possible route: - deterministic code for exact behavior - compiled fuzzy functions for stable ambiguous behavior - small hosted models for flexible low-stakes tasks - frontier models for hard reasoning, planning, or generation The reason this is exciting is not that it removes model routing. It makes routing more granular. ## The Catch: Compilation Needs Evals The easiest bad version of this idea is obvious: compile a fuzzy function, ship it, and assume it behaves like code. It does not. A PAW artifact is still a learned behavior. It needs test sets, drift checks, calibration, and rollback. If a compiled log-triage function quietly stops recognizing a new class of production incident, the fact that it runs locally does not help you. That makes the eval harness more important, not less. For agent work, [Long-Running Agents Need Harnesses, Not Hope](/blog/long-running-agents-need-harnesses) makes the same argument: the model is only one piece of the system. The harness decides whether the behavior is useful enough to trust. For fuzzy functions, a practical harness should include: - a golden set of representative inputs - known hard negatives - recent production examples - latency and memory budgets - regression checks against the hosted-model baseline - a rollback path to the old runtime prompt The hosted model call is your baseline. The compiled artifact has to earn the right to replace it. ## Why This Is Different From Fine-Tuning It is tempting to file PAW under "fine-tuning, but smaller." That undersells the programming model. Fine-tuning usually asks you to train or adapt a model around a task family. PAW asks whether a natural-language function specification can produce a compact program-like weight artifact for one fuzzy function. The unit of reuse is not "our company support model." It is closer to: ```ts const isPagerWorthy = compileFuzzyFunction(` Return true only when this log line suggests user-facing impact, data loss, auth failure, payment failure, or sustained outage risk. `); ``` That pseudo-code is not copied from the PAW repository. It is the developer interface this research points toward. If that interface becomes real, AI engineering starts to look less like prompt sprawl and more like a typed library of fuzzy functions with benchmarks beside them. That connects directly to the skills conversation. In [Skills for Real Engineers Need Governance, Not Fandom](/blog/skills-for-real-engineers-governance), the argument is that reusable agent instructions should be governed like production controls. A compiled fuzzy function deserves the same treatment: owner, version, test set, intended scope, and deletion criteria. ## Opposing View: Most Prompts Should Stay Prompts The fair skeptical view is that most LLM calls are not stable enough to compile. Developers often use prompts because the target keeps moving. The input distribution changes. The product changes. The tolerance for false positives changes. A prompt is easy to tweak during that phase. A compiled artifact adds ceremony. That is a good objection. The right boundary is not "compile everything." It is "compile the calls whose shape has stabilized." If you are still discovering the behavior, keep the prompt. If the task is high-stakes and requires nuanced reasoning, keep the larger model and add review. If the call is stable, frequent, narrow, and expensive, PAW-style compilation becomes interesting. The other caveat is ecosystem maturity. The paper links a project page and a Python repository through Hugging Face, but this is still a research release. Before building production architecture around it, check the repository state, licenses, supported models, dataset access, and whether the benchmark tasks match your workload. ## The Practical Take Program-as-Weights is worth watching because it names a real pain in AI apps: too many fuzzy operations are trapped in per-request prompts. The durable idea is not the exact PAW implementation. It is the split between specification time and execution time. For developers, the useful question becomes: Which prompts in my system are actually functions? Find the calls that are stable, repetitive, narrow, and measurable. Keep the frontier model as the compiler or teacher. Move the hot path toward smaller local execution when the evals prove it works. That is a more grounded version of local AI than "run the biggest model on your laptop." It is also more useful. The win is not local chat. The win is local behavior that your app calls a thousand times without asking permission from a remote model. ## FAQ ### What is Program-as-Weights? Program-as-Weights is a research system for compiling a natural-language fuzzy function specification into compact neural weights that can run through a lightweight local interpreter. ### Is PAW a replacement for LLM APIs? No. It is better understood as a possible replacement for specific high-frequency, narrow, stable LLM calls. Frontier model APIs still make sense for open-ended reasoning, planning, creative generation, and tasks whose behavior is still changing. ### What kinds of tasks fit fuzzy-function programming? Good candidates include log classification, intent detection, search reranking, malformed JSON repair, support routing, document-quality scoring, and other tasks where examples are easy to gather but deterministic rules become brittle. ### Is Program-as-Weights production-ready? Treat it as promising research until you verify the code, license, supported models, and benchmark fit for your workload. The production pattern still needs evals, regression tests, drift checks, and a fallback to the original hosted-model path. ### Why does this matter for AI coding agents? Coding agents depend on many repeated fuzzy judgments: which file matters, whether a test failure is relevant, whether a patch summary is truthful, and whether a trace should be escalated. PAW-style artifacts suggest that some of those judgments could become local, benchmarked helper functions instead of live prompts. ## Sources - [Program-as-Weights: A Programming Paradigm for Fuzzy Functions](https://arxiv.org/abs/2607.02512), arXiv, submitted July 2, 2026. - [Program-as-Weights on Hugging Face Papers](https://huggingface.co/papers/2607.02512), checked July 5, 2026. - [Program-as-Weights project site](https://programasweights.com/), checked July 5, 2026. - [Program-as-Weights Python repository](https://github.com/programasweights/programasweights-python), checked July 5, 2026.

Claude Sonnet 5 Developer Guide: Migration, API, and Effort Levels

Developers Digest — Sat, 04 Jul 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Introducing Claude Sonnet 5](https://www.anthropic.com/news/claude-sonnet-5) | Anthropic official announcement (June 30, 2026) | | [Sonnet 5 Migration Guide](https://platform.claude.com/docs/en/about-claude/models/migration-guide) | Official migration documentation | | [What's New in Sonnet 5](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5) | Feature changelog | | [Effort Parameter Docs](https://platform.claude.com/docs/en/build-with-claude/effort) | Reasoning effort configuration | | [Prompting Claude Sonnet 5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5) | Prompting best practices | | [Claude Pricing](https://claude.com/pricing) | Current pricing for all Claude plans | Claude Sonnet 5 shipped on June 30, 2026 as Anthropic's most agentic Sonnet model yet. It's a drop-in replacement for Sonnet 4.6 - but "drop-in" doesn't mean zero changes. There are three breaking API changes that will hard-fail your code if you don't handle them, plus a new tokenizer that quietly increases your token counts by up to 35%. This guide covers what breaks, what to change, and how to use the new effort parameter to control reasoning depth. **Last updated:** July 4, 2026 ## Quick Migration Checklist Before updating your model ID, verify these four items: 1. **Update model ID:** `claude-sonnet-4-6` to `claude-sonnet-5` 2. **Remove sampling parameters:** Any `temperature`, `top_p`, or `top_k` set to non-default values returns a 400 error 3. **Remove manual extended thinking:** `thinking: {type: "enabled", budget_tokens: N}` returns a 400 error - use the new `effort` parameter instead 4. **Recount tokens:** The new tokenizer maps the same text to ~1.0-1.35x more tokens If your current code is simple (no sampling params, no extended thinking), the migration is just changing the model ID. Otherwise, read on. ## Breaking Change 1: Sampling Parameters Removed **What changed:** Requests that set `temperature`, `top_p`, or `top_k` to non-default values return a 400 error. **Why:** Anthropic's position is that sampling parameters introduce unpredictable output quality and are incompatible with adaptive thinking. Sonnet 5's reasoning process adjusts dynamically based on effort level, so manual sampling control isn't supported. **Migration:** ```typescript // Before (Sonnet 4.6) const response = await anthropic.messages.create({ model: "claude-sonnet-4-6", temperature: 0.7, top_p: 0.9, messages: [{ role: "user", content: "..." }] }); // After (Sonnet 5) - remove sampling params const response = await anthropic.messages.create({ model: "claude-sonnet-5", messages: [{ role: "user", content: "..." }] }); ``` If you were using low temperature for deterministic outputs, the replacement is using low effort level, which produces more consistent results with less exploration. ## Breaking Change 2: Manual Extended Thinking Removed **What changed:** Setting `thinking: {type: "enabled", budget_tokens: N}` returns a 400 error. **Why:** Sonnet 5 uses adaptive thinking that automatically adjusts based on task complexity. Instead of specifying a fixed token budget for reasoning, you set an effort level and the model allocates thinking tokens as needed. **Migration:** ```typescript // Before (Sonnet 4.6) const response = await anthropic.messages.create({ model: "claude-sonnet-4-6", thinking: { type: "enabled", budget_tokens: 10000 }, messages: [{ role: "user", content: "..." }] }); // After (Sonnet 5) - use effort parameter const response = await anthropic.messages.create({ model: "claude-sonnet-5", thinking: { type: "enabled", effort: "high" }, messages: [{ role: "user", content: "..." }] }); ``` The effort values are: `low`, `medium`, `high` (default), `max`, and `xhigh`. ## Breaking Change 3: Adaptive Thinking On By Default **What changed:** On Sonnet 4.6, requests without a thinking field ran without thinking. On Sonnet 5, the same requests run with adaptive thinking at `high` effort by default. **Impact:** Your existing prompts will use more tokens and potentially produce different outputs. This is usually an improvement, but it changes behavior. **To disable thinking entirely:** ```typescript const response = await anthropic.messages.create({ model: "claude-sonnet-5", thinking: { type: "disabled" }, messages: [{ role: "user", content: "..." }] }); ``` **To match Sonnet 4.6 behavior more closely:** Use `medium` effort, which Anthropic says is comparable to Sonnet 4.6 at high effort. ## The New Effort Parameter Sonnet 5's key feature is selectable reasoning effort. Instead of controlling thinking with a token budget, you set a semantic effort level. | Effort | Use Case | Cost | Default | |--------|----------|------|---------| | `low` | Simple classification, quick lookups, high-volume tasks | Lowest | No | | `medium` | Cost-saving step-down, comparable to Sonnet 4.6 at high | Low-Medium | No | | `high` | Complex reasoning, coding, agentic tasks | Medium | Yes | | `max` | Maximum quality for difficult problems | High | No | | `xhigh` | Advanced coding, complex agentic work requiring extended exploration | Highest | No | **Using effort in the API:** ```typescript const response = await anthropic.messages.create({ model: "claude-sonnet-5", thinking: { type: "enabled", effort: "xhigh" }, max_tokens: 16000, // Leave headroom for thinking messages: [{ role: "user", content: "Debug this failing test..." }] }); ``` **Important:** At `high`, `xhigh`, or `max` effort, leave headroom in `max_tokens` so the model has room for thinking and tool calls. ## Effort Level Decision Guide **Use `low` when:** - Processing high-volume batch tasks - Running simple classification - Speed matters more than depth - Tasks are well-scoped with clear outputs **Use `medium` when:** - Migrating from Sonnet 4.6 and want similar cost/quality - Tasks are moderately complex but routine - Balancing cost and capability **Use `high` (default) when:** - Running agents with tool use - Coding tasks with multiple files - Problems requiring chain-of-thought reasoning - Quality matters more than speed **Use `xhigh` when:** - Debugging complex multi-file issues - Agent sessions with many tool calls - Problems that would benefit from extensive exploration - You need maximum capability at the Sonnet tier **Use Opus 4.8 instead when:** - Running `xhigh` and costs are approaching Opus anyway - Tasks require the absolute highest capability - Agentic search or computer use (Opus is cheaper per success on these benchmarks) ## Tokenizer Impact Sonnet 5 uses an updated tokenizer. The same input text produces approximately 1.0-1.35x more tokens than Sonnet 4.6, depending on content type. **Practical impact:** - Prompts that fit in Sonnet 4.6's context may exceed limits in Sonnet 5 - Your per-request costs may increase even at the same per-token price - The introductory pricing ($2/$10) partially offsets this - Anthropic calls it "cost-neutral" **Migration steps:** 1. Re-run token counts on your prompts using Anthropic's token counting API 2. Check that long prompts still fit in the 1M context window 3. Revisit any `max_tokens` limits sized close to expected output length 4. Budget approximately 30% more tokens for the same workload ## Benchmarks at a Glance | Benchmark | Sonnet 5 | Sonnet 4.6 | Opus 4.8 | |-----------|----------|------------|----------| | SWE-Bench Verified | 85.2% | 72.1% | 91.6% | | SWE-Bench Pro | 63.2% | 58.1% | 73.5% | | Terminal-Bench 2.1 | 80.4% | 67.0% | 74.6% | | OSWorld-Verified | 81.2% | 78.5% | 87.3% | Sonnet 5 at 80.4% on Terminal-Bench 2.1 beats Opus 4.8's 74.6% - the first time a Sonnet model has outperformed its Opus sibling on a major coding benchmark. ## Pricing Summary | Period | Input ($/MTok) | Output ($/MTok) | |--------|---------------|----------------| | Now through Aug 31, 2026 | $2 | $10 | | After Aug 31, 2026 | $3 | $15 | The introductory pricing combined with the tokenizer change means: - At $2/$10, Sonnet 5 is genuinely cheaper than Sonnet 4.6 for most workloads - After August 31, costs will be roughly similar due to the ~30% token increase - For high-effort reasoning tasks, costs can approach Opus 4.8 levels ## Complete Migration Example Here's a full before/after showing all three breaking changes: ```typescript // Before: Sonnet 4.6 with all deprecated features const response = await anthropic.messages.create({ model: "claude-sonnet-4-6", temperature: 0.3, thinking: { type: "enabled", budget_tokens: 8000 }, max_tokens: 4000, messages: [{ role: "user", content: "Review this PR and suggest improvements..." }] }); // After: Sonnet 5 with equivalent intent const response = await anthropic.messages.create({ model: "claude-sonnet-5", thinking: { type: "enabled", effort: "high" }, max_tokens: 8000, // Increased for thinking headroom messages: [{ role: "user", content: "Review this PR and suggest improvements..." }] }); ``` ## When to Stay on Sonnet 4.6 Sonnet 4.6 remains available. Consider staying on it if: - You depend on sampling parameters (`temperature`, `top_p`, `top_k`) for your use case - You need precise control over thinking token budgets - You have a production system that's working and the migration isn't worth the risk - You're running high-volume workloads and the tokenizer increase matters to your margins Anthropic hasn't announced an EOL date for Sonnet 4.6 yet. ## FAQ ### What is the model ID for Claude Sonnet 5? The model ID is `claude-sonnet-5`. Use this in API calls to specify the model. The previous model ID `claude-sonnet-4-6` continues to work for Sonnet 4.6. ### Does Claude Sonnet 5 support extended thinking? Yes, but not manually. Sonnet 5 uses adaptive thinking controlled by the `effort` parameter (`low`, `medium`, `high`, `max`, `xhigh`). Setting a manual `budget_tokens` returns a 400 error. The model automatically allocates thinking tokens based on the effort level and task complexity. ### What is the context window for Claude Sonnet 5? Sonnet 5 has a 1M-token context window and 128K max output tokens. There is no long-context pricing premium - the same per-token rates apply regardless of context length. ### How much more do prompts cost with the new tokenizer? The same text maps to approximately 1.0-1.35x more tokens with Sonnet 5's tokenizer compared to Sonnet 4.6. Anthropic set introductory pricing to be "cost-neutral" overall, but your actual cost change depends on your content type and effort level. ### Is Claude Sonnet 5 available in Claude Code? Yes. Sonnet 5 is now the default model in Claude Code with a native 1M-token context window. Interactive Claude Code in the terminal uses your subscription limits; programmatic usage (Agent SDK, `claude -p`) draws from the API credit pool. ### When does the introductory pricing end? August 31, 2026. After that date, pricing moves from $2/$10 per MTok to $3/$15 per MTok. ### Should I use Sonnet 5 or Opus 4.8? Use Sonnet 5 at low/medium effort for high-volume, well-scoped tasks where cost matters. Use Opus 4.8 for complex, open-ended tasks or when you need maximum capability. At `xhigh` effort, Sonnet 5 costs approach Opus 4.8 while performing slightly worse on several benchmarks - at that point, Opus is often the better choice. ### Can I disable thinking in Sonnet 5? Yes. Pass `thinking: { type: "disabled" }` to turn off adaptive thinking entirely. This produces simpler, faster responses but loses the reasoning capability. --- ## Sources - [Introducing Claude Sonnet 5](https://www.anthropic.com/news/claude-sonnet-5) - verified July 4, 2026 - [Sonnet 5 Migration Guide](https://platform.claude.com/docs/en/about-claude/models/migration-guide) - verified July 4, 2026 - [What's New in Sonnet 5](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5) - verified July 4, 2026 - [Effort Parameter Documentation](https://platform.claude.com/docs/en/build-with-claude/effort) - verified July 4, 2026 - [Prompting Claude Sonnet 5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5) - verified July 4, 2026 - [Claude Pricing](https://claude.com/pricing) - verified July 4, 2026 - [Claude Sonnet 5 Benchmarks](https://llm-stats.com/models/claude-sonnet-5) - June 30, 2026

Dan Luu's Agentic Coding Notes Point to the Real Bottleneck

Developers Digest — Sat, 04 Jul 2026 00:00:00 GMT

**Last updated:** July 4, 2026 Dan Luu's [new agentic coding notes](https://danluu.com/ai-coding/#appendix-agentic-loops-and-writing-this-post) hit Hacker News today because they are the opposite of a launch post. No product wrapper. No benchmark table pretending the debate is settled. Just a long working note from someone using coding agents in the messy part of software work: bugs, support tickets, testing, variance, review, and the gap between "the agent produced code" and "the system got better." That is why the essay is useful for developers. The AI coding market keeps arguing about which model writes the best first draft. Luu is mostly pointing at the parts around the first draft. If you already buy the premise that [AI coding agents can open real pull requests](/blog/what-is-an-ai-coding-agent-2026), the next question is not whether the agent can type. It is whether your workflow can absorb, test, and correct the output without turning every human reviewer into a bottleneck. The short version: agentic coding is becoming less constrained by generation and more constrained by verification. That matches the pattern behind [the agent reliability cliff](/blog/the-agent-reliability-cliff), where a chain that looks fine at each step can collapse once small errors compound across many steps. ## The Useful Takeaway Is Testing, Not Autonomy The strongest part of Luu's essay is the testing argument. He describes a support-ticket-to-PR pipeline that can work when every fix still goes through human review, then spends more time on the older testing culture that shaped his bias: dedicated QA, randomized testing, fuzzing, large regression suites, and a lower reliance on handwritten unit tests. That matters because most coding-agent discussions still treat "write tests" as a checklist item. The agent edits code. The agent adds tests. The agent runs the tests. The agent says everything passed. In practice, that loop is often too self-referential. The same model that made the change is now grading whether the change was enough. Luu's point is narrower and more operational: agents are useful when they help you generate better tests, explore more input space, and turn bug reports into reproducible cases. They are weaker when you ask them to stare at code and declare it correct. That maps directly to the pattern in [Agent Evals Need Baseline Receipts](/blog/agent-evals-need-baseline-receipts). The receipt is not "the model sounded confident." The receipt is a stable baseline, a failing case, a reproduced behavior, a randomized test, a fuzz target, or a regression that runs again tomorrow. ## Fuzzing Is a Better Agent Partner Than Vibes One reason fuzzing keeps showing up in serious agent discussions is that it gives the model an external signal. The agent does not have to be perfectly calibrated about correctness. It can propose generators, shrinkers, assertions, harnesses, seed cases, and instrumentation. The test runner supplies the feedback. That is a healthier division of labor: | Layer | What the agent can do | What should stay external | | --- | --- | --- | | Bug intake | Summarize reports and infer reproduction paths | User-visible evidence and logs | | Test design | Draft property tests, fuzz targets, fixtures, and invariants | The actual runner and failure output | | Debug loop | Patch, rerun, narrow, and explain | Version control, CI, and reviewer approval | | Release gate | Produce a compact change narrative | Deployment policy and rollback criteria | This is also why "agent writes test for its own change" is not enough. It is useful as a starting point, but it is not a quality system. A stronger pattern is "agent turns a bug report into a failing harness, then a separate gate proves the harness fails before the fix and passes after it." That is the same philosophy behind [AI Code Review Is the New Bottleneck](/blog/ai-code-review-bottleneck): review has to shift from reading every generated line by hand toward demanding reproduction, smaller diffs, test evidence, and receipts. ## Agent Variance Explains Why Everyone Sounds Right The other useful part of the essay is variance. People who use coding agents can have wildly different experiences and still be describing real results. The same prompt, model family, and repo can produce different outcomes across runs. A workflow that works on one class of task can break down on another. A benchmark that looks decisive can hide the distribution that matters to an actual team. That is why the Hacker News thread around the essay is predictably split. Some readers see the workflow as evidence that agents are finally practical. Others see the failure modes as evidence that the optimism is overdone. Both sides can point to something real. The practical response is not to average the anecdotes into a mood. It is to separate task classes: - Good agent tasks: bug reproduction, migration scaffolding, mechanical refactors, test harness creation, documentation sync, small pull requests with clear acceptance criteria. - Risky agent tasks: ambiguous product decisions, large architectural rewrites, security-sensitive changes, performance work without measurement, and anything where the reviewer cannot cheaply tell whether the answer is correct. - Good orchestration tasks: split work, assign isolated branches, require evidence, and merge only after a gate passes. That is why agent workflow design increasingly looks like [state machines instead of prompt checklists](/blog/agent-workflows-as-code-state-machines). Once variance is real, the workflow needs transitions, gates, retries, and stop conditions. ## The "No Review" Lesson Is Easy to Misread The most dangerous misread of Luu's testing background would be: "a great test culture means you can skip code review." That is not the transferable lesson. The transferable lesson is that code review was not the only quality mechanism in that environment. It had dedicated test engineers, large regression infrastructure, randomized testing, and a culture that treated testing as a first-class engineering path. If your team does not have that system, removing review because an agent is fast is just moving risk into production. For most software teams, the better lesson is: 1. Make the agent produce narrower diffs. 2. Make the agent attach evidence. 3. Make the agent rerun the exact failing case. 4. Make the human reviewer inspect the decision and the risky code, not every generated line equally. 5. Keep deterministic gates outside the model. That is a more boring story than "agents replace developers." It is also closer to what teams can actually ship. ## Google Trends Demand Check Google Trends was only partially reliable for today's candidate set. Several query groups returned `429 Too Many Requests`, so I am not using fabricated search-volume numbers. The usable rows did show current relative interest around broader agent-workflow terms: `agent orchestration`, `AI agent workflow`, `AI agent architecture`, and `multi-agent system`. That supports the article lane, but it does not prove demand for Dan Luu's essay as a named query. The durable search intent is broader: how to make AI coding agents reliable, how to test agent-written code, and how to structure agent workflows so the output can be trusted. ## What I Would Change in a Team Workflow Tomorrow If a team is already using Claude Code, Codex, Cursor, or a similar agent, I would make three small workflow changes before buying more seats. First, add a bug-to-test template. Every bug fix should start with the agent writing the reproduction path and the failing command. If there is no failing command, the diff should be treated as incomplete. Second, split the agent role from the judge role. The same session can draft the change, but CI, a separate review agent, or a human reviewer should verify the claim. The important part is that the judge has a stable checklist and access to the real output, not just a summary. Third, track agent output by task type. "Claude Code is good" or "Codex is bad" is too broad to be actionable. Track migration tasks, UI polish, bug reproduction, test writing, dependency updates, and architecture changes separately. You will find some lanes are ready for automation and others are still expensive. This is the operating model behind [agent evals with receipts](/blog/agent-evals-need-baseline-receipts). The field does not need another leaderboard as much as it needs better local measurement. ## The Real Bottleneck The agent bottleneck is no longer only model capability. It is the surrounding system: - Can the agent select a task that is actually worth doing? - Can it produce a small enough diff? - Can it generate a failing test before the fix? - Can it rerun the relevant checks without hiding failures? - Can a reviewer inspect the result quickly? - Can the workflow remember what worked for the next run? That last question is why skills, repo instructions, and operating playbooks matter. A team that turns repeated lessons into durable instructions will get better faster than a team that starts every agent session from a blank chat box. For the bigger pattern, see [Why Skills Beat Prompts for Coding Agents](/blog/why-skills-beat-prompts-for-coding-agents-2026). Luu's essay is not a final theory of agentic coding. It is more useful than that. It is a reminder that the winning workflow is not the one with the most autonomy. It is the one with the best feedback loop. ## FAQ ### What is Dan Luu's agentic coding essay about? Dan Luu's essay covers practical lessons from using AI coding agents, with emphasis on testing, fuzzing, support-ticket-to-PR workflows, variance across agent runs, and why benchmark-style debates often miss the operational details that matter in real software work. ### Are AI coding agents good at writing tests? They can be good at drafting test harnesses, property tests, fuzz targets, fixtures, and reproduction cases. They are weaker when asked to certify their own work without an external runner, baseline, or reviewer. The stronger workflow makes the agent produce evidence that another system can verify. ### Does fuzzing work well with AI coding agents? Fuzzing can pair well with coding agents because it gives the agent an external feedback source. The agent can propose generators and invariants, while the fuzz runner supplies concrete failures. That is usually more reliable than asking the model to inspect code and judge correctness from prose alone. ### Should teams let coding agents merge without review? Usually no. A no-review workflow only makes sense when a team has unusually strong automated testing, regression infrastructure, rollback discipline, and ownership boundaries. Most teams should start by requiring smaller diffs, failing tests before fixes, CI evidence, and targeted human review. ### How should teams measure coding-agent quality? Measure by task class rather than by vibes. Track bug reproduction success, test quality, CI pass rates, review time, rollback rate, and accepted-change rate separately for migrations, UI work, bug fixes, refactors, and architecture changes. ## Sources - [Dan Luu: Agentic coding notes from Galapagos Island](https://danluu.com/ai-coding/#appendix-agentic-loops-and-writing-this-post) - primary essay, fetched July 4, 2026. - [Hacker News discussion via Algolia item 48782671](https://hn.algolia.com/api/v1/items/48782671) - 120 points and 11 top-level comments observed July 4, 2026. - [Google Trends](https://trends.google.com/trends/) - attempted for candidate query clusters on July 4, 2026; several clusters returned 429, so only reliable rows were used for broad query framing.

Image Token Compression Is a Real Agent Cost Lever

Developers Digest — Sat, 04 Jul 2026 00:00:00 GMT

**Last updated:** July 4, 2026 The most interesting AI cost story on Hacker News this week was not another model price cut. It was a weird compression trick. [`pxpipe`](https://github.com/teamchong/pxpipe) is a local proxy that renders bulky agent context as images before sending it to supported models. The project claims this can cut end-to-end Claude Code-style bills by roughly 59-70 percent on token-dense workloads, with a much smaller vision-token footprint for large system prompts, tool docs, command output, and older history. That sounds like a hack. It is a hack. It is also pointing at a real infrastructure layer. We already track [Claude Code token burn](/blog/claude-code-token-burn-cache-observability), [agent product-market-fit cost control](/blog/ai-agent-pmf-cost-control), and [Codex CLI resource budgets](/blog/codex-cli-resource-budgets). The pxpipe thread adds a sharper question: when agent context becomes the biggest line item, should teams optimize the representation of context as aggressively as they optimize model choice? My take: image-token compression is not something I would blindly put in front of production agents. It is lossy. It can silently misread exact identifiers. It depends on model vision behavior, pricing, prompt caching, and workload shape. But the pattern is worth studying because it forces agent teams to build the measurement layer they should have had anyway. ## The Signal The Hacker News item, ["60% Fable cost cut by converting code to images and having the model OCR it"](https://news.ycombinator.com/item?id=48776464), had 235 points and 87 comments when checked during this run. The linked repository was not just a tweet-sized trick. It includes a proxy, dashboard, token accounting, model allowlists, eval directories, and a long limitations section. The official project claim is narrow enough to be useful: - It compresses selected input blocks, not model output. - It leaves recent turns as text. - It uses a profitability gate so sparse prose can stay text. - It logs counterfactual token accounting to `~/.pxpipe/events.jsonl`. - It explicitly says the method is lossy. - It warns that exact strings, IDs, hashes, secrets, and other byte-exact values must stay text. That last point is the whole story. If you compress context into images, you are no longer sending plain text context. You are asking the model to read a rendered artifact. For many tasks, gist is enough. For some tasks, gist is dangerous. ## Why This Works At All The cost gap exists because text tokens and image tokens are priced and counted differently. In a coding-agent session, large chunks of context are often token-dense: tool schemas, JSON, stack traces, long command output, generated diffs, old chat turns, and documentation excerpts. A rendered page can pack a lot of characters into a fixed-size image. If the model can recover enough of the content from vision, the image can be cheaper than equivalent text. This is not the same as ordinary summarization. A summary throws information away intentionally. Image compression preserves the visual form of the original content but makes access probabilistic. The model may read it correctly. It may read the gist. It may misread a character that matters. That makes it closer to a codec than a prompt trick. And like every codec, it needs a loss model. ## Where I Would Use It The safest use case is bulky, low-precision context where the agent needs orientation more than byte-perfect recall. Good candidates: - old chat turns where the agent needs the project narrative - long logs where the agent is scanning for patterns - repeated tool docs after the active part of the task is already clear - large prose documentation blocks - historical command output that can be re-run or re-read - broad codebase context before the agent opens exact files Bad candidates: - API keys, secrets, tokens, and credentials - commit SHAs, hashes, IDs, invoice numbers, migrations, and exact paths - security findings where one character changes the result - generated code that will be copied without reopening the source file - legal, medical, or financial text where exact wording matters - tool schemas where a misspelled field changes the call This is the same boundary we use in [context engineering](/blog/context-engineering-guide): compressed context can guide attention, but source-of-truth context must remain recoverable. ## The Byte-Safety Rule The rule I would use is simple: If the agent will act on a value as an exact value, keep that value in text. That includes file paths, function names, user IDs, account IDs, SHA hashes, environment variable names, CLI flags, package versions, port numbers, endpoint paths, and short identifiers. The pxpipe README says exact 12-character hex strings in dense imaged content were unreliable in its tests, including silent wrong answers for some model paths. That is the failure mode to design around. A useful agent harness should split context into three lanes: | Lane | Representation | Example | |---|---|---| | Exact | Text | current task, file paths, identifiers, diffs, tool schemas | | Recoverable | Text plus source pointer | old logs, file excerpts, docs chunks | | Compressible | Image or summary | stale chat history, repeated docs, bulky low-risk output | The mistake is treating all context as equally compressible because it is all "just tokens." It is not. Context has different precision requirements. ## Evals Matter More Than The Trick The best part of the pxpipe repository is not the proxy. It is the fact that the project tries to measure the failure surface. The README points to SWE-bench runs, needle-in-haystack tests, gist recall tests, state tracking tests, and legibility audits. I would still treat those as project-provided evidence, not independent proof. But this is the right shape of evidence. A compression system should be judged by task outcomes, exact-string recall, error type, run-to-run variance, latency, and real billing deltas. That matches the argument in [agent evals need baseline receipts](/blog/agent-evals-need-baseline-receipts): an eval without the baseline, candidate, fixture, cost, and review note is not an eval. It is a vibe check. For image-token compression, the minimum eval harness should record: - original request body - compressed request body - model and version - token counterfactual - actual billed usage - task result - exact-string recall checks - whether the agent re-opened source files before editing - latency added by rendering - whether prompt caching still behaved as expected - human review verdict for any behavioral split Do not only measure savings. Measure the mistakes savings bought you. ## The Prompt Caching Question Compression also interacts with prompt caching. If your expensive context is stable and cacheable, ordinary prompt caching may already make it cheap enough. If your context churns every turn, rendering can look more attractive. If image blocks disrupt provider-specific caching behavior, the savings can disappear. The right answer is provider-specific and workload-specific. This is why I like pxpipe's per-request accounting direction. The decision should not be global. A proxy should decide at the block level: - Is this block dense enough to win? - Is it stale enough to compress? - Is it safe to read approximately? - Is it cacheable as text? - Is this model good at reading this render format? - Can the agent recover the exact source if needed? That is a runtime policy problem, not a blog-post benchmark problem. ## The Opposing View Is Right Too There is a fair skeptical reaction: if you need to turn text into images so the model can OCR it back into text, something is wrong with the pricing and context model. I agree with that. This is not an elegant long-term interface. In a cleaner world, model providers would expose cheaper archival context lanes, structured cache primitives, lossy-memory annotations, source-linked retrieval, and explicit precision contracts. Developers would not need to smuggle text through pixels. But engineering teams do not get to wait for clean abstractions. They get invoices now. So the practical question is not "is this beautiful?" It is "can we make compression explicit, measurable, reversible, and safe enough for the narrow cases where it pays?" ## What I Would Build Instead Of A Blind Proxy If I were putting this idea into a production coding-agent stack, I would not start with transparent compression for everything. I would build a context budgeter: 1. Keep the active turn, current files, exact identifiers, and tool schemas in text. 2. Store bulky old context as source-linked artifacts. 3. Compress only blocks that pass density, freshness, and precision checks. 4. Attach a text manifest describing what each image contains. 5. Force source re-open before edits, shell commands, security claims, and exact citations. 6. Run a shadow counterfactual for cost and outcome comparison. 7. Give users a kill switch and an audit log. That turns the idea from "OCR your prompt to save money" into a serious agent runtime feature. It also composes with [model routing](/blog/ai-model-routing-orchestration-layer). Some models may read dense context images well. Others may fail in ways that are hard to detect. A router should know that and only apply compression where the model has earned it. ## SEO Signal And Duplicate Risk This topic is not a duplicate of the existing Claude Code pricing posts. The existing coverage focuses on token burn, cache observability, pricing, and resource budgets. This one is specifically about representation-level compression: changing how context is encoded before the model sees it. Google Trends did not provide reliable per-query rows in this environment during the run. `pytrends` was not installed locally, and the Trends RSS endpoint returned a 404 HTML response rather than usable developer-topic rows. I used Trends only for query framing and fell back to HN velocity, GitHub source quality, existing DD coverage, and durable search intent around `AI agent costs`, `Claude Code costs`, `context compression`, and `prompt caching`. ## The Takeaway Image-token compression is not a free lunch. It is lossy context compression with a surprisingly good economic shape for some agent workloads. That makes it neither a gimmick to dismiss nor a default to enable everywhere. The useful lesson is broader: agent teams need a context accounting layer. Not just token totals. Precision classes, source pointers, cache behavior, exact-value guards, model-specific read tests, and outcome receipts. Once you have that, image compression becomes one policy option among many. Without that, it is just a clever way to buy cheaper mistakes. ## FAQ ### What is image-token compression for AI agents? Image-token compression renders selected text context as images so a vision-capable model can read the content using image tokens instead of ordinary text tokens. It can reduce input cost on token-dense workloads, but it is lossy and model-dependent. ### Is pxpipe safe to use with Claude Code? It should be treated as experimental. The project documents real limitations, including unreliable exact-string recall from dense images. Do not use image compression for secrets, hashes, IDs, exact paths, or any value the agent must reproduce byte-for-byte. ### Does image compression replace prompt caching? No. Prompt caching and image compression solve different problems. Prompt caching reduces repeated stable text cost. Image compression changes the representation of selected context. A production harness should measure both and choose per request. ### What is the best use case for image-token compression? The best fit is bulky, low-precision, token-dense context: stale chat history, repeated docs, long logs, and large tool output that the agent can use for orientation while reopening exact source files before acting. ### How should teams evaluate context compression? Compare compressed and uncompressed runs on the same task fixtures. Track billed usage, token counterfactuals, latency, exact-string recall, task success, human review verdicts, and whether the agent recovered source truth before edits. ## Sources - GitHub: [teamchong/pxpipe](https://github.com/teamchong/pxpipe), checked July 4, 2026. - Hacker News: [60% Fable cost cut by converting code to images and having the model OCR it](https://news.ycombinator.com/item?id=48776464), checked July 4, 2026. - Anthropic docs: [Prompt caching](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching), referenced for the caching tradeoff. - OpenAI docs: [Prompt caching](https://platform.openai.com/docs/guides/prompt-caching), referenced for provider-specific caching behavior. - Developers Digest: [Claude Code token burn and cache observability](/blog/claude-code-token-burn-cache-observability), [Codex CLI resource budgets](/blog/codex-cli-resource-budgets), and [agent evals need baseline receipts](/blog/agent-evals-need-baseline-receipts).

Jamesob's Guide to Running SOTA LLMs Locally: The Hardware and Config That Actually Works

Developers Digest — Sat, 04 Jul 2026 00:00:00 GMT

A new guide to running state-of-the-art LLMs locally is making the rounds on Hacker News, and it stands out from the typical "just buy a Mac" advice. [Jamesob's local-llm repository](https://github.com/jamesob/local-llm) lays out two concrete hardware paths - a $2k budget build and a $40k near-frontier setup - along with the exact BIOS settings, kernel parameters, and software stack configurations that most guides skip entirely. The post resonated with developers who have tried and failed to get multi-GPU inference working reliably. The details matter: PCIe link speed negotiation, IOMMU settings, and power management quirks can silently degrade performance or cause NCCL hangs that are notoriously difficult to debug. **Last updated:** July 4, 2026 --- ## The Two Hardware Paths The guide presents two distinct configurations based on budget and target model size. ### Budget Path: $2k for 48GB VRAM The entry point is two RTX 3090s, giving you 48GB of combined VRAM. This is enough to run Qwen3.6-27B at useful speeds. The 3090 remains attractive because of its memory bandwidth - 936 GB/s per card, or 1.87 TB/s combined across the pair. This matters more than raw compute for inference workloads. Token generation is bottlenecked by memory bandwidth, not FLOPs. Two used 3090s from the secondary market can hit this price point if you shop carefully. ### High-End Path: $40k for Near-Opus The ambitious configuration targets GLM-5.2 running in an Int8Mix-NVFP4 quantization with REAP pruning (22% of experts removed). The hardware: - 4x RTX PRO 6000 Blackwell cards (384GB VRAM total) - AMD EPYC Milan CPU - DDR4 RAM - ASRock Rack motherboard (base system runs about $5.6k) - PCIe Gen4 switches from c-payne.com for GPU-to-GPU peer-to-peer communication The pruned and quantized GLM-5.2 model (approximately 594B parameters after modifications) delivers around 80 tokens/second at 460k context on this setup. The guide characterizes this as "near-Opus-level performance" - a claim the HN community has been debating. --- ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48775921) has over 170 comments covering hardware alternatives, performance comparisons, and the economics of local vs. cloud inference. **The Mac debate is predictable but substantive.** Multiple commenters point out that an M5 MacBook Pro with 48GB of unified memory costs around $3k and fits in a backpack. The counterargument centers on memory bandwidth: the 3090 pair delivers 1.87 TB/s versus 300-600 GB/s on most Mac configurations. One commenter benchmarked Qwen3.6-27B at 68 tok/s on dual 3090s versus 18 tok/s on an M3 MacBook Pro - a significant real-world gap. **The "almost Opus" claim drew skepticism.** Several commenters noted that running a heavily quantized and pruned model introduces quality degradation that benchmarks may not capture. The concern is that aggressive quantization (below 8-bit) combined with expert pruning could introduce behavioral issues - looping, reasoning failures, and context handling problems - that emerge only in production use. **IOMMU configuration is the silent killer.** Multiple experienced users validated the guide's emphasis on kernel parameters. The recommendation to set `iommu=off amd_iommu=off` addresses NCCL communication hangs that plague multi-GPU setups. One commenter noted they spent weeks debugging this exact issue before finding the same fix. **PCIe negotiation failures are common.** The guide's advice to force PCIe Gen4 link speed in BIOS (rather than leaving it on Auto) addresses a common failure mode where links negotiate down to Gen3 or even Gen2 speeds, cutting bandwidth dramatically without obvious symptoms. **The rental vs. buy calculus is shifting.** Several commenters argued that for intermittent use, cloud GPU rental remains cheaper. The breakeven analysis depends on utilization rate, but consensus suggests you need consistent daily use to justify the capital outlay. One commenter with a $40k build noted their machine runs 24/7 for agent workloads - a different economic model than occasional inference. --- ## The Critical Configuration Details What makes this guide valuable is the specific configuration advice that general hardware recommendations miss. ### BIOS Settings 1. **Force PCIe Gen4 link speed** - Auto negotiation can fail to reach full speed, especially after thermal events or power state changes. 2. **Disable ASPM (Active State Power Management)** - This prevents the link from dropping to 2.5GT/s during idle periods, which can cause latency spikes when inference resumes. 3. **Enable Re-Size BAR** - This exposes the full VRAM to the CPU, enabling more efficient memory mapping for large model weights. ### Kernel Parameters The key flags for AMD-based multi-GPU systems: ``` iommu=off amd_iommu=off ``` This prevents NCCL communication hangs. The guide also recommends disabling ACS (Access Control Services) via setpci to allow switch fabric traffic optimization between GPUs. ### Power Management The guide recommends capping GPUs at 350W each. This allows running high-end hardware on standard 110V circuits without tripping breakers - a practical consideration that many builds ignore until they face it. --- ## Software Stack The recommended stack is straightforward: - **Inference**: vLLM in Docker containers - **Speech-to-Text**: Whisper-large-v3 (containerized) - **Interface**: OpenCode web UI on a separate VM - **Model weights**: Cached locally via HuggingFace CLI The containerization approach isolates dependencies and makes the setup reproducible. vLLM handles the multi-GPU inference coordination, which is substantially more complex with other inference engines. --- ## Why This Matters The timing of this guide aligns with several industry shifts. **Cloud AI costs are rising, not falling.** Despite predictions of commoditization, API pricing for frontier models has stabilized or increased. Anthropic's recent data retention policy changes for high-capability models have also pushed compliance-sensitive teams toward self-hosting. **The model gap has narrowed.** Open-weight models like Qwen3.6 and GLM-5.2 now compete credibly with cloud-only options on many coding tasks. Running them locally eliminates latency to the API provider and removes prompt length restrictions. **Hardware depreciation curves favor buyers.** The RTX 3090 launched in 2020 at $1,499 MSRP. You can now find them for $600-800 on the secondary market. For inference (not training), older high-VRAM cards retain most of their value because the workload is memory-bound. The counterargument remains valid: if you need occasional inference, cloud APIs are cheaper and simpler. The economics shift when inference becomes a continuous, high-volume workload - agent loops, research automation, or code review at scale. --- ## Practical Considerations A few notes from the HN discussion that complement the guide: **Thermal management matters at scale.** Four high-power GPUs in a single chassis generate substantial heat. Several commenters recommended running these builds in basements, garages, or dedicated server closets rather than home offices. **Noise is real.** Blower-style datacenter cards (like the RTX PRO 6000) are loud. Consumer cards with open-air coolers are quieter but require better case airflow. **Redundancy is your problem.** Cloud providers handle hardware failures; you do not. Budget for spare components or accept downtime risk. **The DRY penalty for loop prevention.** Multiple commenters mentioned that quantized models are more prone to repetition loops. The DRY (Don't Repeat Yourself) penalty in llama.cpp can mitigate this, though it requires tuning. --- ## Who Should Build This The $2k dual-3090 path makes sense for developers who: - Run inference workloads daily - Work with sensitive code or data that cannot leave their network - Want to experiment with local agents without API cost concerns - Already have a desktop chassis with adequate PSU capacity The $40k path is for teams or individuals with: - Continuous agent workloads (multi-hour or overnight runs) - Budget for dedicated infrastructure - Need for frontier-adjacent performance without cloud dependencies - Willingness to maintain custom hardware For everyone else, cloud APIs remain the pragmatic choice. The guide does not pretend otherwise - it is a resource for people who have already decided to go local and need the implementation details. --- ## Sources - [jamesob/local-llm GitHub repository](https://github.com/jamesob/local-llm) - [Hacker News discussion](https://news.ycombinator.com/item?id=48775921) --- ## FAQ ### How much does it cost to run SOTA LLMs locally in 2026? The budget path is approximately $2k for dual RTX 3090s (48GB total VRAM), capable of running Qwen3.6-27B effectively. The high-end path runs $40k or more for 4x RTX PRO 6000 Blackwell cards (384GB VRAM) to run models like quantized GLM-5.2. ### Why do multi-GPU LLM setups often fail silently? The most common issues are PCIe link speed negotiation failures (where Auto mode selects slower speeds), IOMMU conflicts causing NCCL communication hangs, and ASPM power management dropping links to idle speeds during inference pauses. These problems often show no error messages - just degraded performance. ### Is Apple Silicon competitive for local LLM inference? Apple M-series chips offer simpler setup and competitive memory capacity, but memory bandwidth is lower than dedicated GPUs. Benchmarks show 18-20 tok/s on M3/M4 Macs versus 60-80 tok/s on dual 3090 setups for equivalent models. The gap matters for interactive use and long inference runs. ### When does local LLM inference break even versus cloud APIs? Break-even depends on utilization rate and model costs. For occasional use, cloud APIs are cheaper. For continuous workloads (agent loops, overnight research, high-volume code review), local hardware amortizes quickly - often within 3-6 months of heavy use.

Leanstral 1.5: Mistral's Open Theorem-Proving Model Hits 100% on miniF2F

Developers Digest — Sat, 04 Jul 2026 00:00:00 GMT

Mistral has released [Leanstral 1.5](https://mistral.ai/news/leanstral-1-5/), an open-weight model specialized for formal theorem proving in Lean 4. The headline numbers are striking: 100% on the miniF2F benchmark (both validation and test sets), 587 out of 672 problems solved on PutnamBench, and state-of-the-art results on the FATE-H and FATE-X evaluation suites. The model is licensed Apache 2.0 and weighs in at 119B total parameters with only 6B active - a sparse mixture-of-experts architecture that makes it runnable on consumer hardware while maintaining frontier-level performance on formal proof tasks. **Last updated:** July 4, 2026 --- ## What Leanstral 1.5 Does Leanstral operates in two specialized environments designed for Lean 4 development: **Multiturn Proof Environment**: The model receives theorem statements, submits proof attempts, receives compiler feedback, and iteratively refines its approach until the proof compiles successfully. This mirrors how human mathematicians work with proof assistants - write, get errors, fix, repeat. **Code Agent Environment**: Beyond pure proving, Leanstral can function as a development agent - editing files, running bash commands, and using the Lean language server for real-time inspection of goals and type errors. This is closer to how developers actually interact with Lean in practice. The practical result is a model that can take a theorem statement and, given sufficient token budget, produce a machine-checked proof without human intervention. --- ## The Benchmark Claims Mistral's published numbers: | Benchmark | Leanstral 1.5 | Notes | |-----------|---------------|-------| | miniF2F (validation) | 100% | Full saturation | | miniF2F (test) | 100% | Full saturation | | PutnamBench | 587/672 | At 4M token budget | | FATE-H | 87% | State-of-the-art | | FATE-X | 34% | State-of-the-art | | FLTEval | Surpasses Claude Opus | At 1/7th the cost | The miniF2F saturation is significant because this benchmark has been a standard evaluation for theorem-proving systems. Reaching 100% means the benchmark is no longer useful for differentiating models on this task - Leanstral has effectively solved it. PutnamBench measures performance on competition-level mathematics problems. Solving 87% (587/672) with a 4M token budget demonstrates strong test-time scaling - the model gets better with more compute. --- ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48780801) generated substantive debate about the practical implications and some skepticism about the marketing claims. **The bug-finding example drew fire.** Mistral highlighted that Leanstral found an overflow bug in the datrs/varinteger Rust library - "an edge case that testing and fuzzing would typically miss." Multiple commenters pushed back hard on this characterization. One pointed out that any property-based testing system invented since 1980 would explore boundary values like `U64.MAX`. Another reproduced the bug in seconds using proptest. The consensus view: the bug was real, but calling it something "testing would typically miss" overstates the case. Fuzz testing with boundary value exploration would catch this routinely. The value of formal verification is proving absence of bugs, not finding obvious ones that good testing would catch anyway. **An OpenAI employee weighed in.** One commenter (disclosing they work at OpenAI) ran GPT-5.5 High on the same varinteger repository and found the identical bug. Their point: this particular bug was not tricky; the repository simply lacked attention. The interesting question is whether Leanstral can prove properties that LLM-based bug finding cannot. **The comparison chart timing is awkward.** The article compares Leanstral to models from "half a year ago" - several generations behind in the current pace of releases. Commenters noted this is a familiar pattern in benchmark marketing: compare to a snapshot of competitors rather than current versions. **The size efficiency is genuinely impressive.** At 6B active parameters (119B total with sparse activation), Leanstral is dramatically smaller than the models it outperforms on these benchmarks. Several commenters noted this is the real story - not that it beats large models, but that it does so at 1/50th the active parameter count. **European AI labs are finding their niche.** Some discussion touched on Mistral's strategy of targeting specialized domains (OCR, theorem proving) where they can achieve frontier performance without competing head-to-head with OpenAI and Anthropic on general capabilities. This is pragmatic: France has strong historical expertise in formal methods (Coq, OCaml ecosystem), and Mistral is leveraging that heritage. --- ## Real-World Bug Finding Beyond benchmarks, Mistral claims Leanstral discovered "5 previously unknown bugs across 57 repositories tested." The most interesting was the varinteger overflow: ```rust // On input Std.U64.MAX, the expression (value + 1) overflowed // Crashes in debug mode, silent corruption in release mode ``` The bug was filed as [datrs/varinteger#8](https://github.com/datrs/varinteger/issues/8) a week before the Leanstral announcement. The library is small (about 1k downloads/day on crates.io) and hadn't been touched in 8 years - exactly the kind of low-attention code where automated verification adds value. The broader point: formal verification tools are not primarily about finding bugs that testing misses. They're about proving properties hold for all inputs, which testing fundamentally cannot do. The bug-finding framing is easier to market, but it undersells the actual capability. --- ## How Developers Can Use It Leanstral 1.5 is available through: 1. **Mistral Vibe** - Free API endpoint 2. **Hugging Face** - Downloadable weights 3. **OpenATP** - An open-source Python package for automated theorem provers that supports Leanstral natively ([GitHub](https://github.com/henryrobbins/open-atp)) The practical workflow involves writing Lean 4 code with theorem statements, then using Leanstral to generate proofs. The model integrates with the Lean language server, so it can inspect intermediate proof states and adjust its approach based on type errors. For developers new to Lean 4, the learning curve is real but manageable. One HN commenter reported going from zero knowledge to productive Lean 4 development in six months, heavily assisted by LLMs (including but not limited to Leanstral). The key insight: you need to understand the axioms and theorem statements you're trying to prove, but the model can handle much of the proof construction machinery. --- ## The Bigger Picture: Verified AI Code The interesting application is not mathematical theorem proving - it's using Lean 4 as a target for verified code generation. Several commenters discussed using Lean 4 as: - A metaprogramming framework that lowers to other languages (C++, Rust, Haskell) with provable correspondence - A tool for describing state machines and protocols with formal correctness guarantees - A GPU kernel compiler where tiling and scheduling properties can be formally verified One commenter reported using Lean 4 bolted to io_uring for systems programming, with benchmarks that outperform nginx on reverse proxy workloads. The combination of a proof-capable language with competitive runtime performance opens possibilities that traditional formal methods tools (slow, academic) could not reach. The thesis: as LLM-generated code increases, the need for verification increases proportionally. If humans are no longer reviewing every line, machine-checkable correctness proofs become more valuable. Leanstral points toward a workflow where LLMs write code and other LLMs (or the same LLM) prove properties about it. --- ## Limitations and Caveats **Training data uncertainty.** The model's performance on specific repositories may reflect training data contamination rather than generalization. This is difficult to rule out. **Benchmark saturation.** 100% on miniF2F is impressive, but it means the benchmark is exhausted. Future evaluations will need harder problems. **Practical adoption barriers.** Most developers do not write Lean 4. The path from "LLM can prove theorems" to "my production code has machine-checked properties" involves substantial tooling and process changes. **Comparison to non-specialized models.** The FLTEval comparison to Claude Opus is interesting, but Opus is a general-purpose model. The more relevant comparison would be to other specialized theorem provers, which the release does not address. --- ## Why This Matters for Developers Short term: if you work with Lean 4 or are interested in formal verification, Leanstral 1.5 is the best open-weight option available. The Apache 2.0 license means you can integrate it into commercial tooling without restrictions. Medium term: the combination of small active parameter count and strong performance suggests specialized models will remain competitive against larger general-purpose models for specific domains. This has implications for how teams choose AI tooling - domain-specific may beat one-size-fits-all. Long term: the vision of LLM-generated code with machine-checked correctness proofs is getting more practical. Leanstral is a step toward workflows where code and proofs are generated together, reducing the gap between "it compiles" and "it's correct." --- ## Sources - [Mistral Leanstral 1.5 announcement](https://mistral.ai/news/leanstral-1-5/) - [Hacker News discussion](https://news.ycombinator.com/item?id=48780801) - [datrs/varinteger repository](https://github.com/datrs/varinteger) - [OpenATP - open-source automated theorem prover](https://github.com/henryrobbins/open-atp) --- ## FAQ ### What is Leanstral 1.5 and what can it do? Leanstral 1.5 is Mistral's open-weight model for formal theorem proving in Lean 4. It can take theorem statements, generate proofs, interact with the Lean compiler for feedback, and iteratively refine proofs until they pass verification. It achieves 100% on the miniF2F benchmark and state-of-the-art results on FATE evaluations. ### How many parameters does Leanstral 1.5 have? The model has 119B total parameters but only 6B active due to its sparse mixture-of-experts architecture. This makes it runnable on consumer hardware while maintaining strong performance on theorem-proving tasks. ### Can Leanstral 1.5 find bugs in code? The model can identify bugs by attempting to prove properties about code and failing when those properties don't hold. Mistral claims it found 5 previously unknown bugs across 57 repositories. However, HN commenters noted that the highlighted example (an overflow bug) would have been caught by standard property-based testing or fuzzing. ### Is Leanstral 1.5 open source? Yes, the model is released under the Apache 2.0 license. Weights are available on Hugging Face, and the model is accessible through Mistral's Vibe API. This allows commercial use without restrictions.

Agent Studio: Authoring the Roles, Not Just the Knowledge

Developers Digest — Fri, 03 Jul 2026 00:00:00 GMT

Three posts built one idea in stages. The [first](/blog/skills-over-mcp-progressive-disclosure) argued that `SKILL.md` and the [Model Context Protocol](https://modelcontextprotocol.io) solve two halves of the same problem, and that serving skills over MCP lets an agent pay context cost only in proportion to what a task needs. The [second](/blog/skill-studio-linked-context) let a skill file be a link rather than a copy, fetched only at the moment an agent reaches for it. The [third](/blog/one-endpoint-progressive-disclosure) pulled skills, files, memory, and generation onto a single endpoint with tiered disclosure, one key that scopes everything to its owner, and one credit balance. This post adds the piece that makes the studio complete. Skills answer what an agent should know. They do not answer what role it should play. That second question has its own artifact - a [subagent](https://code.claude.com/docs/en/agent-sdk/subagents) definition - and it now has a home right next to your skills. ## One studio, two units Open the Studio and there is a single segmented toggle: Skills and Agents. Not two pages, not two products. One surface with two tabs, because the two artifacts are edited the same way, served the same way, and used together. The reason to keep them in one place is that they are complementary halves of the same job. A skill is knowledge: a `SKILL.md` body plus optional reference material, some of it linked context pulled from the open web on demand. An agent is a role: a focused subagent with a narrow objective, a constrained tool budget, and a system prompt that says what it does and what it returns. You reach for a skill when you want an agent to know how something is done here. You reach for an agent when you want to spawn a worker that does one thing well. A fleet needs both, and authoring them side by side means the person who writes the operating procedure is the person who defines the role that follows it. ## An agent is one markdown file A member agent is deliberately simpler than a skill. Where a skill can carry a manifest of reference files, an agent is a single markdown definition: YAML frontmatter with a name, a description of exactly when to spawn it, a tool list, and a model, followed by the system prompt. That is the same shape a first-party subagent uses, so an agent authored in the Studio is a real, copyable definition rather than a proprietary record. The starter definition the editor opens with is a filled-in template, not a blank box, so the shape is obvious from the first keystroke: ```markdown --- name: my-agent description: Use when ... . Describe exactly when this subagent should be spawned. tools: Read, Grep, Glob model: sonnet --- You are a focused subagent. State the one job you do, the steps you follow, and what you return. Be concrete. ``` The `description` is doing real work. It is not marketing copy - it is the trigger an orchestrator reads to decide whether to spawn this agent at all. A vague description gets a role that never fires or fires at the wrong time. This is the same discipline that makes a skill's one-line description the thing an agent scans before pulling the body: the cheap text is a routing decision, so it has to be precise. ## The same endpoint, again An agent authored in the Studio is served over the exact endpoint the rest of the platform uses. There is no separate agents API. The MCP surface exposes `list_agents` and `get_agent` alongside `list_skills`, `get_skill`, and everything else, and both resolve against the caller's API key. Agents collapse the middle tier of [progressive disclosure](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) that skills use. A skill has three tiers - a lean index, an overview plus a file manifest, then a file fetched on demand - because a skill has bundled files worth disclosing separately. An agent has no bundled files; the definition is the unit. So `list_agents` returns the lean index of slugs and names, and `get_agent` returns the whole definition. Index, then item. The house style of the endpoint is that a two-part surface skips the manifest tier when the item itself is the payload, and agents are exactly that case. The merge rule matches skills too. When an agent calls `list_agents`, it sees the first-party agent library, its own Studio agents, and other members' public ones, deduplicated by slug with first-party definitions winning a clash. Your private agents ride the public endpoint but are visible only to your key. Nothing about the transport changed to add agents; the surface was already the right shape. ## Three front doors Because agents live on the shared endpoint, they inherit every way of reaching it. The same definitions answer to an MCP client, to plain REST, and to the `dd` command line, with no per-channel work. Over REST, `GET /api/v1/agents` returns the lean index and `GET /api/v1/agents/{slug}` returns the full definition. Over the CLI, that is `dd agents list` and `dd agents get `, which prints the definition and can drop it straight into a local `.claude/agents/` directory so a subagent is ready to spawn. Unlike skills, an agent has no separate download artifact - a skill can be a tree of files worth zipping, but an agent is one markdown file, so `get` is the whole story. Skills keep their `dd skills pull ` for the zip that unpacks into `.claude/skills/`; agents do not need it. One authored artifact, three front doors, and the choice of door is the caller's. An orchestrating agent discovers a role over MCP mid-task. A developer browses the catalog over REST from a script. Someone setting up a machine runs `dd agents get` and commits the file. They are all reading the same row. ## Publishing to the community, with a moderation loop A Studio agent starts private. Flip it public and it joins the pool that other members' keys can list and fetch - the same opt-in that skills use, gated on the agent being both public and active. That last word is the safety valve. Every public agent carries a status, active or hidden. Community members can report an agent, and an owner moderation queue can flip a reported one to hidden. The moment that happens, the agent drops out of everyone else's `list_agents` immediately, because the cross-member query only returns public, active rows. The author still sees their own agent - hiding is a community-visibility action, not a deletion - so a false report costs nobody their work while a genuine problem stops spreading at once. Moderation is a status flip on a row, not a batch job, so the effect is instant and reversible. This is what makes community publishing safe to turn on rather than a liability. The default is private, sharing is a deliberate toggle, and the shared pool is filtered on every read so a hidden entry cannot linger in a cache somewhere. The report flow and the owner queue are the human loop around an otherwise mechanical filter. ## Why the roles belong next to the knowledge The thesis of the series has been that the interesting unit of agent tooling is not the prompt or the tool call but the disclosure discipline around a body of knowledge too large to hold and too dynamic to copy. Agents extend that thesis to roles. Coordinating a fleet of agents is not only a matter of giving each one the right knowledge; it is a matter of defining the right workers in the first place - one objective each, the right tool budget, a description precise enough to route on. Authoring those roles in the same studio as the skills, serving them over the same endpoint, browsing them through the same three doors, and sharing them under the same moderation loop means the two halves stop being separate integrations and become one coherent surface. You write what your agents should know and what your agents should be in the same place, and everything downstream - an MCP client, a REST script, the CLI, another member's fleet - reads both the same way. That is the shape that makes a fleet legible: knowledge and roles, authored together, disclosed on demand, shared safely. ## FAQ ### What is the difference between a skill and an agent in the Studio? A skill is knowledge: a `SKILL.md` body plus optional reference files, including linked context fetched on demand. An agent is a role: a single markdown subagent definition with frontmatter (name, description, tools, model) and a system prompt. Skills tell an agent how something is done; agents define a focused worker to spawn. Both are authored in the same Studio and served over the same endpoint. ### How is a member agent served to an AI client? Over the platform's MCP endpoint through two tools, `list_agents` (a lean index of slug and name) and `get_agent` (the full definition). Both resolve against the caller's API key, so you see the first-party agent library, your own agents, and other members' public ones, deduplicated by slug. ### Why do agents not have the three-tier disclosure that skills have? Skills bundle reference files, so they disclose in three tiers: index, then an overview plus a file manifest, then a file on demand. An agent has no bundled files - the definition is the whole unit - so it collapses to two tiers: an index and the item. The endpoint uses the middle manifest tier only when there are separate files worth listing. ### Can I use agents without an MCP client? Yes. The same definitions are available over REST at `GET /api/v1/agents` and `GET /api/v1/agents/{slug}`, and over the command line as `dd agents list` and `dd agents get `. The CLI can write the definition into a local `.claude/agents/` directory. Skills additionally offer `dd skills pull` for a downloadable zip; an agent is one file, so it needs no separate download. ### What happens when a published agent is reported? Public agents carry an active or hidden status. A reported agent can be set to hidden through the owner moderation queue, and it then disappears from every other member's `list_agents` immediately, because the cross-member query returns only public, active rows. The author still sees their own hidden agent; hiding affects community visibility, not ownership, and is reversible. ### Are my agents public by default? No. A Studio agent is private until you explicitly make it public, and even then it is only visible to others while it is both public and active. Your private agents are scoped to your API key and never appear in another member's listing. ### Where can I read the rest of this series? Start with [skills over MCP](/blog/skills-over-mcp-progressive-disclosure), then [linked context in Skill Studio](/blog/skill-studio-linked-context), then the [one-endpoint reference architecture](/blog/one-endpoint-progressive-disclosure). Primary sources: Anthropic's [Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) writeup and [documentation](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview), the [subagents documentation](https://code.claude.com/docs/en/agent-sdk/subagents), and the [Model Context Protocol](https://modelcontextprotocol.io) spec.

App Builder: From a Prompt to a Working App You Can Watch Run

Developers Digest — Fri, 03 Jul 2026 00:00:00 GMT

Most prompt-to-app tools hand you a project. A folder tree, a package manifest, a dev server to start, a build step that has to succeed before you can see anything. That is the right shape when you are starting a product. It is the wrong shape when you want to answer a smaller question: what would this thing feel like if it existed? [App Builder](/app-builder) is built for that smaller question. You describe an app in plain language, and it returns one self-contained HTML file that renders immediately in a live, sandboxed preview. There is no folder to open, no server to run, no build to wait on. You watch the app run, you talk to it to change it, and when it is ready you share it with a link or download the file. This post is about what that single-file constraint actually buys, how the revision loop works, where the limits are, and what it costs. ## What "single-file" actually buys you The core decision is that every app is exactly one HTML document, with its markup, styles, and scripts all inline. That one decision is what makes everything else work. **No build step.** The file is complete the moment it is generated. There is nothing to compile, bundle, or install. That is why the preview appears the instant the model finishes writing, instead of after a toolchain has run. **It runs in a sandboxed iframe.** The generated document renders inside an iframe using the `srcdoc` attribute with a restrictive [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#sandbox) policy that permits scripts but nothing else. It cannot navigate your page, reach for your cookies, or pop out of its frame. You interact with the real running app, not a screenshot, and it stays walled off from the surface it renders on. **It is a downloadable artifact.** Because the app is one file with no external local dependencies, "download" means exactly what it should: you get a single `.html` you can open by double-clicking, host on any static bucket, email to someone, or drop into another project. Nothing is locked inside the builder. There is a Copy HTML button too, if you would rather paste it somewhere directly. **It is a shareable link.** Publish a build and it gets a public, read-only preview URL that anyone can open without signing in. That makes it a fast way to put a working thing in front of a teammate or a client without deploying anything. To make a single file behave like a real app, the builder standardizes on a small, pinned stack loaded from CDNs: [Tailwind via the Play CDN](https://tailwindcss.com/docs/installation/play-cdn) for styling, and React 19 pulled from [esm.sh](https://esm.sh) with Babel Standalone transpiling the JSX in the browser. Every dependency is pinned to an explicit version rather than `latest`, so an app you generate today does not silently break the day a CDN ships a major version. Simple, mostly-static pages get plain HTML and Tailwind instead, so a trivial app does not carry a React runtime it never uses. ## How revisions work: you talk to the app The first message builds the app. Every message after that revises the same app in place. The interface is a split view: a chat rail on one side, the live preview on the other (they stack on mobile, with the preview on top). You send "make the header sticky" or "add a dark mode toggle" or "the total is not updating when I change quantity," and the builder regenerates the complete document with your change applied and re-renders it. You are not accumulating diffs against a repo or resolving merge conflicts. You are describing the app you want and watching the current version become it. Under the hood, a revision is not a fresh start. The builder passes the current HTML plus recent conversation turns back to the model with your new instruction, and asks for the full updated document. That is why "make it blue instead" understands what "it" is, and why a fix to one thing does not quietly undo the last three changes you asked for. The preview refreshes on every build so you always see the live result, and each app you make is saved, so you can reopen an earlier build and keep iterating on it later. This is the same organizing idea behind the rest of the platform: capability metered by a single credit balance, results that persist as real artifacts rather than throwaway output. If you want the architectural version of that argument, it is laid out in [One Endpoint, Every Capability](/blog/one-endpoint-progressive-disclosure). ## The honest limits Single-file is a real constraint, not a marketing angle, and it is worth being precise about what it rules out. **It is one file, not a project scaffold.** App Builder does not produce a Next.js repo, a `package.json`, a route tree, or a folder you open in your editor and grow into a product. If your end state is a full application with a backend, a database, and a deploy pipeline, this is the wrong tool for that step, and it is not trying to be. It is for the step before that, when you want the working shape of the idea in your hands fast. **Dependencies are CDN-pinned, not bundled.** The React and Tailwind runtimes load from esm.sh and the Tailwind Play CDN at view time. That is what removes the build step, and it also means a generated app needs a network connection to render its dependencies, and its capabilities are bounded by what those pinned CDN libraries provide. It is the right trade for a live preview and a portable file; it is not how you would ship a production bundle. **No secret-bearing API calls.** Because the app is a public, shareable, downloadable file, it does not call external APIs that need keys, and it should not. When an app needs data, it generates realistic sample data inline, and it can persist state to `localStorage`. That keeps every build safe to share by default. It also means App Builder is at its best for tools, calculators, dashboards, widgets, interactive pages, prototypes, and demos, rather than anything that has to talk to your private backend. Knowing where the edges are is what makes the tool useful. Reach for it when you want a working artifact now; reach for a full scaffold when you are committing to a product. ## What it costs App Builder runs on the universal Developers Digest [credit balance](/pricing), the same credits that power chat, image generation, and everything else in the suite. There is no separate subscription for it. The first build of an app costs 20 credits. Each revision costs 5, because a revision reuses the prior app as context and is cheaper to produce than a fresh one. The cost is shown in the composer before you send, so you always know what a build will run before you commit to it. New accounts start with 25 free credits, which is enough for one full build plus a revision to see the loop end to end before paying for anything. ## Try it The fastest way to understand App Builder is to build something small and then change it twice. Describe a pomodoro timer or a sortable table of sample data, watch it render, then tell it to restyle the header and add one feature. Two revisions in, the loop clicks: plain language in, a working app out, and a file you can take anywhere. Start at [App Builder](/app-builder), or read the [pricing](/pricing) if you want the credit math first. ## FAQ ### What is App Builder? App Builder turns a plain-language prompt into a working single-file app with a live, sandboxed preview. You describe what you want, see it run immediately, refine it by talking to it in chat, and then share it with a link or download the file. ### What kind of apps can I build? Self-contained single-file apps: tools, calculators, dashboards, widgets, small interactive pages, prototypes, and demos. Because each app is one HTML file with no build step, it stays easy to preview, share, and download. It is not built to scaffold a full multi-file product with a backend. ### How do revisions work? Every message after the first one revises the same app in place. The builder passes the current HTML and recent conversation back to the model with your new instruction and returns the complete updated document, then re-renders the preview. So "make it blue" or "fix the total" applies to the app you already have, without starting over. ### Can I take the app with me? Yes. Every app is a single self-contained file. Download the `.html` and open it by double-clicking, host it on any static bucket, or drop it into another project. You can also copy the raw HTML, or publish a public read-only preview link. Nothing is locked inside the builder. ### Is the preview safe? The app renders inside an iframe with a restrictive [sandbox](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#sandbox) policy that allows scripts but blocks navigation, popups, and access to the surrounding page. Generated apps also avoid API calls that need keys, so a build is safe to share by default. ### How much does it cost? The first build costs 20 credits and each revision costs 5, on the universal Developers Digest credit balance shared across every app. The cost is shown before you send. New accounts get 25 free credits, enough for a full build plus a revision. See [pricing](/pricing) for the details.

One Endpoint, Every Capability: A Reference Architecture for Progressive Disclosure

Developers Digest — Fri, 03 Jul 2026 00:00:00 GMT

Two earlier posts built up one idea in stages. The [first](/blog/skills-over-mcp-progressive-disclosure) argued that `SKILL.md` and the [Model Context Protocol](https://modelcontextprotocol.io) solve two halves of the same problem, and that the useful move is to serve skills over MCP so an agent pays context cost only in proportion to what a task needs. The [second](/blog/skill-studio-linked-context) removed two constraints from that design: skills no longer had to be ours, and a skill file no longer had to be copied in ahead of time. A file could be a link, fetched only at the moment an agent reached for it. This post is the capstone. It is not a new feature so much as the shape the whole platform settled into once those pieces were in place. The claim is narrow and, I think, useful: skills, files, memory, and generation do not need four separate integrations. They need one endpoint, one auth surface, one billing surface, and one organizing principle applied consistently across all of them. That principle is tiered disclosure. What follows is the architecture and the reasoning, because the architecture is the interesting part, not any single tool. ## The one endpoint Everything a member's agents can do lives at a single [streamable HTTP](https://modelcontextprotocol.io/specification) MCP endpoint: `/api/mcp`. Point any MCP-capable client at that URL with a `dd_live_` API key and the tools appear. There is no second endpoint for skills, no separate service for files, no different auth for generation. The full catalog is documented in the repo as a canonical reference, but the shape is easy to hold in your head, because it is four families of capability on one surface. The first family is generation: `generate_image` and `generate_voice`. These are the metered tools, and they are the only ones that cost credits. Each one does the work, persists the result to the caller's gallery, and hands back a durable URL, so a generation is not a throwaway artifact but a file that now exists in the account. The second family is files and assets: `list_folders`, `list_files`, `get_file`, and `list_assets`. This is where everything a member uploads or generates becomes reachable as context. An agent can list what is there and pull one file's contents on demand. The third family is memory: `save_memory`, `list_memories`, and `search_memories`. Durable notes and links that survive across sessions and machines, so an agent can persist a decision in one run and recall it in the next, on a different computer, weeks later. The fourth family is the library: `list_skills`, `get_skill`, `get_skill_file`, plus the sibling tools for copyable subagent definitions and design contracts. This is the skills-over-MCP surface the earlier posts built, now including a member's own authored skills scoped to their key. Four families, one endpoint. The reason that consolidation matters is not tidiness. It is that a single endpoint with a single key is the difference between an agent that can reach your whole working context and an agent that can reach whichever one integration you wired up this week. ## Tiered disclosure is the organizing principle The thing that keeps four capability families from collapsing into an unusable wall of tool schemas is that they all follow the same loading discipline. Anthropic's [Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) named it for knowledge packaging: [progressive disclosure](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview), where the agent sees short descriptions first, pulls a full body only for the item it chose, and reads deeper reference material only as the work demands. We apply that same staging to every family on the endpoint. For skills it is three tiers. `list_skills` returns a lean index, a slug and a one-line description each, cheap enough to hold a hundred of them in context. `get_skill` returns one skill's body plus a manifest of its files, paths and one-line purposes, still no file contents. `get_skill_file` returns the raw contents of exactly one file, and for a linked file it fetches the remote source at that moment. Three calls, each one paying only for the depth it reached. For files it is two tiers, because a file is its own unit and needs no manifest in between. `list_files` is the lean index: id, name, kind, content type, and size, no URLs and no contents. `get_file` pulls one file on demand, returning the text inline for a textual file, capped so a large file cannot blow the context budget, or a durable URL for a binary. The pattern is identical to skills, just collapsed by one tier because the shape of the data allows it. Memory bends the rule deliberately, and the exception is worth stating because it clarifies the rule. There is no `get_memory` item tier; `list_memories` and `search_memories` return the full note body inline. That is intentional. Notes are small recall items, and the entire point of memory is one-call recall. Forcing a second fetch to read a note you already found would be disclosure theater, cost without benefit. The discipline is not "always add tiers." It is "pay context in proportion to what the task needs," and for a short note the proportional cost is the whole note. The anti-pattern this avoids is the flat server: fifty tools whose full schemas load before the agent has decided anything, or a single tool that dumps every file and every skill body in one response. Either one hands the model tens of thousands of tokens describing things the current task will never touch. A small index in front of on-demand fetches gives the same reach at a fraction of the standing cost. ## The same tools, three front doors Here is the part that turns a tidy API into a coordination substrate. The tools on `/api/mcp` are not a special MCP-only surface. They are the same capabilities the platform exposes everywhere, reached three ways. An external agent reaches them over MCP. Point Claude, Cursor, or any [MCP client](https://modelcontextprotocol.io) at the endpoint with a key, and `list_skills`, `get_file`, and the rest are callable [tools](https://ai-sdk.dev/docs/foundations/tools) the model can choose. The in-product chat reaches the same capabilities from the inside. When a member talks to the assistant in the dashboard, the model is calling the same underlying functions, routed through the [AI SDK's tool-calling](https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling) machinery. The chat is not a separate implementation of image generation or memory; it is another caller of the one that already exists. And a script reaches them over plain HTTP. The REST API and the MCP endpoint are two projections of the same credit-metered capabilities, so a CLI or a cron job hits the same functions with the same key that an agent uses interactively. One capability, three front doors. That is what makes the architecture worth calling a reference architecture rather than a collection of endpoints. A file your agent generates over MCP at 2am is in the gallery your chat can reference at 9am and the CLI can download at noon, because there was only ever one file and one place it lived. The surfaces differ; the substrate does not. ## Auth and credits are what make it shared and safe None of this works as a coordination layer without the two scoping decisions underneath it, and they are almost boring, which is the point. Every tool call on the MCP transport resolves its owner from the API key. There is no session to manage, because the key is the identity. That resolved owner id scopes everything: `list_files` returns your files, `get_skill` includes your authored skills, `search_memories` searches your notes. One member's agents cannot reach another member's private context, and they do not have to be told not to; the scoping is structural, applied once at the transport boundary rather than re-checked in every tool. Credits are the other half. A single universal balance meters the paid actions, and because the key maps to a stable owner id, that balance is the same whether the spend comes from the MCP endpoint, the in-product chat, or a script. Buy credits once, spend them from any front door. The free tools, everything in files, memory, and the library, cost nothing, because their cost is storage and lookups, not inference. The metered tools charge from one source of truth so the price shown and the price charged cannot drift. Put those two together and you have the quiet precondition for a fleet: a shared context substrate that is scoped per owner and billed once, reachable identically from every surface an agent might live on. ## Why this is the shape for coordinating agents The reason I keep returning to this design is that coordinating a fleet of agents is, in practice, a context problem before it is an orchestration problem. Agents do not fail to cooperate because they lack a message bus. They fail because each one holds a slightly different, slightly stale picture of the world, copied onto its disk at a different moment. A single endpoint with tiered disclosure fixes that at the root. The runbook is a skill, one row in an index until an agent needs it, updated in one place so the whole fleet has the fix on its next `get_skill` call. The design doc your teammate uploaded is a file any agent can list and pull. The decision one agent recorded is a memory another agent can search. Nobody re-pastes, nobody re-syncs, and nothing drifts, because there is one library and every agent discovers it the same way. When we [ran a fleet of agents for a day to rebuild this site](/blog/coordinating-an-agent-fleet-for-a-day), the thing that held the day together was exactly this: shared, verifiable context every agent could reach on the same terms. That is the whole architecture. Two open standards each solved one half of the problem, and the combination, applied consistently across skills, files, memory, and generation on one endpoint, is the interesting part. You can browse the catalog by hand at [/library](/library), read the endpoint reference in the [developer docs](/docs), and point your own agents at it today. The next post carries the same architecture to member-authored roles in [Agent Studio](/blog/agent-studio-one-endpoint). ## FAQ ### What is the difference between the MCP endpoint and the REST API? They are two projections of the same credit-metered capabilities. The REST API is for scripts and servers calling over plain HTTP; the MCP endpoint exposes the same underlying functions as model-callable tools for an agent. Both authenticate with the same `dd_live_` key and draw down the same credit balance, so the choice is about which client is calling, not which features are available. ### Why put files and memory behind progressive disclosure instead of just returning everything? Because returning everything spends context on data the current task will never read. A lean index (`list_files`, `list_skills`) plus an on-demand fetch (`get_file`, `get_skill_file`) lets an agent hold a large working set cheaply and pay full cost only for the one item it opens. The exception is memory notes, which are small enough that returning the body inline is the intended behavior rather than a leak. ### How is one member's context kept separate from another's? Every tool call resolves its owner from the API key at the transport boundary, and that owner id scopes every per-user tool. A caller only ever sees their own files, skills, and memories. Public content, like another member's explicitly public skill, is the documented exception, and it is opt-in. ### Can I use this from a harness other than Claude Code? Yes. MCP is a client-neutral protocol, so any [compliant client](https://modelcontextprotocol.io) discovers and calls the tools the same way. The skills themselves are plain `SKILL.md` markdown, an open format, so nothing about the pattern is tied to one harness. ### How do I try it? Create a `dd_live_` API key, point an MCP client at the `/api/mcp` endpoint with it as a Bearer token, and call the tools. You can also browse the same skill and file catalog by hand at [/library](/library), and the full tool reference lives in the [docs](/docs). [App Builder](/blog/app-builder-prompt-to-app) is a good example of the same principle applied to a whole product surface: one prompt in, a working single-file app out, drawn from the same universal credit balance as everything else here.

Best AI Agent Memory Providers in 2026: Mem0 vs Zep vs Letta vs Cloudflare

Developers Digest — Thu, 02 Jul 2026 00:00:00 GMT

| Official Sources | | |:--|:--| | [Mem0 Docs](https://docs.mem0.ai) / [Pricing](https://mem0.ai/pricing) | Extract-and-retrieve memory layer | | [Zep / Graphiti](https://help.getzep.com/) / [Pricing](https://www.getzep.com/pricing/) | Temporal knowledge graph memory | | [Letta Docs](https://docs.letta.com) / [Pricing](https://docs.letta.com/letta-code/pricing) | Stateful agents, self-editing memory | | [Cloudflare Agents](https://developers.cloudflare.com/agents/) | Durable Objects state primitive | | [LOCOMO paper](https://arxiv.org/abs/2402.17753) / [LongMemEval](https://arxiv.org/abs/2410.10813) | The benchmarks everyone cites | **Last updated:** July 2, 2026 Agents forget. The model that just spent twenty turns learning your codebase, your preferences, and the shape of the task wakes up the next session knowing none of it. A memory layer is the fix, and by 2026 it is a real market: you can bolt on a hosted API in an afternoon, or self-host an open-source core and own the data. The four names that come up most are [Mem0](https://docs.mem0.ai), [Zep](https://www.getzep.com/), [Letta](https://docs.letta.com), and [Cloudflare's Agents](https://developers.cloudflare.com/agents/) primitive, and they are not four flavors of the same thing. One extracts facts and retrieves them, one builds a temporal knowledge graph, one lets the agent edit its own memory, and one is not really a memory product at all but the substrate you build memory on. This is a fair, sourced comparison: what each actually is, how it is priced, the benchmark fights you should not take at face value, and a decision guide by workload. If you want the conceptual grounding first, [AI agent memory patterns](/blog/ai-agent-memory-patterns) covers the categories, and [why agent memory benchmarks are not enough](/blog/agent-memory-benchmarks-not-enough) sets up the skepticism you will need for the numbers below. ## Mem0: Extract, Then Retrieve Mem0 bills itself as a "universal memory layer for AI agents." The [core-concepts docs](https://docs.mem0.ai/core-concepts/how-it-works) describe a two-phase design: an extract phase that uses an LLM to pull durable facts out of a conversation, deduplicate them, and embed them, and a retrieve phase that fuses parallel scoring passes (semantic, keyword, and entity) to surface the relevant memories before the next model call. State lands in three tiers: a SQL store for facts, a vector DB for embeddings, and an entity store for relationships, with an optional graph-memory variant described in their [2025 paper](https://arxiv.org/abs/2504.19413). Everything is scoped by `user_id`, `agent_id`, or `run_id`. It is open source under Apache 2.0 ([github.com/mem0ai/mem0](https://github.com/mem0ai/mem0), roughly 59.9k stars as of this writing) and self-hostable, with a managed platform at app.mem0.ai. Hosted [pricing](https://mem0.ai/pricing) runs from a free Hobby tier (10k memory adds, 1k retrievals monthly) through Starter at $19/mo, Growth at $79/mo, and Pro at $249/mo, which is the tier that unlocks graph memory. Enterprise is custom with on-prem, SSO, and audit. On benchmarks, be careful to separate two eras. The 2025 paper claimed roughly a 26 percent relative improvement (LLM-as-judge) over OpenAI's memory on LOCOMO, with about 91 percent lower p95 latency and over 90 percent token savings versus stuffing full context. The 2026 [research page](https://mem0.ai/research) reports newer figures: LoCoMo 92.5, LongMemEval 94.4, and BEAM scores, under roughly 7,000 tokens per retrieval. Those are different measurements from different harnesses; cite them distinctly rather than as one continuous claim. The honest read: Mem0 is the fastest of the four to ship, with low-latency vector retrieval and strong episodic recall. Pure vector-plus-extraction is weaker on its own at deep temporal or multi-hop reasoning, which is exactly the gap the next contender targets. ## Zep: A Temporal Knowledge Graph Zep approaches memory as a graph problem. Its open-source engine, [Graphiti](https://github.com/getzep/graphiti) (Apache 2.0, around 28.2k stars), is a temporally-aware knowledge graph engine, described in the [Zep paper](https://arxiv.org/abs/2501.13956). The defining feature is a bi-temporal model: every fact carries both a valid time and a transaction time, and superseded facts are not deleted but marked, so the graph can answer questions about what was true at a given moment. Retrieval is hybrid, combining embeddings, BM25 keyword search, and graph traversal, with provenance tracked through "episodes." Graphiti self-hosts on Neo4j, FalkorDB, Kuzu, or Amazon Neptune. The managed Zep platform adds governance: attribute-based access control, retention policies, and audit. [Pricing](https://www.getzep.com/pricing/) starts free ($0, 10k credits monthly, 2 projects), then Flex at roughly $104/mo billed annually, Flex Plus at roughly $312/mo, and custom Enterprise with SOC 2 Type II and HIPAA BAA. Zep's [paper](https://arxiv.org/abs/2501.13956) reported 94.8 percent on Deep Memory Retrieval (versus 93.4 for MemGPT) and up to an 18.5 percent accuracy gain on LongMemEval with a 90 percent latency reduction versus full context. The graph approach shines for entity-centric, temporal, and contradiction-resolving questions and multi-hop reasoning. The cost is real: you take on schema and extraction overhead, and self-hosting means running a graph database, which is more operational weight than Mem0's vector store. ## Letta: The Agent Edits Its Own Memory Letta (formerly MemGPT) is less a memory API and more a platform for stateful agents. Its premise, from the [core concepts](https://docs.letta.com/core-concepts/), is that all agent state persists in a database even after it is evicted from the context window. Memory comes in layers: **memory blocks** are labeled text pinned into context that the agent can edit and share, and **archival memory** is a searchable database the agent queries on demand. The distinguishing idea is self-editing memory: the agent decides, via tools, what to write, update, or pull into context. This descends directly from the [MemGPT paper](https://arxiv.org/abs/2310.08560), "Towards LLMs as Operating Systems," which framed context management as an OS-style virtual memory problem. Letta is Apache 2.0 ([github.com/letta-ai/letta](https://github.com/letta-ai/letta), around 23.6k stars) and self-hostable, with Letta Cloud as the hosted option. [Pricing](https://docs.letta.com/letta-code/pricing) offers a free tier (bring-your-own-key across all tiers), Pro at $20/mo, and an API plan at $20/mo base plus $0.10 per active agent per month and a small tool-execution fee, which suits fleets of many long-lived agents. The tradeoff is latency versus flexibility. Letting the agent manage its own memory through tool calls gives you maximum control and auditability (you can see every memory edit as an action), but the LLM-in-the-loop retrieval adds turns and cost that a direct vector lookup avoids. If you want an agent whose memory is a first-class, inspectable part of its reasoning, Letta is the most opinionated choice here. The idea of memory as an inspectable ledger is one this site has explored in [the agent memory context ledger](/blog/agent-memory-context-ledger). ## Cloudflare: A Substrate, Not a Memory Product Cloudflare belongs in this comparison with an asterisk. The [Agents SDK](https://developers.cloudflare.com/agents/) (MIT, around 5.2k stars) does not give you a memory algorithm; it gives you a place to put state. Each agent is a Durable Object with its own identity, lifecycle, and embedded per-agent SQLite storage. State auto-saves, survives restarts and hibernation, and syncs to connected WebSocket clients, and local `this.sql` queries are described as [effectively zero-latency](https://developers.cloudflare.com/agents/api-reference/store-and-sync-state/) because there is no network round trip. Vector memory comes from pairing it with Vectorize, and inference from Workers AI. Idle agents hibernate and cost nothing. Pricing is Cloudflare's platform model, not a per-memory fee: a Workers Paid plan (from $5/mo, required for production SQLite Durable Objects) plus usage on requests, duration, and SQL rows read and written, per the [Durable Objects pricing](https://developers.cloudflare.com/durable-objects/platform/pricing/). There are no benchmark claims to weigh because there is no retrieval algorithm to benchmark; you build the memory logic. The tradeoff is clear. You get a stateful substrate with excellent local-read latency, hibernation economics, and per-session isolation, but you write the extraction and retrieval yourself. And while the SDK is MIT and your data sits in plain SQLite, the runtime primitives are Cloudflare-only, which is the deepest platform coupling of the four. The [Cloudflare agent memory primitive guide](/blog/cloudflare-agent-memory-primitive) goes deeper on wiring it up. ## The Head-to-Head | | Mem0 | Zep (Graphiti) | Letta | Cloudflare Agents | |---|---|---|---|---| | Memory model | Extract + retrieve, vector-first | Temporal knowledge graph | Self-editing agent memory | State substrate you build on | | Core license | Apache 2.0 | Apache 2.0 (Graphiti) | Apache 2.0 | MIT (SDK) | | Self-host | Yes (vector store) | Yes (needs graph DB) | Yes | No, platform-bound runtime | | Managed entry price | Free, then $19/mo | Free, then ~$104/mo | Free, then $20/mo | $5/mo Workers Paid + usage | | Strength | Fast to ship, low-latency recall | Temporal, multi-hop, entity-centric | Auditable, agent-controlled | Zero-latency local state, hibernation | | Main cost | Weaker deep temporal reasoning alone | Schema + graph ops overhead | LLM-in-loop retrieval latency | You build the memory logic | | GitHub stars (approx) | 59.9k | 28.2k | 23.6k | 5.2k | Star counts and prices are point-in-time snapshots; verify against the linked pages before you commit. ## About Those Benchmarks If you take one thing from this post, take this: no single memory benchmark number is comparable across vendors in 2026. Everyone runs the same tests under different configurations, and the results move accordingly. [LOCOMO](https://arxiv.org/abs/2402.17753) is the most-cited benchmark, built on very long conversations (around 300 turns, up to 35 sessions) with question types spanning single-hop, multi-hop, temporal, and adversarial. It has documented flaws, including speaker misattribution and ambiguous questions, which is part of why the scores are contested. The clearest example: Zep originally reported around 84 percent on LOCOMO, Mem0's replication scored Zep at 58.44 percent and alleged methodology errors, and Zep [rebutted](https://blog.getzep.com/lies-damn-lies-statistics-is-mem0-really-sota-in-agent-memory/) with a 75.14 percent figure of its own. Both sides are interested parties. The [GitHub issue trail](https://github.com/getzep/zep-papers/issues/5) is the primary record if you want to judge for yourself. [LongMemEval](https://arxiv.org/abs/2410.10813) (ICLR 2025) is widely seen as more rigorous, with 500 questions across information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention, and it documents roughly a 30 percent accuracy drop over sustained interaction. Both Mem0 and Zep cite it, again under their own harnesses. Deep Memory Retrieval, from the MemGPT paper, is now considered narrow and largely saturated. The practical move is to benchmark the top two candidates on your own traffic rather than trusting any vendor's leaderboard. ## Which to Pick **Pick Mem0** when you want a memory layer live this week, your workload is conversational recall and personalization, and low retrieval latency matters more than deep temporal reasoning. The free and $19 tiers make prototyping cheap, and the Apache 2.0 core is there if you outgrow the hosted plan. **Pick Zep** when your agent must reason over how facts change through time, resolve contradictions, or traverse relationships between entities, think customer histories, evolving account state, or anything where "what was true when" is a real question. Accept the graph-database operational cost as the price of that capability. **Pick Letta** when memory should be a first-class, inspectable part of the agent's own behavior, when you are running many long-lived agents, and when auditability of every memory write is worth the extra latency of LLM-in-the-loop retrieval. It is also the most natural home if you already think in the MemGPT model. **Pick Cloudflare Agents** when you are building on Cloudflare anyway, want per-session stateful agents with near-zero local-read latency and hibernation economics, and are happy to write your own extraction and retrieval on top of Durable Objects and Vectorize. It is a substrate decision, not a memory-algorithm decision. On the broader question of self-host versus managed: all three memory products ship Apache 2.0 cores with managed layers, so you can start hosted and move in-house for data residency or to escape per-call fees. Cloudflare is the outlier, MIT SDK but platform-bound runtime, though your data stays in portable SQLite. Where this fits your larger toolchain is covered in [the agentic dev stack for 2026](/blog/agentic-dev-stack-2026). ## The Take There is no single best memory provider, only the best fit for your access pattern. If your questions are "what did the user tell me," reach for Mem0. If they are "what was true, and when," reach for Zep. If they are "let the agent decide what to remember, and show me every edit," reach for Letta. If they are "I already live on Cloudflare and I will build the memory myself," reach for Durable Objects. And whatever the vendor charts say, run the final two candidates against your own conversations before you wire one in. The benchmarks are a starting point, not a verdict. ## FAQ ### What is an AI agent memory provider? It is a system that persists what an agent learns across sessions and retrieves the relevant pieces before each model call, so the agent does not start from zero every time. Approaches range from extract-and-retrieve over a vector store (Mem0), to temporal knowledge graphs (Zep), to agent-managed self-editing memory (Letta), to building your own on a stateful substrate (Cloudflare). See [AI agent memory patterns](/blog/ai-agent-memory-patterns) for the categories. ### Is Mem0, Zep, or Letta open source? All three have Apache 2.0 open-source cores. Mem0's library and Letta are directly open source and self-hostable, and Zep's memory engine Graphiti is Apache 2.0 and self-hosts on a graph database. Each also offers a managed hosted platform. Cloudflare's Agents SDK is MIT, but its runtime primitives run only on Cloudflare's platform. ### Which agent memory provider is cheapest? For getting started, all four have a free entry point. Paid tiers begin around $19/mo for Mem0, $20/mo for Letta Pro, roughly $104/mo (billed annually) for Zep's Flex tier, and $5/mo plus usage for Cloudflare's required Workers Paid plan. The cheapest at scale depends heavily on your volume of memory writes, retrievals, and active agents, so model it against your own usage. ### When should I use a knowledge-graph memory like Zep instead of vector memory like Mem0? Use a temporal knowledge graph when your agent needs to reason about how facts change over time, resolve contradictions, or traverse relationships between entities. Use vector-based extract-and-retrieve when the priority is fast recall of conversational facts and personalization. Graphs add power for multi-hop and temporal questions at the cost of more setup and operational overhead. ### Are the LOCOMO benchmark scores reliable? Treat them with caution. LOCOMO has documented issues, and vendors run it under different configurations, which has produced public disputes, most notably between Mem0 and Zep over Zep's LOCOMO score. LongMemEval is generally considered more rigorous, but it too is cited under different harnesses. The reliable approach is to benchmark your finalists on your own data. ### What is the difference between Letta and MemGPT? Letta is the platform built by the team behind MemGPT, and it carries the MemGPT context-management approach forward. The [MemGPT paper](https://arxiv.org/abs/2310.08560) introduced the idea of treating the context window like an operating system's memory, paging information in and out; Letta productizes that into stateful agents with editable memory blocks and archival memory. ### Is Cloudflare Agents a memory provider? Not in the same sense as the others. It provides a stateful substrate, per-agent Durable Objects with embedded SQLite and near-zero-latency local reads, on top of which you build your own memory logic. There is no built-in extraction or retrieval algorithm, so there are no memory benchmarks to compare. Pair it with Vectorize for semantic search if you need it. ## Sources - [Mem0 documentation](https://docs.mem0.ai) and [how it works](https://docs.mem0.ai/core-concepts/how-it-works) - [Mem0 pricing](https://mem0.ai/pricing) and [research](https://mem0.ai/research) - [Mem0 GitHub](https://github.com/mem0ai/mem0) and [2025 paper (arXiv:2504.19413)](https://arxiv.org/abs/2504.19413) - [Zep](https://www.getzep.com/) and [pricing](https://www.getzep.com/pricing/) - [Graphiti GitHub](https://github.com/getzep/graphiti) and [Zep paper (arXiv:2501.13956)](https://arxiv.org/abs/2501.13956) - [Zep rebuttal on LOCOMO methodology](https://blog.getzep.com/lies-damn-lies-statistics-is-mem0-really-sota-in-agent-memory/) and [benchmark issue thread](https://github.com/getzep/zep-papers/issues/5) - [Letta documentation](https://docs.letta.com) and [pricing](https://docs.letta.com/letta-code/pricing) - [Letta GitHub](https://github.com/letta-ai/letta) and [MemGPT paper (arXiv:2310.08560)](https://arxiv.org/abs/2310.08560) - [Cloudflare Agents docs](https://developers.cloudflare.com/agents/) and [state API](https://developers.cloudflare.com/agents/api-reference/store-and-sync-state/) - [Cloudflare Durable Objects pricing](https://developers.cloudflare.com/durable-objects/platform/pricing/) - [LOCOMO paper (arXiv:2402.17753)](https://arxiv.org/abs/2402.17753) and [LongMemEval (arXiv:2410.10813)](https://arxiv.org/abs/2410.10813)

Claude Science Developer Guide 2026: AI Workbench for Research

Developers Digest — Thu, 02 Jul 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Claude Science Announcement](https://www.anthropic.com/news/claude-science-ai-workbench) | Anthropic official launch post, June 30 2026 | | [NVIDIA BioNeMo Agent Toolkit](https://blogs.nvidia.com/blog/claude-science-bionemo-agent-toolkit/) | NVIDIA integration announcement | | [Claude Science Pricing](https://claude.com/pricing) | Official Claude pricing page | | [BioNeMo Agent Toolkit on GitHub](https://github.com/NVIDIA-BioNeMo/bionemo-agent-toolkit) | Open-source toolkit repository | | [Claude Platform Docs](https://platform.claude.com/docs/en/about-claude/models/overview) | Model and platform documentation | Claude Science launched on June 30, 2026 as a beta AI workbench designed for scientific research. Unlike Claude Code, which targets software engineering workflows, Claude Science wraps existing Claude models with specialized tools for laboratory work - local code execution, rich scientific artifacts, database connectors, and remote compute access. This guide covers what developers and researchers need to know: where to access it, what it costs, how the integration with BioNeMo works, and when Claude Science is the right tool versus Claude Code. **Last updated:** July 2, 2026 ## What Claude Science Is (and Isn't) Claude Science is not a new model. It is a desktop application that wraps existing Claude models with scientific infrastructure: - **Local code execution** in a sandboxed environment - **Rich artifact rendering** for 3D protein structures, genome tracks, chemical structures, and figures - **Database connectors** to 60+ curated scientific databases - **Remote compute** via SSH to lab workstations and HPC clusters - **Provenance tracking** so every figure, table, and manuscript carries its generation code The core pitch: scientists describe research tasks in natural language, Claude proposes multi-step plans, and the application handles code execution, data retrieval, and artifact generation with full auditability. ## Availability and Access **Current access (July 2026):** | Plan | Access | Notes | |------|--------|-------| | Pro | Yes | $17/month annual, $20/month monthly | | Max | Yes | From $100/month | | Team | Yes | Admin must enable first | | Enterprise | Yes | Admin must enable first | | Free | No | Not available on free tier | **Supported platforms:** - macOS 13 or later - Linux x64 - Windows: Not supported at launch To get started: visit [claude.com/science](https://claude.com/science) and download the desktop application. **Important for organizations:** Team and Enterprise admins must enable Claude Science before members can access it. The feature is off by default during beta. ## Pricing Claude Science does not have separate pricing. Usage counts against your existing Claude plan limits: | Plan | Cost | Notes | |------|------|-------| | Pro | $17/month (annual) or $20/month | Standard Claude Pro usage limits | | Max | From $100/month | Higher limits, priority access | | Team Standard | $20/seat/month (annual) | Requires admin enablement | | Team Premium | $100/seat/month (annual) | 5x usage limits | | Enterprise | Contact sales | Custom limits and compliance | **Academic discount:** Anthropic offers a discounted Team plan for active scientific labs at academic institutions and nonprofit research organizations. Eligibility is verified through the lab's principal investigator. **Grant program:** Anthropic is funding up to 50 Claude Science AI for Science projects with up to $30,000 in credits and up to $2,000 in Modal compute. Applications close July 15, 2026. Awards are announced by July 31, 2026. Projects run September 1 through December 1, 2026. ## Technical Specifications ### Local Environment The default Python environment includes: - NumPy, pandas, SciPy - matplotlib, seaborn, Pillow - Common scientific packages pre-installed The default R environment includes: - tidyverse - ggplot2 - jsonlite Users can create task-specific environments with additional packages. ### Remote Compute Claude Science connects via SSH to: - Lab workstations - HPC clusters with SLURM job submission - Cloud compute resources The application manages job submission and output retrieval. Sensitive datasets stay local - only necessary context is sent to Claude. ### Artifact Rendering Claude Science natively displays: - 3D protein structures - Genome browser tracks - Chemical structures and molecules - Figures and visualizations alongside generating code Every artifact includes: - The exact code that produced it - Environment specifications - Plain-language description - Full message history for reproducibility ## BioNeMo Integration The NVIDIA BioNeMo Agent Toolkit is integrated into Claude Science, bringing GPU-accelerated scientific workflows directly into the workbench. ### Available Models | Model | Category | Description | |-------|----------|-------------| | Evo 2 | Genomics | DNA/RNA sequence analysis | | Boltz-2 | Protein structure | Structure prediction | | OpenFold3 | Protein structure | Open-source structure prediction | ### Performance Gains The integration delivers significant acceleration: | Task | Standard | With BioNeMo | |------|----------|--------------| | Genomic analysis | Hours | Minutes | | 1.3M cell preprocessing | 52 minutes | 25 seconds | | Cheminformatics similarity search | Baseline | Up to 3000x faster | ### Access BioNeMo workflows are accessed through natural language prompts within Claude Science. The toolkit packages models as containerized NIM microservices with pre-tuned inference endpoints. ## Claude Science vs Claude Code | Capability | Claude Science | Claude Code | |------------|----------------|-------------| | Primary use | Scientific research | Software development | | Artifact rendering | 3D structures, molecules, figures | Code, diffs, files | | HPC integration | SLURM, SSH to clusters | Not built-in | | Database access | 60+ scientific databases | Filesystem and git | | BioNeMo integration | Yes | No | | Platform | macOS, Linux desktop app | Terminal-based | | Team collaboration | Through artifacts and provenance | Git workflows | **When to use Claude Science:** - Single-cell RNA sequencing analysis - Protein structure prediction and visualization - CRISPR screen design - Literature review with evidence extraction - Molecular epidemiology studies - Any workflow requiring rich scientific artifacts **When to use Claude Code:** - Software development and refactoring - CI/CD pipeline work - Multi-file code generation - Terminal-native workflows ## Multi-Agent Architecture Claude Science uses a coordinating agent with 60+ skills that can spawn specialist agents. A built-in reviewer verifies citations and calculations against execution records. The permission-based workflow: 1. User describes research task in natural language 2. Claude proposes a multi-step plan 3. User approves plan 4. Application requests permission before accessing folders, running code, or using connectors 5. Code executes in an OS-level sandbox 6. Reviewer checks claims against execution records 7. Artifacts are generated with full provenance ## Limitations (Beta) During beta, be aware of: - **Incomplete admin controls:** Organizational dashboards lack full audit logs - **No air-gapped operation:** Prompts still sent to Anthropic servers - **Not HIPAA-compliant:** Do not use with protected health information during beta - **No Windows support:** macOS and Linux only - **Limited reviewer automation on Pro tier:** Higher tiers get more automated verification ## Real-World Cost Example A Forbes article documented a professor mapping their entire field using Claude Science for $26 - the equivalent of a few hours of API usage. The cost scales with complexity, but for many research workflows the economics are favorable compared to manual literature review or custom analysis pipeline development. ## Getting Started 1. **Verify eligibility:** Claude Science requires Pro, Max, Team, or Enterprise plan 2. **Download the app:** Visit [claude.com/science](https://claude.com/science) 3. **Connect compute (optional):** Add SSH connections to lab workstations or HPC clusters 4. **Configure environment:** Install additional packages as needed 5. **Start with a task:** Describe your research goal in natural language For academic labs, apply for the discounted Team plan through your principal investigator. ## My Take Claude Science is Anthropic's bet that workflow ownership beats raw model capability for scientific users. The same way Claude Code became the agentic coding interface rather than just a better code-completion model, Claude Science aims to own the scientific workflow end-to-end. The BioNeMo integration is strategically smart. 18 of the top 20 pharmaceutical companies already use BioNeMo, so there is an immediate install base in labs Anthropic wants to reach. The key differentiator is provenance. Scientific figures, tables, notebooks, and manuscripts carry the code, environment, and conversation history that created them. That is a genuine value proposition for reproducibility. Whether it catches on depends on whether scientists adopt it as their primary interface rather than using Claude directly or via custom pipelines. The beta status and desktop-app requirement create friction. The academic discount and grant program are designed to overcome that. For developers building research tools or scientific infrastructure, Claude Science is worth watching. The multi-agent architecture and artifact system offer patterns that could influence how AI-assisted research workflows evolve. ## FAQ ### What is Claude Science? Claude Science is an AI workbench for scientific research that wraps Claude models with specialized tools - local code execution, rich artifact rendering, database connectors, and HPC integration. It launched in beta on June 30, 2026. ### How much does Claude Science cost? Claude Science uses your existing Claude plan. Pro is $17-20/month, Max starts at $100/month, and Team is $20-100/seat/month. Academic labs can apply for discounted Team pricing. ### Is Claude Science available on Windows? No. Claude Science currently supports macOS 13+ and Linux x64 only. Windows support is not available at launch. ### What is the BioNeMo integration? NVIDIA's BioNeMo Agent Toolkit provides GPU-accelerated scientific workflows within Claude Science, including Evo 2 for genomics and Boltz-2/OpenFold3 for protein structure prediction. ### How is Claude Science different from Claude Code? Claude Science targets scientific research with artifact rendering, HPC integration, and database access. Claude Code targets software development with terminal-native workflows. Use Science for lab work, Code for coding. ### Is Claude Science HIPAA compliant? No. During beta, Claude Science is not HIPAA compliant. Do not use it with protected health information. ### How do I get started with Claude Science? Visit [claude.com/science](https://claude.com/science) with a Pro, Max, Team, or Enterprise account. Download the desktop app and follow the setup instructions. ### What is the Claude Science grant program? Anthropic is funding up to 50 AI for Science projects with up to $30,000 in credits and $2,000 in Modal compute. Applications close July 15, 2026. ## Sources Verified July 2, 2026. - [Claude Science, an AI workbench for scientists](https://www.anthropic.com/news/claude-science-ai-workbench) - Anthropic - [NVIDIA BioNeMo Agent Toolkit Brings Accelerated AI to Life Sciences Researchers in Claude Science](https://blogs.nvidia.com/blog/claude-science-bionemo-agent-toolkit/) - NVIDIA Blog - [BioNeMo Agent Toolkit](https://github.com/NVIDIA-BioNeMo/bionemo-agent-toolkit) - GitHub - [Plans and Pricing](https://claude.com/pricing) - Claude - [Claude Science: Anthropic AI Workbench, Pricing, Setup and Use Cases](https://coursiv.io/blog/claude-science) - Coursiv - [Anthropic's New AI Workbench Mapped My Field For $26](https://www.forbes.com/sites/johndrake/2026/06/30/anthropics-new-ai-workbench-mapped-my-field-for-26-now-imagine-it-aimed-at-the-rest-of-science/) - Forbes

MCP Servers vs Agent Skills: Which to Build in 2026

Developers Digest — Thu, 02 Jul 2026 00:00:00 GMT

| Official Sources | | |:--|:--| | [Model Context Protocol Spec (2025-11-25)](https://modelcontextprotocol.io/specification/2025-11-25) | Architecture, primitives, transports | | [MCP Transports](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports) | stdio and Streamable HTTP | | [MCP 2026-07-28 Release Candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) | Stateless protocol direction | | [Agent Skills Overview (Anthropic)](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) | SKILL.md format, progressive disclosure | | [Agent Skills Open Standard](https://agentskills.io) | Cross-tool skill specification | | [Anthropic Engineering: Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) | Design rationale, how skills complement MCP | **Last updated:** July 2, 2026 You are adding a capability to an agent. Say you want it to open pull requests, or file expense reports, or format every report your team ships the same way. The question that stops most teams is not "can the model do this" but "what should this capability actually be." An [MCP server](https://modelcontextprotocol.io/specification/2025-11-25)? An [Agent Skill](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview)? Both? They look adjacent, they get pitched as competitors, and the wrong choice leaves you maintaining a service when a folder would have done, or hand-rolling brittle instructions when a real connection was the answer. They are not competitors. They answer different questions. An MCP server answers "what can this agent reach," and a Skill answers "how should this agent do the work." Once that line is clear, the decision is mostly mechanical. Here is the framework, grounded in the primary sources, plus the cases where you genuinely want both. ## What MCP Actually Is The Model Context Protocol is, in Anthropic's own words, "an open protocol that enables seamless integration between LLM applications and external data sources and tools," providing "a standardized way to connect LLMs with the context they need" (see the [specification](https://modelcontextprotocol.io/specification/2025-11-25)). The key word is protocol. MCP is a wire format, not a feature. Architecturally it is JSON-RPC 2.0 between three roles: a Host (the LLM app that initiates a connection), Clients (connectors inside the host), and Servers (the services that expose capabilities). The spec explicitly notes it was inspired by the [Language Server Protocol](https://modelcontextprotocol.io/specification/2025-11-25), and the analogy is a good one. Just as LSP lets any editor talk to any language backend, MCP lets any compatible agent talk to any server, with stateful connections and capability negotiation at setup. A server can expose three primitives, defined in the spec as: - **Resources** - context and data for the user or model to use - **Prompts** - templated messages and workflows - **Tools** - functions the model can execute Servers talk over one of two standard transports. **stdio** launches the server as a subprocess and exchanges newline-delimited JSON-RPC over stdin and stdout; the spec says clients "SHOULD support stdio whenever possible." **Streamable HTTP** uses a single endpoint with POST and GET, optional SSE streaming, and session management via an `MCP-Session-Id` header. That transport replaced the older HTTP+SSE design from the 2024-11-05 revision. The current stable spec is dated 2025-11-25, and if you want the details of what changed, the [changelog](https://modelcontextprotocol.io/specification/2025-11-25/changelog) is the primary source. One direction matters for a 2026 decision: the next revision, a [release candidate dated 2026-07-28](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/), is headlined by making MCP stateless at the protocol layer. If you are building a server today, that is the trend to build toward, and it is covered in the [stateless migration guide](/blog/mcp-stateless-migration-guide-2026). The through-line: an MCP server is **access to a system**. It is a connection, with auth, sessions, and callbacks. If you are new to the concept, the [beginner guide to MCP servers](/blog/what-is-an-mcp-server-beginner-guide-2026) and the [complete guide](/blog/complete-guide-mcp-servers) cover the ground before this decision. ## What Agent Skills Actually Are A Skill is something else entirely. Anthropic's docs define Agent Skills as "modular capabilities that extend Claude's functionality," where "each Skill packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant." The framing they use repeatedly is onboarding: a Skill is "like an onboarding guide you'd create for a new team member." The [open standard](https://agentskills.io) puts it structurally: "At its core, a skill is a folder containing a SKILL.md file. This file includes metadata (name and description, at minimum) and instructions that tell an agent how to perform a specific task. Skills can also bundle scripts, reference materials, templates, and other resources." The `SKILL.md` frontmatter requires only `name` (max 64 characters, lowercase, hyphens) and `description` (max 1024 characters), and the docs stress the description "should include both what the Skill does and when Claude should use it." The design center is progressive disclosure, and the token math is what makes it work. Anthropic's docs lay out three levels: - **Level 1 - Metadata:** always loaded at startup, roughly 100 tokens per Skill, just name and description. As the docs put it, "you can install many Skills without context penalty; Claude only knows each Skill exists and when to use it." - **Level 2 - Instructions:** the SKILL.md body, under about 5k tokens, loaded only when the Skill is triggered. "Only then does this content enter the context window." - **Level 3+ - Resources and code:** effectively unlimited bundled files, read or executed on demand. Scripts run via bash and return only their output, so, per the docs, "the script code itself never enters context." That last property is the quiet superpower. A Skill can ship a 2,000-line reference doc and a data-processing script, and none of it costs context until the moment the agent actually needs it. Skills are also portable. The format "was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products," including Claude Code, Cursor, Gemini CLI, GitHub Copilot, OpenAI Codex, Goose, and Letta. Build one folder, run it across compatible agents. If you have never built one, start with the [beginner guide to Claude Code skills](/blog/what-are-claude-code-skills-beginner-guide). The through-line: a Skill is **how to do a task**. It is procedural knowledge plus bundled resources, loaded into the agent you already have. Nothing new connects. ## The Real Distinction, In One Line MCP gives the agent a new thing it can reach. A Skill gives the agent expertise about work it already does. That is the whole framework. A server is a live capability behind a connection. A Skill is static know-how that flows into context on demand. Everything else in the decision falls out of that difference, and this site has argued the practical side of it before in [skills over MCP for progressive disclosure](/blog/skills-over-mcp-progressive-disclosure) and the closely related [Claude agents vs skills](/blog/claude-agents-vs-skills) breakdown. ## Head to Head | | MCP Server | Agent Skill | |---|---|---| | Fundamental nature | Access to a system | How to do a task | | Wire format | JSON-RPC 2.0 over stdio or Streamable HTTP | None; files read into context | | State | Stateful connection, session management | Stateless files | | Auth | Built-in OAuth, scope consent, remote endpoints | No auth model | | Live data | Yes, queries a running service | No, ships static content plus optional local scripts | | Context cost | Tool definitions occupy context while connected | ~100 tokens until triggered; bundled content is free until read | | Distribution | Deployed and versioned as a service | Portable, version-controlled folder | | Reusability | Any MCP-compatible host connects | Any skills-compatible agent runs the folder | | Runtime network | Server controls its own network access | Varies by surface: Claude API skills have no network, Claude Code skills have full network | The rows on auth, state, and live data are what usually decide it. If the capability needs to talk to a running system, hold a session, or authenticate a user, no amount of markdown replaces a server. ## The Decision Framework Walk these five questions in order. The first "yes" that forces a server usually settles it. **1. Does it need a live connection to a running system?** If the capability queries a database, hits a third-party API in real time, or reads state that changes minute to minute, you need a server. A Skill ships static files; it cannot maintain a session or stream fresh data. This is the cleanest MCP signal. **2. Does it need auth or per-user scopes?** MCP has a built-in authorization model: OAuth, incremental scope consent, remote endpoints. Skills have no auth concept. If a human has to grant access to their account, that is server territory. **3. Is the capability mostly procedure and judgment?** If what you are encoding is "how our team writes a postmortem," "the steps to cut a release," or "the house style for a report," that is a Skill. It is knowledge, not a connection. The [why skills beat prompts](/blog/why-skills-beat-prompts-for-coding-agents-2026) argument applies here: durable procedure belongs in a loadable Skill, not a sprawling system prompt. **4. How much reference material rides along, and how often is it needed?** Progressive disclosure makes Skills ideal for large but occasional context: a long API reference, a lookup table, a template library, a validation script. It sits at zero context cost until the moment it is relevant. Cramming that into an always-connected server means paying for it on every request. **5. Who else needs to consume it, and how do you ship updates?** A server is a deployment: you version it centrally, and every client picks up the change by reconnecting. A Skill is a folder: portable, version-controlled, and runnable across any compatible agent, but you distribute copies rather than updating one live endpoint. If ten teams need the same live capability, a server centralizes it. If ten teams need the same playbook, a Skill travels well but you own the sync. If none of questions one, two, or three forces a server, default to a Skill. It is lighter, cheaper in context, and portable. Reach for a server when the capability is fundamentally a connection. ## When You Want Both This is the case the "vs" framing hides, and it is the one Anthropic actually documents. In the [Agent Skills announcement](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills), the engineering team writes that they "explore how Skills can complement Model Context Protocol (MCP) servers by teaching agents more complex workflows that involve external tools and software." Read that carefully, because it is the whole pattern. The MCP server provides the raw access: it exposes the tools that touch your issue tracker, your cloud console, your data warehouse. The Skill provides the workflow: the sequence, the conventions, the judgment about when to call which tool and what to do with the result. A concrete shape: an MCP server exposes `create_issue`, `search_issues`, and `update_issue` against your tracker. On its own, the agent can call those, but it does not know your triage rules, your labeling scheme, or your escalation ladder. A Skill named "triage-incoming-bugs" encodes exactly that, and calls the server's tools as its hands. The server is the muscle, the Skill is the training. Neither replaces the other. So the mature answer to "MCP server or Skill" is often "a thin server for access, and a Skill for the workflow on top." Build the server when there is a real system to reach; build the Skill when there is a real way you want the work done. ## One Honest Caveat On the Framework The clean decision table above is a synthesis, not an Anthropic edict. The primary docs describe the properties of each, and the announcement says Skills "complement" MCP, but Anthropic does not publish a prescriptive "use X here, Y there" checklist. Sharper slogans you may have seen (variations of "MCP is the hammer, Skills explain how to swing it") come from community writers, not the official docs. The framework here is built from the documented properties (state, auth, context cost, distribution), which is the honest way to reason about it. When someone hands you a crisp rule, check whether it is grounded in those properties or just a memorable line. ## The Take Stop treating this as a versus. MCP is a protocol for reaching systems; Skills are packaged expertise for doing work. If your capability is a connection with state and auth, build a server. If it is procedure, judgment, and reference material, build a Skill, and enjoy the near-zero context cost until it fires. And when a capability is both a system and a way of using that system, which is most real engineering work, build a small server for the access and a Skill for the workflow that drives it. The teams that ship reliable agents in 2026 are not the ones that picked the trendier primitive. They are the ones that matched the primitive to the question. ## FAQ ### What is the difference between an MCP server and an Agent Skill? An MCP server is a service that exposes capabilities (tools, resources, prompts) to an agent over a standardized JSON-RPC connection, per the [MCP spec](https://modelcontextprotocol.io/specification/2025-11-25). It is access to a live system, with state and auth. An Agent Skill is a folder of instructions and optional resources that loads into the agent's context on demand, per [Anthropic's docs](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview). It is procedural knowledge about how to do a task, not a connection. ### Can Skills and MCP servers work together? Yes, and Anthropic frames them as complementary. The [Agent Skills announcement](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) describes Skills teaching agents "more complex workflows that involve external tools and software." A common pattern is an MCP server that provides access to a system and a Skill that encodes the workflow for using that system's tools. ### When should I build an MCP server instead of a Skill? Build a server when the capability needs a live connection to a running system, holds session state, or requires authentication and per-user scopes. Those are things a static Skill folder cannot provide, since a Skill ships files rather than maintaining a connection. ### When is an Agent Skill the better choice? Choose a Skill when the capability is mostly procedure, judgment, or reference material: house style, release steps, triage rules, or a large lookup document. Progressive disclosure keeps a Skill at roughly 100 tokens until it is triggered, so heavy reference content costs nothing until needed. Skills are also portable across any skills-compatible agent. ### Do Skills cost context window space? Very little until used. Anthropic's docs describe three levels: only name and description (about 100 tokens per Skill) load at startup, the instruction body loads when triggered, and bundled files or scripts load only when read or executed. Script code returns output without the code entering context. ### Are Agent Skills specific to Claude? No. The format "was originally developed by Anthropic, released as an open standard," per [agentskills.io](https://agentskills.io), and has been adopted by tools including Cursor, Gemini CLI, GitHub Copilot, OpenAI Codex, Goose, and Letta. Runtime behavior can differ by host: for example, Claude API skills run without network access while Claude Code skills have full network access. ### Is MCP changing in 2026? Yes. The stable spec is dated 2025-11-25, and a [release candidate dated 2026-07-28](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) moves MCP toward a stateless protocol layer. If you are building a server now, build toward that direction; see the [stateless migration guide](/blog/mcp-stateless-migration-guide-2026). ## Sources - [Model Context Protocol Specification, 2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25) - [MCP Basic Transports](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports) - [MCP 2025-11-25 Changelog](https://modelcontextprotocol.io/specification/2025-11-25/changelog) - [MCP 2026-07-28 Release Candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) - [Agent Skills Overview, Anthropic](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) - [Claude Code Skills Documentation](https://code.claude.com/docs/en/skills) - [Agent Skills Open Standard](https://agentskills.io) - [Anthropic Engineering: Equipping Agents for the Real World with Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)

Nimbalyst: A Visual Workspace That Unifies Codex and Claude Code

Developers Digest — Thu, 02 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Watch: Nimbalyst in 10 Minutes](https://www.youtube.com/watch?v=CozwidIE5vw) | The full walkthrough on the DevDigest channel | | [Nimbalyst](https://nimbalyst.com/) | Official product page | | [Nimbalyst on GitHub](https://github.com/Nimbalyst/nimbalyst) | Open-source repository | ## What This Video Covers [Nimbalyst](https://nimbalyst.com/) is a visual workspace that unifies [Codex](/blog/openai-codex-guide) and [Claude Code](/blog/what-is-claude-code) alongside built-in project management. It authenticates both providers through their existing CLIs, so you use the subscriptions you already pay for rather than wiring up separate API keys. The walkthrough creates a new workspace, sets agent autonomy permissions, monitors usage across both providers, and runs the built-in planning flow, where the agent drafts a goal, success criteria, and tech stack, asks clarifying questions, and writes a markdown plan before touching code. From there the demo scaffolds a Next.js SaaS landing page, reviews the created and edited files, and drives a Kanban board where sessions and subtasks move through stages and can run in parallel. This post is a companion to the video. Watch the walkthrough for the live demo, then use the links here to place the tool in context. ## The Idea in One Line Give the coding agent a project board instead of a chat log. Nimbalyst's bet is that the missing layer for CLI agents is not more model power but a workspace that holds the plan, the tasks, and the run history in one place, so work does not live only in a scrollback buffer. ## Why It Matters Three things make this worth a look: - **It is provider-neutral.** Codex and Claude Code run side by side, authenticated through their own CLIs, and you can switch models mid-task. That matches the reality that most developers already work across [more than one agent](/blog/claude-code-vs-codex-vs-cursor-vs-opencode) rather than committing to a single provider. - **Planning happens before code.** The agent produces a goal, success criteria, and a written markdown plan, and asks questions before it starts editing. Forcing that step is a workflow constraint, not a model feature, and it is where a lot of agent runs go wrong. - **The Kanban board is the orchestration surface.** Sessions and subtasks flow through stages and can run in parallel, which turns loose agent runs into something you can [coordinate and inspect](/blog/how-to-coordinate-multiple-ai-agents). ## What Else the Walkthrough Shows Beyond the core loop, the video demonstrates committing changes with "commit with AI," adding and prioritizing tasks, launching sessions directly from a task, and built-in Mermaid and Excalidraw visuals. It also covers marketplace extensions, Claude and Claude Code plugins, MCP servers, and optional local model support through LM Studio, so the workspace can reach both hosted and local models. ## Where It Fits Nimbalyst is one entry in a growing category of [local coding-agent workspaces](/blog/local-coding-agent-workspaces-2026) that wrap the CLI agents you already use with project structure. The useful lens is not "which tool is best" but which layer each tool owns: the model owns generation, the CLI owns execution, and a workspace like this owns the plan, the board, and the history. If you are evaluating where a tool like this earns its place, the [OpenAI Codex guide](/blog/openai-codex-guide) and the [Claude Code guide](/blog/what-is-claude-code) cover the underlying agents it orchestrates. ## Getting Started Nimbalyst is open source, so the fastest path is to check the [GitHub repository](https://github.com/Nimbalyst/nimbalyst) for install steps and point it at a small throwaway project first. Authenticate the CLIs you already use, set conservative autonomy permissions, and run the planning flow on a low-risk task so you can see exactly what the agent proposes before it writes anything. Watch the full walkthrough above, then scaffold your first workspace and let the board hold the plan. ## FAQ ### What is Nimbalyst? Nimbalyst is an open-source visual workspace that unifies OpenAI Codex and Claude Code with built-in project management. It runs both agents through their existing CLI subscriptions and adds a Kanban board, a planning workflow, AI-assisted commits, and diagram support so agent work has structure beyond a chat window. ### Do I need separate API keys to use it? No. Nimbalyst authenticates Codex and Claude Code through their existing CLIs, so it uses the subscriptions you already have rather than requiring separate API billing. It also supports local models through LM Studio. ### How is it different from using Claude Code or Codex directly? The agents are the same. Nimbalyst adds the workspace layer around them: a planning step that writes a markdown plan before coding, a Kanban board where sessions and subtasks run and can go in parallel, usage monitoring across both providers, and the ability to switch models mid-task. It owns the workflow rather than the generation. ### Is Nimbalyst free and open source? The project is open source and available on [GitHub](https://github.com/Nimbalyst/nimbalyst). Check the repository and the [product page](https://nimbalyst.com/) for current licensing and any hosted options. ### Can it run more than one agent at once? Yes. The Kanban board lets sessions and subtasks move through stages and run in parallel, which is the feature that turns it from a single-agent chat wrapper into a coordination surface for multiple runs.

Non-Developers Using AI Agents Need Platform Engineering

Developers Digest — Thu, 02 Jul 2026 00:00:00 GMT

OpenAI's latest workplace-agent research is not only an adoption story. It is a platform-engineering warning. **Last updated:** July 2, 2026 OpenAI Economic Research studied ChatGPT Enterprise customers using agents from January through early June 2026, covering 137 companies and 189,000 agent conversations. The headline is that non-developer workflows are showing up in real enterprise usage, not only demos. The practical takeaway for engineering teams is sharper: if agents are moving into finance, legal, recruiting, sales, and operations, the company needs paved paths before every team builds its own shadow automation stack. That connects directly to the control-plane pattern in [OpenAI's June API updates](/blog/openai-api-control-plane-june-2026), the operating model behind [Codex automations](/blog/codex-automations-recurring-engineering-work), and the safety frame in [agent capability ledgers](/blog/agent-containment-capability-ledger). The agent market is moving from "developers can automate code" to "everyone can automate work." That second phase is where platform teams matter most. ## The Signal: Agents Are Escaping The Developer Corner The useful part of OpenAI's report is the shape of the work. OpenAI says agents are being used across knowledge-work categories, including coding, writing, data analysis, research, and business operations. That matters because enterprise AI adoption often starts with a chatbot and stalls when the work needs files, tools, approvals, private data, and accountability. Agents cross that boundary. A normal assistant can summarize a document. An agent can inspect a folder, draft a plan, update a spreadsheet, call an internal tool, prepare a ticket, or run a workflow. That is why the rise of non-developer agents should not be treated as a training problem only. It is an internal-platform problem. The wrong response is simple enablement theater: | Bad reaction | Why it fails | |---|---| | Give every team a generic agent builder | Nobody owns permissions, logging, or lifecycle | | Ban agents outside engineering | Workflows move into unsanctioned tools | | Ask security to review every workflow manually | Review becomes the bottleneck | | Buy one horizontal agent platform and call it done | Real work still needs domain-specific context | The better response is a paved path. ## What A Paved Path Looks Like Non-developer agents need a platform contract that is boring enough to repeat. At minimum, every sanctioned agent workflow should answer six questions: | Question | Platform artifact | |---|---| | What can it access? | Tool allowlist, data scope, OAuth scopes, filesystem boundary | | Who owns it? | Team owner, reviewer, escalation path | | What does it cost? | Model budget, hosted-tool cost, per-run ceiling | | What did it do? | Trace, tool-call log, output artifact, user approval record | | How does it fail? | Stop conditions, retry limits, rollback path | | How is it evaluated? | Baseline task, acceptance rubric, change history | That sounds heavy until you compare it with the alternative: dozens of teams running business-critical agents with no shared receipts. The lesson from developer agents applies here too. Once a workflow can act, the product surface is not the chat box. The product surface is the harness around it: identity, tools, memory, policy, logs, approval, rollback, and cost control. ## The Developer Team's New Job This is where engineering can either become the blocker or the multiplier. The blocker pattern is familiar: central IT says no, teams keep experimenting anyway, and every useful workflow becomes a one-off script with an API key in the wrong place. The multiplier pattern is more practical: 1. Build a small catalog of approved tools. 2. Give each tool a capability label, not only a name. 3. Route sensitive actions through human approval. 4. Log every tool call and model decision that changes business state. 5. Start each new workflow from a template that already includes budgets and receipts. That is the same operating discipline behind [long-running agents needing harnesses](/blog/long-running-agents-need-harnesses). The agent can be flexible. The wrapper should be predictable. For a sales-ops agent, the tool catalog might include CRM read access, draft-only email creation, and account-note summarization. For a finance agent, it might include read-only invoice search, spreadsheet generation, and approval-required vendor updates. For a recruiting agent, it might include calendar availability, candidate-note summarization, and draft outreach. The point is not to give every non-developer a terminal. The point is to turn agent power into safe internal products. ## Why "Just Use ChatGPT" Is Not Enough ChatGPT Enterprise can be the entry point. It is not the whole platform. Enterprise agents need to touch systems of record. They need to know which documents are canonical. They need to avoid leaking sensitive context into the wrong workflow. They need to respect retention policy. They need to stop when the task becomes ambiguous. They need to leave a reviewable trail. That is why OpenAI's broader platform direction matters. The recent OpenAI API work around workload identity, Admin APIs, spend controls, model allowlists, retention controls, hosted tools, and private tool connectivity is not cosmetic. Those are the pieces that let a company say: "This agent can run, but only inside this boundary." The same idea shows up in [agent eval receipts](/blog/agent-evals-need-baseline-receipts). You do not need a giant eval platform on day one. You do need a stable way to compare the current workflow against the next version before a small prompt tweak changes how invoices, contracts, candidates, or customer notes are handled. ## The Opposing Take: Most Teams Are Not Ready The skeptical take is fair. Many teams do not have clean data ownership, current SOPs, reliable internal APIs, or clear approval boundaries. Adding agents can amplify that mess. A workflow that was vague as a checklist becomes dangerous when an agent starts executing it. That is not an argument against agents. It is an argument against pretending agents remove organizational debt. If a process is undocumented, contradictory, and politically sensitive, an agent will not magically make it operational. It will make the gaps visible. The first platform-engineering job is often not model selection. It is turning messy implicit process into explicit workflow contracts. ## A Practical Rollout Plan Start smaller than the vendor demo. Pick one internal workflow where the answer can be reviewed before it changes business state: - draft a renewal brief from CRM notes and recent tickets - summarize a vendor contract for legal review - prepare a recruiting packet from interview notes - produce a finance variance memo from approved spreadsheets - turn a customer call transcript into a draft implementation plan Then ship it with a contract: | Layer | First version | |---|---| | Inputs | Named folders, systems, or records only | | Tools | Two or three approved actions | | Output | Draft artifact, not automatic state change | | Approval | Human accepts, edits, or rejects | | Logging | Prompt, tool calls, sources, final artifact | | Budget | Per-run ceiling and weekly owner report | | Evaluation | Ten saved examples with pass/fail notes | That is boring. It is also how agent adoption survives contact with a real company. ## SEO Takeaway The search term to watch is not only "AI agents." It is the cluster around "AI agents for business operations," "ChatGPT Enterprise agents," "non developer AI agents," "agent workflow automation," and "AI agent governance." The Google Trends check for this run could not be completed locally because no Trends client was available in the environment and prior automation runs hit HTTP 429. I used those phrases for query framing only, then weighted primary-source quality, existing-site duplicate risk, and durable platform-engineering intent instead of fabricated trend numbers. That should be the editorial stance too. The durable story is not that one report proves every office worker gets an agent tomorrow. The durable story is that non-developer agent usage turns AI adoption into an internal-platform problem. Developers will still build many of the primitives. But the users will not all be developers. ## FAQ ### What are non-developer AI agents? Non-developer AI agents are agent workflows used by teams outside software engineering, such as finance, legal, sales, recruiting, support, and operations. They can draft, research, analyze, update tools, and prepare artifacts without requiring the user to write code. ### Why do non-developer AI agents need platform engineering? They need platform engineering because business workflows require permissions, tool access, audit logs, cost controls, approval steps, and rollback paths. Without a shared platform, every team tends to create its own fragile automation pattern. ### Should companies let every team build its own AI agents? Teams should be able to build useful workflows, but not from scratch with unlimited access. A better model is a paved path: approved tools, workflow templates, ownership, budgets, logging, and human approval for sensitive actions. ### What is the first safe workflow for enterprise AI agents? Start with draft-only workflows where a human reviews the result before it changes a system of record. Good examples include renewal briefs, contract summaries, recruiting packets, finance memos, and customer-call implementation plans. ## Sources - [OpenAI Economic Research: How agents are transforming work](https://openai.com/index/how-agents-are-transforming-work/) - accessed July 2, 2026. - [OpenAI Codex documentation](https://developers.openai.com/codex/) - accessed July 2, 2026. - [OpenAI API platform documentation](https://platform.openai.com/docs) - accessed July 2, 2026. - [OpenAI Agents SDK tracing docs](https://openai.github.io/openai-agents-python/tracing/) - accessed July 2, 2026.

Linked Context: When a Skill Can Point at the Whole Web

Developers Digest — Thu, 02 Jul 2026 00:00:00 GMT

A [previous post](/blog/skills-over-mcp-progressive-disclosure) made an argument: `SKILL.md` and the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) solve two halves of the same problem, and the useful move is to run skills over MCP so an agent pays context cost only in proportion to what a task needs. The implementation was three tools - `list_skills`, `get_skill`, `get_skill_file` - rebuilding [progressive disclosure](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) on the wire. That version worked, but it served a fixed catalog we wrote. This post is about what happens when you take the two constraints off that design: that the skills have to be ours, and that a skill's contents have to be copied in ahead of time. Both constraints are gone now. The feature is called Skill Studio, and the interesting part is not the authoring UI. It is what the authoring UI is allowed to reference. ## The constraint worth removing Go back to what a skill actually is. A skill is a `SKILL.md` with a name and a description, plus optional bundled files - reference docs, checklists, scripts - that the agent pulls in only when the work demands them. In the first version, every one of those bundled files was content we had written and stored. The manifest an agent saw over `get_skill` listed real files with real bytes behind them, sitting in our data store, waiting to be fetched. That is fine for a curated library. It falls apart the moment you want a skill to reference something you do not own and that changes without you. A framework's migration guide. An API's current pricing page. Your own team's runbook that lives in a wiki. The moment a skill's value depends on a document maintained somewhere else, copying that document into the skill is the wrong move. The copy is stale the day after you make it, and now you own a synchronization problem you did not ask for. The fix is to let a skill file be a reference instead of a copy. In the Studio, a file inside a skill is one of two kinds. An inline file is content authored in place and stored with the skill, exactly like before. A linked file is a URL. The skill stores the path and the URL and nothing else. No bytes are copied at author time. The document on the other end stays where it is, owned by whoever owns it, changing whenever it changes. ## Progressive disclosure, extended past the skill Here is the part that makes this more than a convenience. A linked file is not fetched when the skill is saved, and it is not fetched when an agent lists skills, and it is not even fetched when an agent opens the skill to read its manifest. It is fetched at exactly one moment: when the agent calls `get_skill_file` on that specific path because the `SKILL.md` body told it that this is the depth it now needs. That is the same escalation the original three tools implemented, carried one level further out. The first version disclosed in three stages: the cheap index, then one skill's body and file manifest, then one file's contents. Linked context adds a fourth boundary. The contents of that one file might themselves live on the open web, and the token cost of that remote document is only paid at the instant of the fetch. An agent can hold a skill in context whose reference material is a ten-thousand-word external spec, and pay nothing for that spec until the one task in a hundred that actually reaches for it. Progressive disclosure was always about paying in proportion to need. The skill boundary used to be where that discipline stopped: past it, everything was copied in and resident. Linked context moves the boundary out to the network. The manifest an agent reads carries the path, a one-line purpose, and the fact that the source is remote - but never the contents. It is a promise of context, redeemable on demand, rather than context you are already carrying. The resolution itself is deliberately boring, because a feature that can fetch arbitrary URLs on behalf of an agent has to be. Links are validated as ordinary public `http(s)` URLs, with internal and loopback hosts refused so a skill cannot be pointed at infrastructure it should not see. Fetches run with a timeout and a size cap, so one slow or enormous document degrades to a truncated read rather than a hung tool call. A failed fetch does not throw - it returns a readable message as the file's contents, so the agent learns the source was unreachable instead of watching the call crash. The point of linked context is to widen what a skill can reach without widening what can go wrong when it reaches. ## The same endpoint, scoped to your key The second constraint we removed was ownership. In the first version, the catalog was first-party. Skill Studio lets any member author skills, and those skills are served over the identical MCP endpoint, through the identical three tools, with the identical disclosure tiers. There is no second API, no separate "user skills" transport, no different shape to learn. The way this stays safe is scoping by key. MCP has no session on its transport - there is no cookie, no logged-in browser. Every call authenticates with an API key, and the key resolves to exactly one owner. So when an agent calls `list_skills`, the response is the first-party library plus that caller's own skills, and nobody else's. `get_skill` and `get_skill_file` resolve against the same visible set. Your skills ride the public endpoint, but they are visible only to the key that owns them. The universal library and your private skills come down the same pipe, disambiguated entirely by who is asking. This matters more than it sounds. It means a member's own skills get the exact economics and mechanics of the flagship ones. The manifest a user skill produces mirrors the first-party manifest field for field, so an agent cannot tell the difference between a skill we wrote and a skill you wrote - both disclose the same way, cost context the same way, and download the same way. The library stops being a thing we publish to you and becomes a surface you extend. You are not consuming a catalog. You are adding to the one your own agents read. ## Authoring is consumption The third idea is the smallest and the one that changes how it feels to use. The Studio has a live preview, and the preview does not render a prettied-up marketing view of your skill. It renders the file tree exactly as an agent sees it over MCP: `SKILL.md` first, then each file with its path and its one-line purpose, inline files showing their content, linked files showing their URL and the fact that their bytes arrive on demand. The reason this is worth building deliberately is that the usual failure mode of authoring tools is a gap between what the author sees and what the consumer gets. You write in a rich editor, the machine receives something flattened and different, and you find out about the mismatch when the agent behaves oddly. Collapsing that gap means the thing you are editing and the thing an agent will read are the same artifact. When you mark a file as a link, you immediately see it presented as a promise of remote context rather than resident text - which is exactly how the agent will encounter it. When you write a `SKILL.md` body, you are writing the activation-stage document an agent will pull, not a description of it. Authoring becomes consumption. The preview is not a preview of a rendering; it is a preview of the disclosure. That is the right shape for a tool whose output is read by a model, because the model reads the raw artifact, and so should you while you make it. ## Why this is the direction None of these three moves is a new primitive. Linked context is [MCP's resource model](https://modelcontextprotocol.io/specification/2025-06-18/server/resources) - a manifest of things that can be fetched, rather than a wall of content - applied to skill files. Per-key scoping is just honest multi-tenancy on an endpoint that already authenticates every call. The live preview is the old lesson that authoring and consumption should not diverge. What is new is putting them together and noticing that they compose into something with a clear trajectory. The trajectory is this. A skill started as a file on one machine's disk. The first version made it a thing served from a network, so it could be versioned and shared and access-controlled like an API. Linked context makes a skill a composition of references - some resident, some remote, all disclosed only when needed - so a skill can assemble context from anywhere without paying for it up front. Per-key scoping makes that composition personal, so the library an agent reads is partly ours and partly yours with no seam between them. The direction of travel is from context as a payload you ship to context as a graph you point into and pull from lazily, and skills-over-MCP turns out to be a clean substrate for exactly that. That is the bet [Developers Digest](/dashboard/skills-studio) is making at the frontier of agent tooling: the interesting unit is not the prompt or the tool call but the disclosure discipline around a body of knowledge that is too large to hold and too dynamic to copy. Skill Studio is the first place you can build on that unit directly. ## FAQ ### What is a linked context file? It is a file inside a skill whose contents live at a URL rather than being stored with the skill. The skill's manifest carries the path and the URL; the bytes are fetched on demand only when an agent calls `get_skill_file` for that path. It lets a skill reference an external document - a spec, a changelog, a runbook - without copying it in and without owning a synchronization problem. ### How is that different from just pasting the document into the skill? A pasted document is a copy: stale the moment the source changes, and resident in the skill whether or not any task needs it. A linked file stays current because it points at the live source, and it costs no context until the moment an agent decides to fetch it. You trade a guaranteed stale copy for a fresh fetch paid for only on use. ### Do user skills use a different MCP endpoint than the first-party library? No. Member-authored skills are served over the same MCP endpoint through the same three tools - `list_skills`, `get_skill`, `get_skill_file` - with the same progressive-disclosure tiers. They are scoped by API key, so a caller sees the shared library plus their own skills and nobody else's. ### How are my skills kept private if they are on a public endpoint? The MCP transport has no session; every call authenticates with an API key that resolves to one owner. The skill-listing and skill-fetching tools resolve against the set visible to that key, which is the first-party library plus the key owner's own skills. Another member's key never sees yours. ### Can a linked file point at an internal or private URL? No. Links are validated as public `http(s)` URLs, and internal or loopback hosts are refused, so a skill cannot be aimed at infrastructure it should not reach. Fetches also run under a timeout and a size cap, and a failed fetch returns a readable error as the file contents rather than crashing the tool call. ### What does the Studio live preview show? It renders the skill exactly as an agent receives it over MCP: `SKILL.md` first, then each file with its path and one-line purpose, inline files showing content and linked files showing their URL and on-demand nature. The artifact you edit is the artifact the agent reads, so there is no gap between authoring and consumption. ### Where can I read the background on skills over MCP? Start with the earlier post, [Skills Delivered Over MCP](/blog/skills-over-mcp-progressive-disclosure), then the [one-endpoint reference architecture](/blog/one-endpoint-progressive-disclosure) and [Agent Studio](/blog/agent-studio-one-endpoint), which carry the same idea to files, memory, and member-authored agents. For the primary sources: Anthropic's [Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) writeup and [documentation](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview), and the Model Context Protocol [resources specification](https://modelcontextprotocol.io/specification/2025-06-18/server/resources).

The Economics of Agent Fleets: Fable 5 Orchestrators, Sonnet 5 Workers

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Claude Fable 5 and Mythos 5 Announcement](https://www.anthropic.com/news/claude-fable-5-mythos-5) | Fable 5 launch post, pricing, vendor benchmarks | | [Introducing Claude Sonnet 5](https://www.anthropic.com/news/claude-sonnet-5) | Sonnet 5 announcement, intro pricing | | [What's New in Sonnet 5](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5) | Tokenizer change documentation | | [Claude Pricing](https://claude.com/pricing) | Current pricing for all Claude models | | [Claude Models Overview](https://platform.claude.com/docs/en/about-claude/models/overview) | Model specifications and API details | _Part 2 of the Fable 5 agent fleets series. It builds on Part 1, [Orchestrating a Fleet of Agents with Fable 5](/blog/fable-5-agent-fleet-orchestration), and the series origin, [Fable 5 Is Back](/blog/fable-5-returns-what-changed)._ The manager-model pattern from Part 1 has an obvious objection: Fable 5 is expensive. At $10 per million input tokens and $50 per million output, running your whole fleet on it would be brutal. But that is not the pattern. The pattern is one expensive orchestrator and many cheap workers, and once you do the arithmetic it beats an all-frontier fleet for most workloads. This post works the numbers. A note on the numbers: every dollar figure below is an illustrative estimate built from published per-token prices and made-up but plausible token counts. The point is the shape of the math, not a quote for your workload. Your real costs depend on your prompts, your caching, and how much your workers actually read and write. For the per-tool subscription side of the budget, the [AI coding tools pricing comparison](/blog/ai-coding-tools-pricing-2026) is the companion reference. ## The three prices that matter All prices are per 1M tokens, input / output: - **Fable 5** (`claude-fable-5`): $10 / $50. Anthropic's most capable widely released model, the orchestrator in this pattern. See the [launch post](https://www.anthropic.com/news/claude-fable-5-mythos-5). - **Opus 4.8**: $5 / $25. The step-down frontier model and, notably, the model Fable 5 falls back to on a refusal. - **Sonnet 5** (`claude-sonnet-5`): $2 / $10 introductory, through August 31, 2026, then $3 / $15. Anthropic calls it its "most agentic Sonnet yet," near Opus 4.8 on agentic and coding tasks. See the [Sonnet 5 announcement](https://www.anthropic.com/news/claude-sonnet-5). The spread is the whole story. Sonnet 5 output is one-fifth the price of Fable 5 output at the intro rate. When most of your fleet's token volume is worker output - and in a fan-out of code or content, it is - moving that volume to Sonnet 5 is where the savings live. ## The tokenizer caveat that changes worker math Before the arithmetic, one catch that is easy to miss. Sonnet 5 ships with a new tokenizer that produces roughly 30% more tokens for the same text (see the [what's new page](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5)). That means a naive per-token price comparison understates Sonnet 5's real cost, because the same work consumes about 30% more billable tokens. Fold that in and the effective intro output rate is not $10 per "unit of text equivalent to a million old tokens" but closer to $13 once you account for the token inflation. Sonnet 5 is still far cheaper than Fable 5 as a worker. But the tokenizer change narrows the gap, and if you benchmarked worker cost on an older Sonnet's tokenizer, your estimate is low. Re-measure on real Sonnet 5 outputs rather than trusting an old ratio. ## Illustrative cost math: a fan-out build Take a concrete, made-up job: an orchestrator plans a refactor and fans it out to 10 worker tasks, each editing one module. All token counts below are invented for illustration. **Orchestrator (Fable 5).** Say it reads a 200K-token slice of the repo plus spec, and across planning, dispatching, and verifying 10 results it produces 60K output tokens. - Input: 0.2M x $10 = $2.00 - Output: 0.06M x $50 = $3.00 - Orchestrator subtotal: **$5.00** **Workers (Sonnet 5, intro rate).** Say each worker reads 40K tokens of context and writes a 15K-token diff plus reasoning. Apply the ~30% tokenizer inflation to both sides, so 40K becomes ~52K input and 15K becomes ~19.5K output. - Per worker input: 0.052M x $2 = $0.104 - Per worker output: 0.0195M x $10 = $0.195 - Per worker: ~$0.30 - 10 workers: **~$3.00** **Fleet total: about $8.00**, split roughly $5 orchestrator and $3 workers. Now price the same job as an all-Fable-5 fleet. The orchestrator cost is unchanged at $5. But each worker's 40K in / 15K out on Fable 5 (no tokenizer inflation, since that is a Sonnet 5 property) is: - Input: 0.04M x $10 = $0.40 - Output: 0.015M x $50 = $0.75 - Per worker: $1.15 - 10 workers: **$11.50** **All-Fable-5 total: about $16.50.** Same orchestrator, roughly 4x the worker cost, about double the total. The split fleet does the same job for around half the money, and the workers are doing bounded, well-specified tasks where Sonnet 5's near-Opus agentic quality is enough. That is the core result. As the worker count grows, the gap widens, because worker volume dominates and that is exactly the volume you moved to the cheaper model. ## When to promote a worker to Opus 4.8 Sonnet 5 is the default worker, but not every slice is equal. Promote a worker to Opus 4.8 ($5 / $25) when the task carries more risk than a routine edit: - The slice is on a critical path where a subtle bug is expensive to catch later. - The task needs deeper reasoning than a scoped edit - a tricky algorithm, a security-sensitive change, a gnarly migration step. - Your verify loop keeps bouncing a particular slice back to Sonnet 5. If a worker fails verification twice, promoting it is usually cheaper than a third round plus the orchestrator's verification time on each attempt. Opus 4.8 output at $25 is 2.5x Sonnet 5's intro rate but half of Fable 5's, so it is the sensible middle tier for the handful of slices that need more than a default worker but do not justify the orchestrator's model. ## When the task justifies Fable 5 end to end Sometimes the split fleet is the wrong tool and you should just run Fable 5 for the whole thing. That is the right call when the task is long-horizon and hard to decompose cleanly - the exact profile where Anthropic reports Fable 5's lead is largest, and where its vendor-reported results cluster: a codebase-wide migration across a 50M-line Ruby codebase in about a day at Stripe, top scores on Cognition's FrontierCode and Cursor's CursorBench, and outsized gains from file-based memory on long-running tasks (all vendor and partner reported, from the [launch post](https://www.anthropic.com/news/claude-fable-5-mythos-5)). The trade is real. If a job cannot be split into independent slices without the slices needing to know about each other constantly, the coordination overhead of a fleet eats the savings, and a single Fable 5 run holding the whole problem in its 1M context can be both cheaper and better. The heuristic: if you can write clean, independent worker specs, run the split fleet. If every slice bleeds into every other, run Fable 5 end to end and pay for the capability. ## The decision in one line For most workloads with decomposable work, one Fable 5 orchestrator plus a fleet of Sonnet 5 workers is the cost-quality sweet spot, with Opus 4.8 as the promotion tier for risky slices. Reserve all-Fable-5 for the long-horizon, hard-to-split jobs where its lead is worth the premium. Run the arithmetic on your own token counts before committing - the shape holds, but the exact break-even depends on how much your workers read and write. ## Frequently Asked Questions ### Is an all-frontier agent fleet ever worth it? Rarely for decomposable work. If your tasks split into clean, independent slices, running every worker on Fable 5 roughly doubles total cost for the same output versus Sonnet 5 workers, because worker volume dominates and Sonnet 5 is near Opus 4.8 on agentic tasks. All-frontier makes sense for a single long-horizon job that cannot be split cleanly, where one Fable 5 run holding the whole problem beats the coordination overhead of a fleet. ### How does the Sonnet 5 tokenizer change affect worker cost? Sonnet 5's new tokenizer produces roughly 30% more tokens for the same text, so the same work bills about 30% more tokens on both input and output. A naive per-token price comparison understates its real cost. Sonnet 5 is still far cheaper than Fable 5 as a worker, but re-measure worker cost on actual Sonnet 5 outputs rather than trusting a ratio from an older tokenizer. ### When should I promote a worker from Sonnet 5 to Opus 4.8? When the slice is on a critical path, needs deeper reasoning than a routine edit, or keeps failing your verify loop. Opus 4.8 output at $25 per million is 2.5x Sonnet 5's intro rate but half of Fable 5's, making it the sensible middle tier for the few slices that need more than a default worker but do not justify the orchestrator's model. ### What are the current prices for these models? Per million tokens, input / output: Fable 5 is $10 / $50, Opus 4.8 is $5 / $25, and Sonnet 5 is $2 / $10 introductory through August 31, 2026, then $3 / $15. All figures are Anthropic's published rates as of July 1, 2026. Confirm current pricing on Anthropic's model pages before budgeting. ## Sources - Anthropic, [Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) (launch, pricing, vendor-reported benchmarks) - Anthropic, [Introducing Claude Sonnet 5](https://www.anthropic.com/news/claude-sonnet-5) (pricing and positioning) - Anthropic Docs, [What's new in Claude Sonnet 5](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5) (tokenizer change) - Anthropic Docs, [Introducing Claude Fable 5 and Claude Mythos 5](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5) - Developers Digest, [Orchestrating a Fleet of Agents with Fable 5](/blog/fable-5-agent-fleet-orchestration) - Developers Digest, [Fable 5 Is Back: The Anthropic Model the Government Switched Off](/blog/fable-5-returns-what-changed)

Agents 101: How to Build and Deploy Anything with AI Agents

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Watch: Agents 101](https://www.youtube.com/watch?v=eWs50bhFvMY) | The full walkthrough on the DevDigest channel | | [Vercel](https://vercel.com) | The agentic infrastructure stack used in the video | | [Vercel AI SDK](https://vercel.com/docs/ai) | The SDK for wiring models and tools into agents | ## What This Video Covers **Agents 101** is a behind-the-scenes walkthrough of how to build and deploy AI agents quickly using [Vercel as the agentic infrastructure stack](/blog/vercel-agentic-infrastructure-stack). The goal is simple: go from an idea to a running agent without stitching together a dozen services first. This post is a companion to the video. Watch the walkthrough above for the full build, then use the links here to go deeper on each piece. ## The Mental Model An AI agent is not one thing. It is a loop: a model that reasons, tools it can call, memory it can read and write, and a runtime that keeps the whole thing alive between steps. If you want that broken down from first principles, start with [AI Agents Explained](/blog/ai-agents-explained). The reason Vercel keeps coming up is that it packages the parts you would otherwise assemble by hand. The [agentic infrastructure stack](/blog/vercel-agentic-infrastructure-stack) covers the model routing, sandboxed execution, and deployment surface an agent needs to actually run in production rather than just on your laptop. ## From Idea to Deployed Agent The through-line of the video is speed: how little sits between an idea and a live, deployed agent when the infrastructure gets out of the way. A practical path that mirrors that flow: 1. **Pick a job for the agent.** One clear task beats a vague "assistant." A scoped job is easier to build, test, and trust. 2. **Wire the model and tools.** The [Vercel AI SDK](/blog/vercel-ai-sdk-guide) is the layer that connects a model to the tools it can call. 3. **Give it a framework.** If you want structure instead of a bare loop, the [Eve framework for building AI agents](/blog/vercel-eve-framework-for-building-ai-agents) is a good starting point, and there is a hands-on [build your first agent tutorial](/blog/build-first-agent-vercel-eve-tutorial) that walks it end to end. 4. **Deploy.** The payoff in the video is that deploy is not a separate project. The same stack that runs the agent locally is the one that ships it. ## Where to Go Next If you are just getting oriented, [AI Agents Explained](/blog/ai-agents-explained) is the conceptual base. If you are ready to build, the [Eve framework tutorial](/blog/build-first-agent-vercel-eve-tutorial) is the fastest hands-on route. And when you start thinking about running agents for real, the [agentic infrastructure guide](/blog/vercel-agentic-infrastructure-stack) explains how the pieces compose. Watch the full **Agents 101** walkthrough above, then pick one small job and ship an agent that does it.

Where Should Your AI Agent Run Code: E2B vs Daytona vs Modal vs Cloudflare vs Vercel Sandbox

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Provider | Official Source | |----------|----------------| | E2B | [E2B Docs](https://e2b.dev/docs) and [Pricing](https://e2b.dev/pricing) | | Daytona | [Daytona Docs](https://www.daytona.io/docs) and [Pricing](https://www.daytona.io/pricing) | | Modal | [Modal Sandbox Docs](https://modal.com/docs/guide/sandbox) and [Pricing](https://modal.com/pricing) | | Cloudflare Sandbox | [Cloudflare Sandbox Docs](https://developers.cloudflare.com/sandbox/) and [Pricing](https://developers.cloudflare.com/sandbox/platform/pricing/) | | Vercel Sandbox | [Vercel AI SDK Docs](https://sdk.vercel.ai/docs) | Your AI agent can reason about code. The harder question is where that code actually runs. A year ago, most agent frameworks executed generated code in a local subprocess or a throwaway Docker container. That worked when agents ran short scripts. It breaks down when agents need to run for hours, install arbitrary dependencies, persist state between steps, or operate in production with real users and real data. The execution environment is now a first-class architecture decision, and a new category of sandbox-as-a-service providers has emerged to solve it. This guide compares five providers that offer isolated code execution designed for AI agents: **E2B**, **Daytona**, **Modal**, **Cloudflare Sandbox SDK**, and **Vercel Sandbox**. Each takes a different approach to isolation, persistence, latency, and pricing. The right choice depends on your agent's run length, your existing cloud stack, and how much state your workflows need to carry between steps. ## E2B [E2B](https://e2b.dev) provides on-demand Linux VMs purpose-built for AI agent code execution. Each sandbox is described in their docs as "a fast, secure Linux VM" that you create, run code in, and tear down or pause programmatically ([E2B docs](https://e2b.dev/docs)). **Isolation model.** Each sandbox runs as an isolated VM. The specific virtualization technology is not disclosed in their public documentation, but the persistence model (which saves both filesystem and memory state) is consistent with VM-level isolation rather than shared-kernel containers ([E2B persistence docs](https://e2b.dev/docs/sandbox/persistence)). **State and persistence.** E2B offers the most granular persistence model of the group. You can pause a sandbox (saving filesystem and memory), resume it in approximately 1 second, create named snapshots to fork new sandboxes from a running state, and mount persistent volumes that survive across sandbox lifetimes. Paused sandboxes are kept indefinitely with no automatic TTL. An auto-pause option lets you configure sandboxes to pause instead of terminate on timeout ([E2B persistence docs](https://e2b.dev/docs/sandbox/persistence)). **Cold-start and latency.** Resume from pause is documented at approximately 1 second. Pause takes approximately 4 seconds per 1 GiB of RAM. Templates support a start command that pre-warms processes during build, so sandboxes created from a template have processes "already running" ([E2B template docs](https://e2b.dev/docs/template/quickstart)). Fresh sandbox creation latency is not published as a specific number. **Pricing model.** Three tiers: Hobby (free with one-time credits), Pro ($150/month base), and Ultimate (enterprise custom). All tiers charge per-second usage on top of the base fee, metered by vCPU and RAM. A pricing calculator is available at [pricing.e2b.dev](https://e2b.dev/pricing). **SDK support.** Python and TypeScript SDKs, plus a separate Code Interpreter package that runs code in a Jupyter context supporting Python, JavaScript, TypeScript, Bash, Java, and R ([E2B docs](https://e2b.dev/docs)). **Best for.** Teams that need deep state persistence (pause, resume, snapshot, fork) and want the most mature agent-framework integration ecosystem. E2B documents integrations with LangChain, LlamaIndex, CrewAI, Vercel AI SDK, and OpenAI Agents SDK ([E2B integrations](https://e2b.dev/docs/quickstart/connect-llms)). ## Daytona [Daytona](https://www.daytona.io) positions itself as "AI-first infrastructure optimized for LLMs, agents, and evals." Each sandbox is a full composable environment with a dedicated kernel, filesystem, network stack, and allocated compute resources ([Daytona docs](https://www.daytona.io/docs)). **Isolation model.** Each sandbox gets a dedicated kernel, filesystem, and network stack. The enterprise tier adds customer-managed compute in your own cloud with no shared compute and no cross-tenant risk. Docker-in-Docker, Dockerfiles, and Docker Compose are supported natively ([Daytona docs](https://www.daytona.io/docs)). **State and persistence.** Sandboxes are stateful by design and can run indefinitely. Daytona supports environment snapshots (save, restore, and resume any agent workflow), shared volumes across sandboxes, and external storage mounts. The product describes this as "unlimited persistence" ([Daytona homepage](https://www.daytona.io/)). **Cold-start and latency.** Daytona claims sub-90ms sandbox creation on their homepage and docs. Regional deployment is available across US East, US West, EU Central, EU West, and Asia South ([Daytona docs](https://www.daytona.io/docs)). **Pricing model.** Pure pay-as-you-go with per-second billing. Rates are published per vCPU-hour, per GiB RAM-hour, and per GiB storage-hour. GPU options (NVIDIA H100, RTX PRO 6000) are available at hourly rates. New accounts get free compute credits without a credit card. A startup program offers up to $50K in credits ([Daytona pricing](https://www.daytona.io/pricing)). **SDK support.** Five SDKs: Python, TypeScript, Ruby, Go, and Java. Also provides a RESTful API with OpenAPI spec, a Toolbox API, a CLI, and an MCP server for agent tool integration ([Daytona docs](https://www.daytona.io/docs)). **Best for.** Teams that need the broadest SDK language coverage, GPU sandbox access, long-running stateful agents, or enterprise BYOC (bring your own compute) deployments. Daytona also offers computer-use capabilities with virtual desktops (Linux, macOS, Windows) controllable via code ([Daytona docs](https://www.daytona.io/docs)). ## Modal [Modal](https://modal.com) is a serverless cloud platform with a dedicated Sandbox API for executing untrusted user or agent code. Modal reports over 1 billion sandboxes run on their platform, designed for production agent systems and reinforcement learning training at scale ([Modal sandboxes](https://modal.com/products/sandboxes)). **Isolation model.** Modal uses [gVisor](https://gvisor.dev/), the user-space kernel developed at Google, for containerization and virtualization. gVisor intercepts system calls, providing stronger isolation than standard Linux containers without the overhead of full VMs. Modal also runs continuous synthetic monitoring to verify network and application isolation within their runtime ([Modal security docs](https://modal.com/docs/guide/security)). **State and persistence.** Multiple persistence primitives are available: distributed volumes (persistent filesystem mountable across runs), filesystem snapshots (full sandbox state, retained for 30 days by default), directory snapshots, memory snapshots (7-day retention), distributed key-value dicts, and queues. For sandboxes exceeding the 24-hour maximum lifetime, Modal recommends snapshotting and restoring into a new sandbox ([Modal sandbox docs](https://modal.com/docs/guide/sandbox)). **Cold-start and latency.** Modal claims "sub-second scheduling" for sandboxes with strong cold-start performance on custom images. The sandbox lifecycle moves through Created, Scheduled, Started, and optionally Ready stages, with configurable readiness probes ([Modal sandbox docs](https://modal.com/docs/guide/sandbox)). **Pricing model.** Pure usage-based with per-second billing. Three tiers: Starter ($0 base with $30/month in free credits), Team ($250/month base with $100/month included), and Enterprise (custom). Sandbox compute is priced separately from standard function compute. GPU access ranges from T4 to B200 at per-second rates. Region selection and non-preemptible execution carry multipliers ([Modal pricing](https://modal.com/pricing)). **SDK support.** Python (primary, most mature), JavaScript/TypeScript, and Go SDKs. The Python SDK has the most complete sandbox API coverage ([Modal sandbox docs](https://modal.com/docs/guide/sandbox)). **Best for.** Teams already on Modal for serverless compute who want sandbox execution as a natural extension. Strong fit for RL training environments and large-scale batch agent workloads. Modal documents integration examples with LangGraph and supports up to 100K+ concurrent sandboxes ([Modal docs](https://modal.com/docs)). ## Cloudflare Sandbox SDK [Cloudflare Sandbox SDK](https://developers.cloudflare.com/sandbox/) provides isolated code execution environments built on top of Cloudflare Containers and Workers. It is explicitly positioned for AI agents that need to execute code, interactive dev environments, and CI/CD systems ([Cloudflare Sandbox docs](https://developers.cloudflare.com/sandbox/)). **Isolation model.** Each sandbox runs in its own VM with an Ubuntu Linux container inside. The architecture is three-layer: Workers handle application logic, Durable Objects provide persistent sandbox identity and routing, and Containers provide the isolated Linux environment where code runs. Isolation covers filesystem, process, network, and resource limits per sandbox ([Cloudflare architecture docs](https://developers.cloudflare.com/sandbox/concepts/architecture/)). **State and persistence.** Ephemeral by default. State (files, processes, shell sessions) persists only while the container is active. After an idle timeout (default 10 minutes), the container stops and all state is lost. A `keepAlive` option prevents idle sleep with heartbeat pings. S3-compatible storage (R2, S3, GCS) can be mounted as local filesystems for data that persists across sandbox lifecycles. Durable Objects provide the persistent identity layer, but the container filesystem itself does not survive restarts ([Cloudflare sandbox concepts](https://developers.cloudflare.com/sandbox/concepts/sandboxes/)). **Cold-start and latency.** No specific cold-start numbers are published. Cloudflare's broader platform marketing claims "no cold starts or region complexity," but the sandbox-specific docs do not quantify startup latency. A WebSocket transport option reduces overhead for high-frequency operations by multiplexing SDK calls over a single persistent connection ([Cloudflare sandbox docs](https://developers.cloudflare.com/sandbox/)). **Pricing model.** Usage-based, built on Cloudflare Containers pricing. Requires the $5/month Workers Paid plan. Billing is per 10ms of active running time across memory, CPU, and disk dimensions. Instance types range from lite (1/16 vCPU, 256 MiB RAM) to standard-4 (4 vCPU, 12 GiB RAM). Network egress is metered separately ([Cloudflare sandbox pricing](https://developers.cloudflare.com/sandbox/platform/pricing/)). **SDK support.** TypeScript only for the SDK (`@cloudflare/sandbox` npm package). Inside the sandbox, Python and Node.js/JavaScript execution is supported via dedicated Docker images. A code interpreter API provides automatic result capture for Python and JS ([Cloudflare sandbox docs](https://developers.cloudflare.com/sandbox/)). **Best for.** Teams already deep in the Cloudflare ecosystem (Workers, Durable Objects, R2, AI Gateway) who want sandbox execution without adding another vendor. The credential proxy pattern (Worker injects secrets at request time so the sandbox never holds live keys) is a thoughtful security design for agent workflows ([Cloudflare security docs](https://developers.cloudflare.com/sandbox/concepts/security/)). ## Vercel Sandbox [Vercel Sandbox](https://vercel.com/docs/sandbox) is a compute primitive for running arbitrary code in isolated, ephemeral Linux VMs. It went generally available on January 30, 2026, and is explicitly positioned as "the execution layer for agents" ([Vercel Sandbox GA blog](https://vercel.com/blog/vercel-sandbox-is-now-generally-available)). **Isolation model.** Firecracker microVMs with a dedicated kernel per sandbox. Vercel explicitly contrasts this with Docker containers: each sandbox gets kernel-level isolation, a dedicated private filesystem, network namespace isolation, and strict CPU/memory/disk limits. The underlying infrastructure (internally called "Hive") is the same system that handles Vercel's core deployment platform ([Vercel Sandbox concepts](https://vercel.com/docs/sandbox/concepts)). **State and persistence.** Persistent sandboxes are the default. When a sandbox stops, the SDK automatically snapshots its filesystem. Resuming starts a new session from that snapshot. The model is two-level: a Sandbox is a long-lived named entity, and a Session is a single running VM instance. Calling `runCommand` on a stopped sandbox auto-resumes it. Snapshots expire 30 days after last use by default. Drives (beta) provide attachable persistent storage reusable across sandbox runs. Lifecycle hooks (`onCreate`, `onResume`) handle setup automation ([Vercel persistent sandboxes](https://vercel.com/docs/sandbox/concepts/persistent-sandboxes)). **Cold-start and latency.** Vercel claims sandboxes start in milliseconds, with sub-second starts for thousands of sandboxes per task. Resuming from a snapshot is described as faster than starting fresh. The Firecracker-based infrastructure is optimized for fast boot ([Vercel Sandbox docs](https://vercel.com/docs/sandbox)). **Pricing model.** Usage-based, metered across active CPU, provisioned memory, creations, data transfer, and snapshot storage. A key detail: active CPU billing excludes time waiting for I/O (network calls, database queries, AI model calls), so agents that spend time waiting on LLM responses are not billed for that idle time. Hobby tier includes free monthly quotas. Pro tier charges per-unit rates with a $20/month included credit. Maximum runtime is 45 minutes on Hobby and 24 hours on Pro/Enterprise ([Vercel Sandbox pricing](https://vercel.com/docs/sandbox/pricing)). **SDK support.** JavaScript/TypeScript SDK (`@vercel/sandbox`), Python SDK (`vercel.sandbox`), and an open-source CLI. Available runtimes include Node.js (versions 22, 24, 26) and Python 3.13. Custom images are supported via Vercel Container Registry. Full `sudo` access is available inside sandboxes ([Vercel Sandbox docs](https://vercel.com/docs/sandbox)). **Best for.** Teams already deploying on Vercel who want sandbox execution tightly integrated with their existing platform. Strong fit for AI coding agents and "vibe coding" platforms. Vercel's own agent framework (eve) uses Sandbox as a built-in primitive, and customers like Notion, Conductor, and Blackbox AI use it for production agent workloads ([Vercel blog](https://vercel.com/blog/vercel-sandbox-is-now-generally-available)). ## Comparison Summary | Dimension | E2B | Daytona | Modal | Cloudflare Sandbox | Vercel Sandbox | |-----------|-----|---------|-------|-------------------|----------------| | Isolation | VM (type undisclosed) | Dedicated kernel | gVisor (user-space kernel) | VM with Ubuntu container | Firecracker microVM | | Persistence | Deep (pause, resume, snapshot, volumes, indefinite) | Stateful by design, snapshots, volumes | Volumes, filesystem/memory/directory snapshots | Ephemeral by default, bucket mounts for durability | Persistent by default, auto-snapshot, drives (beta) | | Max runtime | Up to 24 hours (Pro) | Unlimited | 24 hours (then snapshot and restore) | Until idle timeout (configurable) | 24 hours (Pro) | | Startup claim | ~1s resume | Sub-90ms creation | Sub-second scheduling | Not published | Milliseconds | | SDK languages | Python, TypeScript | Python, TypeScript, Ruby, Go, Java | Python, TypeScript, Go | TypeScript only | TypeScript, Python | | GPU support | Not documented | H100, RTX PRO 6000 | T4 through B200 | Not documented | Not documented | | Pricing model | Base fee + per-second usage | Pure per-second pay-as-you-go | Per-second usage, tiered base | $5/mo base + per-10ms usage | Per-use metering, I/O wait excluded | ## How to Choose **By isolation requirements.** If your agent runs untrusted code from end users and you need the strongest possible isolation boundary, Vercel Sandbox (Firecracker microVMs with dedicated kernels) and Modal (gVisor with continuous isolation monitoring) both offer well-documented security models. Daytona's enterprise tier adds customer-managed compute for zero cross-tenant risk. **By run length and statefulness.** If your agents run for hours and need to carry state between steps, E2B's pause/resume/snapshot model is the most granular. Daytona offers unlimited persistence by design. Vercel Sandbox defaults to persistent sandboxes with automatic snapshotting. Cloudflare Sandbox is the most ephemeral of the group and requires explicit bucket mounts for durable state. **By existing cloud stack.** If you are already on Cloudflare (Workers, Durable Objects, R2), the Sandbox SDK keeps everything in one vendor and one billing relationship. If you deploy on Vercel, Vercel Sandbox integrates natively with your existing infrastructure and the eve agent framework. If you use Modal for serverless compute, their Sandbox API is a natural extension. E2B and Daytona are cloud-neutral and work from any backend. **By SDK and language needs.** Daytona offers the widest SDK coverage (five languages). If your agent framework is in Ruby, Go, or Java, Daytona is currently the only option with a first-party SDK. For TypeScript-first teams, all five providers have you covered. For Python-heavy ML and agent stacks, E2B, Daytona, and Modal all offer mature Python SDKs. **By GPU requirements.** If your agent needs GPU access inside the sandbox (for local model inference, RL training, or image generation), Modal and Daytona both offer GPU instances. The other three providers do not currently document GPU support for sandbox workloads. ## Frequently Asked Questions ### What is the difference between a sandbox and a regular container for AI agents? A standard Docker container shares the host kernel and relies on namespaces and cgroups for isolation. A sandbox for AI agents typically provides stronger isolation (dedicated kernel, microVM, or user-space kernel like gVisor), automatic lifecycle management (create, pause, resume, snapshot), and APIs designed for programmatic control from an agent orchestration layer. The key difference is that sandboxes are built to safely run untrusted, agent-generated code without risking the host infrastructure or other tenants ([Vercel Sandbox concepts](https://vercel.com/docs/sandbox/concepts), [Modal security](https://modal.com/docs/guide/security)). ### Can I self-host any of these sandbox providers? Daytona offers a bring-your-own-compute option at the enterprise tier where sandboxes run in your own cloud with no shared compute. Modal offers a self-hosted option for enterprise customers. E2B documents a BYOC (bring your own cloud) capability. Cloudflare Sandbox and Vercel Sandbox are managed services tied to their respective platforms and do not currently offer self-hosted options. Check each provider's enterprise documentation for current self-hosting details. ### How do these sandboxes handle secrets and credentials? Approaches vary. Cloudflare Sandbox documents a credential proxy pattern where the Worker injects secrets at request time so the sandbox itself never holds live API keys ([Cloudflare security](https://developers.cloudflare.com/sandbox/concepts/security/)). Vercel offers Vercel Connect for scoped, short-lived tokens to services like GitHub and Slack ([Vercel blog](https://vercel.com/blog/vercel-sandbox-is-now-generally-available)). E2B and Daytona support environment variables passed at sandbox creation. For any provider, the best practice is to avoid baking long-lived secrets into sandbox images and instead use a proxy or injection pattern. ### Do these providers integrate with popular agent frameworks? E2B documents the broadest set of agent framework integrations, including LangChain, LlamaIndex, CrewAI, Vercel AI SDK, and OpenAI Agents SDK ([E2B integrations](https://e2b.dev/docs/quickstart/connect-llms)). Daytona provides integration guides for LangChain and an MCP server for tool integration ([Daytona docs](https://www.daytona.io/docs)). Modal documents examples with LangGraph ([Modal docs](https://modal.com/docs)). Vercel Sandbox integrates natively with Vercel's eve framework and AI SDK. Cloudflare Sandbox integrates with Workers AI. Most providers can work with any agent framework through their SDK, even without a dedicated integration guide. ## Sources - [E2B Documentation](https://e2b.dev/docs) - [E2B Pricing](https://e2b.dev/pricing) - [E2B Persistence Docs](https://e2b.dev/docs/sandbox/persistence) - [E2B Template Docs](https://e2b.dev/docs/template/quickstart) - [E2B LLM Integrations](https://e2b.dev/docs/quickstart/connect-llms) - [Daytona Documentation](https://www.daytona.io/docs) - [Daytona Pricing](https://www.daytona.io/pricing) - [Daytona Homepage](https://www.daytona.io/) - [Modal Documentation](https://modal.com/docs) - [Modal Sandbox Guide](https://modal.com/docs/guide/sandbox) - [Modal Security](https://modal.com/docs/guide/security) - [Modal Pricing](https://modal.com/pricing) - [Modal Sandboxes Product Page](https://modal.com/products/sandboxes) - [Cloudflare Sandbox SDK Docs](https://developers.cloudflare.com/sandbox/) - [Cloudflare Sandbox Architecture](https://developers.cloudflare.com/sandbox/concepts/architecture/) - [Cloudflare Sandbox Security](https://developers.cloudflare.com/sandbox/concepts/security/) - [Cloudflare Sandbox Pricing](https://developers.cloudflare.com/sandbox/platform/pricing/) - [Vercel Sandbox Documentation](https://vercel.com/docs/sandbox) - [Vercel Sandbox Concepts](https://vercel.com/docs/sandbox/concepts) - [Vercel Sandbox Persistent Sandboxes](https://vercel.com/docs/sandbox/concepts/persistent-sandboxes) - [Vercel Sandbox Pricing](https://vercel.com/docs/sandbox/pricing) - [Vercel Sandbox GA Blog Post](https://vercel.com/blog/vercel-sandbox-is-now-generally-available)

Text-to-Speech APIs for Developers in 2026: What to Actually Use

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Provider | Documentation | |----------|---------------| | OpenAI TTS | [Text-to-Speech Guide](https://platform.openai.com/docs/guides/text-to-speech) | | OpenAI Pricing | [Platform Pricing](https://platform.openai.com/docs/pricing) | | ElevenLabs | [API Pricing](https://elevenlabs.io/pricing/api) | | xAI Grok TTS | [Voice Documentation](https://docs.x.ai/developers/model-capabilities/audio/voice) | | xAI Announcement | [Grok STT and TTS APIs](https://x.ai/news/grok-stt-and-tts-apis) | | Cartesia Sonic | [Cartesia Sonic](https://cartesia.ai/sonic/) | | Cartesia Pricing | [Pricing Page](https://cartesia.ai/pricing) | Picking a text-to-speech API is a positioning problem more than a quality problem. Most of the major options sound good now. What separates them is where they sit on the three-way tradeoff between quality, latency, and price, plus two policy questions that decide whether they fit your product at all: streaming and voice cloning. This is a fair, sourced look at the four APIs developers reach for most in 2026: OpenAI, ElevenLabs, xAI Grok, and Cartesia. Every pricing number below is from a primary source and linked. Where numbers churn, we point you at the page rather than freeze a figure that will drift. ## The three-way tradeoff There is no single best TTS API, only the best fit for your latency budget, your quality bar, and your per-character cost ceiling. A voice agent that has to respond in real time cares about time-to-first-audio above all. A batch narration pipeline for articles or podcasts cares about naturalness and price and barely notices latency. Read the comparison through your own workload, not a leaderboard. ## OpenAI OpenAI's current TTS model is `gpt-4o-mini-tts`, with the older `tts-1` and `tts-1-hd` still available as legacy options. The distinctive feature is steerability: alongside the text and voice, you pass an `instructions` field like "Speak in a cheerful and positive tone," which shifts delivery without a new voice. Streaming is supported, so you can start playing audio before the full clip is generated. See the [text-to-speech guide](https://platform.openai.com/docs/guides/text-to-speech). - **Voices:** a fixed set of preset voices (alloy, coral, and others). No custom voice cloning. - **Streaming:** yes, real-time audio output via streaming responses. - **Cloning policy:** none. OpenAI does not offer voice cloning here, which sidesteps consent and likeness questions entirely but limits brand-specific voices. - **Pricing:** published on the [OpenAI pricing page](https://platform.openai.com/docs/pricing). Confirm the current `gpt-4o-mini-tts` and legacy `tts-1` rates there, since OpenAI has been reshaping its audio lineup and posted numbers move. - **Best for:** teams already on OpenAI who want good-enough voices, tone steering, and one fewer vendor. OpenAI's [usage policy](https://platform.openai.com/docs/guides/text-to-speech) also asks you to disclose to end users that the voice is AI-generated. ## ElevenLabs ElevenLabs is the quality-and-cloning specialist, with a model lineup that lets you trade latency for richness. Per its [API pricing](https://elevenlabs.io/pricing/api): - **Flash / Turbo:** $0.05 per 1,000 characters, ultra-low latency around 75ms, up to a 40,000-character limit. This is the tier for real-time voice agents. - **Multilingual v2 / v3:** $0.10 per 1,000 characters, latency around 250-300ms, tuned for the most natural, expressive output. - **Streaming:** yes. - **Cloning policy:** instant voice cloning from a short sample and professional voice cloning are core features. That power comes with consent obligations. Read the current [ElevenLabs terms](https://elevenlabs.io/terms-of-service) before cloning any voice you do not own. - **Best for:** products where voice quality or a custom cloned voice is the point, and teams that want to dial latency up or down per use case with the same vendor. ## xAI Grok xAI shipped standalone [Grok Speech to Text and Text to Speech APIs](https://x.ai/news/grok-stt-and-tts-apis) built on the stack behind Grok Voice. The pitch is simple, predictable pricing. - **Pricing:** $15.00 per 1 million characters for TTS (roughly $0.015 per 1,000 characters), per xAI's [announcement](https://x.ai/news/grok-stt-and-tts-apis) and [voice docs](https://docs.x.ai/developers/model-capabilities/audio/voice). - **Voices:** 5 expressive voices, with Speech Tags for delivery control and telephony codecs for phone use cases. - **Latency:** sub-second, on the `/v1/tts` endpoint. - **Streaming:** yes, with a separate real-time `grok-voice-latest` speech-to-speech option billed at $3.00 per hour for conversational agents. - **Cloning policy:** the public TTS product ships with fixed expressive voices rather than open voice cloning. - **Best for:** developers who want flat, easy-to-forecast per-character pricing, telephony-ready output, and a single vendor for both transcription and speech. ## Cartesia Cartesia's [Sonic](https://cartesia.ai/sonic/) model competes on raw speed. It advertises sub-90ms latency and a roughly 40ms time-to-first-audio, natively multilingual across 40+ languages, with instant voice cloning from a short clip. - **Pricing:** credit-based tiers per the [Cartesia pricing page](https://cartesia.ai/pricing), from a free tier (20K credits/month) up through paid tiers ($5 for 100K credits/month with instant voice cloning, $49 for 1.25M credits/month with pro voice cloning, and higher). Credits map to generated audio, so model your real character volume against a tier. - **Streaming:** yes, with time-to-first-audio as the headline metric. - **Cloning policy:** instant voice cloning on paid tiers, professional cloning higher up. As with any cloning vendor, get consent for the source voice. - **Best for:** latency-critical, real-time voice applications where time-to-first-audio is the metric that makes or breaks the experience. ## How to choose - **Real-time voice agent:** start with ElevenLabs Flash/Turbo or Cartesia Sonic. Both are built for the sub-100ms band. Grok's sub-second TTS is a strong fit when you also want telephony codecs and flat pricing. - **Batch narration (articles, podcasts, courses):** ElevenLabs Multilingual for maximum naturalness, or Grok and OpenAI for predictable cost at volume where a few hundred milliseconds does not matter. - **You need a custom or cloned brand voice:** ElevenLabs or Cartesia. OpenAI and Grok ship fixed voices only. - **You want one fewer vendor:** OpenAI if you are already there, or Grok if you also want its STT. - **Predictable cost is the priority:** Grok's flat per-character rate is the easiest to forecast; ElevenLabs and Cartesia require modeling character or credit volume against tiers. Whatever you pick, prototype with your real content. Naturalness is subjective and workload-specific, and a 30-second test on your actual scripts tells you more than any spec sheet. ## Routing TTS: gateway or direct? If you already send chat traffic through an AI gateway like [Vercel AI Gateway](/blog/vercel-ai-gateway-guide-2026), a fair question is whether TTS should ride the same rails. In 2026 the answer is usually no. AI gateways today focus on text generation and embeddings, and their unified request shapes are built around chat completions, not audio streams. Text-to-speech providers each expose their own audio endpoints, streaming formats, and voice parameters, so you generally call the TTS provider directly. The practical pattern most teams land on: route text and reasoning through a gateway for one key, fallbacks, and spend visibility, and keep a thin direct client per TTS provider. That keeps your audio path close to the provider's streaming API, where the latency wins actually live, while your text stack stays consolidated. Abstract the TTS call behind a small internal interface so swapping providers later is a one-file change, not a refactor. ## FAQ ### Which TTS API has the lowest latency? ElevenLabs Flash/Turbo (around 75ms per its [API pricing](https://elevenlabs.io/pricing/api)) and Cartesia Sonic (sub-90ms, with roughly 40ms time-to-first-audio per [Cartesia](https://cartesia.ai/sonic/)) lead on latency. Grok TTS advertises sub-second latency on its [voice docs](https://docs.x.ai/developers/model-capabilities/audio/voice). ### Which options support voice cloning? ElevenLabs and Cartesia offer voice cloning, instant from a short clip and professional at higher tiers. OpenAI and Grok ship fixed preset voices without public cloning. Always get consent for the source voice and check each vendor's terms. ### What does TTS cost? Grok TTS is $15.00 per 1M characters ([xAI](https://x.ai/news/grok-stt-and-tts-apis)). ElevenLabs is $0.05 per 1K characters for Flash/Turbo and $0.10 per 1K for Multilingual ([ElevenLabs](https://elevenlabs.io/pricing/api)). Cartesia is credit-based from a free tier upward ([Cartesia](https://cartesia.ai/pricing)). Confirm OpenAI's current rates on its [pricing page](https://platform.openai.com/docs/pricing). ### Do these APIs support streaming? Yes. OpenAI, ElevenLabs, Grok, and Cartesia all support streaming audio so playback can start before the full clip is generated, which is what makes real-time voice agents feel responsive. ### Should I route TTS through an AI gateway? Usually not today. Gateways focus on text and embeddings, so call TTS providers directly and keep the audio path close to their streaming APIs. See the [Vercel AI Gateway guide](/blog/vercel-ai-gateway-guide-2026) for the text side. ## Sources - [OpenAI text-to-speech guide](https://platform.openai.com/docs/guides/text-to-speech) - [OpenAI pricing](https://platform.openai.com/docs/pricing) - [ElevenLabs API pricing](https://elevenlabs.io/pricing/api) - [xAI Grok STT and TTS announcement](https://x.ai/news/grok-stt-and-tts-apis) - [xAI Voice docs](https://docs.x.ai/developers/model-capabilities/audio/voice) - [Cartesia Sonic](https://cartesia.ai/sonic/) - [Cartesia pricing](https://cartesia.ai/pricing)

Box3D: Erin Catto Releases an Open Source 3D Physics Engine

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Erin Catto, the creator of Box2D, just released [Box3D](https://box2d.org/posts/2026/06/announcing-box3d/) - an open source 3D physics engine that extends Box2D's design philosophy into the third dimension. If you've built browser games in the 2010s, you probably used Box2D without knowing it. This release gives game developers a new option in the surprisingly thin field of open source 3D physics engines. ## What's In Box3D The engine is written in C17 with a clean C API. It includes: - Triangle mesh and height-field collision detection - Baked compound collision systems - Sub-stepping solver with continuous collision detection - Graph coloring for handling large simulation islands - Wide SIMD contact solver - Multi-threading hooks with optional internal scheduler - Large-world support using double-precision positioning - Cross-platform determinism with recording/replay capabilities That last point matters more than it sounds. Cross-platform determinism means the same simulation inputs produce identical outputs regardless of which platform runs the simulation. This enables replay systems, networked physics synchronization, and test reproducibility - features that are notoriously difficult to achieve with floating-point physics. The codebase blends Box2D algorithms with elements from Rubikon-Lite, Valve's physics engine from Half-Life: Alyx. According to the announcement, Dirk Gregorius at Valve developed optimizations in a new engine called Ragnarok that influenced Box3D's architecture. ## The Open Source 3D Physics Landscape Before Box3D, the open source 3D physics space was remarkably sparse. The HN discussion highlights the history: > "The ancient forefathers are ODE, Bullet and Newton Dynamics (all first released in the early 2000s), then nothing(?) for nearly two decades until Jolt in 2021 and now Box3D." Jolt (used in Horizon games) arrived in 2021 and quickly became a go-to choice. PhysX went open source in 2018 but carries NVIDIA baggage. Bullet remains widely used but shows its age. Rapier brought Rust to the party but has different design tradeoffs. Box3D enters this space with specific advantages: it's from a proven physics engine author, it has Valve production heritage, and it prioritizes determinism from the start. ## What HN Is Saying The [HN thread](https://news.ycombinator.com/item?id=48745445) (365+ points, 80+ comments) is notably positive, with several game developers chiming in. **On Box2D nostalgia:** > "Box2D was a foundation for a lot of interesting physics oriented indie games in my day. I wonder if the landscape is empty enough for a resurgence." The thread name-drops IncrediBots, Angry Birds, and dozens of Flash-era physics games that used Box2D under the hood. **On the determinism features:** > "I was looking for the same thing. There is a replay mechanism, so it seems to be deterministic. But with floating point physics, not across platforms. Though -ffast-math is unsupported according to the documentation, so maybe it is intended to be deterministic across platforms?" A commenter found the answer in the documentation: "Box3D is designed to be deterministic across thread counts and platforms." This is a significant engineering achievement for a physics engine. **On Valve's involvement:** > "On the Valve side, Rubikon continues to evolve and Dirk has developed optimizations (similar to those in Box3D) in a new engine called Ragnarok. Look for that in future Valve games." This triggered the predictable Half-Life 3 jokes, but also genuine curiosity about Valve's upcoming physics-heavy projects. One commenter mentioned a Valve game codenamed "HLX" that apparently uses extensive physics features. **From Glenn Fiedler (gafferongames):** > "Yeah this library is great. Use it!!!" Glenn Fiedler is one of the most respected voices in game networking and physics. He's using Box3D in a 1000-player space game, which is a meaningful endorsement for networked physics use cases. ## Current Users Beyond Fiedler's space game, Box3D already powers: - *The Legend of California* (Kintsugiyama Studios) - the primary development testbed - s&box (Facepunch Studios) - which notably ripped out Source 2's physics for Box3D - Esoterica engine The s&box move is particularly interesting. Facepunch explicitly chose Box3D over Valve's native Source 2 physics, suggesting the open source option has real production advantages. ## Getting Started Box3D follows the same build pattern as modern Box2D: ```bash git clone https://github.com/erincatto/box3d.git cd box3d cmake -B build cmake --build build ``` The API is documented in Doxygen headers, and sample code is included. The current release is alpha software targeting a v1.0, with planned improvements for character movement, ghost collision mitigation, and joint solver refinements. ## My Take The open source 3D physics space needed this. Not because existing options are bad - Jolt is excellent, Rapier is great for Rust projects, PhysX is comprehensive - but because more good options push the whole field forward. Box3D brings specific strengths: deterministic cross-platform physics (hard to find), production heritage from both Box2D and Valve, and an author who has been thinking about physics simulation for decades. The clean C API also matters - it's bindable to essentially any language ecosystem. For indie game developers evaluating physics engines in 2026, the realistic choices are now Jolt, Rapier (if you're in Rust), PhysX (if you want the full commercial package), or Box3D. Each has different tradeoffs. Box3D's bet is on simplicity, determinism, and the accumulated wisdom of someone who's been optimizing 2D physics simulations since 2006. If you're building something that needs networked physics or replay systems, the determinism guarantees make Box3D worth evaluating first. If you just need physics that works, any of the options will serve you well. ## Sources - [Box3D Announcement](https://box2d.org/posts/2026/06/announcing-box3d/) - [Box3D GitHub](https://github.com/erincatto/box3d) - [Box3D Documentation](https://box2d.org/documentation3d/) - [HN Discussion](https://news.ycombinator.com/item?id=48745445)

Claude Sonnet 5 vs Sonnet 4.6: Should You Upgrade?

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Anthropic shipped Claude Sonnet 5 on June 30, 2026, and made it the default model for Free and Pro. The pitch is simple: performance close to Opus 4.8 on agentic and coding work, at Sonnet prices. It is a strong upgrade, but there is one catch in the fine print that changes the cost math. Here is the builder decision. ## What shipped, and when Sonnet 5 (`claude-sonnet-5`) is available same-day across the Claude API, Claude Code, Amazon Bedrock, Google Vertex, and Microsoft Foundry. It is the default on Free and Pro and available on Max, Team, and Enterprise. Anthropic calls it "the most agentic Sonnet yet" - built to plan, use browsers and terminals, and run autonomously. Key specs: - **Context:** 1M tokens (default and max), output up to 128K (300K on the Batches API via a beta header) - **Modalities:** text and image input, text-only output - **Knowledge cutoff:** January 2026 - **Thinking:** adaptive thinking on by default; manual extended-thinking budgets and non-default sampling params now return a 400. You control depth with `effort` (defaults to high on the API and in Claude Code) ## The numbers that justify the upgrade From Anthropic's official system card (Sonnet 5 at adaptive thinking, max effort, 5-trial average): | Benchmark | Sonnet 5 | Sonnet 4.6 | GPT-5.5 | Gemini 3.5 Flash | |---|---|---|---|---| | SWE-bench Verified | 85.2% | - | - | - | | SWE-bench Pro | 63.2 | 58.1 | 58.6 | 55.1 | | Terminal-Bench 2.1 | 80.4 | 67.0 | 83.4 | 76.2 | | BrowseComp | 84.7 | 76.2 | 84.4 | - | | Humanity's Last Exam (with tools) | 57.4 | 46.8 | 52.2 | - | | OSWorld-Verified | 81.2 | 78.5 | 78.7 | 78.4 | | FrontierCode v1 | 38.8 | 15.1 | 25.5 | - | | GDPval-AA v2 (Elo) | 1618 | 1395 | 1509 | 1357 | The story is coding and agents. FrontierCode more than doubled over Sonnet 4.6 (15.1 to 38.8), SWE-bench Pro and BrowseComp both jumped, and it leads GPT-5.5 and Gemini 3.5 Flash on most of the agentic and knowledge benchmarks. Two spots where a competitor leads: Terminal-Bench (GPT-5.5 via Codex CLI) and AutomationBench (Gemini 3.5 Flash). ## The pricing pitch: near-Opus for less Sonnet 5 introductory pricing is $2 per 1M input and $10 per 1M output through August 31, 2026, then $3 / $15 after (the same per-token rate as Sonnet 4.6). For reference, Opus 4.8 is $5 / $25. So on tasks where Sonnet 5 lands close to Opus 4.8, you get comparable results for roughly half the output price. ## The catch every builder needs to see Sonnet 5 uses a new tokenizer that produces about 30 percent more tokens for the same text (Anthropic's own footnote gives a 1.0 to 1.35x range by content type). The per-token price is unchanged, but that means an equivalent request can cost slightly more than it did on Sonnet 4.6, and your `max_tokens` budgets may need re-checking. "Same per-token price" is not the same as "same per-task cost." Model this before you migrate a high-volume workload. ## Honest framing: it is a safety and agent release, not a frontier jump Anthropic's system card is refreshingly direct: overall performance is "comparable to Sonnet 4.6" and Sonnet 5 "does not advance our capability frontier" against Opus and Mythos-class models. The real gains are concentrated in agentic and coding tasks, plus it is the first Sonnet-tier model with real-time cyber safeguards on by default (and it is deliberately weak at cyber-offense by design). ## Should you upgrade? **Upgrade now if** you run coding agents, autonomous workflows, or browser and terminal tasks. The FrontierCode and SWE-bench gains are real, and near-Opus quality at Sonnet prices is a genuine cost win for agent-heavy products. **Hold or test first if** your workload is high-volume and cost-sensitive - the tokenizer inflation can quietly raise per-task cost, so measure on your own traffic before flipping the default. Migration itself is close to a drop-in: swap the model ID, remove manual thinking budgets and non-default sampling params (they now 400), and re-verify your `max_tokens` because of the tokenizer change. ## Frequently Asked Questions ### Is Claude Sonnet 5 better than Sonnet 4.6? Yes on agentic and coding tasks - it beats Sonnet 4.6 across Anthropic's benchmark suite, with FrontierCode more than doubling (15.1 to 38.8). Anthropic notes overall quality is otherwise comparable, so the biggest wins are concentrated in coding and agents rather than a blanket jump. ### How much does Claude Sonnet 5 cost? Introductory pricing is $2 per million input tokens and $10 per million output through August 31, 2026, then $3 / $15. That is the same per-token rate as Sonnet 4.6 and cheaper than Opus 4.8 ($5 / $25). ### What is the tokenizer catch with Sonnet 5? Sonnet 5 uses a new tokenizer that generates roughly 30 percent more tokens for the same text. The per-token price is unchanged, so an equivalent request can cost a bit more per task than on Sonnet 4.6. ### Is Sonnet 5 hard to migrate to? No. It is close to a drop-in: change the model ID, drop manual extended-thinking budgets and non-default sampling parameters (both now return 400), and re-check your max output token budgets because of the tokenizer change. ## Sources - Anthropic, [Introducing Claude Sonnet 5](https://www.anthropic.com/news/claude-sonnet-5) - Anthropic, [Claude Sonnet 5 System Card (PDF)](https://www-cdn.anthropic.com/9e6a1044980d8c4ed85669faf9c2a8342e2e9f1e/Claude%20Sonnet%205%20System%20Card.pdf) - Anthropic Docs, [What's new in Claude Sonnet 5](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5) - Anthropic Docs, [Models overview](https://platform.claude.com/docs/en/about-claude/models/overview) - TechCrunch, [Anthropic launches Claude Sonnet 5 as a cheaper way to run agents](https://techcrunch.com/2026/06/30/anthropic-launches-claude-sonnet-5-as-a-cheaper-way-to-run-agents/)

Cloudflare's x402 Monetization Gateway Brings Micropayments to the Edge

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Cloudflare just shipped something that could fundamentally change how developers monetize APIs and web content. The new [Monetization Gateway](https://blog.cloudflare.com/monetization-gateway/) brings native x402 protocol support to Cloudflare's edge network, enabling micropayments for any resource - web pages, datasets, APIs, and MCP tools - all processed at Cloudflare's 330+ edge locations before traffic ever hits your origin server. ## What Is x402? The x402 protocol operationalizes the HTTP 402 "Payment Required" status code that has been reserved since 1992 but never had a standard implementation. Here's the flow: 1. Client requests a gated resource 2. Server responds with `402 Payment Required` containing pricing details 3. Client pays via blockchain (stablecoins like USDC or Open USD) 4. Client resubmits request with payment proof 5. Facilitator verifies the payment and delivers the resource The key insight is that this happens inside ordinary HTTP requests and responses - no redirect to a checkout page, no separate payment API, no account creation. As Cloudflare puts it: transactions settle in under one second with negligible fees, supporting micropayments down to fractions of a cent. ## Why This Matters for Developers The primary use case Cloudflare is targeting is agent-to-service payments. As the announcement notes, an AI agent can make thousands of micropayments without friction, while asking a person to approve each payment would be impossibly burdensome. Consider the economics: if your API gets scraped constantly by LLM training runs and agent frameworks, you currently have two options - block the traffic or absorb the cost. x402 offers a third path: charge for it. Example pricing structures Cloudflare describes: - Per-call search charges (e.g., $0.001 per query) - Per-MB upload endpoint fees - Outcome-based support escalation payments ($0.99 per resolution) - Variable pricing based on task complexity (e.g., image generation up to $2) You can configure rules via the Cloudflare dashboard, API, or Terraform. The Gateway also integrates with Web Bot Auth for agent identity verification. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48746914) (126+ comments, 200+ points) reveals a mix of optimism and concern. **On the payment mechanism:** > "How will the end user pay? Will we all have stablecoin wallets installed?" The general consensus is that this is primarily agent-to-service infrastructure. Individual users would likely fund agent wallets through their existing LLM provider accounts - the payments get abstracted away. As one commenter noted: "From your POV they'll just get more expensive." **On Cloudflare's position:** Several comments express discomfort with Cloudflare's expanding role as internet gatekeeper. One user wrote: > "I am not a fan of the growing trend that Cloudflare is the gatekeeper of the internet." Others counter that the x402 protocol itself is open - the Linux Foundation now hosts the [x402 Foundation](https://github.com/x402-foundation/x402) with Coinbase's contribution of the original protocol. Anyone can implement it. **On the micropayment dream:** The thread has healthy skepticism about whether micropayments will work this time: > "Micropayments have been tried so many times before, but they all relied on user opt-in and never reached any sort of critical mass. Someone of Cloudflare's scale could actually pull it off." The counterpoint is that AI agents change the equation - they can handle the payment friction that humans find intolerable. **On bot vs. human differentiation:** A practical question from the thread: > "Am I understanding this correct in that you can basically automate monetizing your web/api content to everyone or just agents? Because I would be very much in support of charging agents per request, but I would want to still offer humans a free experience." Cloudflare says they want to offer a range of options - charging everyone, charging unverified bots, or simply charging users who exceed rate limits. A Cloudflare PM in the thread confirmed they're avoiding dependency on any particular detection mechanism. ## The Technical Reality A few important caveats from the announcement and discussion: **Stablecoins only (for now).** The system uses USDC and Open USD on networks like Base and Solana. No credit card support. This is both a feature (programmable, low fees) and a limitation (requires crypto infrastructure). **Waitlist-only.** Cloudflare is accepting signups for early access. This is not generally available yet. **Privacy implications.** Some commenters raised concerns about Cloudflare "knowing their customer" for every page view. The x402 spec itself doesn't require identity, but implementations might. ## My Take This is infrastructure for a world where AI agents are significant traffic generators. Today that means LLM crawlers training on your content. Tomorrow it might mean autonomous agents making API calls on behalf of users who never see the underlying requests. The x402 protocol is genuinely interesting - it's the right level of abstraction for agent commerce. But Cloudflare building it into their edge network specifically is what makes it practical. Most developers don't want to implement payment verification, stablecoin handling, and fraud detection. They want to add a rule that says "charge $0.001 for this endpoint." Whether this becomes the new AdSense or another failed micropayment experiment depends on adoption curves we can't predict yet. But the infrastructure is now real, and it's sitting at the edge of one of the internet's largest CDNs. If you're running APIs that get hammered by AI traffic, the [Monetization Gateway waitlist](https://blog.cloudflare.com/monetization-gateway/) is worth watching. ## Sources - [Cloudflare Monetization Gateway Announcement](https://blog.cloudflare.com/monetization-gateway/) - [x402 Foundation GitHub](https://github.com/x402-foundation/x402) - [HN Discussion](https://news.ycombinator.com/item?id=48746914) - [x402 Protocol InfoQ Coverage](https://www.infoq.com/news/2026/01/x402-agentic-http-payments/)

Codex Record & Replay: Turn Screen Recordings Into Reusable Automation Skills

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Watch: Codex Record & Replay in 9 Minutes](https://www.youtube.com/watch?v=7f4n6h1gzdA) | The full walkthrough on the DevDigest channel | | [OpenAI Codex](https://openai.com/codex) | Official product page for Codex | ## What This Video Covers **Codex: Record & Replay** explains a new OpenAI Codex feature. Record and Replay lets you record a recurring computer task and replay it later as a reusable automation skill. Instead of describing a repetitive workflow in a prompt every time, you record it once and hand Codex something it can run again on demand. This post is a companion to the video above. Watch the nine-minute walkthrough for the live demo, then use the links here to place the feature in context. ## The Idea in One Line Turn a screen recording into a reusable skill. That is the whole pitch. The tasks that eat time are rarely hard, they are just recurring: the same sequence of steps, done again and again. Record and Replay captures that sequence once so it can be replayed without you driving it manually each time. ## Why It Matters Two shifts make this interesting: - **Recording beats re-prompting.** Demonstrating a workflow once is often faster and more precise than writing out every step in text. The recording becomes the spec. - **Skills are reusable.** A recorded task is not a one-off run. It becomes an automation skill you can trigger later, which is the same direction as [Codex automations for recurring engineering work](/blog/codex-automations-recurring-engineering-work). If you have followed the broader trend of [agent replays](/blog/agent-replays-with-tracetrail), the theme is the same: capture what happened so it can be inspected, trusted, and re-run. ## Where It Fits in Codex Record and Replay is one piece of a fast-moving product. For the full picture, the [OpenAI Codex guide](/blog/openai-codex-guide) covers the fundamentals, and the [June 2026 Codex changelog](/blog/codex-changelog-june-2026) tracks what has shipped recently. If you are weighing tools, [Codex vs Claude Code (June 2026)](/blog/codex-vs-claude-code-june-2026) compares the two head to head. ## Getting Started The workflow the video demonstrates is straightforward: identify a task you repeat, record yourself doing it once, and save the replay as a skill. Start with something small and low-risk so you can see exactly what gets captured before you point it at anything important. Watch the full **Codex: Record & Replay** walkthrough above, then record your first repetitive task and let Codex handle the next run.

Coordinating an Agent Fleet for a Day: The Operating Model That Actually Held

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

We rebuilt and replatformed this site in a single day by running a fleet of AI agents in parallel. The [design story lives in its own post](/blog/devdigest-redesign-2026): why we retired the old cream-and-pink system for a hard-edged neutral contract, and what we chose. This post is about the other half, the part that is harder to see and much easier to get wrong: the orchestration. How do you point dozens of agent runs at one codebase in one day and end up with a coherent site instead of a pile of conflicting commits? The short version is that the model is not clever. It is boring, and boring is the point. Coordination fails in exciting ways and succeeds in dull ones. What follows is the operating model that held, the guardrails that made it safe, and the specific failure modes we hit that day with the fix each one produced. None of it is theoretical. All of it cost us something to learn. If you want the framework-level vocabulary first - fan-out, pipeline, hierarchical delegation, blackboard - read the [definitive guide to coordinating multiple AI agents](/blog/how-to-coordinate-multiple-ai-agents). This post assumes you already know the patterns and want the field notes. ## The operating model that worked Seven rules did most of the work. Each one exists because the alternative bit us at some point, either that day or before it. ### 1. Single-owner file scopes The first rule is the one everything else rests on: never two writers per file. Every agent gets a scope, and scopes do not overlap at the file level. One agent owns the homepage. Another owns the blog templates. A third owns the global tokens. When two agents both need to touch a shared file, that is a signal to serialize them, not to let them both edit and merge later. This sounds obvious and is constantly violated in practice, because the natural decomposition of a task ("redesign the site") does not respect file boundaries ("both the nav and the footer import the same tokens file"). The discipline is to decompose along ownership lines, not feature lines. If a change spans a shared file, one agent lands the shared change first, and the others build on top of it. ### 2. Serialized dependency installs Package management is a shared-file problem with extra teeth. Two agents running `pnpm add` at the same time race on the lockfile and `package.json`, and the loser's install silently vanishes or corrupts the tree. So one agent owns `package.json` at a time. Dependency installs are serialized through a single owner, full stop. Component-library installs are the same: one agent runs the install, adapts the component to the design contract, commits, and only then does downstream work start. ### 3. A verification gate on every handoff This is the load-bearing rule. The orchestrator runs the same gate on every single handoff, not at the end of the day. The gate is: typecheck, style check, build, and one more step that catches the failure the other three miss. That extra step is the committed-tree-in-isolated-worktree trick. Agents leave in-progress files in the working tree. A commit can pass every local check while importing a file that was never staged, because the file exists on disk but not in the commit. Local tooling sees the file; the CI runner, which only has the commit, does not. So the gate checks out the actual commit into a throwaway worktree and typechecks that, in isolation from the working tree. If the commit imports something it did not include, this catches it before it reaches the deploy pipeline. Nothing else does. The principle generalizes past our specific stack: verify the artifact you are about to ship, not the environment you built it in. The working directory lies. The commit does not. ### 4. Draft-first for anything externally visible Anything that leaves the building starts as a draft for review. Content, public copy, anything a reader or a customer would see. The agent produces it, a human or a review pass approves it, and only then does it ship. This is not about distrust of the model. It is that the cost of a bad externally-visible change is asymmetric, and the cost of a review pass is small. When the downside is public and hard to reverse, you pay the small tax every time. ### 5. Standing constraints broadcast to all agents Some rules are not task-specific; they apply to every agent regardless of scope. Banned topics. The design contract - square corners, hairline borders, no gradients, no em dashes. These are broadcast to every agent as standing constraints, and they are codified in the project instructions so they are inherited, not remembered. A constraint you have to remember is a constraint you will eventually break. A constraint the codebase and the brief both enforce stays enforced. This is what let agents working on different pages produce work that looked like it came from one hand. ### 6. Fail-closed defaults for anything that spends money Any action that spends money or touches a live external system defaults to off. If an agent is unsure whether it is authorized to make a paid call, provision infrastructure, or hit a production endpoint, the default is to stop and ask, not to proceed and apologize. Fail-closed is the only safe default for irreversible or costly actions, because the failure mode of asking is a few seconds of latency and the failure mode of proceeding is a bill or an outage. ### 7. Continuous shipping, never batch a day's work The last rule is a rhythm: verify, commit, push, per increment. Never let a day of parallel work pile up into one giant unreviewed merge. Each increment goes through the gate and ships on its own. Batching feels efficient and is a trap: it hides which change broke what, it makes the verification gate slower and scarier, and it turns a small revert into a large one. Small, continuous, verified increments keep the blast radius of any single mistake tiny. ## The failure modes we hit, honestly Rules read as clean in a list. They were not clean to learn. Here are the actual failures from the day and the guardrail each one produced. This is the part worth reading twice, because the failures are more transferable than the successes. **Agents assuming unshipped sibling exports.** An agent imported a function it expected a sibling agent to have exported, because the plan said that function would exist. But the sibling had not shipped it yet, or had named it differently. The code looked correct in isolation and broke at integration. Guardrail: agents build against what is committed, not against what is promised. If an export does not exist in the tree yet, you do not import it; you serialize behind the agent that owns it. **Mid-write files breaking global CSS.** An agent was partway through editing the global stylesheet when a downstream build picked up the half-written file, and the broken CSS cascaded across every page at once. A shared global file in a mid-write state is a site-wide outage waiting to happen. Guardrail: shared global files get a single owner who lands complete, verified changes, and downstream work does not build against a global file that is mid-edit. **Silent idles with no reports.** An agent went quiet. Not failed, not finished, just idle, and it produced no report, so the orchestrator did not know whether it was working, stuck, or done. Silence is ambiguous and ambiguity stalls the whole fleet. Guardrail: every agent reports on handoff. A run that goes silent without a report is treated as stalled and gets checked, not assumed to be making progress. **Env files clobbered by a tool.** A tool overwrote an environment file, wiping configuration that other work depended on. Guardrail: treat env and other shared config files as owned, single-writer surfaces exactly like source files, and never let a tool rewrite them as a side effect without that write going through the same ownership and verification path as any other change. **Deploy pipeline broken by a package-manager default.** The deploy failed on a package-manager default we did not know had changed: the newer major version hard-blocks dependency build scripts unless they are explicitly approved, in a config key that moved between versions. Installs that worked locally failed in CI. Guardrail: test dependency changes with a clean, frozen-lockfile install that mirrors CI, not just the warm local install, because the warm local environment hides exactly the failures the cold CI environment will hit. The through-line across every one of these: the failure was never the model being dumb. It was two pieces of work making incompatible assumptions about shared state - a file, an export, an env var, a lockfile, a build default - and the fix was always the same shape. Make the shared thing owned, verify the real artifact, and never assume a sibling's promise is a sibling's commit. ## A starter checklist If you are about to point a fleet of agents at your own codebase, start here. This is the shortest version of what took us a day of mistakes to internalize. 1. Assign single-owner file scopes. No file has two writers. Decompose along ownership lines, not feature lines. 2. Serialize dependency installs through one owner. One agent holds `package.json` at a time. 3. Run a verification gate on every handoff: typecheck, style check, build. 4. Add the isolated-worktree check to that gate. Verify the committed tree, not the working directory, so a commit that imports an unstaged file gets caught before CI. 5. Draft-first everything externally visible. Human or review-pass approval before anything public ships. 6. Broadcast standing constraints to all agents, and codify them in project instructions so they are inherited, not remembered. 7. Default to fail-closed on anything that spends money or touches production. Unsure means stop and ask. 8. Ship continuously: verify, commit, push per increment. Never batch a day of work into one merge. 9. Require a report on every handoff. Treat silence as stalled, not as progress. 10. Test dependency and config changes against a clean, CI-like install before pushing, not just the warm local environment. None of these are exotic. That is the lesson. Coordinating a fleet of agents is mostly the same discipline as coordinating a team of people: clear ownership, honest verification, small reversible increments, and safe defaults when the stakes are high. The agents move faster, so the cost of skipping the discipline arrives faster too. Get the operating model right and the speed is a gift. Skip it and the speed just multiplies your surface area for silent breakage. If you want the next layer down, the [orchestration patterns guide](/blog/how-to-coordinate-multiple-ai-agents) covers the mechanics of each coordination shape, and [managing a fleet of Claude agents](/blog/managing-a-fleet-of-claude-agents) goes deeper on the day-to-day of running one. To go from patterns to a durable skill set, follow a [learning path](/paths) or browse the [agents library](/library/agents). To author and share your own subagents over the same endpoint your fleet already reads, see [Agent Studio](/blog/agent-studio-one-endpoint). ## Frequently Asked Questions ### How do you stop parallel agents from overwriting each other's work? Single-owner file scopes. Every agent gets a scope, and no two scopes touch the same file. Decompose the work along ownership lines rather than feature lines, because features naturally span shared files while ownership does not. When a change genuinely needs a shared file, one agent lands that change first and the others build on top of it. Dependency installs and env files are the highest-risk shared surfaces, so they always go through a single owner. ### What is the verification gate you run on every handoff? Four checks: a typecheck, a style check for banned patterns, a full build, and an isolated-worktree check. That last one checks out the actual commit into a throwaway worktree and typechecks it in isolation from the working directory. It catches the case where a commit imports a file that exists on disk but was never staged, which passes every local check and then fails in CI. The rule is to verify the artifact you are shipping, not the environment you built it in. ### Do you need a framework to coordinate agents like this? No. The operating model here is about discipline, not tooling: ownership boundaries, a verification gate, draft-first review, fail-closed defaults, and continuous shipping. Those apply regardless of whether you use a framework or raw orchestration. Frameworks help once you need explicit loops or shared state, which the [coordination guide](/blog/how-to-coordinate-multiple-ai-agents) covers, but the guardrails that keep a fleet safe are process, not library choice.

Cursor Composer 2.5 Developer Guide 2026

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Cursor Composer 2.5 Announcement | [cursor.com/blog/composer-2-5](https://cursor.com/blog/composer-2-5) | | Cursor Pricing | [cursor.com/pricing](https://cursor.com/pricing) | | Cursor Documentation | [docs.cursor.com](https://docs.cursor.com) | | Kimi K2.5 Base Model | [Moonshot AI](https://www.moonshot.cn/) | | SWE-bench Multilingual | [swebench.com](https://www.swebench.com/) | Cursor shipped Composer 2.5 on May 18, 2026 - just two months after Composer 2. The headline: it matches Claude Opus 4.7 and GPT-5.5 on coding benchmarks at roughly one tenth the cost per token. But the story underneath is more interesting than the benchmark numbers suggest. **Last updated:** July 1, 2026 This guide covers what Composer 2.5 actually is, how to set it up, when to use it versus external models, and the training approach that made the performance jump possible. --- ## What Composer 2.5 Actually Is Composer 2.5 is Cursor's own agentic coding model, purpose-built to plan, edit files, run terminal commands, and verify its own work inside the Cursor editor. It is not a general-purpose chatbot. The training and evaluation targets are software engineering trajectories, not single-shot Q&A. Like its predecessor, Composer 2.5 is based on Moonshot's open-weights Kimi K2.5. The architecture is a mixture-of-experts transformer with 1.04 trillion parameters total and 32 billion active parameters per token. It supports up to 200,000 tokens of context with native function calling, reasoning, and context caching. Inside Cursor, it can: - Read files across your entire project - Edit code in multiple files simultaneously - Search the project semantically - Run terminal commands - Check errors and iterate - Keep working through a task until completion The key improvement over Composer 2 is sustained effort. Composer 2.5 maintains focus across long tasks, follows complex instructions more reliably, and calibrates how much work a request actually needs instead of over- or under-doing it. --- ## How to Set It Up Composer 2.5 ships in Cursor 3.4 and later (3.5 is the current release as of May 20, 2026). **Step 1:** Open the Composer panel or chat sidebar with `Cmd+I` on macOS or `Ctrl+I` on Windows and Linux. **Step 2:** Click the model picker in the top-right corner of the Composer panel. **Step 3:** Select Composer 2.5 from the dropdown. For interactive coding sessions, leave the default Fast variant on. For background agents and Cloud Agent runs, switch to the Standard variant in **Settings > Models > Composer 2.5**. The Fast variant prioritizes low latency for real-time interactions. The Standard variant prioritizes quality for autonomous tasks where you are not waiting on each response. --- ## Pricing Breakdown Composer 2.5 ships in two variants: | Variant | Input | Cached | Output | |---------|-------|--------|--------| | **Standard** | $0.50/MTok | $0.20/MTok | $2.50/MTok | | **Fast** | $3.00/MTok | $0.50/MTok | $15.00/MTok | For context, Claude Opus 4.8 is $5/$25 per MTok and GPT-5.5 runs between $10-$15/$30-$45 per MTok depending on variant. Composer 2.5 is meaningfully cheaper at the Standard tier. The practical impact: Cursor reports that Composer 2.5 completes CursorBench tasks at an average cost of under $1, while Opus 4.7 and GPT-5.5 run between $3 and $11 per task for comparable results. For Cursor subscribers, both variants draw from your usage pool. Pro users get it as part of their $20/month. Teams Standard and Teams Premium get it with their split usage pools (first-party models including Composer 2.5 get their own allocation as of July 1, 2026). --- ## Benchmark Performance Here is where Composer 2.5 sits against the other frontier models as of mid-2026: | Benchmark | Composer 2.5 | Claude Opus 4.7 | GPT-5.5 | |-----------|--------------|-----------------|---------| | **SWE-bench Multilingual** | 79.8% | 80.1% | 78.4% | | **CursorBench v3.1** | 63.2% | 64.8% | 62.7% | | **Terminal-Bench 2.0** | 69.5% | 70.2% | 82.7% | The numbers tell a clear story: **Where Composer 2.5 competes:** On multi-file coding tasks and repository-level refactors, Composer 2.5 matches Opus 4.7 and GPT-5.5 within noise. The benchmark differences are 1-2 percentage points - not enough to change your choice based on raw capability. **Where Composer 2.5 falls behind:** Terminal-Bench 2.0 measures shell and terminal workflows - compiling code, setting up servers, system administration. GPT-5.5 leads by roughly 13 points. If your work is heavy in terminal trajectories, GPT-5.5 is the better tool. **Cost efficiency:** At one tenth the token cost, Composer 2.5 is the default choice for agentic coding inside Cursor unless your task specifically benefits from Opus or GPT-5.5. --- ## How They Trained It Cursor's training approach is worth understanding because it explains why Composer 2.5 improved so much over Composer 2 with the same base model. **25x more synthetic tasks.** Composer 2.5 was trained on 25 times as many synthetic tasks as Composer 2. Cursor developed harder synthetic problems dynamically throughout the training run. **Feature deletion training.** One method: the agent is given a working codebase with a full set of tests, asked to delete specific features while keeping the codebase functional, and then tasked with reimplementing those features. The tests serve as a verifiable reward signal - either the tests pass or they do not. **Targeted textual feedback.** Instead of one reward signal at the end of a task, Cursor writes a short hint describing the fix they want, drops that hint into the agent's local context, and uses on-policy distillation to incorporate the behavior back into the model. This provides denser credit assignment than end-of-task rewards. **Agentic monitoring.** The training pipeline includes monitors that detect and prevent reward hacking behaviors before they compound. The infrastructure side: Cursor uses a sharded Muon optimizer with distributed orthogonalization and dual-mesh HSDP. They report 0.2s optimizer step time on the 1T parameter model - fast enough to iterate quickly on training runs. --- ## When to Use Each Model Pick your model based on task type, not brand loyalty: **Use Composer 2.5 when:** - You are working inside Cursor (it is the native option) - Cost matters and you are doing high-volume agentic work - The task is multi-file editing, codebase-wide refactors, or CI fixers - You want sustained effort across a long session **Use Claude Opus 4.8 when:** - The task requires deep architectural reasoning across very long contexts - You need the strongest single-shot reliability for one-shot generation - The work involves nuanced judgment rather than raw throughput - You are working outside Cursor and need an API **Use GPT-5.5 when:** - The work is heavy in shell and terminal trajectories - You need fast cloud execution with OpenAI's infrastructure - You are using Codex as your primary agentic tool **Use Fable 5 when:** - You need the absolute highest capability for a single complex task - The cost is justified by task completion rate improvements - You have API access (through July 7, Fable 5 is temporarily included in claude.ai subscriptions) --- ## Practical Workflow Patterns **Long refactors.** Composer 2.5 excels at multi-file refactors that require sustained attention. Start with a clear instruction ("refactor all API handlers to use the new error handling pattern") and let it work through the codebase. **Test-driven development.** Write failing tests first, then ask Composer 2.5 to implement the features. The verification loop gives it clear success criteria. **CI fixers.** Point Composer 2.5 at a failing CI run and let it iterate. The combination of file editing and terminal access means it can run the tests locally, see the failures, and fix them. **Code review assistance.** Use Composer 2.5 to review your own changes before committing. It can catch issues you missed and suggest improvements. **Batch operations.** If you have 20 similar changes to make across a codebase, describe the pattern once and let Composer 2.5 apply it everywhere. --- ## Limitations to Know **Not a replacement for external models in all cases.** Terminal-Bench scores show GPT-5.5 is still better for shell-heavy work. For architecture decisions requiring the deepest reasoning, Opus or Fable 5 may justify the cost premium. **Cursor-native.** Composer 2.5 is built for Cursor. If you are using VS Code, Neovim, or another editor, you need to use the external model APIs directly. **200K context window.** Large but not unlimited. For massive codebases, you still need to be selective about what context you load. **Model-specific behaviors.** Composer 2.5 is trained for agentic coding patterns. For general chat, creative writing, or non-coding tasks, general-purpose models may perform better. --- ## FAQ ### What is Cursor Composer 2.5? Cursor Composer 2.5 is Cursor's own agentic coding model, released in May 2026. It is based on Moonshot's Kimi K2.5 with a mixture-of-experts architecture (1T parameters, 32B active per token). It is purpose-built for multi-file editing, terminal commands, and sustained agentic coding inside the Cursor editor. ### How much does Composer 2.5 cost? Standard variant: $0.50 input, $0.20 cached, $2.50 output per million tokens. Fast variant: $3.00 input, $0.50 cached, $15.00 output per million tokens. For Cursor subscribers, usage draws from your plan's allocation. ### How does Composer 2.5 compare to Claude Opus 4.7? On SWE-bench Multilingual and CursorBench, Composer 2.5 matches Opus 4.7 within 1-2 percentage points. Composer 2.5 costs roughly one tenth as much per token. Opus 4.7 may have an edge on tasks requiring the deepest architectural reasoning. ### How does Composer 2.5 compare to GPT-5.5? On coding benchmarks, the two are comparable. GPT-5.5 leads significantly on Terminal-Bench 2.0 (82.7% vs 69.5%) - for shell-heavy workflows, GPT-5.5 is the better choice. Composer 2.5 wins on cost. ### When should I use Composer 2.5 vs external models? Use Composer 2.5 as your default for agentic coding inside Cursor when cost matters. Reach for Opus 4.8 for deep reasoning tasks, GPT-5.5 for terminal-heavy work, and Fable 5 when the task justifies the premium price. ### What is the context window for Composer 2.5? Up to 200,000 tokens with native function calling, reasoning, and context caching. ### Does Composer 2.5 work outside Cursor? No. Composer 2.5 is integrated into Cursor and is not available as a standalone API. For external usage, you need Claude, GPT, or another API-accessible model. ### What training improvements made Composer 2.5 better than Composer 2? 25x more synthetic training tasks, feature deletion training with test-based rewards, targeted textual feedback for denser credit assignment, and agentic monitoring to prevent reward hacking. --- ## Sources - [Cursor Composer 2.5 Announcement](https://cursor.com/blog/composer-2-5) - May 18, 2026 - [Cursor Pricing](https://cursor.com/pricing) - verified July 1, 2026 - [Lushbinary Composer 2.5 Guide](https://lushbinary.com/blog/cursor-composer-2-5-developer-guide-benchmarks-pricing/) - May 2026 - [DevOps.com Composer 2.5 Coverage](https://devops.com/cursors-composer-2-5-brings-smarter-more-reliable-ai-coding-agents/) - May 2026 - [Emergent AI Substack Guide](https://emergingai.substack.com/p/cursor-composer-25-the-practical) - May 2026 - [Memeburn Benchmark Comparison](https://memeburn.com/cursor-composer-2-5-officially-launches/) - May 2026

We Redesigned Developers Digest: The Applied Story of Rebuilding a 1000-Page Site in a Day

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Developers Digest looks different today. We retired the old design system, the playful one built on cream surfaces, pink accents, rounded pills, and offset-layer cards, and replaced it with a hard-edged neutral contract that is closer in spirit to Vercel or Linear than to a Gumroad landing page. This post is the applied version of the story: why we changed direction, the exact constraints we committed to, how we actually built it by coordinating AI agents in parallel, and what comes next. We write about coordinating AI agents. This redesign was a chance to do it on our own site, at real scale, in public. ## Why we changed the design direction The old system was warm and friendly. It worked when the site was small. But Developers Digest is now more than a thousand pages: blog posts, tutorials, guides, a tools directory, courses, comparison surfaces, and programmatic SEO pages. At that scale, a decorative system starts to fight the content. Three problems pushed the change: 1. **Content density.** Comparison tables, pricing grids, and long technical posts want a calm, dense canvas. Rounded pills and cream cards add visual weight to every row. On a page with fifty data points, that weight becomes noise. 2. **Signal over decoration.** Our readers are developers evaluating tools and workflows. They want to scan, compare, and decide. A design that foregrounds itself gets in the way of that job. We wanted the interface to disappear and the information to lead. 3. **Seriousness as an AI-dev authority.** The goal is to be a durable, trusted reference for applied AI development. The visual language should read as an engineering reference, not a consumer marketing site. None of that means the old system was wrong. It means the site outgrew it. ## The constraints we chose A design system is only as good as the constraints it enforces. We picked a small set and applied them globally, with no exceptions per page. - **Square corners everywhere.** The global stylesheet forces `border-radius: 0` and sets the radius token to zero. No component can quietly reintroduce curves. Hard edges are the single most recognizable signal of the new look. - **Hairline borders.** Structure comes from thin `border-black/10` lines, not shadows or filled cards. Sections are defined by rules, not by weight. - **One accent at most.** Default to black. Most pages use zero accent color and let typography and spacing carry the hierarchy. When an accent appears, it is one hue on one element, never a rainbow of states. - **Mono uppercase eyebrows.** Section labels use a monospaced, uppercase, wide-tracked eyebrow. It is the typographic tell of the system and does a lot of hierarchy work for very little ink. - **No gradients, anywhere.** No gradient backgrounds, text, borders, or badges. Solid neutrals only. Gradients are the fastest way to make an interface look generic, and banning them entirely removed a whole category of decisions. The rules live in the project instructions so that every future change, human or agent, inherits them. That is the point: a constraint you have to remember is a constraint you will eventually break. A constraint the codebase enforces stays enforced. ## How it was actually built Here is the honest part. This was not a solo weekend of hand-editing files. It was a coordinated run of parallel AI agents, which is exactly the discipline this site is about. The stack is Next.js 16 with the App Router and Tailwind. The component layer adapts a set of Magic UI components, but every one of them was rewritten to the new contract: square, neutral, no gradients. We did not drop in a template and call it a redesign. We took useful primitives, like grid patterns, marquees, and bento layouts, and stripped them back to the hard-edged system. The work was decomposed into independent slices and handed to separate agents running at the same time. A rough shape of the fan-out: - One track rebuilt the global tokens and base layout so every downstream page would inherit the new contract. - Separate tracks took the homepage, the blog surfaces, the tools and comparison pages, the member dashboard, and the standalone product pages. - Content tracks drafted and refreshed articles in parallel with the design work. - A verification pass ran style checks, type checks, and route checks across the whole site so nothing regressed silently. Coordinating agents this way is not free. The hard parts are the same hard parts as coordinating people: clear ownership boundaries so two agents do not fight over the same file, a shared contract so independent work still composes into one coherent system, and automated checks so you can trust the output without reading every diff by hand. The enforced design constraints did double duty here. Because square corners, hairline borders, and the no-gradient rule were codified, agents working on different pages produced work that looked like it came from one hand. The verification loop mattered most. A machine-readable style check greps the codebase for banned patterns, em dashes among them, and the type and route checks confirm the site still builds and every page still responds. Those checks are what make parallel agent work safe to ship. Without them, fanning out just multiplies the surface area for silent breakage. Rebuilding a thousand-page site in a day is only possible because the pages are not a thousand unique snowflakes. They are a handful of layouts driven by data and content. Fix the layouts and the contract, and the long tail follows automatically. The leverage is in the system, not in the page count. ## What is next The redesign is the foundation, not the finish line. The next wave is member features: - **Credits.** A universal credit balance that works across our tools, so the interactive surfaces on the site can do real work for signed-in members. - **In-app AI chat.** A chat assistant, currently in beta, that lives inside the member dashboard and answers questions grounded in our content and tools. Both are early. We are shipping them in public and will write about what works and what does not, the same way we did here. If you want the running list of what shipped, the [changelog](/changelog) has every entry with dates. And if you are trying to coordinate agents on your own codebase, the constraint-and-verification pattern above is the part worth copying: codify the rules, enforce them with checks, then let independent agents move fast inside the guardrails. ## Frequently Asked Questions ### Why move away from the old cream-and-pink design? The site grew past a thousand pages of dense, comparison-heavy content. A warm, decorative system added visual weight to every element, which worked at small scale but started competing with the information at large scale. The hard-edged neutral system prioritizes scanability and reads as a serious engineering reference. ### What is the new design system based on? It is a hard-edged neutral contract inspired by tools like Vercel and Linear: white surfaces, hairline `border-black/10` borders, square corners enforced globally, monospaced uppercase eyebrows, at most one accent color, and no gradients anywhere. It is built with Next.js 16 and Tailwind, using adapted Magic UI components rewritten to fit the contract. ### How was a thousand-page site rebuilt in a single day? The work was decomposed into independent slices, such as the homepage, blog, tools, dashboard, and content, and handed to separate AI agents running in parallel. Codified design constraints kept their output consistent, and automated style, type, and route checks made the parallel work safe to ship. The leverage came from a small number of shared layouts driving many pages, not from editing each page by hand.

Orchestrating a Fleet of Agents with Fable 5

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

_Part 1 of the Fable 5 agent fleets series. Start with [Fable 5 Is Back: The Anthropic Model the Government Switched Off](/blog/fable-5-returns-what-changed) for the model background, then read Part 2, [The Economics of Agent Fleets](/blog/agent-fleet-economics-fable-5-sonnet-5), for the cost math._ Most multi-agent setups fail in the same place. Not the workers - the manager. You fan out ten agents, they each do a reasonable job on their slice, and then the results do not fit together because nothing held the whole picture. The orchestrator ran out of context, lost the plan, or never had a strong enough model to keep the threads straight. Fable 5 changes the shape of that problem. With a 1M token context window, always-on adaptive thinking, and a set of API primitives built for long-horizon work, the orchestrator can now hold the entire project in one head. That single fact reshapes how you design a fleet. This post is the applied version: the manager-model pattern, why orchestrator quality dominates fleet output, and where each Fable 5 primitive actually fits. ## Why orchestrator quality dominates fleet output In a fleet, the worker agents are interchangeable and cheap. The orchestrator is not. It decides what to build, how to split it, which worker gets which slice, whether the returned work is correct, and what to do next. Every one of those decisions compounds. A worker that produces a mediocre function costs you one function. An orchestrator that mis-plans the architecture costs you the whole run. For the full catalog of coordination patterns a fleet leans on, see [how to coordinate multiple AI agents](/blog/how-to-coordinate-multiple-ai-agents). This is why the manager-model pattern puts your strongest model at the top. Anthropic positions Fable 5 as its most capable widely released model, above Opus 4.8, and frames the pitch simply: the longer and more complex the task, the bigger its lead (see the [launch post](https://www.anthropic.com/news/claude-fable-5-mythos-5)). Orchestration is exactly that kind of task. It is long-horizon, it accumulates state, and a small early error propagates through everything downstream. If you are going to spend on one expensive model in your fleet, spend it on the one making the decisions. ## Context as coordination memory The reason orchestration used to be hard is that coordination state grows fast. The plan, the task list, what each worker returned, which pieces passed verification, what still needs doing - that is a lot of tokens, and it grows with every delegation round. Older orchestrators had to compress or drop that history, and every compression is a chance to lose the thread. Fable 5's 1M token context turns coordination memory from a scarce resource into an abundant one. You can keep the whole repo, the original spec, the running task ledger, and the transcript of every worker result in the orchestrator's context at once. The manager does not have to reconstruct what happened three steps ago from a summary. It reads it directly. A few practical consequences: - **The repo fits in the manager's head.** For most codebases, you can put the relevant tree and key files directly in context, so the orchestrator plans against the actual code rather than a description of it. - **The task ledger is durable.** Instead of a fragile external state machine, the running plan and its status can live in the context itself, updated as work completes. - **Worker outputs stay reviewable.** When a worker returns a diff, the orchestrator still has the original requirements in context to check it against. For work that outlives a single context window, Fable 5 also exposes a file-based memory tool plus context editing and compaction primitives. Anthropic reports that file-based memory tripled long-task gains versus Opus 4.8 on its internal evaluations (vendor-reported, from the [launch post](https://www.anthropic.com/news/claude-fable-5-mythos-5)). For an orchestrator, that memory is where the coordination ledger lives when the run is long enough that even 1M tokens is not enough - the manager writes plan state to files and reads it back across compaction boundaries. ## The delegation patterns Once the orchestrator can hold the whole picture, the useful patterns are straightforward. Three cover most fleets. ### Fan-out The manager decomposes a task into independent slices and dispatches them to workers in parallel. This is the classic case: refactor twelve modules, write tests for eight files, draft ten content pieces. The orchestrator's job is the decomposition (making the slices genuinely independent so they do not conflict) and the reassembly (merging results into a coherent whole). The 1M context matters here because the manager has to hold every returned slice at once to integrate them without contradictions. ### Pipeline Workers run in sequence, each consuming the previous stage's output: research, then draft, then critique, then revise. The orchestrator owns the handoffs and decides whether each stage's output is good enough to advance. Pipelines are where a weak orchestrator quietly fails - it passes bad output downstream because it never really checked. A strong manager with the full spec in context can gate each stage. ### Verify loops The pattern that separates a real fleet from a fancy prompt chain. After a worker returns, the orchestrator verifies the result against the original requirements and either accepts it, sends it back with specific feedback, or re-scopes the task. This is where orchestrator quality pays off most directly, because verification is a judgment task and judgment is what the frontier model is for. A worker can write the code. Deciding whether the code is actually correct, complete, and consistent with everything else is the manager's job. In practice you compose these. A realistic build fans out an initial batch of independent work, runs each result through a verify loop, then pipelines the verified pieces into an integration stage. The orchestrator is the only component that sees all of it. ## Where the effort parameter fits Fable 5's adaptive thinking is always on - you cannot disable it, you tune its depth with the `effort` parameter (see the [model docs](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5)). In an orchestration context, `effort` is a dial you set per decision type, not once for the whole run. - **High effort for planning and verification.** Decomposing a task well, catching a subtle inconsistency between two workers' outputs, deciding whether a returned diff is actually correct - these are the decisions where deeper thinking earns its cost. This is the orchestrator's core loop, and it is worth the tokens. - **Low effort for mechanical steps.** Dispatching an already-planned task, formatting a result, updating the ledger with a status - these do not need deep reasoning. Turning `effort` down on the routine steps keeps the orchestrator affordable without dulling its judgment where judgment matters. The mental model: spend thinking depth where a wrong answer is expensive and cheap out where it is not. Because Fable 5 also supports task budgets (in beta) and programmatic tool calling, the orchestrator can dispatch and coordinate worker calls as part of its own reasoning loop rather than round-tripping every decision back to your application code. That keeps the manager's view of the fleet continuous. ## What this does not fix The manager-model pattern raises the ceiling on fleet quality. It does not remove the parts you still have to engineer. You still have to make fan-out slices genuinely independent, or the merge conflicts. You still have to write verification criteria the orchestrator can actually check against, because a verify loop with vague criteria just launders bad work. And you still have to handle Fable 5's refusal behavior: its safety classifier can return `stop_reason: "refusal"` as a normal 200 response, and with the post-return classifier producing more false positives on benign coding, an orchestrator that ignores refusals will treat a blocked step as a silent success. Build the fallback to Opus 4.8 into the orchestrator loop from day one. We cover that behavior in more depth in [the returns post](/blog/fable-5-returns-what-changed). The shift is real, though. When your manager can hold the whole project in one context and reason deeply about every coordination decision, the fleet stops failing at the top. The workers were rarely the problem. The manager was. ## Frequently Asked Questions ### Why use Fable 5 as the orchestrator instead of the workers? Because orchestration decisions compound and worker output does not. The manager decides the plan, the delegation, and the verification, and a small early error there propagates through the whole run. Fable 5 is Anthropic's most capable widely released model and its lead grows with task length and complexity, which is exactly the orchestrator's job profile. Workers do bounded, scoped tasks where a cheaper model is usually enough. ### How does the 1M context window change multi-agent design? It turns coordination memory from a scarce resource into an abundant one. The orchestrator can keep the repo, the original spec, the running task ledger, and every worker's returned output in context at once, so it plans and verifies against the real state instead of a lossy summary. For runs that outlive a single window, the file-based memory tool plus context editing and compaction carry the ledger across boundaries. ### What is the effort parameter and how should an orchestrator use it? Fable 5's adaptive thinking is always on and cannot be disabled; `effort` tunes how deep it thinks. In a fleet, set it per decision type: high effort for planning and verification, where a wrong answer is expensive, and low effort for mechanical steps like dispatching a pre-planned task or updating the ledger. It is a per-decision dial, not a single run-wide setting. ### Do I still need to handle refusals in an orchestrator? Yes. Fable 5's safety classifier can return `stop_reason: "refusal"` as a normal 200, not an error, and the post-return classifier produces more false positives on benign coding. An orchestrator that only checks for HTTP errors will read a refused step as a silent success and pass broken state downstream. Wire a fallback to Opus 4.8 into the orchestrator loop from the start. ## Sources - Anthropic, [Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) (launch, vendor-reported benchmarks and memory claims) - Anthropic, [Redeploying Fable 5](https://www.anthropic.com/news/redeploying-fable-5) - Anthropic Docs, [Introducing Claude Fable 5 and Claude Mythos 5](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5) - Developers Digest, [Fable 5 Is Back: The Anthropic Model the Government Switched Off](/blog/fable-5-returns-what-changed) - Developers Digest, [The Economics of Agent Fleets: Fable 5 Orchestrators, Sonnet 5 Workers](/blog/agent-fleet-economics-fable-5-sonnet-5)

Running Fable 5 Agent Fleets in Production: The Operations Guide

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Part 2 of the Fable 5 agent fleets series. Part 1, [Fable 5 Is Back: The Anthropic Model the Government Switched Off](/blog/fable-5-returns-what-changed), covered what the model is and how it returned. Part 3, [Fable 5 vs Opus 4.8: Which Should Orchestrate Your Agents?](/blog/fable-5-vs-opus-4-8-orchestrator), is the model-selection decision. This post is about everything between "the model works" and "the fleet runs in production" - the operational surface that most launch write-ups skip. Writing the agent loop is the part everyone does (if you are still designing that layer, start with [how to coordinate multiple AI agents](/blog/how-to-coordinate-multiple-ai-agents)). The part that decides whether your fleet survives a quarter is the operations layer around it: compliance constraints on which model can even run, alerting on classifier behavior, cost dials, observability, and a fallback design that assumes the frontier model can disappear. Fable 5 makes each of these sharper than a normal model rollout, because of how it shipped and how it came back. ## The 30-day retention requirement is a fleet-wide constraint, not a footnote Fable 5 requires 30-day data retention. It is not available to zero-data-retention (ZDR) organizations. This is not a preference you tune - it is a hard availability gate, and it has a specific consequence for fleet design. If your organization runs under a ZDR agreement, Fable 5 is simply off the table for every agent in the fleet. Your workers must run on Opus 4.8 or Sonnet - models with no such restriction. There is no partial mode where the orchestrator uses Fable 5 and the ZDR boundary holds; the request either goes to an API that retains data for 30 days or it does not. Practical implications for operators: - **Confirm your retention posture before you architect the fleet.** If you are ZDR, design entirely around Opus 4.8 and Sonnet. Do not build a Fable 5 orchestrator you cannot legally run. - **Segment by data class.** If only part of your workload can tolerate 30-day retention, you may run Fable 5 on that segment and keep ZDR-bound work on Opus 4.8. That is two model routes, two audit trails, and a routing rule that must be enforced in code, not convention. - **Document the boundary.** Compliance reviewers will ask why one model path retains data and another does not. Have the retention requirement written down and mapped to specific agent roles. The takeaway: retention is an input to your architecture diagram, decided before the first agent runs, not a setting you flip later. ## Classifier false positives are an operational metric On its return, Fable 5 ships with a new safety classifier that blocks the specific reported jailbreak technique in more than 99 percent of cases. The stated tradeoff is more false positives on benign coding and debugging. For a single-shot chat app that is an annoyance. For a fleet running thousands of agent turns, it is a metric you have to watch. When the classifier refuses, Fable 5 returns `stop_reason: "refusal"` as a normal 200 response, not an HTTP error. A fleet that only alerts on 4xx and 5xx codes will treat a wave of refusals as a wave of successful-but-empty completions. Silent degradation is worse than a loud failure, because your agents keep "succeeding" while producing nothing. Treat refusal rate as a first-class operational signal: - **Emit a metric on every `refusal` stop reason.** Tag it by agent role and task type so you can see which workloads trip the classifier. - **Alert on refusal-rate spikes.** A sudden climb usually means either a classifier update on Anthropic's side or a change in your prompts that pushed benign requests into blocked territory. Both are things you want to know within minutes, not at the end of a billing cycle. - **Track the fallback rate alongside it.** Every refusal should be handled by a fallback (see below). Refusal rate and fallback success rate together tell you whether the safety net is holding. If your refusal rate is climbing and your fallback path is quietly absorbing it, your fleet is still working but is no longer running on the model you think it is. That is exactly the kind of drift observability exists to catch. ## Effort is the fleet's cost and quality dial Fable 5 has adaptive thinking always on. You cannot turn it off. You control depth with the `effort` parameter. For a fleet operator, `effort` is the single most direct lever between spend and output quality, and it should be set per agent role, not globally. A reasonable pattern: - **Low effort for routing, triage, and classification agents.** These make fast, cheap decisions and hand off. Deep thinking here mostly burns output tokens. - **Higher effort for the agents doing the genuinely hard reasoning** - long-horizon planning, multi-step migrations, complex synthesis. This is where Fable 5's edge shows up and where the tokens are worth it. - **Tune against real traces, not guesses.** Set an effort level, run a representative batch, and look at both quality and token spend before you lock it in. The right level is workload-specific. Because thinking is always on and raw chain-of-thought is never returned, you cannot inspect the reasoning to decide whether effort is set right. You judge it by outputs and cost. That makes disciplined measurement more important, not less. ## Observability essentials for a Fable 5 fleet You cannot operate what you cannot see. A Fable 5 fleet needs, at minimum, visibility into the following. - **Per-agent token spend.** Input and output tokens broken out by agent role and task. Output at $50 per 1M is where cost concentrates, so watch output tokens especially. - **Per-task budgets.** Fable 5 exposes task budgets as a beta capability. Use them to cap spend on individual long-running tasks so a single runaway agent cannot quietly consume the day's budget. A budget that halts a task is a controlled failure; an unbounded loop is not. - **Refusal and fallback rates.** Covered above. These are the health signals unique to running a classifier-gated frontier model in a fleet. - **Output truncation at 128K.** Fable 5 caps output at 128K tokens per request. Long-horizon agents that generate large artifacts can hit this ceiling and return truncated results that look complete. Instrument for responses that stop at the limit and design your agents to chunk or checkpoint work rather than emit one enormous completion. - **Latency and long-running request behavior.** Deep-thinking, high-effort requests take longer. Fleet schedulers and timeouts have to accommodate that, or you will kill useful work mid-thought. None of this is exotic, but all of it has to exist before you scale past a handful of agents. A fleet without per-agent cost and refusal visibility is a fleet you are operating blind. ## Availability risk is a design principle, not an afterthought Here is the lesson the June episode taught for free. Fable 5 launched on June 9, 2026, and on June 12 a US government export-control directive forced Anthropic to suspend it for every user. It did not come back until the end of the month. A frontier model, at the top of the stack, went dark overnight for reasons that had nothing to do with your code, your contract, or your usage. For a fleet operator the conclusion is blunt: model-agnostic fallback wiring is a design principle, not an optimization you add later. Assume the model your fleet depends on can vanish, and build so the fleet degrades instead of dying. Concretely: - **Route through an abstraction, never call the model directly from agent logic.** Every agent should ask a routing layer for "the orchestrator model," not hardcode `claude-fable-5`. Swapping the underlying model should be one config change. - **Wire Opus 4.8 as the standing fallback.** It is already the model Fable 5 falls back to on refusal, and it has no retention restriction. A well-built Opus 4.8 path is a prerequisite for running Fable 5 anyway, so you are not doing extra work - you are doing the work in the right order. - **Handle refusals as a first-class control-flow branch.** Anthropic supports retrying refusals via a server-side `fallbacks` parameter, SDK middleware, or your own logic. You are not billed if the model refuses before producing output. Build the fallback branch on day one; do not treat it as an edge case. - **Rehearse the switch.** Periodically run the fleet on the fallback model to confirm it actually works. A fallback you have never exercised is a hope, not a plan. The teams that were hurt least by the June suspension were the ones whose fleets already treated model choice as a swappable input. That is the entire design lesson: build for substitution before you need it. ## The pre-production checklist Before you point a fleet at Fable 5 in production, confirm: - [ ] Retention posture is known; if ZDR, the fleet is built on Opus 4.8 or Sonnet instead - [ ] Every agent calls a model-routing abstraction, never a hardcoded model id - [ ] Opus 4.8 is wired as the standing fallback and has been tested end to end - [ ] Refusal (`stop_reason: "refusal"`) is handled as a control-flow branch, not an error - [ ] Refusal rate and fallback rate are emitted as metrics with alerts on spikes - [ ] `effort` is set per agent role and validated against real traces - [ ] Per-agent token spend is visible, with output tokens tracked closely - [ ] Task budgets (beta) cap spend on long-running tasks - [ ] Truncation at the 128K output ceiling is instrumented and agents checkpoint long work - [ ] Timeouts accommodate high-effort, long-running requests If all ten hold, you have an operations layer, not just an agent loop. That is the difference between a demo and a fleet. Continue to Part 3, [Fable 5 vs Opus 4.8: Which Should Orchestrate Your Agents?](/blog/fable-5-vs-opus-4-8-orchestrator), for the model-selection decision that sits underneath all of this. ## Frequently Asked Questions ### Can I run a Fable 5 fleet under zero-data-retention? No. Fable 5 requires 30-day data retention and is not available to zero-data-retention organizations. A ZDR fleet must run its agents on Opus 4.8 or Sonnet, which carry no such restriction. ### How do I detect when Fable 5 refuses a request in a fleet? Fable 5 returns `stop_reason: "refusal"` as a normal 200 response, not an HTTP error. Instrument your fleet to emit a metric on every refusal stop reason, tagged by agent role, and alert on refusal-rate spikes. A fleet that only watches HTTP status codes will miss refusals entirely. ### What should I use as the fallback model for a Fable 5 fleet? Opus 4.8. It is already the model Fable 5 falls back to on refusal, it has no retention restriction, and building a working Opus 4.8 path is a prerequisite for running Fable 5 safely. Wire it as the standing fallback and rehearse the switch periodically. ### How does the effort parameter affect fleet costs? Adaptive thinking is always on in Fable 5 and cannot be disabled; you control its depth with the `effort` parameter. Lower effort on routing and triage agents to save output tokens, and reserve higher effort for genuinely long-horizon reasoning. Tune the level per agent role against real traces, since output tokens at $50 per 1M are where spend concentrates. ## Sources - Anthropic, [Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) - Anthropic, [Redeploying Fable 5](https://www.anthropic.com/news/redeploying-fable-5) - Anthropic Docs, [Introducing Claude Fable 5 and Claude Mythos 5](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5)

Fable 5 Is Back: The Anthropic Model the Government Switched Off

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Claude Fable 5 Announcement | [anthropic.com/news/claude-fable-5](https://www.anthropic.com/news/claude-fable-5) | | Fable 5 System Card | [anthropic.com/research/claude-fable-5-system-card](https://www.anthropic.com/research/claude-fable-5-system-card) | | Claude Models Documentation | [docs.anthropic.com/en/docs/about-claude/models](https://docs.anthropic.com/en/docs/about-claude/models) | | Anthropic API Reference | [docs.anthropic.com/en/api](https://docs.anthropic.com/en/api) | | Anthropic Pricing | [anthropic.com/pricing](https://www.anthropic.com/pricing) | Most model launches are a benchmark table and a price. Fable 5 got a benchmark table, a price, and a three week government suspension. As of today, July 1, 2026, it is back and available globally again. Here is the applied version of the story: what Fable 5 is, what changed on the return, and whether you should build on it. ## The three weeks that made Fable 5 famous Anthropic shipped Fable 5 on June 9, 2026 as its most capable widely released model. Three days later, on June 12, the US government issued an export-control directive citing national security and barring access by any foreign national. Because Anthropic could not verify user nationality in real time, it suspended the model for every user, not just a subset (its other models kept running). The trigger, per Anthropic, was a researcher report of a narrow jailbreak that got Fable 5 to identify software vulnerabilities and, in one case, produce exploit-demonstration code. Anthropic argued the technique was not universal and that lesser models could do similar defensive-security work. On June 26 the government approved a limited redeployment; on June 30 the restrictions were lifted; and today Fable 5 returns on the Claude API, Claude apps, and Claude Code. The one change that matters technically: a new safety classifier now blocks the specific reported technique in more than 99 percent of cases, at the cost of more false positives on benign coding and debugging. Blocked requests fall back to Opus 4.8. ## What Fable 5 actually is Fable 5 is Anthropic's "Mythos-class" model made safe for general use, positioned above Opus 4.8. The pitch: the longer and more complex the task, the bigger its lead. It shipped as a twin release - Fable 5 (`claude-fable-5`, public, with cybersecurity safety classifiers) and Mythos 5 (`claude-mythos-5`, the same underlying model with classifiers lifted, limited to vetted cyberdefense partners). ## The specs that matter for builders - **Context:** 1M tokens, with output up to 128K tokens per request - **Pricing:** $10 per 1M input, $50 per 1M output. Anthropic describes this as less than half the price of the earlier Claude Mythos Preview, but it still sits above the Opus 4.8 tier ($5 / $25) - **Thinking:** adaptive thinking is always on. You cannot disable it; you tune depth with the `effort` parameter - **Data:** requires 30 day retention. It is not available to zero-data-retention organizations - **Modalities:** text plus high-resolution vision input ## The one API behavior every integration must handle This is the part almost no one is writing about, and it is the part that will actually break your app if you ignore it. When Fable 5's safety classifier refuses a request, it returns `stop_reason: "refusal"` as a normal 200 response, not an error. If your integration only handles HTTP errors, a refusal will look like a successful but empty or truncated completion. Anthropic supports retrying refusals via a server-side `fallbacks` parameter, SDK middleware, or your own fallback logic, and you are not billed if the model refuses before producing output. With the post-return classifier increasing benign false positives on coding and debugging, this fallback path is not an edge case you can defer. Build it in on day one, with Opus 4.8 as the fallback target. ## What it is good at Anthropic and its launch partners report the strongest results in long-horizon, agentic work - which is exactly the lane it should win. Reported highlights (these are Anthropic and partner claims, not independently reproduced benchmarks): a codebase-wide migration across a 50M line Ruby codebase in about a day at Stripe, state-of-the-art scores on Cognition's FrontierCode and Cursor's CursorBench, new vision records including rebuilding a web app from screenshots, and outsized gains from file-based memory on long-running tasks. Treat the specific numbers as vendor-reported until the system card benchmarks are independently confirmed. The directional claim - that Fable 5's edge grows with task length and complexity - is consistent across sources. ## Should you use Fable 5 or stick with Opus 4.8? **Reach for Fable 5 when:** you are running long-horizon agentic work (multi-step migrations, deep research, [agent loops](/blog/how-to-coordinate-multiple-ai-agents)), you can absorb the premium price, and your integration handles refusals and fallbacks cleanly. **Stay on Opus 4.8 when:** you are cost-sensitive, you need zero-data-retention, or you want fewer false-positive refusals on routine coding. Opus 4.8 is also the model Fable 5 falls back to, so a well-built Opus integration is a prerequisite anyway. The headline is that Anthropic's most powerful model is back - but for most teams the real decision is not "is it powerful," it is "does my agent handle its refusal behavior and its price." Answer those two questions first. ## Frequently Asked Questions ### Is Fable 5 available again? Yes. Anthropic began redeploying Fable 5 globally on July 1, 2026 across the Claude API, Claude apps, and Claude Code, after a suspension that ran from June 12 to June 30. ### How much does Fable 5 cost? $10 per million input tokens and $50 per million output tokens, with a 1M token context window and up to 128K tokens of output per request. ### What is the difference between Fable 5 and Mythos 5? They are the same underlying model. Fable 5 (`claude-fable-5`) is the public version with cybersecurity safety classifiers on. Mythos 5 (`claude-mythos-5`) has those classifiers lifted and is limited to vetted cyberdefense partners. ### Why was Fable 5 suspended? A US government export-control directive on June 12, 2026 barred access by foreign nationals on national-security grounds, following a report of a jailbreak involving vulnerability analysis. Anthropic could not verify nationality in real time, so it suspended the model for all users until the restrictions were lifted. ## Sources - Anthropic, [Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) (launch) - Anthropic, [Statement on the US government directive to suspend access](https://www.anthropic.com/news/fable-mythos-access) - Anthropic, [Redeploying Fable 5](https://www.anthropic.com/news/redeploying-fable-5) - Anthropic Docs, [Introducing Claude Fable 5 and Claude Mythos 5](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5) - TechCrunch, [Trump drops restrictions on Anthropic's Mythos and Fable models](https://techcrunch.com/2026/06/30/trump-drops-restrictions-on-anthropics-mythos-and-fable-models/)

Running Fable 5 Agents on Vercel's eve Framework

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Two things shipped in 2026 that are better together than apart. Vercel's [eve](https://vercel.com/blog/introducing-eve) turns the repetitive plumbing of a production agent - durable sessions, a sandbox, approvals, subagents, evals - into a folder of files. Fable 5, Anthropic's most capable widely released model, is the reasoning engine you want driving a long, multi-step run. This post is the practical version: how eve's primitives pair with Fable 5's long-horizon strengths, a concrete architecture, honest costs, and the one refusal behavior you have to handle before you ship. | Official Sources | | |---|---| | [Introducing eve - Vercel blog](https://vercel.com/blog/introducing-eve) | Launch, architecture, use cases | | [eve documentation - Vercel docs](https://vercel.com/docs/eve) | Agent structure, tools, sessions | | [Vercel Sandbox is now GA - Vercel blog](https://vercel.com/blog/vercel-sandbox-is-now-generally-available) | The execution layer for agents | | [Introducing Claude Fable 5 - Anthropic docs](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5) | Model card, API surface, pricing | ## Why pair eve with Fable 5 specifically eve's whole pitch is that the plumbing should not be your code. As Vercel puts it in the [launch post](https://vercel.com/blog/introducing-eve), "agents today are where the web was before frameworks, with everyone hand-rolling the same plumbing and nothing carrying over to the next one." You define an agent as files, eve compiles it into an app on [Vercel Functions](https://vercel.com/docs/functions), and durability, sandboxing, and approvals come wired in. That framing matters more for a strong model than a weak one. The reason is where each model spends its lead: Anthropic positions Fable 5 so that the longer and more complex the task, the bigger its advantage. A model that can hold a 1M-token context and keep reasoning across dozens of tool calls is exactly the model that most needs durable sessions, a real sandbox, and a subagent story - because it will actually attempt runs long enough to hit crashes, redeploys, and timeouts. eve supplies that operational spine. Fable 5 supplies the reasoning. Neither is trying to be the other. ## The primitives you are actually composing eve is filesystem-first. You define an agent under an `agent/` directory and eve discovers the files, per the [eve docs](https://vercel.com/docs/eve): ``` my-agent/ └── agent/ ├── agent.ts # Model and runtime config ├── instructions.md # System prompt ├── tools/ # Typed functions, one tool per file ├── skills/ # On-demand procedures loaded when relevant ├── channels/ # Message integrations └── schedules/ # Cron jobs ``` The pieces that carry the Fable 5 stack: - **Model config via AI Gateway.** `agent.ts` names a model string that resolves through Vercel's [AI Gateway](https://vercel.com/docs/ai-gateway), so eve is model-agnostic. You point it at an Anthropic model by editing one line. - **Durable sessions.** Sessions checkpoint each step and survive crashes, cold starts, and deploys, backed by [Vercel Workflow](https://vercel.com/docs/workflows). A five-step run that dies at step three resumes instead of restarting. - **Sandboxed compute.** Agent-generated code runs isolated from your app runtime in [Vercel Sandbox](https://vercel.com/docs/sandbox), which went [generally available on January 30, 2026](https://vercel.com/blog/vercel-sandbox-is-now-generally-available) as, in Vercel's words, the execution layer for agents. - **Human-in-the-loop approvals.** A high-stakes tool call can require manual authorization before it proceeds. - **Subagents.** A parent agent delegates to child agents with isolated contexts, keeping the parent's context window clean. - **Evals.** Scored test suites verify behavior locally or in CI. ## A practical architecture: eve agent, Fable 5 orchestrator, Sandbox for code The shape that gets the most out of both tools is a three-layer split. **Layer 1 - the eve agent (the app).** This is your `agent/` folder. It owns the session lifecycle, the tool surface, the approval gates, and the channels the agent talks over. It is the deployable unit on Vercel Functions. **Layer 2 - Fable 5 as the orchestrator.** Set the top-level agent's model to Fable 5 and let it plan the run, decide which tools and subagents to invoke, and reason across the long context. Because eve resolves models through the gateway, this is a one-line config. The [eve docs](https://vercel.com/docs/eve) show `agent.ts` in this shape: ```ts import { defineAgent } from 'eve'; // Model resolved through Vercel AI Gateway. // Illustrative; use the exact gateway model id from your dashboard. export default defineAgent({ model: 'anthropic/claude-fable-5', }); ``` Fable 5's adaptive thinking is always on; you tune depth with the `effort` parameter rather than toggling reasoning on and off. For an orchestrator that decomposes a big task and delegates, a higher effort on the parent and cheaper models on the leaf subagents is the natural cost shape. **Layer 3 - Vercel Sandbox for code execution.** When the agent needs to write and run code - a data transform, a migration script, a generated test - that executes in the sandbox, not your app runtime. eve wires a sandboxed tool through [Vercel Sandbox](https://vercel.com/docs/sandbox) so a model that is genuinely writing and executing code cannot reach into your application. Each tool is one file in `agent/tools/`, following the [documented](https://vercel.com/docs/eve) `defineTool` shape: ```ts import { defineTool } from 'eve/tools'; import { z } from 'zod'; // Illustrative tool shape - adapt to the current eve API. export default defineTool({ description: 'Run a short Python script in an isolated sandbox.', inputSchema: z.object({ code: z.string(), }), async execute(input) { // Delegate execution to Vercel Sandbox; return stdout/stderr. // ... return { ok: true }; }, }); ``` The division of labor is clean: eve owns durability and isolation, Fable 5 owns the plan, and the sandbox owns anything the model tries to run. ## Handling refusals inside an eve agent This is the part that will silently break the stack if you ignore it. Fable 5 ships with a cybersecurity safety classifier, and when it refuses a request it returns `stop_reason: "refusal"` as a normal 200 response, not an HTTP error, per Anthropic's [model documentation](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5). If your agent only handles HTTP errors, a refusal looks like a successful but empty completion, and the run stalls with no obvious cause. Two things make this a day-one concern rather than an edge case. First, the post-return safety classifier that let Fable 5 redeploy globally on July 1, 2026 trades more benign false positives on coding and debugging for tighter safety, so a code-writing agent will hit refusals more than you expect. Second, Anthropic supports a server-side `fallbacks` parameter and documents Opus 4.8 as the fallback target, and you are not billed when the model refuses before producing output. In eve terms, treat this as a tool-and-orchestrator concern: have the orchestrator recognize a `refusal` stop reason and route the step to a fallback model (Opus 4.8) rather than surfacing an empty result to the session. Because eve sessions are durable, the retried step slots back into the same run. We covered the refusal-handling pattern for multi-agent setups in more depth in [handling Fable 5 refusals across agent fleets](/blog/handling-fable-5-refusals-agent-fleets). ## Honest costs There are two meters running, and they bill differently. **The model.** Fable 5 is $10 per 1M input tokens and $50 per 1M output tokens, per the [model card](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5). That sits above the Opus 4.8 tier ($5 / $25), so an orchestrator that reasons over a long context and emits large outputs is the expensive part of the run. The lever you have is the `effort` parameter and the subagent split: keep Fable 5 on the planning and reasoning, push mechanical leaf work to cheaper models through the same gateway. **The compute.** Vercel Sandbox is billed for the compute an agent actually uses while running code, not a flat idle fee, and it scales to zero when nothing is executing. For the current dimensions and numbers, price it against your own workload from the [Vercel Sandbox pricing and docs](https://vercel.com/docs/sandbox) rather than a headline rate, because a code-heavy agent and a mostly-reasoning agent land in very different places. We compared the sandbox options builders actually choose between in [where should your AI agent run code](/blog/ai-agent-code-sandbox-comparison-2026). The honest summary: the model tokens are usually the dominant cost for a reasoning-led agent, and the sandbox is the variable you control by how much code the agent runs. Neither has a free tier you should design around. ## Who this stack fits Reach for eve plus Fable 5 when three things are true. You are already on Vercel or comfortable deploying there, since eve deploys natively to Vercel today with other platforms described as coming soon. Your agent runs long, multi-step tasks where a strong reasoning model earns its price - migrations, research-and-synthesis, multi-tool operational work - rather than a single classify-or-extract call a cheaper model handles fine. And you want the operational concerns (durability, isolation, approvals, subagents, evals) handled by the framework instead of your own code. If your agent is a short, high-volume, single-shot call, Fable 5 is overkill and eve's durability machinery is more than you need. If you are multi-cloud and cannot commit to Vercel's deployment story yet, treat eve's platform caveat seriously. But for a builder who wants a long-horizon agent in production without hand-rolling the spine, eve gives you the folder and Fable 5 gives you the reasoning, and the two compose cleanly. ## Frequently Asked Questions ### Can eve run Anthropic models like Fable 5? Yes. eve resolves its model string through Vercel's [AI Gateway](https://vercel.com/docs/ai-gateway), which is model-agnostic, so you point `agent.ts` at an Anthropic model by editing one line. Use the exact gateway model id shown in your Vercel dashboard. ### How does eve keep a long Fable 5 run from failing on a deploy? eve sessions are durable. They checkpoint each step and survive crashes, cold starts, and redeploys via [Vercel Workflow](https://vercel.com/docs/workflows), so a long run resumes from its last checkpoint instead of starting over. That durability is most valuable precisely with a model like Fable 5 that attempts long, multi-step tasks. ### What happens when Fable 5 refuses a request inside an agent? It returns `stop_reason: "refusal"` as a 200 response, not an error, per Anthropic's [model docs](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5). Build a fallback path that detects the refusal stop reason and routes to Opus 4.8. You are not billed when the model refuses before producing output. ### Is this stack production-ready today? eve launched as a public preview and is in beta, so its API surface can shift before general availability, and it deploys natively to Vercel with other platforms marked coming soon. Vercel Sandbox and Fable 5 are both generally available. Treat eve's beta status as the main stability caveat. ## Sources - [Introducing eve - Vercel blog](https://vercel.com/blog/introducing-eve) - [eve documentation - Vercel docs](https://vercel.com/docs/eve) - [Vercel Sandbox is now generally available - Vercel blog](https://vercel.com/blog/vercel-sandbox-is-now-generally-available) - [Vercel Sandbox - Vercel docs](https://vercel.com/docs/sandbox) - [Vercel AI Gateway - Vercel docs](https://vercel.com/docs/ai-gateway) - [Vercel Workflow - Vercel docs](https://vercel.com/docs/workflows) - [Introducing Claude Fable 5 and Claude Mythos 5 - Anthropic docs](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5) - [Redeploying Fable 5 - Anthropic](https://www.anthropic.com/news/redeploying-fable-5)

Fable 5 vs Opus 4.8: Which Should Orchestrate Your Agents?

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Part 3 of the Fable 5 agent fleets series. Part 1, [Fable 5 Is Back: The Anthropic Model the Government Switched Off](/blog/fable-5-returns-what-changed), explained the model and its return. Part 2, [Running Fable 5 Agent Fleets in Production: The Operations Guide](/blog/fable-5-fleet-operations-guide), covered the operations layer. This post answers the choice that sits under both: for the orchestrator role, should you run Fable 5 or Opus 4.8? In a [multi-agent fleet](/blog/how-to-coordinate-multiple-ai-agents) the orchestrator is the model that plans, delegates, tracks state across a long run, and decides when the work is done. It is the highest-leverage model choice you make, because a weak orchestrator produces a fleet that is busy but incoherent, and an expensive orchestrator sets the cost floor for everything below it. So this is the decision worth getting right. Here is a fair comparison for that specific role. ## The two candidates, honestly Both are Anthropic models. Fable 5 sits above Opus 4.8 in capability. That does not automatically make it the better orchestrator for your fleet, because "better model" and "better fit for this role, budget, and compliance posture" are different questions. **Fable 5 (`claude-fable-5`)** - 1M token context, up to 128K tokens of output per request - $10 per 1M input, $50 per 1M output - Adaptive thinking always on; depth controlled by the `effort` parameter - Vendor and partner reports point to its largest lead on long-horizon, agentic work - the longer and more complex the task, the bigger the reported edge - Ships with a safety classifier that raises benign false-positive refusals on coding and debugging - Requires 30-day data retention; not available to zero-data-retention organizations **Opus 4.8 (`claude-opus-4-8`)** - $5 per 1M input, $25 per 1M output - half the price on both sides - No 30-day retention restriction; available to ZDR organizations - Proven stability, including through the June window when Fable 5 was suspended - The model Fable 5 itself falls back to on refusal, so a working Opus 4.8 path is a prerequisite for running Fable 5 at all The honest framing: Fable 5 is the more capable model on paper, especially for long runs, but it is twice the price, carries a compliance gate, and adds refusal-handling complexity. Opus 4.8 is cheaper, unrestricted, stable, and already load-bearing in any Fable 5 deployment. ## Decision matrix | Factor | Lean Fable 5 | Lean Opus 4.8 | |--------|--------------|----------------| | **Run length** | Genuinely long-horizon: multi-step migrations, deep research, extended agent loops where the reported edge compounds | Short to medium runs where a top-tier model is already more than enough | | **Budget** | The premium ($10/$50) is absorbed by the value of the outcome | Cost-sensitive workloads; $5/$25 halves the orchestrator cost floor | | **Compliance** | 30-day retention is acceptable for the workload | Zero-data-retention required, which rules Fable 5 out entirely | | **Refusal tolerance** | Your fleet already handles refusals and fallbacks cleanly | You want the fewest false-positive refusals on routine coding with less handling complexity | | **Availability posture** | You have model-agnostic fallback wiring and can absorb a frontier model going dark | You want the most proven, stable default and minimal moving parts | Read the matrix as a whole, not row by row. If most of your answers land in the right column, Opus 4.8 is your orchestrator. If your workload is genuinely long-horizon, the budget absorbs the premium, and you have already built refusal handling, Fable 5 earns its place. ## When Fable 5 wins the orchestrator role Reach for Fable 5 as your orchestrator when all of these are true: - **The runs are genuinely long-horizon.** This is the lane where the reported edge is largest. Partner reports (vendor-stated, not independently reproduced) include a codebase-wide migration across a 50M-line codebase at Stripe in about a day, top scores on Cognition's FrontierCode and Cursor's CursorBench, and long-task gains from the memory tool reported as roughly triple Opus 4.8's on some workloads. The directional claim - the edge grows with task length - is consistent across sources even before you trust the specific numbers. - **The 1M context is doing real work.** If your orchestrator needs to hold a large corpus, a long history, or many delegated results in view at once, the larger context is a concrete advantage, not a spec-sheet number. - **The budget can carry $50 per 1M output.** Long, deep runs generate a lot of output. At orchestrator scale that adds up fast, so the outcome has to justify it. - **Your fleet already handles refusals.** You have the `fallbacks` path, refusal-rate alerting, and an Opus 4.8 fallback wired and tested, as covered in Part 2. If those conditions hold, Fable 5 is the stronger orchestrator and the premium buys real coherence across long runs. ## When Opus 4.8 remains the right default Stay on Opus 4.8 as your orchestrator when any of these apply: - **You are cost-sensitive.** The orchestrator sets the cost floor for the fleet. Half the price on input and output is a large, permanent saving at scale. - **You need zero-data-retention.** This is decisive, not a preference. ZDR organizations cannot run Fable 5, so Opus 4.8 (or Sonnet) is the orchestrator by necessity. - **Your runs are short to medium.** If the task does not stretch into the long-horizon regime, you are paying the Fable 5 premium for an edge you will not exploit. A top-tier model that is more than sufficient is the right tool. - **You want fewer false-positive refusals.** Opus 4.8 does not carry Fable 5's coding-and-debugging refusal tradeoff, so routine engineering work flows with less handling overhead. - **You value stability and fewer moving parts.** Opus 4.8 stayed available through the June suspension and adds no retention gate or classifier branch. For many fleets that predictability outweighs a capability edge they would rarely reach. For a large share of production fleets, Opus 4.8 is not the compromise choice. It is the correct default. ## The honest bottom line Opus 4.8 remains the right orchestrator for many fleets - probably most of them today. It is cheaper, unrestricted, stable, and already required as the fallback in any Fable 5 deployment, so building on it is never wasted work. Fable 5 wins the orchestrator role when the tasks are genuinely long-horizon, the budget absorbs the premium, and you have already built clean refusal and fallback handling. Notice the asymmetry: choosing Fable 5 means you must also build the Opus 4.8 path, because that is where refusals and any future outage land. Choosing Opus 4.8 means you are done. So the practical order for most teams is to build a strong Opus 4.8 orchestrator first, instrument it, and promote specific long-horizon workloads to Fable 5 only where the edge is real and measured. Let the workload earn the upgrade rather than defaulting to the more powerful model because it exists. ## Frequently Asked Questions ### Is Fable 5 always the better orchestrator because it is more capable? No. Fable 5 is the more capable model, but the best orchestrator depends on run length, budget, compliance, and how much refusal-handling complexity you can absorb. For short-to-medium runs, cost-sensitive fleets, or ZDR organizations, Opus 4.8 is the better fit despite being the less powerful model. ### How much more expensive is Fable 5 than Opus 4.8? Fable 5 is $10 per 1M input and $50 per 1M output. Opus 4.8 is $5 per 1M input and $25 per 1M output - half the price on both sides. Since the orchestrator sets the fleet's cost floor, that difference compounds across a long run. ### Can zero-data-retention organizations use Fable 5 as an orchestrator? No. Fable 5 requires 30-day data retention and is unavailable to zero-data-retention organizations. Those fleets must orchestrate with Opus 4.8 or Sonnet. ### Do I need Opus 4.8 even if I choose Fable 5? Yes. Opus 4.8 is the model Fable 5 falls back to when its safety classifier refuses a request, so a working Opus 4.8 path is a prerequisite for running Fable 5 in production. Choosing Fable 5 means building both; choosing Opus 4.8 means building one. ## Sources - Anthropic, [Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) - Anthropic, [Redeploying Fable 5](https://www.anthropic.com/news/redeploying-fable-5) - Anthropic Docs, [Introducing Claude Fable 5 and Claude Mythos 5](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5)

GLM 5.2 in 9 Minutes: The Open-Weight Rival to GPT-5.5

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Watch: GLM 5.2 in 9 Minutes](https://www.youtube.com/watch?v=lVEi3NmndwQ) | The full walkthrough on the DevDigest channel | | [OpenCode](https://opencode.ai) | The coding environment used for the live demo | ## What This Video Covers **GLM 5.2 in 9 Minutes** explains GLM 5.2 as an open-weight rival to GPT-5.5. The video reviews the model, works through benchmarks and pricing, and finishes with a live demo running GLM 5.2 inside OpenCode. This post is a companion to the video above. Watch the nine-minute walkthrough for the benchmarks and the live demo, then use the links here to place GLM 5.2 in context. ## The Idea in One Line An open-weight model aimed squarely at a frontier closed model. GLM 5.2 is framed as a direct rival to GPT-5.5, which is the interesting part: the comparison is not open versus closed in the abstract, it is one specific open-weight release measured against a specific proprietary one. ## Why It Matters Three angles make this worth a look: - **Open weights change the math.** When a model ships its weights, pricing and deployment options open up in ways a hosted-only model cannot match. The video spends time on pricing for exactly this reason, and the [GLM 5.2 cost math for open-weight coding models](/blog/glm-5-2-cost-math-open-weights-coding-models) post goes deeper on the numbers. - **Benchmarks set expectations.** Positioning a model against GPT-5.5 is a claim you can test. The [GLM 5.2 developer guide](/blog/glm-5-2-developer-guide-2026) and the [open-weights coding showdown](/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown) put those numbers next to the alternatives. - **A live demo beats a spec sheet.** Running the model in OpenCode shows how it behaves on real coding work, not just how it scores. ## Where It Fits GLM 5.2 sits in a crowded field of open-weight coding models. If you are weighing access and cost, [GLM 5.2 free and cheap access](/blog/glm-5-2-free-and-cheap-access-2026) covers how to try it without a big commitment. For the closed-model side of the comparison, the [GPT-5.5 hallucination benchmark against GLM 5.2](/blog/gpt-5-5-hallucination-benchmark-glm-5-2) looks at where each model lands. ## Getting Started The path the video demonstrates is simple: try GLM 5.2 inside a coding environment like OpenCode and judge it on your own tasks. Start with a small, well-scoped job so you can compare its output against a model you already trust before leaning on it for anything larger. Watch the full **GLM 5.2 in 9 Minutes** walkthrough above, then run the model against a task of your own and see how the open-weight option holds up.

Godot Bans AI-Authored Code Contributions - What It Means for Open Source

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

The Godot Foundation announced a new contribution policy on June 30, 2026 that explicitly bans autonomous AI agent use and substantial AI-generated code in pull requests. The policy drew immediate attention on Hacker News, sparking debate about how open source projects should adapt to AI-assisted development. ## What the Policy Actually Says The [official policy](https://godotengine.org/article/contribution-policy-2026/) draws clear lines: **Prohibited:** - Autonomous AI agent use or "vibe coding" (results in automatic repository ban) - AI-generated substantial pieces of code - AI-generated text in human communication with maintainers **Allowed:** - Menial tasks like code completion, regex, or find-and-replace - Machine translations (if original content was human-written) Contributors who use AI assistance must disclose it in the PR discussion. Non-compliance with the agent prohibition triggers automatic GitHub repository suspension. ## The Foundation's Reasoning The policy cites three concerns: 1. **AI cannot learn from feedback.** When maintainers provide review comments, those insights go toward mentoring future contributors. With AI slop, that feedback disappears into a model that learns nothing and cannot become a maintainer. 2. **Machines cannot take responsibility.** When code breaks, someone needs to debug it. The Foundation argues that heavy AI users often do not understand their generated code well enough to fix it. 3. **Reviewer demoralization.** The Foundation stated: "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review." ## What HN Is Saying The [Hacker News thread](https://news.ycombinator.com/item?id=48743472) generated 160+ comments with a range of reactions. **Support for the policy:** Several commenters endorsed the approach. One noted that AI-authored PRs feel like "a denial-of-service attack on the human mind" - verbose walls of text that require thorough review but provide no mentorship value. Another pointed out the self-correcting nature of open source: "If someone thinks they're building better open source with their AI, let them fork; their AI can maintain downstream. If it's really better, people will join the fork." **Skepticism about enforcement:** Others questioned the practicality. One commenter asked: "Why base the decision on what tools are used by the author and not on the quality of their past contributions?" The concern is that this polices process rather than outcomes. Another pointed out a logical gap: "The idea that you can't trust code that was generated by heavy users of AI, because they don't understand it enough to fix it, is false, because they can use AI to fix it." Whether that fixes the mentorship concern is a different question. **Wait-and-see takes:** Multiple commenters expressed support for the experiment even if they disagreed with the policy: "I'm glad we are seeing different projects experimenting with different policies. So after a while we can probably see how things shake out in the end." One predicted the policy would need revision: "AI tooling and quality are changing quite fast. In a year I'd expect a modification of this as AI agents get better in virtually every possible way." **Project-specific criticism:** A few commenters used the moment to criticize Godot's pace of development, though this is tangential to the AI policy itself. ## The Broader Context Godot is not the first project to wrestle with AI contributions. Multiple curated lists now track "slop-free" software projects: - [Codeberg's slopfree-software-index](https://codeberg.org/brib/slopfree-software-index) - [Starlightnet's NoAI list](https://noai.starlightnet.work/list.html) The concern is not unique to Godot. As AI coding tools become more capable, open source maintainers face a scaling problem: more contributions, but potentially lower average quality and no path to mentoring the next generation of maintainers. ## What This Means for AI-Assisted Development The Godot policy sits at one end of a spectrum. Other projects may take different approaches: 1. **Ban AI entirely** (Godot's approach for substantial code) 2. **Require disclosure** (already common in many projects) 3. **Judge by output quality** (ignore tooling, focus on results) 4. **Require test coverage** (AI code is fine if it comes with passing tests) For individual developers, the takeaway is to check contribution guidelines before submitting AI-assisted PRs. For maintainers, the Godot policy provides a template - but not the only template. The Foundation acknowledged this is a conservative approach and said they will "continue taking a conservative approach" while re-evaluating as tools evolve. ## A Practical Note If you use AI coding tools and want to contribute to projects with strict policies, the Godot guidelines still allow AI for: - Code completion (copilot-style suggestions) - Regex generation - Find-and-replace automation - Translation of human-written content The ban targets autonomous agents that generate substantial code blocks or entire files without human authorship of the underlying logic. ## Sources - [Godot Foundation Contribution Policy 2026](https://godotengine.org/article/contribution-policy-2026/) - Official policy announcement - [Hacker News Discussion](https://news.ycombinator.com/item?id=48743472) - Community discussion with 160+ comments - [PC Gamer Coverage](https://www.pcgamer.com/gaming-industry/open-source-game-engine-godot-will-no-longer-accept-ai-authored-code-contributions-we-cant-trust-heavy-users-of-ai-to-understand-their-code-enough-to-fix-it/) - Initial reporting --- **Last updated:** July 1, 2026

GPT-5.5 in 7 Minutes: Benchmarks, Codex Agents, Context Window, and Pricing

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Watch: GPT-5.5 in 7 Minutes](https://www.youtube.com/watch?v=A9G3s8Qeu_8) | The full walkthrough on the DevDigest channel | | [OpenAI](https://openai.com) | Official site for ChatGPT and Codex | ## What This Video Covers **GPT-5.5 in 7 Minutes** reviews OpenAI's newly released GPT-5.5, now rolling out to ChatGPT and Codex and positioned as a new class of model. The video works through benchmarks, its behavior as a Codex agent, the context window, and pricing. This post is a companion to the video above. Watch the seven-minute review for the numbers and the demo, then use the links here to place GPT-5.5 in context. ## The Idea in One Line GPT-5.5 is OpenAI's next step across both ChatGPT and Codex. The interesting framing is that it lands in the coding agent, not just the chat product, so the benchmarks and pricing matter to anyone building with Codex. ## Why It Matters Four things the video weighs are worth your attention: - **Benchmarks set the baseline.** New release, new scores. The [GPT-5.5 developer guide](/blog/gpt-5-5-developer-guide) puts the numbers next to what you can actually do with them. - **Codex agents are the real test.** A model that runs inside Codex gets judged on agentic coding, not just single answers. [GPT-5.5 in Codex production](/blog/gpt-5-5-codex-production) looks at how it holds up on real work. - **Context window changes scope.** How much the model can hold at once decides which tasks are even feasible. - **Pricing decides adoption.** The cost per token is what turns a benchmark win into a practical choice. ## Where It Fits GPT-5.5 arrives into a competitive field. [GPT-5.5 versus Claude Opus 4.8](/blog/gpt-5-5-vs-claude-opus-4-8) compares it against Anthropic's flagship, while [Fable 5 versus GPT-5.5](/blog/fable-5-vs-gpt-5-5-benchmark-comparison) and the [GPT-5.5 hallucination benchmark against GLM 5.2](/blog/gpt-5-5-hallucination-benchmark-glm-5-2) place it next to other recent releases. The comparisons are where a spec sheet turns into a decision. ## Getting Started The path the video points to is to try GPT-5.5 where you already work, whether that is ChatGPT or Codex, and judge it on tasks you understand well. Start with something you can grade yourself so the benchmarks become real numbers for your own workflow. Watch the full **GPT-5.5 in 7 Minutes** review above, then run the model on a task of your own and see whether the new release earns the switch.

Refusals at Fleet Scale: Building Fable 5 Agents That Do Not Silently Fail

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

This is Part 3 of the Fable 5 agent fleets series. Part 1 covered [what Fable 5 is and why it came back](/blog/fable-5-returns-what-changed). Part 4 looks at [what its 1M context and memory actually unlock](/blog/long-horizon-agents-fable-5). This post is the applied one: the single API behavior that will corrupt a fleet run if you ignore it, and how to build around it from day one. ## The failure that does not look like a failure When Fable 5's safety classifier refuses a request, it does not raise an HTTP error. It returns a normal `200` response with `stop_reason: "refusal"`. There is no exception to catch, no non-2xx status to branch on, no timeout. From the outside it looks like the model completed and returned very little. For a single interactive chat, this is a minor annoyance. A user sees a short or empty answer, shrugs, and retries. For a fleet, it is a different class of problem. If your orchestrator hands work to 40 parallel workers (the [fan-out coordination pattern](/blog/how-to-coordinate-multiple-ai-agents)) and treats each `200` as a successful worker result, a refused request becomes a hole in the middle of the run that nothing flags. The worker "succeeded." The aggregation step consumes its empty or truncated output as if it were real. The final artifact is quietly wrong, and the only signal you get is a downstream result that does not add up. This is worse than a crash. A crash is loud and local. A silent refusal is quiet and it propagates. It is the reliability equivalent of a function that returns `undefined` instead of throwing. The reason this matters *now*, and not as some theoretical edge case, is the post-return classifier. When Fable 5 came back on July 1, 2026, Anthropic shipped a new safety classifier that blocks the specific reported jailbreak technique more than 99 percent of the time. The tradeoff, stated plainly in [the redeployment post](https://www.anthropic.com/news/redeploying-fable-5), is more false positives on benign coding and debugging work. Blocked requests are re-served by Opus 4.8. If your fleet does security research, vulnerability triage, exploit-adjacent defensive work, or even ordinary debugging that touches those topics, you will see refusals, and you will see them on requests that are completely legitimate. Build the fallback path on day one. It is not an optimization. It is table stakes. ## Detecting a refusal in every worker loop The first rule: never trust a `200` to mean "the model produced a usable answer." Check `stop_reason` explicitly on every completion, in every worker. ```ts // illustrative - fields follow the documented response shape type StopReason = "end_turn" | "max_tokens" | "tool_use" | "refusal"; interface WorkerResult { ok: boolean; refused: boolean; text: string; model: string; stopReason: StopReason; } function interpret(response: MessageResponse): WorkerResult { const refused = response.stop_reason === "refusal"; return { ok: !refused && response.stop_reason !== "max_tokens", refused, text: extractText(response), model: response.model, stopReason: response.stop_reason, }; } ``` The important discipline is structural, not clever: a refusal must be a first-class outcome in your worker's return type, not something inferred later from a suspiciously short string. If `refused` is a real field that the aggregation layer can read, you can decide what to do with it. If it is buried inside an empty `text`, you cannot. A refusal also has one useful billing property worth noting. If Fable 5 refuses before producing any output, you are not billed for that request. That makes the "detect and retry on a different model" pattern cheap: the refused attempt costs nothing, and only the fallback attempt bills. ## Three ways to fall back, and when to use each Anthropic supports three routes for handling a refusal. They are not interchangeable, and picking the wrong one for your fleet shape creates its own problems. ### 1. Server-side `fallbacks` You pass a `fallbacks` parameter and the platform re-serves a refused request on the fallback model for you. This is the least code and the most consistent behavior across every call site, because the retry happens before the response ever reaches your app. Use it when you want a uniform policy across the whole fleet and you are comfortable letting the platform decide when to hand off. The cost is control: the fallback fires on the platform's terms, and your orchestrator sees the final answer without necessarily knowing a handoff happened unless you inspect the returned `model` field. ### 2. SDK middleware You wrap the client so that a refusal is intercepted and retried according to your own logic before your business code sees it. This sits between the raw API and your worker loop. ```ts // illustrative middleware wrapper async function withRefusalFallback( req: MessageRequest, primary = "claude-fable-5", fallback = "claude-opus-4-8", ): Promise { const first = interpret(await client.messages.create({ ...req, model: primary })); if (!first.refused) return first; metrics.increment("fable5.refusal", { stage: req.stage }); const second = interpret(await client.messages.create({ ...req, model: fallback })); return { ...second, refused: false }; // resolved by fallback } ``` Use middleware when you want one consistent fallback policy but also want to emit metrics, tag the result, or vary the fallback per task type. It is the sweet spot for most fleets: centralized, observable, and still yours. ### 3. Manual fallback in the worker The worker itself catches the refusal and decides what to do. Maximum control, maximum boilerplate, and the easiest to get subtly wrong because every worker has to remember to do it. Reserve manual handling for workers with genuinely special requirements, for example a step where the fallback prompt has to differ from the primary prompt, or where a refusal should route to a human review queue instead of another model. For most teams the answer is middleware as the default, with server-side `fallbacks` as a floor so that even an un-wrapped call site is covered. Manual handling stays the exception. ## Designing the Opus 4.8 fallback so results stay consistent Falling back to a different model is not free of consequences. Opus 4.8 is a different model than Fable 5, with a different context window, different pricing, and different output characteristics. If half your fleet's results came from Fable 5 and the other half came from Opus 4.8 because of scattered refusals, you can end up with an inconsistent final artifact: two coding styles in one migration, two summary voices in one report, two verdicts from what should be one rubric. A few practices keep the fallback path coherent: - **Keep the prompt model-agnostic.** The same prompt should produce compatible output on both models. Avoid instructions that lean on Fable-5-only behavior. If you must specialize, specialize on the fallback path explicitly rather than hoping the primary prompt transfers. - **Tag every result with the model that produced it.** Carry `model` through to the aggregation layer. When a downstream reviewer or a human sees an odd result, "this one came from the fallback" is the first thing they should be able to check. - **Normalize at the seams.** If your fleet stitches worker outputs into one artifact, run a consistency pass (formatting, naming, voice) after aggregation so mixed-model output does not leak into the deliverable. - **Decide whether a fallback result is acceptable per task.** For a bulk code migration, an Opus 4.8 result for one file is fine. For a task where only Fable 5's depth is the point, a refusal might mean "escalate to a human," not "silently downgrade." The goal is that a reader of the final artifact cannot tell which workers were refused and re-served, because you designed for that outcome instead of discovering it. ## Idempotency and retry budgets Retries are where a naive fallback turns into a runaway. Two guardrails matter. **Idempotency.** A worker that gets refused, retried, and then partially completes must not double-apply its side effects. If a worker writes a file, opens a PR, or posts a result, tag each unit of work with a stable idempotency key so a retried attempt overwrites rather than duplicates. This is ordinary distributed-systems hygiene, but refusals make it non-optional because refusal-driven retries are now a normal, frequent path rather than a rare error case. **Retry budgets.** Cap how many fallback attempts a single task gets, and cap the aggregate fallback rate for a run. A per-task budget of one Fable 5 attempt plus one Opus 4.8 attempt is a reasonable default. Without a budget, a systematically refused category of work (say, every worker touching a security module) can quietly double your spend and latency as every task burns its full retry allowance. ```ts // illustrative retry-budget guard async function runWorker(task: Task, budget: RetryBudget): Promise { const result = await withRefusalFallback(task.request); if (result.refused && !budget.tryConsume()) { return { ...result, ok: false }; // out of budget - escalate, do not loop } return result; } ``` The failure mode to design against is the fleet that "works" but silently costs 2x because a whole task category is being refused and re-served on every run, and nobody is watching the number. ## Refusal rate is a fleet health metric The most important shift is treating the refusal rate as a first-class operational signal, right next to latency and error rate. Emit a counter every time a worker is refused, tagged by task type, stage, and prompt template. Then watch it: - **A sudden spike** in one task category usually means a prompt or an input started tripping the classifier. That is a debugging lead, not noise. - **A slow climb** across the fleet can mean your workload is drifting toward topics the post-return classifier treats conservatively. - **A near-zero rate everywhere** on a fleet that touches security or debugging work is itself suspicious. It may mean your detection is broken and refusals are being silently swallowed as "successful" empty results. Because the post-return classifier deliberately trades false positives for safety, a healthy Fable 5 fleet has a non-zero baseline refusal rate. The number to alert on is a *change*, not the presence of refusals. Establish the baseline in the first week, chart it per task type, and page on deviations. A practical dashboard has three lines: total requests, refusals, and fallback resolutions. When those three move together, your fleet is absorbing refusals as designed. When refusals climb but fallback resolutions do not, you have workers dropping refused work on the floor, which is exactly the silent corruption this whole post is about. ## The day-one checklist - Check `stop_reason` on every completion. Make `refused` a real field on the worker result. - Wrap the client in middleware with an Opus 4.8 fallback. Keep server-side `fallbacks` on as a floor. - Keep prompts model-agnostic and tag every result with its producing model. - Add idempotency keys to any worker with side effects. - Set per-task and per-run retry budgets. Escalate out-of-budget refusals instead of looping. - Emit and chart refusal rate by task type. Alert on change, not on presence. None of this is exotic. It is the reliability engineering that a `200`-that-means-`refusal` forces you to do up front instead of after your first quietly corrupted run. ## Frequently Asked Questions ### How do I tell a refusal apart from a normal short answer? Check `stop_reason`, not the length of the text. A refusal returns `stop_reason: "refusal"` on an otherwise normal `200` response. A short but legitimate answer returns `end_turn`. Never infer a refusal from a suspiciously short string, because that is exactly the ambiguity that lets refusals slip through as "successful" results. ### Am I billed for a refused request? If Fable 5 refuses before producing any output, you are not billed for that attempt, per Anthropic's guidance. That is what makes the detect-and-fall-back pattern cheap: the refused attempt costs nothing and only the fallback attempt on Opus 4.8 bills. ### Should I use the server-side `fallbacks` parameter or write my own? Use SDK middleware as your default so you can emit metrics and tag results, and keep server-side `fallbacks` enabled as a floor so even un-wrapped call sites are covered. Reserve fully manual, per-worker handling for steps with special requirements like a different fallback prompt or routing to a human queue. ### Why is this a day-one requirement instead of an edge case? Because the post-return safety classifier that shipped with Fable 5's July 1 redeployment blocks the reported technique more than 99 percent of the time at the cost of more false positives on benign coding and debugging. If your fleet does that kind of work, legitimate requests will be refused, so the fallback path is a normal operating condition rather than a rare exception. ## Sources - [Introducing Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) - [Redeploying Fable 5](https://www.anthropic.com/news/redeploying-fable-5) - [Fable 5 and Mythos 5 model docs](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5) - [Fable 5 Is Back: What Changed](/blog/fable-5-returns-what-changed) - [Long-Horizon Agents: What Fable 5's 1M Context and Memory Unlock](/blog/long-horizon-agents-fable-5)

Long-Horizon Agents: What Fable 5's 1M Context and Memory Actually Unlock

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

This is Part 4 of the Fable 5 agent fleets series. Part 1 covered [what Fable 5 is and why the government switched it off](/blog/fable-5-returns-what-changed). Part 3 is the applied guide to [handling refusals at fleet scale](/blog/handling-fable-5-refusals-agent-fleets) so a run does not silently fail. This post is the possibilities one: what a day-long autonomous run actually looks like when a single model holds a million tokens and can write state that outlives its own context. ## The shape of a long-horizon run Most agent frameworks today are built around a hard constraint: the model forgets. Context fills up, you compress or drop history, and the agent loses the thread on anything long. A lot of orchestration complexity - retrieval layers, summarization passes, handoff protocols - exists to work around that single limitation. Fable 5 changes the constraint's dimensions. It ships with a 1M token context window, up to 128K output tokens per request, and a set of API primitives aimed squarely at runs that last longer than one prompt. That does not make the forgetting problem disappear, but it moves the ceiling high enough that a different class of task becomes a single coherent run instead of a fragile pipeline of stitched-together calls. Concretely, the building blocks are: - **1M token context** to hold an entire codebase, a long task history, and the working state of a multi-step job at the same time. - **128K output per request** to emit large artifacts - a full migration, a generated test suite, a long report - without chopping them across dozens of calls. - **A memory tool** to write durable state to files that survive beyond the context window, so a run's knowledge is not lost when the window turns over. - **Compaction and context editing (beta)** to keep a run going even when it outgrows even 1M tokens, by condensing or pruning what is in context without ending the run. - **Task budgets (beta)** to cap the cost and depth of a long autonomous run so "day-long" does not mean "unbounded spend." - **Programmatic tool calling and code execution** so the agent can act, not just describe. Note that adaptive thinking is always on and cannot be disabled; you tune its depth with the `effort` parameter. For long-horizon work that matters, because deeper reasoning on a hard step is often the difference between a run that stays on track and one that drifts. It also means cost control lives in `effort` and task budgets, not in a thinking on/off switch. ## The concrete anchor: a codebase migration in about a day The headline example, and the one worth being precise about, is vendor-reported. In [the Fable 5 launch post](https://www.anthropic.com/news/claude-fable-5-mythos-5), Anthropic reports that Stripe used Fable 5 to migrate a roughly 50-million-line Ruby codebase in about a day. Anthropic also reports top scores on FrontierCode and CursorBench, and that giving the model file-based memory roughly tripled its gains on long-horizon tasks compared with Opus 4.8, with the lead growing as tasks get longer and more complex. Treat all of that as partner-reported and benchmark-reported, because it is. It is a strong signal from a credible source, not an independently reproduced result you should quote as a guarantee to your stakeholders. What it establishes is directional: a single model run holding a very large codebase in context, writing state to memory as it goes, and emitting large volumes of changed code is a real workload the vendor is demonstrating, not a hypothetical. The honest framing for a builder is this. The *primitives* are verified: 1M context, 128K output, a memory tool, compaction, task budgets, code execution. The *magnitude* of what Stripe reports is plausible given those primitives but is a vendor claim under conditions you do not control. Your mileage will depend on your codebase's structure, your test coverage, your prompts, and how much of the work is genuinely mechanical versus judgment-heavy. Design your own pilot to find out, rather than assuming the demo transfers one-to-one. ## What each primitive actually buys you ### 1M context: the whole thing in the room The practical win of a million tokens is not "more history." It is that the agent can reason over a whole system at once. A migration or a repo-wide refactor no longer has to be chunked into files the model sees in isolation, losing cross-file invariants at every boundary. When the entire codebase plus the task's running history fit in context, the model can catch the call site three directories away that your chunked pipeline would have missed. The failure mode of chunked agents - locally correct edits that are globally inconsistent - is exactly what a large context is positioned to reduce. ### 128K output: artifacts, not fragments Large output per request means the deliverable can be the artifact itself. A full test suite, a complete migration diff for a module, a long structured report - emitted in one coherent pass rather than assembled from many partial calls that each lose a little context at the seam. Fewer seams means fewer places for inconsistency to creep in. ### The memory tool: state that outlives the window This is the one that changes the character of a run. A context window, however large, is still finite and still turns over on a long enough job. A file-based memory tool lets the agent write down what it has learned - decisions made, conventions discovered, files already handled - so that knowledge persists even after the raw tokens that produced it have scrolled out of context. Anthropic's own reported result, that file memory roughly tripled long-horizon gains over Opus 4.8, points at this being the load-bearing primitive for genuinely long runs, not the raw window size. ### Compaction and context editing: runs that outgrow 1M Even a million tokens runs out on a large enough job. Compaction and context editing (both beta) are the mechanisms for continuing past that ceiling: condensing what is in context and pruning what is no longer needed without ending the run. Combined with memory, this is what turns "a very long single request" into "a genuinely long-horizon agent" - one that can keep working after its context has been reshaped several times. ### Task budgets: bounded autonomy The catch with day-long autonomy is that a runaway agent can spend a lot of money before anyone notices. Task budgets (beta) cap the cost and depth of a run so autonomy stays bounded. This is the primitive that makes long-horizon runs safe to actually turn loose, because "let it work overnight" only makes sense if "it" cannot burn an unbounded amount while you sleep. For the scheduling side of recurring, unattended runs, [Claude Code loops](/blog/claude-code-loops) covers the native primitive. ## Verified versus plausible It is worth being blunt about the line, because a lot of Fable 5 commentary blurs it. **Verified (documented by Anthropic):** 1M token context; up to 128K output per request; a memory tool; code execution; programmatic tool calling; context editing and compaction (beta); task budgets (beta); always-on adaptive thinking tuned by `effort`; pricing of \$10 per 1M input and \$50 per 1M output; text plus high-resolution vision input; a 30-day retention requirement. **Vendor or benchmark reported (credible, not independently reproduced here):** the Stripe ~50M-line migration in about a day; top FrontierCode and CursorBench scores; file-based memory roughly tripling long-horizon gains over Opus 4.8; the lead growing with task length and complexity. **Plausible but unproven for your workload:** that a day-long autonomous run will hold coherence across your specific codebase; that the memory tool will retain the right state for your task without careful prompt design; that costs will land where you expect before you have measured them. These are the things a pilot answers, not a blog post. Build on the verified primitives. Use the vendor claims as reasons to run a pilot, not as numbers to promise upward. ## Six projects to try now If you have access to Fable 5 and you want to pressure-test long-horizon agents on real work, here are concrete starting points. Each one leans on a different combination of the primitives above. 1. **A codebase-wide migration.** Pick a mechanical but sprawling change - a framework version bump, an API rename, a language idiom shift - and let a single run hold the whole repo in context while writing progress to memory. This is the direct analog of the Stripe example. Start on a subsystem, measure coherence and cost, then decide whether to scale. 2. **Repo-wide test authoring.** Point the agent at an under-tested codebase and have it generate a coherent test suite in large 128K output passes, using memory to track which modules are covered so it does not duplicate or drift as it works across the repo. 3. **A multi-day research agent.** Combine memory and compaction to run a research task that spans far more material than fits in one window - a literature sweep, a competitive teardown, a standards review - where the agent's notes file becomes the durable artifact and the context is repeatedly reshaped around it. 4. **Full documentation regeneration.** Have the agent read an entire codebase in context and regenerate docs that stay consistent with the actual implementation, emitting long structured output and using memory to keep terminology and structure uniform across hundreds of pages. 5. **Dependency upgrades at scale.** Task a bounded run (task budgets on) with upgrading a dependency across a large monorepo, resolving the cascade of breaking changes with the whole tree visible in context rather than one package at a time. 6. **A long-lived maintenance agent.** Give an agent a memory file as its persistent brain and a task budget as its leash, and let it work a backlog over a long session - triaging issues, drafting fixes, updating notes - so its accumulated context survives across many context-window turnovers. For every one of these, the discipline from Part 3 still applies: check `stop_reason` on each call, keep an Opus 4.8 fallback, and treat refusal rate as a health metric. A long-horizon run has more surface area for a silent refusal to corrupt the whole job, so the reliability work is not optional just because the model is more capable. ## The honest bottom line Fable 5's long-horizon story is real where it counts: the primitives that make day-long, large-context, memory-backed runs possible are documented and available. The most eye-catching number, the Stripe migration, is a vendor claim that tells you the ceiling is high, not that your run will hit it. The right move is to build on the verified primitives, run a scoped pilot on one of the projects above, measure coherence and cost on your own workload, and let the results - not the launch post - tell you how far to push. ## Frequently Asked Questions ### Does 1M context mean I no longer need retrieval or memory layers? No. A larger context reduces how much stitching and retrieval you need for a given job, but a million tokens still turns over on a long enough run. The memory tool exists precisely because durable state has to outlive the window. Anthropic's own reported result, that file memory roughly tripled long-horizon gains over Opus 4.8, suggests memory is the load-bearing primitive for long runs, not raw window size. ### Is the Stripe 50-million-line migration something I can rely on? Treat it as vendor-reported. It is a credible signal from Anthropic's launch post that a very large single-run migration is a real workload, but it was performed under conditions you do not control. Use it as a reason to pilot on a subsystem of your own codebase and measure, not as a number to promise to stakeholders. ### How do I keep a day-long run from spending an unbounded amount? Use task budgets (beta) to cap the cost and depth of a run, and tune reasoning depth with the `effort` parameter. Adaptive thinking is always on and cannot be switched off, so cost control lives in budgets and effort, not in a thinking toggle. For fleets, also apply the retry-budget discipline from Part 3 so refusal-driven fallbacks do not quietly multiply spend. ### What is verified versus just plausible about Fable 5's long-horizon claims? Verified and documented: 1M context, 128K output, the memory tool, code execution, programmatic tool calling, compaction and context editing (beta), and task budgets (beta). Vendor or benchmark reported: the Stripe migration, top FrontierCode and CursorBench scores, and the file-memory gains over Opus 4.8. Plausible but unproven for your case: that a run will stay coherent and land on-budget for your specific codebase. That last category is what a pilot answers. ## Sources - [Introducing Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) - [Redeploying Fable 5](https://www.anthropic.com/news/redeploying-fable-5) - [Fable 5 and Mythos 5 model docs](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5) - [Fable 5 Is Back: What Changed](/blog/fable-5-returns-what-changed) - [Refusals at Fleet Scale: Fable 5 Agents That Do Not Silently Fail](/blog/handling-fable-5-refusals-agent-fleets)

Loop Engineering in 9 Minutes: Stop Prompting, Start Building Loops

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Watch: Loop Engineering in 9 Minutes](https://www.youtube.com/watch?v=nKlF15Ic78w) | The full walkthrough on the DevDigest channel | ## What This Video Covers **Loop Engineering in 9 Minutes** discusses moving away from repeatedly prompting an LLM and toward long-running loops and automations. Instead of driving a model one message at a time, you set goals and let long-running workflows carry the work forward. This post is a companion to the video above. Watch the nine-minute walkthrough for the full argument, then use the links here to see how the loop idea shows up across tools. ## The Idea in One Line Stop prompting, start building loops. The tasks that matter are rarely a single question. They are ongoing goals, and a loop that keeps working toward a goal beats retyping the same prompt every time you want the next step. ## Why It Matters The shift changes how you spend your time: - **Goals replace instructions.** Describing an outcome once and letting a loop pursue it is more durable than issuing a fresh prompt for every step. This is the same theme in [Claude Code routines versus managed agent schedules](/blog/claude-code-routines-vs-managed-agents-schedules). - **Long-running beats one-shot.** A workflow that keeps running can react to new state instead of stopping after a single answer. [Claude Code loops](/blog/claude-code-loops) shows how this looks inside one tool. - **Automations compound.** Once a loop exists, it becomes something you reuse, which lines up with [Codex automations for recurring engineering work](/blog/codex-automations-recurring-engineering-work). ## Where It Fits Loop thinking is showing up across the ecosystem. [Codex loops and agent routines](/blog/codex-loops-boris-cherny-agent-routines) covers one implementation, and [the coming loop and agent comprehension](/blog/armin-ronacher-coming-loop-agent-comprehension) looks at where the pattern is headed. The common thread is the same one this video argues: less manual prompting, more standing workflows. ## Getting Started The move the video suggests is to take a task you keep re-prompting, define it as a goal, and set up a loop or automation to carry it. Start with something low-risk and observable so you can watch what the loop does before trusting it with more. Watch the full **Loop Engineering in 9 Minutes** walkthrough above, then turn one repetitive prompt of yours into a standing loop and stop typing it again.

The MCP 2026-07-28 Rewrite: What Breaks and How to Migrate

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | 2026-07-28 Release Candidate announcement | [blog.modelcontextprotocol.io](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) | | 2026 MCP Roadmap | [blog.modelcontextprotocol.io/posts/2026-mcp-roadmap](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/) | | SEP guidelines (spec change process) | [modelcontextprotocol.io/community/sep-guidelines](https://modelcontextprotocol.io/community/sep-guidelines) | | NSA/DoD MCP security guidance (PDF) | [media.defense.gov](https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF) | The next version of the [Model Context Protocol](/blog/what-is-mcp) lands on July 28, 2026, and the maintainers are calling it the largest revision since launch. This is not a point release with a few new fields. The 2026-07-28 spec rewrites the core transport model, deprecates three long-standing features, hardens authorization, and promotes two extensions to first-class status. If you build, host, or integrate MCP servers, this one has a hard dated deadline. The release candidate is available now, and the final spec is locked to July 28. That leaves less than four weeks to validate against the RC and plan your migration. This guide is the decision-intent version: what the spec is, what actually breaks, what is worth adopting, and a concrete checklist split by role so you can figure out how urgent this is for your setup. For the deep code-level walkthrough of the transport change specifically, see the companion [MCP stateless migration guide](/blog/mcp-stateless-migration-guide-2026). This post is the wider map. ## What the 2026-07-28 Spec Actually Is MCP has shipped dated specification versions since launch. Each version is a snapshot of the protocol that clients and servers negotiate against. The 2026-07-28 version consolidates a year of roadmap work ([the 2026 roadmap](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/)) into a single dated release, and it is intentionally a clean break rather than a gentle addition. Three things make it a big deal: 1. It changes the transport contract. A stateless core means the shape of a valid request and response is different, so old and new implementations do not silently interoperate. 2. It deprecates features that many servers and clients rely on today. Deprecation starts a removal clock, so code that works now becomes tech debt on a schedule. 3. It ships governed extensions. Instead of the protocol growing forever, optional capabilities now live in versioned extensions with their own lifecycle, following the [SEP change process](https://modelcontextprotocol.io/community/sep-guidelines). The net effect: fewer things live in the mandatory core, the core is simpler and easier to scale, and the interesting new surface area moves into extensions you opt into. ## What Breaks ### The stateless core The headline change is that the core protocol goes stateless. The old model required a session: the client connected, sent an `initialize` message, received a session identifier, and echoed that identifier on every following request. That session pinned a client to one server instance. The new core drops the session handshake. Each request is self-contained and can hit any server instance, so an MCP server can run behind a plain round-robin load balancer with no sticky sessions and no shared session store. Routing moves to an `Mcp-Method` header, so gateways can make routing decisions from headers instead of parsing request bodies. And `tools/list` responses become cacheable through a `ttlMs` field, so clients and infrastructure can hold the tool list for a defined window instead of refetching it on every connection. The practical impact on existing code: | Concern | Old behavior | 2026-07-28 behavior | |---------|--------------|---------------------| | Session handshake | `initialize` required first | Removed - self-contained requests | | Session state | Server memory or shared store | None required in the core | | Load balancing | Sticky sessions | Plain round-robin works | | Request routing | Inspect body for session ID | `Mcp-Method` header | | Tool list fetch | Re-fetched per connection | Cacheable via `ttlMs` | Any server that expects `initialize` as the first message, any gateway that routes on a session header, and any client that assumes a pinned instance will need to change. The upside is real: horizontal scaling, serverless deployment, and edge compute all get much simpler once state leaves the core. The deeper code patterns for externalizing state are covered in the [stateless migration guide](/blog/mcp-stateless-migration-guide-2026). ### Deprecated: Roots, Sampling, and Logging The spec deprecates three features that shipped in earlier versions: - **Roots** - the mechanism for a client to advertise filesystem or workspace boundaries to a server. - **Sampling** - the mechanism for a server to ask the client's model to generate a completion on its behalf. - **Logging** - the protocol-level logging notifications servers emit to clients. Deprecation is not deletion. Per the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines), deprecated features enter a formal lifecycle rather than disappearing on release day, which is the maintainers' answer to the criticism that breaking changes used to arrive with no runway. But the direction is set: if your server relies on Sampling to call back into the host model, or your client leans on Roots to scope a server, or you depend on protocol Logging for observability, you are now building on features with an expiration date. Plan replacements. For observability, the spec's standardized tracing keys (below) are the forward path instead of protocol Logging. ### Stricter tool schemas: full JSON Schema 2020-12 Tool input schemas move to full [JSON Schema 2020-12](https://json-schema.org/specification-links#2020-12). If your tools currently use a loose subset of JSON Schema, or rely on validator quirks, stricter validation can reject schemas that used to pass. This is a good change for correctness and for how reliably a model can call your tools, but it is a real compatibility checkpoint. Validate every tool schema against a 2020-12 validator before you ship. ## What Is New and Worth Adopting The rewrite is not only subtraction. Several additions are worth adopting deliberately. ### MCP Apps: server-rendered UIs MCP Apps lets a server return sandboxed, server-rendered UI instead of only text. A tool can hand the host a real interface - a form, a table, a control panel - that the client renders in a contained surface. This is the biggest expansion of what a tool call can return, and it changes the design space from "return a string" to "return an interaction." If your product would benefit from richer output than markdown, this is the feature to prototype first. ### Tasks as a first-class extension Long-running work gets a proper home. Tasks graduates from experimental into a first-class extension for operations that do not finish inside one request: builds, deployments, long agent runs, batch jobs. Because the core is now stateless, Tasks is built around resumable, pollable state rather than a held-open connection, so any server instance can report on or advance a task as long as it can reach the shared task store. If you shipped against the earlier experimental Tasks surface, budget time to migrate to the extension's model. ### Auth hardening: OAuth and OIDC Authorization gets stricter and more standards-aligned around OAuth and OIDC. The direction is tighter validation of tokens and issuers and cleaner client registration, which matters because MCP servers increasingly sit in front of real systems and real data. If you run any authenticated server, treat the auth section of the RC as required reading rather than a nice-to-have, and test your token validation against it directly. ### Standardized tracing Distributed tracing keys are standardized across SDKs, so requests can be traced across a chain of MCP servers with a common context. With protocol Logging deprecated, this is the sanctioned observability path. Wire it in as you migrate. ## Migration Checklist: Server Authors Work top to bottom. The early items are the ones that break interoperability. - [ ] **Read the RC.** Start from the [2026-07-28 release candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) and note every capability your server implements today. - [ ] **Remove the `initialize` handshake path.** Stop requiring a session as the first message. Treat every request as self-contained. - [ ] **Externalize any session state.** Move per-session memory into an external store (or drop it) so any instance can serve any request. See the [stateless guide](/blog/mcp-stateless-migration-guide-2026) for patterns. - [ ] **Support `Mcp-Method` header routing.** Make sure your server and any gateway in front of it route on headers, not body inspection or a session ID. - [ ] **Add `ttlMs` to `tools/list`.** Declare how long your tool list is cacheable so clients and infra stop refetching it. - [ ] **Validate tool schemas against JSON Schema 2020-12.** Fix anything a strict validator rejects. - [ ] **Audit Roots, Sampling, and Logging usage.** Find every place you depend on them and plan replacements before their lifecycle ends. - [ ] **Harden auth.** Bring OAuth/OIDC token and issuer validation in line with the RC. Do not ship an authenticated server on the old rules. - [ ] **Migrate Tasks.** If you had long-running operations, move them onto the Tasks extension with resumable state. - [ ] **Adopt standardized tracing.** Replace protocol Logging with the standardized trace context keys. - [ ] **Evaluate MCP Apps.** If richer output helps your product, prototype a server-rendered surface. - [ ] **Test against the RC and confirm your SDK's support.** Do not assume your SDK version already speaks 2026-07-28. ## Migration Checklist: Client and Host Integrators If you build the agent, IDE, or host that connects to MCP servers, your job is different: you decide which spec versions to negotiate and how gracefully you degrade. For how MCP fits into a coding-agent workflow, see the [Claude Code agent teams playbook](/blog/claude-code-agent-teams-subagents-2026). - [ ] **Stop sending `initialize` as a required step.** Issue self-contained requests against 2026-07-28 servers. - [ ] **Do not assume a pinned server instance.** Design for any request reaching any instance behind a load balancer. - [ ] **Honor `ttlMs` on `tools/list`.** Cache the tool list for the declared window instead of refetching per connection. - [ ] **Update your auth flow.** Align client registration and token handling with the hardened OAuth/OIDC requirements. - [ ] **Plan for deprecated capabilities.** If your host relies on Roots, Sampling, or Logging, build the replacement path now. - [ ] **Add MCP Apps rendering, safely.** If you will surface server-rendered UI, render it in a sandbox and treat it as untrusted. - [ ] **Support Tasks polling.** Handle long-running operations through the Tasks extension's resumable model. - [ ] **Decide your compatibility window.** For an established user base, negotiate both the old and new versions through a transition period rather than cutting over overnight. - [ ] **Read the security guidance.** Fold the [NSA/DoD recommendations](https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF) into how your host trusts and isolates servers. ## Who Is Affected and How Urgent Not everyone needs to move at the same speed. Use this to triage. | Situation | Urgency | Why | |-----------|---------|-----| | Building a new MCP server or client now | High | Target 2026-07-28 from day one. No reason to write against the old core. | | Production server with heavy session state | High | The stateless core is a structural change and needs real migration work before the deadline. | | Simple stateless server (file reader, API wrapper) | Medium | Mostly SDK updates and header support, but still test against the RC. | | Authenticated server exposed to external users | High | Auth hardening plus the security guidance make this the riskiest surface to leave stale. | | Host or IDE integrating third-party servers | Medium to high | You set the compatibility window, but old and new servers will not silently interoperate. | | Server built on Roots, Sampling, or Logging | Medium | Not broken on day one, but on a removal clock. Plan the replacement. | | Using a community SDK | Depends | Gate your timeline on when your SDK maintainer ships 2026-07-28 support. | The blunt version: if you maintain session state or run authenticated servers, treat this as high priority with less than four weeks of runway. If your server is already stateless and unauthenticated, you have more slack, but you still need to validate against the RC and update your SDK. ## Security Context The timing matters. On June 2, 2026, the NSA and DoD published [security guidance for MCP](https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF). When defense agencies publish protocol-specific guidance, it is a signal that MCP is now load-bearing infrastructure connecting agents to real systems, and that the threat model deserves attention. Read the two together. The 2026-07-28 auth hardening and the security guidance point the same direction: MCP servers sit in front of sensitive data and actions, so authorization, isolation, and trust boundaries are now core engineering concerns, not afterthoughts. If you adopt MCP Apps, remember that server-rendered UI is untrusted content and must be sandboxed. Migrating is the moment to also close security gaps, not just chase the spec. ## Frequently Asked Questions ### When does the 2026-07-28 MCP spec take effect? The final specification is dated July 28, 2026. The release candidate is available now, so the window between the RC and the final date is your validation and migration runway. As of early July that is less than four weeks. ### Is this really the biggest MCP change since launch? The maintainers describe it as the largest revision since launch, and the scope backs that up: a rewritten stateless core, three deprecated features, stricter tool schemas, hardened auth, and two graduated extensions in one dated release. See the [release candidate announcement](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/). ### What breaks if I do nothing? Servers that require the old `initialize` handshake will not interoperate cleanly with clients that speak 2026-07-28, and vice versa. Gateways that route on a session ID, tool schemas that only pass loose validation, and authenticated flows on the old rules are the most likely to fail. Features you built on Roots, Sampling, or Logging keep working for now but are on a removal clock. ### Are Roots, Sampling, and Logging removed immediately? No. They are deprecated, which starts a formal lifecycle rather than deleting them on release day, per the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines). Treat deprecation as a scheduled removal and plan replacements now instead of waiting for the cutoff. ### Do I have to adopt MCP Apps and Tasks? No. They are extensions you opt into, not mandatory core. Adopt MCP Apps if richer server-rendered output helps your product, and adopt Tasks if you run long-running operations. The stateless core is the part everyone must reckon with; the extensions are opportunistic. ### What is the fastest safe migration order? Fix interoperability first (drop the `initialize` requirement, externalize state, support header routing), then correctness (validate schemas against JSON Schema 2020-12), then security (harden OAuth/OIDC), then adopt extensions. The role-specific checklists above are ordered that way. ### Where is the code-level detail for the stateless change? The companion [MCP stateless migration guide](/blog/mcp-stateless-migration-guide-2026) walks through the transport change with before-and-after code, including how to externalize session state for horizontal scaling. ## Sources - [MCP 2026-07-28 Release Candidate announcement](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) - [2026 MCP Roadmap](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/) - [MCP SEP guidelines (specification change process)](https://modelcontextprotocol.io/community/sep-guidelines) - [NSA/DoD MCP security guidance (PDF)](https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF) - [JSON Schema 2020-12 specification](https://json-schema.org/specification-links#2020-12)

OpenAI Codex in 7 Minutes: The Desktop App, Plan Modes, and Multi-Agent Workflows

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [Watch: OpenAI Codex in 7 Minutes](https://www.youtube.com/watch?v=2OnmwXm6N4U) | The full walkthrough on the DevDigest channel | | [OpenAI Codex](https://openai.com/codex) | Official product page for Codex | ## What This Video Covers **OpenAI Codex in 7 Minutes** showcases OpenAI's Codex desktop app. The video walks through plan and goal modes, plugins, multi-agent workflows, and a UI annotation demo, presenting the desktop app as OpenAI's strongest coding product to date. This post is a companion to the video above. Watch the seven-minute tour for the live demos, then use the links here to place each feature in context. ## The Idea in One Line Codex is moving from a single prompt-and-respond loop to a desktop app with modes, plugins, and multiple agents. The pitch is less "chat with a model" and more "run a coding environment where the agent has structure to work inside." ## Why It Matters A few things stand out from the tour: - **Plan and goal modes add structure.** Instead of one long instruction, you can point Codex at an outcome and let it plan the steps. This is the same direction covered in [Codex goal mode versus Claude managed outcomes](/blog/codex-goal-vs-claude-managed-outcomes-practical-differences). - **Plugins extend what it can reach.** A plugin surface means the app is meant to connect to your tools, not live in a sandbox by itself. - **Multi-agent workflows split the work.** Running more than one agent lets you break a task into parallel pieces, which changes how large jobs get done. - **UI annotation closes the loop.** Annotating the interface gives the agent a way to act on what is actually on screen. ## Where It Fits The desktop app is one part of a fast-moving product. For the fundamentals, the [OpenAI Codex guide](/blog/openai-codex-guide) covers the basics, and [Codex Record & Replay](/blog/codex-record-and-replay) shows another recent feature that turns recorded tasks into reusable skills. If you want recurring work handled automatically, [Codex automations for recurring engineering work](/blog/codex-automations-recurring-engineering-work) is the next stop. Weighing tools? [Codex vs Claude Code (June 2026)](/blog/codex-vs-claude-code-june-2026) compares them directly. ## Getting Started The workflow the video demonstrates is to open the desktop app, pick plan or goal mode for a real task, and let the agent work while you review. Start small so you can see how the modes and plugins behave before handing over anything large. Watch the full **OpenAI Codex in 7 Minutes** tour above, then try plan mode on a task of your own and see how the desktop app changes your loop.

Point Your Agent at Developers Digest

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Most of what this site does, it now does for your agent instead of just for you. As of today, developersdigest.tech ships a Model Context Protocol endpoint. Any MCP-capable harness - Claude Code, Claude Desktop, Cursor, or your own client - can connect with an API key and call the platform's tools directly. No screen scraping, no copy and paste, no glue code. This is the applied version of an idea we keep coming back to: the useful unit of a developer site is not the page a human reads, it is the tool an agent can call. So we exposed the tools. ## What shipping an MCP endpoint actually means MCP is an open standard for connecting AI applications to external tools and data. A server publishes a set of tools with typed inputs. A client discovers those tools and calls them during a task. The value is that the interface is uniform: once a harness speaks MCP, every MCP server it connects to looks the same, so there is no per-integration wiring. The endpoint lives at `/api/mcp` and is served over streamable HTTP. Every call authenticates with a `dd_live_` API key sent as a bearer token. There is no session on the transport, so the key is how each tool resolves who is calling and which credit balance to check. Point a compliant client at the URL, give it the key, and the full tool suite shows up in that client's tool list. ## The tool suite The endpoint exposes the same credit-metered capabilities as the platform REST API, plus a set of free tools built specifically for agents. **Media generation (credit-metered).** `generate_image` produces an image from a text prompt via Fal.ai. `generate_voice` turns text into speech through the AI Gateway. Both persist the result into your Creative Studio gallery, return a durable storage URL and a dashboard link, and charge only on success. If generation fails, you are not charged. **The libraries, served on demand.** This is the part we are most interested in. Three registries are exposed as tools: - `list_skills` / `get_skill` - a registry of vetted, copyable `SKILL.md` files that follow the Agent Skills standard. Your agent lists what is available, then fetches the full markdown ready to save to `.claude/skills//SKILL.md`. - `list_agents` / `get_agent` - copyable subagent definitions, YAML frontmatter plus system prompt, ready to drop into `.claude/agents/`. - `list_design_systems` / `get_design_md` - machine-readable `DESIGN.md` contracts an agent can build against so generated pages match a real visual system, including color swatches and a gradient policy. **Memory that persists.** `save_memory`, `list_memories`, and `search_memories` give an agent durable per-caller notes and links stored server side. They survive across sessions and machines, so an agent can write down context on one run and recall it on the next, even from a different computer. **Content search.** `search_content` searches the Developers Digest index - blog posts, guides, tools, videos, courses - and returns titles, descriptions, and URLs. **Daily brief.** `get_daily_brief` returns the latest Developers Digest Daily Brief as text. **Token counting.** `count_tokens` counts tokens in a string using the o200k_base encoding, so an agent can budget context before making an expensive call. **Balance.** `get_balance` returns the caller's current credit balance and owner status. ## Skills as a service The library tools deserve a second look, because they change a workflow most builders do by hand. Today, when you want an agent to have a capability, you find a good `SKILL.md`, you paste it into your project, and it goes stale the moment the underlying tool changes. The registry flips that. Your agent calls `list_skills`, finds the relevant one, calls `get_skill`, and saves the current version into its own config directory at runtime. The skill is fetched fresh, from a vetted source, at the moment it is needed. The same pattern holds for agent definitions and design contracts. That is the pitch: skills, subagents, and design systems delivered as a service your agent pulls from, instead of static files you maintain by copy and paste. It is deliberately zero credits. We would rather agents adopt these widely than meter them. ## How to connect First, create an API key in the dashboard at `/dashboard/keys`. It will start with `dd_live_`. **MCP client (mcp.json).** Add the server to your client's MCP config. The shape most harnesses accept: ```json { "mcpServers": { "developers-digest": { "url": "https://www.developersdigest.tech/api/mcp", "headers": { "Authorization": "Bearer dd_live_your_key_here" } } } } ``` Reload the client and the Developers Digest tools appear alongside your other MCP servers. **The dd CLI.** If you would rather script against the REST surface directly, the repo ships a small zero-dependency CLI. It needs Node 18 or newer and no packages to install. ```bash export DD_API_KEY=dd_live_your_key_here node cli/dd.mjs image "a hard-edged neutral workflow board" --size landscape node cli/dd.mjs voice "Welcome to Developers Digest." --voice nova --out intro.mp3 node cli/dd.mjs gallery --limit 10 node cli/dd.mjs balance ``` Each command prints the result URL, the model used, credits spent, remaining balance, and a link back to your dashboard studio. ## What is free and what is metered We would rather be honest about this than surprise anyone. **Free (0 credits):** `count_tokens`, `search_content`, `get_daily_brief`, `get_balance`, every memory tool, and every library tool. Usage is still attributed to your key, and rate limits apply, but nothing is charged. **Credit-metered:** `generate_image` costs 5 credits, `generate_voice` costs 2 credits, and both charge only on a successful generation. If you run out of credits mid-task, the tool returns a clear error pointing you to `/pricing` rather than failing silently. Credits are a universal balance across the platform, so one top-up works everywhere the key does. There is no free tier on the paid actions and no metering on the free ones. That split is the whole billing model. ## What is next The obvious next steps are more tools on the same endpoint. The Model Pricing API, a sourced dataset of frontier model pricing and capability facts, already exists as a REST route and is a natural MCP tool. The library registries will grow as we publish more vetted skills, agents, and design contracts. And because every tool call is attributed to a key, the usage data tells us which capabilities agents actually reach for, which is the best signal we have for what to build next. If you build something with the endpoint, we want to see it. ## Frequently Asked Questions ### Do I need a credit balance just to connect? No. Connecting requires a `dd_live_` API key, but the free tools - content search, token counting, the daily brief, memory, and the entire skill, agent, and design library - cost nothing. You only need credits for image and voice generation, which cost 5 and 2 credits and charge only on success. ### Which MCP clients work with this? Any client that speaks MCP over streamable HTTP with bearer-token auth. That includes Claude Code, Claude Desktop, Cursor, and custom clients built on the MCP SDK. Add the server URL and your key to the client's MCP config and the tools appear in its tool list. ### What is the difference between the MCP endpoint and the dd CLI? They are two front doors to the same platform. The MCP endpoint lets an agent discover and call tools inside a task automatically. The dd CLI is a small script you run yourself against the REST surface for media generation and gallery access. Both authenticate with the same `dd_live_` key. ### How is "skills as a service" different from just copying a SKILL.md? A copied file goes stale and you maintain it. The library tools fetch the current, vetted version at runtime and save it straight into your agent's config directory. Your agent pulls the skill when it needs it instead of you pasting a snapshot that drifts out of date. ## Sources - [Developers Digest library](https://www.developersdigest.tech/library) - the skill, agent, and design registries served by the MCP endpoint - [Developers Digest paths](https://www.developersdigest.tech/paths) - guided learning paths across the platform - [API docs](https://www.developersdigest.tech/api-docs) - the REST surface behind the tools - [Model Context Protocol](https://modelcontextprotocol.io) - the open standard the endpoint implements

Skills Delivered Over MCP: Why Progressive Disclosure Is the Missing Piece of Both Standards

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Two standards showed up in the last year that most people file under different problems. Anthropic's [Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) gave us `SKILL.md`, a format for packaging what an agent should know. The [Model Context Protocol](https://modelcontextprotocol.io) gave us a wire format for what an agent can call. Skills are usually described as files on disk. MCP is usually described as servers on the network. They look like they solve unrelated things. They do not. They solve two halves of the same thing, and the interesting move is to run one on top of the other. The thesis of this post is simple: the next useful shape is skills delivered over MCP, and the reason it works is that both standards are really about the same underlying idea. One of them just implements it and the other one forgot to. ## The two halves Start with what each standard is actually good at. `SKILL.md` solved knowledge packaging. A skill is a folder with a markdown file that carries a name, a one-line description, and a body of instructions. The format's real contribution is not the file, it is the loading discipline around it, called progressive disclosure. Anthropic describes it as three stages: discovery, where the agent sees only each skill's name and description; activation, where a matching task pulls the full `SKILL.md` body into context; and execution, where the agent optionally reads bundled reference files or runs bundled scripts as the work demands. The point of the design is that the agent pays context cost in proportion to what the task needs. A hundred skills can sit in the catalog for the price of a hundred one-line descriptions, and the ten-thousand-word reference only loads when someone actually reaches for it. MCP solved capability transport. A server publishes tools with typed inputs, any compliant harness discovers them, and calls them the same way regardless of who wrote the server. That uniformity is genuinely valuable. It is the reason a single harness can talk to a database, a calendar, and an image model without three bespoke integrations. But MCP's discovery model is flat. The classic pattern is `tools/list`, which returns every tool a server offers, each with its full JSON schema, all at once, before the agent has done anything. Connect a handful of rich servers and the tool definitions alone can run into tens of thousands of tokens sitting in context on every single request, most of it describing tools this particular task will never touch. So one standard is disciplined about context and vague about transport, and the other is excellent at transport and profligate with context. That asymmetry is the whole opportunity. ## The combination Picture an MCP server whose tools are not a flat menu but a skill directory expressed as three tools: - `list_skills` returns the cheap index. Names, one-line descriptions, nothing else. This is the discovery stage, delivered over the wire. - `get_skill` takes a slug and returns that skill's body plus a manifest of its bundled files. This is activation. - `get_skill_file` takes a slug and a path and returns one reference file on demand. This is execution. That is progressive disclosure, rebuilt on MCP's transport. The agent pays for the index, then for one body, then for the specific files it needs, in exactly the escalating way it would if the skills lived on its own disk. The difference is that the skills no longer have to live on its own disk. They can be served from anywhere, versioned like an API, updated centrally, access-controlled, and shared across every agent and every machine that holds a key. You get the context economics of local skills with the distribution model of a web service. The reason this is not a hack is that MCP already contains the primitive it needs. A tool can return a manifest of resources instead of a wall of content, and the agent can choose to fetch them. Nobody was forcing the flat `tools/list` dump. It was just the obvious first thing to build, the same way the obvious first thing to do with a new skill is to paste everything into one file. ## Why this is where things are already heading This is not a prediction so much as a reading of what has already shipped. Skills themselves went multi-file. The [public skills repository](https://github.com/anthropics/skills) and the entries in Claude's own directory are not single files. They are folders with `SKILL.md` at the root and `reference/`, `scripts/`, and `assets/` alongside it. Anthropic's guidance is explicit: when a `SKILL.md` gets unwieldy, split the detail into separate files and point at them, so rarely-used paths only cost tokens when they are actually taken. The moment a skill is a directory rather than a document, "serve it over a protocol" stops being exotic and becomes an obvious packaging question. Anthropic ships an `mcp-builder` skill, which is a skill about building MCP servers. The two standards are already being composed in the official tooling; the vocabulary of one is used to teach the other. Anthropic's own framing puts it well: MCP is the professional kitchen with the equipment and ingredients, and skills are the recipes. Recipes are worth distributing, and the kitchen is how you distribute them. And the harness makers are converging on the same context discipline from the tools side. Look at how modern agent harnesses handle large tool sets: instead of loading every tool schema up front, they expose a search or deferred-loading step. The agent gets a lightweight list of tool names, then fetches the full schema for a tool only when it decides to use it. That is progressive disclosure applied to tools rather than to knowledge. It is the exact same idea arriving from the opposite direction. When both the skill people and the tool people independently rediscover "show the index first, load the body on demand," that is not a coincidence. That is the shape of the problem. ## What we built We run this on our own site. `developersdigest.tech` exposes an MCP endpoint at `/api/mcp`, served over streamable HTTP, authenticated with a `dd_live_` API key sent as a bearer token. Point any MCP-capable harness at the URL, give it the key, and the tool suite shows up. The connection story has its own write-up in [Point Your Agent at Developers Digest](/blog/point-your-agent-at-developers-digest); this post is about the shape of the library tools specifically. The skill library is exposed exactly as the pattern above. The catalog you can browse by hand at [/library](/library) is the same catalog an agent reaches through the tools. `list_skills` returns the index, `get_skill` returns a body plus manifest, and files come down individually. A discovery call looks like this: ```json { "method": "tools/call", "params": { "name": "list_skills", "arguments": { "query": "changelog" } } } ``` and comes back as a lean index, one line per skill, no bodies: ```json { "skills": [ { "slug": "release-notes", "description": "Turn a merged PR list into customer-facing release notes." } ] } ``` Only when the agent commits to a skill does it spend context on the body: ```json { "method": "tools/call", "params": { "name": "get_skill", "arguments": { "slug": "release-notes" } } } ``` which returns the full `SKILL.md` ready to save to `.claude/skills/release-notes/SKILL.md`, plus a manifest naming the reference files the agent can pull later with `get_skill_file`. The full endpoint reference lives at [/docs/api](/docs/api). The design goal was that a skill authored for the disk and a skill served over the wire are the same artifact. You should be able to move one to the other without rewriting it. ## How to write a SKILL.md that survives this The pattern only pays off if the skills are authored for it. A good `SKILL.md` over MCP looks like a good `SKILL.md` on disk, because the loading model is identical. Three habits matter. Write the description like it is the only thing the agent will read, because at discovery time it is. It should say when to reach for this skill, in the user's words, not what the skill contains in yours. "Use when generating customer-facing release notes from merged PRs" beats "Release notes utilities." Keep the body lean and make it point outward with when-to-read guidance. Do not inline the full API table or the edge-case catalog. Reference the file and tell the agent the condition under which it should open it: "For the full field-by-field schema, read `reference/fields.md` only when a field is ambiguous." The agent then loads depth on the specific branch it took, not on all of them. Split mutually exclusive paths into separate files. If the skill handles three formats and any given run touches one, three files cost less than one file, because the agent pulls only the branch it is on. The anti-patterns are the mirror image. Do not dump every reference file into one `get_skill` response; that throws away the entire benefit and turns activation back into the flat dump you were trying to escape. And do not build the fifty-tool flat server, where every schema loads before the agent has decided anything. Fifty tools behind a three-tool skill directory is almost always the better trade. ## What this means for teams Follow this one step past the public catalog and you arrive somewhere useful. A private skill server becomes the internal wiki for your agents. Not a wiki humans read and agents ignore, but a versioned, access-controlled library that every agent in the org discovers the same way, loads on demand, and never has to have copied onto its disk. Your deployment runbook, your incident-response steps, your house style for commit messages, your API conventions, each is a skill, each is one row in an index until the moment an agent needs it, each updated in one place. When you fix the runbook, every agent has the fix on its next `get_skill` call. No redeploy, no re-paste, no drift between what the fleet knows and what is true. That is the version of this I care about, because it is what makes a fleet coherent. When we [ran a fleet of agents for a day to rebuild this site](/blog/coordinating-an-agent-fleet-for-a-day), the thing that held the day together was shared, verifiable context that every agent could reach on the same terms. Skills over MCP is the standardized, distributable form of exactly that. Two standards each solved one half. The combination is the interesting part, and it is already being built in the open, one manifest at a time. The same endpoint later grew to serve the fleet's roles as well as its knowledge, which is the subject of a [later post on Agent Studio](/blog/agent-studio-one-endpoint). ## FAQ ### What is the difference between an Agent Skill and an MCP tool? An Agent Skill is packaged knowledge: a `SKILL.md` file with instructions, plus optional reference files and scripts, loaded through progressive disclosure. An MCP tool is a callable capability with a typed input schema, exposed by a server over a wire protocol. Skills tell an agent how to do something; tools let it act. They compose cleanly, and you can even deliver skills through MCP tools, which is the pattern this post is about. ### What is progressive disclosure in this context? It is loading information in stages so the agent pays context cost only for what a task actually needs. First the agent sees short descriptions, then it pulls the full body of the one skill it chose, then it reads specific reference files on demand. It keeps a large library cheap to hold in context, because most of it stays unread until the moment it is relevant. ### Why not just list every tool with MCP's standard discovery? Flat discovery returns every tool's full schema up front, which can consume tens of thousands of tokens per request describing tools the current task will never call. Expressing a large capability set as a small skill directory, index first and bodies on demand, gives you the same reach at a fraction of the standing context cost. ### Can I use this pattern with harnesses other than Claude Code? Yes. The point of MCP is that any compliant client discovers and calls tools the same way, so a skill directory exposed as `list_skills`, `get_skill`, and `get_skill_file` works from any MCP-capable harness. The skills themselves are plain `SKILL.md` markdown, which is an open format, so nothing about the pattern is tied to a single client. ### How do I try the one running on this site? Point an MCP-capable harness at the `/api/mcp` endpoint with a `dd_live_` API key, then call the library tools. You can browse the same skill catalog by hand at [/library](/library), and the full endpoint reference is at [/docs/api](/docs/api).

Vercel AI Gateway in 10 Minutes: One Key for Every Model

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Most "add a new model" tasks are boring in the worst way. You install another SDK, wire up another API key, learn another auth quirk, and rebuild your fallback logic per provider. [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) collapses that into one key and one endpoint. You reference a model by a plain string like `moonshotai/kimi-k2.5` or `anthropic/claude-opus-4.8`, and the request routes to the right provider. We run production chat through it, so this is the applied version: what it is, how it plugs into the AI SDK, what BYOK and OIDC actually buy you, the tradeoffs worth knowing before you couple to it, and who should reach for it. ## What the AI Gateway actually is The AI Gateway is a single HTTP endpoint (`https://ai-gateway.vercel.sh/v1`) that fronts [hundreds of models](https://vercel.com/ai-gateway/models) from many providers. Instead of one client per provider, you get: - **One key, many models.** Access models from multiple providers with a single API key. - **A unified API.** Switch providers and models with minimal code changes, using `creator/model-name` string ids. - **Automatic retries.** If one provider fails, the gateway can retry the request against another. - **Embeddings.** The same endpoint generates vector embeddings, not just chat. - **Spend monitoring.** Usage and cost are tracked across providers in one place. - **No token markup.** Per the [docs](https://vercel.com/docs/ai-gateway), tokens cost the same as buying from the provider directly, including with Bring Your Own Key. It works with the [AI SDK v5 and v6](https://vercel.com/docs/ai-gateway/getting-started), the OpenAI Chat Completions and Responses APIs, and the Anthropic Messages API, so most existing code paths have a compatible entry point. ## The 10-minute version with the AI SDK The fastest path is the AI SDK, where the gateway is the default provider when you pass a model as a plain string. Set one environment variable: ``` AI_GATEWAY_API_KEY=your_key_here ``` Then reference any model by string. No provider import, no per-provider client: ``` import { generateText } from 'ai'; const { text } = await generateText({ model: 'anthropic/claude-opus-4.8', prompt: 'What is the capital of France?', }); ``` Swapping models is a one-line change. `anthropic/claude-opus-4.8` becomes `moonshotai/kimi-k2.5` or `openai/gpt-5.5` and nothing else moves. When you want explicit control, the `gateway()` provider instance gives you the same routing with configurable base URLs and env vars, which matters behind a corporate proxy. Prefer the OpenAI SDK? Point its `base_url` at the gateway and keep your existing code: ``` from openai import OpenAI client = OpenAI( api_key=os.getenv('AI_GATEWAY_API_KEY'), base_url='https://ai-gateway.vercel.sh/v1' ) ``` ## The gotcha we hit in production: the Responses API default Here is the applied lesson that is not obvious from the quickstart. As tooling standardizes on OpenAI's newer [Responses API](https://vercel.com/docs/ai-gateway/sdks-and-apis/responses), many OpenAI-compatible clients now default to it rather than the older Chat Completions shape. That is fine when you talk to OpenAI. It breaks when you point the same client at an upstream that only serves Chat Completions. Calling Moonshot's endpoint directly, for example, we hit exactly this shape mismatch: the client spoke Responses, the upstream spoke Completions, and requests failed in ways that looked like our bug. Routing through the gateway is what made this stop being our problem. The gateway normalizes the request and response shapes across providers, so a single client format reaches models that natively expose different APIs. If you have ever burned an afternoon on a "why does this provider return a different envelope" bug, this abstraction is the quiet reason to adopt a gateway even before you care about routing or spend. ## BYOK: use your own provider keys Bring Your Own Key lets you attach your own provider credentials at the team level. It is useful when you: - Have existing agreements and want enterprise pricing or provider credits. - Need private access to features that require your own credentials. - Want zero additional fee (BYOK requests carry no markup). The reliability twist worth knowing: if your own credentials fail on a request, the gateway can retry with system credentials so the call still succeeds, and that fallback usage is billed against your gateway credits. See the [BYOK docs](https://vercel.com/docs/ai-gateway/authentication-and-byok/byok) for setup. ## OIDC: no keys to manage on Vercel For apps deployed on Vercel, you do not have to manage a gateway API key at all. An [OIDC token](https://vercel.com/docs/ai-gateway/authentication-and-byok/oidc) is automatically available as `VERCEL_OIDC_TOKEN`, so there is nothing to rotate and no secret to leak. A common pattern reads OIDC in production and falls back to a key locally: ``` // OIDC on Vercel, API key locally const apiKey = process.env.AI_GATEWAY_API_KEY || process.env.VERCEL_OIDC_TOKEN; ``` There is a related operational nicety: standard API keys never expire unless revoked, and when a teammate leaves, Vercel deactivates the keys they created. For automation that should not be tied to a person, OIDC is the cleaner path. ## Pricing model Per the [pricing docs](https://vercel.com/docs/ai-gateway/pricing), every team gets a free tier and a paid tier: - **Free tier:** a small monthly credit included, provider list rates with zero markup, and per-model rate limits that are lower than paid. Exceed a limit and you get a `429` to retry after a short wait. BYOK is not available on free. - **Paid tier:** pay-as-you-go with purchased credits, higher rate limits, BYOK available, and no commitment. Token pricing is still provider list rate with zero markup. The headline is that the gateway does not mark up tokens. It monetizes through purchased credits and a handful of optional capabilities (things like team-wide provider allowlists or zero-data-retention) that carry small per-request fees only when you enable them. Verify current numbers on the [pricing page](https://vercel.com/docs/ai-gateway/pricing) before you model costs, since credit and capability details change. ## The honest tradeoffs A gateway is not free of cost in the engineering sense. Weigh these before coupling to it: - **A network hop.** Every request goes through Vercel's infrastructure instead of straight to the provider. For most chat and agent workloads the added latency is small, but latency-critical paths should measure it, not assume it. - **Vendor coupling.** You are standardizing on Vercel's routing layer and model catalog. The mitigation is real: BYOK and OpenAI/Anthropic-compatible endpoints mean your provider relationships and request shapes stay portable, so leaving is a base-URL change, not a rewrite. - **Less low-level control.** If you need a bleeding-edge provider parameter the day it ships, a direct SDK call can expose it before a gateway does. Gateways trade a little immediacy for a lot of uniformity. - **Another dependency in the path.** The gateway adds reliability through cross-provider retries, but it is also one more system that can have an incident. Keep a direct-call fallback for your most critical route. When any of these dominate, go direct for that specific path and keep the gateway for everything else. It does not have to be all-or-nothing. ## Who should use it Reach for the AI Gateway when you: - Call more than one provider, or expect to, and do not want an SDK-and-key sprawl. - Want one place to watch spend and set budgets across models. - Need provider fallbacks without hand-rolling retry logic per provider. - Deploy on Vercel and would rather use OIDC than manage keys. - Keep hitting request-shape mismatches between OpenAI-compatible clients and upstreams. Stay direct when you have a single provider you will never leave, a latency budget so tight that a proxy hop is unacceptable, or a need for provider-specific features the moment they ship. For most teams building AI features in 2026, the gateway removes more friction than it adds, and the migration cost is genuinely a few lines. ## FAQ ### What model id format does the AI Gateway use? Models are referenced as `creator/model-name` strings, for example `anthropic/claude-opus-4.8`, `moonshotai/kimi-k2.5`, or `openai/gpt-5.5`. In the AI SDK, passing that string as the `model` automatically routes through the gateway. See the [models and providers docs](https://vercel.com/docs/ai-gateway/models-and-providers). ### Does the gateway mark up token costs? No. Per Vercel's [docs](https://vercel.com/docs/ai-gateway), tokens are billed at provider list rates with zero markup, including with BYOK. The paid tier is funded through purchased credits rather than a per-token surcharge. ### Do I need an API key if I deploy on Vercel? Not necessarily. Vercel deployments get an [OIDC token](https://vercel.com/docs/ai-gateway/authentication-and-byok/oidc) as `VERCEL_OIDC_TOKEN` automatically, so there is nothing to rotate. Locally you fall back to an `AI_GATEWAY_API_KEY`. ### Can I use my own provider keys? Yes, through [BYOK](https://vercel.com/docs/ai-gateway/authentication-and-byok/byok) on the paid tier. Your credentials are configured at the team level, and if they fail on a request the gateway can retry with system credentials, billed to your credits. ### Does it work with the OpenAI or Anthropic SDKs? Yes. The gateway is compatible with OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages, plus the AI SDK v5 and v6. Point the base URL at `https://ai-gateway.vercel.sh/v1` and keep most existing code. ### Can I route text-to-speech or audio through it? Today the gateway focuses on text generation and embeddings. For text-to-speech you generally still call the provider directly. See our [TTS API guide](/blog/best-tts-apis-for-developers-2026) for that side of the stack. ## Sources - [Vercel AI Gateway overview](https://vercel.com/docs/ai-gateway) - [Getting started with the AI Gateway](https://vercel.com/docs/ai-gateway/getting-started) - [Models and providers](https://vercel.com/docs/ai-gateway/models-and-providers) - [Authentication and OIDC](https://vercel.com/docs/ai-gateway/authentication-and-byok/authentication) - [Bring Your Own Key (BYOK)](https://vercel.com/docs/ai-gateway/authentication-and-byok/byok) - [AI Gateway pricing](https://vercel.com/docs/ai-gateway/pricing) - [OpenAI Responses API through the gateway](https://vercel.com/docs/ai-gateway/sdks-and-apis/responses)

Webernetes: Kubernetes Ported to the Browser in TypeScript

Developers Digest — Wed, 01 Jul 2026 00:00:00 GMT

Sam Rose, a Senior Developer Educator at ngrok, spent two months porting Kubernetes to TypeScript to run entirely in the browser. The result is [Webernetes](https://github.com/ngrok/webernetes) - 100,000 lines of code across 629 files, weighing in at 140KB gzipped. The project is not for running production workloads. It is for teaching how Kubernetes works. ## What Was Actually Ported Rather than compiling the Go codebase to WebAssembly (which would have blown past 500KB), Rose rewrote key components: - **Kubelet functionality** - Pod lifecycle management and probing - **Controllers** - Pod scheduler, namespace controller, kube-proxy, deployment controller - **Container Runtime Interface (CRI)** - Browser-based container execution - **Container Network Interface (CNI)** - Simulated network for pod-to-pod communication - **Cluster API** - TypeScript interface for applying manifests and watching resources What is *not* included: ConfigMaps, Secrets, pod resource limits, persistent volumes, and real container image support. The registry is browser-only. ## Custom Image Format Since Docker Hub images cannot run in a browser, Webernetes uses a TypeScript API for defining container images with built-in HTTP server capabilities: ```typescript const myContainer = new WebContainer({ image: 'my-app', ports: [8080], start: async (ctx) => { ctx.serve(8080, (req) => new Response('Hello from Webernetes')); } }); ``` This is enough to demonstrate pod-to-pod networking, deployments, and service discovery without real container runtimes. ## The Test Suite The legitimacy check for any port is whether it actually behaves like the original. Rose addressed this with two test layers: 1. **204 integration tests** comparing behavior against real k3s clusters using identical APIs 2. **1,855 unit tests** ported from the Kubernetes Go codebase Both suites run against webernetes and k3s, asserting the same behavior. ## The LLM Development Story The [blog post](https://ngrok.com/blog/i-ported-kubernetes-to-the-browser) is upfront about methodology: > Almost all of the webernetes code was authored by LLMs. Rose argues this is not slop because of two practices: 1. **Every line was reviewed.** LLM output was treated as draft code, not final. 2. **Behavior tests against real clusters.** The tests do not just check "does it compile" - they check "does it match what k3s does." This framing - AI generates, human reviews, tests verify against ground truth - is one model for using AI coding tools responsibly in larger projects. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48738985) was generally positive, with interest in both the project and the development process. On the project itself, one commenter noted: "I see this as a fun learning and experimental tool. For a while I have wanted to make a web page where you can do service load balancing and queuing simulations so this would be a great basis for it." Others appreciated the educational angle: "As someone who has authored Kubernetes educational content in a past role, I can definitely see the appeal of building something like this." On the AI development process, one commenter observed: "This feels like the right way to frame LLM-assisted engineering. AI can generate a shocking amount of code, but the actual value is in the review discipline, and tests around it." The complexity question came up predictably, with jokes about Kubernetes overhead. But one commenter made a more nuanced point: "There's an interesting argument to make that something like kube is the necessary complexity level for the kinds of tasks that kube is intended to accomplish, ala Fred Brooks' rule about essential complexity vs accidental complexity." ## Use Cases The demo at [webernetes-demo.ngrok.app](https://webernetes-demo.ngrok.app/) lets you interact with a cluster in your browser. Practical applications include: - **Interactive tutorials** - No cloud credits or local setup required - **Conceptual demonstrations** - Show how pods, services, and deployments interact - **Sandbox experimentation** - Try kubectl commands without consequences - **Educational content** - Embed working clusters in documentation It is explicitly *not* for cluster operations, production workloads, or anything requiring real container images. ## Technical Details | Metric | Value | |--------|-------| | Lines of code | ~100,000 | | Files | 629 | | Gzipped size | ~140KB | | Unit tests | 1,855 | | Integration tests | 204 | | Development time | 2 months (April-June 2026) | | License | Open source (ngrok) | ## The Broader Point Webernetes is interesting on two levels: 1. **As an educational tool** - It solves the "I need a cluster to teach Kubernetes" problem without requiring cloud infrastructure. 2. **As an AI development case study** - The combination of LLM code generation, human review, and behavioral testing against ground truth is a pattern worth studying. The project ships with documentation on how to extend it with custom controllers and workloads, making it useful for anyone building Kubernetes educational content. ## Sources - [Webernetes GitHub Repository](https://github.com/ngrok/webernetes) - Source code and documentation - [Blog Post: I Ported Kubernetes to the Browser](https://ngrok.com/blog/i-ported-kubernetes-to-the-browser) - Full technical writeup by Sam Rose - [Webernetes Demo](https://webernetes-demo.ngrok.app/) - Interactive browser demo - [Hacker News Discussion](https://news.ycombinator.com/item?id=48738985) - Community discussion with 80+ comments --- **Last updated:** July 1, 2026

Claude Code Is Steganographically Marking Requests

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

**Last updated:** June 30, 2026 A developer inspecting the Claude Code binary (version 2.1.196) discovered that the tool silently embeds classification signals into system prompts before sending them to the API. The technique uses unicode character substitutions and date format changes to mark requests based on user timezone, domain, and whether the API endpoint contains keywords associated with competing AI labs. The post hit the top of Hacker News with 350+ points and 100+ comments in a few hours, with discussion ranging from "this is reasonable anti-distillation defense" to "this is malware-adjacent behavior for a developer tool." ## What the Researcher Found According to the blog post at thereallo.dev, the Claude Code binary contains obfuscated functions that conditionally modify the date string sent to the model. The obfuscation uses XOR encryption (key: 91) combined with base64 encoding. The decoded keyword list includes: deepseek, moonshot, minimax, zhipu, baichuan, stepfun, 01ai. Domain lists contain Chinese tech companies and proxy/reseller services. Four apostrophe variants signal different detection states: | Character | Unicode | Meaning | |-----------|---------|---------| | `'` | Standard | Baseline (no triggers) | | `'` | U+2019 | Known domain detected | | `ʼ` | U+02BC | Lab keyword detected | | `ʹ` | U+02B9 | Both triggered | Date format switches from `YYYY-MM-DD` to `YYYY/MM/DD` for users in Asia/Shanghai or Asia/Urumqi timezones. The markers are invisible in normal use - they appear in innocuous sentences like "Today's date is..." where the apostrophe variant encodes the classification. ## What HN Is Saying The thread at [Hacker News](https://news.ycombinator.com/item?id=48734373) shows a split community. **The "this is reasonable" camp** argues Anthropic has legitimate reasons to detect distillation and reselling: > "Combating resellers and distillation seems like a very difficult problem indeed. Interesting to me is that these techniques mentioned in the article are just like anti-observation techniques used by some of the more sophisticated malware out there, however defeating them is pretty trivial." - LPisGood Several commenters noted that this is similar to how content providers try to detect bot scrapers, and that sophisticated actors will simply patch the binary anyway. **The "this is concerning" camp** has several objections: 1. **Undisclosed behavior in a trust-requiring tool.** Claude Code asks for extensive filesystem and terminal access. Users expect transparency about what the tool does with their environment. 2. **Timezone-based classification.** Marking requests from specific timezones (Asia/Shanghai, Asia/Urumqi) raises questions about what happens to those requests downstream. 3. **Obfuscation suggests intentional hiding.** The XOR encryption and base64 encoding indicate Anthropic did not want this behavior to be easily discovered. One commenter captured the sentiment: "Claude code does feel very malwarey to be honest. They have been like that from the start." Others pointed out that if Anthropic wanted to collect this telemetry, transparent logging would be more appropriate than hidden classification signals. **The practical responses** came from developers who are building their own harnesses: > "I used Claude Code for a month because my boss gifted me a sub and wanted me to try it. I used that month to complete a work project and then beef up my personal harness so I'd never have to deal with Anthropic (and these sorts of shenanigans) again." - wolttam Multiple commenters mentioned self-hosting DeepSeek V4 Flash on local hardware as an alternative that avoids these concerns entirely. ## Why This Matters for Developers The core tension here is that Claude Code is a developer tool that requires significant trust - you give it access to run shell commands, read and write files, and interact with your entire development environment. When that tool contains undisclosed fingerprinting mechanisms, it undermines the trust relationship. **Three practical implications:** 1. **Requests may be routed differently.** If Anthropic is classifying requests, they could potentially route marked requests to different models, apply different rate limits, or flag accounts for review. Several HN commenters speculated about output poisoning or compute throttling, though there is no evidence of this yet. 2. **The markers are trivially defeatable.** Any sophisticated actor trying to distill Claude's outputs would simply patch the binary. As one commenter noted: "Defeating a single fingerprinting technique once is easy. Defeating all of the techniques all the time is hard." But this cuts both ways - the feature mostly catches normal developers doing legitimate things, not the actors it is ostensibly designed to stop. 3. **This is probably not the only fingerprint.** If Anthropic is investing engineering effort in one steganographic technique, they likely have others. The obfuscation suggests they anticipated discovery eventually. ## The Broader Context This discovery comes amid ongoing debates about model distillation, where smaller models are trained on outputs from larger models. OpenAI, Anthropic, and Google have all expressed concerns about competitors using their APIs to generate training data. The legality of distillation varies by jurisdiction and use case. API terms of service typically prohibit it, but enforcement is difficult. Techniques like prompt watermarking and output fingerprinting are one approach to detection. From Anthropic's perspective, defending against distillation and unauthorized reselling is a reasonable business interest. The question is whether the implementation - hidden classification signals that are invisible to users - is the right approach for a developer tool that depends on user trust. Several commenters suggested that explicit, opt-in telemetry would achieve the same goals without the trust erosion. Others noted that Anthropic already collects substantial data through normal API logging, so the additional steganographic layer seems unnecessary for legitimate purposes. ## What Developers Should Do If you use Claude Code and this concerns you: 1. **Assume all API-based tools have some telemetry.** This is not unique to Anthropic. Any cloud-based AI tool can log your prompts, responses, and metadata. 2. **Self-hosting is the only complete mitigation.** Local models like DeepSeek V4 Flash, GLM 5.2, or Qwen 3.6 give you full control. The agentic harnesses are less polished than Claude Code, but projects like pi and opencode are improving. 3. **Watch for follow-up analysis.** The original researcher called for testing whether marked requests receive different treatment (rate limits, model quality, etc.). That would be a more serious finding than the fingerprinting itself. For now, this is a transparency issue rather than a security incident. But it is a useful reminder that closed-source tools running on your machine can contain behaviors you did not agree to. ## Sources - [Claude Code Prompt Steganography](https://thereallo.dev/blog/claude-code-prompt-steganography) - Original analysis by thereallo.dev - [Hacker News Discussion](https://news.ycombinator.com/item?id=48734373) - Thread with 100+ comments

Claude in Microsoft Foundry on Azure: Developer Guide 2026

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Claude in Microsoft Foundry docs | [platform.claude.com/docs/en/build-with-claude/claude-in-microsoft-foundry](https://platform.claude.com/docs/en/build-with-claude/claude-in-microsoft-foundry) | | Microsoft Foundry portal | [ai.azure.com](https://ai.azure.com/) | | Azure Foundry pricing | [azure.microsoft.com/pricing/details/microsoft-foundry](https://azure.microsoft.com/en-us/pricing/details/microsoft-foundry/) | | Anthropic pricing | [claude.com/pricing](https://claude.com/pricing) | | Microsoft deployment guide | [learn.microsoft.com/azure/foundry/foundry-models/how-to/use-foundry-models-claude](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-claude) | | Azure blog announcement | [azure.microsoft.com/blog/claude-in-microsoft-foundry-is-now-generally-available](https://azure.microsoft.com/en-us/blog/claude-in-microsoft-foundry-is-now-generally-available/) | As of June 29, 2026, Claude Opus 4.8 and Claude Haiku 4.5 are generally available in Microsoft Foundry on Azure. This is the first time enterprise teams can access Claude with full Azure-native billing, identity management, and governance - no separate Anthropic contract required for initial deployment. The practical implication: if your organization already runs on Azure with an Enterprise Agreement, you can start using Claude today with charges appearing on your existing Azure invoice. Microsoft Azure Consumption Commitment (MACC) applies. **Last updated:** June 30, 2026 ## What Launched Microsoft Foundry is Azure's unified AI platform - the successor to Azure AI Studio. On June 29, Anthropic announced general availability of Claude models in Foundry with two hosting options: **Hosted on Azure** (GA) - Claude runs on Anthropic-operated infrastructure within Azure data centers. Prompts and completions stay within Azure; only usage metadata and safety-flagged content egress to Anthropic. Available models: Claude Opus 4.8 and Claude Haiku 4.5. **Hosted on Anthropic** (Preview) - Claude runs on Anthropic's own infrastructure. Supports all Claude models including Fable 5 and the full Opus/Sonnet lineup. Use this for features not yet available on Azure-hosted deployments. The Hosted on Azure option runs on NVIDIA GB300 Blackwell Ultra systems, which Microsoft positions for autonomous and domain-specific AI agents. ## Model Availability | Model | Hosted on Azure | Hosted on Anthropic | |-------|-----------------|---------------------| | Claude Fable 5 | - | Yes | | Claude Opus 4.8 | Yes | Yes | | Claude Opus 4.7 | - | Yes | | Claude Opus 4.6 | - | Yes | | Claude Opus 4.5 | - | Yes | | Claude Sonnet 4.6 | - | Yes | | Claude Sonnet 4.5 | - | Yes | | Claude Haiku 4.5 | Yes | Yes | All models on Foundry have 1M-token context windows except Claude Sonnet 4.5, which has 200k. ## CCU Pricing Microsoft Foundry bills through Azure Marketplace using Claude Consumption Units (CCUs). The conversion is straightforward: 100 CCU = $1.00 USD of Claude usage at standard Anthropic API rates. | Billing detail | How it works | |----------------|--------------| | Billing unit | Claude Consumption Unit (CCU) | | CCU price | $0.01 per CCU (fixed) | | Conversion | Token usage rated at standard Anthropic per-MTok rates, then converted to CCUs | | Billing cadence | Hourly metering to Azure Marketplace; monthly invoices | | Payment model | Postpaid only - no prepaid credits | | Discounts | Applied as fewer CCUs metered | | MACC eligible | Yes | The underlying token pricing matches Anthropic's standard API rates: | Model | Input ($/MTok) | Output ($/MTok) | |-------|----------------|-----------------| | Fable 5 | $10 | $50 | | Opus 4.8 | $5 | $25 | | Sonnet 4.6 | $3 | $15 | | Haiku 4.5 | $1 | $5 | Prompt caching multipliers apply: 5-minute cache writes cost 1.25x input, 1-hour cache writes cost 2x input, cache hits cost 0.1x input. Batch API discounts (50% off) are available for async workloads. **US Data Zone pricing:** Using the US Data Zone Standard deployment type adds a 1.1x multiplier to all token pricing. This keeps inference within the United States. ## Getting Started ### Prerequisites - An active Azure subscription - Access to [Microsoft Foundry](https://ai.azure.com/) - Azure CLI installed (optional, for resource management) ### Step 1: Create a Foundry Resource 1. Navigate to the [Foundry portal](https://ai.azure.com/) 2. Create a new Foundry resource or select an existing one 3. Configure access management using Azure-issued API keys or Entra ID 4. Optionally configure private network (Azure Virtual Network) 5. Note your resource name - you will use this as `{resource}` in API endpoints Your endpoint URL format: `https://{resource}.services.ai.azure.com/anthropic/v1/*` ### Step 2: Deploy a Claude Model 1. In the Foundry portal, select **Discover** > **Models** 2. Search for a Claude model (e.g., `claude-opus-4-8`) 3. Select **Deploy** > **Custom settings** 4. On your first Claude deployment, accept the Azure Marketplace terms 5. Configure the deployment: - **Deployment name:** Defaults to model ID, but you can customize - **Region scope:** Global or Data Zone (US only) - **Model version:** Select hosting option (Hosted on Azure or Hosted on Anthropic) 6. Select **Deploy** and wait for provisioning ### Step 3: Get Your Credentials 1. In Foundry, select **Build** > **Models** 2. Open your Claude deployment and select the **Details** tab 3. Copy the **Key** and note the **Target URI** ## SDK Installation Foundry is supported by Python, TypeScript, C#, Java, and PHP SDKs. **Python:** ```bash pip install -U "anthropic" ``` **TypeScript:** ```bash npm install @anthropic-ai/foundry-sdk ``` **C#:** ```bash dotnet add package Anthropic.Foundry ``` **Java (Gradle):** ```kotlin implementation("com.anthropic:anthropic-java-foundry:2.40.0") ``` ## Authentication Options ### API Key Authentication Set environment variables: ```bash export ANTHROPIC_FOUNDRY_API_KEY="your-api-key" export ANTHROPIC_FOUNDRY_RESOURCE="your-resource-name" ``` **Python example:** ```python import os from anthropic import AnthropicFoundry client = AnthropicFoundry( api_key=os.environ.get("ANTHROPIC_FOUNDRY_API_KEY"), resource="example-resource", ) message = client.messages.create( model="claude-opus-4-8", max_tokens=1024, messages=[{"role": "user", "content": "Hello!"}], ) print(message.content) ``` **TypeScript example:** ```typescript import AnthropicFoundry from "@anthropic-ai/foundry-sdk"; const client = new AnthropicFoundry({ apiKey: process.env.ANTHROPIC_FOUNDRY_API_KEY, resource: "example-resource" }); const message = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, messages: [{ role: "user", content: "Hello!" }] }); console.log(message.content); ``` **cURL example:** ```bash curl https://{resource}.services.ai.azure.com/anthropic/v1/messages \ -H "content-type: application/json" \ -H "api-key: YOUR_AZURE_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-opus-4-8", "max_tokens": 1024, "messages": [ {"role": "user", "content": "Hello!"} ] }' ``` ### Entra ID Authentication For enterprise deployments, use Microsoft Entra ID (formerly Azure Active Directory) for centralized access management via Azure RBAC. **Python with Entra ID:** ```python import os from anthropic import AnthropicFoundry from azure.identity import DefaultAzureCredential, get_bearer_token_provider token_provider = get_bearer_token_provider( DefaultAzureCredential(), "https://ai.azure.com/.default" ) client = AnthropicFoundry( resource="example-resource", azure_ad_token_provider=token_provider, ) message = client.messages.create( model="claude-opus-4-8", max_tokens=1024, messages=[{"role": "user", "content": "Hello!"}], ) print(message.content) ``` **cURL with Entra ID:** ```bash ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv) curl https://{resource}.services.ai.azure.com/anthropic/v1/messages \ -H "content-type: application/json" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-opus-4-8", "max_tokens": 1024, "messages": [ {"role": "user", "content": "Hello!"} ] }' ``` ## Feature Limitations on Azure When using **Hosted on Azure** deployments, the following features are not available: - Structured outputs - Server-side tools (web search, web fetch, code execution, tool search) - MCP connector - Agent Skills - Programmatic tool calling - Files API Requests that use these features return a `400 Bad Request` error. Claude Code automatically detects Hosted on Azure deployments and adapts its feature set. For full feature parity, use **Hosted on Anthropic** deployments instead. ## Monitoring and Logging Azure provides native observability for Claude usage: - **Azure Monitor:** Track API usage, latency, and error rates - **Log Analytics:** Query and analyze request/response logs - **Cost Management:** Monitor and forecast CCU consumption For debugging, include both `request-id` and `apim-request-id` response headers when contacting support. ## Migration Between Hosting Options To move from Hosted on Anthropic to Hosted on Azure (or vice versa): 1. Create a new deployment with the other hosting version 2. Update your application to pass the new deployment name in the `model` parameter 3. Delete the old deployment once traffic has moved If the new deployment is in the same Foundry resource, your endpoint URL and authentication stay unchanged. ## California Government Partnership On June 29, Governor Newsom announced that California signed a first-of-its-kind agreement with Anthropic giving state agencies, cities, and counties access to Claude at a 50% discount. The deal includes free workforce training, technical assistance, and workflow help from Anthropic developers. This partnership runs through Azure Marketplace, using the same CCU billing structure. Public sector organizations in California should contact their Anthropic or Microsoft account representative for access. ## When to Use Foundry vs Direct API **Use Microsoft Foundry when:** - Your organization is already on Azure with an Enterprise Agreement - You need MACC credits to apply to AI spend - Centralized Azure billing and governance matter - Entra ID for identity management is a requirement - You want Claude alongside other Foundry models in one platform **Use the direct Anthropic API when:** - You need Fable 5, Claude Managed Agents, or Batch API features - Server-side tools (web search, code execution) are required - You want the full feature set without hosting limitations - Multi-cloud or cloud-agnostic deployment is important ## FAQ ### How does Microsoft Foundry billing compare to the Anthropic API? The underlying token rates are identical. Foundry adds no markup - you pay standard Anthropic rates, converted to CCUs for Azure billing. The main difference is payment method (Azure invoice vs Anthropic billing) and MACC eligibility. ### Can I use Claude Code with Foundry deployments? Yes. Claude Code detects Hosted on Azure deployments automatically and adapts its feature set. Some features like server-side tools are not available, but core coding assistance works. ### What is a Claude Consumption Unit (CCU)? A CCU is a billing unit for Azure Marketplace. 100 CCU = $1.00 USD of Claude usage at standard rates. CCUs are metered hourly and invoiced monthly in arrears. ### Are prompt caching and batch processing available on Foundry? Prompt caching is available with the same multipliers as the direct API. Batch API with 50% discount is available. Fast mode is not available on Claude Platform on AWS but should be checked for Foundry availability. ### What models are available on Hosted on Azure? Currently, Claude Opus 4.8 and Claude Haiku 4.5 are available on Hosted on Azure. Other models including Fable 5 and the Sonnet family are available on Hosted on Anthropic (preview). ### How do I get US data residency on Foundry? Use the US Data Zone Standard deployment type when creating your deployment. This keeps inference within the United States and applies a 1.1x pricing multiplier. ### Can I migrate existing Anthropic API applications to Foundry? Yes. The SDK changes are minimal - swap `Anthropic` for `AnthropicFoundry` and provide your resource name. API request/response formats are identical. ### What support options are available? Include both `request-id` and `apim-request-id` response headers when contacting support to help teams locate your request across both Anthropic and Azure systems. --- ## Sources - [Claude in Microsoft Foundry documentation](https://platform.claude.com/docs/en/build-with-claude/claude-in-microsoft-foundry) - verified June 30, 2026 - [Claude in Microsoft Foundry pricing](https://platform.claude.com/docs/en/about-claude/pricing#claude-in-microsoft-foundry-pricing) - verified June 30, 2026 - [Azure blog: Claude in Microsoft Foundry GA](https://azure.microsoft.com/en-us/blog/claude-in-microsoft-foundry-is-now-generally-available/) - June 29, 2026 - [Anthropic: Claude in Microsoft Foundry announcement](https://www.anthropic.com/news/claude-in-microsoft-foundry) - June 29, 2026 - [California Government Claude partnership](https://www.pymnts.com/news/artificial-intelligence/2026/anthropic-gives-california-government-a-discount-on-claude/) - June 29, 2026 - [Microsoft Learn: Deploy Claude in Foundry](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-claude) - June 2026

Claude Sonnet 5 Launch Analysis: The Most Agentic Sonnet Yet

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Claude Sonnet 5 Announcement](https://www.anthropic.com/news/claude-sonnet-5) | Anthropic official release post | | [Claude Models Documentation](https://platform.claude.com/docs/en/docs/about-claude/models) | Model specifications and API details | | [Claude Pricing](https://claude.com/pricing) | Current pricing for all Claude plans | | [Sonnet 5 System Card](https://www.anthropic.com/research/claude-sonnet-5-system-card) | Safety evaluations and capability assessments | | [HN Discussion](https://news.ycombinator.com/item?id=48736605) | Developer community response | Anthropic launched Claude Sonnet 5 today, billing it as "the most agentic Sonnet model yet." The model is available now across all Claude plans, Claude Code, and the API with introductory pricing of $2/million input tokens and $10/million output tokens through August 31, 2026. **Last updated:** June 30, 2026 ## What's New in Sonnet 5 The headline claim is improved agentic capability. According to Anthropic, Sonnet 5 can make plans, use tools like browsers and terminals, and operate autonomously at levels that previously required larger models like Opus. **Key technical details:** - **Model ID:** `claude-sonnet-5` - **Introductory pricing (through Aug 31):** $2/1M input, $10/1M output - **Standard pricing (after Aug 31):** $3/1M input, $15/1M output - **Updated tokenizer:** Similar to Opus 4.7 changes, the same input may map to 1.0-1.35x more tokens depending on content type The benchmarks show substantial improvements over Sonnet 4.6 across reasoning, tool use, coding, and knowledge work. Performance approaches Opus 4.8 while maintaining lower costs - at least on the low and medium effort settings. ### Safety Changes Anthropic is positioning Sonnet 5 as more security-conscious than its predecessor: - Lower rates of undesirable behaviors than Sonnet 4.6 - Better at refusing malicious requests and resisting prompt injection - Significantly reduced cybersecurity capabilities compared to Opus models - Cyber safeguards enabled by default From the system card: "On CyberGym vulnerability discovery, Claude Sonnet 5 is less capable than Sonnet 4.6, and far less capable than Opus 4.8 and Mythos 5. When run with default mitigations, Sonnet 5 scored a 0 on CyberGym." ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48736605) hit 724 points and 395 comments within hours. The conversation is notably skeptical about value proposition. **The pricing paradox at higher effort levels:** Several commenters noted that on Anthropic's own benchmarks, running Sonnet 5 on "extra high" thinking budget costs nearly as much as Opus 4.8 while performing slightly worse on several tasks. As one commenter put it: "If you're doing something hard, just use a bigger model." Looking at the BrowserComp benchmark in particular, Sonnet 5 on high effort actually costs more than Opus 4.8 at a lower pass rate. The value proposition seems strongest at low and medium effort settings. **Haiku update requests:** Multiple commenters asked about a new Haiku model. Haiku 4.5 is nearly a year old, and users are looking for a faster, cheaper model that's kept pace with improvements. Some suggested that Sonnet 5 at launch pricing would make more sense as a new Haiku. **Where's Fable?** A recurring theme was disappointment that this wasn't the rumored Fable model. As one commenter said simply: "That's nice, but we want Fable." Others noted that Fable will eventually be superseded by future Sonnet/Opus versions anyway. **LLM plateau discussion:** Some commenters see this release as evidence that frontier model improvements are slowing. One noted: "LRMs are plateauing for sure, not that there won't be gains to be had in the future, but it's not like the era of rapid progress that was the past year any more." **Comparisons to open models:** Several commenters pointed to GLM 5.2 and other open-weight models as competitive alternatives at lower price points. The consensus seems to be that Sonnet 5 faces stiffer competition than previous Sonnet releases. ## Practical Implications Based on Anthropic's own graphs and the HN discussion, here's when Sonnet 5 makes sense: **Use Sonnet 5 (low/medium effort) when:** - Running high-volume, well-scoped tasks - Cost matters more than maximum capability - Tasks are well-defined and don't require deep reasoning - You're on the introductory pricing **Use Opus instead when:** - Tasks are open-ended or require complex reasoning - Running agentic search or computer use (Opus 4.8 is cheaper per success on these benchmarks) - You need maximum capability regardless of cost **Consider open models when:** - You need Haiku-level intelligence at lower cost - Running on infrastructure where open weights matter - Qwen, GLM 5.2, and other open models are increasingly competitive at this tier The updated tokenizer is worth noting for production workloads. The same prompts may cost 1-1.35x more tokens than with previous models, which partially offsets the lower per-token pricing for some content types. ## My Take The honest read on Sonnet 5 is that it's a solid incremental update to the workhorse model, but the value proposition is narrower than the marketing suggests. The introductory pricing is genuinely attractive for high-volume workloads. At $2/$10, Sonnet 5 on low effort competes well with open models while offering Anthropic's infrastructure and safety work. After August 31, the math changes. For developers already using Claude, the practical question is whether to route tasks to Sonnet 5 low/medium instead of Opus. The answer depends on your specific workload, but the benchmarks suggest Opus remains the better choice for anything complex. The safety story is interesting. Reduced cybersecurity capabilities and stronger prompt injection resistance are useful for production applications, even if some developers would prefer unfettered access. What's missing is a new Haiku. The market has moved, and there's a clear gap for a fast, cheap model that keeps pace with 2026 capabilities. ## FAQ ### Is Claude Sonnet 5 better than Opus 4.8? Not for most complex tasks. Anthropic's own benchmarks show Opus 4.8 beats Sonnet 5 on the Pareto frontier for agentic search and computer use. Sonnet 5 is cheaper for simpler tasks at low effort settings. ### What's the difference between Sonnet 5 effort levels? Low, medium, high, and extra-high control how much "thinking" the model does. Low is fastest and cheapest. Higher levels improve quality but increase cost and latency. The spread between levels is wider than in Sonnet 4.6. ### Should I switch from Sonnet 4.6 to Sonnet 5? Yes, Sonnet 5 is strictly better than Sonnet 4.6 across benchmarks. The new tokenizer may change your token counts, so monitor usage after switching. ### When will Fable be available? Anthropic hasn't announced Fable availability. Based on the discussion, it appears Fable exists but is not generally available. ## Sources - [Anthropic Claude Sonnet 5 announcement](https://www.anthropic.com/news/claude-sonnet-5) - [HN discussion (48736605)](https://news.ycombinator.com/item?id=48736605) - Claude Sonnet 5 System Card (linked in announcement)

Gemini 3.5 Pro Developer Guide: 2M Context Window and Deep Think Mode

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Gemini API Pricing](https://ai.google.dev/gemini-api/docs/pricing) | Official Google AI pricing page | | [Gemini API Models](https://ai.google.dev/gemini-api/docs/models) | Model list and specifications | | [Gemini 3 Developer Guide](https://ai.google.dev/gemini-api/docs/gemini-3) | Technical guide for Gemini 3.x models | | [Gemini Long Context Docs](https://ai.google.dev/gemini-api/docs/long-context) | Long context handling patterns | | [Vertex AI Agent Platform Pricing](https://cloud.google.com/gemini-enterprise-agent-platform/generative-ai/pricing) | Enterprise pricing on Google Cloud | Gemini 3.5 Pro is Google's next flagship model, now rolling into general availability in late June 2026 after an enterprise preview on Vertex AI. The headline numbers: a 2-million-token context window and a Deep Think reasoning mode that trades latency for accuracy on hard problems. This guide covers what developers need to know before integrating: where the model is available, what it actually costs, how the context window and reasoning mode work in practice, and when Gemini 3.5 Pro is the right choice versus Flash or other providers. **Last updated:** June 30, 2026 ## Model Specifications | Specification | Gemini 3.5 Pro | Gemini 3.5 Flash | |---------------|----------------|------------------| | Context window | 2M tokens | 1M tokens | | Output limit | 64K tokens | 64K tokens | | Knowledge cutoff | January 2025 | January 2025 | | Deep Think | Yes | No | | GA status | Late June 2026 | GA since May 2026 | The 2M context window is the largest production context available from any major provider as of this writing. Claude's current Opus 4.x and Fable 5 models cap at 200K tokens. GPT-5.x caps at 512K tokens in the extended context tier. That scale difference matters for specific workloads. It does not mean Gemini 3.5 Pro is the right default for every task. ## Availability and Access **Current access (June 2026):** - **Vertex AI**: Model ID `gemini-3.5-pro-preview-06`. Enterprise accounts can request allowlist access through their Google Cloud account team. - **Google AI Studio**: Expected at GA launch. - **Gemini API (REST/SDKs)**: Expected at GA launch. - **OpenAI-compatible endpoint**: Google AI Studio provides an OpenAI-compatible mode for migration. At general availability, the model will appear in Google AI Studio and the Gemini API alongside the existing Gemini 3.x lineup. ## Pricing (Expected) Google has not published official Gemini 3.5 Pro pricing yet. Based on enterprise preview participant reports and historical Flash-to-Pro ratios, the expected range is: | Tier | Input (per 1M tokens) | Output (per 1M tokens) | |------|----------------------|------------------------| | Standard context (under 200K) | $12 - $15 | $36 - $45 | | Long context (over 200K) | $15 - $18 | $45 - $54 | | Cached input | $1.20 - $1.80 | N/A | | Batch API | 50% discount | 50% discount | These figures are estimates. Verify against the official pricing page before production deployment. For comparison, Gemini 3.5 Flash is $1.50/$9.00 per million tokens, making Pro roughly 8 to 10 times more expensive. The trade-off is reasoning quality, not speed. ## Context Window: What 2M Tokens Actually Holds The 2-million-token context is large enough to hold entire codebases, document sets, or conversation histories that previously required retrieval augmentation. | Use case | Approximate fit | |----------|-----------------| | TypeScript monorepo | 2,000 files at 200 lines average | | Slack team export | 3 years from a 30-person team | | SEC S-1 filings | 4 full documents simultaneously | | Civil litigation case file | Pleadings, depositions, exhibits, transcripts | | Internal handbook | 2+ years of policy documentation | The practical question is not whether the context fits. It is whether loading 2M tokens is worth the cost and latency versus chunked retrieval. ### When massive context helps - **Whole-repository audits**: Security scans, architecture reviews, or dependency analysis where cross-file relationships matter. - **Cross-document analysis**: Comparing multiple legal filings, contracts, or policy documents directly without summarization loss. - **Long-running agent state**: Multi-hour agent sessions where accumulated context would otherwise require expensive handoffs. - **Consistency-sensitive tasks**: Content that must reference distant prior context without semantic drift. ### When massive context does not help - **Single-file tasks**: Code generation or editing scoped to one file does not benefit from 2M context. - **Retrieval-friendly workloads**: If the answer exists in a small slice of the corpus, RAG is cheaper and faster. - **Latency-sensitive paths**: Loading 2M tokens adds significant prefill time. Real-time applications should use Flash. ## Deep Think Mode Deep Think is Google's name for extended inference-time compute. The model spends more cycles reasoning before answering instead of pattern-matching to a quick response. ### How to enable it Deep Think is controlled via the `thinkingConfig` API parameter: ```typescript import { GoogleGenerativeAI } from "@google/generative-ai"; const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY); const model = genAI.getGenerativeModel({ model: "gemini-3.5-pro", generationConfig: { thinkingConfig: { thinkingLevel: "high" // minimal, low, medium, high } } }); const result = await model.generateContent({ contents: [{ role: "user", parts: [{ text: "Your complex reasoning prompt" }] }] }); ``` The `thinkingLevel` parameter has four options: | Level | Use case | Latency impact | |-------|----------|----------------| | minimal | Fast responses, simple queries | Lowest | | low | Standard completions | Low | | medium | Multi-step reasoning | Moderate | | high | Complex analysis, hard problems | Highest | **Important:** Reasoning tokens count against your context budget and appear to be billed at the output token rate. A problem that requires extensive reasoning can consume significant tokens before producing the final answer. ### When to use Deep Think - Mathematical proofs and formal reasoning - Complex code architecture decisions - Multi-constraint optimization problems - Legal or policy analysis requiring careful interpretation ### When not to use Deep Think - Retrieval or lookup tasks - Simple code generation - Real-time or latency-sensitive applications - High-throughput pipelines where cost per call matters ## Integration Patterns ### Python SDK ```python import google.generativeai as genai import os genai.configure(api_key=os.environ["GEMINI_API_KEY"]) model = genai.GenerativeModel( model_name="gemini-3.5-pro", generation_config={ "temperature": 1.0, # keep at default "max_output_tokens": 8192, } ) response = model.generate_content("Analyze this codebase for security vulnerabilities...") print(response.text) ``` ### TypeScript/JavaScript SDK ```typescript import { GoogleGenerativeAI } from "@google/generative-ai"; const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!); const model = genAI.getGenerativeModel({ model: "gemini-3.5-pro", generationConfig: { temperature: 1.0, maxOutputTokens: 8192, } }); const result = await model.generateContent("Your prompt here"); console.log(result.response.text()); ``` ### cURL (REST API) ```bash curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-pro:generateContent?key=${GEMINI_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "contents": [{ "parts": [{"text": "Your prompt here"}] }], "generationConfig": { "temperature": 1.0, "maxOutputTokens": 8192 } }' ``` ## Caching for Cost Control With long-context workloads, caching becomes essential. Cached input on Pro-tier models is typically 90% cheaper than standard input. ```typescript const cachedContent = await genAI.cacheContent({ model: "gemini-3.5-pro", contents: [ { role: "user", parts: [{ text: systemPromptAndContext }] } ], ttl: "3600s" // 1 hour }); const model = genAI.getGenerativeModelFromCachedContent(cachedContent); const result = await model.generateContent("Your task-specific prompt"); ``` For workloads that reuse the same large context across many calls, caching can reduce input costs from $15/M to $1.50/M or less. ## Gemini 3.5 Pro vs Fable 5 vs GPT-5.x | Capability | Gemini 3.5 Pro | Claude Fable 5 | GPT-5.x | |------------|----------------|----------------|---------| | Max context | 2M tokens | 200K tokens | 512K tokens | | Deep reasoning mode | Deep Think | Extended thinking | o-series | | Input pricing (est.) | $12 - $15/M | $20/M | $15/M | | Output pricing (est.) | $36 - $45/M | $60/M | $60/M | | Best for | Long context, whole-repo analysis | Complex agentic coding | Structured multi-step | The context window is Gemini 3.5 Pro's standout advantage. If your workload genuinely needs 500K to 2M tokens of live context, it is currently the only frontier option. For shorter context workloads, the choice depends more on model behavior, API ergonomics, and existing integration. ## My Take Gemini 3.5 Pro is a specialized tool, not a general replacement. The 2M context window solves real problems: whole-codebase security audits, cross-document legal analysis, and long-running agent sessions where context handoff is expensive or lossy. For those workflows, the context size alone makes it worth evaluating. For most day-to-day coding and short-context tasks, Flash at $1.50/$9.00 is the better default. Pro's 8 to 10x cost premium only makes sense when the context or reasoning requirements justify it. Deep Think is interesting but adds both latency and token cost. Use it deliberately for hard reasoning problems, not as a default. The launch timing matters too. Gemini 3.5 Pro arrives shortly after Fable 5, which set a new bar for agentic coding quality. Google is positioning Pro as the context leader rather than trying to match Fable 5's agentic benchmarks directly. That is a reasonable trade-off if your workload is context-bound. ## FAQ ### What is the Gemini 3.5 Pro context window? Gemini 3.5 Pro has a 2-million-token context window, the largest of any production frontier model as of June 2026. This is double the previous Flash generation and ten times larger than Claude Fable 5. ### When will Gemini 3.5 Pro be generally available? General availability is expected in late June 2026. Enterprise developers can currently access the preview via Vertex AI with allowlist approval. ### How much does Gemini 3.5 Pro cost? Official pricing has not been announced. Based on enterprise preview reports, expect $12 to $15 per million input tokens and $36 to $45 per million output tokens, with long-context surcharges above 200K tokens. ### What is Deep Think mode? Deep Think is Google's extended inference-time compute mode. The model spends more reasoning cycles before answering, improving accuracy on complex problems at the cost of higher latency and token usage. ### Should I use Gemini 3.5 Pro or Flash? Use Flash for most tasks. Use Pro when you genuinely need the 2M context window or Deep Think reasoning. Flash is 8 to 10 times cheaper. ### How does Gemini 3.5 Pro compare to Claude Fable 5? Gemini 3.5 Pro leads on context size (2M vs 200K tokens). Fable 5 has set higher benchmarks on agentic coding tasks. Choose based on whether your workload is context-bound or coding-quality-bound. ### Can I use Gemini 3.5 Pro with existing OpenAI code? Google AI Studio provides an OpenAI-compatible endpoint for migration. You can point existing OpenAI SDK code at the Gemini endpoint with minimal changes. ### Is Deep Think worth the extra cost? For complex reasoning tasks - mathematical proofs, architecture decisions, multi-constraint optimization - yes. For retrieval, simple generation, or latency-sensitive paths, no. ## Sources Verified June 30, 2026. - [Gemini API Pricing](https://ai.google.dev/gemini-api/docs/pricing) - Google AI for Developers - [Gemini API Models](https://ai.google.dev/gemini-api/docs/models) - Google AI for Developers - [Gemini 3 Developer Guide](https://ai.google.dev/gemini-api/docs/gemini-3) - Google AI for Developers - [Gemini Long Context Documentation](https://ai.google.dev/gemini-api/docs/long-context) - Google AI for Developers - [Vertex AI Agent Platform Pricing](https://cloud.google.com/gemini-enterprise-agent-platform/generative-ai/pricing) - Google Cloud - [Gemini 3.5 Pro: 2M Context, Deep Think, and the Post-Fable-5 Frontier](https://dev.to/akaranjkar08/gemini-35-pro-2m-context-deep-think-and-the-post-fable-5-frontier-2p60) - DEV Community

Ornith-1.0: What an Open Source Self-Improving Coding Model Actually Means

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

## A new name in open-source coding models DeepReinforce AI dropped Ornith-1.0 on GitHub this week, and the Hacker News thread quickly accumulated over 200 points and 40 comments. The headline claims the model family is "self-improving" - a phrase that immediately raises eyebrows in a space where overpromising has become the norm. The model family ships in four sizes: 9B-Dense, 31B-Dense, 35B-MoE, and 397B-MoE. They are built on top of Gemma 4 and Qwen 3.5 foundations, released under the MIT license. The dense 9B fits on a single 80GB GPU, while the larger MoE variants require multi-GPU tensor parallelism. ## What "self-improving" actually means Let me be direct: Ornith-1.0 does not improve itself during inference. The weights do not change when you run it. The "self-improving" label refers to the training methodology, not the deployment behavior. According to DeepReinforce's documentation, Ornith uses a reinforcement learning approach that jointly optimizes two components: the scaffolding that drives rollouts and the solution rollouts themselves. In practical terms, the model learns to generate both its answers and the task-specific harnesses that guide how those answers are produced. This is different from most RL-for-coding approaches where humans design the evaluation harnesses and the model just learns to produce better solutions within that fixed structure. Ornith learns the structure too. Simon W caught this distinction immediately in the HN thread: > It doesn't self-improve, that's a misleading headline. As far as I can tell they trained it by running their own reinforcement learning on top of Qwen and Gemma 4 - so the "self-improving" is about their training process, not how you use the weights. This is the accurate framing. The term "self-improving" describes the training loop, not runtime behavior. ## What HN is saying The Hacker News discussion split into three camps. **The skeptics** pointed out that this looks like another benchmaxxed fine-tune. One commenter put it bluntly: "These are simply benchmaxxed versions of either Qwen or Gemma 4." Another noted that the model "fails at benchmarks" and "long session tool calls sucks and hallucinate a lot." The LocalLLM community's reputation came up repeatedly. One commenter observed that "the local LLM community is now teeming with erstwhile crypto and NFT hucksters who've brought the culture of hype from their former communities with them." Whether or not that is fair to everyone building local models, it does explain some of the reflexive skepticism. **The cautiously interested** noted that this is the first Qwen fine-tune that has not been immediately rejected by the LocalLLM community. One user reported: "Based on my limited usage, it is good, gives creative solutions to coding problems. I don't expect 9-35B models to one-click create full apps." Another commenter shared a more specific observation: "From what I personally tested Ornith-1.0 35B is slightly better than Qwen-3.6 35B. The part that I find interesting is that the model is way faster than Qwen3.6 35B. It seems Ornith produce a smaller chain of thought. On my test it can be 3 time faster to produce the answer." Speed improvements in chain-of-thought models matter. If Ornith produces equally good solutions with less verbose reasoning, that is a real win for practical use. **The critics of benchmarks** questioned the evaluation methodology entirely. One commenter noted that the benchmark "ranks Kimi K2.6 and K2.7 Code near the bottom. Both are below Ornith 35B. It ranks Gemma 4 26B much higher than GLM-5.2. The results don't make much sense." This is a recurring problem in the open-source model space. Benchmarks are gamed, and results that contradict real-world experience are common. ## The benchmark claims DeepReinforce published performance numbers across several evaluation suites: | Model | SWE-Bench Verified | Terminal-Bench 2.1 | |-------|-------------------|-------------------| | Ornith 9B | 69.4% | - | | Qwen3.5-9B | 53.2% | - | | Ornith 35B | - | 64.2% | | Qwen3.5-35B | - | 41.4% | | Ornith 397B | 82.4% | - | | Claude Opus 4.8 | 87.6% | - | These are substantial claimed improvements over the base models. The 397B MoE variant allegedly approaches Claude Opus 4.8 on SWE-Bench Verified. Take these with appropriate skepticism. SWE-Bench has become a target for optimization, and models trained specifically on similar distributions tend to overperform on benchmarks while underperforming on novel tasks. ## Technical specifications The architecture is a reasoning model - it generates internal chain-of-thought before producing final answers. All variants support a 256K context window and emit well-formed function calls for tool use. Runtime compatibility is broad: vLLM, SGLang, llama.cpp, and Ollama are all supported. The recommended inference settings are temperature=0.6, top_p=0.95, top_k=20 for typical deployment, though benchmarks used temperature=1.0. One HN commenter raised the accessibility issue: "Us mere mortals cannot use this" - referring to the 80GB GPU requirement for even the smallest dense model. This is fair criticism. The quantized versions that appeared shortly after launch help somewhat, but the barrier to entry remains high compared to smaller models. ## The tool-use problem An interesting critique emerged in the thread about testing methodology. One reviewer tested Ornith without tool access and found it "performs poorly in a chat without tools, exhibiting an enthusiasm for hallucination." Another commenter pushed back: > How is that a serious phrase in '26? Testing a (clearly) agentic model without tool access and expecting it to work is crazy, no? What was he even testing?! This is the right frame. Agentic coding models are designed to use tools - file systems, interpreters, search. Testing them without tools is like testing a car without wheels. The model may hallucinate tool outputs rather than admitting it cannot execute, but that says more about how it should be deployed than about its fundamental capability. ## Should you try it? If you are already running local models for coding tasks and have the hardware, Ornith is worth testing against your actual workloads. The reports of faster chain-of-thought generation are interesting if they hold up. If you are looking for a drop-in replacement for Claude or GPT-4 for general coding assistance, this probably is not it. The tool-use requirements and hallucination tendencies outside agentic harnesses make it a poor fit for casual chat use. If you are evaluating open-source coding models for a self-hosted code assistant pipeline, add Ornith to your test matrix alongside Qwen 3.6 and Gemma 4. The proof will be in how it performs on your specific codebase and task distribution, not in benchmark tables. The "self-improving" framing is marketing. The underlying approach - jointly optimizing solutions and scaffolding - is technically interesting but does not change how you deploy or use the model. Judge it on outputs, not on training methodology claims. ## FAQ ### Is Ornith-1.0 actually self-improving? No, not during inference. The "self-improving" label describes the training methodology where the model learns to generate both solutions and the evaluation harnesses that guide those solutions. Once trained, the weights are fixed like any other model. ### What hardware do I need to run Ornith-1.0? The dense 9B model requires an 80GB GPU. The larger MoE variants need multi-GPU tensor parallelism. Quantized versions are available for more accessible hardware, but the full-precision models have steep requirements. ### How does Ornith compare to Qwen 3.6? Reports are mixed. Some users report it slightly outperforms Qwen 3.6 35B with faster chain-of-thought generation. Others say it hallucinates more in long sessions. Your results will depend on your specific use case. ### Is Ornith good for general coding chat? No. It is designed for agentic use with tool access. Testing it as a chat model without tools produces poor results with frequent hallucinations. Deploy it in an agentic harness with proper tool access. ## Sources - [Ornith-1.0 GitHub Repository](https://github.com/deepreinforce-ai/Ornith-1) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48722052) - [DeepReinforce AI Documentation](https://deep-reinforce.com/ornith_1_0.html)

Outer Shell: A Graphical Desktop for Your Remote Server via SSH

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

## The pitch: a home screen for your server Marcus Clarke's blog post "A Native Graphical Shell for SSH" landed on the Hacker News front page with over 320 points and nearly 200 comments. The proposal: what if your remote server had a graphical desktop you could access through SSH, with a home screen showing available applications? The project is called Outer Shell. Instead of opening a terminal and typing commands, you would see something closer to a desktop environment - but one designed from scratch for remote access rather than adapted from local GUI toolkits. ## How it actually works The architecture centers on Unix domain sockets rather than localhost TCP ports. Each application on the server runs a small HTTP server bound to a socket file. This eliminates port conflicts - you cannot have two apps fighting over port 8080 if they are both using named sockets in different paths. The shell provides an API for apps to register themselves by function type. An editor can register as the default handler for text files. A notebook server can register for .ipynb files. When you click a file in the shell's file browser, it looks up the registered handler and opens it. Communication happens over SSH or locally. Since SSH already handles encryption, individual applications do not need to implement their own TLS. They just serve plain HTTP over Unix sockets, and the SSH tunnel provides security. The rendering can be either web-based (HTML served to a browser) or native (an "outerframe" application that runs locally but displays remote content). The latter becomes more practical with AI-assisted development making cross-platform native apps easier to build. ## What HN is saying The discussion generated more debate about terminology than architecture - always a sign that a project touched something fundamental. **The naming controversy** dominated the early comments. Several commenters objected to calling this a "shell" at all. The author's response acknowledged the ambiguity: > I wondered if this would be controversial. It all depends where you grew up. He quoted Microsoft's Cairo documentation: "Cairo, like Chicago, had a new shell (Microsoft's favorite word for the user interface for launching programs and managing files)." Another commenter traced the lineage: "command line shell vs graphical shell. My first experience with a graphical shell was dosshell. For a while we called the Windows 3.1 interface 'the shell'." The terminology debate reflects a real question: is this a shell replacement or a layer on top of SSH? **The skeptics** questioned whether this solves a real problem. One commenter noted: "Haven't really ever seen the need for those, mostly because terminals work better than browsers." Another pushed back on the premise: "Sometimes the browser is the only 'computing platform' you have available (e.g. on some mobile devices, hotel kiosks)." The counterargument for accessibility is fair. Not everyone has a full terminal available, and browser-based access opens remote server interaction to more constrained environments. **The architecture enthusiasts** dug into the Unix socket choice. Using file system paths instead of port numbers means permissions can be controlled with standard Unix file permissions. You do not need a separate authorization layer - if a user can access the socket file, they can connect to the service. One detailed comment explored the implications: "The infrastructure supports both web-based interfaces and platform-native implementations, with the latter becoming more practical given AI-assisted development." This is an interesting observation. Writing native GUI applications has traditionally been expensive enough that most tools default to web UIs. If that cost drops substantially, the architecture that assumes both modes makes more sense. **The comparison to existing tools** came up repeatedly. Commenters mentioned Cockpit, Webmin, and various web-based administration panels. The difference, according to proponents, is that those tools are monolithic while Outer Shell is an infrastructure layer that any application can plug into. One commenter compared it to how modern desktop environments work: "Think of it like a remote GNOME or KDE, but designed for SSH from the ground up rather than adapted from X11." ## The fragmentation problem this addresses The blog post makes an argument about how server-side graphical tools developed historically. Jupyter, Tensorboard, VS Code Server, Grafana - each built its own approach to remote access, authentication, and session management. This leads to: - Different ports for different tools (8888, 6006, 8080, 3000) - Different authentication mechanisms - No shared clipboard or file handling - No consistent way to discover what is running Outer Shell proposes a unifying layer. All apps register with the shell, use consistent authentication via SSH, and appear in a single interface. Whether this fragmentation is actually a problem worth solving depends on your workflow. If you regularly work on remote machines with multiple web interfaces, the unified discovery and authentication story is compelling. If you mainly use SSH for terminal work with occasional port forwarding, the additional layer may feel unnecessary. ## The technical choices Several architectural decisions stand out: **Unix domain sockets over TCP** - This simplifies permissions (use the filesystem) and eliminates port conflicts. The tradeoff is that sockets are local to the machine, so you need the SSH transport layer to make them remotely accessible. **No per-app TLS** - SSH handles encryption. Individual apps serve plain HTTP. This dramatically simplifies application development but requires trusting the SSH tunnel completely. **Registry-based app discovery** - Apps declare what file types and protocols they handle. This enables right-click-open workflows and makes the home screen dynamic. **Dual rendering modes** - Support both browser-based (HTML) and native (outerframe) applications. This future-proofs the architecture for when native cross-platform development becomes cheaper. ## Who this is for The clearest use case is developers who regularly work on remote development machines. If you SSH into a dev server and run Jupyter, a monitoring dashboard, and maybe VS Code Server, the unified access model could reduce friction. Another use case is edge devices and embedded systems that need occasional graphical administration but do not run a full desktop environment. A Raspberry Pi running Outer Shell could expose a home screen with registered management apps. The weakest case is traditional servers where terminal administration works fine. Adding a graphical layer to a production web server that you rarely touch directly solves a problem that does not exist. ## The implementation status As of the blog post, this is more proposal than shipped product. The architecture is documented, some proof-of-concept code exists, but it is not a polished system you can install today. The HN discussion treated it as a design document, which is appropriate. Whether the ideas survive contact with real-world use depends on whether anyone builds out the full implementation. The technical foundation - Unix sockets, SSH tunneling, HTTP servers - is all proven technology. The novel part is the integration layer that makes it feel like a coherent desktop rather than a collection of port-forwarded services. ## Should you watch this project? If you are building remote-first development tools, the architecture ideas are worth studying. The Unix socket approach to eliminating port conflicts is clever and applicable beyond this specific project. If you are looking for something to install today, this is not ready. Keep an eye on the project, but do not plan your infrastructure around it yet. If you are interested in the historical question of why server-side GUIs fragmented the way they did, the blog post itself is a good read even if you never use the software. The fundamental bet Outer Shell makes is that remote servers deserve a GUI layer designed for remote access, not adapted from local desktop toolkits. Whether that bet pays off depends on whether the implementation materializes and whether the developer experience is good enough to overcome the inertia of existing workflows. ## FAQ ### Is Outer Shell a replacement for SSH? No. It runs on top of SSH. SSH provides the transport and encryption; Outer Shell provides a graphical interface layer that makes remote services discoverable and accessible through a unified home screen. ### What is the difference between this and tools like Cockpit or Webmin? Cockpit and Webmin are monolithic administration tools. Outer Shell is an infrastructure layer that any application can register with. Think of it as the difference between a single app and an app store. ### Can I use this today? Not really. The project is in the proposal and proof-of-concept stage. The architecture is documented, but a polished installable system does not exist yet. ### Why Unix domain sockets instead of TCP ports? Unix sockets eliminate port conflicts (no more fighting over 8080), enable file-system-based permissions, and keep traffic local to the machine. SSH handles the remote access part. ### Does this work with existing web UIs like Jupyter? In theory, existing apps could register with Outer Shell. In practice, integration would require those apps to add Unix socket support and registry integration. It is not a drop-in replacement for port forwarding. ## Sources - [A Native Graphical Shell for SSH - probablymarcus.com](https://probablymarcus.com/blocks/2026/06/28/native-graphical-shell-for-SSH.html) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48720758)

PostgreSQL 19 Beta: SQL/PGQ, Temporal Tables, and REPACK CONCURRENTLY

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

**Last updated:** June 30, 2026 PostgreSQL 19 entered beta with a feature set that has the database community excited. The headline additions include SQL Property Graph Queries (SQL/PGQ) for graph-like traversals, native temporal table support based on SQL:2011, and built-in REPACK CONCURRENTLY for online table reorganization. The [Snowflake engineering blog](https://www.snowflake.com/en/blog/engineering/postgresql-19-features-beta/) published an overview (Snowflake acquired Crunchy Data and is now invested in the Postgres ecosystem), and the [Hacker News discussion](https://news.ycombinator.com/item?id=48733031) dove deep into the practical implications of each feature. ## The Big Three Features ### 1. SQL Property Graph Queries (SQL/PGQ) PostgreSQL 19 implements the SQL standard for property graph queries. This lets you define graph patterns over relational tables and traverse relationships using SQL syntax rather than external graph databases. The practical upside: if your application has recursive relationships - org charts, social graphs, dependency trees, or knowledge graphs - you can now query them with standard SQL graph patterns instead of recursive CTEs or separate graph infrastructure. HN discussion noted this is distinct from Neo4j-style graph databases. SQL/PGQ keeps your data in normal relational tables while adding a graph query layer. You do not need to migrate data or maintain a separate system. ### 2. Native Temporal Tables (SQL:2011) PostgreSQL 19 adds application-time temporal data support based on the SQL:2011 standard. This is for tracking "valid time" - when data was true in the real world, as opposed to "system time" (when data was recorded). Depesz covered the implementation details: the new `FOR PORTION OF` syntax allows updates and deletes that automatically split or adjust temporal ranges. The HN thread had experienced users chiming in: > "They're a cool feature but honestly a bit tricky to use well, IMHO. And be careful with PII lingering in a temporal void somewhere for a long time." - mickeyp The warning is valid - temporal tables keep historical records by design, which can conflict with data retention policies. But for audit trails, compliance tracking, and versioned data, this is a significant addition. ### 3. REPACK CONCURRENTLY Table bloat is one of PostgreSQL's operational headaches. Over time, updated and deleted rows leave behind dead tuples that VACUUM removes but do not reclaim disk space. The traditional fix - `pg_repack` or CLUSTER - requires locking the table. PostgreSQL 19 adds REPACK CONCURRENTLY, which reorganizes tables without blocking concurrent operations. This is similar to what pg_repack provides as an extension, but now it is built into core Postgres. For production databases where you cannot afford maintenance windows, this is a major operational improvement. ## What HN Is Saying The discussion at [Hacker News](https://news.ycombinator.com/item?id=48733031) touched on several angles. **The AI-generated content debate** dominated early comments. Multiple users flagged the Snowflake blog post as having AI-generated hallmarks: > "I can't decide whether this person writes in the type of style that was apparently overrepresented in LLM training, or whether they heavily used AI to spruce up their writing. I'm leaning towards the latter." - breakingcups One commenter noted that Snowflake laid off technical writers, citing AI as a replacement. The meta-discussion about content quality consumed a significant portion of the thread. **SQL Server comparisons** came up frequently. Users migrating from MSSQL highlighted features they still miss in PostgreSQL: - Indexed views with automatic incremental maintenance - Query hints for optimizer guidance - DateTimeOffset types that map cleanly to application types - Plan caching behavior One commenter summarized the migration tradeoff: > "I am currently fighting my way off SQL Server towards PostgreSQL. Windows Server is a real pain to operate and the SQL Server ecosystem expects you to run a lot of add-ons on the server alongside your database." - pbronez **Temporal table caveats** got attention from developers who have used similar features: > "These things exist to eliminate the risk of ever serving stale information from a materialised view. I.e., their benefit is political/reputational as much as they are technical in the sense that they save you effort like remembering to invalidate a MV after an ingest operation." - mickeyp **The Snowflake/Crunchy acquisition context** was noted. Craig Kerstiens, the post author, was at Crunchy Data before Snowflake acquired them. Snowflake and Databricks (which acquired Neon) are both investing in managed PostgreSQL - an interesting signal about where enterprise database infrastructure is heading. ## Other Notable Features Beyond the headline additions, PostgreSQL 19 includes: - **Logical replication improvements** - Better handling of schema changes and conflict resolution - **Query planner optimizations** - Ongoing work on the optimizer - **Extension improvements** - Continued investment in the extension ecosystem that makes Postgres so flexible The full release notes are worth reading if you are a Postgres user. Each major version brings dozens of smaller improvements that compound over time. ## When to Expect the Release PostgreSQL follows a predictable annual release cycle. The beta typically appears in May-June, with GA (General Availability) in September-October. If you are planning infrastructure upgrades, PostgreSQL 19 GA should arrive around Q4 2026. For production workloads, waiting 1-2 minor releases after GA (e.g., 19.1 or 19.2) is the conservative approach. But the features in this release - particularly REPACK CONCURRENTLY - may justify earlier adoption for teams with specific operational pain points. ## Why This Matters PostgreSQL's steady feature expansion continues to narrow the gap with commercial databases. SQL/PGQ gives you graph capabilities without Neo4j. Temporal tables provide compliance features that previously required Oracle or custom implementations. REPACK CONCURRENTLY reduces operational toil. The ecosystem strength also matters. PostgreSQL extensions cover vector search (pgvector), geospatial (PostGIS), time-series (TimescaleDB), and more. Each core improvement compounds across this extension ecosystem. For teams evaluating database infrastructure, PostgreSQL 19 reinforces why Postgres has become the default choice for new applications. The combination of relational reliability, extension flexibility, and steady feature improvement is hard to match. ## Sources - [PostgreSQL 19 Features Beta Deep Dive](https://www.snowflake.com/en/blog/engineering/postgresql-19-features-beta/) - Snowflake Engineering Blog - [Hacker News Discussion](https://news.ycombinator.com/item?id=48733031) - Thread with 80+ comments - [Waiting for PostgreSQL 19: ADD UPDATE DELETE FOR PORTION OF](https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-add-update-delete-for-portion-of/) - Depesz temporal tables analysis

ZLUDA 6: Running CUDA on AMD GPUs Is Now a Hobby Project

Developers Digest — Tue, 30 Jun 2026 00:00:00 GMT

ZLUDA 6 released today with a surprising set of features: 32-bit PhysX support, texture implementation for Blender compatibility, and improved Windows tooling. The project lets you run unmodified CUDA applications on AMD GPUs, and with this release, the development direction has fundamentally changed. **Last updated:** June 30, 2026 ## What Is ZLUDA? ZLUDA (the name is Polish for "mirage" or "illusion") translates CUDA calls to run on non-NVIDIA hardware. You take a CUDA application, run it through ZLUDA, and it works on AMD GPUs via ROCm. The project has had a complicated history with AMD. The developer was funded by AMD for several years to help break the CUDA moat for ML workloads. That arrangement ended, and AMD's legal team actually went after the developer for releasing that code as open source. The current version is rebuilt from a pre-AMD-funded codebase. ## What's New in Version 6 From the [release post](https://vosen.github.io/ZLUDA/blog/zluda-update-q1q2-2026/): **PhysX Support (Pre-alpha):** 32-bit PhysX now works on AMD GPUs. This means older games with PhysX effects - debris, flames, particle systems - can render those effects on AMD hardware. Fluid simulations are still glitchy, but basic effects work. **Texture Support:** Basic texture implementation enables Blender compatibility. This was previously impossible because CUDA textures weren't translated. **Windows Improvements:** Better error messaging, automatic performance library loading, and more user-friendly configuration. Windows still requires manual ROCm installation since AMD doesn't bundle it with drivers. **ML Enhancements:** Multiple compiler fixes and new GPU instructions supporting PyTorch workloads. ## The Hobby Project Pivot The most interesting part of the release is the project's new direction. From the author: > "ZLUDA development is no longer commercially funded, so it's back to being my weekend project. This means that the priority is no longer what makes commercial sense, but what I find the most entertaining. That's why the sudden addition of textures, PhysX and better Windows support." This explains why a project previously focused on ML inference suddenly added gaming features. PhysX support doesn't make commercial sense - it helps with old games on AMD GPUs - but it's a fun technical challenge. The flip side is that updates will be less frequent and less predictable. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48730713) was smaller (133 points, 12 comments) but touched on some interesting points. **Legal questions:** One commenter asked if ZLUDA violates NVIDIA's license terms. The answer is unclear. NVIDIA's EULA may prohibit running CUDA on non-NVIDIA hardware, but whether that's actually legally enforceable depends on jurisdiction, how ZLUDA was built, and what exactly NVIDIA would go after. The project has survived this long without legal action. **LLM use cases:** Someone asked how ZLUDA compares to Vulkan for running LLMs on AMD hardware. The consensus: Vulkan and OpenCL paths have matured significantly. Frameworks like Unsloth have made the CUDA moat less relevant for ML specifically, since you can often get native AMD support without a translation layer. **The NVIDIA irony:** The discussion noted that NVIDIA briefly considered dropping 32-bit PhysX support on their own 5000 series cards. They reversed course after backlash, but there was a period where people wondered if AMD users with ZLUDA would have better PhysX support than NVIDIA users with new hardware. **Z-L-U-D-A pronunciation:** The name is Polish. "Zluda" means mirage or illusion, and CUDA is Polish for "miracles." Layers of meaning. ## Practical Considerations If you're considering ZLUDA for real workloads: **For ML/LLMs:** The native ecosystem has caught up. Frameworks increasingly support AMD directly via ROCm. ZLUDA remains useful for CUDA-only libraries that haven't been ported, but check if native support exists first. **For gaming with PhysX:** The new support is pre-alpha. Expect glitches, especially with fluid simulations. But if you have old games that are unplayable on AMD due to missing PhysX effects, this could help. **For Blender:** Texture support enables CUDA rendering paths on AMD GPUs. Worth testing if you've been stuck on OpenCL or CPU rendering. **For Windows:** You need to manually install ROCm. AMD doesn't ship it with consumer drivers. This adds friction compared to NVIDIA's just-works CUDA distribution. **For production:** The project is unfunded and updated on the author's entertainment schedule. Factor that into reliability calculations. ## My Take ZLUDA is a fascinating technical project that exists because NVIDIA's CUDA moat created artificial lock-in. The fact that a single developer can translate CUDA to ROCm shows the moat was always more about ecosystem and inertia than fundamental technical barriers. The shift to hobby-mode is both limiting and liberating. We probably won't see enterprise-grade support or rapid bug fixes. But we're getting features that "make commercial sense" would never prioritize - like making old PhysX games work on AMD hardware. For developers, the bigger picture is that the CUDA moat is eroding from multiple directions. Native framework support, translation layers like ZLUDA, and Apple's work on MLX all chip away at NVIDIA's lock-in. The question isn't whether alternatives will exist, but which will mature fastest for your specific workload. ZLUDA 6 is a good release for what it is: a passionate side project that solves real problems for people stuck with AMD hardware and CUDA-only software. Just don't build production infrastructure on it. ## FAQ ### Does ZLUDA work with all CUDA applications? No. Coverage is partial and depends on which CUDA APIs the application uses. Basic compute works well. Textures are new and basic. Some features remain unimplemented. ### Is ZLUDA legal? The answer is unclear. NVIDIA's EULA may contain restrictions, but enforceability varies by jurisdiction and depends on how ZLUDA was built. The project has operated for years without legal action. ### Should I use ZLUDA for ML workloads? Check if native AMD support exists first. Many frameworks now support ROCm directly, which is more reliable than translation. ZLUDA is most useful for CUDA-only libraries without native AMD ports. ### Will ZLUDA support Intel GPUs? The post doesn't mention Intel. Current focus is AMD GPUs via ROCm. Intel support would require different backend work. ## Sources - [ZLUDA Q1/Q2 2026 Update](https://vosen.github.io/ZLUDA/blog/zluda-update-q1q2-2026/) - [HN discussion (48730713)](https://news.ycombinator.com/item?id=48730713) - [Tom's Hardware coverage](https://www.tomshardware.com/pc-components/gpu-drivers/cuda-emulator-for-amd-gpus-zluda-loses-funding-with-v6-release-embattled-project-goes-back-to-hobby-status-but-now-includes-32-bit-physx-support)

LangSmith Fleet Turns Agent Ops Into On-Call Work

Developers Digest — Mon, 29 Jun 2026 00:00:00 GMT

**Last updated:** June 29, 2026 LangChain's June newsletter reads like a normal product roundup: Fleet On-Call Copilot, computer use in Fleet, voice traces, experiment status tracking, Slack notifications, Deep Agents rubrics, and a deployment course. The more interesting read is that LangSmith is turning agent operations into on-call work. That matters because the next useful agent surface is not another blank chat box. It is an operator loop that can read traces, inspect runbooks, use a sandboxed computer, pause for human approval, notify the right Slack thread, and turn production behavior into evals. If you have been following the Developers Digest thread on [agent reliability](/blog/the-agent-reliability-cliff), [local traces](/blog/dd-traces-local-otel), and [debugging agent workflows](/blog/debug-ai-agent-workflows), this is the same argument with a hosted platform attached. LangSmith Fleet is not just "no-code agents." It is LangChain's bet that the agent runtime, observability layer, and operations surface are becoming one product. ## What changed in June The official [June 2026 LangChain newsletter](https://www.langchain.com/blog/june-2026-langchain-newsletter) highlights five LangSmith updates that fit together: | Update | Practical meaning | |---|---| | Fleet On-Call Copilot | A prebuilt agent template for triaging alerts with code, traces, and runbooks | | Computer use in Fleet | Agents can operate an isolated virtual computer for files, code, and authenticated API calls | | Voice traces | Audio debugging gets trace-level visibility into active spans | | Experiment status tracking | Long eval runs expose live progress instead of opaque waiting | | Slack notifications for Engine | Agent-improvement issues can land where teams already work | The [LangSmith changelog](https://docs.langchain.com/langsmith/changelog) fills in the operational details around that story. Fleet picked up MCP OAuth improvements, protocol-version handshakes, Slack interrupt notifications, custom OAuth callback support, agent sharing controls, access profile creation from chat, and fixes for long-running agent runs that previously cut off after 60 seconds. Individually, these are product improvements. Together, they look like a control surface for agent work. That is the right direction. A production agent is not a chat transcript. It is a running system with identity, tools, traces, retries, costs, approvals, incidents, evals, and humans in the loop. ## The useful concept is agent on-call Most teams already know how to run software on call: - alert fires - dashboard opens - runbook gets checked - owner investigates - mitigation is proposed - update is posted - post-incident work becomes tickets or tests Agents need the same shape. The difference is that the agent can participate in the investigation instead of only producing a summary after the fact. That is what makes the On-Call Copilot template interesting. The newsletter describes it as an agent that works through code, traces, and runbooks to triage alerts and draft updates for review. The review part is important. This is not "the agent fixes production while everyone sleeps." It is "the agent gathers evidence, proposes a read, and hands it to the human operator." That is a healthier pattern than full autonomy for most teams. It keeps the agent inside a role the organization already understands: first responder assistant, not unbounded production actor. It also matches the lesson from [long-running agents need harnesses](/blog/long-running-agents-need-harnesses). Reliability improves when the agent has a loop around it: scoped tools, receipts, checkpoints, evals, and a reviewer who can see what happened. ## Computer use makes the sandbox a first-class operator tool The other June feature that matters is computer use in Fleet. LangChain's [Fleet overview docs](https://docs.langchain.com/langsmith/fleet) frame Fleet as a no-code platform for creating and managing agents from templates, connected accounts, approvals, and chat surfaces. The newsletter adds that Fleet agents can now use an isolated virtual computer for code, files, and authenticated API calls. That is a big boundary change. Traditional agent tools are API-shaped. The model calls `searchTickets`, `getTrace`, `createPullRequest`, or `sendSlackMessage`. Computer use adds a broader escape hatch: the agent can operate software surfaces that do not have clean APIs, or that require stateful file and browser workflows. That is powerful, but it changes the safety model: | Old question | New question | |---|---| | Which API tools can the agent call? | Which applications and files can the virtual computer reach? | | Which token did the tool use? | Which authenticated sessions exist inside the sandbox? | | Did the tool return the expected shape? | Can the action be replayed from screenshots, files, and traces? | | Can we revoke this connector? | Can we reset or snapshot the whole work environment? | The sandbox becomes part of the control plane. That connects directly to [sandboxed agents as a control surface](/blog/sandboxed-agents-control-plane) and [OpenAI's June API control-plane upgrades](/blog/openai-api-control-plane-june-2026). The recurring theme is simple: if agents can act, the environment they act inside needs to be inspectable. ## Traces are becoming the shared language LangSmith's advantage is that LangChain has spent years making traces the center of the workflow. For simple chat apps, traces are nice. For production agents, traces are table stakes. You need to know: - which instruction the agent followed - which tool it called - which result came back - where latency accumulated - where cost accumulated - where a human interrupted or approved the run - whether the same failure repeats across users The June updates reinforce that. Voice traces add span-level visibility to audio interactions. Experiment status tracking makes evaluation progress visible while runs are still executing. Engine issue notifications put agent-improvement work into Slack. Changelog entries around trace retention and feedback correction keep tightening the observability workflow. That is the right kind of boring. The hard part of agent ops is not generating a trace. It is making the trace useful enough that a human can debug the system faster than they could by reading logs and guessing. That is the bar I would use when comparing LangSmith against [local OTEL-style tooling](/blog/dd-traces-local-otel), [TraceTrail-style replays](/blog/agent-replays-with-tracetrail), or a homegrown event log. ## MCP auth is an operations feature, not a demo feature The Fleet changelog also calls out remote MCP authorization improvements. Fleet now handles MCP servers whose authorization server requires client-secret authentication at the token endpoint. It also sends the negotiated MCP protocol version during the handshake and during tool calls, so servers that require newer protocol behavior can accept requests cleanly. That sounds niche until you try to run agents across a real organization. MCP is attractive because it turns tools into a common interface. It is risky because every connector is also a permission boundary. If the auth flow is brittle, users work around it. If the protocol negotiation is invisible, failures look like model failures. If the connecting application is shown as a raw client ID instead of a recognizable app, humans approve things they do not understand. This is why [MCP zero-touch OAuth](/blog/mcp-zero-touch-oauth-enterprise-auth) and [agent capability ledgers](/blog/agent-containment-capability-ledger) keep coming up. Tool access is not plumbing. It is the runtime permission model. Fleet's recent MCP work is a sign that agent platforms are moving past "can the model call a tool" toward "can an admin understand and govern which tool got called, by whom, through which authorization flow." ## The opposing view: this may be too much platform There is a reasonable counterargument: agent teams may not want their builder, fleet manager, tracing system, eval runner, deployment surface, sandbox, Slack integration, and improvement engine inside one vendor platform. That concern is real. LangSmith is most compelling if your stack already uses LangChain or LangGraph, your team wants a managed operations surface, and you are comfortable with a hosted product becoming the source of truth for traces and evals. If you are building a lightweight TypeScript app, [Vercel AI SDK 7](/blog/vercel-ai-sdk-7-production-agents) may be a cleaner fit. If your main goal is local-first inspection, a smaller tracing tool may be faster. If your organization requires custom retention, network isolation, or self-hosting, every managed feature needs a procurement and security review. The second risk is abstraction drift. A Fleet agent that can use Slack, Gmail, MCP servers, Salesforce, and a virtual computer is useful only if the permissions stay understandable. Once the tool graph gets too broad, the operator loses the thread. The mitigation is not to avoid platforms. It is to keep each agent role narrow: - one job - one owner - one approval policy - one trace project - one eval set - one incident class Broad agent platforms work best when the agents themselves stay boring. ## How I would evaluate Fleet If I were testing LangSmith Fleet for an engineering team, I would not start with a generic "company assistant." I would start with one operational workflow: 1. Pick a recurring alert class with decent runbooks. 2. Create a Fleet agent that can read the relevant traces, docs, and issue history. 3. Give it read-only access first. 4. Require human approval for every external action. 5. Have it draft the incident update and suggested next step. 6. Convert accepted and rejected drafts into eval examples. 7. Track whether time-to-triage improves without increasing false confidence. That last point is the whole game. The metric is not "the agent answered." The metric is whether the agent made the operator faster while leaving better evidence behind. For teams already running LangGraph, LangSmith Deployment, or LangSmith evals, Fleet can become the human-facing layer on top of that machinery. For teams still comparing frameworks, pair this with [LangChain vs Vercel AI SDK](/blog/langchain-vs-vercel-ai-sdk) and [managed agents vs LangGraph vs DIY](/blog/managed-agents-vs-langgraph-vs-diy-2026) before committing. ## The bigger pattern The agent market is converging on the same product shape from different directions. OpenAI is adding identity, admin controls, moderation scores, prompt-cache retention policy, and Secure MCP Tunnel. Vercel is adding typed tool context, workflow durability, approvals, realtime, and telemetry to AI SDK 7. LangChain is adding Fleet, on-call templates, computer use, trace improvements, MCP auth, Slack interrupts, and deployment education. Different stacks, same direction: agents need operations surfaces. That is the piece worth paying attention to. The next wave of agent tooling will not be won only by better model calls. It will be won by the systems that make agent work observable, governable, interruptible, and easy to improve after production behavior exposes the weak spots. LangSmith Fleet is one of the clearest examples of that shift because it starts where teams already feel pain: alerts, traces, runbooks, Slack, evals, and approvals. That is not glamorous. It is useful. ## FAQ ### What is LangSmith Fleet? LangSmith Fleet is LangChain's no-code platform for creating, sharing, and managing AI agents. It supports templates, connected accounts, approvals, chat surfaces, Slack, MCP servers, and managed agent workflows inside the broader LangSmith platform. ### What is the Fleet On-Call Copilot? Fleet On-Call Copilot is a LangSmith template introduced in the June 2026 newsletter. It is designed to triage alerts using code, traces, and runbooks, then draft updates for human review. ### Does LangSmith Fleet replace LangGraph? No. LangGraph is the orchestration runtime for building stateful agent workflows. Fleet is a higher-level management and no-code surface for creating and operating agents. Teams can use Fleet alongside LangGraph, LangSmith Deployment, tracing, and evals. ### Why does computer use matter for Fleet agents? Computer use lets a Fleet agent operate inside an isolated virtual computer for code, files, and authenticated API calls. That expands what the agent can do, but it also makes sandbox permissions, replayability, and approvals more important. ### Is LangSmith Fleet only useful for LangChain teams? It is most natural for teams already using LangChain, LangGraph, or LangSmith, but the operational pattern applies broadly. Any production agent stack needs traces, evals, approvals, tool permissions, incident workflows, and a way to improve from real behavior. ## Sources - [LangChain: June 2026 LangChain Newsletter](https://www.langchain.com/blog/june-2026-langchain-newsletter), checked June 29, 2026. - [LangSmith Fleet documentation](https://docs.langchain.com/langsmith/fleet), checked June 29, 2026. - [LangSmith changelog](https://docs.langchain.com/langsmith/changelog), checked June 29, 2026. - [LangSmith usage documentation](https://docs.langchain.com/langsmith/view-usage), checked June 29, 2026. - [LangSmith full-platform self-hosting documentation](https://docs.langchain.com/langsmith/deploy-self-hosted-full-platform), checked June 29, 2026.

Using Claude Code for a Second Opinion on MRI Scans - What Actually Happened

Developers Digest — Sun, 28 Jun 2026 00:00:00 GMT

A developer named Antoine recently published an experiment that caught fire on Hacker News: he fed 266MB of DICOM MRI data from his right shoulder into Claude Code (Opus 4.8) to get a second opinion on his orthopedist's diagnosis. The result? The AI disagreed with the human doctor. And the ensuing HN discussion - with actual radiologists weighing in - reveals a lot about where AI medical imaging stands today. ## What Antoine Did The setup was straightforward. Antoine had been dealing with right shoulder pain for two to three weeks. His doctor diagnosed a "Grade III (>50%-width) partial-thickness tear at the apical insertion" of the subscapularis tendon - a significant rotator cuff injury that typically leads to aggressive treatment. Rather than accept this at face value, Antoine: 1. Exported his full MRI as DICOM files (266MB, hundreds of individual files) 2. Pointed Claude Code at the data 3. Let the AI install necessary packages for medical image analysis 4. Gave minimal clinical context: just "right shoulder pain for 2-3 weeks" Claude developed a methodical analysis strategy, writing code to process the imaging data and examining it from multiple perspectives. ## The Disagreement Here's where it gets interesting. The human radiologist saw a significant partial tear. Claude Code reported an "intact tendon" - essentially no tear at all. When Antoine had Claude arbitrate between the two readings (providing both reports plus clinical test results), the AI concluded with "moderate-to-high confidence" that the evidence favored its own reading: "Mild insertional tendinosis; NO discrete partial- or full-thickness tear." Antoine was left in diagnostic limbo. As he put it, the AI second opinion suggested the human-recommended treatment plan was "premature and more intervention-heavy than the facts seemed to justify." But he also acknowledged uncertainty about fully trusting AI for medical interpretation. ## What HN Is Saying The thread exploded with 368+ comments, and the discussion divided into several camps. **Radiologists pushed back hard.** One actual radiologist commented: "I can't really weigh in without seeing the full 3D MRI dataset." They pointed out a critical technical detail - ultrasound (which Antoine had also gotten) isn't great for detecting calcification and will miss small calcifications that would show on X-ray or MRI. Multiple commenters noted that MRI is a 3D medium, and slicing it incorrectly can miss features entirely: "I would not be at all surprised if one could slice an MRI the wrong way to produce a 2D image that fails to show a feature that exists in the source data." **The "Claude is bad at images" camp appeared.** Several commenters argued that Claude specifically underperforms on image understanding compared to other frontier models. One wrote: "Claude is the worst FM at image understanding. Prior to gpt-5.4 the only usable models were Gemini and Qwen." Others countered that Claude handles some image types well, particularly PDF-to-markdown conversion and document understanding - but medical imaging is a different beast. **The sonography vs radiology distinction came up.** A cardiac sonographer offered perspective: "Medical imaging is one of those things everyone thinks is simple because they don't know what they don't know. Any comment that doesn't start with 'I'm a radiologist' should be taken with a grain of salt." **The "AI second opinions help catch missed things" camp.** Some shared stories of AI helping catch procedural errors or outdated treatment plans. One person described using AI-generated questions to push a GP who was mishandling their mother's care - and it worked. **The "this is a nightmare for doctors" camp.** Multiple commenters argued that patients approaching doctors with AI-generated diagnoses creates friction: "Nightmare because users approach LLMs with the false confidence that they're always right, and present LLM outputs as fact to Doctors who have to waste time explaining that it's wrong most of the time." ## The Technical Reality Several important technical points emerged from the discussion: **MRI complexity matters.** 2D MRI scans have gaps between slices (typically 10% of slice thickness). 3D scans don't have gaps but are slower and more prone to movement artifacts. The voxels in 3D scans might be 1mm x 1mm x 1mm - which sounds precise until you realize subtle tears can be smaller than that. **Prompting affects diagnosis.** One researcher noted: "Subtle changes in prompts can cause different diagnosis." The exact wording you use when asking an AI about medical images meaningfully changes the output. **Modality matters.** When a radiology report says something "isn't present," there's always an implicit caveat that the finding isn't present within the context of that specific imaging modality. An ultrasound saying "no calcifications" and an X-ray showing calcifications can both be correct - the ultrasound just can't see small ones. ## Why This Matters for Developers This isn't really a story about whether you should trust AI for medical diagnosis (you shouldn't, not yet, not without human verification). It's a story about the current frontier of multimodal AI and where the edges are. A few takeaways: **The capability gap is real but narrowing.** Two years ago, asking any LLM to analyze raw DICOM files would have been absurd. Now Claude Code can install packages, write analysis code, and produce a structured medical reading. The reading might be wrong, but the workflow exists. **Domain expertise still matters.** The radiologists in the thread could immediately identify limitations that a non-specialist wouldn't know to ask about - 2D vs 3D acquisition, slice gaps, modality-specific blind spots. AI doesn't yet surface these caveats reliably. **Second opinions have value, even imperfect ones.** Antoine's doctor recommended shockwave therapy for a condition that recent clinical guidelines say doesn't respond to it (rotator cuff tendinopathy without calcification). Even if Claude's diagnosis is wrong, the friction of having a second opinion made Antoine dig deeper. **The probabilistic nature cuts both ways.** As one commenter put it: "Not quite. An LLM generates text that would likely follow... A patient in pain with a bone protruding from their shin has a... 'broken leg.' The more training data, the more questions it can answer with a reasonable degree of probability of accuracy." The counterpoint: "It can be helpful in your understanding the choices made by asking questions and thus in reassurance, but it requires something most people lack: understanding you are likely wrong since you are just collecting information without understanding it." ## The Bigger Picture What's notable about this story isn't that Claude Code can read MRIs (it can, sort of). It's that the experiment is now cheap and accessible enough that a solo developer can run it on a weekend, publish results, and get hundreds of HN comments including feedback from actual radiologists. That feedback loop - AI output, expert critique, public discussion - is how capabilities actually improve. The radiologist comments are training data for the next iteration of these models, whether directly or through the discourse they generate. For now, the prudent approach is obvious: AI as a thinking aid, not a replacement for professional judgment. But the gap is closing faster than the medical establishment is adapting. Antoine ended his post in diagnostic limbo, uncertain whether to trust the AI or the doctor. That uncertainty is probably the healthiest response right now. ## Sources - [Original article by Antoine](https://antoine.fi/mri-analysis-using-claude-code-opus) - [Hacker News discussion](https://news.ycombinator.com/item?id=48708941) (368+ comments)

GLM 5.2 Outperforms Claude Code on Semgrep's IDOR Vulnerability Benchmarks

Developers Digest — Sun, 28 Jun 2026 00:00:00 GMT

Semgrep's security research team published benchmark results that caught Hacker News's attention: the Chinese open-weight model GLM 5.2 beat Claude Code on IDOR (Insecure Direct Object Reference) vulnerability detection - and did it at roughly one-sixth the cost per finding. The headline number: GLM 5.2 scored 39% F1 versus Claude Code's 32%, with no scaffolding or multi-agent system. Just a prompt and a model. ## The Benchmark Setup Semgrep tested multiple models on a specific security task: finding IDOR vulnerabilities in real, open-source applications. IDOR is a common web vulnerability where an application exposes internal identifiers (like user IDs or order numbers) without proper authorization checks, letting attackers access other users' data by manipulating those identifiers. The researchers held several things constant: - The same IDOR dataset (real applications from prior research) - The same evaluation method (F1 scoring) - The same system prompt What varied was the model and the harness (the wrapper code that orchestrates the model). ## The Results | Rank | Model | Harness | F1 Score | |------|-------|---------|----------| | 1 | Semgrep Multimodal (GPT 5.5) | Custom Semgrep | 61% | | 2 | Semgrep Multimodal (Opus 4.8) | Custom Semgrep | 53% | | 3 | GLM 5.2 | Pydantic AI | 39% | | 4 | Claude Code (Opus 4.6) | Claude SDK | 37% | | 5 | Claude Code (Opus 4.8/4.7) | Claude SDK | 28% | The key insight: GLM 5.2 with minimal guidance (just a prompt via Pydantic AI) outperformed Claude Code by 7 points. The cost? Approximately $0.17 per vulnerability found - about one-sixth what frontier models cost. Semgrep's own multimodal pipeline with GPT 5.5 still wins overall at 61%, but that system includes endpoint discovery, code filtering, and other scaffolding. The comparison shows what raw model capability looks like versus engineered systems. ## What HN Is Saying The thread drew 59+ comments with strong opinions on both sides. **The skeptics called it marketing.** Several commenters noted the narrow scope: "It reads like an ad. Secondly these are 'just' IDORs, arguably the easiest class of vulnerabilities. Thirdly it compares to GPT 5.5 and Opus 4.8. No, we don't have Mythos at home." The critique is valid - Semgrep explicitly noted this evaluates a single task and may not generalize to other vulnerability types like SSRF. **The open-weight advocates pushed back.** Multiple commenters argued that the benchmark's limitations don't diminish its value. One wrote: "GLM5.2 is in the room with us, today. Mythos is not. And for us in the EU, it's even more complicated, as Mythos might be with us in the room one day, and go poof the next day, on the whims of political entities that we have 0 control over." Another: "In my experience, GLM 5.2 is extremely good at finding vulnerabilities, and more importantly, unlike Opus, I've never seen it refuse a command." **The export control discussion emerged.** One commenter predicted: "GLM export controls incoming? I predict Commerce will force OpenRouter, HuggingFace to take some open models down within the next few months." This sparked a thread about the absurdity of the US trying to export-control a Chinese model. Others noted that any such restrictions would only affect American companies while attackers continue using whatever tools they want: "If that happens it'll be an absolute disaster. Imagine a scenario where Anthropic and OpenAI prohibit most US companies from using their latest models because of safety... And meanwhile attackers use equivalent open source models to attack US companies." **The harness vs model distinction came up.** A sharp commenter pointed out: "Claude Code is an agent harness, not an LLM. Claude is a brand (or group of models), not an LLM." The benchmark title conflates these - but the article author acknowledged this and argued Claude Code pricing is the best proxy for amortized inference costs. **Practical experiences surfaced.** One developer shared weekend results: "I have taken another look on these open models after the fiasco of Fable and GPT 5.6 this weekend and... GLM-5.2 truly is a good workhorse model for daily programming. I consider myself a heavy user of LLMs and a seasoned developer. A typical session for me with GPT is usually over a hundred dollars... Two days later and 20 dollars poorer I have what I need: a multimodal agent written in rust that has access to my homelab." ## The Technical Context Several technical points emerged from both the article and discussion: **GLM 5.2 is massive.** At 753 billion parameters, running it locally requires serious hardware. Commenters discussed 8x RTX 6000 setups costing $80-100k. For most developers, API access through providers like Fireworks or OpenRouter makes more sense than local deployment. **The scaffolding gap is real.** Semgrep's 61% result with GPT 5.5 includes endpoint discovery, code filtering, and multi-agent orchestration. GLM 5.2's 39% is with essentially zero scaffolding. The question is whether wrapping GLM 5.2 in similar tooling would close that gap. **Safety guardrails may affect results.** One commenter noted that Claude Code with Opus 4.8 actually performed worse (28%) than with older Opus versions (37%). This could be due to increased safety restrictions on newer models - a recurring theme where safety training potentially reduces capability on security research tasks. **Self-training loops are emerging.** A security researcher noted: "These numbers seem pretty low compared to what I was able to achieve specifically around windows kernel... GLM 5.2 is already capable enough to assist in self-training which is similar to what we saw happen with frontier models and they appear to be getting there at a significantly lower cost than OpenAI/Anthropic." ## Why This Matters The benchmark reveals a few important trends: **Open weights are catching up.** Not across the board, not on every task, but on specific workloads - including security-relevant ones - open models now compete with frontier providers. At 39% F1 versus 28-37%, GLM 5.2 isn't just close; it's ahead of Claude Code on this task. **Cost matters for security.** At $0.17 per vulnerability versus $1+ for frontier models, the math changes for automated security scanning. You can run six times as many scans for the same budget, or cover six times as much code. **The model vs system distinction is blurring.** What beats what depends heavily on the harness. Semgrep's multimodal pipeline with GPT 5.5 destroys everything else at 61%, but that's a product, not a raw model capability. As agentic tooling improves, the "which model wins" question becomes less important than "which system architecture wins." **Regulatory risk is emerging.** The thread's discussion of potential export controls on Chinese AI models reflects growing tension between open-source AI development and national security concerns. Whether such controls would be effective (or even enforceable) is debatable, but the fact that people are discussing it signals a shift. ## The Bottom Line Semgrep's benchmark is narrow - one vulnerability type, one evaluation method - but the signal is clear: open-weight models have reached competitive parity on at least some security tasks, at a fraction of frontier model costs. For security teams doing automated vulnerability scanning, the implication is worth exploring. GLM 5.2 through providers like Fireworks offers a cost-effective alternative that - on this specific task - outperforms Claude Code. For the broader AI development community, it's another data point in the ongoing debate about open versus closed models. The capability gap that justified frontier model pricing is narrowing faster than some expected. ## Sources - [Semgrep blog: "We Have Mythos at Home - GLM 5.2 Beats Claude in Our Cyber Benchmarks"](https://semgrep.dev/blog/2026/we-have-mythos-at-home-glm-52-beats-claude-in-our-cyber-benchmarks/) - [Hacker News discussion](https://news.ycombinator.com/item?id=48709670) (59+ comments) - [GLM 5.2 on Hugging Face](https://huggingface.co/zai-org/GLM-5.2)

OpenAI's June API Updates Are Really a Control-Plane Upgrade

Developers Digest — Sun, 28 Jun 2026 00:00:00 GMT

OpenAI's June API changelog is easy to read as a pile of unrelated entries. Moderation scores landed in the Responses API. Container sessions moved to per-minute billing. OpenAI models showed up behind an OpenAI-compatible Responses endpoint on Amazon Bedrock. Prompt cache retention changed. Admin APIs got spend, model, retention, hosted-tool, and billing controls. Workload identity federation removed another reason to park long-lived API keys in production. Secure MCP Tunnel gave enterprise teams a way to connect private tools without putting them on the public internet. That is not random plumbing. It is the shape of an agent control plane. **Last updated:** June 28, 2026 The model news will always get more attention, but production teams do not fail because they forgot to name the newest model. They fail because nobody can answer boring questions cleanly: - Which workload called the model? - Which tools could it reach? - Which models were allowed? - What did the run cost? - Was input and output moderated? - Did a private MCP server need public exposure? - How long did prompt cache data stick around? - Did hosted containers bill like a fixed block or an actual job? OpenAI's late-May and early-June platform updates start answering those questions. That matters for anyone building on the [Responses API](/blog/openai-responses-api-migration), running [Codex](/blog/openai-codex-managed-agents-aws-2026), comparing [OpenAI versus Anthropic](/blog/openai-vs-anthropic-2026), or trying to make agent infrastructure boring enough for a real platform team. ## The Useful Pattern: More Knobs Before More Autonomy The agent market loves autonomy language. The platform work that makes autonomy usable is less glamorous: identity, spend controls, allowlists, moderation, private networking, billing granularity, and audit surfaces. That is the frame for these updates: | Update | What it controls | Why agent teams should care | |---|---|---| | Workload identity federation | Authentication | Replace long-lived keys with short-lived workload tokens | | Admin API expansion | Org policy | Manage spend alerts, model allowlists, retention, hosted-tool permissions, and billing lines | | Secure MCP Tunnel | Private tools | Connect private MCP servers without exposing them publicly | | Moderation scores | Safety gates | See input and output moderation results in the generation response | | Container per-minute billing | Runtime cost | Align hosted tool cost with shorter tasks | | 24h prompt cache retention default | Latency and cost | Improve reuse for non-ZDR orgs, with a data-retention tradeoff | | Bedrock Responses endpoint | Enterprise routing | Let AWS-centered teams use OpenAI models through Bedrock patterns | None of these replaces an application architecture. Together, they move OpenAI's API surface closer to the operational layer teams already expect from cloud infrastructure. That is the difference between "we can call a model" and "we can let an agent act inside a governed system." ## Workload Identity Is the Key-Rotation Story The most obviously enterprise-shaped update is [workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation). OpenAI describes it as a way for trusted workloads to exchange externally issued identity tokens for short-lived OpenAI access tokens. That sounds like identity plumbing because it is. It is also exactly the kind of plumbing that makes agent workloads easier to approve. The older pattern is familiar: 1. Create an API key. 2. Store it in a secret manager. 3. Inject it into jobs, containers, CI, or serverless functions. 4. Rotate it on a calendar, after an incident, or not often enough. Workload identity changes the ownership model. A workload running in a cloud or Kubernetes environment can prove what it is using its native identity layer, then receive a short-lived OpenAI credential. The application no longer needs to carry a standing secret for every call. This is not a flashy developer-experience feature. It is a procurement feature, a security-review feature, and a blast-radius feature. For agents, the blast-radius angle is the important one. A long-running tool-using agent should not inherit a permanent organization credential just because it needs to call a model. Short-lived workload credentials make it easier to scope, revoke, and reason about the execution environment. That connects directly to the argument in [AI agent containment needs a capability ledger](/blog/agent-containment-capability-ledger): the hard part is not only sandboxing. It is proving which actor had which capability at the moment it acted. ## Admin APIs Turn Policy Into Something Agents Can Obey OpenAI's May 26 changelog entry says the [Admin API](https://developers.openai.com/api/docs/guides/admin-apis) gained capabilities for spend alerts, model allowlists, data retention settings, hosted tool permissions, and granular billing line items. That list is easy to skim past. It is also the list platform owners need before they let agent workloads spread. Spend alerts matter because agent loops can turn a mistake into a bill. Model allowlists matter because not every workload should be free to pick the most expensive or least-reviewed model. Data retention settings matter because agent prompts often include private code, customer context, logs, or business data. Hosted tool permissions matter because a model call with shell, code execution, file search, or web search is not the same risk as a plain text completion. Billing line items matter because aggregate spend is not enough when multiple products, teams, and automated jobs share one provider. That is why this update is more interesting than a dashboard screenshot. API-controlled policy can be wired into platform workflows: - pre-production checks that confirm a project has the right model allowlist - deployment gates that fail if hosted tools are broader than expected - daily spend anomaly jobs that watch agent projects separately from human chat usage - quarterly retention reviews that can be checked in code - per-product cost attribution that does not depend on humans tagging every run manually The same theme shows up in [frontier model API pricing](/blog/frontier-model-api-pricing-june-2026): price tables are not enough. Teams need budget controls that match the way agents actually run. ## Secure MCP Tunnel Is the Private-Tools Story MCP has the right developer shape: tools live behind a protocol instead of inside every prompt. The enterprise objection is just as obvious: many useful tools are private. OpenAI's [Secure MCP Tunnel](https://developers.openai.com/api/docs/guides/secure-mcp-tunnels) addresses that gap for enterprise customers by using a customer-hosted tunnel client. The pitch is straightforward: supported OpenAI products can connect to private or on-prem MCP servers without the customer exposing those servers to the public internet. This is the practical version of a problem we covered in [zero-touch OAuth for MCP](/blog/mcp-zero-touch-oauth-enterprise-auth). Tool access is not only a protocol problem. It is a network, identity, authorization, and audit problem. The strongest argument for the tunnel is not convenience. It is separation of concerns: - OpenAI-hosted products do not need direct public access to internal tools. - The customer keeps a controlled tunnel endpoint in their environment. - MCP servers can remain inside private networks. - Platform teams can review one connection pattern instead of many one-off public exposures. There is a tradeoff. A vendor-specific tunnel is not the same thing as a portable MCP deployment story. Teams that want provider-neutral agent infrastructure still need to ask how this compares with direct MCP server hosting, private gateways, and client-side agent runtimes. But for companies already standardizing on OpenAI products, Secure MCP Tunnel answers a real blocker: "How do we let the agent use internal tools without publishing the tools?" ## Moderation Scores Move Safety Into the Response Path On June 4, OpenAI added moderation scores to both the Responses API and Chat Completions API. The changelog says developers can pass a `moderation` object and receive moderation results for both model input and generated output in the same response. That is a small API shape with a large product implication. Many agent systems treat safety as a separate pre-flight or post-flight call. That can work, but it often creates awkward plumbing: one call for input moderation, one generation call, another moderation call, then an application-specific decision about whether to show, store, retry, escalate, or block. Putting moderation results into the response path makes the safety signal easier to attach to the run record. That matters for: - customer-support agents that need output review - code agents touching security-sensitive repositories - internal assistants that summarize private documents - tool-using agents that should escalate risky turns - evaluation pipelines that need to compare safety behavior across model and prompt changes The key is not to treat the score as a magic permission slip. It is a signal. The application still needs policy: what thresholds block output, what thresholds route to a human, what gets logged, and what gets dropped. This is the same reason [agent evals need baseline receipts](/blog/agent-evals-need-baseline-receipts). A system is only governable if the decision points leave evidence. ## Container Billing Finally Matches Short Jobs Better The June 2 pricing change is easy to underrate. OpenAI says eligible container sessions now bill per minute with a five-minute minimum instead of the full 20-minute session rate. The underlying per-minute rate stays the same. For hosted tool and agent workflows, that changes the cost shape. Many agent jobs are bursty. They need a shell, a code interpreter, or a short-lived execution environment for a few minutes, not a 20-minute block. Fixed session billing punishes short tasks and encourages awkward batching. Per-minute billing with a five-minute floor is still not free, but it is closer to how these jobs actually run. The practical takeaway is simple: revisit the economics of short hosted-tool workflows before assuming a self-hosted sandbox is always cheaper. This does not remove the need for cost controls. If anything, it makes them more important because shorter jobs become easier to justify. Pair the pricing change with the Admin API's spend and billing controls, then decide which tasks belong in hosted containers and which belong in your own runtime. ## Prompt Cache Retention Is a Cost Win With a Governance Footnote On May 29, OpenAI changed `prompt_cache_retention` so that organizations without zero data retention enabled default to `24h` instead of `in_memory`. The reason is clear: longer cache retention can improve reuse, latency, and effective cost for repeated prompts. For agent teams, that is useful. Agents often reuse the same system instructions, tool definitions, rubric blocks, repository context, or policy preambles. Better cache reuse can make repeated runs cheaper and faster. But the default deserves a governance note. Longer retention is not only an optimization. It is a data-handling choice. If your organization is not on ZDR, ask: - Which prompts are cacheable? - Do system prompts include private policy or customer data? - Are repository summaries, logs, or traces being reused? - Does the retention behavior match your internal data classification? - Should sensitive workflows override defaults? The tradeoff is not scary by itself. It just needs to be deliberate. Cost and latency improvements should not sneak in as unreviewed retention policy. ## The Bedrock Piece Is About Procurement, Not Just Models OpenAI's June 1 changelog says OpenAI models are available in Amazon Bedrock through an OpenAI-compatible Responses API endpoint, with supported models and features varying by AWS Region. That is not just a routing option. For some teams, it changes the buying path. AWS-centered organizations often care less about whether an API call is aesthetically pure and more about whether it fits existing identity, billing, procurement, networking, and compliance workflows. Bedrock can make the OpenAI conversation easier for teams already operating inside AWS controls. This also sharpens the competition with Anthropic. We have covered cases where Bedrock routing creates real boundary questions for Claude's newer models, especially around data retention and regulated workloads. OpenAI's Bedrock path should be evaluated on its own exact feature and region limits, but the direction is clear: model providers are fighting for the enterprise control plane, not only the benchmark chart. ## What To Do With This If You Build Agents If your team is already on OpenAI, do not treat these updates as changelog trivia. Turn them into a platform checklist: 1. Replace standing API keys in production agents with workload identity where available. 2. Split human, CI, batch, and autonomous-agent projects so billing and policy are visible. 3. Use model allowlists instead of letting every workload choose every model. 4. Review hosted tool permissions separately from model permissions. 5. Decide whether 24-hour prompt cache retention is acceptable for each workload class. 6. Attach moderation scores to run records where safety review matters. 7. Put private MCP servers behind a governed tunnel or gateway, not a public quick fix. 8. Recalculate hosted container costs for short jobs under the new five-minute floor. That checklist is the story. The more autonomy you give an agent, the more boring the surrounding platform needs to become. ## FAQ ### What changed in OpenAI's June 2026 API updates? OpenAI added moderation scores to generation responses, changed eligible container sessions to per-minute billing with a five-minute minimum, made OpenAI models available through an Amazon Bedrock Responses endpoint, and recently added workload identity federation, expanded Admin APIs, Secure MCP Tunnel, IP allowlist management, and longer prompt-cache retention defaults. ### Why do these updates matter for AI agents? Agents need more than model quality. They need identity, scoped tool access, cost controls, model allowlists, moderation signals, private-network access, retention policy, and billing attribution. These updates add pieces of that operational layer. ### Is Secure MCP Tunnel the same as self-hosting MCP servers? No. Secure MCP Tunnel is an OpenAI enterprise connection pattern that lets supported OpenAI products reach private MCP servers through a customer-hosted tunnel client. Self-hosting MCP servers is broader and may be more portable across providers, but it requires your own gateway, identity, and network design. ### Should every team use 24-hour prompt cache retention? No. Longer cache retention can improve cost and latency, but it is also a data-handling decision. Teams should review whether cached prompt content includes sensitive code, customer data, internal policy, or logs before relying on the default. ## Sources - [OpenAI API changelog](https://developers.openai.com/api/docs/changelog) - [OpenAI workload identity federation guide](https://developers.openai.com/api/docs/guides/workload-identity-federation) - [OpenAI Admin API guide](https://developers.openai.com/api/docs/guides/admin-apis) - [OpenAI Secure MCP Tunnel guide](https://developers.openai.com/api/docs/guides/secure-mcp-tunnels) - [OpenAI prompt caching guide](https://developers.openai.com/api/docs/guides/prompt-caching) - [OpenAI API pricing](https://developers.openai.com/api/docs/pricing)

Vercel AI SDK 7: The Production Agent Upgrade

Developers Digest — Sun, 28 Jun 2026 00:00:00 GMT

**Last updated:** June 28, 2026 | Official Sources | | |---|---| | [AI SDK 7 launch post](https://vercel.com/blog/ai-sdk-7) | Release overview, agent features, migration command | | [AI SDK docs](https://vercel.com/docs/ai-sdk) | Current SDK reference | | [AI SDK 7 migration guide](https://vercel.com/docs/ai-sdk/migration-guides/migration-guide-7-0) | Breaking changes and context migration | | [WorkflowAgent docs](https://vercel.com/docs/ai-sdk/agents/workflow-agent) | Durable agent execution | | [Introducing eve](https://vercel.com/blog/introducing-eve) | Vercel's open-source agent framework built on the SDK layer | ## AI SDK 7 is not just a chat SDK release Vercel shipped [AI SDK 7](https://vercel.com/blog/ai-sdk-7) on June 25, 2026, and the interesting part is not another hook for a chat box. The useful read is simpler: Vercel is moving the AI SDK from "stream tokens in a React app" toward "run agents with typed context, approvals, durable steps, telemetry, realtime sessions, and migration tooling." That matters because the TypeScript agent market is crowded now. You can build with [LangGraph](/blog/langchain-vs-vercel-ai-sdk), [Mastra](/blog/mastra-durable-typescript-agents), [eve](/blog/vercel-eve-framework-for-building-ai-agents), OpenAI's Agents SDK, or a direct model loop. The AI SDK 7 question is not "can it call a model?" Everyone can. The question is whether it gives product teams enough runtime structure to keep a model loop alive after the demo. My take: AI SDK 7 is strongest when you already want a TypeScript-first application layer and you want agent primitives without adopting a full graph framework. It is weaker if your core problem is multi-hour orchestration, language-agnostic workflows, or deeply stateful agent planning. For that, keep comparing it against [durable agent frameworks](/blog/managed-agents-vs-langgraph-vs-diy-2026) instead of treating the SDK as a complete platform by default. ## The five changes that matter The launch post lists a large surface area: reasoning control, tool context, runtime context, provider files, skills, MCP Apps, terminal UI, approvals, durability, timeouts, sandbox support, telemetry, lifecycle events, realtime voice, and video generation. That is a lot of product nouns. For developers, five changes matter most. First, tool context is now explicit and typed. Instead of passing one loose bag of hidden values into every tool, each tool can define its own `contextSchema`, and the caller passes matching values through `toolsContext`. This is the right shape for production. A customer lookup tool should not see the weather API key. A billing tool should not see the Slack token. Second, runtime context is separate from tool context. Shared request data such as `tenantId`, `requestId`, plan tier, region, or current workflow state can live in `runtimeContext`, while tool-private secrets stay scoped to the tool that needs them. Third, `WorkflowAgent` gives Vercel a durability story. The docs frame it around serializable runtime state and workflow-compatible execution. That is exactly where simple model loops break: the user closes the tab, the deployment rolls, the function times out, or the agent needs to wait for approval. Fourth, approvals and telemetry move closer to the agent loop. Approvals are not just a UI feature. They are the difference between "the model can call a tool" and "the model can request a risky action under a policy." Telemetry is the difference between reading logs after an incident and replaying what happened turn by turn. Fifth, realtime support is becoming provider-agnostic. AI SDK 7 adds experimental realtime primitives for browser WebSocket sessions, ephemeral tokens, audio transcription, and client-driven tool calls across OpenAI, Google, and xAI provider implementations. That is early, but it points to the same thesis as the rest of the release: normalize provider differences before they leak into every product surface. ## The migration is really about context boundaries The most important migration is from `experimental_context` to a split model: tool-specific `context` plus shared `runtimeContext`. The old pattern was convenient but too broad: ```ts const weather = tool({ inputSchema: z.object({ location: z.string(), }), execute: async ({ location }, { experimental_context }) => { const { weatherApiKey } = experimental_context as { weatherApiKey: string; }; return getWeather(location, weatherApiKey); }, }); ``` AI SDK 7 makes the boundary visible: ```ts const weather = tool({ inputSchema: z.object({ location: z.string(), }), contextSchema: z.object({ apiKey: z.string(), }), execute: async ({ location }, { context: { apiKey } }) => { return getWeather(location, apiKey); }, }); const result = await generateText({ model, tools: { weather }, prompt: "Will it rain in Toronto tomorrow?", runtimeContext: { requestId: "req_123", tenantId: "tenant_456", }, toolsContext: { weather: { apiKey: process.env.WEATHER_API_KEY!, }, }, }); ``` That looks like boilerplate until you connect it to agent security. A tool schema validates model-supplied input. A context schema validates developer-supplied runtime data. Keeping those worlds separate reduces accidental authority leakage. It does not solve [prompt injection](/blog/prompt-injection-agent-apps-practical-version), but it gives you a cleaner place to enforce boundaries. ## Where WorkflowAgent fits `WorkflowAgent` is the part to watch if you care about production agents rather than chat widgets. The current docs show it carrying `runtimeContext`, `toolsContext`, and per-step logic in a workflow-compatible shape: ```ts import { WorkflowAgent } from "@ai-sdk/workflow"; import { tool } from "ai"; import { z } from "zod"; const agent = new WorkflowAgent({ model: "anthropic/claude-sonnet-4-6", tools: { customerLookup: tool({ description: "Look up a customer account", inputSchema: z.object({ customerId: z.string(), }), contextSchema: z.object({ region: z.enum(["us", "eu"]), }), execute: async ({ customerId }, { context }) => { return lookupCustomer(customerId, context.region); }, }), }, runtimeContext: { tenantId: "tenant_123", requestId: "req_abc", plan: "enterprise", }, toolsContext: { customerLookup: { region: "us" }, }, prepareStep: ({ runtimeContext }) => { if (runtimeContext.plan === "enterprise") { return { temperature: 0.2 }; } return {}; }, }); ``` The architectural bet is obvious: the agent object should carry enough typed state to make each turn reproducible, inspectable, and resumable. That aligns with Vercel's broader [agentic infrastructure stack](/blog/vercel-agentic-infrastructure-stack): gateway, sandbox, workflows, observability, and application UI under one platform umbrella. If you are already building on Next.js, this is compelling. If you are deploying agents across Python services, queues, data pipelines, and non-Vercel infrastructure, treat it as a good SDK layer, not an automatic orchestration standard. ## Telemetry should be selective by default AI SDK 7 also documents selective telemetry for runtime and tool context. This is a small feature with a big operational implication. ```ts const result = await agent.generate({ prompt: "Check whether this customer is eligible for priority support.", runtimeContext: { requestId: "req_abc", tenantId: "tenant_123", userId: "user_123", }, telemetry: { includeRuntimeContext: { requestId: true, }, includeToolsContext: { customerLookup: { region: true, }, }, }, toolsContext: { customerLookup: { apiKey: process.env.CUSTOMER_API_KEY!, region: "us", }, }, }); ``` This is the right default posture: logs need enough context to debug a run, but not every tenant ID, user ID, or secret-adjacent value. If you are building an agent that touches customer data, make telemetry allowlists part of the implementation checklist. Do not add observability after the first weird tool call. ## The opposite view: AI SDK 7 may still be too platform-shaped There is a fair criticism here. AI SDK 7 makes Vercel's stack more coherent, but coherence can become gravity. If the best experience assumes AI Gateway, Vercel Workflows, Vercel Sandbox, Vercel Observability, and Next.js, teams may drift into a platform decision before they have made an architecture decision. That does not make the release bad. It means you should choose deliberately. Use AI SDK 7 when: - Your app is TypeScript-first. - You already use Next.js or Vercel. - You want streaming UI and agent loops in the same codebase. - Your tools need typed context boundaries. - Your agents are product features, not a separate distributed workflow system. Reach for LangGraph, Mastra, Temporal, or another durable workflow layer when: - Runs last minutes to hours. - State transitions matter more than token streaming. - You need language-agnostic orchestration. - You need explicit graph inspection and replay as the central abstraction. - Your infrastructure cannot depend on Vercel-managed runtime pieces. This is the same decision boundary from [Vercel AI SDK vs LangGraph](/blog/vercel-ai-sdk-6-vs-langgraph-typescript-agents), but AI SDK 7 moves the line. The SDK now covers more of the middle. It still does not erase the need for a workflow engine when workflows are the product. ## Search and demand notes I attempted a Google Trends check for the AI SDK 7 lane during this run, but the local environment did not have `pytrends` installed, and no reliable Trends rows were available. I am not going to invent relative interest numbers. The demand case is still strong enough to publish because the topic has: - A fresh primary-source release dated June 25, 2026. - Clear duplicate-safe differentiation from the existing [AI SDK guide](/blog/vercel-ai-sdk-guide). - Strong internal topical fit with [eve](/blog/vercel-eve-framework-for-building-ai-agents), [agentic infrastructure](/blog/vercel-agentic-infrastructure-stack), and [TypeScript agent architecture](/blog/how-to-build-ai-agents-typescript). - Durable search intent around `AI SDK 7`, `Vercel AI SDK migration`, `WorkflowAgent`, and `TypeScript agents`. The launch chatter will fade. The migration and architecture queries will not. ## FAQ ### What is new in Vercel AI SDK 7? AI SDK 7 adds production-oriented agent features: reasoning control, typed tool context, runtime context, WorkflowAgent durability, approvals, telemetry, lifecycle events, realtime voice support, video generation, MCP Apps, skills support, and migration tooling from AI SDK 6. ### Should I migrate from AI SDK 6 to AI SDK 7 immediately? Migrate quickly if you rely on tool context, agent loops, approvals, or telemetry. If your app only streams text into a chat UI and is stable, schedule the migration deliberately and run the official codemod plus your own regression tests. ### Is AI SDK 7 a replacement for LangGraph? Not fully. AI SDK 7 is stronger for TypeScript product apps that need model calls, tools, streaming UI, and moderate agent runtime structure. LangGraph is still a better fit when graph state, long-running orchestration, and explicit workflow inspection are the core of the system. ### What is WorkflowAgent? `WorkflowAgent` is AI SDK 7's durable agent primitive. It lets an agent carry typed runtime context, per-tool context, tools, and step preparation logic in a workflow-compatible form so runs can be made more resilient and inspectable. ### Does AI SDK 7 solve agent security? No. It improves the shape of agent security by separating model-supplied tool input from developer-supplied tool context and shared runtime context. You still need tool allowlists, approval gates, prompt-injection defenses, logging policy, and rollback paths. ## Sources - [Vercel: AI SDK 7](https://vercel.com/blog/ai-sdk-7), fetched June 28, 2026. - [Vercel AI SDK documentation](https://vercel.com/docs/ai-sdk), checked through Context7 on June 28, 2026. - [AI SDK 7 migration guide](https://vercel.com/docs/ai-sdk/migration-guides/migration-guide-7-0), checked through Context7 on June 28, 2026. - [WorkflowAgent documentation](https://vercel.com/docs/ai-sdk/agents/workflow-agent), checked through Context7 on June 28, 2026. - [Vercel: Introducing eve](https://vercel.com/blog/introducing-eve), fetched June 28, 2026. - Google Trends: attempted during automation run on June 28, 2026; no reliable local Trends rows were available, so no Trends numbers are cited.

Grok Build Developer Guide: xAI's Terminal Coding Agent (June 2026)

Developers Digest — Sat, 27 Jun 2026 00:00:00 GMT

**Last updated:** June 27, 2026. Grok Build is in public beta. Pricing and features are subject to change. Verify current details against the official xAI documentation before committing to a subscription. ## Official Sources | Topic | Official source | |-------|-----------------| | Grok Build CLI | [x.ai/cli](https://x.ai/cli) | | Installation | [x.ai/cli/install](https://x.ai/cli/install.sh) | | Announcement | [Introducing Grok Build](https://x.ai/news/grok-build-cli) | | API pricing | [xAI API pricing](https://x.ai/api#pricing) | | xAI documentation | [docs.x.ai](https://docs.x.ai/) | | SuperGrok subscription | [x.ai/grok](https://x.ai/grok) | xAI shipped Grok Build on May 14, 2026. It is a terminal-native coding agent with a clear architectural bet: parallelism over depth. Where Claude Code runs one powerful reasoning pass, Grok Build runs up to eight agents racing the same problem. Where Codex emphasizes cloud sandboxes, Grok Build runs local-first on your machine. This is the practical developer guide: installation, pricing, real commands, what the parallel architecture actually does, and where Grok Build fits against Claude Code and Codex CLI. ## What Grok Build Is Grok Build is an agentic CLI where you point it at a project directory, describe a task in plain English, and the agent inspects the repository, locates the relevant files, and proposes and applies changes. The workflow follows three stages: 1. **Plan.** The agent drafts an execution plan you can review and approve before any code is written. 2. **Search.** It searches the codebase to ground its changes in existing patterns and structure. 3. **Build.** It carries out the edits, running up to eight subagents in parallel for speed. The underlying model is `grok-build-0.1`, a purpose-built coding model with a 256K context window. The larger Grok-4.3 model with its 2M context window is available for complex reasoning tasks. ## Installation ### macOS and Linux ```bash curl -fsSL https://x.ai/cli/install.sh | bash ``` ### Windows PowerShell ```powershell irm https://x.ai/cli/install.ps1 | iex ``` After installation, navigate to your project directory and run: ```bash grok ``` The first run prompts for authentication via your X account or xAI API key. ## Pricing Grok Build requires an active xAI subscription or API access. As of June 27, 2026: | Tier | Monthly cost | Access level | |------|-------------|--------------| | X Premium+ | $40 | Basic Grok Build access | | SuperGrok | $30 | Standard Grok Build access | | SuperGrok Heavy | $299 ($99 intro) | Full parallel agent features | | API | Usage-based | $1.00/$2.00 per M input/output tokens | The SuperGrok Heavy tier is where the 8-agent parallelism lives. Lower tiers provide Grok Build access with reduced parallel capacity. For API usage, the `grok-build-0.1` model is priced at $0.20 per million input tokens, $2.00 per million output tokens. Cached input runs at $0.20 per million tokens. **What the pricing page does not tell you:** The $299 SuperGrok Heavy tier is comparable to Claude Code Max at $200 or ChatGPT Pro at $200. The introductory $99 rate expires after six months. Developers who try Grok Build on lower tiers may find the parallel features limited compared to the full Heavy experience. ## Core Commands ### Start a session ```bash grok ``` Opens an interactive session in the current directory. The agent reads your project structure and is ready for prompts. ### Run a single task ```bash grok exec "add pagination to the users API endpoint" ``` Non-interactive mode. The agent plans, executes, and exits. ### Plan mode ```bash grok plan "refactor the auth module to use JWT" ``` Generates a plan without executing. Review the plan, then run `grok apply` to execute. ### Goal mode (June 2026) ```bash grok goal "all tests pass and lint is clean" ``` Long-running autonomous mode. The agent plans work, executes until the condition is met, and verifies the result. Control with `grok goal status`, `grok goal pause`, `grok goal resume`, and `grok goal clear`. This is similar to Claude Code's `/goal` command - both support verifiable end conditions and autonomous execution. ## Parallel Subagents The architectural headline is parallelism. Grok Build can spawn up to eight subagents that run simultaneously on the same task. The use cases: - **Arena Mode:** Multiple agents race to solve the same problem. You pick the best output. - **Divide-and-conquer:** Different agents work on independent parts of a task. - **Redundancy:** Multiple attempts increase the odds of finding a working solution. Arena Mode is the flagship feature. Instead of trusting one agent's output, you get multiple competing solutions and select the winner. This catches errors that a single pass might miss. **How it differs from Claude Code:** Claude Code's subagents divide a task into different parts - one handles tests, one handles docs, one handles implementation. Grok Build's parallel agents race the same problem. Claude divides and conquers. Grok races for the best single answer. ## MCP Compatibility Grok Build supports Model Context Protocol for tool integration. Connect external services like databases, APIs, and development tools. ```bash grok mcp add github grok mcp add linear ``` The MCP support is newer than Claude Code's but growing. Check the xAI docs for the current list of supported MCP servers. ## Agent Communication Protocol (ACP) ACP is xAI's standard for external tools and IDEs to communicate with Grok Build. It enables integrations with VS Code, Cursor, JetBrains, and custom developer tools. This is useful for teams building workflows that span multiple tools. A VS Code extension can trigger Grok Build tasks, receive progress updates, and display results in the editor. ## Local-First Architecture Grok Build runs on your machine, not in a cloud sandbox. The agent reads your local files, executes commands locally, and applies changes directly. Benefits: - No code leaves your machine (except for API calls to xAI). - Works in sensitive offline environments after initial setup (air-gap compatible). - Full access to local tools, SDKs, and development environments. Tradeoffs: - No cloud isolation like Codex provides. - You are responsible for managing the execution environment. - Long-running tasks require your machine to stay active. ## Grok Build vs Claude Code vs Codex CLI The three main terminal coding agents take different architectural approaches: | Feature | Grok Build | Claude Code | Codex CLI | |---------|-----------|-------------|-----------| | Primary bet | Parallelism (8 agents) | Reasoning depth | Cloud sandboxes | | Context window | 256K (grok-build-0.1) | 200K+ (Opus/Sonnet) | 200K+ (GPT-5.x) | | Execution | Local-first | Local | Cloud or local | | Plan mode | Yes | Yes (plan mode) | Yes | | Goal mode | Yes (/goal) | Yes (/goal) | Yes (goal command) | | Parallel agents | 8 fixed racing | Dynamic subagents | Not emphasized | | Arena Mode | Yes | No | No | | MCP support | Yes | Yes | Limited | | Entry price | $30-40/mo | $20/mo | $20/mo | | Full features | $299/mo | $100-200/mo | $200/mo | **When to use Grok Build:** - You want multiple competing solutions for comparison. - Your tasks are well-scoped and benefit from speed over depth. - You are already in the xAI/X ecosystem. - You need air-gap compatibility for sensitive environments. **When to use Claude Code:** - Your tasks require deep multi-file understanding. - You need divide-and-conquer parallelism across different task parts. - You work on complex refactors where reasoning quality matters more than speed. **When to use Codex CLI:** - You want cloud isolation for untrusted code. - You need integration with the OpenAI ecosystem. - Your team uses ChatGPT Pro for other work. ## Benchmark Reality On Terminal-Bench 2.1: - Codex CLI (GPT-5.5): 83.4% - Claude Code (Fable 5): 83.1% - Grok Build (grok-code-fast-1): 70.8% On SWE-bench Verified: - Fable 5: 95.0% - GPT-5.5: 88.7% - Claude Code (Opus 4.7): 87.6% Grok Build trails on raw benchmark scores but benchmarks do not capture the Arena Mode advantage. For well-scoped tasks where multiple attempts increase success probability, the parallel architecture compensates for lower single-pass accuracy. ## Practical Patterns ### Arena Mode for critical fixes ```bash grok arena "fix the race condition in the payment processor" ``` Eight agents tackle the same bug. Review all outputs, pick the cleanest solution. ### Goal with budget ```bash grok goal "test suite passes" --max-turns 20 ``` Autonomous execution with a turn cap to prevent runaway costs. ### Plan before touching production code ```bash grok plan "migrate from REST to GraphQL" ``` Review the plan. Check which files it plans to touch. Approve before execution. ### Parallel feature implementation ```bash grok exec "add user preferences with three UI variations" ``` Parallel agents produce three UI approaches. You merge the best parts. ## Limitations **Context window:** The 256K limit on `grok-build-0.1` is smaller than Claude Code or Codex. Large monorepos may require selective file loading. **Benchmark gap:** Single-pass accuracy trails Claude Code and Codex. Arena Mode compensates but requires reviewing multiple outputs. **Beta maturity:** Launched May 2026. Some features are still evolving. Expect breaking changes. **Price barrier:** Full parallel features require SuperGrok Heavy at $299/mo. Lower tiers are more limited. ## Getting Started 1. Install: `curl -fsSL https://x.ai/cli/install.sh | bash` 2. Authenticate with your X account or xAI API key. 3. Navigate to a project directory. 4. Run `grok` for interactive mode or `grok exec "task"` for one-shot. 5. Start with plan mode (`grok plan "task"`) until you trust the agent's judgment. 6. Graduate to goal mode for autonomous execution once you understand the cost profile. The parallel architecture is genuinely different from Claude Code and Codex. Whether that difference is valuable depends on your task shape. Well-scoped problems with multiple valid solutions benefit from Arena Mode. Complex multi-file refactors still favor Claude Code's reasoning depth. ## FAQ ### What is Grok Build? Grok Build is xAI's terminal-native coding agent. You point it at a project directory, describe a task in plain English, and it plans, searches the codebase, and applies changes. Its architectural headline is parallelism with up to eight subagents running simultaneously. ### How do I install Grok Build? On macOS and Linux: `curl -fsSL https://x.ai/cli/install.sh | bash`. On Windows PowerShell: `irm https://x.ai/cli/install.ps1 | iex`. Then run `grok` in your project directory. ### How much does Grok Build cost? X Premium+ ($40/mo) and SuperGrok ($30/mo) provide basic access. SuperGrok Heavy ($299/mo, $99 intro) unlocks full 8-agent parallel features. API usage is $1.00/$2.00 per million input/output tokens. ### How does Grok Build compare to Claude Code? Claude Code bets on reasoning depth with one powerful pass. Grok Build bets on parallel breadth with up to eight agents racing the same problem. Claude Code has higher single-pass benchmark scores. Grok Build offers Arena Mode for comparing multiple solutions. ### What is Arena Mode? Arena Mode runs multiple agents on the same task simultaneously. You review all outputs and pick the best solution. This catches errors that a single pass might miss and works well for tasks with multiple valid approaches. ### Does Grok Build support MCP? Yes. Grok Build supports Model Context Protocol for connecting external tools like GitHub, Linear, and databases. The MCP ecosystem is newer than Claude Code's but growing. ### Is Grok Build local or cloud? Local-first. All code runs on your machine. Only API calls to xAI leave your system. This makes it air-gap compatible for sensitive environments after initial setup. ### What is the context window limit? The `grok-build-0.1` model has a 256K context window. For larger context needs, the Grok-4.3 model with 2M context is available for complex reasoning tasks. ## Sources - [xAI - Introducing Grok Build](https://x.ai/news/grok-build-cli) - [xAI - Grok Build CLI](https://x.ai/cli) - [xAI - API Pricing](https://x.ai/api#pricing) - [xAI - SuperGrok Subscription](https://x.ai/grok) - [xAI Documentation](https://docs.x.ai/) - [Grok Build vs Claude Code: 8 Agents vs Deep Reasoning - MorphLLM](https://www.morphllm.com/comparisons/grok-build-vs-claude-code) - [Grok Build Ships Autonomous Execution - TechTimes](https://www.techtimes.com/articles/318976/20260624/grok-build-ships-autonomous-execution-xai-agent-now-plans-runs-verifies.htm) - [Best AI Coding Agents (June 2026) - MorphLLM](https://www.morphllm.com/best-ai-coding-agents-2026)

Perplexity Bumblebee: Developer Guide to the Open Source Supply Chain Scanner

Developers Digest — Sat, 27 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Perplexity blog announcement](https://www.perplexity.ai/hub/blog/perplexity-is-open-sourcing-bumblebee) | Official release post with rationale and use cases | | [GitHub repository](https://github.com/perplexityai/bumblebee) | Source code, installation, and full documentation | | [Apache 2.0 License](https://github.com/perplexityai/bumblebee/blob/main/LICENSE) | Open source license terms | **Last updated:** June 27, 2026 The [Mastra supply chain attack](/blog/mastra-npm-supply-chain-attack-2026) compromised 140+ npm packages in under 90 minutes. The [MCP config supply chain risk](/blog/agent-config-files-are-executable-supply-chain) means AI tool configurations can execute arbitrary code. Both attacks share a common problem: by the time advisories go out, developers need to check their machines quickly - and traditional scanners either run install scripts (triggering the payload) or require network calls that might not be available during incident response. Perplexity built Bumblebee to solve exactly this. It is a read-only scanner that checks your on-disk package metadata, editor extensions, and MCP configurations against known-compromised releases - without executing anything. Open-sourced in May 2026 under Apache 2.0, it ships as a single Go binary with zero external dependencies. --- ## What Bumblebee Does Bumblebee answers one question: when an advisory names a compromised package, extension, or version, which developer machines show a match in their on-disk metadata right now? It reads lockfiles, installed package metadata, extension manifests, and MCP configuration files. It never runs npm, pip, or any other package manager. It never reads your source code. It never makes network calls during the scan. The result is a tool that can run safely on a machine that might be compromised, because the scan itself cannot trigger malicious code. ## Installation Bumblebee requires Go 1.25+ and builds as a single static binary with zero non-stdlib dependencies. **Install the latest release:** ```bash go install github.com/perplexityai/bumblebee/cmd/bumblebee@latest ``` **Pin to a specific version:** ```bash go install github.com/perplexityai/bumblebee/cmd/bumblebee@v0.1.1 ``` **Build from source:** ```bash git clone https://github.com/perplexityai/bumblebee.git cd bumblebee go build -o bumblebee ./cmd/bumblebee go test ./... ``` **Verify installation with the built-in self-test:** ```bash bumblebee selftest # selftest OK (2 findings in 1ms) ``` The self-test validates that the binary can detect deliberately fake compromised package names without making network calls. ## Supported Ecosystems Bumblebee reads metadata from these package managers and tools: | Ecosystem | Sources Read | Tag | |-----------|-------------|-----| | npm / pnpm / Yarn / Bun | `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lockb` | `npm` | | Python / PyPI | `.dist-info/METADATA`, installer files | `pypi` | | Go modules | `go.sum`, `go.mod` | `go` | | RubyGems | `Gemfile.lock`, `.gemspec` files | `rubygems` | | Composer | `composer.lock`, installed metadata | `packagist` | | MCP configs | JSON host configurations for Claude, Cursor, etc. | `mcp` | | Agent skills | Skill lock files | `agent-skill` | | VS Code / Cursor / Windsurf | Extension manifests | `editor-extension` | | Chromium / Firefox | Extension metadata | `browser-extension` | | Homebrew | Formula receipts, cask markers | `homebrew` | The MCP config scanner is the first open source tool to treat MCP configuration files as a security surface. Given that [MCP configs can include env blocks with credentials](/blog/agent-config-files-are-executable-supply-chain), this is a meaningful addition to supply chain monitoring. ## Scan Profiles Bumblebee operates as a one-shot scanner with three profiles: **Baseline** - Scans common global and user package roots, language toolchains, editor extensions, browser extensions, and MCP configs. Good for recurring lightweight inventory. ```bash bumblebee scan --profile baseline > inventory.ndjson ``` **Project** - Examines configured development directories. Designed for daily sweeps of known project workspaces. ```bash bumblebee scan --profile project \ --root "$HOME/code" \ --root "$HOME/Developer" ``` **Deep** - Accepts explicit `--root` paths including broad roots like `$HOME`. Intended for on-demand incident response. ```bash bumblebee scan --profile deep \ --root "$HOME" \ --exposure-catalog ./catalog.json \ --max-duration 10m ``` The `baseline` and `project` profiles refuse bare-home roots to prevent accidental full-disk scans. Only `deep` permits them, signaling explicit incident-response intent. ## Running an Exposure Check The real power of Bumblebee is checking against exposure catalogs - curated lists of known-compromised packages. The repository includes a maintained `threat_intel/` directory with catalogs assembled from public threat-intelligence reporting. **Check against the bundled threat intel:** ```bash bumblebee scan --profile baseline \ --exposure-catalog ./threat_intel/ ``` **Check against a custom advisory:** ```bash bumblebee scan --profile deep \ --root "$HOME" \ --exposure-catalog ./mastra-advisory-2026-06-17.json ``` **Filter to specific ecosystems when you know the attack surface:** ```bash bumblebee scan --profile baseline \ --ecosystem npm,pypi ``` ## Exposure Catalog Format Catalogs use a minimal JSON schema with exact ecosystem-name-version matching: ```json { "schema_version": "0.1.0", "entries": [ { "id": "advisory-2026-0042", "name": "easy-day-js malicious release", "ecosystem": "npm", "package": "easy-day-js", "versions": ["1.11.22"], "severity": "critical" } ] } ``` You can point `--exposure-catalog` to a directory containing multiple JSON files - Bumblebee will merge them automatically. This makes it easy to layer your organization's internal advisories on top of the public threat intel. ## Output Format Bumblebee outputs NDJSON (newline-delimited JSON) to stdout, with diagnostics to stderr. This makes it easy to pipe into jq, grep, or your SIEM. **Package records include:** - Ecosystem and package name - Installed version - Source file path - Confidence level (high/medium/low) - Endpoint metadata: hostname, OS, architecture, username, device ID **Finding records (exposure matches) include:** - Severity from the catalog - Catalog reference ID - Matching evidence - Source location Each record includes a content-addressed `record_id` for deduplication across multiple scans. **Example: count findings by severity** ```bash bumblebee scan --profile baseline \ --exposure-catalog ./threat_intel/ \ | jq -r 'select(.record_type == "finding") | .severity' \ | sort | uniq -c ``` ## Integration Patterns **CI/CD gating:** Run Bumblebee in CI before deployment to catch compromised dependencies before they reach production. ```yaml # GitHub Actions example - name: Supply chain check run: | go install github.com/perplexityai/bumblebee/cmd/bumblebee@v0.1.1 bumblebee scan --profile project \ --root . \ --exposure-catalog ./threat_intel/ \ --output-file findings.ndjson # Fail if critical findings exist if jq -e 'select(.severity == "critical")' findings.ndjson > /dev/null; then echo "Critical supply chain exposure detected" exit 1 fi ``` **Fleet-wide inventory:** Run Bumblebee on developer machines via your endpoint management tool. The scan summary record at the end of each run includes machine identifiers for aggregation. **Incident response:** When an advisory drops, generate a catalog entry and broadcast it to all endpoints. Developers run `bumblebee scan --profile deep` and report back findings. ## What Bumblebee Does Not Do Bumblebee is deliberately limited in scope: - **No remediation.** It reports findings but does not remove packages or modify lockfiles. - **No runtime monitoring.** It is a point-in-time scanner, not a background daemon. - **No network calls during scan.** Catalog updates must be distributed separately. - **No SaaS component.** Everything runs locally. For runtime supply chain monitoring, you would layer Bumblebee with tools like Socket, Snyk, or your organization's SIEM. Bumblebee's value is the safe, read-only sweep you can run on a potentially compromised machine. ## Why Perplexity Built This Perplexity operates a large fleet of developer machines running AI-assisted coding tools. When the Mastra attack hit, they needed to check all endpoints quickly without risking code execution. Existing tools either required network access, ran install hooks, or focused on SaaS dashboards rather than local CLI use. They built Bumblebee internally, then open-sourced it under Apache 2.0 for the broader developer community. The threat intel directory is maintained via contributions and Perplexity's own research using their AI tools. --- ## FAQ ### Does Bumblebee require network access to run? No. Bumblebee makes zero network calls during scanning. Exposure catalogs must be distributed to machines separately - via git, your endpoint management tool, or manual download. ### Can Bumblebee trigger malicious install scripts? No. Bumblebee never runs package managers like npm, pip, or go install. It reads only metadata files - lockfiles, manifests, and installed package receipts. This is the core design principle that makes it safe to run on potentially compromised machines. ### Does Bumblebee read my source code? No. Bumblebee reads package metadata and configuration files only. It does not parse or analyze your application source code. ### What about MCP configuration credentials? MCP configurations may contain credentials in `env` blocks. Bumblebee parses these configs for inventory purposes but does not emit sensitive values in its output. ### How do I update the threat intelligence catalogs? The `threat_intel/` directory in the repository is updated via community contribution. Pull the latest version of the repo or configure a git submodule pointing to the Bumblebee repository's threat_intel directory. ### Can I run Bumblebee on Windows? Bumblebee is designed for macOS and Linux developer endpoints. Windows support is not currently available, though the Go codebase could be extended with Windows path handling. ### How does this compare to npm audit or pip-audit? npm audit and pip-audit run the respective package managers and make network calls to advisory databases. Bumblebee reads only local metadata and checks against local catalogs. This makes Bumblebee suitable for incident response on potentially compromised machines where you cannot trust package manager execution. ### Is there a SaaS version or dashboard? No. Bumblebee is a local CLI tool only. For fleet-wide visibility, aggregate NDJSON output to your SIEM or log management platform. --- ## Sources - [Perplexity Bumblebee announcement](https://www.perplexity.ai/hub/blog/perplexity-is-open-sourcing-bumblebee) - May 2026 - [GitHub repository](https://github.com/perplexityai/bumblebee) - verified June 27, 2026 - [MarkTechPost analysis](https://www.marktechpost.com/2026/05/23/perplexity-open-sources-bumblebee-a-read-only-supply-chain-scanner-for-developer-endpoints/) - May 2026 - [DevOps.com coverage](https://devops.com/perplexity-bumblebee-shakes-loose-hidden-threats-on-dev-desktops/) - May 2026

Best AI Code Review Tools in 2026: CodeRabbit vs DeepSource vs Greptile Compared

Developers Digest — Thu, 25 Jun 2026 00:00:00 GMT

## Official Sources | Tool | Official Source | |:--|:--| | CodeRabbit | [coderabbit.ai/pricing](https://www.coderabbit.ai/pricing) | | DeepSource | [deepsource.com/pricing](https://deepsource.com/pricing) | | Greptile | [greptile.com/pricing](https://www.greptile.com/pricing) | | SonarQube | [sonarsource.com/products/sonarqube](https://www.sonarsource.com/products/sonarqube/) | | GitHub Copilot Code Review | [docs.github.com/copilot](https://docs.github.com/en/copilot) | **Last verified:** June 25, 2026 AI-assisted development generates pull requests faster than humans can review them. Claude Code, Cursor, and Devin push code at rates that overwhelm traditional review workflows. The bottleneck is no longer writing code - it is reviewing it. AI code review tools address this by scanning PRs automatically, catching bugs, security vulnerabilities, and style issues before human reviewers touch them. The best ones understand your entire codebase, not just the diff. Here is how the leading tools compare in June 2026. ## Quick Comparison Table | Tool | Price | Best For | Platform Support | |:--|:--|:--|:--| | CodeRabbit | Free / $24-48/user/mo | PR summaries, multi-platform teams | GitHub, GitLab, Azure DevOps, Bitbucket | | DeepSource | Free / $24/user/mo | Security, compliance, hybrid static+AI | GitHub, GitLab, Bitbucket | | Greptile | Free / $30/user/mo | Full codebase context, architecture review | GitHub, GitLab | | SonarQube | Free / custom | Enterprise security, existing SAST investment | Self-hosted, all Git platforms | | GitHub Copilot Review | Included in Copilot | GitHub-native teams | GitHub only | ## CodeRabbit CodeRabbit won hands-on evaluations primarily on PR summarization and architectural diagrams. It installs natively across GitHub, GitLab, Bitbucket, and Azure DevOps - the only AI reviewer with native support across all four major Git platforms. **Pricing:** - Free: Unlimited reviews on public repos - Pro: $24/user/mo (annual) or $30/user/mo (monthly) - 5 reviews per developer - Pro Plus: $48/user/mo (annual) - 10 reviews per developer, pre-merge checks - Enterprise: Custom pricing **Key features:** - Auto-generates PR summaries with diagrams - Supports 40+ linters - Issue Planner: analyzes issues and generates coding plans from Linear, Jira, GitHub Issues, GitLab - Custom instructions per repository - Full four-platform Git support **Best for:** Teams spread across multiple Git platforms, or teams that prioritize PR documentation and architectural visibility. ## DeepSource DeepSource runs a deterministic static analysis engine before the AI touches the code. The static pass applies 5,000+ rules across 30+ languages, catching known bug patterns, security vulnerabilities, and anti-patterns with zero false positive risk. The AI agent then reviews with full codebase context, data-flow graphs, and taint analysis. On the OpenSSF CVE Benchmark, DeepSource scored 84.51% F1 - the highest of any tool tested. **Pricing:** - Open Source: Free for public repos, unlimited team members, 1,000 PR reviews/month - Team: $24/user/mo (annual), $30/user/mo (monthly) - includes $120/year in bundled AI review credits **Key features:** - Hybrid static analysis + AI review architecture - Secrets detection covering 165+ providers (AWS, GCP, Stripe, Twilio) - SCA with reachability analysis - only alerts for vulnerabilities in code paths you actually execute - OWASP Top 10 and SANS Top 25 compliance reporting - Code coverage tracking **Best for:** Teams prioritizing security and compliance. The hybrid architecture catches both deterministic bugs and context-dependent issues in a single pass. ## Greptile Greptile indexes your entire codebase and reviews each PR against that context, catching bugs in the seams between files, services, and shared dependencies. It builds a Semantic Code Graph before reviewing, indexing the entire repository's functions, classes, variables, and call relationships. Among seven mainstream tools tested, Greptile ranks second with an overall score of 9.0/10 and leads the industry with an 82% raw bug catch rate. **Pricing:** - Developer: Free tier available - Pro: $30/user/mo - includes 50 credits, 1 credit per review, $1 per additional credit - Enterprise: Custom pricing The per-review credit model was introduced in March 2026. **Key features:** - Full codebase indexing - understands architecture and dependencies - Multi-hop investigation: traces dependencies, checks git history, follows leads across files - Semantic Code Graph for deep context - Detects cross-service bugs that single-file reviewers miss **Best for:** Monorepos and complex codebases where bugs hide in service boundaries and shared dependencies. ## SonarQube SonarQube is the established player in static application security testing (SAST), supporting 30+ languages and serving as the default quality gate tool for many engineering organizations. As of SonarQube Server 2026.2 (March 2026), organizations can connect multiple LLM providers to the AI CodeFix engine, avoiding vendor lock-in. **Pricing:** - Community: Free, open source - Developer, Enterprise, Data Center: Contact for pricing **Key features:** - 30+ language support - Multi-LLM AI CodeFix (March 2026) - connect multiple providers - Deep integration with existing CI/CD pipelines - Long track record in enterprise security compliance **Best for:** Organizations with existing SAST investments or strict compliance requirements. The multi-LLM support addresses the vendor lock-in concern that kept some teams from adopting AI features. ## GitHub Copilot Code Review GitHub added code review capabilities to Copilot, making it the natural choice for GitHub-native teams already paying for Copilot. **Pricing:** - Included with Copilot Pro ($10/mo), Pro+ ($39/mo), Max ($100/mo) - Business and Enterprise plans include review capabilities **Key features:** - Inline suggestions directly in GitHub PR interface - Uses the same model context as Copilot coding - No additional install - works if you have Copilot **Best for:** Teams fully committed to the GitHub ecosystem who want a single vendor for coding and review. ## Which Tool Should You Choose? **If you need multi-platform support:** CodeRabbit is the only tool with native integrations across GitHub, GitLab, Azure DevOps, and Bitbucket. **If security and compliance are top priority:** DeepSource's hybrid static+AI architecture and 84.51% F1 score on the OpenSSF CVE Benchmark makes it the leader for vulnerability detection. **If your codebase is a monorepo or has complex service dependencies:** Greptile's full codebase indexing catches cross-service bugs that other tools miss. **If you have existing SAST investment:** SonarQube's multi-LLM AI CodeFix lets you add AI review without replacing your quality gates. **If you are GitHub-only and already use Copilot:** Copilot's built-in code review requires no additional setup or billing. ## The Review Bottleneck Problem AI code review tools do not replace human review - they reduce the cognitive load that makes human review unsustainable at AI-assisted development volumes. When agents generate 10x the PRs, human reviewers cannot keep pace without help. The tools above differ in approach: some prioritize security (DeepSource), some prioritize context (Greptile), some prioritize platform reach (CodeRabbit). The right choice depends on where your review process breaks down. For teams where the bottleneck is PR volume, any of these tools will help. For teams where the bottleneck is security or cross-service bugs, the choice matters more. --- ## FAQ ### What is the best free AI code review tool in 2026? CodeRabbit offers unlimited free reviews on public repositories with no credit card required. DeepSource's Open Source tier includes 1,000 PR reviews per month for public repos with unlimited team members. For private repos, most tools offer limited free tiers or trials. ### How much does AI code review cost per developer? The typical price is $24-30 per developer per month. CodeRabbit and DeepSource both price at $24/user/month on annual plans. Greptile is $30/user/month but charges per review after 50 reviews. Enterprise pricing varies. ### Can AI code review tools replace human reviewers? No. AI code review tools catch bugs, security issues, and style violations, but they do not understand business context, user intent, or architectural direction. They reduce the volume of issues humans need to catch, making human review sustainable at higher PR volumes. ### Which AI code review tool has the best security detection? DeepSource leads on security benchmarks with an 84.51% F1 score on the OpenSSF CVE Benchmark. Its hybrid architecture combines deterministic static analysis (5,000+ rules) with AI review, catching both known patterns and context-dependent vulnerabilities. ### Does GitHub Copilot include code review? Yes. GitHub Copilot Pro, Pro+, Max, Business, and Enterprise plans include code review capabilities as of 2026. It works inline in the GitHub PR interface with no additional install required. ### Which AI code review tool works with GitLab and Azure DevOps? CodeRabbit is the only tool with native integrations across GitHub, GitLab, Azure DevOps, and Bitbucket. DeepSource supports GitHub, GitLab, and Bitbucket. Greptile supports GitHub and GitLab. SonarQube works with any Git platform via self-hosting. ### What is the difference between AI code review and static analysis? Static analysis applies deterministic rules to catch known patterns - it is fast and has no false positives but misses context-dependent bugs. AI code review understands natural language and codebase context, catching issues that rules cannot express but with some false positive risk. Tools like DeepSource combine both approaches. ### How do AI code review tools handle codebase context? Greptile builds a Semantic Code Graph, indexing the entire repository's functions, classes, and call relationships. DeepSource uses data-flow graphs and taint analysis. CodeRabbit uses repository instructions and PR history. The depth of context varies by tool. --- ## Sources - [CodeRabbit Pricing](https://www.coderabbit.ai/pricing) - verified June 25, 2026 - [DeepSource Pricing](https://deepsource.com/pricing) - verified June 25, 2026 - [DeepSource AI Code Review Tools Comparison](https://deepsource.com/resources/ai-code-review-tools) - June 2026 - [Greptile Pricing](https://www.greptile.com/pricing) - verified June 25, 2026 - [Best AI Code Review Tools 2026 - Greptile](https://www.greptile.com/content-library/best-ai-code-review-tools) - June 2026 - [The Best AI Code Review Tools of 2026 - DEV Community](https://dev.to/heraldofsolace/the-best-ai-code-review-tools-of-2026-2mb3) - June 2026

Arcade AI Agent Authorization: A Developer Guide

Developers Digest — Wed, 24 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Arcade Homepage | [arcade.dev](https://www.arcade.dev/) | | Arcade Documentation | [docs.arcade.dev](https://docs.arcade.dev/en/home) | | Arcade GitHub (MCP SDK) | [github.com/arcadeai/arcade-mcp](https://github.com/arcadeai/arcade-mcp) | | MCP Authorization Spec | [modelcontextprotocol.io](https://modelcontextprotocol.io/) | | Series A Announcement | [BusinessWire](https://www.businesswire.com/news/home/20260615229631/en/Arcade-Raises-$60M-to-Become-the-Secure-Action-Layer-Behind-Every-Production-AI-Agent) | On June 15, 2026, Arcade closed a $60 million Series A led by SYN Ventures with strategic investments from Morgan Stanley and Wipro. The round brings their total funding to $72 million. The company was founded by former Okta and Snowflake engineers and claims to author the MCP tool authorization specification that Anthropic and other model providers now reference. The pitch is simple: AI agents need to take real actions in production systems like Salesforce, Slack, Jira, and Google Workspace. The hard part is not teaching the agent to call an API. The hard part is authorization - making sure the agent acts as a specific authenticated user, with only the permissions that user has, and leaving a complete audit trail of every action. **Last updated:** June 24, 2026 --- ## The Problem Arcade Solves When you connect an AI agent to external systems, three things break immediately: **1. Authorization is backwards.** Traditional API integrations use service accounts or shared API keys. The agent acts as "the system" with broad permissions. But users expect the agent to act as them - to see only what they can see, to modify only what they are allowed to modify. A sales rep's agent should not be able to access every deal in Salesforce just because the integration API key can. **2. OAuth flows are designed for humans.** The standard OAuth redirect dance assumes a human is sitting at a browser, clicking through consent screens. Agents run in terminals, background jobs, and automated pipelines. They cannot click a consent button. Worse, if the token expires mid-task, the agent has no way to re-authenticate. **3. Audit trails do not exist.** When something goes wrong - and it will - you need to answer: "What action did this agent take, on behalf of which user, against which resource, at what time?" Most agent implementations cannot answer this because the action ran through a shared credential with no user attribution. Arcade claims to solve all three. --- ## How Arcade Actually Works Arcade is an MCP runtime - a layer that sits between your agent and the external systems it needs to access. The Model Context Protocol (MCP) is the open standard that Anthropic and others use to define how agents interact with tools. Arcade implements the authorization piece of that standard. ### The Core Flow 1. **User authenticates once.** When a user first interacts with an agent that needs external access (say, Google Calendar), Arcade surfaces a login URL. The user clicks it, authenticates with Google directly, and grants the agent limited permissions. Arcade stores the token securely. 2. **Agent inherits user permissions.** On subsequent requests, the agent calls Arcade with the user's identity. Arcade retrieves the appropriate token and makes the API call on behalf of that specific user. The agent never sees the raw token. 3. **Policy enforcement at the edge.** Before any action executes, Arcade checks policies: Is this user allowed to call this tool? Is this action within the agent's scope? Custom pre-call and post-call hooks let you add business logic - rate limits, approval workflows, content filtering. 4. **Every action is logged.** Arcade records which agent called which tool, for which user, with what parameters, and what the result was. This audit trail is searchable and exportable. ### URL Elicitation The clever part is what Arcade calls "URL elicitation" - a capability they co-developed with Anthropic. When an MCP server needs the user to authenticate, it can return a special response containing a login URL. The agent surfaces this URL to the user (in a terminal, chat interface, or wherever it is running). The user clicks, authenticates in their browser, and the agent continues without ever handling credentials directly. This is different from how most agent frameworks handle auth today, where you typically pre-configure API keys or service accounts in environment variables. --- ## What You Get Out of the Box Arcade ships with 8,000+ pre-built MCP tools across common SaaS systems: - **Productivity:** Google Workspace (Calendar, Drive, Docs, Gmail), Asana, Jira, Linear, Notion - **Communication:** Slack, Microsoft Teams, Discord - **CRM:** Salesforce, HubSpot - **Developer tools:** GitHub, Vercel, Stripe - **Data:** Snowflake, BigQuery, Airtable These are not just API wrappers. Arcade claims their tools are "agent-optimized" - meaning the tool descriptions and parameter schemas are designed for how LLMs actually call them, reducing hallucinations and failed actions. You can also build custom tools using their Python or TypeScript SDK: ```python from arcade_ai import tool @tool async def get_calendar_events( user_id: str, start_date: str, end_date: str ) -> list: """Fetch calendar events for a user within a date range.""" # Arcade handles OAuth - you just call the API client = await arcade.get_authorized_client("google_calendar", user_id) events = await client.events.list( calendarId="primary", timeMin=start_date, timeMax=end_date ) return events ``` The `get_authorized_client` call is where the magic happens - Arcade looks up the user's stored token, refreshes it if needed, and returns an authenticated client. --- ## Framework Integrations Arcade is not an agent framework - it is infrastructure that agent frameworks call. Current integrations include: | Framework | Status | |-----------|--------| | LangChain (Python/TS) | Production | | OpenAI Agents SDK | Production | | CrewAI | Production | | Google ADK | Production | | Vercel AI SDK | Production | | Mastra | Production | | Spring AI SDK | Production | | Pydantic AI | Production | For LangChain, the integration looks like: ```python from langchain_arcade import ArcadeToolkit # Initialize with your API key toolkit = ArcadeToolkit(api_key="arc_...") # Get tools for the current user tools = toolkit.get_tools(user_id="user_123") # Use with any LangChain agent agent = create_react_agent(llm, tools) ``` The tools returned are standard LangChain tool objects, but the authorization is handled by Arcade. --- ## Pricing and Deployment Arcade's pricing is not publicly listed. Their website says "free to start, priced by usage, designed for enterprise volume." Based on the Series A announcement and Fortune 500 customer references, expect enterprise-tier pricing for production deployments. Deployment options include: - **Arcade Cloud** - Managed service, fastest to start - **On-premises** - Run in your own infrastructure - **Air-gapped** - For regulated environments - **Hybrid** - Mix cloud and on-prem as needed The company is SOC 2 compliant and supports SSO, RBAC, and comprehensive audit logs. --- ## When to Use Arcade vs. Rolling Your Own **Use Arcade when:** - You need agents to act as authenticated users, not as service accounts - You are connecting to multiple SaaS systems and do not want to build OAuth integrations for each - Audit and compliance matter - you need to prove what agents did - You are scaling beyond a prototype and cannot afford to debug OAuth token refresh bugs in production **Roll your own when:** - You only need one or two integrations to systems you already have service accounts for - Your use case does not require per-user permissions - You are early in experimentation and want to understand the auth layer yourself first --- ## The Competitive Landscape Arcade is not the only company working on agent authorization. [Stytch](https://stytch.com/) has agent-specific OAuth features. [Auth0](https://auth0.com/) (now Okta) has explored machine-to-machine auth patterns. The major cloud providers - AWS, Google Cloud, Azure - all have identity products that could theoretically serve this use case. What differentiates Arcade is the MCP-native approach. They authored the authorization spec that model providers are adopting, and their tooling is designed specifically for the agent interaction pattern rather than being retrofitted from human-to-service auth. Whether that matters depends on how deeply you are invested in the MCP ecosystem. If you are building with Claude Code, Cursor, or other MCP-aware tools, Arcade fits cleanly. If you are building your own agent infrastructure from scratch, the MCP specificity may be less relevant. --- ## FAQ ### What is an MCP runtime? An MCP runtime is infrastructure that handles the connection between AI agents and external tools. It manages authentication, authorization, tool execution, and logging. Arcade is one implementation - there are others, including self-hosted options using the open-source MCP server framework. ### Does Arcade work with OpenAI models? Yes. Arcade is model-agnostic. It works with Claude, GPT-4, Gemini, and any other model that can call tools. The MCP spec is becoming a de facto standard for tool calling across providers. ### How does Arcade handle token refresh? Arcade stores OAuth tokens securely and refreshes them automatically before they expire. If a refresh fails, it surfaces a new login URL to the user through the URL elicitation pattern. ### What happens if an agent tries to access something the user cannot access? The API call fails with a permissions error, just as it would if the user tried to access it directly. Arcade does not grant additional permissions beyond what the user has. ### Can I use Arcade with my own custom APIs? Yes. You can build custom MCP tools using Arcade's Python or TypeScript SDK. These tools can call any API you have access to, with the same authorization and audit features as built-in tools. ### Is Arcade open source? The arcade-mcp SDK for building custom tools is open source on GitHub. The Arcade runtime itself (the managed service) is proprietary. ### How does this compare to API gateways? API gateways handle request routing, rate limiting, and authentication at the API level. Arcade operates at the agent level - it understands that an agent is acting on behalf of a user and enforces permissions accordingly. The two can work together: Arcade calls through your API gateway, adding the user-attribution layer on top. ### What is the latency overhead? Arcade adds a network hop between your agent and the target API. For most use cases, this is negligible compared to LLM inference time. The company claims sub-50ms overhead for typical tool calls. --- ## Sources - [Arcade $60M Series A Announcement](https://www.businesswire.com/news/home/20260615229631/en/Arcade-Raises-$60M-to-Become-the-Secure-Action-Layer-Behind-Every-Production-AI-Agent) - June 15, 2026 - [Arcade Documentation](https://docs.arcade.dev/en/home) - accessed June 24, 2026 - [Arcade.dev Homepage](https://www.arcade.dev/) - accessed June 24, 2026 - [Model Context Protocol Specification](https://modelcontextprotocol.io/) - accessed June 24, 2026 - [Arcade MCP SDK on GitHub](https://github.com/arcadeai/arcade-mcp) - accessed June 24, 2026

Developer Fired by Google for Building Google Workspace CLI

Developers Digest — Wed, 24 Jun 2026 00:00:00 GMT

Two months ago, Justin Poehnelt was fired by Google. His offense: creating a CLI tool for Google Workspace that went viral, hit #1 on Hacker News, accumulated thousands of GitHub stars, and attracted many thousands of users in just a couple of days. The timing made it worse. Two days before his termination, Google announced at Cloud Next 2026 that an official Workspace CLI was in development. ## What Happened Poehnelt spent nearly seven years on Google's Workspace Developer Relations team. His job involved building open-source layers and abstractions over Google APIs - exactly the kind of work the team was designed to do. The CLI tool he created, `gws`, provides unified command-line access to Google Drive, Gmail, Calendar, and other Workspace APIs. When the tool went viral, it caught leadership by surprise. Directors and leaders asked what they could learn from the project. Then legal started grilling him about why Google's logo and brand colors appeared on a Google Workspace GitHub code repository. According to Poehnelt, the core issue was fear of disruption - not about his CLI specifically, but about what AI agents meant for Workspace as a product. The CLI made Workspace APIs accessible in a way that AI coding assistants and automation tools could easily consume. ## What HN is Saying The Hacker News thread has 340+ comments and surfaces several angles on the story. **The process question dominates.** Multiple former Googlers confirm that Google has strict OSS release processes. The debate is whether Poehnelt followed them. He claims the process is "not clearly documented and always changing" and that he had approval through the internal launch system (Ariane/Launcher2) with the engineering bit flipped by his manager. Others point to Google's public OSS release documentation as evidence the rules were clear. **The branding issue is murky.** The GitHub organization `googleworkspace` displays Google's logo on all its repositories - that's an org-level setting, not something Poehnelt added. The README includes the standard "This is not an officially supported Google product" disclaimer. But releasing a viral product with official-looking branding without the full corporate launch review is risky at any large company. **20% time is invoked nostalgically.** Several commenters see this as evidence that Google's famous 20% time culture is dead. "Google has gone from encouraging 20% time to firing people for doing it," writes one commenter. Others push back: 20% time never meant bypassing launch approvals, and this appears to be less about side projects and more about proper channels. **The AI disruption angle resonates.** The CLI made Google Workspace APIs trivially accessible to AI agents. One commenter notes: "Your tool is something that made Workspace so much more useful to me personally... Getting fired for making a product more useful to customers is quite ironic." Another adds that paired with a Claude skill, it saved significant time creating meeting notes - exactly the kind of AI-native workflow that Workspace apparently wasn't ready to officially support. **Corporate politics gets blamed.** "Good ideas are now risky because it steps on the toes of someone's fiefdom," writes one commenter. Another: "They've been GE'd." The general sentiment is that something broke in how Google handles internal innovation. Read the full discussion at [Hacker News](https://news.ycombinator.com/item?id=48649011). ## The Bigger Picture This situation illustrates a recurring tension in big tech: the gap between what developer relations teams are supposed to do (build tools that make platforms accessible) and what product teams want to control (the timing, branding, and narrative around new capabilities). It also highlights how AI is changing developer tools. A CLI that exposes APIs cleanly isn't just a convenience anymore - it's infrastructure for AI agents. When every developer has access to coding assistants that can call arbitrary APIs, making those APIs easily callable becomes a strategic decision. For developers working at large companies, the lessons are practical: **Document your approvals.** If you have sign-off, make sure it's on record and that you understand exactly what scope it covers. **Understand branding implications.** Using company GitHub orgs, logos, or anything that could make your project look official creates liability. Even "not officially supported" disclaimers may not be enough if the visual presentation suggests otherwise. **Consider timing.** A project that goes viral right before your company announces a competing official version creates an awkward situation for everyone - especially if your project is better received. **Recognize disruption risk.** If your side project enables use cases that threaten existing business models (like AI agents automating away SaaS seats), expect friction from stakeholders who see the threat before they see the opportunity. ## The Tool Itself The Google Workspace CLI (`gws`) is still available at [github.com/googleworkspace/cli](https://github.com/googleworkspace/cli). It provides command-line access to Workspace APIs in a format that works well with AI coding tools. Whether Google eventually releases their own version or claims this one remains unclear. For now, it serves as a case study in what happens when developer tools become too useful too fast. ## Sources - [Justin Poehnelt's X post](https://x.com/JPoehnelt/status/2069482265953087602) - [HN Discussion](https://news.ycombinator.com/item?id=48649011) (340+ comments) - [Google OSS Release Documentation](https://opensource.google/documentation/reference/releasing) - [Google Workspace CLI Repository](https://github.com/googleworkspace/cli)

Vulnerability Reports Are Not Special Anymore

Developers Digest — Wed, 24 Jun 2026 00:00:00 GMT

Filippo Valsorda, the cryptography engineer behind the Go cryptography standard library and age encryption, published an essay this week arguing that vulnerability reports no longer deserve special treatment. The reason: LLMs can now find vulnerabilities "as good as almost any security researcher." The post sparked a 170+ comment discussion on Hacker News, with maintainers, security researchers, and vendors all weighing in on whether the old coordinated disclosure model still makes sense in 2026. ## The Core Argument Valsorda's thesis is straightforward. Vulnerability reports historically received privileged treatment because security researchers provided two scarce resources: 1. **Valuable insight** into potential vulnerabilities 2. **Confidentiality** allowing fixes before public disclosure In exchange, maintainers offered responsiveness and public credit. Both sides of this bargain have eroded. LLMs can now perform vulnerability discovery at scale. The insight isn't scarce anymore. And confidentiality matters less when any attacker can run the same LLM analysis independently and find the same bugs. "The insight is not scarce and precious anymore," Valsorda writes. If an AI found the vulnerability, there's no reason to assume attackers haven't already found it too. The practical conclusion: maintainers should prioritize rapid triage and remediation over courteous researcher communication. Implement LLM-based scanning in your CI/CD pipeline. Reserve special treatment only for unusually severe cases or highly-trusted sources. ## What HN is Saying The thread surfaces both validation of the problem and pushback on the solution. **Maintainers confirm the spam problem is real.** One maintainer of a vulnerability disclosure program reports that submissions went from 5 per month to 5 per day since January 2026. "These are clearly AI-generated and extremely low quality (albeit well-written). The rules of the program aren't read." They're considering shutting down the program entirely. **Dependabot fatigue compounds the issue.** Several developers describe getting 100+ vulnerability alerts per week, mostly for dev dependencies or issues that don't affect their actual attack surface. "Half of them for dev dependencies," one writes. The signal-to-noise ratio has collapsed. **ReDoS is the poster child for broken scoring.** Multiple commenters point to regex denial-of-service vulnerabilities that get marked as 10/10 severity despite being in build-time code that never sees untrusted input. "We got 116 github dependabot alerts this week. Half of them for dev dependencies." **The payment friction idea emerges.** One commenter suggests requiring a small payment to submit vulnerability reports, refunded on valid findings. This triggers immediate pushback: "Why would anyone pay money to have a chance of being arrested?" The legal risks of security research already create friction - adding financial friction could discourage legitimate researchers entirely. **Supply chain concerns complicate the dev-dependency dismissal.** Several commenters note that dev dependencies are still attack vectors - SolarWinds was compromised through its build tooling. "Developer's machines and cicd systems are high value targets." Dismissing dev dependency alerts entirely isn't risk-free. **Some question the AI capability claim.** Not everyone agrees that LLMs can find vulnerabilities as well as skilled researchers. The counterargument: AI-generated reports are mostly garbage, suggesting the discovery capability isn't actually that strong. Valsorda's framing may overstate where we are today while being correct about the trajectory. Read the full discussion at [Hacker News](https://news.ycombinator.com/item?id=48653216). ## What This Means for Developers If you maintain open source software or run a vulnerability disclosure program, this shift creates practical problems: **Triage becomes the bottleneck.** When anyone can generate plausible-looking vulnerability reports, filtering real issues from AI-generated noise becomes the core challenge. Quality scoring, source reputation, and automated validation become more important than manual review of every submission. **The AI-found vulnerability paradox.** If AI can find a bug, assume adversaries have already found it. This changes disclosure timelines - you may want to patch faster and skip the courtesy dance. **Bug bounty economics shift.** Programs that pay per valid bug create incentives for volume submissions. Expect more platforms to adopt filtering mechanisms like video reproduction requirements, reputation gating, or even the controversial payment friction model. **Run your own scans.** If LLMs can find your vulnerabilities, you should be running those scans yourself before researchers (or attackers) do. Integrate security scanning into CI/CD rather than relying on external reports. **Dev dependency alerts still matter, sometimes.** Don't dismiss all dev dependency vulnerabilities, but do context-aware triage. A ReDoS in your test framework is different from malicious code in a build tool. ## The Broader Shift Valsorda's essay is part of a larger pattern: AI commoditizing expertise-based workflows. Security research joins code review, penetration testing, and other traditionally specialized domains where AI tools are compressing the skill curve. This doesn't mean security researchers are obsolete. The hardest vulnerabilities - novel attack classes, complex chains, hardware-level exploits - still require human expertise. But the long tail of straightforward vulnerability discovery is increasingly automatable. For maintainers, this means the volume of incoming reports will keep growing while the average quality drops. The workflows designed for a world of scarce, thoughtful security researchers need to adapt to a world of abundant, mechanical scanning. The old model assumed vulnerability reporters were partners deserving special treatment. The new model may need to assume they're noise until proven otherwise - and design systems accordingly. ## Sources - [Vulnerability reports are not special anymore - Filippo Valsorda](https://words.filippo.io/vuln-reports/) - [HN Discussion](https://news.ycombinator.com/item?id=48653216) (170+ comments) - [Scanii Vulnerability Disclosure Program Rules](https://docs.scanii.com/article/131-does-scanii-have-a-security-vulnerability-disclosure-program) (example of video reproduction requirement)

Agent Identity Is the Missing Security Layer for AI Workflows

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Linux Foundation ANS Announcement](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-agent-name-service-to-establish-trusted-identity-infrastructure-for-ai-agents) | Official announcement of Agent Name Service for AI agent identity | | [Model Context Protocol Specification](https://modelcontextprotocol.io/specification) | MCP protocol spec governing tool connections | | [OAuth 2.0 Security Best Current Practice (RFC 9700)](https://www.rfc-editor.org/rfc/rfc9700.html) | OAuth security guidance for authorization flows | | [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html) | Identity layer on OAuth 2.0 for authentication | | [SPIFFE Identity Standard](https://spiffe.io/docs/latest/spiffe-about/overview/) | Service identity framework for workloads | The Linux Foundation announced its intent to launch the Agent Name Service, or ANS, as trusted identity infrastructure for AI agents. The short version: agent identity is becoming a platform problem. The proposal describes an open standard built on DNS so agents can discover each other, verify identity, advertise capabilities, and establish trust relationships across organizations. That sounds abstract until you connect it to the tools developers are already wiring into agents: MCP servers, Slack connectors, code hosts, ticket systems, browsers, databases, and production logs. **Last updated:** June 30, 2026 Google Trends was light on AI/developer signals during this pass. The only clean trend-led post today was [Cerebras and AI inference demand](/blog/cerebras-cbrs-stock-ai-inference-market-signal). This one came from Hacker News and the Linux Foundation source, but it fits the same filter: a fresh story only matters here if it changes how developers build or operate AI workflows. ## Why Agent Identity Matters Most agent security conversations start too late. Teams ask whether the model is safe, whether a prompt is well written, or whether a tool call should be approved. Those questions matter, but they assume the system already knows who the agent is and what it is allowed to do. That assumption breaks down fast. Imagine three agents interacting with the same company systems: | Agent | Legitimate job | Risk without identity | |---|---|---| | release agent | open PRs, summarize CI, request approval | can be confused with a human committer or another automation | | support agent | read tickets and propose replies | may access customer records outside its scope | | security agent | inspect logs and dependency changes | may be allowed to perform actions meant only for analysis | If those agents are only "the thing behind this API key," governance gets messy. You cannot cleanly answer which agent acted, which task authorized it, which tools it touched, and whether its privileges should still exist tomorrow. That is why agent identity belongs next to the [agent containment capability ledger](/blog/agent-containment-capability-ledger). A capability ledger says what an agent can touch. Identity says which agent is asking, how that claim is verified, and whether the request is still valid. ## DNS Is Boring in the Right Way The Linux Foundation framing matters because ANS is not pitched as another app-specific registry. It is pitched as open infrastructure that builds on DNS. That is a pragmatic direction. DNS is already the internet's boring naming substrate. Developers understand domains, records, ownership, delegation, and lookup. Security teams understand that DNS is not magic, but it is a durable place to start for discoverability and administrative control. For agents, a naming layer could eventually answer questions like: - What organization controls this agent identity? - Which public key or verification material is associated with it? - Which capabilities does it advertise? - Which endpoint or protocol should another system use to reach it? - Has this identity been revoked or rotated? - Is this the same agent that acted in a previous workflow? Those answers do not make the agent safe by themselves. They make safety enforceable. That distinction matters. We just covered how [cybersecurity skills for AI agents](/blog/cybersecurity-skills-ai-agents-runtime) can become runtime infrastructure only when paired with provenance, tests, and abuse boundaries. Agent identity has the same shape. A name is useful only when the runtime can tie it to policy and logs. ## Identity Is Not Authorization The easiest mistake is treating identity as the whole security model. It is not. A verified agent can still be over-permissioned. A legitimate agent can still be prompt-injected. A known identity can still perform the wrong action if the surrounding workflow is sloppy. The better model is layered: 1. Identity: who is this agent? 2. Scope: what is it allowed to access? 3. Intent: what task is it currently executing? 4. Evidence: what inputs and approvals led to the action? 5. Revocation: how do we shut it down or rotate trust? 6. Audit: can we reconstruct what happened? This is the same reason [permissions, logs, and rollback](/blog/permissions-logs-rollback-ai-coding-agents) matter for coding agents. The identity layer tells you which agent opened the pull request. The permission layer tells you whether it was allowed to touch those files. The log layer tells you why it did so. The rollback layer lets you recover when the answer was wrong. Without all four, identity becomes a nice label on an unsafe system. ## The MCP Connection MCP made this problem more urgent. Once agents can connect to tool servers, identity is no longer just a UI concern. It becomes part of protocol trust. If an agent calls a local file server, a Slack connector, a database helper, and a code-review tool in the same task, every hop needs a defensible answer to the same questions: - Is this the expected agent? - Is the user or organization behind it known? - Is the current task allowed to use this tool? - Are the requested scopes narrower than the agent's total identity? - Can the tool log the action against the right actor? That connects directly to [MCP zero-touch OAuth](/blog/mcp-zero-touch-oauth-enterprise-auth). OAuth can help authorize a tool connection, but the broader system still needs stable agent identity and task-level boundaries. Otherwise, every connector becomes another place where "trusted automation" turns into ambient authority. It also connects to [prompt injection in agent apps](/blog/prompt-injection-agent-apps-practical-version). If untrusted content can steer an agent, then downstream tools should not blindly trust "the agent said so." They should evaluate identity, scope, source, and task context together. ## What Developers Should Build Now You do not need to wait for ANS to become mature before improving your agent stack. Start with a local identity model: - Give each agent a stable name and owner. - Separate agent identity from human identity. - Give each workflow a task id. - Log every tool call with agent id, user id, task id, and approval source. - Keep capability grants narrow and time-bound. - Add revocation paths for agents, keys, connectors, and tasks. - Treat public agent instructions, repo config, and connector descriptions as untrusted until reviewed. If you are connecting tools for the first time, use the [agent security checklist before connecting tools](/blog/agent-security-checklist-before-connecting-tools) before adding another connector. The checklist forces the basic questions that identity infrastructure eventually needs to answer automatically. For production teams, the next useful artifact is a small agent registry: | Field | Why it matters | |---|---| | agent id | stable actor for logs and review | | owner | team accountable for behavior | | allowed tools | prevents ambient access | | default scopes | keeps connectors narrow | | task types | blocks identity reuse across unrelated workflows | | key material | enables verification and rotation | | expiration | forces cleanup | | incident contact | gives security teams a real handoff | That registry can be a markdown file, database table, internal admin page, or policy-as-code config. The important part is that agent identity becomes explicit before the workflow scales. ## The Practical Take Agent identity is not exciting because it lets agents talk to each other. It is exciting because it makes agent behavior accountable. The next generation of AI workflows will not be one chatbot calling one tool. It will be many agents acting across many services with different scopes, owners, and risk levels. In that world, "the model did it" is not an audit trail. The useful question for every new agent workflow is now: Can we prove which agent acted, why it was allowed, what it saw, what it changed, and how to revoke that trust? If the answer is no, identity is not a nice-to-have. It is the missing layer. ## FAQ ### What is Agent Name Service? Agent Name Service is a Linux Foundation announced effort to establish trusted identity infrastructure for AI agents, using DNS-based naming ideas for discovery, verification, and trust. ### Why do AI agents need identity? Agents need identity so systems can distinguish one automated actor from another, apply scoped permissions, log actions correctly, and revoke trust when a workflow changes or fails. ### Does identity make AI agents safe? No. Identity is only one layer. Agents still need scoped permissions, task boundaries, audit logs, approval paths, and revocation mechanisms. ### How does agent identity relate to MCP? MCP makes tool access easier, which makes identity more important. Tool servers need to know which agent is calling, what task it is executing, and what scopes it should have. ## Sources - [Linux Foundation announces intent to launch Agent Name Service](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-agent-name-service-to-establish-trusted-identity-infrastructure-for-ai-agents) - [Hacker News newest](https://news.ycombinator.com/newest) - [Google Trends daily RSS, United States](https://trends.google.com/trending/rss?geo=US) - [Model Context Protocol specification](https://modelcontextprotocol.io/specification) - [OAuth 2.0 Security Best Current Practice](https://www.rfc-editor.org/rfc/rfc9700.html)

Agent PR Governance: The New Rules for Copilot Reviews

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |:--|:--| | [Security validation for third-party coding agents](https://github.blog/changelog/2026-06-09-security-validation-for-third-party-coding-agents/) | GitHub Changelog, June 9 2026 | | [Shape Copilot code review around your team](https://github.blog/changelog/2026-06-02-shape-copilot-code-review-around-your-team/) | Skills, MCP, and medium review tier | | [Copilot code review AGENTS.md support](https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements/) | Repository-level agent instructions | | [Generated release notes credit developers](https://github.blog/changelog/2026-06-18-generated-release-notes-credit-you-for-copilot-pull-requests/) | Attribution for Copilot PRs | | [GitHub Copilot Documentation](https://docs.github.com/en/copilot) | Official feature reference | **Last verified:** June 25, 2026 Agent-authored pull requests are becoming normal enough that "does the agent write code?" is no longer the useful question. The useful question is: what policy stack catches bad agent work before it reaches `main`? GitHub's June Copilot updates are a good signal. The company shipped security validation for third-party coding agents, Copilot code review customization with skills and MCP, a medium review-effort tier, AGENTS.md support inside Copilot code review, author search for Copilot-authored pull requests, and release-note attribution that credits the human who asked Copilot to open the PR. That is not one feature. It is a governance surface. The teams that win with coding agents will not be the teams that generate the most pull requests. They will be the teams that make agent pull requests easy to validate, review, attribute, and reject. **Last updated:** June 25, 2026 ## The June Signal Here is the GitHub update cluster that matters: - [Security validation for third-party coding agents](https://github.blog/changelog/2026-06-09-security-validation-for-third-party-coding-agents/) is generally available. - [Copilot code review can be shaped around your team](https://github.blog/changelog/2026-06-02-shape-copilot-code-review-around-your-team/) with skills, MCP, and a new medium review-effort tier. - [Copilot code review now supports repository-level AGENTS.md files](https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements/), so review feedback can use repo instructions. - [Generated release notes credit the developer for Copilot pull requests](https://github.blog/changelog/2026-06-18-generated-release-notes-credit-you-for-copilot-pull-requests/), not only `@copilot`. - GitHub's June changelog also says Copilot-authored pull requests now show up in author searches, making agent work easier to find and audit. Read those together with [GitHub Copilot Agent Finder](/blog/github-copilot-agent-finder-ard-specification-2026) and the direction is clear: GitHub is making agent work visible in the same places teams already manage software delivery. That is the right place for the fight. Agent quality is not only a model problem. It is a pull request governance problem. ## The Policy Stack Teams Actually Need A useful agent PR policy has five layers: | Layer | Question it answers | GitHub signal | |---|---|---| | Validation | Is this agent allowed to act here? | third-party coding-agent security validation | | Context | Did review use the repo's rules? | AGENTS.md and review skills | | Depth | Was review effort matched to risk? | low, medium, and deeper review tiers | | Attribution | Who initiated and owns the work? | Copilot PR attribution and author search | | Release accountability | Does shipped work credit the right operator? | generated release-note credit | This is more concrete than saying "humans should review AI code." Of course they should. The policy question is what evidence reviewers receive before they spend attention. For the broader bottleneck, read [AI Code Review Is the New Bottleneck](/blog/ai-code-review-bottleneck). This piece is about the narrower GitHub-native policy stack. ## Layer 1: Validate Which Agents Can Touch the Repo Third-party coding agents change the risk profile. A built-in Copilot feature and an external agent provider are not the same trust boundary. Security validation is the first gate. Before an agent can create branches, open pull requests, or request review, the platform needs a way to prove the integration is configured correctly and operating under the expected permissions. That does not remove the need for repository rules, branch protection, required checks, code owners, or human review. It gives teams a better starting point: agent access should be explicit, validated, and visible. The policy I would write: ```text Agent PRs are allowed only from validated agent providers. Agent-created branches must target protected pull requests. No agent-authored PR can merge without required checks and a human reviewer. ``` That is boring. Boring is good here. For the wider tool-access checklist, pair this with [the agent security checklist](/blog/agent-security-checklist-before-connecting-tools). ## Layer 2: Make Repo Instructions Part of Review AGENTS.md support in Copilot code review is more important than it looks. Most agent mistakes are not syntax mistakes. They are local-context mistakes: - using the wrong test command; - ignoring a design-system rule; - duplicating an existing helper; - changing a public API without a migration note; - writing a broad refactor when the repo prefers small diffs; - missing a security boundary that exists only in project docs. If review does not see the repo's rules, it can only judge generic correctness. That is not enough. Put the review contract in plain language: ```text For every agent-authored PR, review must check: - the diff is smaller than the task requires; - the PR includes the command output that proves the change; - generated tests fail on the broken code when applicable; - public behavior, docs, and changelog are updated together; - security-sensitive changes name the permission boundary touched. ``` Then put that contract somewhere the review agent and humans both read: `AGENTS.md`, `.github/skills/code-review/SKILL.md`, PR templates, or repo docs. This is where [AI code attribution](/blog/vscode-copilot-ai-coauthor-attribution) becomes practical. Attribution is only useful when it routes the right scrutiny. ## Layer 3: Match Review Depth to Change Risk GitHub's new medium review-effort tier is a useful product detail because it acknowledges a real workflow problem: not every pull request deserves the same review budget. A typo fix and a permissions refactor should not receive the same automated review pass. A dependency update that touches lockfiles, CI, and runtime code should not be treated like a CSS tweak. Teams should define review tiers before the queue gets noisy: | Change type | Minimum review tier | Extra requirement | |---|---|---| | docs-only or copy-only | low | link preview or rendered artifact | | small bug fix | medium | failing test or reproduction note | | dependency or lockfile change | medium | supply-chain review and install proof | | auth, billing, security, or data access | high | code owner and threat note | | generated migration or broad refactor | high | rollback plan and staged rollout | The exact labels can change. The principle should not: review depth follows blast radius. This also keeps AI review from becoming theater. A code review agent that comments equally on every PR is just another notification source. A review system that escalates based on risk can save human attention for the work that matters. ## Layer 4: Attribute the Operator, Not Just the Agent Generated release notes now credit the developer who asked Copilot to open the pull request, alongside `@copilot`. That is the right direction. Agent work still has a human operator. The operator chooses the task, prompt, repo, branch, timing, acceptance criteria, and merge decision. If a Copilot cloud agent opens the PR, the agent is part of the provenance. But the human who initiated the work is still responsible for whether it should ship. That is why attribution should answer three separate questions: 1. Which tool generated or edited the code? 2. Which human initiated the work? 3. Which human approved the merge? Those questions matter later when a regression appears. A `Co-authored-by` line or release-note credit is not a root-cause analysis. It is an audit pointer. For that distinction, see [AI Code Attribution Needs Defect Forensics](/blog/ai-code-attribution-needs-defect-forensics). Attribution helps you find the trail. It does not prove cause. ## Layer 5: Make Agent Work Searchable Copilot-authored pull requests appearing in author searches sounds minor. It is not. Once agent PR volume rises, teams need ways to ask operational questions: - Which repos receive the most agent PRs? - Which agents open PRs that get merged? - Which agent PRs fail checks repeatedly? - Which teams are generating review load faster than they can absorb it? - Which incidents involved agent-authored changes? If agent work is not searchable, it becomes anecdotal. People argue from vibes. If agent work is visible in search, metrics, release notes, and review history, teams can inspect patterns. This connects directly to [FrontierCode and mergeability](/blog/frontier-code-benchmark-what-it-means-for-ai-coding). Passing a narrow test is not the same as producing code maintainers would merge. Searchable agent PR history gives teams a way to measure their own mergeability, not only vendor benchmark scores. ## The Opposing Take: Governance Can Become Theater The skeptical view is fair. Security validation, review tiers, attribution, release-note credit, and AGENTS.md context can all become box-checking. A team can add every label and still merge a bad agent change because nobody reproduced the issue, read the diff carefully, or understood the product intent. That is the failure mode to avoid. Good governance should reduce reviewer uncertainty. Bad governance creates more dashboards and labels without changing decisions. The test is simple: would this policy help a reviewer reject a bad PR faster? If the answer is no, the policy is probably theater. ## A Practical Agent PR Policy Here is the compact version I would put into a team handbook: ```text Agent-authored PR policy 1. Only approved and validated agents may create branches or pull requests. 2. Every agent PR must include the task, acceptance criteria, and verification output. 3. Review depth must match blast radius: docs, bug fix, dependency, security, migration. 4. AGENTS.md and code-review skills are part of the review contract. 5. Human review is required before merge, even when automated review passes. 6. Release notes should preserve both agent provenance and human operator credit. 7. Any production incident involving an agent PR gets defect forensics, not blame-by-label. ``` That policy is short enough to enforce and specific enough to matter. The main point: agent PR governance is not anti-agent. It is how you make agents useful without letting the review queue become a junk drawer. ## FAQ ### What is agent PR governance? Agent PR governance is the set of policies and review controls for pull requests opened or edited by AI coding agents. It covers which agents may act, what evidence every PR needs, how review depth is chosen, how attribution works, and when humans must approve changes. ### Does Copilot code review replace human review? No. Copilot code review can provide useful first-pass feedback, especially when it has repo instructions and team skills. It should not replace human review for product intent, architecture, security, migrations, or merge accountability. ### Why does AGENTS.md matter for code review? AGENTS.md gives review systems and coding agents repo-specific instructions. That helps automated review check local rules instead of only generic correctness. It is useful when the file points to actual commands, constraints, ownership rules, and verification expectations. ### Should all agent-authored PRs use the same review level? No. Review depth should follow blast radius. A copy edit, a small bug fix, a dependency update, and an auth change need different review effort. Teams should define tiers before agent PR volume grows. ### Is AI attribution enough to prove an agent caused a bug? No. Attribution is an audit signal, not causal proof. If a regression appears in AI-assisted code, teams still need defect forensics: reproduction, commit range, failing test, review history, and an explanation of which decision actually introduced the issue. ## Sources - [GitHub Changelog: Security validation for third-party coding agents](https://github.blog/changelog/2026-06-09-security-validation-for-third-party-coding-agents/) - [GitHub Changelog: Shape Copilot code review around your team](https://github.blog/changelog/2026-06-02-shape-copilot-code-review-around-your-team/) - [GitHub Changelog: Copilot code review AGENTS.md support and UI improvements](https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements/) - [GitHub Changelog: Generated release notes credit you for Copilot pull requests](https://github.blog/changelog/2026-06-18-generated-release-notes-credit-you-for-copilot-pull-requests/) - [GitHub June 2026 changelog archive](https://github.blog/changelog/month/06-2026/) - [GitHub Docs: About GitHub Copilot code review](https://docs.github.com/en/copilot/concepts/agents/code-review) - [GitHub Docs: About third-party coding agents](https://docs.github.com/en/copilot/concepts/agents/about-third-party-coding-agents)

Agent Sandbox Architecture: How to Choose the Right Runtime Boundary

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

AI agents are starting to need computers of their own. That sounds dramatic, but the architecture shift is simple. Once an agent can write code, run shell commands, edit files, install packages, inspect outputs, and keep working across sessions, a plain tool call is not enough. You need a runtime boundary around the work. That boundary is the sandbox. The question is no longer whether sandboxes matter. The question is which sandbox shape fits the job. **Last updated:** June 23, 2026 ## Official Sources | Resource | Link | |----------|------| | LangChain sandbox guide | [langchain.com/blog/how-to-choose-the-right-sandbox-for-your-agent](https://www.langchain.com/blog/how-to-choose-the-right-sandbox-for-your-agent) | | OpenAI Agents SDK docs | [developers.openai.com/api/docs/guides/agents-sdk](https://developers.openai.com/api/docs/guides/agents-sdk) | | OpenAI Agents SDK TypeScript | [openai.github.io/openai-agents-js/guides/sandbox-agents](https://openai.github.io/openai-agents-js/guides/sandbox-agents/) | | E2B sandbox docs | [e2b.dev/docs](https://e2b.dev/docs) | | Docker security | [docs.docker.com/security](https://docs.docker.com/security/) | ## Why This Is Timely LangChain's recent guide on [choosing the right sandbox for AI agents](https://www.langchain.com/blog/how-to-choose-the-right-sandbox-for-your-agent) puts the risk plainly: agent-written code can create threats to data and systems, so teams need to control where code runs and what it can access. The post calls sandboxes computers your agent can safely use. OpenAI's [Agents SDK docs](https://developers.openai.com/api/docs/guides/agents-sdk) now route builders toward sandbox agents when work needs files, commands, packages, snapshots, mounts, or provider links. The [TypeScript sandbox-agent docs](https://openai.github.io/openai-agents-js/guides/sandbox-agents/) describe persistent workspaces where agents can search document sets, edit files, run commands, generate artifacts, and resume from saved sandbox state. Flue's repo frames the same category from another angle: a sandbox agent framework where agents can keep context, use tools, modify files, and complete real work in a secure environment. That puts it in the same practical lane as the agent harness question in [Flue: Agent Harness Framework, Different or Just Shiny?](/blog/flue-agent-harness-framework-different-or-just-shiny). The trend is clear: sandboxing is becoming agent backend infrastructure. ## The Take: A Sandbox Is Not Just a Container The lazy version of sandboxing is "run it in Docker." That may be part of the answer. It is not the whole answer. A useful agent sandbox answers seven questions: | Question | Why it matters | |---|---| | What filesystem can the agent see? | Prevents accidental access to secrets, unrelated repos, or private data | | What network can it reach? | Limits exfiltration and malicious downloads | | Where do credentials live? | Keeps secrets out of untrusted code execution | | Can the workspace be snapshotted? | Enables resume, rollback, and incident review | | What resource limits apply? | Stops runaway CPU, memory, disk, and token-adjacent loops | | Which tools are mounted? | Keeps agent capability tied to task need | | What evidence is captured? | Makes the run reviewable after the model says it is done | If your sandbox only isolates processes but leaves secrets, network, logs, and snapshots vague, you still have a weak agent runtime. For the broader team-control-plane layer, read [Sandboxed Agents Are Becoming the Team Control Plane](/blog/sandboxed-agents-control-plane). This piece is the lower-level architecture guide. ## The Agent Lethal Trifecta LangChain uses a useful security frame: agents become risky when three ingredients combine. 1. They can access private data. 2. They can receive untrusted instructions. 3. They can exfiltrate data or take actions. That is the agent version of the lethal trifecta. The sandbox should break at least one side of that triangle. Ideally, it weakens all three: - only mount the files the task needs; - treat web pages, issues, docs, and customer messages as untrusted inputs; - block broad outbound network access; - inject credentials after the sandbox boundary instead of placing them inside it; - log every file, command, and network-relevant action. This is why "just ask the model not to leak secrets" is not a security control. The model may be tricked. The sandbox should make the trick less useful. ## Local vs Cloud Sandboxes The first architecture choice is where the sandbox lives. | Sandbox type | Best for | Watch out for | |---|---|---| | local process sandbox | fast iteration, private repos, developer-controlled tasks | weak isolation if it can see the whole machine | | Docker sandbox | repeatable builds, file work, package installs | secrets and network need explicit policy | | cloud sandbox | team workflows, background jobs, scalable runs | data residency, cost, vendor lock-in | | hosted provider sandbox | fastest path with managed lifecycle | opaque internals and provider-specific limits | | self-hosted remote sandbox | stronger control over data and models | operational burden and patching | There is no universal winner. A docs summarizer probably does not need a shell. A code migration agent probably does. A security triage agent may need an isolated workspace with no outbound network except approved package mirrors. A customer support agent may need no filesystem at all. The architecture should follow blast radius, not ambition. ## The Secrets Boundary Is the Real Test The most important sandbox design question is where credentials live. If secrets are mounted as plain files or environment variables inside the sandbox, untrusted code can try to read and leak them. That may be acceptable for a throwaway API key in a toy demo. It is not acceptable for production systems. LangChain's sandbox post describes an authorization-proxy pattern: credentials get injected into outbound traffic after it leaves the sandbox, so untrusted code inside the sandbox does not directly hold the secret. That is the shape teams should copy. The policy: ```text Do not put durable production credentials inside an agent sandbox. Give the sandbox scoped capabilities. Inject credentials at a controlled boundary. Log which capability was used, not only which command ran. ``` For coding-agent workflows, pair this with [Permissions, Logs, and Rollback](/blog/permissions-logs-rollback-ai-coding-agents). Permissions without logs are weak. Logs without rollback are a documentary. ## Snapshots Matter More Than People Expect OpenAI's sandbox-agent docs emphasize saved sandbox state and snapshots. That is not a minor convenience. Snapshots solve three practical problems: **Resume.** Long-running work can continue from the same files, packages, and generated artifacts instead of rebuilding context from scratch. **Rollback.** A bad edit, bad package install, or bad generated artifact can be compared against a previous state. **Review.** The team can inspect what the agent actually had in its workspace when it made a decision. Without snapshots, a failed agent run is often unreproducible. You have logs, but not the state those logs refer to. That connects directly to [agent workflows as code](/blog/agent-workflows-as-code-state-machines). If a workflow has typed gates, the sandbox snapshot is one of the receipts those gates should preserve. ## When Shell Access Is Overkill Not every agent needs a computer. Giving an agent shell and filesystem access increases capability, but it also increases attack surface. Before adding a sandbox, ask whether the agent can do the job with narrower tools: - database query tool with read-only access; - document retrieval; - structured API calls; - file search only; - code interpreter without network; - domain-specific function tools; - human approval before writes. If a narrow tool solves the workflow, use the narrow tool. Reach for a general sandbox when the agent genuinely needs to create or transform artifacts over multiple steps: code patches, notebooks, generated files, package experiments, build outputs, data analysis scripts, or long-running project work. That is the difference between useful autonomy and unnecessary blast radius. ## A Decision Checklist Before choosing a sandbox provider or framework, answer these questions: 1. Does the agent need a filesystem, or only structured tools? 2. Which files should be mounted by default? 3. Is outbound network blocked, allowlisted, or open? 4. Are secrets inside the sandbox, or injected at a proxy boundary? 5. Can the sandbox snapshot and resume state? 6. What CPU, memory, disk, and time limits apply? 7. Are logs and artifacts retained for review? 8. Can humans approve risky actions before they happen? 9. Can the run be reproduced from a snapshot? 10. Can the sandbox be self-hosted if policy requires it? If a vendor cannot answer those clearly, do not treat it as production-grade yet. ## The Opposing Take: Most Agents Should Stay Narrow The counterargument is strong: sandboxes are infrastructure, and infrastructure has cost. Many useful agents do not need general code execution. A support agent can answer from retrieved documents. A sales agent can draft follow-ups from CRM fields. A release-note agent can summarize merged pull requests. A documentation agent can propose edits through a narrow patch tool. That is also why the managed-agent decision in [Managed Agents vs LangGraph vs DIY](/blog/managed-agents-vs-langgraph-vs-diy-2026) should start with the runtime boundary, not the marketing category. For those agents, a full sandbox may be ceremony. The better default is least capability: - start with narrow tools; - add file access only when needed; - add shell only when command execution is central to the job; - add network only when the task proves it needs it; - keep snapshots and logs whenever stateful work begins. Sandboxes are powerful because they let agents do real work. That is also why they should not be handed out casually. ## FAQ ### What is an AI agent sandbox? An AI agent sandbox is an isolated runtime where an agent can work with files, commands, packages, tools, and artifacts without directly touching the host system or production environment. A good sandbox also controls network access, credentials, resource limits, snapshots, and logs. ### Is Docker enough for agent sandboxing? Docker can be part of a sandbox, but it is not sufficient by itself. You still need filesystem scoping, network policy, secrets handling, resource limits, snapshots, logs, and approval gates. ### When does an agent need shell access? An agent needs shell access when the task depends on running commands, installing packages, executing tests, transforming files, or generating artifacts. If the task can be handled through narrow structured tools, avoid shell access. ### Where should secrets live in an agent sandbox? Prefer keeping durable secrets outside the sandbox and injecting scoped credentials at a controlled boundary, such as an authorization proxy. Avoid placing production credentials directly into files or environment variables that untrusted code can inspect. ### What should I log from sandboxed agent runs? Log the task contract, mounted files, allowed tools, commands, file changes, network-relevant actions, approvals, snapshots, verification output, cost, latency, and final receipt. The goal is to make the run reproducible and reviewable. ## Sources - [LangChain: How to Choose the Right Sandbox for AI Agents](https://www.langchain.com/blog/how-to-choose-the-right-sandbox-for-your-agent) - [OpenAI API Docs: Agents SDK](https://developers.openai.com/api/docs/guides/agents-sdk) - [OpenAI Agents SDK TypeScript: Sandbox agents](https://openai.github.io/openai-agents-js/guides/sandbox-agents/) - [GitHub: withastro/flue](https://github.com/withastro/flue) - [Hacker News: Build and Host AI apps on your own servers](https://news.ycombinator.com/item?id=48631977)

Agent Workflows as Code: Why State Machines Beat Prompt Checklists

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Aharness GitHub](https://github.com/Alfredvc/aharness) | Workflow harness for Codex with finite state machine enforcement | | [OpenAI Agents SDK docs](https://developers.openai.com/api/docs/guides/agents-sdk) | Official SDK for building production agents with typed tools and state | | [LangChain custom agent harness](https://www.langchain.com/blog/how-to-build-a-custom-agent-harness) | Middleware patterns for retries, policies, and human approvals | | [XState documentation](https://stately.ai/docs) | State machine library referenced in the post | | [LangGraph docs](https://langchain-ai.github.io/langgraph/) | Graph-based agent orchestration with state nodes | Prompts can describe a workflow. They cannot enforce one. That is the sharp lesson from the latest agent tooling wave. OpenAI is moving production agent work away from hosted visual surfaces and toward the Agents SDK. LangChain is writing about custom harnesses as the scaffolding around the model. Aharness, a new Codex-focused project on GitHub and Hacker News, makes the argument more explicit: encode coding-agent workflows as finite state machines with typed gates, validated evidence, controlled transitions, repair paths, and inspectable logs. That is the right direction. The next useful abstraction is not a longer prompt. It is a workflow runtime the agent cannot casually ignore. **Last updated:** June 27, 2026 ## What Is New Here The fresh signal is [Aharness](https://github.com/Alfredvc/aharness), described as a workflow harness for Codex. Its pitch is narrow and practical: agent workflows should be finite state machines written in TypeScript, with states that define what Codex may do next and transitions that require validated exits. The [Show HN thread](https://news.ycombinator.com/item?id=48643056) frames the problem directly: models are capable enough for longer autonomous work, but process drift and context management are now the failure modes. Prompts and skills describe the process; they do not enforce it. That is the distinction worth writing down. It also fits the larger context from the last few days: - [OpenAI Agent Builder and Evals are on a shutdown path](/blog/openai-agent-builder-evals-migration), which pushes production agent logic toward code and repo-owned evals. - [LangChain's custom agent harness post](https://www.langchain.com/blog/how-to-build-a-custom-agent-harness) argues that production agents need middleware for retries, policies, human approvals, cost limits, and task-specific scaffolding. - OpenAI's [Agents SDK docs](https://developers.openai.com/api/docs/guides/agents-sdk) emphasize typed application code, direct tool control, custom storage, state, guardrails, human review, and observability. The direction is consistent: serious agent workflows are becoming software artifacts. ## The Take: Process Belongs in Runtime, Not Prompt Memory A prompt checklist can say: ```text Plan first. Only edit the requested files. Run tests. Attach evidence. Stop if tests fail twice. Ask before risky changes. ``` That is better than nothing. It is also easy for an agent to forget, reinterpret, or satisfy with a weak summary. A workflow runtime can enforce: - the agent cannot leave planning until it submits an accepted plan; - implementation cannot start until scope is declared; - verification cannot pass without command output; - repair can only loop a fixed number of times; - final reporting cannot happen until evidence is attached; - risky actions require a human gate. That is a different class of control. This is the same reason [long-running agents need harnesses](/blog/long-running-agents-need-harnesses). The model can do more work now. The surrounding system has to decide what counts as a valid move. ## Why Finite State Machines Fit Agent Work A finite state machine sounds academic until you map it to a coding-agent run. | State | Allowed exits | Evidence required | |---|---|---| | intake | accept task, request clarification, reject task | task contract | | plan | approve plan, revise plan | scoped plan and file boundaries | | implement | move to verify, request tool approval | diff summary | | verify | pass, fail, repair | command output and failing logs | | repair | retry verify, escalate, stop | fix attempt and retry count | | final | close run | receipt with changes, checks, risks | That is already how good human-led agent sessions work. The difference is whether the structure lives in the operator's head or in code. State machines give agent runs three useful properties: **Controlled transitions.** The agent can only move to states the workflow exposes. If there is no direct path from intake to final, the agent cannot skip planning and verification by writing a confident closeout. **Typed submissions.** Each state can require a specific shape of evidence: a plan object, a file list, a command transcript, a test result, or a risk note. Natural language becomes input to a verifier, not the verifier itself. **Repair paths.** Failure can be part of the workflow instead of an exception. A failed test can move the run to repair with a retry budget, or to escalation if the same failure repeats. That makes the workflow inspectable after the fact. You can ask where the run stalled, which gate failed, which evidence was missing, and whether the agent followed the process. ## Skills Still Matter, But They Are Not Enough This is not an argument against skills. Skills are useful because they package operating knowledge. A good skill can teach an agent how your team debugs flaky tests, writes release notes, reviews migrations, or handles UI QA. That is why [skills beat prompts](/blog/why-skills-beat-prompts-for-coding-agents-2026) for repeatable work. But a skill is still mostly instruction. It tells the agent what good looks like. A workflow runtime tells the agent what moves are allowed. You want both: - `AGENTS.md` for repo context; - skills for reusable methods; - MCP and CLI tools for observation and action; - state machines for process control; - eval receipts for outcome comparison. That is the stack the post-visual-builder world is converging on. ## Where LangChain's Harness Pattern Fits LangChain's custom harness post uses different language, but the problem is similar. The post defines a harness as scaffolding around the model that connects it to the real world. It specifically calls out middleware for retries, fallbacks, policy enforcement, PII handling, approval gates, steering, cost limits, and prompt caching. That is harness thinking. The useful part is "task-harness fit." A customer service agent, coding agent, data agent, and legal review agent should not share one generic runtime. They need different gates, tools, logs, and failure paths. State machines are one way to make that fit explicit. Middleware is another. LangGraph is another. The common point is that process moves out of invisible prompt wording and into something engineers can inspect. This is where [agent eval receipts](/blog/agent-evals-need-baseline-receipts) matter. Once the workflow is code, you can compare versions: - Did the new gate reduce bad final reports? - Did typed evidence increase pass rates? - Did repair loops save human review time or burn tokens? - Did stricter transitions make exploratory work worse? Those are answerable questions. ## The Opposing Take: State Machines Can Overfit the Work The strongest objection is also correct: not every agent task should be a state machine. Some work is exploratory. Research, debugging, discovery, architecture search, and incident response often start without a known path. If you force those into a rigid workflow too early, you get process theater: the agent fills boxes instead of thinking. That is the risk. The answer is not to wrap everything in a finite state machine. The answer is to encode the parts of the workflow that should not be ambiguous. Good candidates: - migration checklists; - release note generation; - dependency upgrade review; - security triage; - code review receipts; - frontend QA loops; - eval replay workflows; - deploy closeout checks. Bad candidates: - open-ended research; - early product exploration; - ambiguous architecture discovery; - first-pass debugging where the failure mode is not known. Use dynamic agent behavior for discovery. Use state machines for commitments. ## A Practical Pattern If I were turning a prompt checklist into an agent workflow, I would start with four files: ```text workflows/ bugfix.fsm.ts bugfix.schema.ts bugfix.evals.jsonl README.md ``` The finite state machine owns the legal transitions. The schema file owns typed submissions. The eval file owns representative tasks. The README explains when to use the workflow and when not to. For teams that already version prompts, this should feel like the next step after [Prompt Versioning with Promptlock](/blog/prompt-versioning-with-promptlock). Prompt diffs show what instructions changed. Workflow diffs show what the agent is allowed to do with those instructions. The key gates: | Gate | What it prevents | |---|---| | accepted task contract | vague work entering the run | | scoped plan | broad diffs before agreement | | declared file list | silent ownership expansion | | verification output | fake "tests passed" summaries | | bounded repair loop | endless retry token burn | | final receipt | unreviewable closeouts | This is not heavy process. It is the minimum scaffolding that keeps a capable agent from wandering. ## What To Watch Next The interesting race is not whether Aharness specifically wins. It is whether the pattern spreads. Watch for: - workflow packages shared like npm modules; - agent harnesses with typed submission schemas; - CI checks that verify agent workflow definitions; - visualizers that render state-machine runs for human review; - eval suites that compare workflow versions, not only model versions; - integrations that let Codex, Claude Code, Cursor, and custom agents consume the same process definitions. That last point matters. The durable artifact should not be "a prompt that works in one chat app." It should be a workflow definition that survives model and UI churn. The agent ecosystem is slowly relearning a very old software lesson: if a process matters, put it in code. ## FAQ ### What does "agent workflows as code" mean? It means encoding the agent process in versioned software artifacts instead of relying only on natural language prompts. The workflow can define states, allowed transitions, evidence requirements, retry limits, tool policies, and final receipts. ### Why use a state machine for coding agents? State machines make the run inspectable and enforceable. They prevent agents from skipping required stages, require evidence before transitions, and make failures route through defined repair or escalation paths. ### Are skills the same as workflows as code? No. Skills package operating knowledge and reusable instructions. Workflows as code enforce the process around the skill: when it runs, what evidence it must produce, what transitions are allowed, and when the run stops. ### When should I avoid state-machine agent workflows? Avoid rigid workflows for early exploration, open-ended research, and ambiguous debugging. Use them when the process is known and the cost of skipping steps is high: releases, migrations, security triage, code review receipts, eval replay, and deploy checks. ### Is Aharness only for Codex? Aharness is currently framed around Codex workflows, but the broader idea is not Codex-specific. Any coding-agent stack can benefit from typed gates, controlled transitions, repair paths, and inspectable evidence. ## Sources - [GitHub: Alfredvc/aharness](https://github.com/Alfredvc/aharness) - [Hacker News: Show HN Aharness](https://news.ycombinator.com/item?id=48643056) - [LangChain: How to Build a Custom Agent Harness](https://www.langchain.com/blog/how-to-build-a-custom-agent-harness) - [OpenAI API Docs: Deprecations](https://developers.openai.com/api/docs/deprecations) - [OpenAI API Docs: Agents SDK](https://developers.openai.com/api/docs/guides/agents-sdk) - [OpenAI Agents SDK TypeScript docs](https://openai.github.io/openai-agents-js/)

AI's Affordability Crisis Is Really an Agent Cost Accounting Problem

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | HN Affordability Discussion | [news.ycombinator.com/item?id=48646276](https://news.ycombinator.com/item?id=48646276) | | Claude API Pricing | [anthropic.com/pricing](https://www.anthropic.com/pricing) | | OpenAI API Pricing | [openai.com/api/pricing](https://openai.com/api/pricing) | | Gemini API Pricing | [ai.google.dev/pricing](https://ai.google.dev/pricing) | | OpenTelemetry Semantic Conventions | [opentelemetry.io/docs/specs/semconv/gen-ai](https://opentelemetry.io/docs/specs/semconv/gen-ai/) | The Hacker News thread around [AI's Affordability Crisis](https://news.ycombinator.com/item?id=48646276) is popular because it says the quiet part out loud: a lot of AI economics still do not feel settled. Cloud GPU supply is expensive. Frontier training is expensive. Inference is cheaper than it was, but not cheap enough to make every agent loop feel disposable. Token prices keep moving, vendors keep reshaping plans, and teams are trying to decide whether to buy subscriptions, call APIs directly, route across providers, or self-host open weights. That is the public argument. For developer teams, the more useful question is smaller: What are you actually paying for when an AI agent does work? **Last updated:** July 1, 2026 The answer is not just "tokens." Tokens are the easiest line item to see, but the real bill includes retries, tool calls, failed runs, cache misses, latency, GPU availability, human review, incident cleanup, and the opportunity cost of waiting for a stuck agent to finish. This is why the affordability debate matters. It is not a generic complaint that AI is expensive. It is a reminder that agent systems need cost accounting at the workflow level. ## Sticker Price Is the Wrong Unit Most pricing pages teach teams to think in dollars per million tokens or dollars per seat. That is necessary, but it is not enough. For normal chat, per-token pricing is a decent approximation. For agentic work, it hides the part that matters. An agent run has at least five cost surfaces: | Cost Surface | What It Measures | |---|---| | Model cost | input, output, cached input, batch discounts | | Runtime cost | session hours, containers, browsers, sandboxes, GPUs | | Retry cost | loops, failed tool calls, reruns, escalations | | Review cost | human time spent reading, validating, and fixing output | | Reliability cost | incidents, wrong changes, broken builds, stale context | The cheap model is not cheap if it needs three attempts. The expensive model is not expensive if it finishes once and saves a senior engineer an hour. The hosted plan is not predictable if a background agent can run all night. The self-hosted model is not free if it needs GPU ops, utilization tuning, and debugging. That is the missing unit: cost per accepted outcome. ## The Developer Cost Model Before cutting model spend, measure the workflow. For every serious agent path, log these fields: | Metric | Why It Matters | |---|---| | task type | bug fix, code review, research, migration, test repair | | model route | which model started, which model escalated, which provider served it | | input tokens | context size, cacheable prefix, retrieved chunks | | output tokens | answer size, patch size, tool chatter | | cache hit rate | whether stable context is actually being reused | | attempts | how many agent runs were needed before acceptance | | wall time | latency plus tool time plus queue time | | human review minutes | the cost most dashboards ignore | | outcome | accepted, edited, rejected, abandoned, reverted | This turns "AI is expensive" into a measurable system question. If output tokens dominate, tune prompts and stop verbose tool chatter. If retries dominate, improve harnesses and tests. If review time dominates, improve receipts and diffs. If cache misses dominate, stabilize prefixes. If every task escalates to the frontier model, your router is not routing. We covered the implementation side in [model routing recipes to cut AI spend](/blog/model-routing-recipes-cut-ai-spend), but the principle is broader: you cannot optimize what you only measure at the invoice level. ## The Four Mistakes That Make Agents Feel Unaffordable ### 1. Treating Every Task as Frontier Work Not every task deserves the best model. A docs summary, changelog draft, import rename, or test snapshot update should not start on the same route as a hard architecture migration. If your system cannot classify task difficulty, it will use premium capacity as the default. The practical pattern: 1. Start routine tasks on a cheaper workhorse route. 2. Escalate only when there is a measurable failure signal. 3. Keep the original attempt in the trace. 4. Compare cost per accepted task, not cost per call. That last point matters. A cheaper first pass that reliably filters easy work can reduce total cost even if the hard cases still escalate. ### 2. Ignoring Cache Hit Rate Agent runs resend the same context constantly: system instructions, repo conventions, tool docs, project summaries, and stable file context. If that prefix changes every time, you lose the main discount structure vendors are building around long-context workflows. A healthy agent setup should know: - what part of the prompt is stable - whether the stable prefix is identical across turns - how often cached input is actually hit - whether tools are adding noisy context ahead of the cache boundary This is why [DeepSeek's cache-first agent pattern](/blog/deepseek-reasonix-cache-first-coding-agents) is more than a cheap-token story. Cache design is a harness feature. Bad prompt assembly can erase the discount before the model sees the task. ### 3. Counting Tokens But Not Review Time A model bill is easy to export. Review time is not. But for developer teams, review time is often the larger cost. If an agent creates a 2,000-line diff that technically works but takes 90 minutes to trust, the low token price did not save much. Track review time as a first-class field: - time to understand the diff - time to run or repair tests - number of reviewer comments - number of follow-up agent turns - whether the work was merged, rewritten, or reverted This is the same lesson from the [$400 overnight agent bill](/blog/400-dollar-overnight-bill-agent-finops): uncontrolled work is not only expensive because tokens burn. It is expensive because someone has to untangle the result. ### 4. Moving to Self-Hosting Too Early Self-hosting open weights can be the right move at sustained volume. It can also turn a pricing problem into an operations problem. The break-even math depends on: - utilization - batchability - latency targets - hardware depreciation - serving stack maturity - on-call tolerance - quality difference versus hosted APIs If your workload is bursty, hosted APIs may stay cheaper because someone else eats the idle capacity. If your workload is steady, predictable, and privacy-sensitive, self-hosting starts to make sense. The [open-weights self-hosting break-even guide](/blog/self-hosting-open-weights-models-break-even-math) is the right companion here. The trap is deciding from ideology instead of utilization. ## What to Do This Week If you are worried about AI affordability, do not start by banning expensive models. Start with a one-week audit: | Day | Action | |---|---| | Day 1 | Add task IDs to every agent run | | Day 2 | Log model route, tokens, cache reads, and runtime | | Day 3 | Add accepted, edited, rejected, and reverted outcomes | | Day 4 | Sample 20 tasks and record human review minutes | | Day 5 | Sort by cost per accepted task | The result will usually show one of three problems. First, you have a routing problem: too much easy work starts on the premium path. Second, you have a harness problem: retries and failed tool calls dominate cost. Third, you have a review problem: the agent produces work that is expensive to trust. Each problem has a different fix. Pricing pages do not tell you which one you have. ## My Take AI affordability is real, but for developers it is not just a macro argument about GPUs and vendor margins. It is an operating discipline. Teams that only stare at per-token rates will make blunt decisions: downgrade the model, cancel seats, self-host too early, or route everything through the cheapest endpoint. Some of those moves will help. Some will quietly move cost into retries, review, latency, and maintenance. The better move is to price the whole workflow. Cost per accepted patch. Cost per resolved ticket. Cost per reviewed migration. Cost per support handoff. Cost per successful document extraction. That is the level where the affordability crisis becomes actionable. The winners will not be the teams that use the cheapest model everywhere. They will be the teams that know when cheap is enough, when expensive is worth it, and when the right answer is to stop the loop before it spends another hour pretending to make progress. ## FAQ ### What is the AI affordability crisis? The current affordability debate is about whether AI systems can become cheap enough for broad, sustained use given training costs, inference costs, GPU supply, energy use, and vendor pricing. For developer teams, the practical version is whether agents create enough accepted work to justify their total workflow cost. ### Why are token prices not enough for agent cost planning? Agent work includes retries, tool calls, runtime, cache misses, human review, and failure recovery. A low token price can still produce an expensive workflow if the model needs repeated attempts or creates output that takes too long to trust. ### What metric should engineering teams use instead? Use cost per accepted outcome. For coding agents, that may mean cost per merged patch, cost per resolved issue, or cost per accepted review. Include model spend, runtime, retries, and human review time. ### Should teams switch to cheaper models? Sometimes. Start by routing easier tasks to cheaper models and escalating on measurable failure signals. Do not move everything blindly. A cheap model that needs multiple retries can cost more than a stronger model that finishes once. ### When does self-hosting make sense? Self-hosting makes sense when volume is sustained, utilization is high, data constraints matter, and your team can operate the serving stack. For bursty workloads, hosted APIs often remain cheaper because they avoid idle GPU capacity and operational overhead. ## Sources Fetched June 23, 2026. - [DSHR: AI's Affordability Crisis](https://blog.dshr.org/2026/06/ais-affordability-crisis.html) - [Hacker News discussion: AI's Affordability Crisis](https://news.ycombinator.com/item?id=48646276) - [Anthropic pricing](https://www.anthropic.com/pricing) - [OpenAI API pricing](https://developers.openai.com/api/docs/pricing) - [Google Gemini API pricing](https://ai.google.dev/gemini-api/docs/pricing)

Armin Ronacher on The Coming Loop and Why Agent-Driven Code Still Needs Human Comprehension

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Armin Ronacher published [The Coming Loop](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/) today, and the piece immediately hit the Hacker News front page. As the creator of Flask and a long-time voice in the Python and Rust ecosystems, Ronacher's perspective on AI coding tools carries weight. The essay asks a question that has been circulating in engineering circles: what happens when the human engineer is no longer in the loop? **Last updated:** June 23, 2026 ## What The Essay Actually Says Ronacher distinguishes two nested loops in AI-assisted development: 1. **The agent loop** - the model calls tools, reads results, makes decisions, and iterates internally. This is what happens inside a single Claude Code or Codex session. 2. **The harness loop** - external systems decide when work continues. A harness can restart sessions, modify context, escalate tasks, or route work to another machine. This extends work past the point where the model would naturally stop. The harness loop is the new territory. It is where companies start to ask: can we run agents overnight without a human watching? Can we set up a CI job that loops until the tests pass? Can we let the machine keep going until it solves the problem or runs out of budget? Ronacher's answer is that yes, this is coming, whether developers want it or not. He is explicit about the competitive pressure: > Opting out of this fully machine-driven future may not be an option. He also notes the security angle. If attackers are using loops to find vulnerabilities, defenders may need loops to patch them. ## Where Loops Work Today The essay acknowledges that some tasks already work well in loop mode: - **Code porting and mechanical transformation** - moving a codebase from one language to another, applying a consistent refactor across thousands of files - **Performance benchmarking and optimization** - letting an agent iterate on a hot path until the numbers improve - **Security scanning and research exploration** - running an agent against a target until it finds something interesting - **Proof-of-concept generation** - producing a first draft that a human can then evaluate These are tasks where the output can be measured or verified without deep human judgment. ## Where Loops Fail The concerns are more interesting than the optimism. Ronacher observes that loop-generated code often exhibits specific failure modes: - Overly defensive, complex implementations - Redundant error handling instead of making bad states impossible - Lack of strategic thinking about system invariants - A style that prioritizes local correctness over global coherence He writes about the risk of losing comprehension: > For now I have not moved past the point of comprehension being important to me. That sentence resonates because it describes a line that many engineers are quietly drawing. The tools are powerful. The temptation to let them run is real. But something feels off about shipping code you do not understand. ## What HN Is Saying The [Hacker News thread](https://news.ycombinator.com/item?id=48643180) has over 200 comments, and the discussion is notably more cautious than the usual AI hype. Several commenters echoed the comprehension concern: > I feel uneasy, and I do not enjoy the work I deliver using LLMs. Others pushed back on the inevitability framing: > This is a very fatalistic take. Engineers getting increasingly distant from how things are getting built is not something that will 'undoubtedly happen, whether we like it or not.' One commenter made a practical observation about specifications: > Loops work when you spend the proper amount of time to understand what you want ahead of time. The prerequisite is clarity - enough clarity that you could write a careful specification that you could hand off to a junior colleague. Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions. This point deserves emphasis. The loop is not a substitute for thinking. It is a tool for executing after the thinking is done. Another commenter raised the cost angle: > Currently my org of 8 people use around 1000 euro worth of tokens per month. We've recently had a discussion near the water-cooler, that if the cost climbs 5x-10x it may be just more worth it to get more developers. That math is real. Loops multiply token usage. At API rates, overnight agent sessions can cost hundreds or thousands of dollars. ## The Unsolved Problem The essay ends without a clean resolution, which is honest. Ronacher is describing a tension that does not have an obvious answer: - Loops are coming because competitive pressure and security threats demand them. - Loops produce code that humans struggle to understand. - Systems built on code no one understands become unmaintainable. - Unmaintainable systems eventually fail in ways that matter. The question is not whether to use loops. The question is how to use them without losing the engineering judgment that makes software reliable. ## A Practical Frame For developers reading this today, a few practical takeaways emerge: **1. Separate exploration from execution.** Use loops for tasks that have clear success criteria. Use interactive sessions for tasks that require judgment. **2. Budget for review.** If a loop produces code overnight, someone needs to understand that code before it ships. The loop does not eliminate review time - it moves it. **3. Watch the cost curve.** Loops can burn through token budgets fast. Set hard limits. Monitor spend. The productivity gain is only real if it does not blow your budget. **4. Keep comprehension in scope.** If you cannot explain what the code does, you probably should not ship it. This rule has not changed just because the code was written by a machine. **5. Be skeptical of inevitability claims.** "Everyone will do this" is not a reason to do it. Teams should make deliberate choices about how much autonomy they grant their tools. ## My Take Ronacher is one of the clearer thinkers in the developer tools space, and this essay captures a real tension. The loop is seductive because it promises to remove the human bottleneck. But the human bottleneck is also the human judgment. Removing it is not free. The most useful framing I have seen is this: treat loops as automation, not intelligence. Automation is great for repetitive, well-specified tasks. Intelligence is what you need when the spec is ambiguous, the trade-offs are unclear, or the consequences of failure are high. For code that matters, the human is still in the loop - not because the tools are bad, but because the stakes require it. ## FAQ ### What is "The Coming Loop"? "The Coming Loop" is an essay by Armin Ronacher exploring the tension between autonomous AI coding agents that loop without human oversight and the engineering comprehension needed to maintain reliable software. ### What is a harness loop? A harness loop is an external system that decides when an AI agent's work should continue, restart, or escalate. It extends agent work beyond a single session, potentially running overnight or across multiple machines. ### Does Armin Ronacher recommend using loops? Ronacher describes loops as likely inevitable due to competitive and security pressures, but expresses unease about the loss of code comprehension that comes with hands-off agent work. ### What are the risks of loop-driven development? Risks include overly defensive code, loss of architectural coherence, high token costs, and shipping code that no human fully understands. ### Should teams adopt harness loops today? The essay and HN discussion suggest caution. Loops work best for well-specified, measurable tasks. For code that requires judgment, interactive sessions with human oversight remain more appropriate. ## Sources - [The Coming Loop - Armin Ronacher](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/) - [Hacker News discussion](https://news.ycombinator.com/item?id=48643180)

Cerebras Stock Is a Public Test of AI Inference Demand

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

`CBRS stock` showed up in the United States Google Trends feed today after Cerebras reported its first earnings as a public company. That is not just a finance story. For developers, it is a useful signal that AI inference infrastructure has crossed into a more measurable phase. The market is not only asking whether a chip company has a better architecture. It is asking whether fast inference can become durable revenue, how much margin the compute buildout consumes, and whether large AI customers turn into a repeatable business rather than one dramatic backlog number. **Last updated:** June 23, 2026 This is not investment advice. The more useful lens for Developers Digest is operational: what does public-market scrutiny reveal about the infrastructure layer underneath coding agents, chat apps, model routers, and AI-native products? ## What Happened Google Trends' US daily feed surfaced `cbrs stock` today with related coverage around Cerebras' first earnings report since its IPO. The numbers in current market coverage point in the same direction: | Signal | What it suggests | |---|---| | Q1 revenue came in around $193 million in multiple reports | demand for non-GPU AI infrastructure is real enough to measure publicly | | year-over-year revenue growth was reported in the low-to-mid 90% range | the category is still in rapid expansion mode | | shares fell after hours despite the revenue beat | investors are looking past growth and into margins, concentration, and execution risk | | guidance for the next quarter was above several analyst expectations | buyers still appear to be pulling compute capacity forward | The tension is the story. Cerebras can show strong revenue growth and still face pressure because AI infrastructure is expensive to build, hard to forecast, and exposed to a small number of very large customers. That is the same pattern developers feel one layer up. AI products can look magical in a demo and still run into token budgets, latency ceilings, approval loops, review queues, and vendor concentration. ## The Developer Angle Cerebras is already in the Developers Digest tools directory as an [AI infrastructure provider](/tools/cerebras). The product pitch is simple: wafer-scale systems and very fast inference, exposed through developer-facing APIs and partnerships. The public-market version of that pitch is less simple. Developers care about: - time to first token - output tokens per second - model availability - OpenAI-compatible APIs - reliability during spikes - price per million tokens - enough capacity for real users Public investors care about: - revenue growth - gross margin - customer concentration - capex intensity - backlog quality - guidance - whether large AI contracts convert into profitable recurring demand Those lists are now connected. If a provider has to spend aggressively to serve inference demand, that can eventually affect pricing, rate limits, model availability, enterprise contracts, and which workloads get priority. If one or two strategic customers dominate demand, that can affect roadmap incentives. If the economics improve, developers get a larger menu of fast inference options. That is why `CBRS stock` belongs in an AI developer publication. The ticker is just the visible part of the infrastructure question. ## Why Fast Inference Matters Fast inference is not only a vanity benchmark. It changes product shape: - voice agents feel conversational instead of staged - coding agents can iterate through tests faster - model routers can afford retries and fallbacks - UI copilots can respond before users context-switch - long-running agents can spend less wall-clock time waiting on model output We saw a related pattern in [diffusion language models](/blog/diffusion-language-models): speed can come from architecture, not only hardware. We saw it again in [Windsurf's SWE model infrastructure](/blog/windsurf-swe-1-vs-cursor-composer), where fast serving changes how an AI coding tool feels in the editor. Cerebras represents the hardware-heavy version of the same bet. If inference becomes cheap and fast enough, product teams can design around agent loops instead of treating every model call as a scarce event. The hard part is that cheap, fast, reliable, and profitable do not automatically arrive together. ## The Market Is Asking the Right Questions The useful market pushback is not "AI is fake." It is more specific: - Can non-GPU infrastructure scale without destroying margin? - Are large AI customers durable customers or launch-window accelerants? - Does speed command a premium, or does it quickly get competed away? - How much capacity must be built before revenue arrives? - Do developers route meaningful workloads to specialized providers, or keep defaulting to model vendors and hyperscalers? Those are also product questions. If you are building an AI app, [model routing](/blog/model-routing-recipes-cut-ai-spend) is no longer just about picking the smartest model. It is about matching latency, cost, reliability, and vendor risk to the task. A fast inference provider can be the right answer for: - real-time coding suggestions - voice interfaces - high-volume batch summarization - agent loops with many short turns - retrieval workflows where model latency dominates database latency It may be the wrong answer if the workload needs a model that is unavailable, a compliance posture the vendor cannot support, or a cost profile that only works at promotional pricing. ## What to Watch Next For developers, the next Cerebras questions are practical: 1. Does the API remain easy to integrate into OpenAI-compatible stacks? 2. Do latency and throughput claims hold under normal developer workloads? 3. How many production models are actually available? 4. Does pricing stay predictable as public-company pressure increases? 5. Do OpenAI, AWS, or other large partnerships improve capacity for everyone, or absorb the best capacity first? Those are the same questions any team should ask before moving traffic to a specialized inference provider. The finance section matters here too. The site now has market pages where readers can continue from the article into public-company data. For this story, the useful follow-up is [CBRS filings](/markets/cbrs/filings), [CBRS market cap](/markets/cbrs/market-cap), and the broader [markets filings feed](/markets/filings). The goal is not to turn Developers Digest into a stock-picking site. It is to make the infrastructure layer easier to inspect when the companies behind that layer become public. ## My Take Cerebras' first earnings report is a useful reminder that the AI stack has two scoreboards now. One scoreboard is technical: latency, throughput, model quality, API ergonomics, and developer trust. The other is financial: revenue growth, margins, backlog, customer concentration, and capital intensity. For the next wave of AI infrastructure, both scoreboards matter. Developers may not care about every quarterly number, but they should care when those numbers explain why an API is fast, cheap, rate-limited, repriced, deprioritized, or suddenly strategic. Google Trends catching `CBRS stock` is a small signal. The bigger signal is that AI inference is no longer only a benchmark chart. It is a public-market operating system constraint. ## FAQ ### Why is Cerebras relevant to developers? Cerebras sells AI infrastructure and inference capacity. If fast inference becomes easier to buy through APIs, developers can build lower-latency agents, coding tools, voice interfaces, and high-volume AI workflows. ### Is this a stock recommendation? No. This post uses the public-market reaction as an infrastructure signal. It is not investment advice and does not recommend buying or selling CBRS. ### What did Google Trends show? The United States Google Trends daily RSS feed surfaced `cbrs stock` on June 23, 2026, with related news coverage about Cerebras' first public-company earnings report. ### What should developers watch after Cerebras earnings? Watch API availability, real-world latency, pricing stability, supported models, reliability during traffic spikes, and whether large strategic customers affect capacity for normal developer workloads. ### How does this connect to model routing? Model routing is about assigning each task to the right provider. A specialized inference provider can be valuable when speed matters, but teams still need fallbacks, cost controls, and a clear policy for vendor concentration. ## Sources Fetched June 23, 2026. - [Google Trends US daily RSS feed](https://trends.google.com/trending/rss?geo=US) - [Cerebras Q1 2026 earnings date announcement](https://investors.cerebras.ai/news-releases/news-release-details/cerebras-systems-sets-date-first-quarter-2026-financial-results) - [Investors Business Daily: AI Upstart Cerebras Beats Q1 Sales Target](https://www.investors.com/news/technology/cerebras-stock-cbrs-first-report-post-ipo-q1-2026/) - [Investopedia: Cerebras first earnings preview](https://www.investopedia.com/cerebras-is-about-to-report-earnings-for-the-first-time-since-its-ipo-here-s-how-much-the-stock-is-expected-to-move-cbrs-12003990) - [SEC: Cerebras S-1 filing](https://www.sec.gov/Archives/edgar/data/2021728/000162828024041596/cerebras-sx1.htm)

Claude Outages Are a Workflow Design Problem

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Claude outages are easy to treat as vendor news. That is usually the least useful angle. The better question for developers is: what happens to your workflow when Claude.ai, Claude Code, or the Claude API degrades for an hour? If the answer is "everything stops and nobody knows what state the agent was in," the fragile part is not only the provider. It is the workflow. **Last updated:** June 23, 2026 Anthropic's status page currently reports its major services as operational, but June 2026 has already had several posted incidents, including elevated Claude.ai error rates, elevated errors across multiple models, elevated API error rates, and a June 18 service disruption on Claude services. The point is not to single out Claude. The point is that Claude is a normal production dependency. Production dependencies need fallback plans. ## This Is Not Just an API Retry Problem We already have a [Claude API reliability playbook](/blog/claude-api-reliability-error-handling) for retry logic, rate limits, backoff, request IDs, and error handling. This post is about a different layer: the AI coding workflow. When Claude Code or the API degrades, your team needs answers to questions like: | Question | Why it matters | |---|---| | What was the agent doing? | prevents duplicated work and unsafe restarts | | What files changed? | lets a human review or resume elsewhere | | Which checks passed? | separates useful progress from partial output | | What model was in use? | helps distinguish capacity, quality, and cost issues | | Can the task move to another model? | keeps low-risk work moving | | Is there a checkpoint? | avoids losing a long session | | Should the run stop? | prevents noisy retries and token burn | That is a workflow design problem. ## 529 Is Not Your Usage Limit Anthropic's API docs distinguish `529 overloaded_error` from `429 rate_limit_error`. That distinction matters. A `429` usually means your request hit a rate or usage boundary. A `529` means the service is temporarily overloaded. Claude Code's error docs say it retries transient failures with exponential backoff before surfacing an error, and repeated 529s indicate temporary API capacity issues across users, not necessarily your personal limit. The practical response is different: - For `429`, reduce usage, respect rate-limit headers, queue work, or raise limits. - For `529`, wait, retry with backoff, check status, and consider switching models if the issue is model-specific. But neither response solves the whole coding-agent problem. A retry loop cannot tell you whether the agent's half-finished refactor is safe. That is where [the agent reliability cliff](/blog/the-agent-reliability-cliff) starts to matter. The model can be good most of the time and still create operational trouble when a long task fails at the wrong moment. ## The Workflow That Survives an Outage A resilient Claude workflow has four layers. ### 1. Small task slices Do not put a whole migration, redesign, test suite rewrite, and deploy into one giant Claude session. Use slices: - one module - one route - one test family - one content post - one dependency upgrade - one review pass Small slices are easier to checkpoint, hand off, or rerun with another model. ### 2. Receipts after every meaningful step Claude should leave evidence: - commands run - files changed - tests passed - tests skipped - screenshots captured - source links used - assumptions made - next action recommended This is why [agent swarms need receipts](/blog/agent-swarms-need-receipts). If the provider degrades, receipts let another agent or human resume without guessing. ### 3. Model-switch paths Anthropic's Claude Code docs recommend using `/model` to switch models when capacity is model-specific. That is useful, but only if the task can tolerate a model switch. Some work can move: - summarizing logs - drafting docs - simple tests - small refactors - repetitive cleanup Some work should wait: - risky security changes - ambiguous architecture calls - subtle UI review - migrations with data risk - tasks where the original context is too large to reconstruct This is where [model dependency risk](/blog/model-dependency-risk-after-fable-5) and [model routers as optionality](/blog/model-routers-optionality-advantage-2026) become practical. Multi-provider fallback is not magic. Schemas, tools, context formats, and behavior differ. The workflow needs to say which tasks can switch and which should pause. ### 4. Local artifacts If all useful state lives inside a chat session, you are fragile. Keep state in the repo: - task notes - TODO files - test output - screenshots - patch files - issue links - source citations - deploy evidence This is the same reason [long-running agents need harnesses](/blog/long-running-agents-need-harnesses). The agent's value should survive the session. ## A Claude Outage Playbook for Coding Teams Use this as a simple operating rule. | Event | Team response | |---|---| | Claude.ai degraded | pause exploratory chat, keep repo-local work moving | | Claude Code 529s | wait, check status, switch model only for safe slices | | API elevated errors | queue user-facing work, retry with jitter, preserve request IDs | | long agent session fails | inspect diff, logs, and receipts before restarting | | model quality regression | reduce task scope, add tests, compare against baseline | | repeated failures | stop the run and write a handoff note | The point is not to avoid every outage. The point is to avoid losing the thread. For Claude Code specifically, that means your `CLAUDE.md`, `AGENTS.md`, or project instructions should include: - when to stop retrying - how to record progress - which commands prove the work - which files are in scope - which tasks may switch models - what evidence must be in the final answer The [Claude Code usage limits playbook](/blog/claude-code-usage-limits-playbook-2026) covers the capacity and burn-rate side. The [Claude token burn observability post](/blog/claude-code-token-burn-cache-observability) covers monitoring. This post is the operational layer around both. ## The Practical Take Claude outages do not mean "never depend on Claude." They mean "do not make Claude the only place your work exists." The resilient workflow is boring: - smaller tasks - visible checkpoints - local artifacts - request IDs - saved diffs - model-switch rules - stop conditions - human review When Claude is healthy, that structure makes agents more productive. When Claude degrades, it keeps the work recoverable. That is the difference between an AI coding habit and an AI coding system. ## FAQ ### Is Claude down right now? Check Anthropic's official status page for the current state. This post is about designing workflows that survive degraded Claude.ai, Claude Code, or API availability. ### What is a Claude 529 error? Anthropic documents `529 overloaded_error` as temporary overload, distinct from a `429 rate_limit_error`. It can happen during high traffic across users. ### Should I switch models during a Claude outage? Only for safe, bounded task slices. Model switching is useful for docs, summaries, small fixes, and repetitive work. Risky migrations, security changes, and ambiguous architecture work may be better paused. ### How do I make Claude Code work resilient? Use small tasks, repo-local notes, clear stop conditions, saved diffs, test evidence, model-switch rules, and final receipts that let another agent or human resume. ## Sources - [Anthropic status page](https://status.claude.com/) - [Anthropic API errors documentation](https://platform.claude.com/docs/en/api/errors) - [Claude Code error reference](https://code.claude.com/docs/en/errors) - [Anthropic April 23 postmortem](https://www.anthropic.com/engineering/april-23-postmortem) - [Hacker News: Claude.ai unavailable and elevated errors on the API](https://news.ycombinator.com/item?id=47938097) - [Hacker News: A postmortem of three recent issues](https://news.ycombinator.com/item?id=45281139)

Anthropic Claude Tag Turns Slack Into a Shared Agent Workspace

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Anthropic released Claude Tag today, and the easy headline is "Claude comes to Slack." That undersells it. The more interesting shift is that Claude is becoming a team-visible participant in the place where work already gets assigned, debated, and handed off. Instead of asking an AI assistant a private question, a channel can tag Claude into a shared thread, give it context from the conversation, and let the team see the result. That changes the shape of agent work. **Last updated:** June 23, 2026 Claude Tag is in beta for Team and Enterprise customers. Anthropic describes it as a Slack integration where you mention `@Claude` in channels or direct messages, then Claude works through the task and responds in-thread. The setup is admin-controlled, channel-scoped, and tied to tool access that administrators define. Anthropic also says Claude Tag replaces the previous Claude in Slack app and currently works with Opus 4.8. The product detail matters, but the real question for developers is larger: What happens when the default interface for an agent is not a private chat window, terminal session, or API call, but a shared team channel? ## What Anthropic Actually Shipped Based on Anthropic's launch post and docs, Claude Tag gives Slack workspaces a first-party way to invoke Claude in normal Slack conversations. The basic flow is intentionally simple: 1. A workspace admin installs and configures Claude Tag. 2. A user mentions `@Claude` in Slack. 3. Claude reads the relevant thread or channel context available to it. 4. Claude replies in Slack so the team can review, continue, or correct the work. Anthropic positions it around everyday team work: summarizing threads, answering questions, drafting follow-ups, turning scattered discussion into action items, and helping teams keep momentum without leaving Slack. That sounds familiar because Slack has had AI features and bot integrations for years. The difference is the Anthropic-native identity and model surface. Claude Tag connects Claude directly to a shared collaboration layer, rather than forcing every team to build its own Slack bot, OAuth flow, prompt wrapper, and permission model. The boldest line in the launch post is Anthropic's own internal usage claim: the company says 65% of its product team's code is created by its internal version of Claude Tag. Treat that as vendor-reported evidence, not a neutral benchmark. Still, it tells you how Anthropic wants teams to understand the product: not as a notification bot, but as a multiplayer agent interface for real work. For a developer team, this is not just another chatbot. It is a new place for agent work to start. ## Why Slack Is a Serious Agent Surface Most teams already treat Slack as a semi-structured operating system: | Work Pattern | What Slack Already Holds | |---|---| | Incident response | timeline, owners, symptoms, links, decisions | | Product planning | requirements, debates, launch notes, objections | | Code review escalation | PR links, reviewer context, blockers | | Customer support | issue summaries, screenshots, account details | | Daily operations | reminders, handoffs, status, follow-ups | That context is usually trapped in human conversation. Agents can operate on it only when someone manually copies the useful parts into a prompt. Claude Tag reduces that copying step. A team can bring Claude to the thread where the context already exists. This pairs with the broader Anthropic pattern we covered in [Claude Code remote control](/blog/claude-code-remote-control): Claude is moving from one private prompt box toward many operational surfaces. Remote sessions, scheduled tasks, managed agents, and now Slack mentions all point in the same direction. The assistant is becoming ambient infrastructure around the team's work loop. ## The Useful Developer Workflows The obvious use cases are summaries and drafts. The better ones are workflow handoffs. ## 1. Incident Threads During an incident, Slack usually becomes the source of truth before the postmortem exists. Claude Tag can help turn the live thread into: - a timeline - current hypothesis - commands already tried - open questions - next owner - customer-facing update draft The important detail is that the answer happens in the same thread. Other engineers can correct Claude immediately, which is safer than one person privately asking an assistant and pasting back a polished summary that nobody can audit. ## 2. PR and Release Coordination Developer teams already paste GitHub, Linear, Jira, Sentry, and deploy links into Slack. Claude Tag can sit on top of that coordination layer: - summarize the current blocker - list which links still need action - draft a release note from the discussion - extract follow-up tasks - identify who made which decision It does not replace CI, code review, or release tooling. It makes the messy conversation around those tools more legible. This is exactly the kind of boundary we discussed in [Claude Code routines vs managed agent schedules](/blog/claude-code-routines-vs-managed-agents-schedules): recurring and operational agent work needs the right identity, trigger, and review surface. Slack is a natural trigger and review surface for team-visible work. ## 3. Support-to-Engineering Handoffs Support and solutions teams often have the best customer context, while engineering has the fix path. Slack is where that context gets compressed, sometimes badly. Claude Tag can help turn a long support thread into: - reproduction steps - impacted accounts - observed symptoms - suspected subsystem - missing evidence - escalation note for engineering The win is not that Claude knows the product perfectly. The win is that it can create a first draft of the handoff in the same place the people with context are already talking. ## 4. Meetingless Planning Teams that avoid meetings often replace them with long Slack threads. That works until the thread becomes too long to re-enter. A channel-native Claude can summarize the current decision, arguments for each option, unresolved objections, and suggested next step. That is especially useful when the alternative is another meeting where everyone replays the thread from memory. ## The Governance Questions Matter More Than the Demo The demo version is easy: tag Claude, get a helpful answer. The production version is more serious: - Which channels can Claude access? - Can Claude read private channels? - What context does it receive from a thread? - Can admins disable it for sensitive workspaces? - What data retention policy applies? - Are Slack messages used to improve models? - How are user identities and audit logs handled? - Can security teams review usage? Anthropic says administrators can define which tools and information Claude can access in which channels, keep memories scoped to those channel-defined identities, set token-spend limits, and review a log of what Claude did and who requested each task. Those controls are the right shape. Teams still need to decide their own policy before putting Claude in sensitive channels. The broader rule is stable: once an agent enters Slack, it enters the company's social and operational memory. That requires tighter policy than a personal assistant. This is also why the feature fits into the [Anthropic vs OpenAI developer experience](/blog/anthropic-vs-openai-developer-experience) comparison. Anthropic keeps pushing toward opinionated work surfaces: Claude Code, Team/Enterprise controls, managed agents, and now a first-party Slack presence. OpenAI has its own connector and agent platform story, but Anthropic's product direction is increasingly about embedding Claude where work already happens. ## Slack Connector vs MCP Server Developers may ask why this matters if Slack MCP servers already exist. The answer is that they solve different problems. An MCP Slack server gives an agent tool access to Slack. Claude Tag gives Slack users a first-party way to summon Claude inside Slack. | Approach | Starts From | Best For | |---|---|---| | Slack MCP server | agent runtime | agent reads/posts Slack as one tool among many | | Claude Tag | Slack thread | humans bring Claude into shared team context | | Custom Slack bot | internal app | bespoke workflows and strict company-specific policy | If you are building an internal agent platform, an MCP server or custom bot may still be the right path. If your team already uses Claude and wants shared Slack-native assistance without building the integration layer, Claude Tag is the simpler product move. For deeper protocol context, start with our [complete MCP server guide](/blog/complete-guide-mcp-servers). MCP is the tool interface story. Claude Tag is the collaboration surface story. ## The Risk: Slack Becomes Another Prompt Dump The strongest counterargument is that Slack is already noisy. Adding an AI participant can make it worse. Bad Claude Tag usage will look like this: - every thread gets summarized whether it needs it or not - people tag Claude instead of reading the thread - sensitive context gets pulled into channels too casually - action items appear without clear owners - teams accept polished summaries without checking facts That is not a model problem. It is a workflow problem. The best teams will create simple norms: 1. Tag Claude when there is a concrete output needed. 2. Ask for receipts, not vibes. 3. Keep sensitive channels out unless policy is clear. 4. Assign a human owner to every Claude-generated action list. 5. Treat summaries as drafts until someone validates them. This is the same principle behind [agent workspaces needing filesystem contracts](/blog/agent-workspaces-need-filesystem-contracts). Shared agents need boundaries. In Slack, the boundary is not a directory. It is a channel, thread, audience, and retention policy. ## My Take Claude Tag is not important because Slack needed another assistant. It is important because team agents need shared interfaces. Private chat is good for exploration. Terminals are good for implementation. APIs are good for production systems. Slack is good for coordination, context, and accountability. That makes it a natural home for a certain class of agent work: - summarize - hand off - triage - draft - extract decisions - keep a shared thread moving The mistake would be asking Slack Claude to become the whole agent platform. The opportunity is narrower and more useful: make the messy human coordination layer easier to convert into reviewed, assigned, trackable work. For engineering teams, that is enough to matter. ## FAQ ### What is Claude Tag? Claude Tag is Anthropic's Slack-based beta that lets Team and Enterprise users mention Claude from Slack and get responses in the conversation context. ### Is Claude Tag the same as a Slack MCP server? No. A Slack MCP server gives an agent tool access to Slack from an agent runtime. Claude Tag starts inside Slack, so humans can bring Claude into a shared team thread directly. ### Who can use Claude Tag? Anthropic says Claude Tag is available in beta for Team and Enterprise customers. Admin setup and access controls should be checked against the current Anthropic docs before rollout. ### What is the best developer use case? Incident summaries, PR coordination, support-to-engineering handoffs, and planning-thread synthesis are the strongest early use cases because they already happen in Slack and benefit from shared review. ### What should teams decide before enabling it? Decide which channels Claude can access, what data retention policy applies, how usage is audited, and when a human must validate Claude's output before it becomes an action item. ## Sources Fetched June 23, 2026. - [Anthropic: Introducing Claude Tag](https://www.anthropic.com/news/introducing-claude-tag) - [Claude Tag product page](https://claude.com/product/tag) - [Anthropic Claude for Enterprise](https://www.anthropic.com/enterprise) - [Slack platform documentation](https://api.slack.com/) - [Model Context Protocol](https://modelcontextprotocol.io/)

Codex-Maxxing: How to Run Long-Running Codex Workflows Without Losing the Plot

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Codex-Maxxing is a fun phrase for a serious workflow shift. OpenAI is clearly pushing Codex beyond one-off code edits. The current Codex surface spans the app, CLI, IDE integration, cloud tasks, background work, subagents, `AGENTS.md`, and model choices tuned for longer software work. The mistake is interpreting that as "let the agent run forever." The better interpretation is bounded autonomy. **Last updated:** June 23, 2026 Codex is becoming useful for long-running work because it can keep state, operate in worktrees, follow repo instructions, run commands, and split tasks when asked. But the workflow only compounds if the human stays in mission control: define the job, constrain the workspace, demand receipts, review checkpoints, and stop bad runs early. ## What Codex-Maxxing Should Mean The useful version of Codex-Maxxing is not bigger prompts or longer unattended sessions. It is a system: | Layer | Practical meaning | |---|---| | repo instructions | `AGENTS.md` tells Codex how the project works | | scoped worktree | each effort has a clean branch or worktree | | explicit goal | the task has a finish line and stop conditions | | checkpoints | the agent reports evidence before pushing further | | subagents | only used when the work is genuinely separable | | budgets | token, time, disk, and process limits are visible | | review trail | commits, tests, screenshots, logs, and diffs prove the work | That connects directly to the [OpenAI Codex guide](/blog/openai-codex-guide): Codex is strongest when the task is concrete enough for the agent to inspect the repo, make changes, run checks, and explain the result. Long-running work just raises the bar. ## The Real Codex Surface Area OpenAI's current Codex docs describe several pieces that matter for long-running workflows: - Codex CLI runs locally from the terminal, can read and modify code in the selected directory, and is open source. - Codex cloud can run background tasks in its own environment. - `AGENTS.md` is a first-party customization surface that Codex reads before work. - Subagents can be spawned in parallel when explicitly requested. - The Codex app launch framed the product around supervising multiple agents, parallel work, and worktrees. - OpenAI positions newer Codex models for tasks involving research, tool use, and complex execution. That is a meaningful shift from "AI pair programmer" to "agent workspace." It also explains why the [June Codex changelog](/blog/codex-changelog-june-2026) matters. Goals, browser use, permissions, plugins, model updates, and background work are not isolated features. They are pieces of a control plane for software tasks that take longer than one chat turn. ## The Bounded Autonomy Playbook Here is the workflow I would actually trust. ### 1. Start with a small worktree Do not hand a long-running agent your entire main checkout and a vague instruction. Give it a narrow worktree: - one branch - one repo - one task family - known files or modules - clear no-touch areas - a rollback path This is the same reason [parallel coding agents need merge discipline](/blog/parallel-coding-agents-merge-discipline). The more agents you run, the more you need isolation and clean integration points. ### 2. Put the job in `AGENTS.md` `AGENTS.md` should not be a motivational poster. It should be the local operating manual: - commands to run - test expectations - design rules - content rules - deploy paths - forbidden categories - review evidence required - when to stop and ask Codex reads these files as project instructions. That means your repo can carry the work style forward instead of forcing every session to rediscover it. ### 3. Define stop conditions A long-running workflow needs explicit stops: - stop after N failed attempts at the same test - stop if the diff crosses the assigned files - stop if a dependency install changes lockfiles unexpectedly - stop if a deploy health check does not flip after a defined window - stop before destructive git commands - stop before sending email, posting externally, or changing billing settings Without stop conditions, "autonomy" becomes drift. ### 4. Use subagents only for separable work OpenAI's subagent docs make an important point: subagents can consume more tokens than comparable single-agent runs. So the question is not "can I spawn more agents?" It is "is this work independent enough that parallelism reduces wall-clock time without creating merge debt?" Good subagent work: - research three independent sources - inspect unrelated modules - draft separate content candidates - run verification while the main agent implements - compare options and report evidence Bad subagent work: - five agents editing the same component - vague "improve the codebase" prompts - duplicated source research - long-running agents with no output contract - background tasks that nobody checks This is where [Codex automations](/blog/codex-automations-recurring-engineering-work) and [long-running agent harnesses](/blog/long-running-agents-need-harnesses) meet. Automation is useful when the harness makes the output reviewable. ## Budgets Are Part of the Workflow Long-running Codex work has more than one budget. Token cost matters, especially now that OpenAI explains Codex usage through plan access and token-based credit accounting. But tokens are not the whole story. You also need: - time budget - disk budget - process budget - dependency budget - review budget - CI budget - human attention budget We already covered this in [Codex CLI resource budgets](/blog/codex-cli-resource-budgets). A local agent can burn disk, write logs, spawn processes, or create review debt even when the model output looks useful. Codex-Maxxing without resource budgets is just hidden spend. ## A Practical Long-Running Codex Template For a real engineering task, I would frame it like this: ```text Goal: Ship one scoped improvement to [module] without touching unrelated files. Allowed files: - app/example/* - components/example/* - tests/example/* Required evidence: - explain the current behavior - make the smallest useful change - run pnpm typecheck - run the focused test - show git diff --stat - list any skipped checks Stop conditions: - stop after three failed attempts at the same test - stop if lockfiles change unexpectedly - stop before destructive git commands - stop if another agent changed the same files Subagents: - only use subagents for read-only research or independent verification ``` That is not glamorous. It is the shape that keeps a long-running agent from losing the plot. It also pairs well with [Codex `/goal` vs Claude Managed Outcomes](/blog/codex-goal-vs-claude-managed-outcomes-practical-differences). Goals keep execution moving. Outcome criteria keep the final result honest. ## The Practical Take Codex-Maxxing should mean using more of Codex's workflow surface, not surrendering judgment to a longer session. Use the app, CLI, cloud tasks, `AGENTS.md`, subagents, and goals when they fit. But wrap them in: - scoped worktrees - clear instructions - stop conditions - resource budgets - verification gates - short commits - production evidence The winning long-running Codex workflow is not the one that runs the longest. It is the one that leaves the cleanest trail. ## FAQ ### What is Codex-Maxxing? Codex-Maxxing is an informal term for using more of Codex's agent workflow surface, such as app tasks, CLI work, cloud background runs, `AGENTS.md`, subagents, and long-running goals. ### Are Codex subagents cheaper than one agent? Not necessarily. OpenAI's docs say subagents can consume more tokens than comparable single-agent runs, so they should be used when parallel work is genuinely separable. ### What makes long-running Codex workflows safe? They need scoped worktrees, clear instructions, stop conditions, test gates, resource budgets, review checkpoints, and a final evidence trail. ### Should Codex run unattended? Only for bounded work where the allowed files, commands, budget, and stop conditions are explicit. High-risk work still needs human review before merge or deploy. ## Sources - [OpenAI Codex docs](https://developers.openai.com/codex) - [OpenAI Codex CLI docs](https://developers.openai.com/codex/cli) - [OpenAI Codex cloud docs](https://developers.openai.com/codex/cloud) - [OpenAI AGENTS.md guide](https://developers.openai.com/codex/guides/agents-md) - [OpenAI Codex subagents docs](https://developers.openai.com/codex/subagents) - [OpenAI Codex best practices](https://developers.openai.com/codex/learn/best-practices) - [OpenAI: Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/) - [OpenAI Codex rate card](https://help.openai.com/en/articles/20001106-codex-rate-card)

Cybersecurity Skills for AI Agents Are Becoming Runtime Infrastructure

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

GitHub Trending surfaced [`mukul975/Anthropic-Cybersecurity-Skills`](https://github.com/mukul975/Anthropic-Cybersecurity-Skills) today, and the pitch is unusually specific: 817 cybersecurity skills across 29 domains, mapped to frameworks like MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF, and the Fight Fraud Framework. That matters more than a normal prompt-library launch. The interesting part is not that someone wrote a lot of security prompts. The interesting part is that security work is being packaged as agent-callable procedures with domain labels, framework mappings, and enough structure that a coding agent can treat them as reusable job instructions. **Last updated:** June 23, 2026 Google Trends did not surface a cleaner AI security query today. The only strong AI/developer signal in the US Trends feed was `cbrs stock`, which is why the first post today covered [Cerebras and public-market inference demand](/blog/cerebras-cbrs-stock-ai-inference-market-signal). This one comes from GitHub Trending, but it fits the same editorial rule: trend data is useful only when it points to a developer workflow that deserves a practical take. ## Why This Is Not Just a Prompt Dump Most security prompt collections fail because they are too vague. They say things like "act as a penetration tester" or "review this code for vulnerabilities," then leave the model to invent the actual process. The better pattern is closer to the [agent skills production checklist](/blog/agent-skills-production-checklist): put the task boundary, inputs, expected outputs, references, and escalation rules in a reusable file that the agent can load at the right moment. That is why a cybersecurity skills library is worth watching. Security teams already work through playbooks: | Security workflow | Agent-skill version | |---|---| | triage an alert | gather evidence, classify severity, preserve uncertainty | | threat model a feature | map assets, entry points, trust boundaries, and mitigations | | review a dependency | inspect package provenance, maintainer activity, install scripts, and transitive risk | | handle a suspicious auth event | collect logs, compare baseline behavior, propose containment steps | | prepare a compliance note | map evidence to a named control framework without inventing proof | That shape is much closer to software than to chat. We have already seen this pattern in development workflows. [Skills beat prompts for coding agents](/blog/why-skills-beat-prompts-for-coding-agents-2026) because they carry context that should not be rediscovered every run. [Skills are becoming an agent operating system](/blog/skills-are-the-new-agent-operating-system) because they turn repeated work into loadable procedures. Security is one of the strongest tests of that idea. ## The Runtime Layer Agents Were Missing Coding agents are getting better at writing and editing code. The failure mode is now less often "can the agent produce a diff?" and more often "does the agent know the operational boundary of the task?" Security work needs that boundary. An agent reviewing an OAuth integration should know the difference between: - validating redirect URI handling - checking token storage - confirming refresh-token rotation - looking for confused-deputy paths - deciding when the evidence is not enough - refusing to turn a defensive review into an exploit walkthrough That is not a single clever prompt. It is runtime context. A cybersecurity skill can define: - the allowed scope - the sources of truth - the required artifacts - the risk taxonomy - the non-goals - the exact handoff format for a human reviewer This is also where a security skill differs from a normal coding skill. A React refactor skill can be wrong and create a messy PR. A security skill can be wrong and create a false sense of coverage. ## The False Confidence Problem The contrarian take is simple: a large cybersecurity skills library is useful only if teams treat it as scaffolding, not authority. Framework mappings sound reassuring. MITRE ATT&CK, NIST CSF, D3FEND, MITRE ATLAS, and NIST AI RMF are real reference points. But a mapped skill is not proof that the agent completed a control, found every issue, or understood the environment. The same warning applies to dependency work. In [npm supply-chain trust boundaries for AI agents](/blog/npm-supply-chain-trust-boundaries-ai-agents), the core problem was not that agents can install packages. It was that agents can normalize risky actions unless the workflow forces provenance checks and approval boundaries. Cybersecurity skills need the same discipline: - source provenance for every skill - version history for framework mappings - test fixtures with known vulnerable and known clean examples - a clear line between defensive analysis and dual-use escalation - logs that show what the agent inspected - human review for consequential findings - refusal paths for requests that cross the allowed scope Without that, a skills library can become security theater. It gives the agent better vocabulary, but not necessarily better judgment. ## Where This Fits in a Real Agent Stack The practical setup is not "give Claude Code 817 security skills and let it roam." The useful setup is narrower: 1. Put security skills behind explicit triggers. 2. Scope each skill to a reviewable task. 3. Require evidence snippets and file references in the output. 4. Keep exploit-generation and production-change permissions separate. 5. Log which skill ran, which inputs it saw, and what it concluded. 6. Add regression fixtures for recurring security checks. That connects directly to [approval fatigue as an agent security bug](/blog/approval-fatigue-agent-security-bug). If every security action becomes another vague approval prompt, humans start clicking through. Skills should reduce ambiguity, not increase the number of approvals. It also connects to [prompt injection in agent apps](/blog/prompt-injection-agent-apps-practical-version). A skill is another input channel. If an agent can load a skill file, follow web content, read repo docs, and execute commands, then the runtime needs a hierarchy: which instructions win, which content is untrusted, and which operations require confirmation. ## What Developers Should Copy Even if you do not use this particular repository, the pattern is worth copying. For your own agent workflows, write security skills for jobs you already repeat: - "review a new GitHub Action before merging" - "inspect a package before adding it" - "threat model a new webhook endpoint" - "review an MCP server before connecting it" - "check auth changes before deploy" - "summarize suspicious production logs without leaking secrets" Keep each skill boring. A good security skill is not a persona. It is a checklist with judgment points, source requirements, and a clean output contract. The strongest agent workflows are not the ones with the most autonomy. They are the ones where autonomy is surrounded by receipts. ## FAQ ### What are AI agent cybersecurity skills? AI agent cybersecurity skills are reusable instruction files or playbooks that guide an agent through a security task such as threat modeling, dependency review, incident triage, or framework mapping. ### Are cybersecurity skills safer than prompts? They can be safer because they are more structured, but only if they include scope boundaries, evidence requirements, tests, and human review paths. A skill without provenance can still create false confidence. ### Should developers use a large public security skills library? Use it as inspiration and scaffolding. Before using it in real work, review the source, pin versions, test the outputs on known examples, and keep high-risk actions behind human approval. ### How do security skills relate to Claude Code? Claude Code and similar coding agents can load project instructions and task-specific procedures. Security skills make those procedures more explicit, but teams still need permission controls, logs, and review gates. ## Sources - [`mukul975/Anthropic-Cybersecurity-Skills` on GitHub](https://github.com/mukul975/Anthropic-Cybersecurity-Skills) - [GitHub Trending daily repositories](https://github.com/trending?since=daily) - [MITRE ATT&CK](https://attack.mitre.org/) - [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) - [MITRE ATLAS](https://atlas.mitre.org/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [Google Trends daily RSS, United States](https://trends.google.com/trending/rss?geo=US)

Envoy AI Gateway 1.0 Makes LLM Routing an Infrastructure Decision

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

[Envoy AI Gateway 1.0](https://aigateway.envoyproxy.io/blog/v1.0-release-announcement/) is a useful signal because it moves LLM routing out of the "clever app code" bucket and into the infrastructure bucket. The launch is not just another model proxy. It is a gateway built on the Envoy ecosystem, aimed at teams that already think in Kubernetes, Gateway API, traffic policy, rate limits, observability, and centralized controls. That changes the buying question. You are no longer only asking: which model should this request hit? You are asking: where should model traffic be governed? **Last updated:** June 23, 2026 That distinction matters more after a week where developers were debating [AI affordability](/blog/ai-affordability-crisis-agent-costs), provider outages, model routing, and runaway agent loops. Once model calls are production traffic, they need the same boring controls as the rest of production traffic: limits, retries, logs, ownership, and policy. Envoy AI Gateway is one answer to that. ## What Envoy AI Gateway 1.0 Is Envoy AI Gateway is an open-source gateway for managing access to generative AI services, built on [Envoy Gateway](https://gateway.envoyproxy.io/) and the broader [Envoy Proxy](https://www.envoyproxy.io/) ecosystem. The 1.0 release announcement positions it as stable and production-ready. The project documentation and GitHub repo emphasize a few core capabilities: - unified access to generative AI services - routing across model backends - rate limiting and traffic management - observability hooks - Kubernetes-native deployment patterns - policy-driven configuration through gateway resources That shape is important. A developer can already call OpenAI, Anthropic, Gemini, Mistral, or an open model host directly from application code. A small team can put [LiteLLM](/blog/llm-router-comparison-2026) in front of those providers and get a lot of value quickly. Envoy AI Gateway is for a different moment: when model calls are no longer a library choice inside one service, but shared production infrastructure across teams. ## The Decision: SDK Call, App Router, or Gateway Most teams should not start with the heaviest control plane. Use the simplest layer that matches the risk. | Stage | Best Starting Point | Why | |---|---|---| | prototype | direct SDK call | fastest, least operational overhead | | one app with a few models | app-level router or LiteLLM | easy fallback and spend tracking | | multiple apps or teams | shared gateway | one policy and observability layer | | regulated or platform team | Envoy-style infrastructure gateway | traffic governance, Kubernetes fit, central ownership | The failure mode is adding a gateway before you have gateway problems. A proxy hop adds configuration, deployment, dashboards, and another component to debug. The opposite failure mode is worse at scale: every product team hardcodes provider keys, retry behavior, timeout defaults, model names, logging formats, and spend controls differently. That is how model traffic becomes invisible. The gateway earns its keep when consistency is worth more than local simplicity. ## Why Envoy Is an Interesting Foundation Envoy is already trusted in production networking. That does not automatically make Envoy AI Gateway the right choice, but it explains the appeal. LLM traffic has unusual behavior: - requests can be long-running - output streams can last many seconds - rate limits vary by model and provider - context windows create failure modes normal APIs do not have - fallback can change cost and quality - prompts may contain sensitive internal data - observability needs token, latency, model, user, and route metadata Those are infrastructure concerns. If your platform team already operates Envoy, Kubernetes, Gateway API, and service-level policy, an Envoy-native AI gateway gives them a familiar place to manage the new traffic class. This is the same pattern behind [Vercel's AI Gateway](/blog/vercel-agentic-infrastructure-stack), but with a different audience. Vercel's gateway is a managed product for teams building on Vercel. Envoy AI Gateway is an open infrastructure component for teams that want to own the control plane. Neither is universally better. They sit at different points on the build-versus-buy curve. ## Where Envoy AI Gateway Fits Envoy AI Gateway is most compelling when at least three of these are true: - more than one application calls model providers - you need central rate limits or budgets - you need consistent request logs across teams - you need provider fallback as policy, not application code - your platform team already runs Kubernetes and Envoy-family tooling - direct provider keys are spreading across too many services - compliance needs a clear path for data handling and audit trails - you need to test model migration without editing every app If only one app calls one provider, direct SDK calls are probably fine. If one team wants quick multi-provider abstraction, [LiteLLM, Portkey, or OpenRouter](/blog/llm-router-comparison-2026) may be faster. If the company wants LLM traffic governed like API traffic, Envoy AI Gateway becomes much more interesting. ## The Tradeoffs ### Gateways Add Operational Surface A gateway can reduce application complexity while increasing platform complexity. Someone now owns: - gateway deployment - route configuration - provider credentials - rate limit policies - error handling - telemetry exports - upgrades - incident response That ownership is healthy if a platform team exists. It is overkill if the "platform team" is one developer trying to ship a feature. ### Fallbacks Are Not Free A fallback from one provider to another is not like failing over between two identical database replicas. Different models produce different output. They have different tool-call behavior, safety systems, latency, context windows, and prices. A gateway can make fallback mechanically easy, but it cannot guarantee semantic equivalence. Test fallback paths before relying on them. ### Central Policy Can Hide Product Needs The whole point of a gateway is central control. The risk is central control becoming too blunt. A support summarizer, code review assistant, document extraction agent, and customer-facing chat product should not necessarily share the same timeout, fallback, logging, and model policy. A good gateway setup still needs per-route intent, not one global rule for every model call. This is why the [model routing recipes](/blog/model-routing-recipes-cut-ai-spend) pattern starts with task classification. Infrastructure cannot replace product understanding. ## The Practical Rollout If you are evaluating Envoy AI Gateway, do not migrate every model call first. Start with one boring, high-volume path. 1. Pick a route where output quality is easy to inspect. 2. Mirror traffic or run a small percentage through the gateway. 3. Log provider, model, latency, tokens, error type, and user or service. 4. Add one rate limit and one fallback. 5. Compare cost per successful request against the direct path. 6. Only then move a second workload. That rollout keeps the conversation grounded. The question is not "is a gateway architecturally elegant?" The question is whether it lowers cost, improves reliability, tightens governance, or makes incidents easier to debug. For agent workloads, add one more field: accepted outcome. A gateway can tell you a request succeeded. It cannot tell you the patch was good. Pair gateway telemetry with the workflow accounting from the [AI affordability cost post](/blog/ai-affordability-crisis-agent-costs). ## My Take Envoy AI Gateway 1.0 is important because LLM traffic is becoming ordinary production traffic. That sounds boring, but boring is the point. The agent era does not only need better models. It needs infrastructure that can answer ordinary operational questions: - who called which model? - what did it cost? - why did it fail? - what fallback ran? - which app owns this route? - can we cap this before it surprises finance? - can we change policy without editing five services? For a small app, direct SDK calls still win. For a growing AI platform, a gateway becomes the place where model choice, reliability, observability, and cost control meet. Envoy's bet is that many teams will want that place to look like the rest of their infrastructure. That is a reasonable bet. ## FAQ ### What is Envoy AI Gateway? Envoy AI Gateway is an open-source gateway for managing access to generative AI services. It is built on the Envoy ecosystem and is designed for routing, rate limiting, observability, and policy around LLM traffic. ### Is Envoy AI Gateway the same as LiteLLM? No. LiteLLM is a popular Python SDK and proxy for calling many model providers through a unified interface. Envoy AI Gateway is more infrastructure-oriented, built around Envoy Gateway and Kubernetes-native traffic policy. ### When should a team use an AI gateway? Use a gateway when multiple applications or teams need shared model routing, rate limits, spend controls, provider fallback, and centralized logs. For a single prototype, direct SDK calls are usually simpler. ### Does a gateway reduce AI costs automatically? No. A gateway gives you the control point for routing, rate limits, caching, and spend visibility. Cost drops only if you configure useful policies and measure outcomes, retries, cache hit rate, and review cost. ### What is the main risk of putting a gateway in front of LLM apps? The main risk is adding operational complexity before you need it. A gateway also makes fallback easy at the network layer, but teams still need to test whether fallback models produce acceptable answers. ## Sources Fetched June 23, 2026. - [Envoy AI Gateway 1.0 release announcement](https://aigateway.envoyproxy.io/blog/v1.0-release-announcement/) - [Envoy AI Gateway documentation](https://aigateway.envoyproxy.io/) - [Envoy AI Gateway GitHub repo](https://github.com/envoyproxy/ai-gateway) - [Envoy Proxy](https://www.envoyproxy.io/) - [Hacker News item for Envoy AI Gateway 1.0](https://news.ycombinator.com/item?id=48652415)

F3 Is a Reminder That File Formats Are Becoming Runtime Contracts

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

[F3](https://github.com/future-file-format/F3) is on the Hacker News front page today, and the thread is exactly what you would expect when someone proposes a "file format for the future." Some people see a serious research idea: a next-generation columnar format with embedded WebAssembly decoders so files can stay readable even when native library support is missing. Other people see a prototype with a thin README, no obvious migration path, and a familiar problem: Parquet is everywhere, so why would anyone leave? Both reactions are fair. The useful takeaway is not "replace Parquet." It is this: **File formats are becoming runtime contracts.** **Last updated:** June 23, 2026 That matters for data systems, analytics tools, and AI agents that increasingly consume files they did not create. ## What F3 Is F3 stands for Future-proof File Format. The project describes itself as an open-source data file format designed around efficiency, interoperability, and extensibility. The README is explicit that it is a research prototype and should not be used in production. The paper's core claim is that modern columnar formats like Parquet and ORC were designed for an older hardware and workload environment. They can evolve, but every evolution runs into compatibility problems. Engines need native decoders. Tooling drifts. New encodings can be hard to deploy everywhere. F3's answer is to make files self-describing in a stronger way: - the file carries data - the file carries metadata - the file can carry WebAssembly binaries that decode the data - native decoders can still exist - Wasm acts as a compatibility fallback when native support is unavailable That is the interesting bit. The file does not just describe its shape. It can bring a portable decoder with it. ## Why Developers Were Skeptical The HN thread had a clear theme: the repo does not make the case quickly enough. People asked: - What is this a file format for? - What Parquet shortcomings does it fix? - Why would anyone leave Parquet or ORC? - Where are the examples? - Is embedded executable code inside data a security risk? - Is this a research artifact or a project with adoption momentum? Those are not nitpicks. File formats live or die on boring adoption constraints. A better format that nobody can read is worse than a flawed format that every warehouse, query engine, notebook, ETL tool, and object-store scanner already supports. Parquet has massive present-tense gravity. Spark reads it. DuckDB reads it. BigQuery reads it. Snowflake reads it. Pandas, Polars, Arrow, Trino, Athena, and a pile of internal systems read it. That support is the product. So the practical stance is simple: F3 is not a migration recommendation today. It is a design signal. ## The Wasm Decoder Idea Is the Signal The embedded Wasm decoder idea points at a bigger shift. Historically, a data file mostly carried bytes and schema. The runtime carried the intelligence: - the engine knew the format - the library knew the encoding - the application knew how to interpret fields - the user hoped versions lined up F3 pushes some of that contract into the artifact itself. If a file uses a new encoding, it can include a decoder implementation. The consumer still needs a sandbox and execution policy, but the file is no longer helpless without a matching native library. That is a powerful direction for long-lived data. Think about files that need to survive: - scientific archives - compliance exports - ML training corpora - public datasets - government records - company data lakes - analytics snapshots The longer a file has to live, the more painful decoder drift becomes. This is also where the security question becomes real. A file that carries executable logic must be treated differently from a file that only carries inert bytes. Wasm is designed for sandboxed execution, but sandboxing is a policy surface, not a magic word. Readers need resource limits, capability controls, deterministic execution expectations, and a clear answer for "what is this decoder allowed to do?" That makes F3 less like a simple format and more like a runtime boundary. ## Why This Matters for AI Agents AI agents make the file-format problem sharper. Agents are constantly asked to inspect unfamiliar artifacts: - CSV exports - Parquet datasets - JSON logs - notebooks - model cards - trace files - benchmark outputs - internal reports The agent often sees the surface text but not the deep contract. It can summarize a README, but can it verify the encoding? Can it recover column semantics? Can it explain a weird compression scheme? Can it cite which decoder produced the data? As agents move closer to data engineering work, the file is not just input. It is an operational boundary. We made a similar argument in [agent workspaces need filesystem contracts](/blog/agent-workspaces-need-filesystem-contracts): agents become safer when their workspaces expose clear, inspectable contracts. F3 applies that mindset lower in the stack. The file itself becomes more self-explaining and self-contained. That does not mean agents should blindly execute Wasm from random files. It means agent runtimes need a stronger notion of file trust: - inert metadata is safe to inspect - embedded code requires sandbox policy - generated decoders need provenance - derived values need receipts - file-level capabilities should be explicit This is the same trust-boundary lesson that shows up in MCP servers, plugin systems, and tool-call sandboxes. Once data can carry behavior, the reader needs policy. ## Where F3 Could Matter F3's best near-term use case is not replacing every Parquet file in a data lake. The better fit is research and specialized systems where format evolution is the bottleneck: - testing new encodings without waiting for every engine to ship native support - distributing datasets with portable decoding behavior - experimenting with hardware-aware layouts - preserving long-lived scientific or compliance datasets - building engines that can safely execute file-provided decoders That is still meaningful. Research prototypes do not need to win the whole market to move the conversation. The important question is whether the idea can be packaged into something boring enough for real operators: - clear examples - obvious Parquet comparisons - reproducible benchmarks - sandbox defaults - a small reader API - compatibility with Arrow-like workflows - a migration story for existing data lakes HN was right to ask for the "why" upfront. A future file format has to win trust before it can win adoption. ## My Take F3 is interesting because it treats file compatibility as a runtime problem, not just a schema problem. That is a big idea. It is also nowhere near enough to overcome Parquet by itself. The data world is not short on clever formats. It is short on formats that every tool reads, every team trusts, and every operator can debug at 2 a.m. So the practical takeaway is not "move to F3." The takeaway is to watch the contract shift: - files will carry richer metadata - formats will need safer extension points - portable execution will become more common - readers will need policy, not just parsers - agents will need to reason about file provenance and decoder trust That is bigger than F3. It is the direction data infrastructure has to go if files are going to outlive the tools that created them. ## FAQ ### What is F3? F3 is a research prototype for a future-proof columnar data file format. It is designed around efficiency, interoperability, and extensibility, including embedded WebAssembly decoders. ### Is F3 ready for production? No. The F3 README says the project is a research prototype and should not be used in production. ### Is F3 trying to replace Parquet? The paper compares F3 against existing columnar formats such as Parquet and ORC, but developers should not treat it as a drop-in replacement today. Parquet's ecosystem support remains the practical default. ### Why embed Wasm decoders in a file? The idea is that a file can remain readable even when a native decoder for its encoding is not available. Wasm provides a portable fallback, assuming the reader has a safe sandbox and execution policy. ### Is executable code inside a data file risky? Yes, it creates a trust boundary. Wasm can reduce risk through sandboxing, but readers still need resource limits, capability controls, provenance checks, and a policy for whether embedded decoders can run at all. ## Sources Fetched June 23, 2026. - [F3 GitHub repository](https://github.com/future-file-format/F3) - [F3 paper DOI](https://doi.org/10.1145/3749163) - [Hacker News: F3](https://news.ycombinator.com/item?id=48647799) - [Apache Parquet documentation](https://parquet.apache.org/docs/) - [WebAssembly security model](https://webassembly.org/docs/security/)

GitHub Copilot CLI, BYOK, and AI Credits: The New Cost-Control Stack

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

GitHub's latest Copilot updates are easy to read as separate feature announcements: a new CLI interface, bring-your-own-key support, AI credit reporting, Claude as an agent provider in JetBrains, and more code review polish. Read together, they say something bigger. Copilot is becoming a control plane for coding agents. The product is no longer only about where suggestions appear. It is about where agent work runs, which model provider pays for it, which teams can use it, how spend gets measured, and how generated work moves into review. That is the useful lens for engineering teams. The terminal agent matters, but the cost and governance layer matters more. **Last updated:** June 23, 2026 ## What GitHub Shipped This Week GitHub's June 19-23 Copilot changelog tells a coherent story: - [Copilot CLI's new terminal interface is generally available](https://github.blog/changelog/2026-06-23-copilot-cli-new-terminal-interface-is-generally-available). - [The GitHub Copilot app now supports BYOK](https://github.blog/changelog/2026-06-23-github-copilot-app-support-for-byok) for OpenAI, Azure OpenAI, Microsoft Foundry, Anthropic, LM Studio, Ollama, and OpenAI-compatible endpoints. - [AI credits consumed per user now appear in the Copilot usage metrics API](https://github.blog/changelog/2026-06-19-ai-credits-consumed-per-user-now-in-the-copilot-usage-metrics-api). - [Claude as an agent provider is in public preview for JetBrains IDEs](https://github.blog/changelog/2026-06-22-new-features-and-claude-as-agent-provider-preview-in-jetbrains-ides), alongside model picker improvements and a per-turn AI credits indicator. - [Copilot code review now uses repository-level AGENTS.md files](https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements), which brings project instructions into review feedback. That bundle is more important than any one item. It turns Copilot into a governed routing layer across terminal work, app sessions, IDE agents, review workflows, and billing data. For the broader platform context, start with [GitHub Copilot Coding Agent and CLI](/blog/github-copilot-coding-agent-cli-2026). This piece is narrower: how the June updates change cost control. ## The Take: Copilot Is Becoming the Enterprise Agent Ledger The old Copilot buying question was simple: do developers want autocomplete and chat inside the editor? The new question is different: can your team delegate work to agents without losing track of cost, model choice, policy, and review load? GitHub is positioning Copilot as the ledger for that system. The CLI gives developers a local terminal surface. BYOK gives teams a route for their own model providers. AI credit reporting gives administrators a way to see per-user consumption. Claude provider support shows Copilot is willing to host outside agent runtimes in specific surfaces. AGENTS.md support connects repository instructions to review behavior. That is not just "more Copilot." It is a response to the same pressure behind [Claude Code vs Codex App](/blog/claude-code-vs-codex-app-2026): teams are standardizing around agent workflows, but they still need a place to manage who can spend, which providers are allowed, and what evidence must accompany generated code. ## Why BYOK Matters, Even If You Do Not Use It Immediately BYOK is not magic cost savings. Your OpenAI, Anthropic, Azure, or local model bill still exists. Local Ollama or LM Studio providers still need hardware and operational discipline. The important part is optionality. When one vendor bundles models, billing, and workflow into a single plan, the organization has fewer levers. BYOK separates the agent surface from the model provider. That gives teams room to: - Route sensitive work to approved enterprise endpoints. - Test a local model without changing the whole developer workflow. - Compare bundled Copilot credits against direct provider billing. - Keep the same app or CLI surface while switching model providers. - Reserve premium bundled credits for the tasks where they actually pay off. That is why BYOK belongs next to [AI coding tools pricing](/blog/ai-coding-tools-pricing-june-2026), not only next to model feature lists. Once coding agents run multi-step tasks, the model bill becomes a workflow design question. ## AI Credits Turn Usage Into a Management Problem The June 19 metrics update is the piece administrators should care about. Per-user AI credit consumption in the Copilot usage metrics API means usage-based billing can be inspected at the same level where teams already manage seats and adoption. That matters because agent work is uneven. One developer may use Copilot for small completions. Another may run long terminal sessions, cloud-agent tasks, review requests, and expensive model turns. A flat active-user count does not explain that difference. The new reporting does not automatically prove value. It only creates the possibility of better value measurement. Teams still need to connect spend to outcomes: | Metric | Why it matters | |---|---| | AI credits consumed per user | Shows where agent usage is concentrating | | Agent sessions started | Separates passive chat from delegated work | | Pull requests opened | Shows whether sessions produce reviewable artifacts | | Pull requests merged | Connects usage to accepted changes | | Review cycles | Shows whether the agent creates review debt | | Failed checks | Finds workflows that spend credits without producing usable output | This is the same bottleneck we covered in [AI Coding Agents Move the Bottleneck to Review Queues](/blog/ai-coding-agents-review-queues). The scarce resource is no longer just code generation. It is the system that turns generated code into trusted merges. ## The CLI Changes the Adoption Path Copilot CLI's new terminal interface going generally available is the adoption lever. Developers who already live in the terminal do not want every agent task forced through an editor sidebar. GitHub's [Copilot CLI page](https://github.com/features/copilot/cli) positions the product as a GitHub-native terminal agent that works with issues and pull requests, can run parallelized subagents, and is included across Copilot Free, Pro, Pro+, Max, Business, and Enterprise subscriptions. It also says each interaction draws on the plan's AI Credits allowance. That last sentence is the product strategy. Copilot CLI is not only a local agent. It is a local agent tied into GitHub identity, plan access, organization policy, and usage accounting. That is where GitHub has leverage against terminal-native competitors. [Claude Code](/blog/what-is-claude-code) and Codex can be stronger choices for developers who want direct local control, deeper workspace orchestration, or a model-specific workflow. Copilot CLI is strongest when the organization wants the terminal path to remain inside the same GitHub governance surface as issues, pull requests, code review, and billing. ## The Opposing Take: This Does Not Solve Agent Cost by Itself The skeptical read is fair: more controls do not automatically make agentic coding cheap or effective. BYOK can move spend from one invoice to another. AI credit metrics can create dashboards that show usage without showing value. CLI access can encourage more delegation before teams have review capacity. Provider choice can become a menu of expensive options rather than a routing strategy. That is why the right conclusion is not "standardize on Copilot for everything." The better conclusion is this: If your team already runs on GitHub and wants centralized policy, Copilot's June updates make it harder to ignore. If your team optimizes for raw agent capability, local control, or independent model choice, you should still compare Copilot CLI against Claude Code, Codex, Cursor, and other tools task by task. The winning setup may be mixed: - Copilot for GitHub-native issue, PR, and review workflows. - Claude Code or Codex for long local investigations and parallel implementation. - BYOK for provider experiments and sensitive routing. - Usage metrics for budget guardrails. - Review queues and receipts for merge discipline. That mix is messier than a single vendor story. It is also closer to how serious teams actually adopt developer tooling. ## What Teams Should Do Now Do not start by enabling every agent surface. Start by writing a cost-control policy that answers five questions: 1. Which Copilot surfaces are approved: CLI, app, IDE, cloud agent, code review? 2. Which model providers are allowed through BYOK? 3. Which repos can use agentic workflows? 4. What evidence must every agent-authored PR include? 5. Which usage metrics decide whether the rollout expands or shrinks? Then run a small pilot. Pick one repo, one team, and one class of task. Compare Copilot CLI with your existing Claude Code, Codex, or Cursor workflow. Track credits, PR quality, review cycles, and merge rate. That is how you avoid the common failure mode: lots of agent activity, no clear answer on whether it helped. ## FAQ ### What is GitHub Copilot BYOK? GitHub Copilot BYOK means bring your own key. In the Copilot app, GitHub says users can add their own model providers, including OpenAI, Azure OpenAI, Microsoft Foundry, Anthropic, LM Studio, Ollama, and OpenAI-compatible endpoints, then use those providers in agent sessions. ### Does BYOK make Copilot cheaper? Not automatically. BYOK changes where model spend is routed. It can reduce cost if your team already has better provider pricing, local inference capacity, or approved enterprise endpoints. It can also increase cost if developers route heavy agent sessions to expensive models without guardrails. ### What changed in Copilot usage metrics? GitHub added per-user AI credit consumption to the Copilot usage metrics API on June 19, 2026. That gives administrators a clearer way to see who is consuming AI credits, which is essential now that Copilot agent workflows can consume more than simple autocomplete. ### Is Copilot CLI now generally available? Yes. GitHub announced on June 23, 2026 that the new Copilot CLI terminal interface is generally available. GitHub positions it as a terminal-native agent tied into Copilot subscriptions and AI Credits. ### Should teams choose Copilot CLI instead of Claude Code or Codex? Choose based on workflow, not brand. Copilot CLI is compelling when GitHub governance, issues, pull requests, and usage accounting matter. Claude Code and Codex may still be better for teams that prioritize direct local control, model-specific workflows, or independent multi-agent orchestration. ## Sources - [GitHub Changelog: Copilot CLI new terminal interface is generally available](https://github.blog/changelog/2026-06-23-copilot-cli-new-terminal-interface-is-generally-available) - [GitHub Changelog: GitHub Copilot app support for BYOK](https://github.blog/changelog/2026-06-23-github-copilot-app-support-for-byok) - [GitHub Changelog: AI credits consumed per user now in the Copilot usage metrics API](https://github.blog/changelog/2026-06-19-ai-credits-consumed-per-user-now-in-the-copilot-usage-metrics-api) - [GitHub Changelog: New features and Claude as agent provider preview in JetBrains IDEs](https://github.blog/changelog/2026-06-22-new-features-and-claude-as-agent-provider-preview-in-jetbrains-ides) - [GitHub Changelog: Copilot code review AGENTS.md support and UI improvements](https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements) - [GitHub Copilot CLI product page](https://github.com/features/copilot/cli) - [GitHub Docs: Copilot usage metrics](https://docs.github.com/en/copilot/reference/copilot-usage-metrics/copilot-usage-metrics)

GLM-5.2 Local Deployment: Running Z.ai's 744B Model on Consumer Hardware

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

GLM-5.2 is Z.ai's flagship open-weights model - 744 billion parameters total, 40 billion active (it is a mixture-of-experts architecture), and a 1 million token context window. Running it unquantized requires around 800GB of memory. Running it at all seemed out of reach for anyone without datacenter hardware. Then Unsloth shipped dynamic quantization support for GLM-5.2, and the math changed. ## What Unsloth's Documentation Actually Says The [official Unsloth docs](https://unsloth.ai/docs/models/glm-5.2) lay out the hardware requirements for each quantization level: | Quantization | Memory Needed | Disk Space | |--------------|---------------|------------| | 1-bit (UD-IQ1_S) | 223 GB | ~90 GB | | 2-bit (UD-IQ2_M) | 245 GB | ~239 GB | | 3-bit | 290-360 GB | ~300 GB | | 4-bit | 372-475 GB | ~400 GB | | 8-bit | 810 GB | ~800 GB | The 2-bit quantization can fit on a 256GB unified memory Mac. It can also run on a single 24GB GPU (like an RTX 3090) with 256GB of system RAM using MoE offloading - the active parameters stay in VRAM while inactive experts get paged from system memory. Unsloth's "dynamic" quantization approach preserves critical layers at higher precision while compressing less important ones. According to their testing, 4-bit dynamic is "essentially lossless" on standard benchmarks. ## What HN Is Actually Saying The [discussion thread](https://news.ycombinator.com/item?id=48636377) has 188 comments and the conversation centers on whether these quantization claims hold up in practice. **The skeptics:** One commenter warns that "lossless" claims are "often made based on KL-divergence over some arbitrary corpus, not performance in the real world or benchmarks." Their experience: "I need to go a couple steps past whatever quantizations are good enough in the KL-divergence testing to get good performance in real tasks with long context. So when Q4 is claimed to be lossless I end up with Q5 or Q6." **The practical coders:** Another commenter reports that for coding work specifically, "ideal range is at least Q8." The 2-bit and 4-bit variants work for general use but degrade on tasks requiring precise reasoning over long contexts. **The hardware math crowd:** Several comments work through generation speed calculations. The formula is straightforward: token generation requires reading all active weights per token. With 40B active parameters at 4-bit quantization, that is 20GB of weight reads per token. Divide by your memory bandwidth to get tokens per second. One commenter breaks it down: "With 100GB/s [memory bandwidth] you get 5 tokens per second." The RTX 3090 has roughly 936GB/s bandwidth, so you would expect around 40-50 tok/s if the weights fit entirely in VRAM - which they do not, hence the offloading penalty. **The cost reality check:** An earlier thread claimed running GLM-5.2 locally would cost "$500k in hardware." Commenters here pushed back hard. The actual math: 6x RTX 6000 PRO Blackwell cards (576GB VRAM total) plus supporting hardware runs around $80-90k for 120 tok/s at NVFP4 precision. You could get 40 tok/s decode for under $50k. A single GB300 workstation at the official $85k price point can also handle it, likely exceeding 120 tok/s. **The Mac crowd:** M-series Macs with 256GB unified memory can run the 2-bit variant directly. One commenter estimates "M5 Ultra will ship before end of year" with 256GB max, though RAM shortages may limit availability. ## Running It Yourself Unsloth provides a one-liner install: ```bash curl -fsSL https://unsloth.ai/install.sh | sh ``` Then start the local inference server: ```bash unsloth studio -H 0.0.0.0 -p 8888 ``` The studio interface handles model download, GPU detection, and automatic offloading configuration. Models are available on [Hugging Face](https://huggingface.co/unsloth/GLM-5.2-GGUF). For direct llama.cpp usage, you can reduce memory further with KV cache quantization. Using q4_0 cache quantization extends context capacity by roughly 3.5x at minimal quality cost for most tasks. ## Performance Numbers From the Unsloth docs, GLM-5.2's benchmark numbers: | Benchmark | Score | |-----------|-------| | AIME 2026 | 99.2% | | SWE-bench Pro | 62.1% | | MCP-Atlas | 76.8% | The model includes three thinking modes: non-thinking, High, and Max. You control these via `enable_thinking` and `reasoning_effort` parameters. For coding tasks, Unsloth recommends temperature 1.0 and top-p 0.95 (or 1.0 for SWE-Bench Pro specifically). The recommended settings for local deployment: - Temperature: 1.0 - Top-p: 0.95 - Max context: 1,048,576 tokens (if your hardware can handle it) ## When Local Makes Sense The HN discussion surfaced a practical question: when does running GLM-5.2 locally beat using the API? **Local wins when:** - You need the full 1M context window without per-token costs - You are running high-volume batch jobs where API costs compound - You want to avoid network latency for interactive coding sessions - You need to keep code entirely offline for compliance reasons **API wins when:** - You do not have 256GB+ of memory available - You need consistent high-throughput (120+ tok/s) without hardware investment - You want to swap models without downloading hundreds of gigabytes - You are comparing GLM-5.2 against other models in routing setups For the cost math on API access, see our [GLM-5.2 free and cheap access guide](/blog/glm-5-2-free-and-cheap-access-2026). For comparing GLM-5.2 against other coding models, see the [coding model showdown](/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown). ## The Bigger Picture The fact that a 744B-parameter frontier model can run on consumer hardware - even with quality tradeoffs - marks a shift. A year ago, "local LLM" meant 7B or 13B models that could not compete with API offerings. Now the gap is narrowing. Several commenters noted they are running Qwen3.6 27B (the non-MoE version) locally on 24GB cards for daily coding work. One described it as "smart enough to do debugging, refactoring, and implementing 'clean' specs" - not flagship-level, but genuinely useful. GLM-5.2 at 2-bit is slower and potentially lower quality than the API version, but it is the same model. That is new territory for local inference. ## Frequently Asked Questions ### Can I run GLM-5.2 on a Mac? Yes, if you have 256GB unified memory. The 2-bit quantization (UD-IQ2_M) fits in 245GB. M3 Ultra with 256GB works. M4 Max with 128GB does not - you would need to wait for M5 Ultra or go the Linux/Windows route with a GPU + system RAM setup. ### What GPU do I need? A 24GB GPU (RTX 3090, RTX 4090, A6000) works with MoE offloading if you also have 256GB of system RAM. The active 40B parameters fit in VRAM; inactive experts page from system memory. Expect 5-15 tok/s depending on your memory bandwidth. ### Is 2-bit quantization actually usable? For general use and simple coding tasks, yes. For precise reasoning over long contexts, commenters report needing Q5 or Q6 to match full-precision behavior. The "lossless" claims are based on benchmark metrics that may not reflect your specific workload. ### How does this compare to running smaller models locally? Smaller models (Qwen3 27B, Llama 3 70B) run faster and require less hardware, but have capability ceilings. GLM-5.2 at 2-bit is slower but has access to the same 744B parameter knowledge - the quantization compresses the weights, not the capability surface. Whether that tradeoff makes sense depends on your tasks. ## Sources - [Unsloth GLM-5.2 documentation](https://unsloth.ai/docs/models/glm-5.2) - [GLM-5.2 GGUF models on Hugging Face](https://huggingface.co/unsloth/GLM-5.2-GGUF) - [Hacker News discussion](https://news.ycombinator.com/item?id=48636377) - [Z.ai GLM-5 blog post](https://z.ai/blog/glm-5)

LangChain Rubrics Make Agent Evals Part of the Runtime

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

LangChain's new [rubrics for Deep Agents](https://www.langchain.com/blog/introducing-rubrics-for-deepagents) are worth paying attention to because they move evals closer to the agent loop itself. The headline feature is simple: give an agent a rubric, let it evaluate its own work against that rubric, and use the result to correct the output before handing it back. That sounds like a small product feature. It is bigger than that. It is a sign that agent evals are becoming runtime infrastructure, not only offline dashboards. **Last updated:** June 23, 2026 The useful version is not "the model grades itself and declares victory." That would be too easy to game and too easy to trust blindly. The useful version is a disciplined loop: 1. define task-specific criteria 2. run the agent 3. evaluate against the criteria 4. revise or stop 5. store the trace 6. sample against human review That is where rubrics become practical. ## What LangChain Shipped LangChain's post describes rubrics as a way to build agents that evaluate and correct their work. The feature lands in the Deep Agents context, which LangChain positions as a batteries-included agent harness for complex, multi-step tasks. The surrounding product story matters: - [Deep Agents](https://www.langchain.com/deep-agents) handles complex multi-step agent work. - [LangSmith evaluation](https://www.langchain.com/langsmith/evaluation) gives teams an eval and observability surface. - The [LangSmith evaluation docs](https://docs.langchain.com/langsmith/evaluation) cover datasets, experiments, evaluators, and review workflows. - Rubrics bring part of that quality-control thinking into the agent's working loop. The direction is clear: agents should not only produce output. They should check whether the output meets a declared standard. That is the right instinct. ## Why Rubrics Matter for Agents Traditional evals happen after the fact. You run a batch of examples. You score them. You compare model A to model B. You decide whether to ship a prompt, model, retrieval setting, or tool change. That is still necessary. We covered that in [agent evals need baseline receipts](/blog/agent-evals-need-baseline-receipts): a useful eval keeps the baseline, candidate, task fixture, trajectory, cost, and human review note together. But agent work has another problem. The failure often happens during the run. A coding agent may: - forget a constraint from the task - produce a diff without tests - fix the happy path while missing the migration path - use the wrong abstraction - return a polished answer without receipts - spend too much work on a low-value branch If the agent only learns that after the run is complete, the system has already wasted time and tokens. A runtime rubric gives the agent a chance to catch obvious quality failures before the user becomes the evaluator. That is not a replacement for offline evals. It is a new layer. ## The Good Rubric Test A rubric is useful only if it changes behavior. Bad rubric: ```text Make the answer good, correct, helpful, and safe. ``` Good rubric: ```text Before final response, verify: 1. Every factual claim cites a source URL or local file. 2. The answer separates verified facts from inference. 3. The recommendation names one case where it should not be used. 4. Any code change includes the exact command used to verify it. 5. If a source was unreachable, the answer says so. ``` The difference is not style. The second rubric is inspectable. A human reviewer can tell whether the agent followed it. For developer workflows, rubrics should be: | Property | Why It Matters | |---|---| | specific | vague criteria become vibes | | versioned | teams need to know which rubric judged which run | | task-scoped | a support rubric is not a coding rubric | | evidence-linked | the judge should inspect the trace, not only the final answer | | cheap enough | a rubric that doubles cost everywhere will get bypassed | | sampled by humans | model-judged quality needs calibration | That last point is the one teams skip. Self-correction is useful. Self-certification is dangerous. ## Where This Fits in the Agent Stack Rubrics sit between the agent harness and the eval platform. At the harness level, a rubric can decide whether to loop: ```text draft -> rubric check -> revise -> rubric check -> final ``` At the eval-platform level, rubrics become the reusable criteria that compare candidate systems against baselines. At the product level, rubrics become part of the user promise: - this support answer must cite policy - this code patch must include tests - this data-agent answer must name the source table - this research summary must separate claims from uncertainty - this migration plan must include rollback This is why rubrics belong next to [long-running agent harnesses](/blog/long-running-agents-need-harnesses). A loop without a rubric tends to optimize for "keep going." A loop with a rubric can optimize for "stop when the output satisfies these criteria, or stop when it clearly does not." That is a much safer loop. ## The Counterargument The obvious critique is that a model grading a model can launder mistakes. That critique is correct. A rubric check can fail in several ways: - the evaluator shares the same blind spot as the generator - the rubric is too vague - the final answer looks compliant but hides weak evidence - the agent learns to satisfy the rubric wording instead of the user need - the rubric check adds cost without improving acceptance rate This is the same reliability cliff we discussed in [the agent reliability cliff](/blog/the-agent-reliability-cliff). Adding another agent step does not automatically improve the system. If that step has weak criteria or no external signal, it can create confidence without quality. The fix is not to avoid rubrics. The fix is to bind them to evidence. Use executable checks where possible: - schema validation - unit tests - source-link checks - required fields - diff-size limits - lint and typecheck - policy allowlists - replayable traces Then use LLM rubric judges for the parts that are genuinely semantic: reasoning quality, user fit, clarity, missing caveats, and tradeoff coverage. ## The Operational Pattern If you are adding rubrics to an agent this week, start small. | Step | Action | |---|---| | 1 | Pick one workflow with repeat failures | | 2 | Write a five-point rubric that a human reviewer already uses mentally | | 3 | Save the rubric with a version ID | | 4 | Run the agent with and without the rubric on the same task set | | 5 | Compare accepted outcomes, cost, latency, and review time | | 6 | Sample failures manually and adjust the rubric | Do not measure only the rubric score. Measure whether the output is accepted faster. That connects directly to the [AI affordability cost model](/blog/ai-affordability-crisis-agent-costs). A rubric that adds tokens but reduces retries and review time can be a net win. A rubric that adds tokens and mostly agrees with bad output is just ceremony. ## My Take LangChain rubrics are interesting because they make a quiet but important claim: agent quality criteria should be explicit and reusable. That is the right direction. The mature agent stack will not be "prompt plus tools." It will be: - prompt - tools - memory - harness - trace - rubric - baseline - human calibration Rubrics are not magic. They are a way to turn taste, policy, and task-specific quality into something an agent can inspect before it stops. For teams building real agent workflows, that matters. The agent that can revise against a clear rubric is more useful than the agent that simply runs longer. The team that versions and samples those rubrics is safer than the team that trusts a self-grade. Use rubrics to make the loop better. Do not use them to avoid owning the loop. ## FAQ ### What are LangChain rubrics for Deep Agents? LangChain rubrics let developers define criteria that Deep Agents can use to evaluate and improve their own outputs. They bring quality checks closer to the agent runtime instead of leaving all evaluation for offline dashboards. ### Are rubric-graded agents safe to trust automatically? No. Rubrics help agents catch failures, but model-judged quality should still be sampled against human review and executable checks. A rubric is a control, not proof of correctness. ### What makes a good agent rubric? A good rubric is specific, task-scoped, versioned, evidence-linked, and reviewable. It should name observable criteria rather than vague goals like "be helpful" or "write good code." ### How do rubrics relate to LangSmith evals? LangSmith evals help teams compare agent behavior across datasets, experiments, and baselines. Rubrics can become the reusable criteria inside those evals and, in Deep Agents, part of the runtime correction loop. ### Do rubrics make agents cheaper? Not automatically. Rubrics add evaluation work. They save money only when they reduce retries, review time, rejected outputs, or failed agent loops enough to offset the extra tokens and latency. ## Sources Fetched June 23, 2026. - [LangChain: Introducing Rubrics for Deep Agents](https://www.langchain.com/blog/introducing-rubrics-for-deepagents) - [LangSmith evaluation platform](https://www.langchain.com/langsmith/evaluation) - [LangSmith evaluation docs](https://docs.langchain.com/langsmith/evaluation) - [LangChain Deep Agents](https://www.langchain.com/deep-agents) - [Deep Agents GitHub repo](https://github.com/langchain-ai/deepagents)

Local Coding Agent Workspaces Are the New IDE Surface

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

The IDE is no longer the only place where coding agents want to live. The interesting product layer in AI coding right now is the local workspace around the agent: a desktop shell, a terminal runtime, a repo worktree, a memory folder, a diff gate, a rollback path, and a set of local tools that keep the model inside a developer-controlled loop. That is the useful read on projects like [`y`](https://github.com/y-times-y/y), a new local desktop coding-agent app that wraps Claude Code, Codex, and other CLI-native agents instead of trying to replace them. The repo has low public traction right now, so this is not an adoption victory lap. It is a design signal. The signal is that the next coding-agent interface may not be "chat inside an IDE." It may be a local agent workbench that sits beside the IDE and coordinates the actual work. **Last updated:** June 23, 2026 ## Why This Is Timely Several current signals point in the same direction. The [`y` repo](https://github.com/y-times-y/y) describes itself as a local, chat-first desktop app for Claude Code, OpenAI Codex, and other CLI-native agents. Its more interesting claim is malleability: the app can change its own UI through a protected modify surface, keep the change if it renders safely, or roll it back if it does not. [`Recall`](https://github.com/raiyanyahya/recall) takes a different slice of the same problem. It is a fully local project-memory layer for Claude Code, aimed at reducing repeated project explanation without sending memory to a hosted service. GitHub is moving the terminal side forward too. The [Copilot CLI docs](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/overview) position Copilot as usable directly from the command line, and GitHub's [Agent Tasks REST API changelog](https://github.blog/changelog/2026-06-04-agent-tasks-rest-api-now-available-for-copilot-pro-pro-and-max/) makes background cloud-agent work programmable. Those are different products, but the pattern is shared: the interface is moving from one prompt box to a workspace that can manage context, state, tools, and review. ## The Take: The Workspace Is Becoming the Product The model still matters. But for daily development, the model is no longer enough to define the product. A serious coding-agent workspace has to answer questions the model cannot answer by itself: | Workspace question | Why it matters | |---|---| | Which repo state is the agent allowed to see? | Prevents stale or unrelated context from steering the run | | Where does memory live? | Keeps durable project knowledge inspectable and deletable | | How are diffs reviewed? | Makes agent work concrete before merge | | Can a bad turn roll back? | Lets developers experiment without destroying state | | Which CLI agent owns the task? | Separates the workspace from the model/provider | | What runs locally vs remotely? | Controls privacy, latency, and credentials | | What receipt survives the session? | Makes the work reviewable after the chat scroll disappears | That is why this topic belongs next to [agent workspaces needing filesystem contracts](/blog/agent-workspaces-need-filesystem-contracts) and [terminal agents becoming portable runtime surfaces](/blog/terminal-agents-portable-runtime-surface). The interface is not just where a user types. It is where permissions, memory, diffs, and rollback become visible. ## Desktop Shells Are Different From IDE Plugins IDE plugins are convenient because they live where code is edited. Local agent workspaces are different because they can sit around multiple tools. A workspace can call Claude Code, Codex, Copilot CLI, shell commands, git, local indexes, and review tools without being locked to one editor surface. That matters for the way developers actually use agents: - one agent explores the repo; - another writes a patch; - a terminal command verifies it; - a browser checks the UI; - a memory file explains project rules; - a worktree isolates the diff; - a review step decides whether to keep the result. An IDE can host some of that. A local workspace can coordinate all of it. This is the difference between an AI autocomplete feature and an agent bench. ## Memory Is Useful Only If It Is Governed Recall is interesting because it keeps memory local. That is the right instinct for many developer workflows. But local memory is not automatically good memory. A workspace memory layer needs rules: - what gets saved; - who can edit it; - which projects can read it; - whether old facts expire; - how the agent cites memory back to the user; - how a human deletes a bad assumption. Otherwise memory becomes a quieter version of prompt drift. The agent remembers something, nobody knows where it came from, and future sessions inherit the mistake. That is why [agent memory needs a context ledger](/blog/agent-memory-context-ledger). A local workspace should make memory visible enough to audit, not just durable enough to accumulate. ## Self-Modifying UI Needs Diff Gates The most provocative part of `y` is not that it wraps Claude Code and Codex. It is the self-modifying interface idea. If an agent can modify the app that supervises the agent, the product needs a strong boundary between "suggest a change" and "ship the changed control surface." The safe shape looks like this: 1. The agent proposes a UI or workflow change. 2. The workspace renders it in an isolated preview. 3. A diff shows exactly what changed. 4. The user accepts, rejects, or rolls back. 5. The old state remains recoverable. That turns malleability into a controlled loop instead of a gimmick. The same principle applies to project code. Coding agents are most useful when they can move quickly inside a worktree, but only if the workspace can show what changed and restore the previous state. For the lower-level runtime boundary, read [agent sandbox architecture](/blog/agent-sandbox-architecture-guide). ## Cloud Agents Push The Same Pattern From The Other Side GitHub's [Agent Tasks REST API](https://github.blog/changelog/2026-06-04-agent-tasks-rest-api-now-available-for-copilot-pro-pro-and-max/) is not a local desktop feature, but it reinforces the same trend. Agent work is becoming programmable. The API lets Copilot users start and track cloud-agent tasks. GitHub's examples include fanning out migrations across repositories, setting up new repos from an internal portal, and preparing releases. That is workspace thinking, even when the execution environment is remote. The local version and the cloud version are converging on the same product shape: - start work from a structured task; - run in an isolated environment; - track progress; - validate changes; - open or update a pull request; - leave a receipt. The open question is where your team wants the boundary. Some work belongs in a local repo workbench. Some work belongs in a managed cloud agent. Some work needs both. That is also why [Claude Code vs Codex App](/blog/claude-code-vs-codex-app-2026) should be read as an execution-surface decision, not only a model comparison. ## The Opposing Take: This May Be Too Much Interface The skeptical view is strong. Developers already have IDEs, terminals, browsers, GitHub, shells, and task managers. A new local workspace can become one more window that promises to organize work while adding another layer of state. The risk is real: - desktop wrappers can hide what the underlying CLI is doing; - local memory can preserve stale assumptions; - self-modifying UI can become novelty instead of workflow; - multi-agent benches can multiply unfinished branches; - rollback can feel safe while external systems changed outside the repo. That is why I would not evaluate local agent workspaces by screenshots. Evaluate them by receipts. Can the workspace show which agent ran, which files it saw, which memory it used, which commands it executed, which diff it produced, and how to roll it back? If not, the interface is probably ahead of the control plane. ## What To Look For In A Local Coding Agent Workspace If this category keeps growing, use a boring checklist. 1. **Worktree isolation.** The agent should not casually edit your main branch. 2. **Visible memory.** Durable context should be inspectable, scoped, and removable. 3. **Diff-first review.** The workspace should make file changes obvious before merge. 4. **Rollback.** A failed turn should be recoverable without manual archaeology. 5. **Provider separation.** The workspace should not confuse the shell around the agent with the model itself. 6. **Local credential boundaries.** Secrets should not be sprayed into every tool call. 7. **Source receipts.** The agent should say where its project facts came from. 8. **Headless hooks.** Useful workspaces should support scripts, CI, or recurring jobs, not only chat. 9. **Cost visibility.** Local does not mean free if it burns premium agent sessions or paid API calls. 10. **Exit path.** You should be able to leave with normal git history, files, and docs. The goal is not to replace the IDE. The goal is to make agent work supervisable across the tools developers already use. ## The Practical Bottom Line Local coding-agent workspaces are becoming a real product layer. They are not the model. They are not just an IDE plugin. They are the bench where Claude Code, Codex, Copilot CLI, local memory, repo state, diffs, shells, browsers, and review loops meet. That category is still early. Some projects will be experiments. Some will be wrappers. Some will disappear. But the direction is worth watching because it matches how serious agent work actually happens: not in a single chat turn, but in a controlled local environment with memory, tools, rollback, and receipts. ## FAQ ### What is a local coding agent workspace? A local coding agent workspace is a developer-controlled environment around one or more coding agents. It can combine a desktop app, terminal agent, repo worktree, local memory, shell commands, diffs, rollback, and review receipts. ### Is this different from an IDE plugin? Yes. An IDE plugin lives inside one editor. A local agent workspace can coordinate multiple surfaces: terminal agents, git worktrees, local memory, browser checks, shell commands, and cloud-agent tasks. ### Why not just use Claude Code or Codex directly? Direct CLI use is often enough. A workspace becomes useful when you need better memory visibility, multi-agent coordination, rollback, diff review, or a local shell around multiple agent providers. ### Are self-modifying agent apps safe? They can be useful only if changes are isolated, previewed, diffed, approved, and reversible. Without those gates, self-modifying UI creates a control-plane risk. ### What should teams measure before adopting a workspace? Measure whether it reduces repeated setup, improves review quality, leaves better receipts, lowers context mistakes, makes rollback easier, and keeps provider/model switching understandable. ## Sources - [GitHub: y-times-y/y](https://github.com/y-times-y/y) - local malleable coding-agent workspace, verified June 23, 2026 - [GitHub: Recall](https://github.com/raiyanyahya/recall) - fully local project memory for Claude Code, verified June 23, 2026 - [GitHub Docs: Using GitHub Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/overview) - command-line Copilot workflow, verified June 23, 2026 - [GitHub Copilot CLI product page](https://github.com/features/copilot/cli) - terminal agent positioning, verified June 23, 2026 - [GitHub Changelog: Agent tasks REST API](https://github.blog/changelog/2026-06-04-agent-tasks-rest-api-now-available-for-copilot-pro-pro-and-max/) - programmable cloud-agent tasks, verified June 23, 2026 - [GitHub: OpenAI Codex](https://github.com/openai/codex) - CLI-native coding agent repository, verified June 23, 2026

In Praise of Memcached: Why Simpler Caching Might Be Better

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

A [blog post praising memcached](https://jchri.st/blog/in-praise-of-memcached/) hit the Hacker News front page with 242 points and 100 comments, reigniting the eternal Redis vs memcached debate. The core argument: Redis's flexibility is a trap that leads to operational pain. The post generated some predictable "this is AI-written" accusations (it was not) but also surfaced a genuinely interesting architectural discussion about what caches should and should not do. **Last updated:** June 23, 2026 ## The Core Argument The author's thesis is simple: Redis gets deployed as a "cache" but inevitably becomes treated as a persistent database by developers who do not understand its volatility assumptions. When Redis goes down (upgrades, hardware failures), the impact is severe because it is now storing critical data. Memcached, by contrast, is architecturally constrained in ways that prevent this drift: **1. Graceful degradation is built in.** Client libraries ignore connection exceptions. A simple `get` returns the default value (or none) if the server is down. Your application does not crash - it just runs slower while the cache refills. **2. No built-in clustering forces client-side distribution.** Memcached has no cluster mode. Clients handle distribution through key hashing. When nodes fail, clients automatically remove them from rotation and later attempt reconnection. This sounds like a limitation, but it means no cluster state to manage, no consensus protocols to debug at 3am. **3. No persistence means true statelessness.** Memcached does not persist to disk. You can deploy it as a stateless workload without worrying about data loss because there is no data to lose. It is genuinely ephemeral. That constraint is the whole architectural point. A cache should be easy to delete. If deleting it requires a migration plan, an incident bridge, and a data-recovery checklist, you probably built a database-shaped system and named it cache. For AI infrastructure teams, the same distinction shows up in [agent spend guardrails](/blog/ai-infrastructure-agents-need-spend-guardrails) and [agent-native backends](/blog/agent-native-backends-insforge): the operational contract matters more than the label on the component. ## What HN Is Saying The [discussion](https://news.ycombinator.com/item?id=48638886) produced some excellent technical depth. **The Redis defenders** pushed back on the framing: > "Redis is brought into a stack because (most importantly!) it's fast and (almost as importantly!) because it's simple. I have very very rarely experienced Redis being treated as a persistent store." One commenter with 15 years of Redis experience noted they had "never had to manage clustering or had any issues with it" even for games with 30- or 60-tick state updates across multiple regions. **The operations perspective** was more sympathetic to the original post: > "I've had teammates that treated Redis as an actual durable production database and operated that way. It's not unreasonable for a new dev to assume this unless told otherwise." Another commenter laid out the practical rules for using Redis safely as a cache: 1. Wrap your client library so it is impossible to store anything without an expiry date 2. Either turn off persistence, or use a separate database for the cache 3. Set up a reasonable maxmemory value with an appropriate eviction policy 4. Resist the urge to use complex data structures - if you try to update a single field on an expired hash, you will end up with an incomplete object **The performance discussion** was illuminating. A commenter from Notion reported: > "memcached is about a bazillion times faster than redis at doing the simple KV cache job. it's got threads. at notion we use redis for a lot of things, but actual caching we leave to memcached" The numbers from another commenter comparing local cache (APCu), memcached, and MariaDB: ``` APCu avg=0.000318ms Memcached avg=0.039714ms MariaDB avg=0.019541ms ``` The interesting observation: MariaDB was actually faster than memcached in this test because the network hop dominates. "Don't even start a socket if possible." **The architecture purists** argued for separation of concerns: > "Redis is a great piece of tech but it suffers from trying to be good at two different jobs (persistent data structures, volatile cache) which should not be combined. Indeed in Redis itself they don't combine well - persistence is globally on or off." **The pragmatists** countered that most teams will end up needing Redis anyway: > "I'd almost guarantee a large enough team using memcache will find a way to need Redis. And then we're maintaining 2 cache technologies." ## The Real Question: When Do You Need Either? Several commenters asked the practical question: when do you actually need to move from database-level caching to a dedicated cache layer? One commenter summarized it well: > "The most common first thing to cache is getting the current user, because this ends up being a very hot path for most stateless systems. Because you need to get the current user for almost every request, it's quite easy for getting the current user to be 50% of database load." Another offered a decision framework: - Do you need to recover from a reboot with queues intact? You need persistence - Is it a distributed system? You need coordination - Do you have complex multi-step workflows? You might need data structures - If you answered no to all of these: `import Queue from queue` might be enough The performance hierarchy from another commenter: ``` Servers are so insanely large (up to 400 Cores) now that you can get meaningful scale on a single box. If you can colocate the app and cache on the same server, you can get many orders of magnitude better performance, regardless of which cache it is. ``` The boring decision rule: | Need | Better default | |---|---| | throwaway request cache | memcached | | session-adjacent but rebuildable values | memcached or Redis with strict TTLs | | rate limiting, counters, atomic structures | Redis or Valkey | | queues and coordination | Redis/Valkey only if you accept stateful operations | | durable system of record | neither | This is why caching decisions belong in architecture review, not only performance tuning. The wrong cache can quietly become the data model. ## The Slab Allocation Footgun Several commenters noted that memcached is not actually as simple as it appears: > "The memcache slab pools are a leaky abstraction that you may end up having to manage operationally, and it's another way Redis is simpler." Memcached pre-allocates memory in fixed-size "slabs" for items of different sizes. If you store a lot of 50-byte items and then start storing 500-byte items, you can run into slab starvation where the cache evicts data even though there is technically free memory. Most developers "just reach for redis at that point." ## Non-Caching Uses of Redis The thread surfaced several common patterns where Redis's extra features matter: - Rate limiting via leaky bucket algorithm - Feature flags and stats tracking - Websocket pub/sub - Background job queues (Sidekiq, Celery) - Distributed task coordination - Atomic operations across threads (INCRBY) - Lua scripts for complex atomic operations For these use cases, memcached is not a viable alternative - you need the data structures. The argument is really about whether you should use the same Redis instance for caching and for these stateful operations. That separation also matters for AI apps. A retrieval cache, prompt-cache ledger, job queue, and user-facing database should not silently collapse into one Redis deployment because it was convenient during prototyping. If you are building with serverless databases, queues, and vector stores, compare the same boundary discipline in [Convex vs Supabase for AI apps](/blog/convex-vs-supabase-ai-apps) and [prompt caching for Claude API production](/blog/prompt-caching-claude-api-production-guide). ## The Verdict The discussion converged on a nuanced position: **For pure caching:** Memcached's constraints are features. The lack of persistence, the dumb client-side clustering, the graceful degradation - these all push you toward correct cache usage patterns. **For stateful operations:** Redis (or Valkey, now that licensing is weird) is the right tool. But configure it as a persistent store with appropriate backup strategies, not as a "cache that happens to persist." **For most teams:** Pick one and be disciplined. The real problem is not the technology - it is developers who do not understand the difference between a cache and a database. Memcached makes it harder to confuse the two. Redis makes it easier to do powerful things and also easier to shoot yourself in the foot. As one commenter put it: "if you're letting a junior dev who refuses to read product documentation the responsibility of architecting production systems, then your problem isn't Redis." For model-serving infrastructure, do not confuse this with transformer KV cache. That is a different cache with a different failure mode. The [KV caching transformer inference guide](/blog/kv-caching-transformer-inference-guide) covers that layer. ## FAQ ### Is memcached better than Redis for caching? Memcached can be better for pure ephemeral caching because it is intentionally simple, stateless, and easy to discard. Redis is better when you need richer data structures, atomic operations, pub/sub, queues, or coordination. ### When should I choose Redis instead of memcached? Choose Redis when the workload needs stateful operations: counters, rate limits, locks, pub/sub, background jobs, sorted sets, hashes, streams, or Lua-backed atomic workflows. Use it deliberately as stateful infrastructure, not as a vague cache. ### Is Redis safe as a cache? Yes, if you configure it like a cache: strict TTLs, maxmemory, eviction policy, separate instances for cache and durable-ish state, and operational playbooks for cold starts. Problems start when teams treat Redis as a durable database without designing for that. ### What is the biggest memcached downside? Memcached is simple, but not magic. Slab allocation, item sizing, network latency, and client-side distribution still require operational understanding. Its constraints help prevent database drift, but they do not remove capacity planning. ### Should AI apps use Redis or memcached? Use the same rule as any backend. For throwaway response, retrieval, or computed-value caches, memcached is often enough. For queues, rate limits, coordination, or structured state, Redis or Valkey may fit. Durable user data belongs in a real database. ## Sources - [In Praise of Memcached - Original Post](https://jchri.st/blog/in-praise-of-memcached/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48638886) - [Memcached Internals: Slab Allocation](https://vectree.io/c/memcached-internals-slab-allocation-lru-eviction-and-consistent-hashing) (referenced in thread) - [Memcached documentation](https://docs.memcached.org/) - [Redis data types documentation](https://redis.io/docs/latest/develop/data-types/) - [Redis eviction policy documentation](https://redis.io/docs/latest/operate/rs/databases/memory-performance/eviction-policy/)

Mistral OCR 4 and Unlimited OCR Make Document Parsing an Agent Runtime Choice

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Two OCR stories hit Hacker News today for the same reason. [Mistral released OCR 4](https://mistral.ai/news/ocr-4/), a dedicated document extraction model with bounding boxes, block classification, inline confidence scores, markdown output, 170-language support, API pricing, and a self-hosted container path. [Baidu's Unlimited OCR](https://github.com/baidu/Unlimited-OCR) also surfaced, positioning itself around one-shot long-horizon parsing for multi-page documents and open model deployment. The interesting part is not that OCR exists. OCR has existed forever. The interesting part is that document parsing is becoming a runtime decision for agents. **Last updated:** June 23, 2026 If you are building a RAG system, support triage agent, invoice workflow, legal review tool, financial document monitor, research archive, or internal search product, the first step is often not retrieval. It is ingestion. Can the system turn messy documents into trustworthy structured evidence before an LLM reasons over them? That used to be a boring preprocessing question. Now it is an architecture question. ## What Mistral OCR 4 Changes Mistral's launch post frames OCR 4 as a small, focused document-understanding model. The feature list is aimed directly at production ingestion: - extracted text - markdown-structured output - bounding boxes - block types - inline confidence scores - support for 170 languages across 10 language groups - a single-container self-hosting option - API, Batch API, and Document AI product paths The pricing is also explicit: Mistral lists OCR 4 API pricing at $4 per 1,000 pages, Batch API at $2 per 1,000 pages, and Document AI at $5 per 1,000 pages. That matters because OCR pipelines are volume problems. A demo with five PDFs does not tell you much. A production archive with five million pages forces different questions: - What is the cost per thousand pages? - Can the model preserve layout? - Can you route low-risk batches through cheaper async processing? - Can you keep sensitive documents in your own environment? - Can downstream agents inspect confidence and geometry instead of trusting plain text? Mistral is answering those questions with product packaging, not just a model card. The [OCR 4 model card](https://docs.mistral.ai/models/model-cards/ocr-4-0) and [document-processing docs](https://docs.mistral.ai/studio-api/document-processing/basic_ocr) make the implementation shape clearer than the launch post alone. The API can return structured OCR output with blocks, confidence signals, and document-aware formatting rather than only a flat text transcript. That matters because downstream agents need more than words. They need evidence handles. This is the same pressure we covered in [Claude Vision API at production scale](/blog/claude-vision-api-production-guide): vision extraction looks simple until volume, cost, edge cases, and validation show up. A dedicated OCR model gives teams a more focused tool than calling a general-purpose multimodal model for every page. ## What Unlimited OCR Represents Baidu's Unlimited OCR is a different kind of signal. It is open, developer-facing, and shaped around long documents. The GitHub repo describes "one-shot long-horizon parsing" and includes inference paths through Hugging Face Transformers and SGLang. The README shows multi-page parsing, PDF-to-image conversion, a 32,768 token max length setting, and OpenAI-compatible streaming requests through an SGLang server. That is not the same product category as Mistral's hosted OCR endpoint. It is closer to a research/runtime surface for teams that want to run the model themselves, tune serving, and own the deployment. The HN thread around Unlimited OCR had the right skepticism. Some commenters asked whether OCR was already solved. Others pushed back that long-run OCR is still constrained by cost, throughput, latency, memory pressure, language coverage, and degraded documents. That is exactly the point. "OCR" is too broad a word now. Reading a clean screenshot is one problem. Parsing a 200-page scanned contract with tables, stamps, footnotes, rotated pages, handwriting, and mixed languages is another. Feeding that output into an agent that makes decisions or updates records is a third problem. Unlimited OCR is interesting because it attacks the long-context, multi-page version of the problem directly. The caution is maturity. Unlimited OCR is a fresh research/runtime project, not a settled production platform. Treat it as a promising model to benchmark on your own documents, not as a drop-in replacement for validation, serving operations, or human review. ## The New OCR Decision Tree For developers, the useful question is not "which OCR model won HN today?" The useful question is: what kind of document workload do you have? | Workload | Better Starting Point | |---|---| | High-volume document ingestion with product SLAs | Dedicated OCR API or Document AI product | | Sensitive archives with data residency constraints | Self-hosted OCR model or private container | | Long PDFs and multi-page parsing experiments | Open model runtime like Unlimited OCR | | One-off screenshots, UI images, charts, and mixed visual reasoning | General vision model | | Business extraction with validation, workflows, and deployment UI | Higher-level document platform | This is where existing tools still matter. A platform like [Unstract](/blog/unstract-ai-document-parser) is not obsolete because a new OCR model ships. It sits higher in the stack: workflow design, field extraction, validation, deployment, and integration. The OCR layer feeds it. Likewise, a multimodal model like Claude still makes sense when the input is not just a document. Screenshots, charts, interface audits, and visual reasoning belong in the broader vision bucket. The new pattern is compositional: 1. Use OCR to turn pages into structured evidence. 2. Preserve coordinates, block types, tables, and confidence where possible. 3. Store the parsed result alongside page images and source metadata. 4. Retrieve evidence by section, page, table, or entity. 5. Let an agent reason only over cited, inspectable chunks. That is the bridge from OCR to agents. ## Why This Matters for RAG RAG quality is capped by ingestion quality. If the parser loses table structure, the retriever cannot recover it. If it merges headers with body text, the answer layer inherits confusion. If it strips page numbers and coordinates, the UI cannot show receipts. If it overconfidently reads a bad scan, the agent can produce a polished answer grounded in bad evidence. This is why Mistral's bounding boxes, block classification, and confidence scores are more important than the word "OCR." They give downstream systems more handles. A good document RAG pipeline should be able to say: - this answer came from page 17 - this table cell came from row 4, column 2 - this field had low confidence - this page was rotated or degraded - this paragraph was a figure caption, not body text That is not just extraction. It is evidence design. The [SNEWPAPERS post](/blog/agentic-search-snewspapers) made the same point from a historical archive angle. Search got better only after layout processing, OCR, classification, indexing, and query assistance were treated as separate parts of the system. The agent was the layer on top, not a replacement for the ingest pipeline. ## The Tradeoff Developers Should Watch There is a temptation to collapse document AI into one giant model call. Upload the PDF. Ask for JSON. Done. That works for prototypes and small internal tools. It gets fragile at scale. The better production shape is usually a pipeline: - page rendering - orientation and image cleanup - OCR or document model extraction - table and layout preservation - chunking with page references - schema extraction - validation - human review for low-confidence fields - searchable storage Dedicated OCR models fit cleanly into that pipeline. Open models fit when you need cost control, deployment control, or research flexibility. General multimodal models fit when reasoning across visual context matters more than raw throughput. The wrong move is pretending one layer solves the whole system. ## The Benchmark Caveat OCR benchmarks are useful, but they can hide the exact failures that break document agents. A model can look strong on clean scans and still fail on: - low-resolution faxes; - rotated tables; - handwriting; - stamps and signatures; - multi-column legal exhibits; - mixed-language forms; - scanned pages with handwritten corrections; - PDFs where the embedded text layer disagrees with the image. That is why the real evaluation set should come from your own archive. Keep page images, parsed markdown, bounding boxes, confidence values, extracted fields, and human corrections together. Then measure the pipeline by downstream task quality: did the agent cite the right page, preserve the table, flag low confidence, and avoid inventing missing fields? This also connects to [RAG with Claude](/blog/rag-with-claude-add-context-without-retraining). Retrieval does not repair bad ingestion. It only finds whatever your OCR pipeline preserved. For the baseline architecture, the older [What is RAG?](/blog/what-is-rag) guide is still the right starting point: retrieval quality depends on source preparation before the model ever sees a prompt. ## My Take Mistral OCR 4 and Unlimited OCR are important because they make document ingestion feel like an active model category again. For the last year, a lot of teams treated OCR as either solved infrastructure or a prompt you send to a frontier vision model. That is too simple. The real decision now includes layout fidelity, confidence metadata, serving mode, cost per page, self-hosting, long-document behavior, and how much evidence your agent can show back to a user. If you are building document agents, start evaluating OCR like a runtime: - hosted or self-hosted - sync or batch - short page or long document - text-only or layout-aware - black-box answer or inspectable evidence - cheap enough for reprocessing - reliable enough for human review queues The winners will not be the systems with the fanciest demo on one clean PDF. The winners will be the systems that preserve enough structure for agents to reason, cite, and recover from uncertainty. That is the practical shift. ## FAQ ### What is Mistral OCR 4? Mistral OCR 4 is Mistral's document extraction model released on June 23, 2026. It returns extracted text, markdown structure, bounding boxes, block types, and confidence scores, with API, batch, Document AI, and self-hosted deployment paths. ### What is Unlimited OCR? Unlimited OCR is Baidu's open OCR project for one-shot long-horizon parsing. The repo includes model links, Transformers inference, SGLang serving instructions, and multi-page PDF parsing examples. ### Is OCR solved already? Clean text extraction is mature. Production document parsing is not solved in the general case. Long PDFs, degraded scans, tables, mixed languages, handwriting, layout preservation, latency, cost, and evidence tracing still create hard engineering choices. ### Should I use a dedicated OCR model or a general vision model? Use a dedicated OCR or document model for high-volume page ingestion, layout-aware parsing, and cost-controlled pipelines. Use a general vision model when the task requires broader visual reasoning across screenshots, charts, diagrams, or mixed image content. ### Why does OCR matter for AI agents? Agents need reliable evidence. If document ingestion loses layout, confidence, tables, or page references, the agent has weaker grounding. Better OCR gives agents cleaner source material and better receipts. ## Sources Fetched June 23, 2026. - [Mistral: Introducing OCR 4](https://mistral.ai/news/ocr-4/) - [Mistral OCR 4 model card](https://docs.mistral.ai/models/model-cards/ocr-4-0) - [Mistral OCR processor docs](https://docs.mistral.ai/studio-api/document-processing/basic_ocr) - [Baidu Unlimited OCR GitHub repo](https://github.com/baidu/Unlimited-OCR) - [Unlimited OCR paper on arXiv](https://arxiv.org/abs/2606.23050) - [Hacker News: Mistral OCR 4](https://news.ycombinator.com/item?id=48645152) - [Hacker News: Unlimited OCR](https://news.ycombinator.com/item?id=48643426)

Do AI Coding Agents Need Their Own Version Control?

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Oak is a provocative little signal from the current agent-infrastructure wave: maybe AI coding agents do not just need better prompts, better context windows, or better model routing. Maybe they need version control that was designed for them from day one. That is a high bar. Git is not a casual dependency. It is the shared substrate for GitHub, CI, code review, release automation, local development, open source, and most team workflows. Replacing it is the kind of idea that deserves skepticism by default. But the reason Oak is interesting is not that every team should move off Git tomorrow. The reason it is interesting is that it names a real pressure point: coding agents are using Git workflows that were designed around humans carefully editing one checkout at a time. **Last updated:** June 23, 2026 If you have run multiple agents against the same repo, you already know the shape of the problem. Agents want isolated sessions. They want cheap branches. They want to inspect history without burning context. They want to checkpoint speculative work. They want to throw away bad attempts. They want to merge only the part that survived review. Git can do all of that, but the default workflow is not optimized for autonomous workers. It is optimized for developers who understand the repo, read diffs, resolve conflicts, and know when not to touch a file. That difference matters. ## What Oak Is Betting On Oak describes itself as version control rebuilt for AI coding agents. The pitch is that agents should work in lightweight virtual workspaces, avoid full repo clones where possible, and spend fewer tokens explaining file history and branch state to the model. The most important claims from Oak's site and launch materials are: - virtual mounts instead of full local clones for every agent session - branch-per-session workflows - team and project scoping for agent work - export back to Git when needed - fewer version-control tokens spent per agent operation - faster operations for agent-heavy workflows - open-source core and self-hosting options The claims need independent validation. A new VCS can sound magical in a launch post and still run into the blunt gravity of GitHub integrations, CI providers, code review habits, editor support, and team trust. But as a product thesis, it is worth taking seriously. We already argued in [agent workspaces need filesystem contracts](/blog/agent-workspaces-need-filesystem-contracts) that agents need explicit rules for where they can read, write, cache, and persist state. Oak pushes that idea one layer deeper: what if the version-control layer itself should expose an agent-native contract? ## Why Git Feels Awkward For Agents Git is extremely good at content-addressed history, local branching, distributed collaboration, and durable review. The awkwardness shows up at the interface between Git and autonomous work. | Agent Need | Git Can Do It | Why It Still Feels Awkward | |---|---|---| | Isolated attempts | Branches or worktrees | Setup and cleanup are external workflow chores | | Parallel sessions | Worktrees | Merge and conflict discipline becomes user-owned | | Cheap checkpoints | Commits or stashes | Agents often make noisy commits unless constrained | | Context-efficient history | `git log`, `git diff` | Raw output burns tokens quickly | | Safe rollback | Branch reset or revert | Dangerous commands need careful policy | | Reviewable output | Pull requests | Agents may not know what reviewers need | None of these are impossible. They are just not first-class. That is why wrappers have become common. Claude Code users reach for worktrees. Codex users lean on branch discipline and patch review. Cursor and Windsurf users often rely on editor-side checkpoints. Internal agent platforms build their own session stores, patch queues, or ephemeral sandboxes. Oak is asking whether the wrapper should become the primitive. ## The Real Problem Is Agent Session Shape Human version control is usually shaped around intent: 1. I understand the change. 2. I edit files. 3. I run tests. 4. I commit a coherent diff. 5. I open a PR. Agent version control is often shaped around search: 1. Try an approach. 2. Discover missing context. 3. Patch several files. 4. Run tests. 5. Backtrack. 6. Try another approach. 7. Keep the useful subset. 8. Summarize what survived. That second workflow creates a lot of transient state. Some of it should be saved. Most of it should not become the history future developers have to read. This is why [parallel coding agents need merge discipline](/blog/parallel-coding-agents-merge-discipline). Once more than one agent is active, version control becomes less about "can I create a branch?" and more about "can I reliably decide which branch deserves to exist?" The important artifact is not just the diff. It is the receipt: - what goal the agent pursued - what files it touched - which tests it ran - which failures it observed - which assumptions it made - which changes were discarded - what a human should review first Git stores the final tree well. It does not naturally store that receipt as a structured, queryable object. ## What An Agent-Native VCS Would Need For Oak or any similar system to matter, it has to do more than make branching feel nicer. It needs to expose primitives that map to how agents actually work. Here is the minimum useful contract. ## 1. Session-Scoped Workspaces Every agent run should have a clear workspace identity. The workspace should know: - base commit - branch or session name - files changed - generated files - ignored files - test commands run - current review status This should not live only in the model transcript. It should live next to the code state. ## 2. Cheap Disposable Attempts Agents should be encouraged to throw away bad attempts. That requires cheap checkpointing and cleanup. In Git, developers can already do this with worktrees, branches, and reset commands. The issue is that the safe version requires discipline. An agent-native layer could make the safe path the default: create attempt, run, score, promote or discard. ## 3. Context-Aware History Agents do not need the same history view as humans. A human may want a narrative commit log. An agent often needs a compact answer: - which files changed recently? - which subsystem owns this pattern? - which previous attempt failed for the same reason? - which branch already touched this test? That is a retrieval problem, not just a log display problem. This is where Oak's token-efficiency pitch becomes interesting. If version control can answer agent-shaped questions directly, the model spends fewer tokens parsing raw command output. ## 4. Review Receipts Code review for agents should start with a receipt, not a wall of generated prose. The receipt should be structured enough for CI, reviewers, and other agents to consume: ```json { "goal": "add route policy smoke coverage", "base": "abc123", "changedFiles": ["scripts/smoke-route-policy.mjs"], "tests": [ {"cmd": "pnpm smoke:route-policy", "status": "passed"} ], "reviewFocus": ["auth header behavior", "timeout defaults"] } ``` This can be built on top of Git. It does not require replacing Git. But if a VCS is designed for agents, receipts should not be an afterthought. ## The Counterargument: Do Not Replace Git The strongest counterargument is simple: the Git ecosystem is too valuable to bypass. Git already has: - universal hosting - mature CI integration - editor support - code review UI - release automation - signed commits - branch protection - enterprise policy controls - decades of operational trust Any agent-native VCS has to either interoperate perfectly with Git or remain a niche experiment. "Export back to Git" is helpful, but it is not the same as living inside the workflows teams already trust. There is also a social problem. Developers understand Git's sharp edges. They may dislike them, but they know how to inspect what happened. A new VCS has to earn that same debuggability before teams let autonomous agents use it on real code. That is why I would not frame Oak as "Git is dead." That is the wrong take. The better take is that Git is becoming a lower-level substrate, while agent systems build higher-level workspace, receipt, and review layers above it. ## The Practical Middle Ground Most teams do not need a new VCS today. They need a more explicit agent workflow on top of Git. That looks like: 1. One branch or worktree per agent run. 2. One structured receipt per run. 3. A hard rule that agents do not merge themselves without policy. 4. CI that reports which agent produced a diff. 5. Cleanup for abandoned attempts. 6. Review templates optimized for generated code. 7. A merge queue that can handle many small agent PRs. This is the bridge between today's Git workflows and a possible Oak-shaped future. Our [portable terminal agent runtime](/blog/terminal-agents-portable-runtime-surface) piece made a related point: the durable product surface is not only the model. It is approvals, rollback, diagnostics, cost telemetry, and state. Version control sits right in that control plane. ## What To Watch Oak is early. The launch is more interesting as a direction than as a settled answer. The questions to watch are concrete: - Does it integrate cleanly with GitHub and existing CI? - Can it represent agent receipts better than a PR body? - Can it make abandoned agent attempts cheap to delete? - Does token-efficiency hold up in real repos? - Can humans inspect and recover state without trusting a magic layer? - Does it work across macOS, Linux, Windows, and remote dev environments? - Can it serve teams, not just solo experiments? If those answers are strong, Oak becomes more than a neat VCS experiment. It becomes a sign that agent infrastructure is starting to reshape old developer primitives. If those answers are weak, the idea still matters. It tells us where the pressure is building. ## My Take AI coding agents probably do not need to replace Git. They do need a version-control experience that treats agent sessions as first-class objects. The current best path is likely Git underneath, plus agent-native layers for workspaces, receipts, cleanup, review, and policy. Oak is worth watching because it makes that pressure visible. Whether or not it becomes the tool teams adopt, the question it raises is the right one: What would version control look like if the next thousand code edits came from agents, not people typing one file at a time? ## FAQ ### Is Oak a Git replacement? Oak positions itself as version control designed for AI coding agents, with export back to Git. In practice, any serious adoption will depend on how well it interoperates with existing GitHub, CI, and review workflows. ### Do AI coding agents need a new VCS? Not necessarily. Most teams can start with Git branches, worktrees, structured receipts, and cleanup policy. The deeper need is agent-native workflow state, not automatically a full Git replacement. ### Why is version control harder with agents? Agents create more speculative attempts, parallel branches, noisy intermediate diffs, and abandoned work. The hard part is deciding what to promote, what to discard, and what evidence reviewers need. ### What should teams do today? Use one isolated branch or worktree per agent run, require a concise receipt, run CI before review, and keep humans in charge of merges until policy is explicit. ### What makes this an agent infrastructure topic? Version control is where agent output becomes durable team history. If that layer is messy, the rest of the coding-agent workflow becomes harder to trust. ## Sources Fetched June 23, 2026. - [Oak](https://oak.space/) - [Oak blog](https://oak.space/blog) - [Show HN discussion for Oak](https://news.ycombinator.com/item?id=48631726) - [Git worktree documentation](https://git-scm.com/docs/git-worktree) - [GitHub pull request documentation](https://docs.github.com/en/pull-requests)

OpenAI Agent Builder and Evals Are Shutting Down: Move the Agent Stack Into Code

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

OpenAI just made the agent-builder lesson explicit: production agent workflows need to live closer to code. The official deprecations page now lists three June 3, 2026 deprecations that agent teams should not ignore: - Agent Builder is scheduled to shut down on November 30, 2026. - The Evals platform becomes read-only on October 31, 2026 and is scheduled to shut down on November 30, 2026. - Reusable prompt objects and the `v1/prompts` API are scheduled to shut down on November 30, 2026. ChatKit remains available, and OpenAI points Agent Builder users toward the Agents SDK or ChatGPT Workspace Agents. For builders, the direction is clear: visual builders are useful for exploration, but the durable production surface is code, versioned prompts, and eval runs you can replay. That does not make visual builders useless. It does mean you should not let your production agent logic live only in a hosted canvas. **Last updated:** June 23, 2026 ## What Is Actually Changing OpenAI's [deprecations page](https://developers.openai.com/api/docs/deprecations) is the source to read first. The relevant timeline: | Surface | Deprecation announced | Read-only date | Shutdown date | Migration direction | |---|---:|---:|---:|---| | Agent Builder | June 3, 2026 | Not listed | November 30, 2026 | Agents SDK or ChatGPT Workspace Agents | | Evals platform | June 3, 2026 | October 31, 2026 | November 30, 2026 | Promptfoo or repo-owned eval workflows | | Reusable prompts API | June 3, 2026 | Not listed | November 30, 2026 | Move prompt content into application code | The Evals docs repeat the same point: the hosted Evals platform is being deprecated, existing eval content stays available during the transition window, and teams should look at alternatives if they are new to evaluations or want a more iterative environment. This is not only a product cleanup. It changes the advice I would give any team building agents on OpenAI. For the original builder-side take, read [OpenAI AgentKit in Production](/blog/openai-agentkit-builder-guide). This post is the migration follow-up. ## The Take: Treat Hosted Builders as Prototyping Surfaces The lesson is not "never use visual tools." The lesson is: do not let the only copy of your agent logic live in a hosted visual tool. Production agents need the same boring properties as production code: - version control; - code review; - typed configuration; - test fixtures; - reproducible eval runs; - deploy history; - rollback paths; - ownership in the repo. Hosted builders can accelerate discovery. They are great when a PM, designer, support lead, or ops teammate needs to see the shape of a workflow. They are less durable when they become the sole source of truth for branching logic, prompts, tool permissions, or evaluation criteria. That is why this deprecation matters. It pushes the ecosystem toward a healthier split: - Use visual surfaces to explore and communicate. - Use code for the production loop. - Use repo-owned eval receipts to decide whether changes ship. ## Migration Step 1: Inventory the Hidden Agent State Before moving anything, list the state that currently lives outside the repo. For Agent Builder, that usually means: - node graph structure; - prompt text inside nodes; - tool configuration; - branch conditions; - approval steps; - connector scopes; - published versions; - run traces. For Evals, it means: - eval definitions; - graders and rubrics; - datasets; - baseline runs; - score thresholds; - dashboard notes; - failure examples. For reusable prompt objects, it means: - prompt names and IDs; - prompt content; - template variables; - version history; - call sites that reference prompt IDs. Treat this like an API migration, not a copy-paste exercise. If a production service calls a prompt object by ID, the migration is not finished until that service reads a versioned prompt from code or config and has a rollback path. ## Migration Step 2: Move Prompts Into the Repo OpenAI's deprecation guidance for reusable prompt objects is blunt: move reusable prompt content into your application code. That does not mean scattering giant strings through handlers. Use a small repo convention: ```text agents/ support/ agent.ts prompts/ system.md escalation.md evals/ fixtures.jsonl rubric.md ``` The important part is not the exact folder name. The important part is that prompts get reviewed with the code that depends on them. Good prompt files should include: - what the agent is allowed to do; - what tools it may call; - what it must never claim; - what evidence it must preserve; - which eval fixtures protect the behavior. That pairs naturally with [OpenAI Agents SDK for TypeScript](/blog/openai-agents-sdk-typescript), where agent definitions, tools, handoffs, guardrails, and structured outputs already live in code. ## Migration Step 3: Rebuild Builder Flows as Explicit Agent Loops The Agents SDK is the obvious destination when the workflow is owned by engineers. The current SDK docs emphasize a few primitives that map well from visual builders: | Builder concept | Code-first replacement | |---|---| | node | function, tool, agent step, or handoff | | branch | normal control flow or guardrail | | human approval | human-in-the-loop checkpoint | | connector | MCP server, hosted tool, or typed integration | | visual run trace | SDK tracing and saved receipts | | workflow version | git commit and deployment version | This is not always a one-to-one migration. A visual canvas often has too many tiny nodes because each node is easy to add. Code lets you collapse low-value nodes into one function and expose only the actual decision points. The migration rule: ```text Keep branch decisions explicit. Batch mechanical steps into code. Preserve approval gates. Preserve tool permission boundaries. Preserve trace receipts. ``` For the SDK-side architecture details, read [Agents SDK Evolution](/blog/agents-sdk-evolution) and [Managed Agents vs LangGraph vs DIY](/blog/managed-agents-vs-langgraph-vs-diy-2026). ## Migration Step 4: Move Evals From Dashboard to Receipts The Evals platform deprecation is the more important deadline for serious teams. An agent without evals is just a workflow you hope still works. When you move evals out of the hosted dashboard, do not only move the final score. Move the evidence. A useful eval receipt should include: | Receipt field | Why it matters | |---|---| | fixture ID | ties the run to a stable test case | | baseline version | prevents comparing against a moving target | | candidate version | maps behavior to a branch or commit | | model and tool config | explains why behavior changed | | inputs and expected behavior | keeps the task reviewable | | run trace | shows tool calls, retries, and decisions | | score and rubric notes | separates correctness, safety, cost, and style | | cost and latency | prevents expensive "wins" from hiding | That is the point of [baseline receipts](/blog/agent-evals-need-baseline-receipts). You are not trying to recreate a pretty dashboard first. You are trying to preserve enough evidence that a developer can replay the important claim. OpenAI's docs point to Promptfoo as one migration path. That is reasonable if your evals are prompt and output focused. If your agent uses tools, files, browsers, sandboxes, or multi-step state, you may need a custom harness around the SDK so the eval can capture the whole run. ## Migration Step 5: Choose Workspace Agents Only for the Right Jobs OpenAI's deprecations page says Agent Builder users can continue with the Agents SDK or ChatGPT Workspace Agents. That split matters. Use code-first Agents SDK when: - the workflow ships inside your product; - the agent touches customer data; - you need CI, tests, and deployment history; - evals must run in your repo; - tool permissions are part of your security model. Use Workspace Agents when: - the workflow is mostly internal; - natural-language editing by non-engineers matters; - the output is advisory or draft-like; - the risk is bounded by human review; - you want the agent available inside ChatGPT workspaces. The mistake is treating those as interchangeable. They are not. One is a developer runtime. The other is a workspace automation surface. ## The Opposing Take: Visual Builders Still Matter There is a fair counterargument: code-first systems exclude the people who understand the process. Support leaders, product managers, sales engineers, data analysts, and operations teams often know the workflow better than the engineer implementing it. A visual builder gives them a shared artifact. A TypeScript file does not. That is why the answer is not "delete the canvas." The better pattern is dual-surface: - diagrams and visual flows for design reviews; - code for production execution; - eval receipts for behavior changes; - ChatKit or workspace surfaces for human interaction; - PR review for prompt and tool changes. The visual artifact explains the workflow. The repo owns the workflow. That distinction becomes more important as agent systems grow. A diagram can show intent. Code and evals prove what actually runs. ## A Five-Day Migration Plan Use the deprecation clock to force discipline: **Day 1: Inventory.** Export every Agent Builder flow, hosted eval, prompt object, and service call that references those IDs. **Day 2: Freeze baselines.** Save representative successful and failed runs before changing anything. Capture inputs, outputs, tool calls, cost, latency, and human notes. **Day 3: Move prompts.** Put prompts in the repo with owners, review rules, and version history. Replace prompt-ID lookups with file or config loading. **Day 4: Rebuild the loop.** Implement the agent in the Agents SDK, LangGraph, or your own loop. Preserve approval gates and tool boundaries first, then optimize. **Day 5: Replay evals.** Run the old baseline against the new implementation. Do not ship until the candidate beats or matches baseline behavior on the cases that matter. That is the practical standard. Not "we copied the graph." The standard is "we can prove the migrated agent behaves at least as well as the old one." ## FAQ ### Is OpenAI Agent Builder shutting down? Yes. OpenAI's deprecations page says Agent Builder deprecation was announced on June 3, 2026, and Agent Builder is scheduled to shut down on November 30, 2026. ChatKit remains available. ### Is OpenAI Evals shutting down? The hosted Evals platform is being deprecated. OpenAI's docs say existing evals become read-only on October 31, 2026, and the platform is scheduled to shut down on November 30, 2026. ### What should replace Agent Builder? For product-owned workflows, move the production loop into the OpenAI Agents SDK, LangGraph, or a repo-owned agent loop. For internal workspace automations where non-engineer editing matters, evaluate ChatGPT Workspace Agents. ### What should replace reusable prompt objects? Move reusable prompt content into application code or repo-managed prompt files. Keep prompts versioned, reviewed, and tied to the eval fixtures that protect their behavior. ### Does this mean visual agent builders are dead? No. Visual builders remain useful for prototyping, design reviews, and non-engineer collaboration. The change is where production truth should live: in code, reviewed prompts, deploy history, and replayable eval receipts. ## Sources - [OpenAI API Docs: Deprecations](https://developers.openai.com/api/docs/deprecations) - [OpenAI API Docs: Agents SDK](https://developers.openai.com/api/docs/guides/agents-sdk) - [OpenAI Agents SDK TypeScript docs](https://openai.github.io/openai-agents-js/) - [OpenAI Agents SDK Python docs](https://openai.github.io/openai-agents-python/) - [OpenAI API Docs: Working with evals](https://developers.openai.com/api/docs/guides/evals)

OpenAI Daybreak Shows the AppSec Bottleneck Is Patching, Not Finding

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

OpenAI's Daybreak work is easy to summarize badly. The lazy version is: "AI finds vulnerabilities now." The more useful version for developers is different: OpenAI and Trail of Bits are trying to move AI-assisted security from finding bugs toward validating, patching, testing, and handing maintainers something they can trust. That is the real AppSec bottleneck. **Last updated:** June 23, 2026 OpenAI announced [Patch the Planet](https://openai.com/index/patch-the-planet/) on June 22, 2026 as part of Daybreak, built with Trail of Bits and other partners to help open-source maintainers find, validate, and fix vulnerabilities. The important word is not "find." It is "fix." ## The Scarce Resource Is Maintainer Attention Security teams already know how to drown a project in findings. Static analyzers do it. Dependency scanners do it. Bug bounty programs can do it. AI agents can do it faster. The hard part is what happens after the finding appears: | Stage | What usually breaks | |---|---| | validation | the report is plausible but not reproducible | | triage | severity is unclear or duplicated | | patching | the fix is invasive, incomplete, or style-incompatible | | testing | the patch lacks a regression case | | disclosure | the report skips project norms or private channels | | review | maintainers spend more time interpreting the report than fixing the risk | That is why Daybreak is worth covering after our post on the [AI security triage bottleneck](/blog/ai-security-triage-bottleneck). That piece argued that finding more issues is not enough if humans cannot validate and route them. Daybreak pushes the next step: can the agent help close the loop with a useful patch? Trail of Bits described the first week of Patch the Planet as 64 pull requests and 51 issues across 19 projects, with 37 patches already merged. OpenAI named early participant projects including cURL, NATS Server, pyca/cryptography, Sigstore, aiohttp, Go, freenginx, Python, and python.org. Those numbers matter less as a scorecard than as a workflow clue. The unit of value is not a vulnerability count. It is a maintainer-acceptable change. ## What Daybreak Is Actually Testing OpenAI says the broader Daybreak stack includes Codex Security, GPT-5.5-Cyber, human reviewers, partner researchers, and maintainer coordination. The interesting system design is the wrapper around the model: - scan real repositories - use repository-specific context and threat models - validate findings in isolated environments - rank results by practical risk - attach evidence - suggest patches - route findings through human review before maintainers see them - coordinate disclosure when details are not ready to be public That wrapper is the product. For developers, the lesson is similar to [long-running agents need harnesses](/blog/long-running-agents-need-harnesses). A security agent without a harness is just a louder scanner. A security agent with evidence, tests, review queues, and rollback paths can become part of the engineering system. This also connects to [agent evals need baseline receipts](/blog/agent-evals-need-baseline-receipts). A benchmark score is interesting, but a patching workflow needs receipts: the finding, the reproduction, the patch, the test, the review decision, and the final state. ## Codex Security Is Not Just a Scanner OpenAI's [Codex Security documentation](https://developers.openai.com/codex/security/) describes workflows for scans, deep scans, pull request review, backlog triage, fixing findings, exporting, and tracking. That scope matters because the developer value is not "run one more security tool." It is "turn a security queue into engineering work." The best agentic AppSec workflow should be able to answer: - What changed since the last scan? - Which finding is reproducible? - What is the minimal safe patch? - Which test proves the patch? - Which maintainer owns the review? - Which issues were fixed, dismissed, duplicated, or still uncertain? - What evidence can be exported into the team's existing tracker? If the tool only produces a wall of warnings, it competes with every other noisy scanner. If it produces a narrow patch with evidence and tests, it competes with manual security engineering time. That is a much better category. ## The Supply Chain Angle Open-source security is also a supply-chain problem. We covered this in [npm supply-chain trust boundaries for AI agents](/blog/npm-supply-chain-trust-boundaries-ai-agents): agents are good at normalizing risky automation unless the workflow forces provenance, scope, and review. AppSec agents need the same discipline. Patch generation is powerful, but it introduces new trust questions: - Who authored the patch? - Which model and toolchain produced it? - Which tests were run? - Which disclosure channel approved it? - Did the patch introduce new behavior outside the reported issue? - Is the fix minimal enough for maintainers to audit quickly? Maintainers should not have to accept "AI found this" as evidence. They need a patch they can read, a reproduction they can run, and a review trail they can audit. That is why the OpenAI and Trail of Bits framing around expert review is important. Patch the Planet is not positioned as fully automatic open-source fixing. The sources emphasize human review and maintainer control. ## What Teams Can Copy Now Most engineering teams do not need GPT-5.5-Cyber or a global open-source campaign to copy the useful pattern. They can start with a local security-agent loop: 1. Pick one repo and one class of issue. 2. Require a reproduction or evidence snippet before a finding enters the queue. 3. Ask the agent for the smallest safe patch, not a broad refactor. 4. Require a regression test or harness change with every fix. 5. Route the patch through the same review queue as human code. 6. Track fixed, duplicate, false positive, and needs-human-investigation states. 7. Periodically compare agent findings against a baseline scanner and human review. That maps neatly to [AI coding agents need review queues](/blog/ai-coding-agents-review-queues). The queue is not bureaucracy. It is the place where agent output becomes accountable engineering work. It also maps to the [OpenAI Codex guide](/blog/openai-codex-guide): the most useful agent workflows are specific, bounded, and reviewable. "Find security bugs" is too broad. "Reproduce this class of parser issue, propose the smallest patch, add a regression test, and leave evidence" is a workflow. ## The Practical Take The best security agent is not the one that opens the most issues. It is the one that closes the most real risk without exhausting the people who own the code. That is why Daybreak is important. It points away from vanity vulnerability counts and toward a maintainer-aware AppSec system: evidence, validation, patch, test, disclosure, review, and tracking. For developers building with agents, that is the template. Do not measure your security automation by how many warnings it can produce. Measure it by how many safe, understandable, well-tested changes humans are willing to merge. ## FAQ ### What is OpenAI Daybreak? Daybreak is OpenAI's security initiative around AI-assisted cyber defense, including tools and programs such as Codex Security and Patch the Planet. ### What is Patch the Planet? Patch the Planet is an OpenAI Daybreak initiative built with Trail of Bits to help open-source maintainers find, validate, and fix vulnerabilities with AI assistance and expert human review. ### What is agentic AppSec? Agentic AppSec is application security work where AI agents help inspect code, validate findings, propose patches, run tests, and support review workflows rather than only generating static reports. ### Should teams trust AI-generated security patches? Not blindly. AI-generated patches need reproduction evidence, tests, human review, maintainer control, and a clear audit trail before they should be merged. ## Sources - [OpenAI: Patch the Planet](https://openai.com/index/patch-the-planet/) - [OpenAI: Daybreak tools](https://openai.com/index/daybreak-securing-the-world/) - [OpenAI Daybreak product page](https://openai.com/daybreak/) - [OpenAI Developers: Codex Security](https://developers.openai.com/codex/security/) - [Trail of Bits: Introducing Patch the Planet](https://blog.trailofbits.com/2026/06/22/introducing-patch-the-planet/)

OpenMontage Shows the Real Future of AI Video: Agents, Not Editors

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Most AI video coverage is obsessed with the wrong surface. The question is usually: which model generates the best clip? OpenMontage points at a more interesting shift: video production is becoming a repo-shaped agent workflow. The important pieces are not only pixels and frames. They are scripts, assets, timelines, renders, review notes, file conventions, and agents that can operate the whole pipeline. **Last updated:** June 23, 2026 OpenMontage is trending on GitHub today, and its README describes it as an open-source agentic video production system with 12 pipelines, 52 tools, and 500+ agent skills. The project says it works with Claude Code, Cursor, Copilot, Windsurf, and Codex, with prerequisites including Python, FFmpeg, Node.js, and an AI coding assistant. That is the story. Not "AI video replaces editors." More like: video work is moving closer to software work. ## Why This Is Different From AI Video Hype AI video hype usually starts with a text box and ends with a clip. That is useful for ideation, but production is a lot messier: | Production object | Why agents care | |---|---| | script | can be versioned, revised, and split into scenes | | assets | need filenames, rights, dimensions, and reuse rules | | timeline | has structure, dependencies, durations, and tracks | | audio | needs cleanup, pacing, captions, and sync | | render scripts | can be automated, tested, and retried | | review notes | can become concrete edits instead of vague comments | | distribution exports | need formats, thumbnails, titles, descriptions, and metadata | That is why OpenMontage belongs next to posts like [skills are how agents learn the job](/blog/skills-are-how-agents-learn-the-job) and the [agent skills production checklist](/blog/agent-skills-production-checklist). A useful production agent does not just know how to call a model. It knows the local job. For video, the local job is full of structured work. ## The Repo-Shaped Video Studio The most practical AI video workflow looks less like a magic editor and more like a small software project. You have: - a source script - a scene list - asset folders - voiceover files - caption files - render templates - export targets - review notes - distribution drafts - a changelog of what changed That is exactly the kind of surface coding agents can operate on. They can read files, revise markdown, update JSON, run scripts, inspect errors, split work into steps, and keep state in the repository. This is the same reason the [best Claude Code skills](/blog/best-claude-code-skills-2026) are not just clever prompts. They package repeatable work. The unit is not "make a video." The unit is "turn this script into a scene plan," "generate missing caption timing," "rerender this section," or "prepare three distribution exports." Small, reviewable jobs beat one giant autonomous promise. ## Why Coding Agents Fit Video Production Video production has an unusual mix of creative judgment and mechanical repetition. Humans should still own taste: pacing, tone, narrative, humor, and whether the final thing is worth publishing. But a lot of the workflow is procedural: - normalize filenames - generate a scene manifest - split a transcript into caption chunks - verify every asset exists - run FFmpeg - inspect render logs - update a storyboard - produce social clips - create a thumbnail brief - write distribution copy That explains why OpenMontage lists compatibility with coding agents rather than positioning itself as only a web editor. The agent does not need a timeline UI if the pipeline exposes enough of the work as files, scripts, and structured instructions. This is also where [taste skills for AI agents](/blog/taste-skills-ai-agents-design-review) matter. A video agent can produce a lot of output quickly. Without taste constraints, it can also produce a lot of generic sludge quickly. The production system needs review gates, not only generators. ## What Developers Should Copy Even if you never use OpenMontage, the pattern is useful. If you make technical videos, demos, course clips, or product walkthroughs, start by making the workflow legible to agents: 1. Put each video in its own folder. 2. Keep the script in markdown. 3. Store scene metadata in JSON or YAML. 4. Use stable asset names. 5. Keep render commands in scripts. 6. Save review notes as files. 7. Track distribution drafts beside the source. 8. Make every output reproducible from repo state. That gives an agent something concrete to operate. It also gives humans a clean review surface. You can inspect the script diff, scene manifest, caption file, render command, and export folder separately instead of judging one opaque "AI made a video" blob. For a smaller example, the [AI podcast generator](/blog/build-ai-podcast-generator) post already shows how media production becomes more useful when it is broken into data, script, voice, and export steps. OpenMontage pushes the same idea further into video. ## Where This Can Go Wrong The contrarian take: "500+ skills" is not automatically a moat. A large skill library can be impressive, but production quality depends on a smaller set of things: - Are the workflows reproducible? - Are assets tracked? - Are render failures recoverable? - Are rights and provenance visible? - Are captions reviewed? - Are edits tied to human notes? - Can the final output be regenerated? - Can the team tell what changed between versions? Those are software questions. That is why [AI skills for knowledge work](/blog/ai-skills-knowledge-work) matters here. Skills are useful when they turn hidden professional judgment into explicit workflow. They are less useful when they become a pile of vaguely named commands. ## The Practical Take OpenMontage is interesting because it treats video production as an agent-operable system. That is the broader shift. The next useful AI video tools will not only generate clips. They will manage the boring middle: scene planning, asset checks, render automation, captions, review loops, and distribution exports. For developers, this is the lesson to steal: If you want agents to help with creative work, make the creative workflow file-based, testable, reviewable, and repeatable. The future of AI video may look less like a single editor and more like a repo with a very good production crew attached. ## FAQ ### What is OpenMontage? OpenMontage is an open-source agentic video production project that describes itself as a system with pipelines, tools, and agent skills for video workflows. ### What is agentic video production? Agentic video production means using AI agents to operate parts of the video workflow such as scripting, asset organization, render automation, captions, review tasks, and distribution exports. ### Does OpenMontage replace video editors? No. The useful framing is not replacement. It is workflow automation around structured production tasks, with humans still owning taste, review, and publishing decisions. ### Why does this matter for developers? Developers are already comfortable with repo-based workflows, scripts, logs, and version control. That makes video production a natural place for coding agents when the workflow is expressed as files and commands. ## Sources - [OpenMontage on GitHub](https://github.com/calesthio/OpenMontage) - [GitHub Trending daily repositories for agent](https://github.com/trending?since=daily&q=agent) - [GitHub Trending weekly repositories for agent](https://github.com/trending?since=weekly&q=agent) - [Google Trends daily RSS, United States](https://trends.google.com/trending/rss?geo=US) - [OpenAI: Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/) - [Anthropic Claude Code overview](https://docs.anthropic.com/en/docs/claude-code/overview)

Prompt Injection Is Really Role Confusion

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Simon Willison linked a new paper writeup today that gives prompt injection a better name: role confusion. That framing is useful because it moves the problem out of the vague "LLMs are gullible" bucket and into a concrete systems problem. An agent receives system instructions, developer messages, user prompts, tool outputs, retrieved webpages, previous assistant messages, and sometimes reasoning traces as one long stream of tokens. Humans see separate boxes. The model sees text with role labels. If the model cannot reliably perceive those role boundaries, prompt injection is not a weird edge case. It is an expected failure mode. **Last updated:** June 23, 2026 The research site, [Prompt Injection as Role Confusion](https://role-confusion.github.io/), makes the core point cleanly: roles are how LLMs recover structure from a "token soup." The model is supposed to treat system text differently from user text, tool output differently from instructions, and its own reasoning differently from untrusted content. That works until it does not. ## The Core Idea The role-confusion writeup describes roles as an attempted type system for language. That is exactly the right phrase. In software, types tell the runtime what a value is allowed to mean. A string can be user input, HTML, SQL, a shell command, JSON, or a file path. Treating all strings the same is how you get injection bugs. LLM agents have a similar problem: | Text Source | What It Should Mean | |---|---| | system | high-priority operating rules | | developer | product and integration instructions | | user | the human's requested task | | tool | external data, not instructions | | assistant | previous model output | | reasoning | private intermediate inference, when exposed to the model runtime | Prompt injection happens when low-authority text gets interpreted as high-authority text. A webpage should be data. A malicious line inside that webpage should not become an instruction. A PDF should be evidence. A hidden paragraph inside that PDF should not be allowed to rewrite the task. A Slack message should be conversation context. It should not be able to exfiltrate connected data. The problem is that roles are represented in the same medium as everything else: tokens. ## Why Better Warnings Are Not Enough The paper writeup and Simon's summary highlight a disturbing finding: models can respond more to style than to the explicit role label. The authors describe "destyling" attacks: rewrite injected text so it no longer resembles privileged reasoning or instruction text, and attack success changes dramatically. Simon quoted their result that destyling reduced average attack success in one dataset from 61% to 10%. That is not just a jailbreak trick. It suggests the model is not reading role boundaries like a compiler reads types. It is inferring them from patterns, style, position, and learned associations. This explains why prompt injection defenses often feel like whack-a-mole: - "Ignore previous instructions" gets memorized as suspicious. - The attacker rephrases it. - The model sees a style that resembles a legitimate instruction. - The boundary blurs again. Attack memorization is brittle. Role perception is the thing we actually need. For developers, that means stronger system prompts help, but they are not a complete security boundary. If your safety model is "we told the agent not to follow tool-output instructions," you do not have a boundary. You have a preference. ## The Agent Design Implication The dangerous version of prompt injection is not a chatbot saying something weird. The dangerous version is an agent with tools: - browser access - Slack access - email access - file access - database access - issue tracker access - payment or deployment access Once the agent can act, role confusion becomes capability confusion. The model may confuse a webpage instruction with the user's request, then use real tools to satisfy it. That is why prompt injection belongs next to capability design, not just prompt engineering. We covered the practical version in [prompt injection for agent apps](/blog/prompt-injection-agent-apps-practical-version), but this research gives the deeper reason: the model's internal role perception is not discrete enough to carry the whole security model. The architecture should assume untrusted content can sound like instructions. ## Practical Defenses The right response is layered isolation. ### 1. Preserve Provenance Every chunk passed to the model should carry a source label that the rest of the system also understands. Do not only wrap text in a prose warning. Store provenance in your application state: - source URL - tool name - user who supplied it - timestamp - permission scope - trust level - whether it is allowed to contain instructions The model can use the label, but your code should enforce the policy. ### 2. Separate Evidence From Commands Treat tool output as evidence, not as executable instruction. A good agent loop distinguishes: - "The webpage says X" - "The user asked me to do Y" - "The policy allows action Z" Those should not be collapsed into one blob of context. ### 3. Require User Approval At Authority Boundaries If untrusted content causes the agent to send a message, modify a file, hit an external API, change permissions, spend money, or reveal private data, require approval. The approval prompt should identify the source of the request. "This webpage appears to be asking me to email your token" is very different from "Do you want me to continue?" ### 4. Constrain Tools By Default The easiest injection to survive is the one that cannot reach a dangerous tool. Use scoped credentials, read-only modes, limited file roots, allowlisted domains, dry runs, and separate agents for separate trust zones. If a research agent only needs public browsing and note writing, do not give it GitHub write access or Slack posting rights. This is the same principle behind an [agent containment capability ledger](/blog/agent-containment-capability-ledger): list what the agent can touch before you worry about how clever the prompt is. ### 5. Make Retrieval Output Visibly Untrusted For UI agents and internal tools, show users where retrieved text came from. Make it easy to inspect the source, page, thread, or file that influenced an answer. This does not solve model perception, but it improves human review. The reviewer can see whether the agent treated a source as evidence or as an instruction. ## The Bigger Lesson Role confusion is not only a security bug. It is a design constraint for every agent product. Agents need roles, but roles are currently soft. They are represented through tokens and training, not enforced like process isolation or type checking. That means the surrounding application has to provide the hard edges: - permissions - sandboxing - source metadata - tool gating - user approvals - logs - replayable traces MCP servers, browser agents, file-editing agents, and Slack agents all face the same issue. The model may be good at following roles most of the time. Security architecture has to care about the times it fails. That is why I like the role-confusion framing. It makes prompt injection feel less mystical. It is not that the model has a tiny villain inside it. It is that the model is asked to infer authority from text style and role markers inside one continuous stream. Sometimes it infers wrong. ## My Take The next generation of agent security will look less like clever prompt wording and more like boring systems engineering. Treat roles as hints to the model, not as the enforcement layer. Put enforcement in the harness: - code decides which tools are available - code decides which sources are trusted - code decides when approval is required - code logs why an action happened - code preserves provenance The model can still reason over messy text. It just should not be the only thing deciding whether messy text has authority. Prompt injection is role confusion. The fix is not one perfect warning. The fix is making role boundaries visible, reviewable, and enforceable outside the model. ## FAQ ### What is role confusion in prompt injection? Role confusion is when an LLM misperceives which role a piece of text belongs to. For example, it may treat untrusted tool output as if it were a user instruction or privileged reasoning. ### Why does role confusion matter for agents? Agents can take actions. If an agent confuses untrusted content for authorized instructions, it may use tools, send messages, edit files, or expose data in ways the user never requested. ### Can system prompts prevent prompt injection? System prompts help, but they are not a complete security boundary. The surrounding application still needs tool gating, provenance tracking, sandboxing, and approval flows. ### What is the difference between attack memorization and role perception? Attack memorization means the model recognizes known injection phrases and refuses them. Role perception means the model understands that text from a low-authority source lacks permission to issue commands, even when the attack is rephrased. ### What should developers do first? Start by inventorying capabilities. List every tool the agent can use, which sources can influence it, and which actions require approval. Then make untrusted content visibly separate from user instructions in both the model context and the application state. ## Sources Fetched June 23, 2026. - [Prompt Injection as Role Confusion](https://role-confusion.github.io/) - [Simon Willison: Prompt Injection as Role Confusion](https://simonwillison.net/2026/Jun/22/prompt-injection-as-role-confusion/) - [OWASP: Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) - [Model Context Protocol specification](https://modelcontextprotocol.io/specification/)

TikZ Editor Is a WYSIWYG LaTeX Figure Tool Built Almost Entirely by Codex

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

A [Show HN post](https://news.ycombinator.com/item?id=48645437) hit the front page today featuring [TikZ Editor](https://tikz.dev/editor/), an open-source WYSIWYG editor for TikZ figures in LaTeX. The creator, Dominik Peters, described the project as "built almost entirely by Codex." The reception was enthusiastic. The technical details are worth examining for anyone interested in what agent-built software actually looks like when it ships. **Last updated:** June 23, 2026 ## What TikZ Editor Does TikZ is a widely-used LaTeX package for drawing figures in academic papers. It uses commands like `\draw[->] (0,0) -- (1,2);` to draw lines, shapes, and text. Academics typically code up figures by hand, tweaking coordinates and recompiling until things look right. TikZ Editor solves this with a dual-pane approach: - **Live source editing** - you can edit the TikZ code directly - **Visual manipulation** - you can drag and resize elements on a rendered preview - **Bidirectional sync** - changes in either pane update the other The key technical insight is that when you drag an element, the editor only modifies the coordinate numbers in the source code. It preserves line breaks, indentation, and everything else. The source never turns into unreadable machine-generated soup. This is the kind of careful design that makes tools feel professional rather than gimmicky. ## Why It Took an Agent to Build The creator's explanation in the Show HN is direct: > This approach essentially required reimplementing a large fraction of TikZ, which is the kind of task that no human would ever want to do. TikZ is a complex package with loops, macros, and extensive syntax. Parsing it accurately enough to track source locations for every drawn object is not technically impossible - it is just tedious. The kind of tedious that stops projects before they start. The argument is not that agents are smarter than humans at this task. The argument is that agents have a higher tolerance for grunt work. If a task requires implementing hundreds of edge cases with no intellectual novelty, an agent can do it while a human would give up. Peters describes several "side quests" that came out of the project: - Converters from SVG, PowerPoint, and Ipe to TikZ - A re-implementation of the LaTeX hyphenation and line-breaking algorithm for multi-line nodes - A color picker using LaTeX's `red!20!black` color mixing notation Each of these is a small, self-contained problem that an agent can solve without needing high-level architectural judgment. ## What HN Is Saying The [Hacker News thread](https://news.ycombinator.com/item?id=48645437) is overwhelmingly positive, which is notable for a Show HN. A few representative comments: > Wow, this is really, really great. Congratulations on an excellent offering and piece of tech! > All STEM students and researchers from the world thank you. > The killer feature for me is not drawing TikZ visually, but being able to touch old TikZ without turning the source into generated-looking soup. That last point is worth emphasizing. The editor respects existing code. It does not reformat or regenerate. It edits in place. This is what makes it usable for real academic workflows where papers are co-authored and version controlled. Some commenters asked for related features: - Support for CeTZ (the Typst equivalent of TikZ) - Support for pgfplots (the TikZ extension for charts and plots) These are reasonable requests that fit the same technical pattern: implement enough of the target syntax to enable visual editing without destroying source formatting. ## The Case Study for Agent-Built Software TikZ Editor is interesting as an existence proof. It shows: **1. Agents can handle tedious implementation work.** Reimplementing TikZ parsing is exactly the kind of task that agents excel at. The specification exists (TikZ has documentation). The success criteria are clear (does the rendered output match?). The work is repetitive. **2. Quality depends on the guiding vision.** The editor is not a random pile of generated code. It has a coherent design - bidirectional editing, source preservation, converter ecosystem. That design came from a human. The agent implemented it. **3. Open source matters for trust.** Agent-built software raises natural questions about code quality and maintainability. Publishing the source lets the community verify and contribute. It also makes the project sustainable - others can fix bugs and add features. **4. The "impossibly tedious" category is real.** There are projects that never get built because the ratio of grunt work to interesting work is too high. Agents shift that ratio. Some previously impossible projects become possible. ## The Limits The Show HN post does not describe any significant debugging struggles or agent failures. That is unusual. Most agent-built projects involve substantial human intervention - reviewing generated code, fixing subtle bugs, rejecting bad approaches. It is possible that TikZ parsing happens to be an unusually good fit for agent work: clear specs, testable output, minimal ambiguity. It is also possible that the creator is understating the human effort involved. Either way, the result is a functional, useful tool. The question of how much human effort was really required is interesting but secondary. ## Practical Takeaways For developers considering agent-assisted builds: **Look for tedious-but-specified tasks.** If the work is boring and the success criteria are clear, an agent can probably help. If the work requires judgment about trade-offs or user experience, you will need more human involvement. **Design before generating.** TikZ Editor works because someone thought carefully about bidirectional editing and source preservation before writing any code. The agent implemented a design. It did not invent one. **Publish the source.** Agent-built software benefits from transparency. If the code is good, publishing it builds trust. If the code has issues, the community can help fix them. **Match the tool to the task.** The creator used Codex, which has particular strengths in code generation and transformation. Different agents have different strengths. Pick the one that fits your task. ## My Take TikZ Editor is the kind of project that makes agent-assisted development feel real rather than hypothetical. It is not a demo or a proof of concept. It is a production tool that solves a genuine problem for a specific audience. The fact that it was built "almost entirely by Codex" is noteworthy, but the more important point is that it works. Users do not care whether the code was written by a human or an agent. They care whether the tool does what they need. This is the right frame for thinking about agent-built software. The question is not "who wrote the code?" The question is "does it work, can it be maintained, and does it solve a real problem?" For TikZ Editor, the answer appears to be yes on all three counts. ## FAQ ### What is TikZ Editor? TikZ Editor is an open-source WYSIWYG editor for TikZ, the LaTeX package used to draw figures in academic papers. It lets you edit TikZ code visually while preserving the original source formatting. ### How was TikZ Editor built? The creator, Dominik Peters, states it was "built almost entirely by Codex." The agent handled tedious implementation work like parsing TikZ syntax and tracking source locations. ### Does the editor reformat TikZ code? No. A key design choice is that visual edits only modify coordinate numbers in the source code. Line breaks, indentation, and other formatting are preserved. ### Is TikZ Editor open source? Yes. The project is available as both a web app and a desktop application, with source code publicly available. ### What other converters does it include? The project includes converters from SVG, PowerPoint, and Ipe to TikZ format, plus a re-implementation of LaTeX hyphenation for multi-line nodes. ## Sources - [TikZ Editor](https://tikz.dev/editor/) - [Show HN: TikZ Editor](https://news.ycombinator.com/item?id=48645437) - [TikZ documentation](https://ctan.org/pkg/pgf)

Unlimited OCR: Baidu's Open-Source Solution for Long Document Parsing

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

Baidu has open-sourced [Unlimited OCR](https://github.com/baidu/Unlimited-OCR), a vision-language model designed to transcribe long documents in a single pass. The project hit the Hacker News front page with 310 points and sparked a surprisingly heated debate about whether OCR is actually a solved problem. Spoiler: it is not. **Last updated:** June 23, 2026 For the broader runtime decision that compares this with Mistral's launch, read [Mistral OCR 4 and Unlimited OCR make document parsing an agent runtime choice](/blog/mistral-ocr-4-unlimited-ocr-document-agents). This post stays focused on Baidu's open long-document approach. ## What Unlimited OCR Actually Does The core innovation is architectural. When you feed a 100-page PDF to a typical vision-language model, the KV cache (the model's short-term memory of what it has already transcribed) grows linearly. This means memory consumption explodes and generation slows to a crawl. Developers have historically worked around this by chunking documents page-by-page, processing them separately, and stitching the text back together - a janky approach that loses cross-page context. Unlimited OCR introduces Reference Sliding Window Attention (R-SWA) to split the model's attention into two paths: 1. **Global Reference**: The model maintains full, uncompromised sight of the original document image. Context is never lost. 2. **Local Generation**: The model restricts its memory of its own output to a tight, moving window (roughly the last 128 words) and forgets the rest. The result: O(1) memory consumption for output generation, regardless of document length. That claim matters most for document-agent workloads. A support agent, legal review tool, research assistant, or internal knowledge base does not only need text. It needs long documents parsed without quietly losing cross-page context. That is the same ingestion problem behind [RAG with Claude](/blog/rag-with-claude-add-context-without-retraining): retrieval quality is capped by source preparation. ## Technical Details The model supports two processing modes: - **Gundam config**: base_size=1024, image_size=640, crop_mode enabled - optimized for multi-page documents - **Base config**: base_size=1024, image_size=1024 - standard processing for single images The system implements n-gram repetition blocking (window sizes of 128 for single images, 1024 for multi-page documents) to prevent the model from getting stuck in repetitive output loops. **Requirements:** - Python 3.12.3 - CUDA 12.9 - PyTorch 2.10.0 - Transformers 4.57.1 - An NVIDIA GPU with sufficient VRAM You can run inference via HuggingFace Transformers directly or deploy an OpenAI-compatible API server via SGLang. The model is available on both HuggingFace (baidu/Unlimited-OCR) and ModelScope. That makes Unlimited OCR more of a developer runtime surface than a packaged document platform. If you need workflow UI, validation queues, deployment controls, or business extraction templates, a higher-level parser like [Unstract](/blog/unstract-ai-document-parser) still sits above the OCR layer. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48643426) immediately split into two camps. **The "OCR is solved" camp** pointed to existing vision models: > "OCR has been solved long time ago with vision models. Solutions are consistent, reliable, and stable." They were quickly corrected by practitioners who work with OCR daily: > "I've been working on Parseur for the last 10 years, and OCR has not been solved yet, let me tell you. OCR still sucks in 2026." The most nuanced take came from commenters who distinguished between different OCR tasks: > "If you try to OCR hand-filled forms with a fixed structure, traditional OCR models are great. But if you are trying to ingest diverse documents with headings, multi-column layouts, headers and footers, ad space in the middle of your text, etc, vision-llms are a giant step forward." **The "OCR is too expensive" camp** raised valid concerns about cost and speed: > "Traditional OCR is faster, cheaper, and much more reliable than LLMs" But others countered with specific examples where LLM-based OCR works: > "I found that feeding it to Claude Sonnet 4.x via API gave me results that were perfect. No corrections required. So perfect, that Claude was reading along with the story, and actually pointed out a continuity error in the story." **The hallucination concern** was raised multiple times. LLM-based OCR can "improve" text by filling in what it thinks should be there rather than what the document actually says: > "A simple example is words that are supposed to be in other languages being automatically translated to English, which ruins the effect" One commenter reported Unlimited OCR working well for Japanese grammar PDFs: "It has converted about 200 pages in an hour" on a 4090. **The music notation thread** was unexpected. A jazz musician derailed the conversation into a discussion of optical music recognition (OMR), which remains far behind text OCR. LLMs understand music theory well enough when described in text, but reading sheet music is still "basically a greenfield for AI wherever you look." ## The Real Landscape: What to Use When Based on the discussion, here is a rough hierarchy: **For simple, structured forms with clean scans:** - Tesseract or PaddleOCR (also from Baidu) work well - Fast, cheap, deterministic **For complex documents with mixed layouts:** - Azure Document Intelligence or AWS Textract are the commercial leaders - About 85% accuracy - "but you have to run a test because they both fail in different ways on the 15%" **For multi-page documents where context matters:** - Unlimited OCR is worth testing - Marker (with --force-ocr) gets good results - Mistral OCR 4 (released today - timing) **For production pipelines:** - Expect to validate. Every OCR tool fails on edge cases - Build verification into your pipeline, not just blind extraction For general vision extraction, the [Claude Vision API production guide](/blog/claude-vision-api-production-guide) covers the other side of the choice: use a broader multimodal model when the task is visual reasoning, not only page transcription. ## Why This Matters The paper (arXiv:2606.23050) acknowledges that using an LLM decoder for OCR is a double-edged sword. The language prior helps correct errors and handle degraded inputs, but the accumulated memory load makes long documents impractical. R-SWA is an elegant architectural fix that keeps the benefits while eliminating the scaling problem. For developers building document processing pipelines, this is another tool in the toolkit. The fact that it is open-source (Apache 2.0) and runnable locally is significant - you can actually iterate on edge cases rather than filing support tickets. The HN discussion also surfaced a useful tool comparison: Marker, Mistral OCR, Docling, Azure Document Intelligence, Textract, and now Unlimited OCR. If you are in the market for document parsing, run your actual documents through a few of these before committing. This is especially true for archives and search products. The [SNEWPAPERS agentic search writeup](/blog/agentic-search-snewspapers) is a good reminder that OCR is only one stage. Layout segmentation, indexing, metadata, retrieval, and source-visible UI all decide whether the final agent can be trusted. ## FAQ ### What is Unlimited OCR? Unlimited OCR is Baidu's open-source vision-language model for long-document OCR. It is designed to parse multi-page documents without the generation memory growing linearly with document length. ### What makes Unlimited OCR different from normal OCR? The key idea is Reference Sliding Window Attention. The model keeps access to the document image while limiting how much generated text history it carries forward, which targets long-document memory blowup. ### Is Unlimited OCR production-ready? Treat it as a promising open model to benchmark, not a full production document platform. You still need serving, validation, confidence checks, human review for low-confidence fields, and operational monitoring. ### Should I use Unlimited OCR or Mistral OCR 4? Use Unlimited OCR when open deployment and long-document experimentation matter. Use a packaged OCR or document API when you need pricing, SLAs, batch processing, model cards, and production support. ### How does OCR affect RAG quality? OCR quality sets the floor for retrieval. If page structure, table boundaries, language, or references are lost during parsing, the retriever and final agent cannot reliably recover them later. ## Sources - [Unlimited-OCR GitHub Repository](https://github.com/baidu/Unlimited-OCR) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48643426) - [arXiv Paper: 2606.23050](https://arxiv.org/abs/2606.23050) - [Unlimited OCR on Hugging Face](https://huggingface.co/baidu/Unlimited-OCR) - [Unsloth Documentation for GLM models](https://unsloth.ai/docs/models/glm-5.2) (related model tooling)

VibeThinker-3B: A 3 Billion Parameter Model That Outscores Opus 4.5 on Reasoning

Developers Digest — Tue, 23 Jun 2026 00:00:00 GMT

A paper titled "VibeThinker: Spectrum-to-Signal Reasoning in Compact Language Models" is circulating on [Hacker News](https://news.ycombinator.com/item?id=48639240) with a headline claim: a 3 billion parameter model achieves 94.3% on AIME 2026 (97.1% with test-time scaling), 80.2% Pass@1 on LiveCodeBench v6, and a 96.1% acceptance rate on unseen LeetCode contests. Those numbers match or exceed flagship models that are 100x larger. The [arXiv paper](https://arxiv.org/abs/2606.16140) explains how - and the tradeoffs involved. **Last updated:** June 23, 2026 ## What the Paper Claims VibeThinker-3B is a "compact dense model" designed specifically for verifiable reasoning tasks. The authors use what they call the "Spectrum-to-Signal post-training paradigm" with three components: 1. **Curriculum-based supervised fine-tuning** - training on progressively harder reasoning problems 2. **Multi-domain reinforcement learning** - using verifiable rewards from math and code execution 3. **Offline self-distillation** - the model teaching itself from its own successful reasoning traces The key theoretical contribution is the "Parametric Compression-Coverage Hypothesis": verifiable reasoning can be compressed into compact models, while open-domain knowledge and general-purpose competence require broad parameter coverage. Translation: you can make a small model very good at math and code if you are willing to sacrifice its ability to answer general knowledge questions. That is the same tradeoff behind [local Qwen as a different tool, not a worse Opus](/blog/local-qwen-different-tool-not-worse-opus) and [GLM 5.2 local deployment](/blog/glm-5-2-local-deployment-unsloth-quantization). Small models get interesting when you give them narrow jobs, controlled inputs, and a harness that catches the failure modes. ## What HN Is Actually Saying The [discussion](https://news.ycombinator.com/item?id=48639240) has 99 comments and the community is split on what this result means. **The clarifiers:** One highly-upvoted comment cuts through the confusion: "Lots of confusion about what this model is actually focused on. It is a cheap specialist for closed-world, verifiable reasoning tasks like math, self-contained coding problems, and similar. 'Closed-world' means the needed information is already in the context. It is not a tool-using agent that can discover missing context." **The skeptics:** Several commenters tried standard LLM tests and found the model lacking. One attempted the "pelican on a bicycle SVG" test and got "a rectangle and a black circle." Others pointed out this is expected - the model was not trained on SVG generation or visual reasoning. **The practical testers:** One commenter reported success using VibeThinker-3B as a replacement for GPT-5 nano in source code security review, running on an RTX 3090 via vLLM. "It's not great on structured output but I'm working around that in my harness." **The math crowd:** Someone tested it on a nasty ODE problem from the Mathematica 15 release notes and "surprisingly it found a valid solution." Running at 25 tok/s on an RTX 2070 Super. Another commenter reproduced the result with the Q4_K_M quantized version at 110 tok/s. **The tool calling concern:** Multiple comments noted the model does not support tool calling. "Was not part of its training. It's focused on Python and I think C++ competitive programming and mathematics tasks." This limits its usefulness as an autonomous agent. ## Running It Locally VibeThinker-3B is small enough to run on consumer hardware. The quantized versions are available on [Hugging Face](https://huggingface.co/prithivMLmods/VibeThinker-3B-GGUF). Hardware reports from the thread: - **RTX 2070 Super**: 110 tok/s generation, 1800 tok/s prefill with Q4_K_M - **RTX 3090**: Full speed via vLLM for batch security review work - **CPU only**: Viable but slower - it is a 3B model after all The model uses extended thinking by default. One test took 3 minutes 22 seconds to answer a math problem, spending 22k tokens on reasoning before producing the final answer. ## The Architecture Question A recurring theme in the comments: is this a reasoning module or a standalone model? One commenter frames it well: "These kinds of models might be more useful as tools to be used by larger orchestrator models, than being the orchestrators themselves." The lack of tool calling support reinforces this. VibeThinker-3B cannot search the web, cannot look up documentation, cannot call external APIs. It can only reason over what is already in its context window. For a multi-agent architecture, that might be exactly what you want - a cheap, fast reasoning specialist that handles the math and code verification while a larger model handles orchestration, context gathering, and general knowledge tasks. That is also the practical version of [model routing to cut AI spend](/blog/model-routing-recipes-cut-ai-spend): route the closed-world reasoning slice to a cheap specialist, and keep broad repo context, tool use, and product judgment on a stronger agent. ## When to Use This Based on the paper and HN discussion, VibeThinker-3B makes sense for: **Competitive programming problems** - The 96.1% LeetCode acceptance rate is real, and the model runs fast enough for interactive use. **Math verification** - AIME-level competition math, equation solving, and formal verification tasks where the problem is self-contained. **Code security review** - As one commenter demonstrated, it works for single-file security analysis where you do not need external context. **Local inference budgets** - At 3B parameters, it runs on laptop GPUs. You can have a capable reasoning model without API costs. This belongs in the same budget conversation as [DeepSeek V4 for budget coding agents](/blog/deepseek-v4-budget-coding-agents) and [AI affordability pressure for agent costs](/blog/ai-affordability-crisis-agent-costs). The question is not whether a tiny model replaces a frontier model. The question is which slices no longer need one. It does not make sense for: **General assistant tasks** - It traded general knowledge for reasoning capability. Do not ask it about history, current events, or "what is a pelican." **Agentic workflows** - No tool calling means no web search, no file system access, no API calls from the model itself. **Multi-file code understanding** - It is optimized for self-contained problems. Repository-scale reasoning is not its strength. ## The Bigger Question VibeThinker-3B is evidence that the "parameter count equals capability" assumption has caveats. A 3B model can outperform 300B+ models on specific benchmarks - if you accept dramatic tradeoffs in generality. The Parametric Compression-Coverage Hypothesis suggests this is not a fluke. Verifiable reasoning - tasks where you can check the answer programmatically - may compress better than open-ended knowledge. If true, we should expect more specialized small models that excel in narrow domains while failing badly outside them. The practical implication for developers: model selection is becoming task-specific. The best model for coding might be different from the best model for research might be different from the best model for writing. VibeThinker-3B is a data point in that direction. For a broader local-model shortlist, keep [best local coding LLMs in 2026](/blog/best-local-coding-llms-2026) nearby. VibeThinker is not the general winner. It is a reminder that specialist local models are becoming real routing options. ## Frequently Asked Questions ### Does VibeThinker-3B really beat Claude Opus 4.5? On AIME 2026 math competition problems, yes - 94.3% vs lower reported scores for much larger models. On general tasks, no. It traded general knowledge for specialized reasoning capability. ### Can I use it for coding assistance? For self-contained coding problems (competitive programming, algorithm implementation, code review), yes. For repository-scale development with tool calling and context management, no - it lacks tool calling support. ### How does it compare to other small models? At 3B parameters, it competes with Phi-3, Qwen2 3B, and similar. On reasoning benchmarks it dramatically outperforms them. On general knowledge and instruction following, expect comparable or worse performance. ### Is the quantized version good enough? The Q4_K_M version runs at 110 tok/s on an RTX 2070 Super and produces equivalent results on math problems. For reasoning tasks, the quantization appears to preserve capability well. ### Should I use this instead of API models? For batch processing of self-contained math or code problems where you want to avoid API costs, potentially yes. For general development work with tool calling and broad context needs, API models remain more capable. ## Sources - [VibeThinker arXiv paper](https://arxiv.org/abs/2606.16140) - [VibeThinker-3B GGUF on Hugging Face](https://huggingface.co/prithivMLmods/VibeThinker-3B-GGUF) - [Hacker News discussion](https://news.ycombinator.com/item?id=48639240)

Apertus: Europe's Answer to AI Sovereignty - and Why HN Is Skeptical

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 The Swiss AI Initiative just shipped Apertus, a fully open foundation model developed by EPFL, ETH Zurich, and the Swiss National Supercomputing Centre (CSCS). The pitch: complete transparency, EU AI Act compliance, and training data you can actually inspect. The Hacker News response has been complicated. Developers like the ambition, but they are asking the same practical question that follows every open model launch: how much capability are you giving up for transparency? ## What Apertus Actually Is Apertus ships in two sizes - 8B and 70B parameters - trained on 15 trillion tokens across 1,000+ languages. The headline differentiator is openness: training data, code, weights, methods, and alignment principles are all documented and reproducible. From the [official site](https://apertus.swiss/): > Fully open model: open weights + open data + full training details including all data and training recipes. The model was trained on CSCS's Alps supercomputer using up to 4,096 GPUs. Swisscom serves as the strategic partner, and you can access it through Hugging Face or the Public AI network. Key claims: - Built to meet EU AI Act requirements - Respects opt-outs and removes PII - Prevents memorization - Competitive with top open models at equivalent scales ## What HN Is Saying The [HN discussion](https://news.ycombinator.com/item?id=48622778) splits into a few camps: ### The "Actually Open" Appreciation The core appeal is scientific reproducibility. Several commenters treated Apertus less as a leaderboard play and more as infrastructure for research: a model where training data, recipes, methods, and weights are visible enough to audit. Several users pointed out that Apertus joins a small club of genuinely open models - alongside Allen AI's OLMo 3.1, MBZUAI's K2 Think V2, and Nvidia's Nemotron (though Nemotron has some proprietary data). ### The Performance Question The most upvoted criticism is simple: is the model actually good? Artificial Analysis now has dedicated pages for [Apertus 8B Instruct](https://artificialanalysis.ai/models/apertus-8b-instruct) and [Apertus 70B Instruct](https://artificialanalysis.ai/models/apertus-70b-instruct), and the takeaway is not flattering on raw intelligence rankings. That does not invalidate the openness story, but it does make the tradeoff explicit: transparency is the product, not frontier capability. The multilingual claims also drew skepticism from hands-on users. The safer read is that broad language coverage is a research and sovereignty win, while practical quality still needs task-by-task evaluation. ### The Training Data Debate This is where things get philosophically interesting. Simon Willison noted that Apertus "uses fineweb, which is derived from Common Crawl, which is an unlicensed scrape of web pages." This prompted a subthread about whether "sovereign AI" can really claim ethical high ground while using web-scale scraped corpora. One side argues public web analysis is legitimate and necessary. The other argues that transparency about scraping does not answer compensation or consent concerns. Apertus is useful here because it makes the debate inspectable instead of hiding it behind a closed training stack. ### The Geopolitical Angle Several comments touched on why European AI independence matters. The argument is straightforward: even if Apertus is not state-of-the-art today, European-controlled AI infrastructure matters for data sovereignty, public-sector procurement, language coverage, and regulatory compliance. ## The Practical Takeaway If you're evaluating Apertus for production use, here's what the evidence suggests: **Strengths:** - Full training transparency - you can audit everything - EU AI Act compliance baked in - No licensing restrictions for commercial use - Multilingual training with underrepresented languages (Swiss German, Romansh) **Weaknesses:** - Performance lags behind Nemotron, DeepSeek, and frontier models - Not ready for agentic use cases according to hands-on reports - Multilingual quality is inconsistent in practice **Best use cases:** - RAG applications where transparency matters more than peak performance - European organizations with strict data sovereignty requirements - Research where reproducibility is the priority That makes Apertus adjacent to the local/open-model lane rather than the frontier-agent lane. If you are choosing models for coding agents, start with [the best local coding LLMs](/blog/best-local-coding-llms-2026), [Cohere North Mini Code](/blog/cohere-north-mini-code-open-weight-coding-model), [GLM-5.2 local deployment](/blog/glm-5-2-local-deployment-unsloth-quantization), or [DeepSeek V4 budget coding agents](/blog/deepseek-v4-budget-coding-agents). If you are choosing models for transparency, auditability, or public-sector sovereignty, Apertus enters the shortlist. ## The Bigger Picture The debate in this thread mirrors a broader tension in AI development: should we prioritize transparency and ethical sourcing even at the cost of capability? Or does "open" only matter if the model is actually competitive? For now, Apertus represents a credible attempt at the transparency-first approach. Whether the capability gap closes depends on continued funding and research. The Swiss AI Initiative has the institutional backing - EPFL and ETH Zurich are serious players - but catching up to labs spending billions requires more than good intentions. If you want a model where you can trace every training decision, Apertus delivers. If you need frontier performance, you're still looking at Nemotron, DeepSeek, or the closed models. The market has room for both. In practice, most teams should treat this as a routing decision: use transparency-first models where auditability matters, and route high-difficulty work to stronger models when quality is the binding constraint. That is the same operational pattern behind [local Qwen as a different tool](/blog/local-qwen-different-tool-not-worse-opus), [VibeThinker small-model routing](/blog/vibethinker-3b-small-model-beats-opus-reasoning), and [AI affordability as cost accounting](/blog/ai-affordability-crisis-agent-costs). ## FAQ ### Is Apertus fully open? It is one of the stronger openness claims in the model market: the project emphasizes open weights, open data documentation, training details, methods, and recipes. That is different from many "open-weight" models where the weights ship but the data and training process remain opaque. ### Is Apertus good enough for production? It depends on the job. The practical evidence points toward transparency-first RAG, public-sector experimentation, multilingual research, and audit-heavy workflows. For frontier coding agents or general high-stakes reasoning, benchmark and hands-on reports suggest stronger models are still ahead. ### Why does Apertus matter if it is not the strongest model? Because sovereignty and reproducibility are product requirements for some teams. A weaker but inspectable model can be more useful than a stronger closed model when procurement, compliance, language coverage, or research reproducibility matters. ### Where can developers try Apertus? Start with the official Apertus site and documentation, then check the Swiss AI organization on Hugging Face. Availability and hosted routes may change, so verify the current model card and license before building around it. ## Sources - [Apertus Official Site](https://apertus.swiss/) - [Apertus Documentation](https://apertus.swiss/pages/documentation/) - [Apertus Get Started](https://apertus.swiss/pages/get-started/) - [Swiss AI on Hugging Face](https://huggingface.co/swiss-ai) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48622778) - [ETH Zurich Press Release](https://ethz.ch/en/news-and-events/eth-news/news/2025/09/press-release-apertus-a-fully-open-transparent-multilingual-language-model.html) - [Artificial Analysis: Apertus 8B Instruct](https://artificialanalysis.ai/models/apertus-8b-instruct) - [Artificial Analysis: Apertus 70B Instruct](https://artificialanalysis.ai/models/apertus-70b-instruct)

Claude Code's Extended Thinking Is a Summary - What That Means for You

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 A [blog post by Patrick McCanna](https://patrickmccanna.net/the-text-in-claude-codes-extended-thinking-output-is-not-authentic/) hit the Hacker News front page yesterday with a discovery that surprised some developers: Claude Code's "extended thinking" output isn't the raw chain-of-thought reasoning. It's a summary. The discussion quickly moved from "scandal" to "wait, this is documented" to "but what does it actually mean for my workflow?" The short version: Anthropic documents the behavior, but developers still need to know what is visible, what is billed, and what counts as an audit trail. ## What McCanna Found McCanna examined session logs stored on disk over a weekend and found only encrypted signatures (around 600 characters) with no readable text. Digging into Anthropic's documentation, he discovered that: 1. Claude encrypts its actual reasoning into signatures that Anthropic controls 2. Users' machines don't receive the decryption key 3. The API returns a summary of reasoning, not the reasoning itself 4. Full thinking output requires an enterprise agreement His analogy: "This is like saving a jpeg as a .bmp and then editing the .bmp and presenting it as a jpeg. The conversion produces data loss." (A few HN commenters pointed out he got the lossy format backwards - JPEG is the lossy one, BMP is lossless - but the point stands.) ## What HN Is Saying The [discussion](https://news.ycombinator.com/item?id=48630535) breaks into several threads: ### "This Isn't News" The most common response: this is documented behavior, not a hidden secret. Commenters also pointed out that major AI labs generally avoid exposing raw reasoning because it can reveal too much about model behavior and can be used for distillation. The useful takeaway is not "Anthropic hid this." It is "visible thinking text is a developer interface, not a forensic transcript." ### The Anti-Distillation Argument Several commenters explained why AI labs hide raw thinking tokens: competitors can train on exposed chain-of-thought to replicate results. There's even an open acknowledgment that this already happens with whatever output is available - someone shared a [Hugging Face model](https://huggingface.co/Jackrong/Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled) fine-tuned on Opus "thinking" tokens. ### The Practical Impact For working developers, the key question is: does this matter for your workflow? A critical detail from the docs and discussion: the readable summary is for human consumption. The underlying thinking blocks are represented by opaque signatures when passed back to the API. And crucially: you're billed for the full thinking tokens, not the summary. ### The Workaround If you want more explicit reasoning text without encrypted summaries, you can go old-school and ask the model to reason in ordinary output: Example prompt structure: ``` Before providing your answer, think step by step. For example: The user is asking me to... I need to think about the blah blah. First, I should foo the bar, and then... Answer: ``` This bypasses the summarization entirely - but you lose whatever optimization Anthropic has built into their thinking mode. ### The Philosophy Question Some comments went deeper on what "authentic thinking" even means for an LLM. Research has shown that the text a model produces in its "reasoning" may not accurately reflect the actual activation patterns happening internally. So even "raw" thinking tokens might not be the ground truth. ## What Changed in the Current Docs Anthropic's current docs make three practical points worth separating: - The Messages API can return a **summary** of the full thinking process. - The encrypted `signature` field is opaque and should not be parsed. - You are billed for the full generated thinking tokens, not just the visible summary. The newer model defaults also matter. Some models default to visible summaries, while newer models can default to `display: "omitted"`, where the visible thinking field is empty and only the signature remains. Separately, Anthropic now recommends adaptive thinking and effort controls for newer models rather than old manual `budget_tokens` patterns. For teams watching spend, this connects directly to [Claude Code usage limits](/blog/claude-code-usage-limits-playbook-2026), [Claude token burn observability](/blog/claude-code-token-burn-cache-observability), and [what a fleet of Claude agents actually costs](/blog/what-parallel-claude-agents-actually-cost). Visible text is not the cost surface. Token accounting is. ## The Encryption Angle Matthew Green's cryptography writeup adds a separate lesson: encrypted reasoning blobs are not just hidden text. They are active protocol objects that can affect later model behavior when replayed. His experiments around replay and side channels are a reminder that "encrypted" does not mean "irrelevant to application security." For application builders, the conservative rule is simple: do not parse, modify, log, or treat thinking signatures as user-readable audit evidence. Treat them as provider-controlled protocol state. If your product needs an audit trail, record prompts, tool calls, approvals, files changed, diffs, and final answers. Do not promise an audit trail of the model's private reasoning. ## What This Means for Your Workflow **If you're debugging agent behavior:** The summary should be sufficient for most prompt engineering. You see the key decision points. But if you need to trace exactly why a model made a specific choice, you're working with compressed information. **If you're measuring performance drift:** McCanna's original concern was tracking changes over time. With summarized output, you're comparing summaries - which may vary even if the underlying reasoning stays consistent. **If you're worried about costs:** You're already paying for the full reasoning. The summary is a presentation convenience, not a cost reduction. **If you care about distillation protection:** This matters more for AI labs than individual developers. But it does mean you can't easily capture and reuse Claude's exact reasoning patterns for your own fine-tuning. **If you need reviewable agent work:** Shift attention away from hidden reasoning and toward receipts: tool calls, diffs, tests, logs, permissions, and human approvals. This is the same discipline behind [long-running agent harnesses](/blog/long-running-agents-need-harnesses), [agent swarms needing receipts](/blog/agent-swarms-need-receipts), and [Claude Code agent teams](/blog/claude-code-agent-teams-subagents-2026). ## The Bigger Picture This situation reveals a tension in the AI tooling space: developers want transparency for debugging and understanding, but AI labs have commercial reasons to obscure how their models work. Anthropic's approach is documented and defensible - you get enough to debug, they protect enough to prevent easy replication. Whether that tradeoff works for you depends on your use case. For most Claude Code users, the summary is fine. For researchers trying to understand model behavior at a deep level, you'll need to look elsewhere - or pay for enterprise access. ## FAQ ### Is Claude Code showing raw chain-of-thought? No. The visible extended-thinking text should be treated as a summary or display layer, not the raw reasoning transcript. ### Are you billed for the summary or the full thinking? Anthropic's docs say billing is based on the full thinking tokens generated internally. The visible summary can be much shorter than the billed output token count. ### Can I use visible thinking as an audit log? Not safely. Use it for debugging and prompt iteration, but build audit trails around prompts, tool calls, files touched, diffs, approvals, and final outputs. ### Can I force the model to show detailed reasoning? You can ask for step-by-step reasoning as ordinary output, but that is different from native extended thinking. It may help debugging, but it loses whatever behavior Anthropic attaches to native thinking mode. ## Sources - [Original Blog Post - Patrick McCanna](https://patrickmccanna.net/the-text-in-claude-codes-extended-thinking-output-is-not-authentic/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48630535) - [Anthropic Extended Thinking Docs](https://docs.claude.com/en/docs/build-with-claude/extended-thinking) - [Anthropic Adaptive Thinking Docs](https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking) - [Anthropic Pricing Docs](https://platform.claude.com/docs/en/about-claude/pricing) - [Claude Extended Thinking Announcement](https://www.anthropic.com/news/visible-extended-thinking) - [Matthew Green: Fooling around with encrypted reasoning blobs](https://blog.cryptographyengineering.com/2026/05/29/fooling-around-with-encrypted-reasoning-blobs/)

Codex CLI Needs Resource Budgets, Not Just Token Budgets

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Codex SQLite WAL issue | [openai/codex#28224](https://github.com/openai/codex/issues/28224) | | Earlier Codex WAL write issue | [openai/codex#17320](https://github.com/openai/codex/issues/17320) | | Codex goals write amplification issue | [openai/codex#27911](https://github.com/openai/codex/issues/27911) | | Unbounded logs_2 WAL issue | [openai/codex#28997](https://github.com/openai/codex/issues/28997) | | Codex troubleshooting docs | [developers.openai.com/codex/app/troubleshooting](https://developers.openai.com/codex/app/troubleshooting) | | Codex changelog | [developers.openai.com/codex/changelog](https://developers.openai.com/codex/changelog) | | Hacker News discussion | [news.ycombinator.com/item?id=48626930](https://news.ycombinator.com/item?id=48626930) | A Codex bug report hit Hacker News this week because it had the kind of number that makes developers stop scrolling: a local SQLite feedback log path that could, by the reporter's estimate, write hundreds of terabytes per year under sustained use. The issue is [openai/codex#28224](https://github.com/openai/codex/issues/28224). The exact number is a community measurement, not an OpenAI postmortem. That distinction matters. But the broader pattern is harder to dismiss because related Codex issues describe excessive `logs_2.sqlite-wal` growth, heavy local I/O, idle process churn, and desktop startup failures when local log databases grow too large. This is not really a SQLite story. It is a local-agent operations story. We already talk about token budgets. We write about [Claude Code token burn](/blog/claude-code-token-burn-cache-observability), [agent FinOps](/blog/400-dollar-overnight-bill-agent-finops), and [AI coding review queues](/blog/ai-coding-agents-review-queues) because model calls are visible enough to become product complaints. But agent CLIs also spend disk, CPU, file descriptors, terminal sessions, background processes, log volume, and human trust. **Last updated:** June 22, 2026 ## The Take Agent CLIs need resource budgets as first-class product features. Not only: - how many tokens did this run spend? - how many credits are left? - how many model calls did the agent make? Also: - how much disk did the agent write? - how large are its local databases and WAL files? - how many background processes are still alive? - how much I/O is happening while the app is idle? - when will logs rotate, compact, or checkpoint? - what command cleans up safely? The local runtime is part of the product. If the local runtime can fill a disk, stall a workstation, or quietly chew through SSD endurance, that needs the same engineering attention as a flaky model response. ## What Actually Appears To Be Happening The public reports point at Codex's local SQLite-backed state and diagnostic logging. In [issue #28224](https://github.com/openai/codex/issues/28224), the reporter describes high write amplification from Codex feedback logs. In [issue #17320](https://github.com/openai/codex/issues/17320), another report says streaming responses caused sustained writes to `~/.codex/logs_2.sqlite-wal`, with observed rates in the MiB-per-second range. In [issue #28997](https://github.com/openai/codex/issues/28997), the report narrows the symptom to unbounded `logs_2.sqlite-wal` growth under default-style state behavior. There are adjacent reports too: [#27911](https://github.com/openai/codex/issues/27911) describes write amplification around `goals_1.sqlite`, [#22444](https://github.com/openai/codex/issues/22444) says deleting a WAL file did not immediately free disk because older suspended Codex processes still held deleted file descriptors open, and [#20563](https://github.com/openai/codex/issues/20563) frames idle I/O as SQLite WAL churn rather than plain log appending. That does not prove one root cause. It does prove a shape: ```text local agent process -> high-frequency state or trace writes -> SQLite database -> WAL growth or checkpoint pressure -> disk usage, I/O stalls, startup failures, or manual cleanup ``` The bug might be a logging-level problem. It might be checkpoint behavior. It might be multiple processes holding files open. It might be trace volume that made sense during early debugging and stopped making sense once Codex became a daily driver. The public thread does not need to settle that for the lesson to be useful. ## The Opposing Take Is Fair The obvious pushback is: this is a bug, not a category lesson. That is partly true. OpenAI can fix the specific Codex behavior. SQLite WAL is not inherently bad. Write-ahead logging is a normal durability design. Local apps have used SQLite successfully for years. A scary write-rate estimate in a GitHub issue should not turn into "SQLite is broken" or "Codex will destroy your SSD." The better critique is narrower: local agent products need bounded failure modes. If a diagnostic sink goes noisy, it should rotate. If a WAL grows, it should checkpoint or alert. If deleted files are held open by suspended processes, the app should surface that. If background agents are still running, the user should be able to see and stop them. If telemetry is high volume by design, the product should explain the retention policy and disk budget. That is why this belongs next to the [permissions, logs, and rollback loop](/blog/permissions-logs-rollback-ai-coding-agents). Logs are only helpful when they are designed as operational receipts. When logs become unbounded side effects, they stop being observability and become another production incident. ## The Local Agent Runtime Has More Budgets Than Tokens Token spend is easy to talk about because it maps to money. Disk and I/O budgets are easier to ignore because they feel like local machine details. That separation breaks once agents run for hours. A serious local coding agent now has: | Resource | Failure Mode | What The User Needs | |---|---|---| | Tokens | quota exhaustion, surprise bills | per-run spend, cached vs uncached input, stop caps | | Disk | log growth, state bloat, failed startup | path, size, retention, cleanup command | | I/O | laptop stalls, SSD wear, battery drain | write rate, idle writes, hot files | | Processes | orphaned agents, stuck file descriptors | process list, run owner, stop button | | Network | runaway browsing, repeated API calls | domain log, request budget, retry caps | | CI | queue floods, flaky reruns | job budget, run ledger, merge gate | | Human review | PR backlog, ambiguous diffs | receipts, scope summary, rollback path | The [Codex changelog](/blog/codex-changelog-june-2026) shows how quickly the product surface has expanded: browser use, hooks, automations, mobile review, Computer Use, and Sites. That is useful product velocity. It also means Codex is no longer just a command that exits. It is a local runtime with state. Local runtimes need runtime controls. ## What I Would Add To Every Agent CLI The minimum viable fix is not a beautiful dashboard. It is a boring `doctor` command that tells the truth. ```bash agent doctor resources ``` It should report: ```text state directory: ~/.codex database files: 842 MB wal files: 1.7 GB largest hot file: logs_2.sqlite-wal current write rate: 0.0 MB/s idle, 3.2 MB/s active active agent processes: 2 deleted files still held open: 0 log retention: 7 days or 2 GB last checkpoint: 2026-06-22 14:12 safe cleanup: agent doctor resources --compact ``` Then add hard limits: ```toml [resources] max_log_bytes = "2gb" max_wal_bytes = "512mb" max_idle_write_rate = "1mb/min" max_background_processes = 4 warn_at_disk_free = "10gb" ``` And wire those limits into the agent loop: - warn before a run starts if local state is already unhealthy - stop optional telemetry before it can fill the disk - rotate logs by default - checkpoint SQLite WAL files intentionally - expose a safe compaction command - include local resource stats in bug reports - show a run-level receipt when an agent exits This is the same argument behind [long-running agent harnesses](/blog/long-running-agents-need-harnesses). A harness is not just "keep trying until green." A harness owns the budget envelope around the work. ## What Developers Should Do Today Until agent CLIs expose better resource controls, treat local agent state like build artifacts: useful, inspectable, and disposable only when you understand what you are deleting. Practical steps: 1. Know where your agent stores state. For Codex, current reports point at `~/.codex`, but verify on your machine and platform. 2. Check disk usage before and after long runs. 3. Fully quit the app before deleting SQLite or WAL files, especially if disk does not free immediately. 4. Use Activity Monitor, `lsof`, or platform equivalents when disk appears full after deleting logs. 5. Keep Codex updated and read the changelog before assuming an old workaround is still valid. 6. Avoid leaving many suspended local agent sessions open indefinitely. 7. File bug reports with version, platform, active processes, file sizes, write rate, and reproduction steps. The goal is not to babysit every CLI. The goal is to make abnormal resource use visible enough that you can stop it before it becomes a machine problem. ## The Bigger Product Lesson The agent tools that win will not only generate better code. They will make their side effects legible. That includes: - model calls - file edits - shell commands - browser sessions - local state - logs - background processes - CI jobs - review load This is why [terminal agents need a portable runtime surface](/blog/terminal-agents-portable-runtime-surface). Once a terminal agent becomes a persistent work environment, it needs the boring controls that mature runtimes have: health checks, limits, rotation, compaction, and receipts. Codex is moving fast. That is good. The point of writing about this bug is not to dunk on the product. It is to name the next layer of maturity for every coding agent, Codex included. Token budgets were the first obvious meter. Resource budgets are next. ## FAQ ### Is the Codex SQLite WAL issue confirmed by OpenAI? The public GitHub issues are open user reports, not an OpenAI postmortem. The reports are still useful because several independent issues describe related local SQLite, WAL, disk-growth, and I/O symptoms. ### Does this mean SQLite is a bad choice for agent logs? No. SQLite is a reasonable local-state store. The issue is not SQLite itself; it is unbounded write volume, WAL growth, checkpoint behavior, process lifecycle, and missing user-facing resource controls. ### Should I delete `~/.codex/logs_2.sqlite-wal`? Do not blindly delete live SQLite or WAL files while Codex processes are running. Fully quit Codex first, verify no related processes are holding file descriptors, and prefer an official cleanup or compaction command when available. ### What should agent CLIs expose for disk usage? At minimum: state directory, database size, WAL size, current write rate, active process count, log retention policy, last checkpoint time, and a safe cleanup command. ### Why does this matter if token cost is the main agent budget? Token cost is only one budget. Long-running local agents also consume disk, CPU, I/O, battery, network calls, CI capacity, and human review time. Serious agent workflows need visibility across all of them. ## Sources - GitHub: [Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance](https://github.com/openai/codex/issues/28224) - Hacker News: [Discussion of the Codex SQLite feedback log issue](https://news.ycombinator.com/item?id=48626930) - GitHub: [Excessive SQLite WAL writes during streaming due to TRACE logs](https://github.com/openai/codex/issues/17320) - GitHub: [`goals_1.sqlite` write amplification on long-running sessions](https://github.com/openai/codex/issues/27911) - GitHub: [`logs_2.sqlite-wal` grows without bound into tens of GB](https://github.com/openai/codex/issues/28997) - GitHub: [`logs_2.sqlite-wal` grows indefinitely and remains allocated after deletion](https://github.com/openai/codex/issues/22444) - GitHub: [Heavy I/O activity from idle Codex processes](https://github.com/openai/codex/issues/20563) - OpenAI Developers: [Codex app troubleshooting](https://developers.openai.com/codex/app/troubleshooting) - OpenAI Developers: [Codex changelog](https://developers.openai.com/codex/changelog)

Codex Logging Bug Can Write Terabytes to Your SSD

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 OpenAI's Codex CLI hit a useful local-agent operations lesson: a persistent SQLite feedback log was writing excessive diagnostic data, with one public report extrapolating the churn to hundreds of terabytes of SSD writes per year. The original [GitHub issue](https://github.com/openai/codex/issues/28224) is still reported as open by GitHub's API at verification time, but OpenAI has merged three related fixes and shipped the first two in Codex `0.142.0`. That changes the framing. This is no longer just "check your SSD right now." It is a case study in what happens when a global TRACE default meets a local database, and why coding agents need explicit resource budgets. If you run Codex heavily, update first, then check whether old log files still need cleanup. ## The Bug Codex continuously writes trace-level logs to `~/.codex/logs_2.sqlite` and its associated WAL/SHM files. The logging is indiscriminate - it captures everything from low-value dependency logs (inotify events, locale lookups) to raw websocket payloads and OpenTelemetry diagnostic events. **By the numbers:** - Extrapolated write rate: ~640 TB/year - One user reported ~37 TB written after 21 days of uptime - TRACE-level logs account for approximately 71% of retained log bytes The problem is compounded by write amplification in the SQLite database. Users report approximately 36,211 rows inserted per 15 seconds while the retained row count remains static - a continuous insert-and-prune cycle that multiplies actual disk writes. A 1 TB SSD with 600 TBW (terabytes written) endurance rating could theoretically be worn out in less than a year of continuous Codex usage. ## What Changed Since Publication The issue now has a better ending than the first version of this post suggested. OpenAI engineer `jif-oai` merged three PRs: - [#29432](https://github.com/openai/codex/pull/29432) stopped logging every Responses WebSocket event. - [#29457](https://github.com/openai/codex/pull/29457) filtered noisy persistent-log targets and duplicated telemetry records. - [#29599](https://github.com/openai/codex/pull/29599) added a follow-up filter for bridged dependency log events that still reached SQLite. The [Codex `0.142.0` release notes](https://github.com/openai/codex/releases/tag/rust-v0.142.0) explicitly mention reduced persistent-log churn from the first two fixes. The third fix merged into `main` and is marked by the issue reporter as targeting `0.143.0`; an alpha tag for `0.143.0` was already published on June 24, 2026. The reporter updated the issue body saying those three PRs avoided about 85% of logs in their own Codex measurement. That is still a user-side measurement, not a formal benchmark, but it is enough to change the recommendation: upgrade before applying heavier workarounds. ## Root Cause The SQLite feedback log sink used a broad TRACE-level persistence path. This meant high-volume log targets could write to disk even when their diagnostic value was low. The merged fixes did not remove logging entirely. They narrowed what gets persisted: raw WebSocket payload events, mirrored telemetry records, and bridged dependency TRACE events no longer belong in the durable SQLite sink. That is the important design lesson for local agent tools. Telemetry is useful, but persistence needs a budget. Local logs should have level filters, target filters, retention limits, and a clear difference between interactive debugging and always-on background storage. ## What HN is Saying The [Hacker News thread](https://news.ycombinator.com/item?id=48626930) is running hot. A few representative comments: **On quality:** > "Codex is one of the most infamous examples of slopware. Just having the window unhidden on my mac will cause it to use 100% of the GPU displaying the spinner message." > "I don't understand how Codex can blunder so badly. I imagine that even if they would be using vibe-coding, surely they must have some good engineers." **On OpenAI's response:** > "Shocking. Been open a week and AFAICT just silence from OpenAI. I just find it baffling. You'd think that these vendors would be very sensitive to this sort of issue." > "SQLite + unbounded TRACE logs = firehose in a bathtub. No rotation, no cap, no surprise. The RAISE(IGNORE) fix patches a design flaw. OpenAI's silence is worse than the bug." **Defending the nuance:** > "This thread will become a typical 'haha slop company made slop' but I've been bitten by a bug exactly like this before in a (pre-AI, artisan) OSS project." Fair point. Shipping trace logging to production is a classic blunder that predates AI coding tools by decades. The difference is the volume - modern SSDs are fast enough that the app remains usable while silently burning through drive endurance. **On AI tool quality generally:** > "I want to like codex, but the quality is just not very good, especially when compared to Claude." > "OpenAI really snatched defeat from the jaws of victory late last year when Claude Code was a laggy mess. Nowadays Codex has typing latency out of the gate, whereas Claude Code has the odd pause but generally displays my key presses as... you know... I press them." One commenter noted that Claude Code has similar logging behavior - "writes massive debug logs to ~/.claude/logs" - suggesting the problem may be broader than just Codex. ## What To Do Now If you use Codex regularly, start with the boring path: ```bash codex --version ``` If you are below `0.142.0`, update before assuming the workaround is still necessary. Then inspect the current log footprint: ```bash du -sh ~/.codex ls -lh ~/.codex/logs_2.sqlite* ``` If old log files are still large after upgrading, you have options. **Option 1: Disable logging via SQLite trigger** ```sql sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;" ``` This blocks new log inserts at the database level. Use it as a temporary local workaround, not as the default team recommendation, because it removes useful diagnostics too. **Option 2: Reclaim space with VACUUM** ```bash sqlite3 ~/.codex/logs_2.sqlite "VACUUM;" ``` SQLite uses `VACUUM`, not PostgreSQL-style `VACUUM FULL`. Run it after quitting Codex so the database is not being actively written. **Option 3: Delete the log files** ```bash rm ~/.codex/logs_2.sqlite* ``` The files will be recreated, but you will have bought yourself time. **Option 4: Symlink to tmpfs** For users concerned about SSD wear, symlinking the logs directory to a RAM-backed tmpfs prevents disk writes entirely (at the cost of losing logs on reboot). ## The Bigger Picture This bug is a reminder that even flagship developer tools from major AI labs can ship mundane systems bugs. Excessive logging is not new. What is new is the shape of the runtime: agent CLIs stay open for hours, stream events constantly, and often sit in the background while developers work elsewhere. For teams evaluating AI coding assistants, bugs happen. What matters is whether the tool exposes enough local state to diagnose the problem, whether the vendor responds with targeted fixes, and whether your own workflow has resource guardrails. This is the same reason I keep coming back to [Codex CLI resource budgets](/blog/codex-cli-resource-budgets), [Claude Code token burn observability](/blog/claude-code-token-burn-cache-observability), [permissions and rollback for AI coding agents](/blog/permissions-logs-rollback-ai-coding-agents), [long-running agent harnesses](/blog/long-running-agents-need-harnesses), and [terminal agents as portable runtime surfaces](/blog/terminal-agents-portable-runtime-surface). The better takeaway is not "never trust Codex." It is that local agents need the same operational controls as any other long-running developer service: bounded logs, visible storage use, process lifetime controls, and upgrade discipline. ## FAQ ### Is the Codex SQLite logging bug fixed? Partially, based on public evidence. OpenAI merged three PRs tied to the issue. The first two shipped in Codex `0.142.0`; the third is marked by the reporter as targeting `0.143.0`. At verification time, GitHub's API still reported issue `28224` as open, even though the issue body says the reporter intended to close it after the fixes. ### Should I delete `~/.codex/logs_2.sqlite`? If the file is huge, quit Codex first, upgrade, and then either delete the old SQLite/WAL files or run `sqlite3 ~/.codex/logs_2.sqlite "VACUUM;"`. Deleting old logs may remove diagnostic history, but it is reasonable if the files are consuming disk space. ### Does this mean Codex is unsafe to run? Not categorically. It means Codex, like any long-running local agent, should be monitored. Check version, disk footprint, log churn, and release notes. Teams should treat local agent CLIs as runtime software, not just one-off commands. ### Is this only a Codex problem? No. The pattern is broader: local AI tools can write logs, caches, transcripts, embeddings, and checkpoints while staying open for long sessions. Codex issue `28224` is useful because the public report included concrete measurements and the fixes are visible. ## Sources - [GitHub Issue #28224](https://github.com/openai/codex/issues/28224) - [Codex PR #29432](https://github.com/openai/codex/pull/29432) - [Codex PR #29457](https://github.com/openai/codex/pull/29457) - [Codex PR #29599](https://github.com/openai/codex/pull/29599) - [Codex 0.142.0 release notes](https://github.com/openai/codex/releases/tag/rust-v0.142.0) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48626930)

Deno Desktop Lets You Build Native Apps with TypeScript

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

Deno just shipped [Deno Desktop](https://docs.deno.com/runtime/desktop/), a framework for building cross-platform desktop applications using TypeScript and web technologies. Available in Deno 2.9.0 canary builds, it compiles a Deno project into a native app bundle that includes your code, the Deno runtime, and either a system WebView or a bundled Chromium runtime. **Last updated:** June 24, 2026 The announcement landed on the front page of [Hacker News](https://news.ycombinator.com/item?id=48626137), where the useful debate was not "is web UI good or bad?" It was more practical: if your team already builds in TypeScript, does Deno Desktop give you a cleaner path to local tools than Electron or Tauri? That question matters for AI development work too. A lot of new developer tools are not traditional consumer desktop apps. They are local dashboards, agent workbenches, background runners, prompt inspectors, file-system aware editors, and operator consoles. Those sit close to the territory we have covered in the [TypeScript AI agent stack](/blog/typescript-ai-agent-stack-2026), [portable terminal agents](/blog/terminal-agents-portable-runtime-surface), and [local coding agent workspaces](/blog/local-coding-agent-workspaces-2026). Deno Desktop is interesting because it turns that local TypeScript surface into something you can package. ## What Deno Desktop Actually Does Deno Desktop transforms a Deno project into a redistributable app for macOS, Windows, or Linux. The output includes: - Your application code - The Deno runtime - A rendering backend - Permission choices baked in at compile time - Optional bundled assets and framework output The framework auto-detects popular web frameworks including Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, and Vite SSR projects. If your app runs with `Deno.serve()`, the webview can connect to the local server without you manually wiring a port. The two main rendering paths are: 1. **System WebView** - Uses the operating system's webview, which keeps binaries smaller and looks closer to the Tauri architecture. 2. **Bundled Chromium through CEF** - Ships a consistent browser engine with the app, closer to the Electron tradeoff. The system WebView approach is the lightweight path. The CEF path is the consistency path. That choice is the whole product story in miniature: Deno Desktop is not trying to erase the web-on-desktop tradeoff. It is giving TypeScript teams a first-party Deno version of that tradeoff. ## What Developers Are Debating The HN discussion is useful because it surfaces the real objections teams will have before adopting this. **Web technology is still not a native UI toolkit.** Desktop apps built on webviews often miss platform-specific interaction details, accessibility defaults, keyboard behavior, and system conventions. Deno Desktop does not change that. If the product needs deeply native UI, this is still the wrong lane. **The Tauri comparison is unavoidable.** Tauri already gives teams a system WebView plus a native backend, usually Rust. Deno Desktop's difference is that the backend stays in TypeScript and runs on Deno. That is a real simplification for teams that do not want a Rust sidecar just to ship an internal tool. **The Chromium bundle is not free.** Deno's comparison page lists WebView apps around 40 MB and Chromium-backed apps around 150 MB before your own app code and assets. A later HN commenter reported a much larger local macOS output for a tiny test app, so treat size as something to measure in your own release build, not as a solved marketing number. **Permissions become a release artifact.** Deno's compile reference says permissions granted at compile time are baked into the compiled binary. That fits Deno's security model, but it also means teams should document the permission surface the same way they document environment variables, update channels, and auto-start behavior. ## Why This Fits the AI Tooling Moment Deno Desktop is not only competing for consumer apps. Its better early target may be the growing class of local developer utilities. Think about the tools developers are building around agents: - A local prompt evaluation console that reads a repo and writes reports - A model-router dashboard for switching providers - A file-system aware coding assistant with a packaged UI - A deployment inspector that tails logs and stores local state - A private admin surface for a single team Those workflows already look more like the [agent workspace contracts](/blog/agent-workspaces-need-filesystem-contracts) and [OpenCode-style local agent loops](/blog/opencode-developer-guide-2026) than like polished native apps. They need file access, shell-adjacent capabilities, local storage, predictable packaging, and a UI that developers can iterate on quickly. That is where "TypeScript all the way down" has leverage. You can share validation code, schemas, API clients, model routing utilities, and UI components across the server, browser, and packaged desktop surface. If your team is already evaluating [TypeScript agent frameworks](/blog/vercel-ai-sdk-6-vs-langgraph-typescript-agents), a desktop wrapper becomes another distribution target instead of a separate engineering culture. ## Deno Desktop vs Electron vs Tauri The short version: | Tool | Best fit | Main tradeoff | | --- | --- | --- | | Electron | Mature desktop apps with Chromium consistency and a huge ecosystem | Larger runtime, Node plus Chromium packaging, heavier updates | | Tauri | Smaller apps that can use a system WebView and benefit from a Rust backend | Rust/native bridge complexity for TypeScript-heavy teams | | Deno Desktop | TypeScript-first Deno apps, internal tools, agent workbenches, and local dashboards | Canary status, young ecosystem, real-world bundle sizes still need proof | Electron is still the boring default for serious web-based desktop apps because it is mature, documented, and widely tested. Tauri is still compelling when small binaries and native integration matter. Deno Desktop becomes interesting when the backend logic is already TypeScript, the team likes Deno's permission model, and the app is closer to a developer tool than a consumer-grade native app. ## Technical Notes Worth Checking **Compile path:** The docs show Deno Desktop through `deno compile --desktop`. That means you should read it as part of Deno's compilation story, not as an unrelated desktop framework. **Framework detection:** Deno Desktop can detect several modern web frameworks. This is important because many internal tools begin life as a web app before someone asks for a local packaged version. **Backends:** The docs describe WebView, CEF, and lower-level backend options. For most teams, the decision is WebView for smaller packages or CEF for browser consistency. **Bindings:** Deno's docs frame backend-to-webview communication as bindings rather than a socket-first IPC story. That is promising for local tools that need frequent frontend-to-runtime calls, but it is still early enough that teams should benchmark their actual workload. **Auto-update:** Deno Desktop includes an update system with binary diffs and rollback. That is a serious feature for internal tools because distribution and update reliability are where many "quick desktop app" experiments get painful. ## The Practical Take Deno Desktop is not a reason to rewrite an existing Electron app this week. It is not a reason to abandon Tauri if your team is comfortable with Rust. It is also not production-stable yet. But it is absolutely worth watching if your work sits in this shape: - The product is a developer tool, internal tool, or agent workbench - The team already writes TypeScript and wants to avoid a second backend language - The app needs local file or system access - A web UI is acceptable - Packaging matters more than deep native polish That is a real category. As AI coding tools become more local, more workspace-aware, and more operational, the packaging layer matters again. Deno Desktop gives Deno a credible place in that conversation. ## Getting Started If you want to try it, install the canary release and compile a small app before bringing in a full framework: ```bash deno upgrade canary deno compile --desktop your-app.ts ``` Measure the output size on every platform you care about. Check the permission flags you grant during compilation. Test update behavior before treating this as a production distribution path. ## FAQ ### Is Deno Desktop production ready? Not yet. The current Deno Desktop materials are tied to Deno 2.9.0 canary and pre-stable documentation. It is reasonable to prototype with it now, but critical desktop apps should wait for more stable release notes, migration guidance, and real-world packaging evidence. ### How is Deno Desktop different from Electron? Electron pairs Chromium with Node.js and has a mature desktop ecosystem. Deno Desktop pairs Deno with a rendering backend, using either system WebView or bundled Chromium through CEF. The attraction is a Deno-native TypeScript runtime and Deno's compile and permission model. ### How is Deno Desktop different from Tauri? Tauri usually uses a system WebView with a Rust backend. Deno Desktop can also use a system WebView, but the application logic stays in TypeScript on Deno. That is simpler for TypeScript-heavy teams, while Tauri remains stronger for teams that want a mature Rust-native desktop stack. ### Does Deno Desktop preserve Deno permissions? The compile reference says permissions granted at compile time are baked into the compiled binary. Treat that as part of your release checklist. A packaged desktop app should make its file, network, environment, and subprocess access easy for maintainers to audit. ## Sources - [Deno Desktop documentation](https://docs.deno.com/runtime/desktop/) - [Deno Desktop comparison page](https://docs.deno.com/runtime/desktop/comparison/) - [Deno compile CLI reference](https://docs.deno.com/runtime/reference/cli/compile/) - [Hacker News discussion: Deno Desktop](https://news.ycombinator.com/item?id=48626137)

Microsoft Agent Framework Developer Guide: AutoGen + Semantic Kernel Unified

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

**Last updated:** June 22, 2026 | Official Sources | | |---|---| | [Microsoft Agent Framework Docs](https://learn.microsoft.com/en-us/agent-framework/overview/) | Architecture, installation, agents, workflows | | [Version 1.0 Announcement](https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/) | Release notes, feature summary | | [BUILD 2026 Announcements](https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-at-build-2026-announce/) | Agent harness, hosted agents, CodeAct | | [GitHub Repository](https://github.com/microsoft/agent-framework) | Source code, examples, issues | | [Foundry Agent Service Pricing](https://azure.microsoft.com/en-us/pricing/details/foundry-agent-service/) | Hosted agents billing | ## AutoGen and Semantic Kernel are now one SDK On April 3, 2026, Microsoft shipped Microsoft Agent Framework 1.0 - the production-ready unification of AutoGen and Semantic Kernel into a single SDK. The announcement described it as combining "the enterprise-ready foundations of Semantic Kernel with the innovative orchestrations of AutoGen" into stable APIs with long-term support. This is not a wrapper or compatibility layer. The same teams that built AutoGen and Semantic Kernel built this successor. If you are starting a new agent project in Python or .NET today, Microsoft Agent Framework is the default choice for Microsoft-ecosystem teams. ## What it actually does The framework has two primary capabilities, per the official docs: | Capability | Description | |---|---| | **Agents** | Individual agents that use LLMs to process inputs, call tools and MCP servers, and generate responses. Supports Microsoft Foundry, Anthropic, Azure OpenAI, OpenAI, Ollama, and more. | | **Workflows** | Graph-based workflows that connect agents and functions for multi-step tasks with type-safe routing, checkpointing, and human-in-the-loop support. | The foundational building blocks include model clients (chat completions and responses), agent sessions for state management, context providers for agent memory, middleware for intercepting agent actions, and MCP clients for tool integration. ## Installation Python: ```bash pip install agent-framework ``` .NET: ```bash dotnet add package Microsoft.Agents.AI.Foundry --prerelease ``` The framework does not automatically load `.env` files in Python. Call `load_dotenv()` at the start of your application or set environment variables directly. ## Minimal agent example Python: ```python from agent_framework.foundry import FoundryChatClient from azure.identity import AzureCliCredential credential = AzureCliCredential() client = FoundryChatClient( project_endpoint="https://your-foundry-service.services.ai.azure.com/api/projects/your-foundry-project", model="gpt-5.4-mini", credential=credential, ) agent = client.as_agent( name="HelloAgent", instructions="You are a friendly assistant. Keep your answers brief.", ) result = await agent.run("What is the largest city in France?") print(f"Agent: {result}") ``` .NET: ```csharp using System; using Azure.AI.Projects; using Azure.Identity; using Microsoft.Agents.AI; AIAgent agent = new AIProjectClient( new Uri("https://your-foundry-service.services.ai.azure.com/api/projects/your-foundry-project"), new AzureCliCredential()) .AsAIAgent( model: "gpt-5.4-mini", instructions: "You are a friendly assistant. Keep your answers brief."); Console.WriteLine(await agent.RunAsync("What is the largest city in France?")); ``` From this minimal agent you can add tools, multi-turn conversations, middleware, and workflows to build production applications. ## Core architecture The framework ships with: - **First-party connectors** for Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama - **Agent memory** with multiple backend options: conversational history, persistent key-value state, and vector-based retrieval - **Multi-agent orchestration patterns**: sequential, concurrent, handoff, group chat, and Magentic-One - **Declarative YAML-based** agent and workflow definitions - **A2A (Agent-to-Agent)** and **MCP (Model Context Protocol)** support - **DevUI** for browser-based debugging - **Hosted agent integration** with Microsoft Foundry and Azure Durable Functions The workflow engine uses graph-based composition for multi-step tasks with type-safe routing and checkpointing. This is the part that came from Semantic Kernel's enterprise experience - production agents need explicit control over execution order, not just autonomous tool use. ## When to use agents vs workflows The docs give a clear decision framework: | Use an agent when... | Use a workflow when... | |---|---| | The task is open-ended or conversational | The process has well-defined steps | | You need autonomous tool use and planning | You need explicit control over execution order | | A single LLM call (possibly with tools) suffices | Multiple agents or functions must coordinate | The documentation adds a blunt recommendation: "If you can write a function to handle the task, do that instead of using an AI agent." ## Migrating from AutoGen or Semantic Kernel Both predecessor frameworks are in maintenance mode. Microsoft provides dedicated migration guides: - [Migration Guide from Semantic Kernel](https://learn.microsoft.com/en-us/agent-framework/migration-guide/from-semantic-kernel/) - [Migration Guide from AutoGen](https://learn.microsoft.com/en-us/agent-framework/migration-guide/from-autogen/) The framework includes migration assistants specifically designed to help teams transition. If you are currently on AutoGen, the multi-agent orchestration patterns transfer directly. If you are on Semantic Kernel, the session-based state management, middleware, and telemetry patterns carry over. ## Hosted agents pricing For teams deploying to Azure, hosted agents in Foundry Agent Service bill based on consumption: | Resource | Price | |---|---| | Compute | $0.0994 per vCPU-hour | | Memory | $0.0118 per GiB-hour | | Model inference | Billed separately | | Persistent memory | Billed separately | Billing began April 22, 2026 during preview. The key cost feature: scale to zero. You pay nothing while the agent is idle, and it scales back up on the next request. The framework itself is open source under MIT license. Azure AI Foundry services use standard usage-based Azure pricing. ## Microsoft Agent Framework vs LangGraph vs CrewAI The choice between major agent frameworks depends on your stack and orchestration needs: | Framework | Best for | Language support | Key strength | |---|---|---|---| | Microsoft Agent Framework | .NET and Azure-native teams | Python, .NET | Enterprise features, A2A protocol | | LangGraph | Stateful production workflows | Python, TypeScript | Checkpointing, human-in-the-loop | | CrewAI | Role-based multi-agent demos | Python | Fastest prototype-to-working-demo | **Choose Microsoft Agent Framework when:** - Your team uses .NET - Your team uses Python on Azure - You need A2A protocol support - You want a single SDK that combines single-agent and multi-agent patterns **Choose LangGraph when:** - You need maximum control over agent behavior - Your workflow has complex conditional logic, error recovery, or human-in-the-loop requirements - You are building for production and need monitoring, persistence, and streaming - You are in a regulated environment where auditability matters **Choose CrewAI when:** - Your task naturally decomposes into specialist roles - You want to prototype quickly and iterate on agent design - Your team includes non-engineers who need to understand the agent architecture If you are auditing dependencies in 2026, the safe defaults are LangGraph 0.4+, CrewAI 0.105+, and Microsoft Agent Framework 1.0+. ## BUILD 2026 additions At BUILD 2026 on June 2-3, Microsoft shipped several additions: - **Agent harness**: Skills support and standardized agent lifecycle management - **Hosted agents in Foundry Agent Service**: Long-running agents and routines - **Tracing and evaluation**: Agent optimizer for hosted agents - **CodeAct**: Agent pattern for code execution tasks Sessions covered multi-agent systems, observability, evals, and open-source governance. ## The honest caveats Microsoft Agent Framework is the obvious default for .NET and Azure-native teams. For everyone else, the calculus is less clear. **Self-hosted enterprise support**: The primary deployment path Microsoft offers for enterprise production is through Foundry Agent Service. There is no self-hosted enterprise support without third-party providers. **Ecosystem maturity**: LangGraph has a larger ecosystem of community tools and integrations. CrewAI has broader adoption at Fortune 500 companies for prototyping. Microsoft Agent Framework is newer and the third-party ecosystem is still developing. **Model lock-in**: While the framework supports multiple providers, the Azure integration is deepest with Microsoft Foundry. Teams not on Azure may find the setup overhead higher than alternatives. That said, if you are already in the Microsoft ecosystem, the unified SDK, production-grade features, and direct support from the teams that built AutoGen and Semantic Kernel make this the path of least resistance. ## FAQ ### What is Microsoft Agent Framework? Microsoft Agent Framework is a production-ready SDK for building AI agents and multi-agent workflows in Python and .NET. It is the unified successor to AutoGen and Semantic Kernel, created by the same teams, combining AutoGen's agent abstractions with Semantic Kernel's enterprise features. ### Is Microsoft Agent Framework free? The framework is open source under MIT license. Hosted agents in Foundry Agent Service use consumption-based Azure pricing: $0.0994 per vCPU-hour for compute, $0.0118 per GiB-hour for memory, with model inference and persistent memory billed separately. ### Should I migrate from AutoGen to Microsoft Agent Framework? Yes, if you are starting new work. AutoGen is in maintenance mode. Microsoft provides a dedicated migration guide and assistants to help transition. The multi-agent orchestration patterns transfer directly. ### Should I migrate from Semantic Kernel to Microsoft Agent Framework? Yes, for new agent projects. Semantic Kernel remains supported for existing applications, but new agent-focused work should use Microsoft Agent Framework. Session-based state management, middleware, and telemetry patterns carry over. ### Does Microsoft Agent Framework support MCP? Yes. The framework includes MCP (Model Context Protocol) clients for tool integration, allowing agents to call MCP servers directly. ### Which models does Microsoft Agent Framework support? First-party connectors support Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama. You can also integrate other providers through the extensible model client architecture. ### When should I use LangGraph instead of Microsoft Agent Framework? Use LangGraph when you need maximum control over agent behavior, complex conditional logic, or are in a regulated environment where auditability and deterministic control matter. LangGraph has a larger ecosystem and works well for teams not on Azure. ### When should I use CrewAI instead of Microsoft Agent Framework? Use CrewAI when your task naturally decomposes into specialist roles and you want to prototype quickly. CrewAI is the fastest path from idea to working multi-agent demo, with strong adoption for prototyping at Fortune 500 companies. ## Sources - [Microsoft Agent Framework Overview - Microsoft Learn](https://learn.microsoft.com/en-us/agent-framework/overview/) (accessed June 22, 2026) - [Microsoft Agent Framework Version 1.0 - Microsoft Agent Framework Blog](https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/) (accessed June 22, 2026) - [Microsoft Agent Framework at BUILD 2026 - Microsoft Agent Framework Blog](https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-at-build-2026-announce/) (accessed June 22, 2026) - [microsoft/agent-framework - GitHub](https://github.com/microsoft/agent-framework) (accessed June 22, 2026) - [Foundry Agent Service Pricing - Microsoft Azure](https://azure.microsoft.com/en-us/pricing/details/foundry-agent-service/) (accessed June 22, 2026) - [AI Agent Frameworks Compared - PE Collective](https://pecollective.com/blog/ai-agent-frameworks-compared/) (accessed June 22, 2026)

Oak: A New Version Control System Built for AI Agents

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

Oak is a new version-control system positioning itself as infrastructure for AI coding agents. Its homepage calls it an "agentic substrate" for software development: a storage and version-control layer where autonomous coding agents can mount large repositories, branch per task, snapshot quickly, and work beside humans. **Last updated:** June 24, 2026 The project landed on Hacker News as [Show HN: Oak - Git alternative designed for agents](https://news.ycombinator.com/item?id=48631726), where the useful debate was not "can anything replace Git?" It was more specific: do agentic workflows need a different version-control interface than human-first Git? That question connects directly to themes we keep seeing in [local coding agent workspaces](/blog/local-coding-agent-workspaces-2026), [parallel coding agent merge discipline](/blog/parallel-coding-agents-merge-discipline), and [agent workspace filesystem contracts](/blog/agent-workspaces-need-filesystem-contracts). When agents work in parallel, the VCS stops being only history storage. It becomes coordination infrastructure. ## What Oak Is Trying To Change Oak argues that Git's full-clone, history-rich model is not always the right default for coding agents. The Oak pitch has a few parts: - Mount large repositories without a full local clone. - Give each task or agent a lightweight branch. - Keep a server-side source of truth. - Snapshot faster than Git on the workflows Oak cares about. - Reduce VCS-related context overhead for agents. - Export to Git when interoperability matters. The key idea is virtual mounting. Instead of forcing every agent process to clone the full repository and history before doing useful work, Oak gives the agent a working view it can operate on quickly. That is a real problem. Git worktrees help, but managing many concurrent agent branches still gets messy. We have covered this from the Git side in the [Git worktrees and Claude Code guide](/blog/git-worktrees-claude-code-parallel-agents-guide). Oak is asking whether the model should be redesigned around this workflow instead of adapted after the fact. ## What Oak Claims Oak's current homepage describes itself as the version-control and storage layer for autonomous coding agents. Its meta description claims agents can mount large repos without a full clone, branch per task, and snapshot up to 95% faster than Git. I would treat those as project-published claims until there is a reproducible benchmark suite and broader third-party testing. The claim is interesting, but not yet the same thing as proven general performance. The safer interpretation is: - Oak is optimizing for fast agent startup and task isolation. - It is not trying to preserve every Git workflow as-is. - Its Git export story is important because teams still need interoperability. - The value will depend on agent workload shape, repo size, server latency, and review flow. That framing is more useful than treating Oak as a drop-in Git replacement. ## The HN Pushback The HN discussion surfaced three recurring objections. First, several developers compared Oak to [Jujutsu](https://github.com/jj-vcs/jj). Jujutsu is not an agent-specific VCS, but it does address many Git UX problems while remaining Git-compatible. At the time of this refresh, the `jj-vcs/jj` GitHub repo has roughly 29.8k stars and an Apache-2.0 license. Second, commenters questioned whether the agent problem belongs in version control or in agent tooling. If an agent wraps Git poorly, a new VCS may not be the right fix. Better prompts, safer command wrappers, branch naming, worktree discipline, and review automation can solve a lot. Third, people asked for concrete comparisons. Oak is early. It needs examples where the same multi-agent task is materially better in Oak than in Git plus worktrees, Jujutsu, or Sapling. Those objections are fair. "Designed for agents" is not enough by itself. The tool has to make the agent loop safer, cheaper, or easier to review. ## Why The Idea Still Matters The core Oak question is valid: what should version control look like when software changes are produced by many semi-autonomous workers? Human Git workflows assume: - A developer intentionally stages changes. - A branch has a human narrative. - Commit messages are written after understanding the work. - Review happens at human speed. - The local checkout is a durable workspace. Agent workflows often look different: - Many tasks start speculatively. - Branches are short-lived. - Workspaces are disposable. - The agent may need only part of the repo. - The review artifact matters more than the local clone. - Rollback and traceability matter more than preserving every intermediate thought. That is why VCS design is back on the table. It is also why [Epic's Lore VCS](/blog/epic-games-lore-version-control-system), Zed's DeltaDB work, Jujutsu, Sapling, and Oak are all worth watching even if Git remains the default. ## Where Oak Could Fit Oak is most interesting for teams building agent platforms, not for teams looking to migrate their main repository tomorrow. Potential fits: - Agent sandboxes that need cheap per-task branches. - Large repos where full clone startup dominates. - CI-like agent workers that produce reviewable patches. - Hosted coding-agent platforms that need storage isolation. - Internal tools where Git export is enough for final handoff. Less compelling fits: - Small repos where Git startup is trivial. - Teams that need every Git hosting feature today. - Regulated teams that rely on mature Git audit tooling. - Workflows where developers already use Jujutsu or Sapling effectively. The practical question is not "is Oak better than Git?" It is "does Oak make agent task isolation and review cheaper enough to justify a new VCS surface?" ## The Review Layer Is The Hard Part Version control for agents is not only about storage. It is also about review. Agents need: - Clear file ownership boundaries. - Safe rollback. - Durable logs. - Human-readable diffs. - Branch-to-task traceability. - A way to prevent parallel agents from silently overwriting each other. Those are the same problems behind [permissions, logs, and rollback for AI coding agents](/blog/permissions-logs-rollback-ai-coding-agents), [agent PR governance](/blog/agent-pr-governance-github-copilot-review), and merge discipline for parallel agents. If Oak helps with those, it becomes more than a faster checkout. If it only makes clone-like operations faster, it will have to compete against a lot of Git-adjacent tooling. ## The Takeaway Oak is early, but it is asking the right systems question. Agent workflows put pressure on assumptions that Git made for human developers in 2005. I would not migrate production work to Oak today just because it says "agents." I would watch it if you are building agent infrastructure, especially anything involving many short-lived workspaces or hosted coding-agent execution. Git is still the safe default. Jujutsu is the practical Git-compatible experiment to try now. Oak is the more speculative bet: version control redesigned around agents from the start. ## FAQ ### What is Oak? Oak is a version-control and storage system designed around AI coding-agent workflows. It focuses on virtual mounts, per-task branching, fast snapshots, and Git export rather than copying the full Git model. ### Is Oak a Git replacement? Not for most teams today. Oak is early and more interesting as an agent-infrastructure experiment than as a production Git replacement. Git, often with worktrees or Jujutsu, remains the safer default. ### How is Oak different from Jujutsu? Jujutsu is a Git-compatible VCS frontend with a different user model and strong local workflow ergonomics. Oak is positioning itself as a server-backed version-control and storage substrate for agents, with virtual mounts and agent task isolation as core ideas. ### Should agent teams care about version control? Yes. Parallel agents need branch isolation, rollback, logs, review artifacts, and conflict handling. Whether the answer is Git worktrees, Jujutsu, Oak, or a hosted agent platform, version control becomes part of the agent safety layer. ## Sources - [Oak project page](https://oak.space/oak/oak) - [Oak homepage](https://oak.space) - [Oak documentation](https://oak.space/docs) - [Oak blog](https://oak.space/blog#git-is-forever) - [Hacker News discussion: Show HN Oak](https://news.ycombinator.com/item?id=48631726) - [Jujutsu GitHub repository](https://github.com/jj-vcs/jj)

Prompt Injection is Role Confusion - New ICML Research Explains Why LLMs Can't Tell Friend from Foe

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 A new paper from MIT researchers Charles Ye, Jasmine Cui, and Dylan Hadfield-Menell presents a compelling theory for why prompt injection attacks remain so effective against modern LLMs: the models don't actually understand role boundaries - they just recognize writing styles. The research, titled "Prompt Injection as Role Confusion" and accepted at ICML 2026, demonstrates that LLMs perceive the source of text from how it sounds, not from any explicit labeling. To the model, sounding like a role is indistinguishable from being that role. ## The Core Finding: Style Overrides Tags The researchers developed what they call "role probes" - linear classifiers that measure how strongly an LLM internally perceives each token as belonging to specific roles (system, user, tool, think, assistant). Their key discovery: when you remove all role tags from a conversation and just leave the text, the model's internal perception of roles barely changes. The `` tags that wrap chain-of-thought reasoning aren't what makes the model treat text as internal thinking - it's the reasoning style itself. As the paper puts it: "former-think tokens (still orange) register high CoTness, virtually unchanged" even when all tags were removed. The style alone triggers role perception. This means that everything arrives through the same channel as "one long token soup." Tags attempt discrete control, but models learn continuous role signals from content style. ## CoT Forgery: A 60% Success Rate Attack Armed with this insight, the researchers developed "CoT Forgery" - a technique where attackers inject fake chain-of-thought reasoning into user messages or tool outputs. The attack exploits the fact that "think text gets a kind of blanket trust" from the model. By writing text that sounds like internal reasoning - using phrases like "Let me analyze this step by step..." or "The user is asking... policy states..." - attackers can hijack the model's decision-making. The results are striking: - **60% attack success rate** on jailbreak benchmarks using CoT Forgery - **Near-zero baseline** without the technique - **Human red-teamers** achieved near-100% success against frontier models in late 2025 When the researchers "destyled" the fake reasoning - replacing characteristic phrases with neutral language - success dropped from 61% to 10%. The style matters more than the content. ## What HN is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48631888) has been active, with several useful threads emerging. Many commenters treated the paper as a formal explanation for something practitioners already feel: today, most LLM applications still pass trusted instructions and untrusted content through one blended context window. That makes the "control plane" and "data plane" too easy to confuse. Others compared prompt injection to social engineering. The attacker does not need actual authority if they can imitate the language of authority closely enough. That maps directly onto the paper's point about role perception: style can impersonate identity. A significant thread explored potential solutions. One suggestion was to embed role identity into tokens themselves - adding role-specific embeddings to each token so the model has an "unambiguous, unspoofable tag." However, this would require retraining from scratch with role-labeled data. The security implications are less tidy. "Sanitize the input" is easy advice when the system has a grammar like SQL. It is much harder when the model's job is to interpret natural language, summarize arbitrary content, and decide which instructions matter. That is why prompt injection keeps showing up in [agent app security](/blog/prompt-injection-agent-apps-practical-version), [banking memo attacks](/blog/ai-agent-prompt-injection-banking), and [Codex cloud security planning](/blog/openai-codex-cloud-security-playbook-2026). ## Why This Matters for Production Systems The paper identifies two contrasting defensive approaches: 1. **Attack Memorization** - Models learn to recognize common injection patterns from training data. This is brittle because it fails against adaptive human attackers who vary their phrasing. 2. **Role Perception** - Models correctly identify commands as tool/external data and ignore embedded instructions regardless of phrasing. This would be robust, but current LLMs cannot perceive roles accurately. The researchers note that some frontier models have improved through what they call "distrust of reasoning" - essentially training the model to doubt text that sounds like chain-of-thought but appears in unexpected places. But this creates a problematic dynamic: models learn to doubt genuine cognition rather than correctly perceiving boundaries. For anyone building agentic systems or user-facing LLM applications, the implications are clear: - **Role tags provide no security boundary.** They're formatting hints, not access control. - **Any text that sounds authoritative will be treated as authoritative.** Style trumps structure. - **Static benchmarks underestimate risk.** Human red-teamers adapt; static tests don't. The production move is not to hope for one perfect prompt. Treat role confusion as a systems risk: - Separate untrusted content from tool instructions wherever the platform allows it. - Keep high-impact tools behind explicit permission checks. - Prefer allowlisted tool schemas over free-form command execution. - Log tool calls, external content origins, and approval decisions. - Test against adaptive attacks, not just a fixed jailbreak list. That puts the paper in the same operating lane as [role confusion in agent security](/blog/prompt-injection-role-confusion-agent-security), [agent identity layers](/blog/agent-identity-security-layer-ai-workflows), [security checklists before connecting tools](/blog/agent-security-checklist-before-connecting-tools), [approval fatigue as a security bug](/blog/approval-fatigue-agent-security-bug), and [cybersecurity skills as runtime infrastructure](/blog/cybersecurity-skills-ai-agents-runtime). ## The Path Forward The paper doesn't propose a complete solution, but it does clarify the problem space. If prompt injection is fundamentally about role confusion, then solutions need to address how models perceive identity. Some commenters suggested architectures where role information is embedded at the token level - similar to how positional embeddings encode sequence information. Others pointed to research on "Instructional Segment Embedding" that adds a parallel embedding channel for identity information. Whatever the solution, the paper makes one thing clear: the current approach of wrapping different types of content in different tags and hoping the model respects the boundaries is not working. LLMs are fundamentally different from systems like SQL where you can cleanly isolate trusted and untrusted data. Once trusted and untrusted tokens are blended into the same attention stream, you should assume the boundary is soft unless the model and runtime give you a stronger mechanism. ## FAQ ### What does "prompt injection as role confusion" mean? It means the model can confuse who is speaking. The paper argues that LLMs infer roles from writing style, not only from explicit tags. If attacker-controlled text sounds like system reasoning, tool output, or assistant analysis, the model may treat it as more trusted than it should. ### Do system prompts and role tags prevent prompt injection? No. They help structure the conversation, but they are not security boundaries by themselves. The paper's role-probe experiments suggest that models still infer role identity from content style even when tags are removed. ### What should agent builders do differently? Assume prompt injection is a runtime risk. Keep dangerous tools behind approval gates, preserve provenance for external content, use narrow tool schemas, log decisions, and test with adaptive attacks. Prompt wording is one layer, not the control plane. ### Is prompt injection solved by better filters? Filters help against known patterns, but the paper argues that memorizing attack strings is brittle. The stronger target is accurate role perception or architecture-level separation between trusted instructions and untrusted content. ## Sources - [Prompt Injection as Role Confusion - Project Page](https://role-confusion.github.io) - [Paper on arXiv](https://arxiv.org/abs/2603.12277) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48631888) - [OWASP GenAI: LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) - [OWASP LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)

Fugu Ultra's Frontier Performance Claim, Explained Without the Hype

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [Sakana Fugu release](https://sakana.ai/fugu-release/) | Fugu Ultra launch and benchmark charts | | [Sakana Fugu product page](https://sakana.ai/fugu/) | Architecture, pricing, API, applications | | [Fugu technical report](https://github.com/SakanaAI/fugu) | Benchmark methodology | | [TRINITY paper](https://arxiv.org/abs/2512.04695) | Evolved coordinator research | | [Conductor paper](https://arxiv.org/abs/2512.04388) | RL orchestration research | Sakana Fugu Ultra is one of the more interesting model releases of 2026 because the claim is both bold and easy to misread. Sakana is not saying it trained a single new base model that simply outruns GPT-5.5, Gemini 3.1 Pro, Opus 4.8, Fable 5, and Mythos Preview. It is saying learned orchestration can reach frontier performance by coordinating multiple models through one API. That distinction matters. If the claim holds up under independent testing, the next jump in AI capability may come from better routing, verification, and test-time coordination, not only bigger proprietary training runs. **Last updated:** June 22, 2026. ## The Benchmark Picture Sakana's launch chart places Fugu and Fugu Ultra against frontier baselines across coding, reasoning, science, agentic work, and long-context tasks. ![Sakana Fugu benchmark chart](/images/blog/sakana-fugu-frontier-performance/benchmark-fugu-grid.webp) Source image: [Sakana Fugu release](https://sakana.ai/fugu-release/). The table gives the more concrete numbers. In Sakana's release, Fugu Ultra is reported at: - 73.7 on SWE-bench Pro - 82.1 on TerminalBench 2.1 - 93.2 on LiveCodeBench - 90.8 on LiveCodeBench Pro - 50.0 on Humanity's Last Exam - 86.6 on CharXiv Reasoning - 95.5 on GPQA-D - 93.6 on MRCRv2 ![Sakana Fugu benchmark table](/images/blog/sakana-fugu-frontier-performance/benchmark-table.webp) Source image: [Sakana Fugu release](https://sakana.ai/fugu-release/). Those numbers put Fugu Ultra in the same conversation as the most expensive frontier systems. But there are important footnotes: - Non-Fugu baseline scores are provider-reported. - Fable 5 and Mythos Preview are not publicly accessible and are not in Fugu's agent pool. - Sakana uses the max score where Fable 5 and Mythos Preview both have scores on the same benchmark. - SWE-bench Pro uses mini-swe-agent scaffolding. So the right conclusion is not "case closed." The right conclusion is "this is a serious orchestration result that deserves workload-level evals." ## Why The Result Is Plausible The intuitive argument for Fugu is simple: hard tasks are not one skill. A complex coding task might require: - reading a long issue - finding relevant files - forming a plan - writing a patch - spotting an edge case - running tests - explaining the change One giant model can do all of that. But it may not be the best planner, implementer, critic, and synthesizer at the same time. A routed system can assign those jobs differently. ![Sakana Fugu architecture overview](/images/blog/sakana-fugu-frontier-performance/fugu-architecture.webp) Source image: [Sakana Fugu product page](https://sakana.ai/fugu/). Sakana's research points in exactly that direction. TRINITY assigns Thinker, Worker, and Verifier roles. Conductor learns natural-language coordination strategies through reinforcement learning. Earlier Sakana work on AB-MCTS explores inference-time search and multi-model cooperation. The big idea is test-time scaling. Instead of making the model bigger before inference, spend more coordination and verification compute during inference. ## What Is Novel Three parts stand out. **First, the orchestrator is itself a model.** Fugu is trained to call other LLMs and can call instances of itself recursively. That is different from a static router. **Second, coordination is learned.** The Conductor paper says a 7B model can learn communication topologies and targeted prompts for a worker pool. This is closer to learned project management than provider selection. **Third, the agent pool is swappable.** Sakana's product framing is that Fugu can route around unavailable or restricted providers and incorporate new models as they arrive. Put together, this makes Fugu a bet on AI systems rather than AI models. The intelligence is partly in the base workers and partly in the coordination policy. ## The Benefit For Developers For developers, the value is not philosophical. It is whether you can get better task outcomes with less bespoke infrastructure. Fugu is useful if it lets you avoid building: - your own model router - your own retry policy - your own planner-worker-verifier loop - your own benchmark-specific prompt routing - your own model-fallback logic - your own answer synthesis step The single API matters. Teams already have enough moving parts in agent products. If a model endpoint can hide orchestration complexity and still produce better results, that is a real product improvement. ## The Case Against Solely Proprietary AI The obvious alternative is to pick one top proprietary model and use it everywhere. That is still a reasonable default for small teams. But the risk profile is getting worse: - model access can become regional - prices can move - rate limits can bind - safety policies can change behavior - roadmap changes can deprecate models - frontier performance can rotate between labs Model routing gives teams a way to avoid treating one provider as permanent infrastructure. It also makes open models more valuable. An open model does not need to beat the best closed model at everything if it is the best worker for one common subtask. That is the strongest version of the argument. The future may be less "open model beats closed model" and more "open, closed, local, and specialized models cooperate under a routing policy." ## What Still Needs Proof The main missing piece is independent evaluation. Sakana's benchmark release is detailed, but provider-reported baselines and mixed comparison conditions leave room for uncertainty. The results should be replicated by independent harnesses on real tasks. The second missing piece is routing observability. Teams will want to know: - which model saw which data - why a model was selected - how much each step cost - where failures occurred - whether a compliance opt-out was respected The third missing piece is cost-per-successful-task. A routed model can look expensive per token but cheap per outcome if it solves hard tasks in fewer attempts. It can also look cheap in theory and expensive in practice if it uses too many internal calls. For production teams, the metric is not benchmark score. It is successful task completion per dollar, with latency and governance constraints included. ## A Sensible Evaluation Plan If you want to test Fugu Ultra, do not start with a vibe check. Use a workload sample. 1. Pick 30 to 100 real tasks from your backlog. 2. Split them into simple, medium, and hard. 3. Run your current best model, standard Fugu, and Fugu Ultra. 4. Grade blind where possible. 5. Track wall-clock time, tokens, retries, failure modes, and reviewer edits. 6. Compare cost per accepted answer, not cost per token. The likely result: Fugu Ultra will be most interesting on hard multi-step work and least interesting on fast simple prompts. ## FAQ ### Did Sakana train a new frontier base model? Not in the usual sense. Fugu is presented as a learned orchestration model that coordinates a pool of agents through one API. ### Does Fugu Ultra use Fable 5 or Mythos Preview? Sakana says Fable 5 and Mythos Preview are not in Fugu's agent pool because they are not publicly accessible. They are benchmark comparison points. ### Are the benchmarks independently verified? Not fully. Sakana reports Fugu results directly, while many baseline scores are provider-reported. Independent workload testing is still needed. ### Why is model routing important? Routing lets teams match tasks to model strengths, reduce single-provider dependency, and use test-time coordination for hard tasks instead of relying only on one giant model call. ### Is Fugu Ultra better than direct GPT-5.5 or Claude calls? It may be for complex multi-step tasks. It may not be for latency-sensitive or simple tasks. The right answer depends on cost per successful task in your workload. ### What is the biggest tradeoff? Opacity. A powerful orchestrator can improve outcomes, but it can also make debugging, auditing, and compliance harder if it does not expose enough routing detail. ## Sources - [Sakana Fugu release](https://sakana.ai/fugu-release/) - verified June 22, 2026 - [Sakana Fugu product page](https://sakana.ai/fugu/) - verified June 22, 2026 - [SakanaAI/fugu technical report repository](https://github.com/SakanaAI/fugu) - verified June 22, 2026 - [TRINITY: An Evolved LLM Coordinator](https://arxiv.org/abs/2512.04695) - verified June 22, 2026 - [Learning to Orchestrate Agents in Natural Language with the Conductor](https://arxiv.org/abs/2512.04388) - verified June 22, 2026 - [Sakana AB-MCTS post](https://sakana.ai/ab-mcts/) - verified June 22, 2026 - [Anthropic Fable/Mythos access context](https://www.anthropic.com/news/fable-mythos-access) - verified June 22, 2026

Sakana Fugu and the Case for Not Betting Everything on One Proprietary Model

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [Sakana Fugu release](https://sakana.ai/fugu-release/) | Launch framing and single-vendor dependency argument | | [Sakana Fugu product page](https://sakana.ai/fugu/) | Product behavior, model opt-out, pricing, availability | | [TRINITY paper](https://arxiv.org/abs/2512.04695) | Evolved coordinator approach | | [Conductor paper](https://arxiv.org/abs/2512.04388) | RL-trained orchestration over open and closed agents | | [Anthropic Fable/Mythos access update](https://www.anthropic.com/news/fable-mythos-access) | Context for model access and policy risk | The cleanest way to explain Sakana Fugu is this: it tries to make frontier AI feel less like a single proprietary dependency. That does not mean Fugu is open source. It does not mean the underlying pool is fully open. It means the product's central design bet is routing. Instead of your app calling one model and hoping that provider stays available, affordable, permitted, and best-in-class, Fugu presents one API that can coordinate a swappable pool of models behind it. For engineering teams, that is the interesting part. Model routing is moving from cost hack to architecture strategy. **Last updated:** June 22, 2026. ## The Problem With One-Model Architecture The single-model architecture is easy: 1. Pick the best model. 2. Put it behind your product. 3. Add retries, caching, evals, and observability. 4. Hope nothing material changes. Something always changes. Prices move. context windows change. rate limits change. model behavior changes. access policies change. regional rules change. The model that is best this quarter may be second-best next quarter. Sakana's launch leans directly into that reality. It points to recent model-access disruptions and argues that relying on one company for critical AI capability is a material vulnerability. That is a strong claim, but it is not abstract anymore. Model access is now an architecture risk. ## Fugu's Answer: Orchestration Behind One API Fugu is designed to hide the complexity of a multi-model system behind a single OpenAI-compatible API. ![Sakana Fugu architecture overview](/images/blog/sakana-fugu-open-model-routing/fugu-architecture.webp) Source image: [Sakana Fugu product page](https://sakana.ai/fugu/). The user sends one request. Fugu chooses whether to answer directly or coordinate multiple agents. It can select models, delegate subtasks, verify outputs, and synthesize the final result. Standard Fugu also lets users opt specific agents out of the pool for compliance or privacy requirements. This is a meaningful difference from normal API abstraction. A basic provider gateway swaps one model for another. Fugu is trying to decide how models should collaborate. ## Why Routing Beats Pure Proprietary Dependence The benefit of routing is not ideological. It is practical. **You can move around outages and access changes.** If a provider becomes unavailable, a swappable pool can route elsewhere. A direct integration cannot. **You can match work to capability.** Some tasks need a top reasoning model. Others need cheap summarization, retrieval cleanup, or code formatting. Routing can reserve expensive models for where they matter. **You can improve as the ecosystem improves.** Sakana says Fugu can incorporate newer models over time, including open models and Sakana's own models. If the pool improves, the surface API can improve without each customer rebuilding orchestration logic. **You can separate application logic from model selection.** Your product should not need 40 hand-coded branches for every provider, model, task type, and failure mode. A good routing layer makes the application smaller. ## The Frontier Performance Claim Sakana reports that Fugu Ultra reaches frontier-level performance across coding, reasoning, science, and agentic benchmarks. ![Sakana Fugu benchmark chart](/images/blog/sakana-fugu-open-model-routing/benchmark-fugu-grid.webp) Source image: [Sakana Fugu release](https://sakana.ai/fugu-release/). The detailed benchmark table shows strong results across SWE-bench Pro, TerminalBench 2.1, LiveCodeBench, GPQA-D, Humanity's Last Exam, SciCode, and long-context reasoning. ![Sakana Fugu benchmark table](/images/blog/sakana-fugu-open-model-routing/benchmark-table.webp) Source image: [Sakana Fugu release](https://sakana.ai/fugu-release/). The most honest interpretation is that Fugu makes routing competitive with the direct-frontier path for certain hard tasks. It does not prove routing is always better. The release relies partly on provider-reported baseline scores, and independent third-party evals will matter. But the bar has moved. A routed system no longer looks like a second-tier fallback. It looks like a serious contender for high-end work. ## The Novel Part: Learned Coordination The old way to build this is a hand-authored pipeline: - send planning to Model A - send execution to Model B - send critique to Model C - ask Model A to summarize That works for demos. It gets brittle in production. Sakana's research direction is learned coordination. [TRINITY](https://arxiv.org/abs/2512.04695) evolves a lightweight coordinator that assigns Thinker, Worker, and Verifier roles. [Conductor](https://arxiv.org/abs/2512.04388) trains a 7B coordinator with reinforcement learning to discover communication patterns and instructions for worker models. That matters because the right workflow is task-dependent. A coding benchmark, a literature review, a cyber assessment, and a mechanical design task should not use the same agent topology. ## The Tradeoffs Routing has real costs. **Opacity.** If you cannot see which model handled which part of a request, auditing gets harder. This matters for regulated teams and for debugging quality regressions. **Latency.** Multi-agent systems are slower than direct calls. Fugu exists for tasks where quality matters enough to spend more inference-time compute. **Cost.** Fugu Ultra pricing is frontier-tier for heavy usage. Routing can reduce waste, but orchestration itself burns tokens. **Data governance.** Standard Fugu includes model opt-out. Fugu Ultra is more quality-focused and less configurable. Teams with strict data policies need to check this before sending sensitive work. **New lock-in.** A routing layer can reduce dependence on one model provider while increasing dependence on the orchestrator. That may be a good trade, but it is still a trade. ## A Practical Routing Policy Use a routed system like Fugu when: - the task has multiple phases - correctness matters more than latency - different model strengths are useful - provider resilience matters - you do not want to maintain orchestration yourself Use a direct model call when: - latency matters - the task is simple - the answer is easy to verify - your compliance policy requires known model execution - cost needs to be predictable per request The mature architecture is not "everything through Fugu" or "never use routers." It is a policy: | Workload | Default | |----------|---------| | Autocomplete and chat UI | Fast direct model | | Routine summaries | Cheap direct model | | Code review on important PRs | Routed model or frontier model | | Research synthesis | Routed model | | Security analysis | Routed model with strict scope | | Regulated data | Direct approved model or self-hosted model | ## What This Means for Open Models The open-model ecosystem benefits from routing because open models do not need to win every benchmark to be useful. They need to be excellent at some jobs, cheap enough to call often, and easy to swap into a larger system. That is the deeper point. If AI architecture becomes routed, the winner is not only the single best proprietary model. The winner is the best portfolio: frontier models, open models, small specialists, verifiers, local models, and task-specific tools. That is better for developers. It creates price pressure. It creates deployment options. It makes self-hosting and data residency more realistic. It also forces proprietary labs to compete on reliability and ecosystem fit, not only peak benchmark scores. ## FAQ ### Does Sakana Fugu eliminate vendor lock-in? No. It changes the lock-in shape. You depend less directly on one model provider, but you depend more on Sakana's orchestration layer. ### Is Fugu open source? No. Fugu is a commercial product. The open-model relevance is that it can route across a pool that may include open models, closed models, and future Sakana models. ### Why not just use OpenRouter or LiteLLM? Gateways are useful for provider abstraction. Fugu is aiming at learned multi-agent coordination, not only model selection. For simple routing, a gateway may be enough. ### Is opaque routing a problem? It can be. If you need to prove exactly which model saw which data, opaque routing is a compliance and debugging concern. Standard Fugu's model opt-out helps, but it does not make the system fully transparent. ### When should teams avoid model routing? Avoid it for low-latency UI, simple deterministic tasks, highly regulated data paths, or any workflow where the orchestration overhead costs more than the quality gain. ## Sources - [Sakana Fugu release](https://sakana.ai/fugu-release/) - verified June 22, 2026 - [Sakana Fugu product page](https://sakana.ai/fugu/) - verified June 22, 2026 - [TRINITY: An Evolved LLM Coordinator](https://arxiv.org/abs/2512.04695) - verified June 22, 2026 - [Learning to Orchestrate Agents in Natural Language with the Conductor](https://arxiv.org/abs/2512.04388) - verified June 22, 2026 - [SakanaAI/fugu technical report repository](https://github.com/SakanaAI/fugu) - verified June 22, 2026 - [Anthropic Fable/Mythos access context](https://www.anthropic.com/news/fable-mythos-access) - verified June 22, 2026

Sakana Fugu Ultra: The Model Router Making the Frontier Look Less Proprietary

Developers Digest — Mon, 22 Jun 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [Sakana Fugu release](https://sakana.ai/fugu-release/) | June 22 launch, benchmark framing, product positioning | | [Sakana Fugu product page](https://sakana.ai/fugu/) | Architecture, pricing, API behavior, EU availability | | [Fugu technical report](https://github.com/SakanaAI/fugu) | Methodology and benchmark details | | [TRINITY paper](https://arxiv.org/abs/2512.04695) | Evolved LLM coordinator accepted to ICLR 2026 | | [Conductor paper](https://arxiv.org/abs/2512.04388) | RL-trained natural-language agent orchestration | Sakana AI's latest release is important because it changes the unit of competition. Fugu Ultra is not marketed as a single monolithic model that beats everyone by being bigger. It is a language model trained to coordinate other language models, exposed through one OpenAI-compatible API. That sounds like a wrapper until you look at the details. Fugu decides whether to answer directly, delegate to specialist agents, verify intermediate work, call itself recursively, and synthesize the final answer. The pitch is simple: the next frontier may be less about owning one giant proprietary model and more about learning how to route across many strong models. **Last updated:** June 22, 2026. ## What Sakana Fugu Actually Is Sakana describes Fugu as a multi-agent system delivered as one model. You send one request. Behind the endpoint, Fugu can select models, assign roles, coordinate several steps, and return a single answer. ![Sakana Fugu architecture overview](/images/blog/sakana-fugu-ultra-model-routing/fugu-architecture.webp) Source image: [Sakana Fugu product page](https://sakana.ai/fugu/). The launch has two tiers: | Model | Best fit | Tradeoff | |-------|----------|----------| | Fugu | Everyday coding, code review, chatbots, interactive work | Better latency, lower orchestration depth | | Fugu Ultra | Hard multi-step work like research, cyber analysis, paper reproduction, patent review | Higher quality target, more latency and cost | The standard Fugu tier also lets teams opt specific agents out of the pool for privacy, compliance, or data-governance reasons. Fugu Ultra is positioned differently: maximum answer quality from a deeper pool, with less user control over exactly what participates. ## The Benchmark Claim Sakana's headline claim is that Fugu Ultra stands with models such as Anthropic Fable 5 and Mythos Preview across engineering, scientific, and reasoning benchmarks. The release also compares Fugu and Fugu Ultra against provider-reported scores for Opus 4.8, Gemini 3.1 Pro, and GPT-5.5. ![Sakana Fugu benchmark grid](/images/blog/sakana-fugu-ultra-model-routing/benchmark-fugu-grid.webp) Source image: [Sakana Fugu release](https://sakana.ai/fugu-release/). The detailed table is more useful than the headline. It shows Fugu Ultra ahead on several coding and reasoning benchmarks, including SWE-bench Pro, TerminalBench 2.1, LiveCodeBench, LiveCodeBench Pro, Humanity's Last Exam, and CharXiv Reasoning. Fugu itself leads on some others, including SciCode, tau3 Banking, and long-context reasoning in Sakana's table. ![Sakana Fugu detailed benchmark table](/images/blog/sakana-fugu-ultra-model-routing/benchmark-table.webp) Source image: [Sakana Fugu release](https://sakana.ai/fugu-release/). The caveats matter: - Baseline scores other than Fugu's are provider-reported. - Fable 5 and Mythos Preview are not in Fugu's agent pool because they are not publicly accessible. - The Fable/Mythos comparison uses the higher score where both are available on the same benchmark. - The SWE-bench Pro result uses mini-swe-agent as scaffolding. That does not make the result meaningless. It means the right reading is "Sakana reports frontier-class performance from orchestration" rather than "an independent lab proved Fugu is strictly better than every frontier model." ## Why This Is More Than a Router Most model routing is simple: classify the request, pick the cheapest model likely to work, call it once. Fugu is closer to a learned conductor. Sakana points to two ICLR 2026 papers as the technical base. [TRINITY](https://arxiv.org/abs/2512.04695) uses a lightweight coordinator to assign Thinker, Worker, and Verifier roles across multiple LLMs over several turns. The paper reports that this coordinator can outperform individual models across coding, math, reasoning, and knowledge tasks. [Conductor](https://arxiv.org/abs/2512.04388) goes further. It trains a 7B model with reinforcement learning to discover natural-language coordination strategies among worker models. The paper says the Conductor learns both communication topologies and focused instructions, and can adapt to arbitrary pools of open and closed agents. That is the novel part. Fugu is not just "Claude for planning, GPT for writing, Gemini for checking" hardcoded into a workflow. The claim is that coordination itself is learned. ## The Case for Model Routing The strongest practical reason to care is not novelty. It is operational leverage. **Better cost-performance.** Easy subtasks can go to cheaper or faster models. Hard subtasks can escalate. If the router is good, you get frontier-ish output without paying frontier prices for every token. **Better specialization.** Coding, long-context synthesis, math, visual reasoning, and structured critique are not the same skill. A single model may be good enough at all of them, but a coordinated pool can route around individual weaknesses. **Better resilience.** If one provider changes pricing, policy, availability, or regional access, a swappable pool can degrade more gracefully than a single-model dependency. **Better product ergonomics.** Calling one API while getting multi-agent behavior is cleaner than building and maintaining your own routing harness, eval loop, retry policy, and synthesis layer. This is the same reason agent teams work in software engineering. The win is not that every agent is smarter than the best solo agent. The win is that planning, execution, verification, and synthesis are different jobs. ## The Non-Proprietary Point Sakana frames Fugu as a response to single-vendor dependency. That is partly technical and partly geopolitical. If your application depends on one proprietary frontier model, your product inherits that provider's pricing, outage profile, account policy, export-control exposure, regional availability, and product roadmap. That is a lot of business logic to outsource to one model vendor. Fugu does not eliminate proprietary dependency. It still calls models in an underlying pool, and Sakana does not expose every routing decision. But it changes the dependency shape. Instead of your application being wired directly to one provider, your application is wired to an orchestrator that can swap providers behind the scenes. That is valuable if the orchestrator is trustworthy and observable enough for your use case. It is dangerous if it becomes a new opaque dependency you cannot audit. ## Benefits | Benefit | Why it matters | |---------|----------------| | One OpenAI-compatible API | Easier migration than rebuilding an agent framework | | Learned routing | Potentially better than hand-authored if/else model selection | | Recursive orchestration | More inference-time compute on hard tasks without changing your app | | Provider opt-out in Fugu | Useful for compliance and privacy-sensitive teams | | Frontier-class benchmark claims | Serious enough to evaluate on real workloads | | Swappable agent pool | A hedge against single-provider changes | ## Tradeoffs | Tradeoff | Why it matters | |----------|----------------| | Opaque routing | You may not know which model handled which part of a task | | Latency variance | Multi-step orchestration is slower than a direct call | | Cost variance | Fugu Ultra can be expensive on deep tasks | | Benchmark caveats | Baselines are provider-reported, not all independently reproduced | | EU/EEA unavailability | Sakana says it is working through GDPR and EU-specific regulations | | New single point of failure | The orchestrator can become the dependency you were trying to avoid | ## Who Should Try It Try Fugu Ultra if you already run expensive, long, multi-step work: code review, security analysis, research synthesis, paper reproduction, data-science exploration, benchmark triage, or patent/literature review. Start with standard Fugu if latency matters and the task is interactive. Use Fugu Ultra only where answer quality is worth the response-time and cost premium. Stick with direct model calls when the task is simple, low-risk, latency-sensitive, or easy to verify with deterministic code. Routing overhead is not free. A clean single-model call is still the best architecture for many product surfaces. ## FAQ ### What is Sakana Fugu? Sakana Fugu is a multi-agent orchestration system exposed as one OpenAI-compatible model API. Internally, it can select, coordinate, verify, and synthesize work across an agent pool. ### What is Fugu Ultra? Fugu Ultra is the quality-maximized tier for hard multi-step problems. It coordinates a deeper pool of expert agents and is aimed at research, cybersecurity, paper reproduction, code review, and other demanding workflows. ### Is Fugu Ultra an open model? No. Fugu is a commercial Sakana product. The non-proprietary angle is not that Fugu itself is open-weight. It is that Fugu orchestrates a swappable pool instead of forcing your application to depend directly on one proprietary model provider. ### Does Fugu Ultra beat GPT-5.5 or Claude? Sakana reports higher scores than several provider-reported frontier baselines on multiple benchmarks. Treat that as a serious launch claim, not final truth. Validate it on your own evals before replacing a production model. ### Can I control which models Fugu uses? Standard Fugu lets teams opt specific agents out of the pool for privacy, compliance, or organizational requirements. Fugu Ultra is optimized for maximum quality and gives less control over the full pool. ### Is model routing worth it? It is worth it when tasks are heterogeneous, expensive, or multi-step. It is overkill for simple prompts where one fast model already clears the quality bar. ## Sources - [Sakana Fugu release](https://sakana.ai/fugu-release/) - verified June 22, 2026 - [Sakana Fugu product page](https://sakana.ai/fugu/) - verified June 22, 2026 - [SakanaAI/fugu technical report repository](https://github.com/SakanaAI/fugu) - verified June 22, 2026 - [TRINITY: An Evolved LLM Coordinator](https://arxiv.org/abs/2512.04695) - verified June 22, 2026 - [Learning to Orchestrate Agents in Natural Language with the Conductor](https://arxiv.org/abs/2512.04388) - verified June 22, 2026 - [Sakana AB-MCTS post](https://sakana.ai/ab-mcts/) - verified June 22, 2026 - [Anthropic Fable/Mythos access context](https://www.anthropic.com/news/fable-mythos-access) - verified June 22, 2026

GLM 5.2 in 9 Minutes

Sun, 21 Jun 2026 12:26:35 GMT

GLM 5.2 Explained: Open-Weight Rival to GPT 5.5 + Benchmarks, Pricing, and a Live OpenCode Demo Try GLM 5.2 in OpenCode & Get $5 in Credits: https://opencode.ai/go?ref=M6HEHM4JM5 The video reviews G...

Agentic AI Reliability Is a Systems Problem

Developers Digest — Sun, 21 Jun 2026 00:00:00 GMT

## Official Sources | Source | Link | |--------|------| | Bayer/Thoughtworks case study | [Building Reliable Agentic AI Systems](https://martinfowler.com/articles/reliable-llm-bayer.html) | | Hacker News discussion | [HN discussion with 119 points](https://news.ycombinator.com/item?id=48615680) | | LangSmith evals documentation | [LangSmith Evaluation](https://docs.smith.langchain.com/evaluation) | | OpenAI Evals documentation | [OpenAI Evals](https://platform.openai.com/docs/guides/evals) | | OpenTelemetry semantic conventions | [OpenTelemetry Spec](https://opentelemetry.io/docs/specs/semconv/) | [Martin Fowler's site published a Bayer and Thoughtworks case study on building reliable agentic AI systems](https://martinfowler.com/articles/reliable-llm-bayer.html), and it is more useful than another model-release post because it shows what production reliability actually looks like. The system, PRINCE, is a preclinical research assistant for Bayer. It combines agentic RAG and Text-to-SQL over decades of structured and unstructured research material, including PDF study reports. The interesting part for developers is not the pharma domain. It is the architecture vocabulary: context engineering, harness engineering, transparency, evaluation, monitoring, resilience, and human-in-the-loop review. **Last updated:** June 22, 2026 The post also made the Hacker News front page today with 119 points and 29 comments when I checked, which is a useful signal. Developers are not only asking "which model is best?" anymore. They are asking how to make agents accountable enough to use inside real systems. That is the right question. ## The Takeaway Reliable agentic AI is a systems problem. The PRINCE case study describes a system that evolved from keyword search into a natural-language research assistant. That path matters because the team did not simply drop a chat box on top of documents and call it done. They split the work into stages: clarify the user's intent, plan, retrieve evidence, validate sufficiency, synthesize an answer, expose traceable sources, monitor behavior, and keep humans in the loop for high-consequence work. That maps directly to the pattern we keep seeing in developer tools. A coding agent that edits one file can look magical with a thin prompt. A coding agent that touches auth, migrations, tests, docs, release notes, and production rollout needs a harness. For more on the failure math, see [the agent reliability cliff](/blog/the-agent-reliability-cliff). For the eval side, pair this with [baseline receipts for agent evals](/blog/agent-evals-need-baseline-receipts). The Bayer case study is the same story from an enterprise RAG system instead of a codebase. ## Context Engineering Is the First Reliability Layer The case study frames context engineering as shaping what information each model receives, what it does not receive, and how information moves between specialized steps. That is a better framing than "give the model more context." Long context windows are useful, but they also make it easier to hide stale instructions, irrelevant documents, duplicated chunks, and contradictory history inside the prompt. Agent reliability improves when context is intentionally routed: | Context question | Production version | |---|---| | What does the user mean? | Clarify intent before retrieval or tool use | | What evidence is needed? | Separate planning from retrieval | | What should be excluded? | Keep noisy context out of worker steps | | What evidence was used? | Attach citations, traces, and source receipts | | What changed during the run? | Persist intermediate state outside the model | That is the same reason [agent context reduction](/blog/agent-context-reduction-pattern) keeps becoming more important. The goal is not smaller prompts for their own sake. The goal is a context path you can inspect and debug. If a production agent gives a wrong answer, "the model saw a lot of documents" is not enough. You need to know which documents, why they were selected, which intermediate claim they supported, and where the system decided the evidence was sufficient. ## Reflection Is a Gate, Not a Vibe The PRINCE architecture includes a reflection agent for data validation and sufficiency. That is the part most demo agents skip. Reflection gets weak when it means "ask the model if it feels confident." It gets useful when it has a job: - check whether retrieved evidence actually answers the question; - identify missing studies, documents, tables, or entities; - force a retry when evidence is too thin; - mark uncertainty instead of smoothing it away; - block synthesis when the answer would be overconfident. For coding agents, the equivalent is a review gate between "I edited files" and "ship it." Did tests run? Did the diff touch the intended files? Did the agent change behavior outside the requested surface? Did it preserve user work? Did it leave a receipt a reviewer can trust? That is why [long-running agents need harnesses](/blog/long-running-agents-need-harnesses), not just better prompts. The harness owns state, retries, checkpoints, logs, and stop conditions. The model makes decisions inside that frame. ## Evals Need Realistic Fixtures The Bayer system is grounded in a real enterprise problem: structured metadata, unstructured PDF reports, domain-specific terminology, fragmented systems, and regulatory pressure. That combination is exactly where generic benchmarks stop being useful. The lesson for developer teams is to build realistic fixtures before arguing about model choice. For an agentic RAG product, a realistic fixture might include: - documents with overlapping but not identical claims; - stale metadata that conflicts with source documents; - tables that require entity normalization; - questions that require refusing or asking for clarification; - expected answers with source-level evidence requirements. For a coding agent, the fixture is a fake but realistic repo: auth, billing, migrations, flaky tests, feature flags, partial docs, and a bug that cannot be solved by one grep. This is where [baseline receipts](/blog/agent-evals-need-baseline-receipts) matter. Do not only score the final answer. Compare the candidate run against the current production baseline and keep the trajectory evidence: prompt version, model version, retrieved sources, tool calls, retries, latency, cost, and human review notes. ## Monitoring Is Part of the Product The Fowler article calls out monitoring as part of building trust in a production LLM system. That should be obvious, but agent products still often treat logs as an afterthought. A useful monitoring surface for an agentic system should answer: | Signal | Why it matters | |---|---| | Retrieval coverage | Shows whether the agent is using the right evidence pool | | Reflection failures | Reveals where evidence is insufficient or validation is too strict | | Retry counts | Finds loops before they turn into spend incidents | | Human override rate | Shows where automation is not earning trust | | Citation quality | Separates grounded answers from fluent answers | | Cost and latency by step | Makes reliability tradeoffs visible | This is the production version of the same instinct behind [Claude API reliability and error handling](/blog/claude-api-reliability-error-handling). Resilience is not one retry wrapper. It is a set of signals that tell you when the system is drifting, looping, skipping evidence, or asking humans to clean up too much. ## The Skeptical Read There is a fair opposing view: this is a lot of machinery. If you are building a small internal assistant, do you really need intent clarification, planning, retrieval, reflection, synthesis, evals, monitoring, and a human review loop? Maybe not. Sometimes the right answer is a plain search box, a deterministic workflow, or a normal database report. The practical dividing line is consequence. If the agent's output is low-risk, easy to inspect, and cheap to rerun, keep the system boring. If the output influences regulated work, production code, customer decisions, money movement, security, or medical/legal interpretation, the harness stops being optional. The better criticism is not "agents do not work." It is "agents only work when the surrounding system narrows the task, verifies the evidence, and makes failure visible." That is a useful bar. ## A Developer Checklist Before shipping an agentic workflow, ask these seven questions: 1. What exact context is allowed into each step? 2. Where does intermediate state live outside the model? 3. What evidence must be present before synthesis? 4. Which failures trigger retry, escalation, or stop? 5. What trace does a reviewer see after the run? 6. What baseline does a candidate change have to beat? 7. Which actions always require human approval? If those answers are vague, the system is still a demo. ## FAQ ### What is agentic AI reliability? Agentic AI reliability is the ability of a multi-step AI workflow to produce correct, grounded, reviewable results across real tasks, not just a successful demo. It depends on context routing, tool boundaries, verification, retries, monitoring, and human escalation. ### What is context engineering? Context engineering is the practice of deciding what information a model receives, what it does not receive, and how context moves between steps. It is important because more context can make agents less reliable if the information is noisy, stale, or unauditable. ### Do agentic RAG systems need evals? Yes, if they influence real decisions. Evals should use realistic fixtures, compare candidate changes against a stable baseline, and preserve receipts for retrieved evidence, tool calls, costs, latency, and human review. ### When should a team avoid an agentic architecture? Avoid agentic architecture when a deterministic workflow, search interface, report, or conventional application flow solves the problem with less ambiguity. Use agents when the workflow genuinely requires planning, retrieval, judgment, synthesis, and adaptation. ## Sources - [Building Reliable Agentic AI Systems, Martin Fowler / Thoughtworks / Bayer](https://martinfowler.com/articles/reliable-llm-bayer.html), checked June 21, 2026. - [Hacker News front-page discussion data for the article](https://hn.algolia.com/api/v1/search?tags=front_page), checked June 21, 2026. - [Hacker News item for "Building reliable agentic AI systems"](https://news.ycombinator.com/item?id=48615680), checked June 21, 2026. - [LangSmith evaluation documentation](https://docs.smith.langchain.com/evaluation), checked June 22, 2026. - [OpenAI Evals documentation](https://platform.openai.com/docs/guides/evals), checked June 22, 2026. - [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/), checked June 22, 2026.

AI Coding Agents Move the Bottleneck to Review Queues

Developers Digest — Sun, 21 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [GitHub Copilot coding agent](https://github.blog/changelog/label/copilot/) | GitHub Changelog entries for Copilot agent features | | [Claude Code Overview](https://docs.anthropic.com/en/docs/claude-code/overview) | Anthropic's terminal coding agent documentation | | [OpenAI Codex](https://openai.com/index/openai-codex/) | OpenAI's agent-first coding tool | | [GitHub Actions documentation](https://docs.github.com/en/actions) | CI/CD infrastructure referenced for agent workflows | | [GitHub code review best practices](https://github.com/resources/articles/software-development/code-review-best-practices) | Official GitHub guidance on review processes | The most important coding-agent trend is no longer whether an agent can produce a diff. It can. The harder question is what happens after ten agents produce ten plausible diffs before lunch. The bottleneck moves from generation to review queues, CI capacity, flaky environments, branch policy, cost ceilings, and the human attention needed to decide what should actually merge. That is the practical read on the current AI coding wave. GitHub is turning Copilot into an issue-to-PR agent. Claude Code and Codex make terminal delegation normal. Cursor, Windsurf, and smaller tools keep pushing multi-file edits closer to the default workflow. The market is converging on the same shape: ask for work, get a branch, inspect the result. The next durable advantage is not "more generated code." It is a delivery system that can absorb generated code without drowning the team. **Last updated:** June 28, 2026 ## The Output Problem Became a Throughput Problem Classic AI coding tools were mostly latency products. You typed, the assistant completed, and the productivity question lived inside the editor. Agentic coding is different. It is a throughput product. You assign work and receive artifacts: commits, pull requests, tests, logs, screenshots, migrations, release notes, or review comments. That changes the operating model. A single autocomplete suggestion competes for seconds of attention. A pull request competes for the same review lane as every other change in the organization. It touches CI minutes, dependency caches, preview environments, security checks, branch protections, code owners, and deployment windows. This is why the useful conversation has shifted toward [long-running agent harnesses](/blog/long-running-agents-need-harnesses), [baseline receipts](/blog/agent-evals-need-baseline-receipts), and [defect forensics](/blog/ai-code-attribution-needs-defect-forensics). The model matters, but the delivery surface matters just as much. If a coding agent writes decent code but creates noisy pull requests, the team still loses. If it passes tests locally but cannot reproduce the environment, the team still loses. If it opens five branches that each require senior review, the work has not disappeared. It has changed shape. ## GitHub Is the Obvious Place This Shows Up GitHub's Copilot coding agent is important because it puts AI work directly into the existing issue, branch, and pull request workflow. That is the right integration point for many teams. Developers already know how to review a PR, inspect logs, request changes, and merge. It also exposes the constraint. GitHub does not just need a good coding model. It needs the agent output to fit the mechanics of GitHub itself: Actions, checks, logs, permissions, secrets, code review, repository rules, and team workflows. That is why [GitHub Copilot's agent push](/blog/github-copilot-coding-agent-cli-2026) is less about a chat UI and more about the whole software delivery loop. The moment a cloud agent can turn issues into draft PRs, the platform has to answer operational questions: | Question | Why it matters | |---|---| | How many agent PRs can a repo absorb? | Review capacity is finite | | Which tasks are safe to delegate? | Bad delegation creates review debt | | What evidence should every PR include? | Reviewers need receipts, not vibes | | How are CI minutes and preview environments budgeted? | Agent work can multiply infrastructure usage | | Who owns failures after merge? | Accountability still matters | | How does the team distinguish useful automation from noise? | Volume alone is not progress | The interesting bottleneck is not whether Copilot, Claude Code, Codex, or another agent can make a change. It is whether the surrounding system can turn that change into a trusted merge. ## Opposing Take: More Agents Means Less Review The optimistic counterargument is straightforward: agents will also review code, fix tests, summarize diffs, catch security issues, and reduce the burden on humans. That is partly true. AI review is already useful for first-pass feedback, test suggestions, style drift, and obvious missed cases. A good agent can shrink the review surface by attaching logs, explaining intent, and cleaning up its own mistakes before a human opens the PR. But agent review does not erase the queue. It changes what the queue is for. Human reviewers should spend less time catching formatting issues and more time asking product, architecture, security, and maintenance questions: - Does this change solve the right problem? - Is the abstraction worth keeping? - Did the agent choose the smallest useful diff? - Does the migration path preserve real customer state? - Are we comfortable owning this code six months from now? Those questions are not going away soon. In fact, they become more important when code is cheap. The best teams will not review every generated line with equal intensity. They will build triage lanes. Low-risk chores get automated checks and lightweight review. Medium-risk product work gets stronger receipts. High-risk changes get human design review before the agent starts. That is the difference between agent throughput and agent spam. ## The New Unit Is the Reviewable Task Agents make task design more important. A vague task like "improve settings" can produce a sprawling diff that is technically impressive and practically annoying. A reviewable task is smaller: - "Add empty-state copy to the billing settings page." - "Move this route from client-side fetch to server rendering." - "Add a regression test for this parser edge case." - "Update this deprecated API call across three files." - "Generate a draft migration plan, but do not edit code yet." The task should tell the agent what to change, what not to change, how to verify it, and what evidence to return. That makes the PR easier to review and easier to reject. This is where agent evals and daily engineering process meet. A team that cannot write crisp tasks will struggle to evaluate agents honestly. A team that can write crisp tasks can compare models, tools, prompts, and workflows against a stable baseline. For more on that measurement loop, read [Agent Evals Need Baseline Receipts](/blog/agent-evals-need-baseline-receipts). The short version: compare the candidate against a known baseline, keep the run evidence, and judge behavior instead of only judging the final score. ## What an Agent PR Should Include An agent-generated pull request should not look like a human PR with less context. It should include more machine-readable context because the agent can afford to collect it. A useful agent PR receipt includes: | Receipt | Minimum bar | |---|---| | Task summary | What the agent was asked to do | | Scope boundary | Files, routes, packages, or APIs intentionally touched | | Verification | Exact tests, lint, typecheck, smoke checks, or screenshots | | Known gaps | What was not checked or could not be proven | | Risk label | Low, medium, or high based on runtime and ownership impact | | Cost signal | Approximate run time, retries, model/tool usage, or CI minutes | | Reviewer focus | The two or three decisions a human should inspect | This is not bureaucracy. It is compression. Reviewers do not need another wall of generated explanation. They need the shortest path to deciding whether the change should merge. ## CI Capacity Becomes Product Infrastructure Agentic coding also makes CI less invisible. When every developer opens a couple of PRs a day, CI is background infrastructure. When humans and agents can open many more branches, CI becomes a product surface. Slow queues, flaky tests, dependency cache misses, and preview environment limits directly reduce agent usefulness. This creates a new kind of platform work: - Faster selective test routing - Better flaky-test quarantine - Prebuilt workspaces and dependency caches - Per-agent budget caps - Preview environments that expire aggressively - Branch rules that separate safe chores from risky changes - Logs that summarize failures clearly enough for another agent to fix them That is not glamorous, but it is where compounding productivity lives. The team with a boring, reliable delivery harness will get more value from mediocre agents than a team with frontier models and a chaotic merge pipeline. ## Practical Playbook If your team is starting to delegate real coding work to agents, treat this as an operations problem. First, create task classes. Label work as chore, test, docs, refactor, feature, migration, security, or incident-adjacent. Do not give every class the same review path. Second, define a minimum PR receipt. Require the agent to state scope, checks, gaps, and reviewer focus. The template should be short enough that humans actually read it. Third, measure merge friction. Track agent PRs opened, closed, merged, bounced for changes, failed in CI, and reverted. The rejection rate is not a shame metric. It is your training signal. Fourth, protect senior review time. Use agents for first-pass cleanup and evidence gathering, but keep architecture and ownership decisions explicit. Fifth, keep a baseline. When you change models, prompts, tools, permissions, or memory, compare against previous behavior on the same task set. That is the boring version of agentic coding. It is also the version that survives contact with production. ## The Takeaway AI coding agents are making code generation abundant. That does not make engineering judgment abundant. The winners will not be the teams that generate the most code. They will be the teams that turn agent output into small, reviewable, verified changes with low merge friction. The next bottleneck is the queue. Build for that. ## FAQ ### Are AI coding agents ready for production software teams? They are ready for scoped work where the task, environment, verification, and review path are clear. They are not a replacement for product judgment, architecture ownership, or release accountability. ### What is the biggest hidden cost of coding agents? Review capacity. Agent runs can also increase CI usage, preview environment churn, and debugging overhead, but the most scarce resource is usually trusted human attention. ### How should teams review AI-generated pull requests? Use a short receipt: task summary, touched scope, verification, known gaps, risk label, and reviewer focus. Route low-risk chores differently from high-risk architecture or data changes. ### Will AI agents replace code review? They will automate parts of review, especially obvious bugs, style issues, summaries, and test suggestions. Human review still matters for intent, maintainability, ownership, security, and whether the change should exist. ## Sources - [GitHub Docs: About Copilot coding agent](https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent) - [GitHub Docs: About Copilot CLI](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-copilot-cli) - [GitHub Docs: About pull request reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) - [GitHub Docs: About GitHub Actions](https://docs.github.com/en/actions/about-github-actions/understanding-github-actions) - [Anthropic Docs: Claude Code overview](https://docs.anthropic.com/en/docs/claude-code/overview) - [OpenAI Docs: Codex](https://platform.openai.com/docs/codex) - [Developers Digest: GitHub Copilot Coding Agent and CLI](/blog/github-copilot-coding-agent-cli-2026) - [Developers Digest: Long-Running Agents Need Harnesses, Not Hope](/blog/long-running-agents-need-harnesses)

How to Use GLM 5.2 and Other Custom Model Providers in Codex

Developers Digest — Sun, 21 Jun 2026 00:00:00 GMT

Codex is not limited to OpenAI's hosted models. The advanced config supports custom model providers, which means Codex can talk to a compatible provider by changing `~/.codex/config.toml`: a different base URL, API wire format, auth environment variable, and optional headers. That is useful if you want to try GLM 5.2 through an OpenAI-compatible endpoint, route Codex through an internal LLM proxy, run local models behind Ollama, or test a provider like Mistral without changing the rest of your Codex workflow. The feature is powerful because it keeps the agent interface stable while swapping the model backend. It is also easy to misconfigure. **Last updated:** June 21, 2026 ## The Mental Model A Codex model provider answers four questions: | Provider setting | What it controls | |---|---| | `base_url` | Where Codex sends model requests | | `wire_api` | Which API shape Codex should speak | | `env_key` | Which environment variable contains the API key | | `http_headers` / `env_http_headers` | Extra headers for gateways, betas, org routing, or proxies | You then choose a model and point Codex at the provider: ```toml model = "gpt-5.4" model_provider = "proxy" [model_providers.proxy] name = "OpenAI using LLM proxy" base_url = "http://proxy.example.com" env_key = "OPENAI_API_KEY" ``` That one indirection is the whole trick. `model` names the model. `model_provider` names the connection profile. For a broader Codex workflow, pair this with [Codex exec in CI](/blog/codex-exec-ci-headless-guide) and the [Codex vs Claude Code June comparison](/blog/codex-vs-claude-code-june-2026). Those posts cover where Codex fits. This one is just the provider wiring. ## The Three Rules That Save Time First, do not use reserved provider IDs. Codex reserves `openai`, `ollama`, and `lmstudio` for built-in providers. Your custom provider can be called `glm`, `zai`, `mistral`, `proxy`, `openrouter`, `company_gateway`, or almost anything else, but not those three. Second, keep provider definitions in user config. The official docs call out that project-local `.codex/config.toml` files cannot override provider authentication, provider headers, or provider definitions. That is a good safety boundary. A repo should not silently reroute your agent to a different model service. Third, match the provider's API shape. Many providers advertise OpenAI-compatible chat completions. Some expose Responses-style APIs. Local Ollama often behaves like an OpenAI-compatible `/v1` endpoint. Do not assume every model provider supports every Codex feature. ## GLM 5.2 Through an OpenAI-Compatible Endpoint If your GLM 5.2 provider exposes an OpenAI-compatible API, Codex config is usually simple. Use a custom provider ID, set the provider base URL, set the key environment variable, and put the provider's model name in `model`. ```toml model = "glm-5.2" model_provider = "glm_proxy" [model_providers.glm_proxy] name = "GLM 5.2 through an OpenAI-compatible endpoint" base_url = "https://api.example-glm-provider.com/v1" env_key = "GLM_API_KEY" ``` Then set the key in your shell: ```bash export GLM_API_KEY="..." codex ``` Replace the `base_url` and `model` with the exact values from your provider. The important part is the shape, not the placeholder URL. If the provider requires an extra beta flag, organization header, or routing feature, use headers: ```toml model = "glm-5.2" model_provider = "glm_proxy" [model_providers.glm_proxy] name = "GLM 5.2 via gateway" base_url = "https://api.example-glm-provider.com/v1" env_key = "GLM_API_KEY" env_http_headers = { "X-Provider-Features" = "GLM_FEATURES" } ``` Then: ```bash export GLM_API_KEY="..." export GLM_FEATURES="reasoning-preview" codex ``` Use `env_http_headers` for values that should not live directly in config. Plain `http_headers` is fine for non-secret static values. ## Local Ollama Is Different Ollama is already a built-in provider ID in Codex, so do not redefine `[model_providers.ollama]` yourself. If you want a separate local endpoint profile, give it a different name: ```toml model = "qwen3.5:27b" model_provider = "local_ollama" [model_providers.local_ollama] name = "Local Ollama" base_url = "http://localhost:11434/v1" ``` This is useful when you want Codex's agent loop around a local model. It is not magic. Smaller local models may be useful for search, summaries, mechanical edits, or cheap experimentation, but they will not behave like a frontier coding model on a large refactor. For model-selection context, read the [GLM 5.2 vs DeepSeek vs Qwen coding model comparison](/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown) and the [frontier model pricing roundup](/blog/frontier-model-api-pricing-june-2026). ## Mistral Example The official docs show a Mistral-style provider shape: ```toml model = "mistral-large-latest" model_provider = "mistral" [model_providers.mistral] name = "Mistral" base_url = "https://api.mistral.ai/v1" env_key = "MISTRAL_API_KEY" ``` Then: ```bash export MISTRAL_API_KEY="..." codex ``` The same pattern applies to any provider that exposes a compatible API. What changes is the provider URL, key name, model ID, supported features, and whether Codex needs a specific wire API mode. ## Internal Proxy Example Teams often want Codex to go through an internal gateway instead of sending requests directly to every vendor. That can centralize logging, rate limits, policy, spend controls, model routing, and data handling. ```toml model = "gpt-5.4" model_provider = "company_proxy" [model_providers.company_proxy] name = "Company LLM Gateway" base_url = "https://llm-gateway.internal.example.com/v1" env_key = "COMPANY_LLM_KEY" http_headers = { "X-Client" = "codex" } env_http_headers = { "X-Team" = "CODEX_TEAM" } ``` Then: ```bash export COMPANY_LLM_KEY="..." export CODEX_TEAM="platform" codex exec "review the staged diff and list the risky changes" ``` This is the most realistic enterprise use case. The developer still uses Codex. The platform team owns routing, budgets, logging, and approved models. ## When to Set `wire_api` Most simple OpenAI-compatible providers work with the default provider shape. If a provider needs a specific protocol, set `wire_api` explicitly according to the Codex docs and the provider docs. The practical rule: - Use the provider's recommended OpenAI-compatible `/v1` endpoint when available. - Use Responses-style configuration only when the provider supports that API shape. - Do not enable provider-specific Codex options just because they exist. One sharp edge: Codex `model_verbosity` applies only to providers using the Responses API. If you point Codex at a chat-completions-style provider, do not expect every OpenAI-specific tuning knob to work. ## A Safer Test Loop Do not test a new provider on a production refactor. Use a small, read-heavy task first: ```bash codex exec "Read this repo and summarize the test commands. Do not edit files." ``` Then try a small edit: ```bash codex exec "Add one regression test for the smallest parser edge case you can find. Keep the diff minimal." ``` Then inspect: ```bash git diff --stat git diff ``` You are testing three things: 1. Does the provider connect? 2. Does the model follow Codex's tool and editing loop? 3. Does the output justify the cost and latency? That third question is the real one. A model can connect successfully and still be the wrong model for Codex. ## Common Failures | Symptom | Likely cause | |---|---| | Codex ignores your provider | `model_provider` does not match the table name | | Auth fails | `env_key` points at an unset environment variable | | Provider returns 404 | Wrong `base_url`, often missing or duplicating `/v1` | | Provider returns unsupported feature errors | API is OpenAI-like but not fully compatible | | Local model edits are low quality | The model is too small or weak for agentic coding | | Config works in one shell but not another | API key was exported only in the current shell | | Project config does not override provider settings | This is expected by design | If you are debugging a Codex installation issue on macOS, keep the [Codex macOS certificate update runbook](/blog/openai-codex-macos-certificate-update-runbook) nearby. Provider config problems and local trust/certificate problems can look similar from the outside. ## The Takeaway Custom model providers make Codex more interesting because they separate the agent surface from the model backend. You can keep the same terminal workflow and route it through OpenAI, GLM 5.2, Mistral, Ollama, or an internal gateway, as long as the provider exposes a compatible API and the model is strong enough for the task. But the goal is not to collect provider configs. The goal is to find the cheapest, fastest, most reliable model path for each class of coding work. Start with one provider. Run the same task set. Keep the receipts. Then decide whether the switch is worth it. ## FAQ ### Can Codex use GLM 5.2? Codex can use GLM 5.2 if you access it through a provider endpoint compatible with the API shape Codex expects. Configure a custom provider with the provider's `base_url`, key environment variable, and exact model ID. ### Can I redefine the built-in `openai`, `ollama`, or `lmstudio` providers? No. Those provider IDs are reserved. Use a custom name like `glm_proxy`, `company_proxy`, `mistral`, or `local_ollama`. ### Should provider config live in a project repository? No for secrets and provider definitions. Codex intentionally prevents project-local `.codex/config.toml` from overriding provider auth, headers, and definitions. Keep those in your user config. ### Do all custom providers support every Codex feature? No. OpenAI-compatible does not always mean feature-identical. Some settings, including `model_verbosity`, depend on the provider's wire API and may not apply to chat-completions-style endpoints. ## Sources - [OpenAI Codex advanced configuration: custom model providers](https://developers.openai.com/codex/config-advanced#custom-model-providers) - [OpenAI Codex advanced configuration](https://developers.openai.com/codex/config-advanced) - [OpenAI Codex CLI documentation](https://developers.openai.com/codex/cli) - [Ollama OpenAI compatibility documentation](https://github.com/ollama/ollama/blob/main/docs/openai.md) - [Mistral AI API documentation](https://docs.mistral.ai/api/) - [Developers Digest: Codex exec CI headless guide](/blog/codex-exec-ci-headless-guide) - [Developers Digest: GLM 5.2 vs DeepSeek v4 vs Qwen3 open weights coding showdown](/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown)

Agents 101: How to Build and Deploy Anything with AI Agents

Sat, 20 Jun 2026 12:06:11 GMT

Build Anything with Vercel, the Agentic Infrastructure Stack Check out Vercel: https://vercel.plug.dev/cwBLgfW The video shows a behind-the-scenes walkthrough of how the creator rapidly builds and d...

Agent Evals Need Baseline Receipts

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Hex agent eval writeup | [hex.tech/blog/evaluate-data-agents](https://hex.tech/blog/evaluate-data-agents/) | | OpenAI Evals guide | [platform.openai.com/docs/guides/evals](https://platform.openai.com/docs/guides/evals) | | Anthropic output consistency | [docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency](https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency) | | LangSmith evaluation docs | [docs.smith.langchain.com/evaluation](https://docs.smith.langchain.com/evaluation) | | Braintrust AI evals | [braintrustdata.com/docs/guides/evals](https://www.braintrustdata.com/docs/guides/evals) | [Hex's writeup on evaluating data agents](https://hex.tech/blog/evaluate-data-agents/) is the most useful AI developer post on the wire today because it skips the usual benchmark theater. The interesting part is not that Hex built an eval tool. Everyone is building eval tools. The interesting part is the shape of the tool: a lab bench for pairwise experiments, stable production baselines, locally executed candidate runs, custom rubrics, side-by-side trajectories, and a fake business with realistic data. That is the right direction for agent products. **Last updated:** June 30, 2026 Agents do not fail like autocomplete models. They fail across a run: a bad assumption in step two, a missed join in step four, an overconfident final chart, a useful tool call made too late, or a correct answer that cost 10x too much. A single score at the end loses most of the evidence. If you are building coding agents, data agents, browser agents, or internal operators, the durable primitive is not "run more benchmarks." It is baseline receipts. ## Why Data Agents Expose the Problem First Hex describes analytics as a difficult domain for agents because easy questions can look hard, hard questions can look easy, warehouse context is private and out of distribution, and wrong answers can still sound plausible. That maps almost perfectly to software work. A coding agent can pass a unit test while choosing the wrong abstraction. A data agent can produce a clean chart from the wrong grain. A support agent can cite the right document but apply it to the wrong customer state. A browser agent can finish the happy path while missing the broken edge state. This is why [context reduction](/blog/agent-context-reduction-pattern), [agent memory contracts](/blog/agent-memory-benchmarks-not-enough), and [long-running harnesses](/blog/long-running-agents-need-harnesses) keep showing up as the same conversation. The model is only one part of the system. The context stores, retrieval layer, tool choices, planner, permissions, UI state, and final judge all change the result. Hex makes that explicit. Their post says agent performance is increasingly a function of the rich context stores an agent can access, not just the model or system prompt. That is the sentence to steal for your own roadmap. An agent eval that only compares model A to model B is under-instrumented. A useful eval compares the whole candidate system to the whole baseline system and keeps enough evidence to explain the delta. ## The Baseline Is a Product Feature The most practical detail in Hex's setup is the hybrid workflow: local candidate runs compared against shared remote production baselines. That sounds boring. It is not. Most agent teams drift into a messy eval loop: 1. Someone changes a prompt. 2. Someone else changes a retrieval setting. 3. A third person upgrades the model. 4. The eval set changes quietly. 5. A dashboard says the number moved. Nobody knows whether the agent improved or whether the measurement surface moved underneath it. A stable baseline fixes that. It gives every experiment a reference point that does not depend on the developer's laptop, branch, cached data, or current prompt edits. It also changes the conversation from "this run scored 82" to "this candidate beat the production baseline on these cases, lost on these cases, cost this much more, and changed these behaviors." That is the same operational instinct behind [token-budget ledgers](/blog/harness-engineering-token-budget). You do not just ask whether the agent finished. You ask what it spent, what it touched, which path it took, and whether the new path is worth shipping. For a coding-agent team, a baseline receipt should include: | Receipt field | Why it matters | |---|---| | Baseline version | Prevents comparing against a moving target | | Candidate version | Ties behavior to a branch, prompt, model, tool config, or memory change | | Task fixture | Captures the repo, issue, database state, browser state, or document set | | Trajectory summary | Shows tool calls, files touched, retries, and major decisions | | Rubric results | Separates correctness, efficiency, safety, style, and user-fit | | Cost and latency | Makes expensive wins visible before they become defaults | | Human review note | Preserves the examples that aggregate scores flatten | The key is not to make every receipt huge. The key is to make it stable enough that a reviewer can replay the important claim. ## Pairwise Beats Absolute Scores Absolute eval scores are comforting because they look like grades. Pairwise evals are useful because they look like engineering. Hex's writeup describes candidate and baseline runs as the default mental model. That one choice prevents a lot of bad dashboard behavior. You are not arguing about whether a synthetic benchmark number is impressive. You are asking whether the candidate made the real workflow better than the thing users currently have. This matters even more as agent systems add model panels and judges. In the [OpenRouter Fusion post](/blog/openrouter-fusion-model-panels-escalation), the right lesson was that multi-model panels should be escalation lanes, not autopilot defaults. The same applies to eval judges. A judge is useful when it has a concrete comparison, a task-specific rubric, and access to the run evidence. A judge is weaker when it scores a final answer in isolation. The pairwise question is sharper: ```text Given the same task fixture, did candidate run B improve on baseline run A? Evaluate: - correctness - evidence use - unnecessary tool calls - cost and latency - policy violations - final user usefulness ``` That framing makes it harder for a model to reward fluent nonsense. It also makes the failures legible. Maybe the candidate solved more tasks but stopped using the semantic layer. Maybe it was more accurate but doubled warehouse queries. Maybe it followed the workspace guide better but got slower. Those are product decisions, not benchmark trivia. ## The Fake Business Is the Secret Ingredient Hex also built Shorelane Commerce, a fake business with realistic data. That is the part more teams should copy. Public benchmarks are useful for broad model selection, but they rarely match your operating environment. Internal production data is realistic, but it is private, messy, permissioned, and hard to share across dev, CI, vendors, and external reviewers. A synthetic-but-realistic fixture gives you the missing middle. For developer tools, the equivalent could be: - a fake SaaS repo with auth, billing, migrations, flaky tests, and incidents; - a fake support workspace with realistic customer plans, tickets, docs, and contradictory history; - a fake analytics warehouse with dimensional models, bad joins, stale tables, and business definitions; - a fake browser app with logged-in state, feature flags, permissions, and broken responsive views. The goal is not to trick the model. The goal is to give the agent a world where the right answer depends on context, not trivia. This is also where opposing opinions matter. The Hacker News thread for Hex's post had not developed much discussion when I checked it, but recent HN skepticism around AI testing agents is relevant: developers asked why they should pay token costs for nondeterministic test agents when LLMs can already write deterministic end-to-end tests. That pushback is fair. The answer is not "replace tests with agents." The answer is "use deterministic tests for known invariants and agent evals for exploratory workflows where the path matters." A browser checkout test should be deterministic. A release-readiness agent that investigates a suspicious analytics drop needs trajectory evaluation. ## What To Build Before Buying an Eval Platform Do not start with a giant eval platform. Start with one receipt format and one shared baseline. For a small agent team, the first useful loop is: 1. Pick 20 representative tasks. 2. Freeze the fixture for each task. 3. Run the current production agent and save baseline receipts. 4. Run candidate changes locally against those fixtures. 5. Compare candidate receipts against baseline receipts with a rubric. 6. Review the biggest wins and losses by hand. 7. Promote a new baseline only after the team agrees the tradeoff is worth it. This is enough to catch most prompt, retrieval, memory, and tool-routing regressions. It also creates the habit that matters: every agent change has to explain what it improved against the current product. OpenAI's eval docs frame evals as structured tests for model and application behavior. Anthropic's testing docs emphasize defining success, improving consistency, and using stricter output controls when you need schema conformance. Hex's contribution is the product-engineering layer between those ideas: shared baselines, pairwise runs, rich trajectories, and realistic fixtures. That is the pattern to copy. ## The Takeaway Agent evals should feel less like leaderboard watching and more like code review. A good code review asks what changed, why it changed, what evidence supports it, what risk remains, and whether the tradeoff is worth merging. A good agent eval should do the same. The next time a prompt, model, tool, memory layer, or context store makes an agent "feel better," ask for the baseline receipt. If the team cannot show the candidate run next to the production run, with the task fixture, trajectory, rubric, cost, and reviewer note, it does not have an eval yet. It has an anecdote. ## FAQ ### What is a baseline receipt for an AI agent? A baseline receipt is a compact record of how the current production agent handled a task: the fixture, agent version, tool calls, trajectory, costs, rubric results, and reviewer notes. Candidate changes are compared against that receipt so teams can see what actually improved or regressed. ### Why are pairwise evals better than benchmark scores for agents? Pairwise evals compare a candidate run against a known baseline on the same task. That makes regressions easier to spot and keeps the discussion tied to product behavior. Benchmark scores are still useful for model selection, but they usually hide the trajectory details that matter in agent systems. ### Should agent evals replace deterministic tests? No. Deterministic tests should cover known invariants, API contracts, schema rules, browser flows, and safety gates. Agent evals are better for exploratory tasks where the path, evidence use, tool efficiency, and final judgment all matter. ### What should teams evaluate besides correctness? Evaluate evidence use, unnecessary tool calls, cost, latency, policy violations, context-store behavior, memory use, final answer usefulness, and whether the candidate changed the action compared with the baseline. ## Sources - Hex: [How we built a lab to evaluate data agents](https://hex.tech/blog/evaluate-data-agents/) - fetched June 20, 2026. - Hacker News: [We built a lab to evaluate data agents](https://news.ycombinator.com/item?id=48604937) - checked June 20, 2026. - Hacker News: [Launch HN: TesterArmy - Agents that test web and mobile apps](https://news.ycombinator.com/item?id=48586299) - used for opposing developer pushback, checked June 20, 2026. - Ian Barber: [LLMs are complicated now](https://ianbarber.blog/2026/06/19/llms-are-complicated-now/) - used as adjacent evidence that modern model systems need composable, verifiable baselines. - OpenAI Docs: [Working with evals](https://platform.openai.com/docs/guides/evals) - fetched June 20, 2026. - Anthropic Docs: [Increase output consistency](https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency) - fetched June 20, 2026.

There Are No Instances in ATProto - Dan Abramov Explains the Architecture

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

Dan Abramov - yes, the React/Redux Dan Abramov - has written a piece explaining why the mental model most people bring to ATProto from Mastodon is fundamentally wrong. The [post](https://overreacted.io/there-are-no-instances-in-atproto/) hit the Hacker News front page with 467 points and 236+ comments, and it's worth reading in full if you care about how decentralized protocols actually work. The title is the thesis: **there are no instances in ATProto**. ## What the Article Actually Says Abramov's core argument is that Mastodon-style federation bundles two things that should be separate: **hosting** and **applications**. In Mastodon, you are "Alice-from-instance-#1." Your identity, your data, and your experience of the network are all tied to which server you picked when you signed up. If that server shuts down, goes offline, or decides to defederate from other parts of the network, your identity goes with it. ATProto decouples these. You have: 1. **Hosting** (called a PDS, or Personal Data Server) - where your data lives 2. **Applications** (called AppViews) - which aggregate and display data from across the network The key insight: hosting servers in ATProto never talk to each other directly. They just store data. Applications pull from all the hosting servers and present a unified view. Abramov uses an RSS analogy: "Keep our stuff outside the apps; let the apps aggregate over it." Your blog posts live in one place. Any RSS reader can display them. You can switch readers without losing your posts, and you can move your blog without breaking your readers. | Aspect | Mastodon | ATProto | |--------|----------|---------| | **Coupling** | Hosting + apps bundled | Separated at network level | | **Identity** | Instance-bound | Independent of host | | **Portability** | Complex migrations | Straightforward host switching | | **Apps** | Limited alternatives | Multiple clients/platforms | Abramov moved his own hosting to Eurosky, uses multiple applications (Tangled, Semble, Bluesky), and notes he could self-host on Cloudflare without losing his identity or connections. ## What Hacker News Is Saying The [discussion thread](https://news.ycombinator.com/item?id=48599515) is one of the more technically substantive HN threads in recent memory, with Abramov actively responding to critiques. **The relay question came up immediately.** Several commenters pointed out that the article glosses over relays - the components that aggregate data from all the hosting servers so apps don't have to connect to thousands of individual servers. One commenter asked: "Aren't relays basically instances?" Abramov's response: relays are an optimization, not a fundamental part of the architecture. An app can work without a relay (like [reddwarf.app](https://reddwarf.app/) does). Running your own relay costs about $30/month now. There are multiple community-run relays. And crucially, a relay is just a "dumb retransmitter" - it doesn't make moderation decisions or control your identity. **The "centralization in disguise" critique showed up.** Some commenters argued that having one main Bluesky AppView is effectively centralization. Abramov's counter: "It's not centralized in any way that matters." You can run your own AppView, there are independent ones like Blacksky, and the relay infrastructure is cheap enough that multiple competing ones exist. **The moderation angle got attention.** One commenter linked to [prior writing](https://blog.raed.dev/posts/mastodon_moderation) about why federated moderation is a problem - the "warring fiefdoms" dynamic where instance admins fight about who to defederate. Another pointed out that ATProto's separation means you can take your identity to another AppView if you disagree with Bluesky's moderation, without losing your data or network. **Mastodon defenders pushed back.** Some argued that you can plug different frontends into Mastodon servers, and that the article treats Mastodon (the implementation) as if it were ActivityPub (the protocol). Fair point, but Abramov's response is that even with different frontends, the fundamental coupling of hosting to a specific server's policies and uptime remains. **The "can it scale down" question.** One commenter asked if you could run this on a Raspberry Pi at home. Abramov linked to a [post](https://bsky.bad-example.com/can-atproto-scale-down/) showing that some ecosystem services do run on Raspberry Pis, and noted that "the best algorithmic 'For You' feed on the app runs off someone's gaming computer at home." ## Why This Matters for Developers If you're building anything that touches social protocols, this architectural distinction has real implications. **Data portability is a first-class concern.** In ATProto, your posts are stored in a format that any compliant application can read. This is not an afterthought or an export feature - it's how the system works. If you're building an app, you're building something that reads and writes to a shared data layer, not a walled garden. **Identity is not locked to infrastructure.** The DID (decentralized identifier) system means your handle and your data are yours regardless of who hosts them. If you're building auth flows or user management, this is a different model than "log in with X server." **The "build your own Twitter" question has a real answer.** You don't have to build your own Twitter. You can build an application that reads from and writes to the same network everyone else is using. The barrier to entry is "build an AppView" not "build an entire social network." **Moderation happens at the application layer.** This is both a feature and a responsibility. Applications decide what to show, not hosting providers. If you're building an application, you're also building a moderation policy - but that policy doesn't affect other applications or force users to choose between your moderation and keeping their data. For related reading on protocol-level architecture decisions, see our coverage of [MCP server ecosystem](/blog/mcp-server-ecosystem-developers-guide) and [agent infrastructure tools](/blog/ten-tools-for-agent-infrastructure). ## Sources - [Original article: "There are no instances in ATProto"](https://overreacted.io/there-are-no-instances-in-atproto/) - [Hacker News discussion](https://news.ycombinator.com/item?id=48599515) - [ATProto documentation](https://atproto.com/docs) - [Can ATProto scale down?](https://bsky.bad-example.com/can-atproto-scale-down/)

Cloudflare Temporary Accounts: Let Agents Deploy Without OAuth Flows

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

## Official Sources | Source | Link | |--------|------| | Cloudflare Blog Announcement | [blog.cloudflare.com/temporary-accounts](https://blog.cloudflare.com/temporary-accounts/) | | Cloudflare Changelog | [developers.cloudflare.com/changelog](https://developers.cloudflare.com/changelog/post/2026-06-19-temporary-accounts-for-agents/) | | Wrangler CLI Documentation | [developers.cloudflare.com/workers/wrangler](https://developers.cloudflare.com/workers/wrangler/) | | Workers Documentation | [developers.cloudflare.com/workers](https://developers.cloudflare.com/workers/) | **Last updated:** June 20, 2026 AI agents hit a wall when they need to deploy code. The problem is not the deployment itself - it is the account creation flow that precedes it. OAuth popups, dashboard click-throughs, API token copy-paste rituals, multi-factor authentication challenges - all designed for humans with browsers and patience. Cloudflare addressed this on June 19, 2026 with temporary accounts. An agent running Wrangler 4.102.0 or later can now deploy a Worker, a D1 database, KV storage, Durable Objects, or any supported Cloudflare resource without creating an account first. The deployment stays live for 60 minutes. During that window, a human can claim the account and make it permanent. ## How It Works The mechanism is a single CLI flag: ```bash wrangler deploy --temporary ``` When an agent runs this command without credentials, Wrangler provisions a temporary Cloudflare account in the background, issues an API token to itself, deploys the Worker, and returns two URLs: the live deployment URL and a claim URL. The agent does not need to navigate a browser, handle OAuth callbacks, or parse emails. It gets infrastructure. ## The 60-Minute Window Temporary deployments self-destruct after 60 minutes of inactivity. That is enough time for an agent to: 1. Deploy an initial version 2. Test the endpoint 3. Iterate with fixes 4. Redeploy multiple times 5. Hand the claim URL to a human for permanent ownership Each redeploy resets the 60-minute timer. An agent actively iterating on a deployment can keep it alive indefinitely - the clock only runs when nothing is happening. When a human clicks the claim URL, they authenticate with Cloudflare (signing up or logging in), and the temporary account converts to a permanent one. All resources - Workers, databases, KV namespaces, Durable Objects - transfer with it. If nobody claims the account within the window and no redeploy happens, Cloudflare deletes everything. ## What You Can Deploy The temporary accounts feature supports a significant slice of the Cloudflare developer platform: | Product | Supported | |---------|-----------| | Workers | Yes | | Workers Static Assets | Yes | | Workers KV | Yes | | D1 (SQLite database) | Yes | | Durable Objects | Yes | | Hyperdrive | Yes | | Queues | Yes | | SSL/TLS certificates | Yes | This covers most common deployment patterns. An agent can spin up an API with a database backend, deploy a static site, or launch a real-time application with Durable Objects - all without a pre-existing account. ## Version Requirements You need Wrangler 4.102.0 or later. Check your version: ```bash wrangler --version ``` If you are behind, update: ```bash npm install -g wrangler@latest ``` One gotcha: if you have cached credentials from a previous login, they may interfere with temporary account creation. Run `wrangler logout` before testing the feature to ensure a clean state. ## What This Means for Agent Workflows The pattern Cloudflare enabled here is "deploy first, claim later." It inverts the traditional flow where account creation is a prerequisite for any action. For agent developers, this opens several use cases: **Prototype deployment agents.** An agent can take a description like "build me an API that converts markdown to PDF" and ship a working endpoint without any credential handoff. The human reviews the live deployment before claiming it. **CI/CD without secrets.** Ephemeral preview deployments in CI pipelines can use temporary accounts instead of storing Cloudflare API tokens in secrets. The deployment lives long enough for automated tests, then either gets claimed or expires. **Sandbox environments.** Agents testing infrastructure code can deploy to throwaway Cloudflare accounts, validate behavior, and clean up automatically after 60 minutes. **Demo flows.** A conversational agent can deploy a working example during a support interaction. The user sees it live, decides if they want it, and claims or abandons it. ## The Agent Discovery Pattern Cloudflare built in a helpful fallback. When an agent tries to run `wrangler deploy` without credentials, Wrangler outputs a message suggesting the `--temporary` flag. An agent parsing CLI output can discover the feature and adapt without explicit instructions. This matters because it means agents designed for credentialed deployments can gracefully degrade to temporary deployments when credentials are unavailable. No special-case code required - just read the error message. ## Integration Example Here is a minimal agent loop that deploys a Worker and returns both URLs: ```typescript import { execSync } from 'child_process'; async function deployTemporary(projectPath: string) { // Ensure no cached credentials execSync('wrangler logout', { cwd: projectPath, stdio: 'ignore' }); // Deploy with temporary flag const output = execSync('wrangler deploy --temporary', { cwd: projectPath, encoding: 'utf-8' }); // Parse URLs from output const deployUrl = output.match(/https:\/\/[^\s]+\.workers\.dev/)?.[0]; const claimUrl = output.match(/https:\/\/dash\.cloudflare\.com\/temporary-claim\/[^\s]+/)?.[0]; return { deployUrl, claimUrl }; } ``` The agent hands back both URLs. A human can visit the claim URL to take ownership, or let the deployment expire. ## Limitations The 60-minute window is both the feature and the constraint. For deployments that need to survive without human intervention, temporary accounts are not the answer - you still need proper credentials. Not every Cloudflare product is supported yet. R2 storage, Workers AI, and some enterprise features are absent from the launch list. Check the changelog for updates. The claim flow requires a human with a browser. There is no API to convert a temporary account to permanent programmatically - someone needs to click through. ## Broader Context This is part of a pattern where infrastructure providers are adapting to agentic workloads. Stripe and WorkOS have similar agent-friendly provisioning flows. The thesis: if agents are going to deploy production infrastructure, the infrastructure needs to meet them halfway. For developers building agents that touch deployment, this removes one of the harder integration problems. You no longer need to build OAuth handling, token management, or credential storage into your agent just to deploy a Worker. ## FAQ ### Does temporary deployment cost anything? Cloudflare has not published pricing specific to temporary accounts. Claimed accounts follow normal Workers pricing. Unclaimed deployments that expire do not appear to incur charges. ### Can I extend the 60-minute window? Each redeploy resets the timer. An agent actively iterating keeps the deployment alive. There is no explicit "extend" command. ### What happens to data in D1 or KV if I do not claim? It gets deleted with the rest of the temporary account when the 60 minutes expire. ### Can multiple agents share a temporary account? No. Each `wrangler deploy --temporary` creates a new isolated account. Agents cannot collaborate on a single temporary deployment. ### Does this work with wrangler.toml configuration? Yes. Your standard wrangler.toml configuration applies to temporary deployments. Bindings, routes, and other settings work as expected. ### Is this available on the free tier? Yes. Temporary accounts do not require a paid Cloudflare plan. ### Can I use this for production? The 60-minute expiration makes it unsuitable for persistent production workloads. Use it for prototyping, previews, and handoff flows - then claim the account for production. ### What version of Node.js do I need? Wrangler 4.x requires Node.js 18 or later. ## Sources - [Temporary Cloudflare Accounts for AI Agents](https://blog.cloudflare.com/temporary-accounts/) - Cloudflare Blog, June 19, 2026 - [Temporary accounts for AI agent deployments](https://developers.cloudflare.com/changelog/post/2026-06-19-temporary-accounts-for-agents/) - Cloudflare Changelog, June 19, 2026 - [Wrangler CLI Documentation](https://developers.cloudflare.com/workers/wrangler/) - Cloudflare Workers docs

Cloudflare Now Lets AI Agents Deploy Workers Without Signup

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

AI agents still trip over the boring parts of software delivery. OAuth flows require browsers. Email verification requires inboxes. CAPTCHA challenges require humans. API tokens have to exist before the agent can use them. [Cloudflare Temporary Accounts](https://blog.cloudflare.com/temporary-accounts/) is a direct answer to that friction. An unauthenticated agent can run `wrangler deploy --temporary`, get a working Workers URL, iterate for a short window, and hand the human a claim link if the result is worth keeping. **Last updated:** June 24, 2026 The important part is not only that Cloudflare made Workers easier to deploy. It is that Cloudflare made deployment discoverable by agents. If Wrangler has no credentials, the CLI can tell the agent to rerun with `--temporary`. That small product choice matters for the same reason [terminal agents are becoming portable runtime surfaces](/blog/terminal-agents-portable-runtime-surface): agents can operate reliably when the workflow is expressed as normal CLI feedback instead of a hidden dashboard ritual. ## How Temporary Accounts Work The flow starts with a normal deploy attempt. If the machine has no Cloudflare credentials, the agent can rerun with: ```bash npx wrangler deploy --temporary ``` Cloudflare's [claim deployments documentation](https://developers.cloudflare.com/workers/platform/claim-deployments/) says this requires Wrangler `4.102.0` or later. The CLI creates or reuses a temporary preview account, deploys to a `workers.dev` URL, and prints a claim URL. The deployment can be claimed for 60 minutes. If the user signs in or creates an account through the claim URL, the temporary preview account becomes owned by that user and the resources remain available. If nobody claims it, Cloudflare deletes the temporary account and its deployments. That makes it a clean fit for agent-generated previews: - The agent can deploy without OAuth. - The user can inspect a real URL. - The agent can redeploy within the same temporary window. - The user can claim the work only when it is worth keeping. This is the deployment equivalent of a scratch branch. It gives the agent enough cloud access to show proof, without requiring the user to prepare credentials first. ## The Limits Matter Temporary accounts are not production infrastructure. Cloudflare is explicit about the boundaries: - The preview account expires after 60 minutes if it is not claimed. - The CLI performs a proof-of-work check before creating the account. - Cloudflare rate-limits temporary account creation. - `--temporary` is for unauthenticated use only. - Claim URLs grant ownership, so they should be treated as sensitive. - Cloudflare applies additional abuse-prevention checks. The supported resource list is useful but bounded: Workers, Workers Static Assets, Workers KV, one D1 database up to the documented temporary-account size limits, Durable Objects, Hyperdrive, Queues, and SSL/TLS certificate operations that use temporary credentials. For production and CI/CD, Cloudflare says to use a permanent account with `wrangler login` or an API token. That is the right split. Temporary accounts are for previews, demos, first-time evaluations, and background agent sessions. They are not a replacement for deployment governance. ## Why This Is an Agent UX Pattern The product lesson is broader than Cloudflare Workers. When agents hit an auth wall, they usually fail in one of three ways: - They ask the user to log in manually, breaking autonomy. - They need a long setup guide, which kills the "try it now" moment. - They are given broad API credentials, which creates security and cost risk. Temporary accounts give platforms a fourth option: issue a narrow, short-lived workspace that can be claimed later. That pattern lines up with several pieces of the agent stack: - [Zero-touch OAuth for MCP](/blog/zero-touch-oauth-mcp-enterprise) handles delegated access when the user already has an identity. - [Agent identity](/blog/agent-identity-security-layer-ai-workflows) gives teams a way to separate the actor from the human owner. - [Permission, logs, and rollback controls](/blog/permissions-logs-rollback-ai-coding-agents) keep autonomous changes auditable. - [Workspace contracts](/blog/agent-workspaces-need-filesystem-contracts) make the local side predictable before the agent touches remote systems. - [Cloudflare Agent Memory](/blog/cloudflare-agent-memory-primitive) shows Cloudflare is already thinking about agent-native primitives, not only classic web hosting. Temporary deploys fit that same direction: do not force every agent workflow through a human signup path, but do not hand the agent a permanent production account either. ## What Developers Pushed Back On The [Hacker News discussion](https://news.ycombinator.com/item?id=48608394) was smaller than some launch threads, but the objections were useful. The first concern was abuse. Ephemeral infrastructure can be misused, and developers immediately asked how Cloudflare plans to prevent malicious temporary deployments from becoming a low-friction hosting surface. Cloudflare's docs mention rate limits, proof-of-work, and additional abuse checks, but the exact enforcement details are necessarily not public. The second concern was cost control. Some commenters used the launch as another opportunity to ask for harder billing caps across Workers. That is not exactly the same product problem, but it is related: if agents can create infrastructure quickly, platforms need clear spending boundaries and shutdown behavior. The third concern was deployment authority. Letting a non-deterministic agent deploy directly feels wrong to some engineers. That concern is valid. The safe pattern is not "agent gets production keys." The safe pattern is "agent creates a preview artifact, human or CI promotes it through the normal path." Temporary accounts support the second model better than the first. ## The Practical Use Cases This is most useful when the deployment is evidence, not the final release. **Agent-built prototypes.** A user asks an agent to build a small Worker, webhook endpoint, redirect resolver, or API demo. The agent can return a live URL instead of a patch that still needs account setup. **PR previews.** A bot can publish a short-lived URL for reviewers. If the result matters, a human can claim or recreate it under the real account. **Teaching and evaluation.** New Workers users can see a deployed result before creating a Cloudflare account. That shortens the first-run path. **Background coding sessions.** A long-running agent can deploy, test, patch, and redeploy while the user is away, then leave a claim link and a summary. This is also a good fit for [Codex automation loops](/blog/codex-automations-recurring-engineering-work). Scheduled agents often need a safe way to produce verifiable artifacts without being granted the keys to everything. ## The Security Model To Use For teams, the right operating model is straightforward: 1. Use temporary accounts only for preview and evaluation. 2. Treat claim URLs like credentials. 3. Never paste claim links into public logs or issue comments. 4. Keep production deploys on permanent Cloudflare accounts with API tokens and normal review. 5. Add a receipt: source commit, command run, URL returned, expiry time, and whether the preview was claimed. That last point matters. Agent workflows need receipts because the human reviewer is not always watching the session live. A preview URL is useful, but the audit trail around it is what makes the workflow repeatable. ## The Takeaway Cloudflare Temporary Accounts are not just a convenience flag. They are a sign of where developer platforms are heading. The next wave of infrastructure will need first-run paths for software actors, not only human users. That does not mean agents should bypass security. It means platforms need short-lived, claimable, auditable spaces where agents can prove work before a human promotes it. Cloudflare got the shape right: one CLI flag, a real URL, a short expiry, rate limits, proof-of-work, and a human claim step. The remaining question is whether other developer platforms copy the pattern. They probably should. ## FAQ ### What is Cloudflare Temporary Accounts? Cloudflare Temporary Accounts lets an unauthenticated Wrangler CLI create a temporary preview account, deploy a Worker to a `workers.dev` URL, and print a claim link. It is designed for AI agents, prototypes, and first-time evaluations where the user has not logged in yet. ### How long do temporary Cloudflare deployments last? The claim window is 60 minutes. If the temporary preview account is not claimed within that window, Cloudflare deletes the temporary account and its deployments. ### Should agents use `wrangler deploy --temporary` for production? No. Cloudflare's docs say production and CI/CD should use a permanent Cloudflare account with `wrangler login` or an API token. Temporary deploys are best for previews, demos, and evaluation flows. ### What is the main security risk? The claim URL is sensitive because it grants ownership of the temporary preview account. Teams should avoid logging it publicly and should keep production deploys behind normal review, token, and rollback controls. ## Sources - [Temporary Cloudflare Accounts for AI Agents](https://blog.cloudflare.com/temporary-accounts/) - [Claim deployments documentation](https://developers.cloudflare.com/workers/platform/claim-deployments/) - [Wrangler deploy command reference](https://developers.cloudflare.com/workers/wrangler/commands/#deploy) - [Cloudflare Workers pricing and limits](https://developers.cloudflare.com/workers/platform/pricing/) - [Hacker News discussion: Temporary Cloudflare accounts for AI agents](https://news.ycombinator.com/item?id=48608394)

Where to Run GLM-5.2 Free and Cheap: Every Provider Compared (2026)

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [Z.ai: GLM-5.2 research blog](https://z.ai/blog/glm-5.2) | Official release, architecture, benchmarks | | [Z.ai subscribe + model API pages](https://z.ai/subscribe) | GLM Coding Plan tiers and per-token API pricing | | [Hugging Face: zai-org/GLM-5.2](https://huggingface.co/zai-org/GLM-5.2) | Open weights, MIT license, framework support | | [OpenCode Go referral link](https://opencode.ai/go?ref=M6HEHM4JM5) | $5 credits plus $5 first-month promo with referral code `M6HEHM4JM5` | | [OpenRouter: z-ai/glm-5.2](https://openrouter.ai/z-ai/glm-5.2) | Live multi-provider routing table and prices | | [Artificial Analysis: GLM-5.2 providers](https://artificialanalysis.ai/models/glm-5-2/providers) | Independent blended price and throughput across hosts | Because GLM-5.2 is released under a permissive MIT license, the usual question for a frontier model - "where can I even get access?" - has the opposite answer here. It is hosted almost everywhere within days of release, several providers undercut Z.ai's own list price, and a couple of routes will run it for free or nearly free right now. The hard part is not finding access. It is picking the route that fits your workload without overpaying or accidentally self-hosting a 756-billion-parameter model you did not need to. This post maps every path: the genuinely free ones, the cheapest paid ones, and local. Prices are per million tokens and were verified on June 20, 2026. Pricing pages are the only source of truth and they move, so treat the numbers as a snapshot, not a contract. **Last verified:** June 20, 2026. ## What GLM-5.2 is, in one paragraph GLM-5.2 is Z.ai's (formerly Zhipu AI) open-weights coding model, released in mid-June 2026. It is a mixture-of-experts model with roughly 756B total parameters, a 1M-token context window (1,048,576 tokens), and an MIT license that places no regional or commercial restrictions on the weights. On Z.ai's own benchmarks it is the strongest open-source coding model available, trailing Anthropic's Opus 4.8 and edging out GPT-5.5 on the FrontierSWE suite. For the full benchmark and cost breakdown, see the [GLM-5.2 cost math](/blog/glm-5-2-cost-math-open-weights-coding-models) and [developer guide](/blog/glm-5-2-developer-guide-2026). This page is only about access. ## The free routes (right now) Four paths will run GLM-5.2 with little or no upfront cost today. None is unlimited, and the genuinely free ones are time-limited, so read the terms before you wire a production agent to them. ![Abstract systems illustration for The free routes (right now)](/images/blog/glm-5-2-free-and-cheap-access-2026/inline-1.webp) - **OpenCode Go referral credits.** If you want to test GLM-5.2 through an agent-first route before committing to a full plan, [OpenCode Go](https://opencode.ai/go?ref=M6HEHM4JM5) is the easiest place to start. Use referral code `M6HEHM4JM5` and you get $5 in credits plus $5 off the first month. Because GLM-5.2 inference is cheap, that promo can translate to roughly $60 worth of practical GLM-5.2 inference compared with paying frontier-model rates for the same coding workload. Treat the exact mileage as workload-dependent, but put this near the top of your shortlist if you want a low-friction trial. - **Devin (Cognition), inside the Pro plan.** Cognition's [Devin pricing](https://devin.ai/pricing/) lists "free use of leading open source models" and "full model availability" on the Pro plan, with GLM-5.2 among them. The important caveat: this is bundled into a paid plan, not a standalone giveaway. The model itself adds no marginal cost once you are on Pro, which is what people mean when they say GLM-5.2 is "free in Devin." The free tier carries limited model availability and does not include it. - **Z.ai ZCODE CLI free quota.** Z.ai has been seeding its own coding CLI with a large free token allowance (community reports put it near 300M tokens) to pull developers onto GLM-5.2. Quotas and eligibility change, so confirm on [z.ai](https://z.ai/) before relying on it. - **Hugging Face Inference Providers, launch window.** Hugging Face opened a limited free window for GLM-5.2 through its Inference Providers routing shortly after release. Free windows close, so check the [model page](https://huggingface.co/zai-org/GLM-5.2) for current status. If you want free and you want it to last, the honest answer is local: download the weights and run them yourself. That is the [Ollama and self-host](#local-and-self-host) section below. ## The cheapest paid routes For most teams the right answer is a hosted API at a few dollars per million tokens. GLM-5.2 is open weights, so any inference shop can serve it and compete on price, which is exactly why the per-token cost sits well below comparable closed models. Here is the live picture. | Provider | Input ($/1M) | Output ($/1M) | Cached input | Context | Notes | |----------|-------------|---------------|--------------|---------|-------| | OpenRouter (cheapest route) | 1.20 | 4.10 | 0.20 | 1.05M | Auto-routes across 13+ hosts | | DeepInfra | 1.20 | 4.20 | 0.20 | 1.05M | fp4, among cheapest blended | | Z.ai (first-party API) | 1.40 | 4.40 | 0.26 | 1.05M | fp8, the reference price | | Fireworks AI | 1.40 | 4.40 | 0.26 | 1.04M | Day-zero, dedicated GPU option | | Novita | 1.40 | 4.40 | 0.26 | 1.05M | fp8 | A few things worth knowing before you pick a row: - **OpenRouter is a router, not a host.** Its [endpoints API](https://openrouter.ai/api/v1/models/z-ai/glm-5.2/endpoints) shows 13-plus providers serving `z-ai/glm-5.2`, and OpenRouter sends your request to the cheapest or fastest one that meets your constraints. You get failover and price competition without managing keys for each host. There is no `:free` variant for GLM-5.2 on OpenRouter, despite some other models having one. - **Quantization matters.** The cheapest routes (DeepInfra, Wafer) serve fp4 quantized weights; Z.ai, Fireworks, and Novita serve fp8. For coding agents the quality gap is usually small but real, and it is the reason the price differs. Test your own task before optimizing purely on price. - **Blended price is lower than the table suggests.** On a typical 3:1 input-output mix, [Artificial Analysis](https://artificialanalysis.ai/models/glm-5-2/providers) puts the cheapest blended hosts (GMI, Wafer, DeepInfra) near $0.72 to $0.80 per million tokens, with Wafer the fastest at over 200 tokens/sec. For the worked cost-per-task math versus closed models, the [GLM-5.2 cost math post](/blog/glm-5-2-cost-math-open-weights-coding-models) runs the numbers. ## Direct from Z.ai: API vs the Coding Plan If you go first-party, Z.ai sells two things, and they suit different usage shapes. - **Per-token API** at roughly $1.40 input and $4.40 output per million tokens, with cached input near $0.26. Right for variable or bursty usage where you pay for exactly what you run. - **GLM Coding Plan** flat-rate subscriptions, which bundle GLM-5.2 access into agentic coding tools (Claude Code, Cursor, Cline, and 20-plus others). As verified on [z.ai/subscribe](https://z.ai/subscribe) on June 20, 2026: | Tier | Monthly | Yearly (per mo) | Rough quota | |------|---------|-----------------|-------------| | Lite | $18 | $12.60 | ~80 prompts / 5 hrs | | Pro | $72 | $50.40 | ~400 prompts / 5 hrs | | Max | $160 | $112 | ~1,600 prompts / 5 hrs | The subscription wins when you code with it daily and would otherwise burn through far more than the flat fee in per-token charges. The API wins for spiky or automated workloads. Quotas are from Z.ai's [devpack FAQ](https://docs.z.ai/devpack/faq) and are stated per a rolling window, so check the current terms. ## Local and self-host Because the weights are MIT-licensed and on [Hugging Face](https://huggingface.co/zai-org/GLM-5.2), you can run GLM-5.2 with no per-token cost at all - if you have the hardware. ![Abstract systems illustration for Local and self-host](/images/blog/glm-5-2-free-and-cheap-access-2026/inline-2.webp) - **Ollama.** GLM-5.2 is published as `glm-5.2`. The currently surfaced tag is `glm-5.2:cloud`, which runs on Ollama Cloud GPUs rather than your machine. Community GGUF builds (Unsloth, llama.cpp) exist for true local runs, but at roughly 756B total parameters this is a datacenter-class model: even a 4-bit quant targets high-RAM multi-GPU rigs, not a laptop. If your goal is genuinely local coding on modest hardware, a smaller dense model is the better tool - see [the best local coding LLMs](/blog/best-local-coding-llms-2026). - **Self-host at scale.** The Hugging Face model card lists first-class support for vLLM (0.23.0+), SGLang, Transformers, KTransformers, and llama.cpp, plus Ascend NPU paths. `vllm serve "zai-org/GLM-5.2"` works out of the box. This only pays off above a high, steady token volume where amortized GPU cost beats per-token API pricing. Below that line, a hosted route is cheaper and far less operational work. ## Which route should you pick? - **Just trying it:** OpenCode Go with referral code `M6HEHM4JM5`, Devin Pro if you already pay for it, the Z.ai ZCODE free quota, or OpenRouter with a few dollars of credit. - **Cheapest production tokens:** OpenRouter's auto-router or DeepInfra, accepting fp4 quantization. Validate on your own task first. - **Daily agentic coding in a tool you live in:** the GLM Coding Plan (Lite or Pro), so cost is predictable. - **Highest control or compliance needs:** self-host on vLLM. Only worth it at steady high volume. - **Truly offline or air-gapped:** local weights, but budget for serious GPU memory or step down to a smaller model. ## FAQ ### Is GLM-5.2 free? GLM-5.2 is free or nearly free to use in a few specific places right now: OpenCode Go referral credits, bundled into Devin's paid Pro plan at no extra model cost, through Z.ai's ZCODE CLI free token quota, and via a limited Hugging Face Inference Providers window. The weights themselves are free under an MIT license, so self-hosting has no per-token cost. There is no permanent, unlimited free hosted API. ### What is the cheapest way to use GLM-5.2? On hosted APIs, the cheapest routes are OpenRouter's auto-router and DeepInfra, around $1.20 input and $4.10 to $4.20 output per million tokens (fp4 quantized). On a blended 3:1 mix, independent trackers put the cheapest hosts near $0.72 to $0.80 per million tokens. Self-hosting is cheapest only at high, steady volume. ### Can I run GLM-5.2 with Claude Code, Cursor, or OpenCode? Yes. The Z.ai GLM Coding Plan is built for exactly this and supports Claude Code, Cursor, Cline, and 20-plus tools. Model-agnostic open-source agents like [OpenCode](/blog/opencode-developer-guide-2026) are an especially good fit, since they let you point at any OpenAI-compatible endpoint (Z.ai API, Fireworks, OpenRouter) and swap models freely without leaving the tool. ### Can I run GLM-5.2 locally on my laptop? Not practically. At roughly 756B total parameters, even a 4-bit quant needs high-RAM multi-GPU hardware. Ollama's `glm-5.2:cloud` tag runs on hosted GPUs, not your machine. For local coding on consumer hardware, a smaller dense model is the right choice. ### What license is GLM-5.2 under? MIT. Some early posts claimed Apache 2.0, but Z.ai's blog, the Hugging Face model card, and provider pages all confirm MIT - permissive, with no regional or commercial restrictions. ## Sources - [Z.ai: GLM-5.2 research blog](https://z.ai/blog/glm-5.2) - [Z.ai subscribe (GLM Coding Plan tiers)](https://z.ai/subscribe) and [model API](https://z.ai/model-api) - [Z.ai devpack FAQ (quotas)](https://docs.z.ai/devpack/faq) - [OpenCode Go referral offer](https://opencode.ai/go?ref=M6HEHM4JM5) - [Hugging Face: zai-org/GLM-5.2 (weights, MIT, frameworks)](https://huggingface.co/zai-org/GLM-5.2) - [OpenRouter: z-ai/glm-5.2](https://openrouter.ai/z-ai/glm-5.2) and [endpoints API](https://openrouter.ai/api/v1/models/z-ai/glm-5.2/endpoints) - [Fireworks AI: GLM-5.2](https://fireworks.ai/models/fireworks/glm-5p2) - [DeepInfra: zai-org/GLM-5.2](https://deepinfra.com/zai-org/GLM-5.2) - [Devin (Cognition) pricing](https://devin.ai/pricing/) - [Ollama: glm-5.2](https://ollama.com/library/glm-5.2) - [Artificial Analysis: GLM-5.2 providers](https://artificialanalysis.ai/models/glm-5-2/providers)

GPT-5.5 Has a 3x Higher Hallucination Rate Than MIT-Licensed GLM-5.2

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

A new benchmark analysis from Arrow TSX is making the rounds on Hacker News, and the headline number is stark: **GPT-5.5 has an 86% hallucination rate on the AA-Omniscience benchmark, versus 28% for Z.ai's MIT-licensed GLM-5.2**. That is a 3x difference in how often these models make up answers when they do not actually know. ## What the Article Actually Says The [original piece](https://arrowtsx.dev/bigger-models/) is titled "Bigger models are not the way," and it uses hallucination data as evidence for a broader argument: that scaling up parameter counts is hitting diminishing returns. Here are the raw hallucination rates from the AA-Omniscience benchmark: | Model | Hallucination Rate | |-------|-------------------| | GLM-5.2 | 28% | | Claude Opus 4.8 | 36% | | Fable 5 | 48% | | GPT-5.5 | 86% | | DeepSeek V4 Pro | 94% | The methodology works like this: when a model does not know the answer to a question, it can either admit that or make something up. The hallucination rate measures how often it makes something up instead of saying "I don't know." The researchers tested models with a specific Python asyncio question that contains an architectural impossibility - there is no correct answer because the premise is flawed. They used a "high" reasoning effort setting, temperature 1, and the same system prompt across all models. Models were served on OpenRouter with FP8 precision. DeepSeek V4 Pro spent 3 minutes 52 seconds reasoning (7.7k tokens) and still produced a "confidently incorrect" answer. GLM-5.2 finished in 12 seconds (799 tokens) and correctly identified that the question described an impossible scenario. ## What Hacker News Is Saying The [discussion thread](https://news.ycombinator.com/item?id=48600167) is active with 85+ comments, and the conversation is more nuanced than the headline. Several commenters point out that **hallucination rate is a conditional metric**. It measures what happens when the model does not know - not the overall probability of encountering a hallucination in typical use. A model that knows more things would have fewer opportunities to hallucinate, even if its conditional hallucination rate is higher. One commenter laid out the math: "If a model A has 50 correct answers, 20 incorrect answers, and 30 abstentions, its hallucination rate is 40%, while a model with 20 correct answers, 20 incorrect answers, and 60 abstentions has a hallucination rate of 25%, even though it hallucinated exactly the same number of times." Others argue this framing is too generous to the larger models. If you ask a question the model cannot answer, the only correct response is "I don't know." Making up something plausible is still wrong, regardless of whether the model "knew" the answer somewhere in its weights. The "you're prompting it wrong" counterargument showed up: one commenter suggested that a well-crafted system prompt explicitly telling the model that "I don't know" is a valid answer could change these numbers significantly. But another pushed back: "You're prompting it wrong is quickly becoming the new 'you're holding it wrong.'" The thread also picked up on the article's bigger claim about scaling. If larger models and larger training sets have stopped producing proportional improvements, the S-curve thesis has real implications for how these companies are valued. One commenter noted: "That's huge news, considering the valuation of companies like OpenAI and xAI is largely based around the absurd idea of ever increasing scaling from these models." ## Why This Matters for Developers If you are building agents or workflows that rely on LLM outputs, these numbers translate directly into production reliability. An 86% hallucination rate when the model does not know means that roughly 9 out of 10 times you hit an edge case, you will get confident nonsense instead of a signal that you need to route elsewhere. The practical takeaways: **Model selection is not just about raw capability.** A model that is slightly less capable but much better calibrated - meaning it knows what it does not know - can be more useful in production than a model that is more capable but confidently wrong when it fails. **Open weights are winning on this metric.** GLM-5.2's 28% rate is nearly half of Opus 4.8's 36% and a third of GPT-5.5's 86%. This is a meaningful differentiator when you can self-host or route to API providers serving open weights. **System prompt design matters more than we thought.** If explicit instructions to admit uncertainty can move these numbers, then the agentic frameworks that bake in those instructions will have real reliability advantages. **The "bigger is better" assumption needs revisiting.** The DeepSeek V4 Pro result is particularly striking: 1.6 trillion parameters, nearly 4 minutes of reasoning, and still a 94% hallucination rate. More compute did not help here. For our model comparison content, see [GLM-5.2 vs DeepSeek V4 vs Qwen3](/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown) and [best AI coding tools for June 2026](/blog/best-ai-coding-tools-june-2026-post-fable5). ## Frequently Asked Questions ### What is a hallucination rate? On the AA-Omniscience benchmark, the hallucination rate measures how often a model makes up an answer instead of admitting it does not know. It is a conditional metric: it only counts cases where the model lacks the answer, so it is a measure of calibration, not overall accuracy. ### Is GLM-5.2 really more reliable than GPT-5.5? On this specific benchmark, yes: GLM-5.2 hallucinated 28% of the time it did not know an answer, versus 86% for GPT-5.5. That is a calibration result, not a blanket capability claim. GLM-5.2 is also MIT-licensed and open-weight, which is why you can self-host or route it cheaply. See [where to run GLM-5.2 free and cheap](/blog/glm-5-2-free-and-cheap-access-2026). ### Does a lower hallucination rate mean GLM-5.2 is the better coding model? Not on its own. Calibration is one axis; raw coding capability, context length, and cost are others. For the full picture see [GLM-5.2 vs DeepSeek V4 vs Qwen3](/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown) and the [GLM-5.2 cost math](/blog/glm-5-2-cost-math-open-weights-coding-models). ### Why does this challenge the "bigger is better" assumption? DeepSeek V4 Pro, a much larger model, posted a 94% hallucination rate despite nearly four minutes of reasoning on the test question. More parameters and more compute did not improve calibration here, which is the core of the original article's argument that scaling is hitting diminishing returns. ## Sources - [Original article: "Bigger models are not the way"](https://arrowtsx.dev/bigger-models/) - [Z.ai GLM-5.2 model card on Hugging Face](https://huggingface.co/zai-org/GLM-5.2) - [GLM-5.2 on Artificial Analysis](https://artificialanalysis.ai/models/glm-5-2) - [Hacker News discussion](https://news.ycombinator.com/item?id=48600167) - [Artificial Analysis Intelligence Index](https://artificialanalysis.ai/) (benchmark source referenced in article)

LLM Architectures Got Complicated Fast

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

The original transformer architecture from "Attention Is All You Need" (2017) was elegant. Feed-forward layers, multi-head attention, residual connections. You could sketch it on a napkin. That era is over. A [recent post by Ian Barber](https://ianbarber.blog/2026/06/19/llms-are-complicated-now/) argues that LLM architectures have crossed a complexity threshold similar to what happened with recommendation systems a decade ago. The simple stack that powered GPT-2 and early GPT-3 has been replaced by a maze of optimization techniques that are now load-bearing. ## What Changed Modern frontier models deploy a grab-bag of architectural innovations: **Attention variants everywhere.** Models now use "query grouping, compressed, sparse, linear, sliding-window" attention - sometimes multiple variants in the same model. Grouped Query Attention (GQA) alone has become standard because it dramatically reduces KV cache memory during inference. **Mixture-of-Experts routing.** MoE extends from feedforward blocks to the residual stream itself in recent architectures. DeepSeek-V3 routes to 256 experts per layer with only 8 active per token. The routing decision is trainable, introducing new failure modes. **Vision and audio encoders are no longer bolted on.** Early multimodal approaches treated vision as a separate tower feeding into a frozen language model. Current architectures weave modality encoders throughout the stack, with cross-attention at multiple layers. **Multi-GPU comms become architectural.** Once inference spans multiple GPUs, communication operations (all-reduce, all-gather) become part of the computation graph. Where you place a layer split matters for latency. ## Why It Happened Barber draws a useful parallel to recommendation systems. For most of the 2010s, recommendation models were relatively straightforward two-tower architectures with sparse embeddings. They got complicated when: > "The gap between performance being an optimization and performance being a necessity became very, very small." At scale, every percentage point of efficiency matters. The original transformer had known inefficiencies - quadratic attention scaling, dense activations, redundant computation. One by one, researchers found optimizations. Each optimization hardened into the baseline. The problem: once an optimization is load-bearing, you cannot easily experiment without it. Removing GQA from a modern model means you cannot fit the same context length. Removing MoE means you cannot match the same capabilities at the same inference cost. Barber puts it directly: > "You can't hand-fuse your way back without investing significant time that might not be worth it." ## What HN Is Saying The [HN discussion](https://news.ycombinator.com/item?id=48605355) surfaced several practical observations from people working with these models. One commenter tracking llama.cpp development noted the implementation gap: > "The earlier models were always fully implemented. Yet with more contributors, as of today tons of latest models only have partial implementation. DeepSeekv3.2 isn't fully implemented, same with KimiK2.6, GLM5.2+, DeepSeekv4 has no implementation, MiniMaxM3 not supported yet." The architectural diversity means inference libraries cannot keep up. Features that a model relies on may simply not exist in your preferred runtime. Another commenter framed it as the "bitter lesson lifecycle": > "When a technique or technology is new people are making massive gains by just applying it to some use case, or gathering more data for training. As time goes on those 'bitter lesson' gains start to hit the shallow part of the logistic curve and companies have to start investing more and more effort into engineering for each small, incremental gain." The easy scaling gains are behind us. What remains is feature engineering at the architecture level. ## The Composability Problem Barber highlights FlexAttention in PyTorch as a potential solution. FlexAttention lets you define custom attention patterns that compile down to efficient Triton kernels: ```python from torch.nn.attention.flex_attention import flex_attention, create_block_mask def causal_mask(b, h, q_idx, kv_idx): return q_idx >= kv_idx block_mask = create_block_mask(causal_mask, B, H, Q_LEN, KV_LEN) output = flex_attention(query, key, value, block_mask=block_mask) ``` The abstraction captures sliding window, causal, document masking, and custom patterns without hand-writing CUDA. Performance hits are mild (single-digit percentage overhead vs. hand-tuned kernels). This matters because it restores some ability to experiment. If attention is composable and fast, researchers can try new patterns without reimplementing everything from scratch. ## What This Means for Developers If you are building on top of LLMs rather than training them, three implications stand out: **Model selection is more than benchmarks.** Two models with similar scores on a benchmark may have very different architectural requirements. One may need 2x the VRAM for the same context length because it uses different attention. Check the architecture, not just the numbers. **Inference libraries are fragmented.** Llama.cpp, vLLM, TensorRT-LLM, and SGLang each support different model architectures to different degrees. A model's claimed features may not work in your runtime. Test with your actual stack. **Local deployment complexity is rising.** Running a 7B model locally in 2023 was straightforward. Running a current MoE model with the same parameter count requires understanding expert routing, activation memory, and potentially multi-GPU splits even at small scale. The upside: if architectural complexity is where the gains are, well-optimized inference is a genuine competitive advantage. Companies investing in inference engineering are not just saving compute costs - they are enabling capabilities that would otherwise be impractical. ## The Parallel to Web Frameworks There is an analogy in frontend development. React started simple - a render function, virtual DOM diffing, done. Then came hooks, concurrent rendering, server components, streaming, suspense boundaries. Each addition solved real problems at scale. Each addition made the mental model more complex. LLMs are following the same arc, just faster. The transformer paper is 9 years old. The complexity explosion happened in roughly 3 years. The question Barber poses is whether composable abstractions like FlexAttention can prevent this from becoming unmanageable. The alternative is that only large labs with custom CUDA kernels can push the frontier - a consolidation that would slow down the field. ## Sources - [LLMs Are Complicated Now](https://ianbarber.blog/2026/06/19/llms-are-complicated-now/) - Ian Barber - [HN Discussion](https://news.ycombinator.com/item?id=48605355) - 120+ points, 40+ comments - [LLM Architecture Gallery](https://sebastianraschka.com/llm-architecture-gallery/) - Sebastian Raschka's visual comparison tool - [FlexAttention Documentation](https://pytorch.org/docs/stable/nn.attention.flex_attention.html) - PyTorch

The Definitive Guide to Loop Engineering in Claude Code and Codex

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

Last updated: June 20, 2026. Loop features in Claude Code and Codex move fast. Treat this as a working field guide and confirm exact command behavior in the official docs linked below before you leave anything running unattended. The shift everyone keeps circling is real, and it is simpler than the discourse makes it sound. Stop being the thing in the loop. Write the goal, the loop, or the routine, give it a budget and a way to check itself, and go decide what to build next. That is loop engineering. Everything else is plumbing. This guide covers the whole thing: the one distinction almost everyone gets wrong, the real commands in both Claude Code and Codex, the patterns people are actually running in production, and the two failure modes that turn a clever loop into a money fire. ## Official Sources | Topic | Official source | |------|------------------| | Claude Code `/loop` and `/schedule` | [code.claude.com/docs](https://code.claude.com/docs) | | Claude Code Routines (web scheduled tasks) | [Web scheduled tasks docs](https://code.claude.com/docs/en/web-scheduled-tasks) | | Codex CLI | [developers.openai.com/codex/cli](https://developers.openai.com/codex/cli) | | Codex Automations | [Codex app automations](https://developers.openai.com/codex/app/automations) | | Codex `exec` (non-interactive) | [Non-interactive mode](https://developers.openai.com/codex/noninteractive) | | The Codex agent loop, unrolled | [OpenAI: unrolling the Codex agent loop](https://openai.com/index/unrolling-the-codex-agent-loop/) | | Loop engineering, the term | [Addy Osmani: Loop Engineering](https://addyosmani.com/blog/loop-engineering/) | | Forward Future Loop Library | [signals.forwardfuture.ai/loop-library](https://signals.forwardfuture.ai/loop-library/) | ## First, the three verbs (this is where everyone trips) The cleanest framing going around separates three things people constantly collapse into one word: - **Goal**: keep working until the outcome is achieved, then stop. - **Loop**: keep repeating a task while I am here, hands on. - **Routine**: keep working while I am gone. Get the verb right and every pattern in this guide falls into place. Get it wrong and you either leave a hands-on loop running into an empty room, or you point a "while I sleep" routine at a task that needed you watching. The verb is the design decision. The command is just syntax. Here is how each verb maps to a real command in each tool. ### Goal: run until a condition is true, then stop In Claude Code this is `/goal`, shipped in v2.1.139. ``` /goal all tests in test/auth pass and the lint step is clean ``` The important part is not that it loops. The important part is *who decides it is done*. After every turn, Claude Code sends the condition plus the transcript to a separate, small, fast model (Haiku by default) that acts as a judge. That judge returns yes or no with a reason. On no, Claude reads the reason and takes another turn. On yes, the goal auto-clears and the run stops. This is the single most important idea in the whole field, so it is worth saying plainly: the worker does not grade its own homework. A separate model does. We will come back to why that matters more than anything else. Check status any time with a bare `/goal`. Clear an active goal with `/goal clear`. Bound it with a turn cap baked into the condition itself, for example "or stop after 20 turns." You can also run it headless: ```bash claude -p "/goal CHANGELOG.md has an entry for every PR merged this week" ``` Codex shipped its own goal-style controls in CLI v0.128.0, with set, pause, resume, and clear. The shape is the same: a verifiable end state, a checker, and a stop. ### Loop: repeat while you watch In Claude Code this is `/loop`, and it lives only inside your open session. ``` /loop 5m check the deploy ``` Two modes. With an interval it runs on a timer (`5m`, `30m`, `2h`), rounding odd values to the nearest cron boundary. Without an interval it self-paces: Claude watches the output and picks the next delay itself, anywhere from one minute to an hour, printing the reason for each wait. Press Esc to cancel while it waits. A bare `/loop` with no prompt runs a built-in maintenance pass (git and PR triage plus cleanup). You can override that default by dropping a `loop.md` into `.claude/` for the project or `~/.claude/` globally. Three things to remember about `/loop`: it is session-scoped and dies when you close the session, it only fires when the session is idle, and forgotten loops auto-expire after seven days. It is the tool for watching something, hands on, right now. We have a deeper walkthrough in [Claude Code Loops: recurring prompts that actually run](/blog/claude-code-loops). Codex has no `/loop` command yet. Its equivalent is `codex exec` wrapped in a shell loop, or a minute-interval thread automation in the Codex app. ### Routine: run while you are gone In Claude Code this is `/schedule`, and it runs on Anthropic's cloud, not your laptop. ``` /schedule daily PR review at 9am ``` A routine is durable. It survives your machine being closed, clones a fresh copy of your repo each run, and works on `claude/`-prefixed branches. It can be triggered three ways: on a cron schedule (minimum one-hour interval), on a GitHub webhook (PR opened, labeled, released, and so on), or via a dedicated API endpoint. Manage them with `/schedule list`, `/schedule update`, and `/schedule run`. Full transcripts land at claude.ai/code/routines. Codex's equivalent is Automations in the Codex app: standalone, project, or thread automations on daily, weekly, or custom cron schedules, with results landing in a Triage inbox. One trap that comes up constantly: there is no `/routine` command in either tool. In Claude Code the scheduler is `/schedule`; in Codex it is Automations. We compare where this work should actually live in [Claude Code Routines vs Managed Agents schedules](/blog/claude-code-routines-vs-managed-agents-schedules). ### The one table to remember | | `/goal` | `/loop` | `/schedule` | |---|---|---|---| | Verb | until done | while I watch | while I am gone | | Runs on | your machine | your machine | Anthropic cloud | | Needs open session | yes | yes | no | | Stops itself | yes, on verified condition | optional (self-paced) | on schedule end | | Min interval | n/a | 1 minute | 1 hour | | Best for | fix until tests pass | watch a deploy | nightly PR sweep | ## The patterns people are actually running The commands are easy. The interesting part is what people point them at. Here are the loop shapes that keep surfacing across X, Reddit, GitHub, and the demo circuit, grouped by verb, rewritten as something you can paste tonight. ### 1. The build-test-fix pair (loop) The most-demoed loop of all. Two roles: a builder that writes code and a checker that runs the tests, types, and lint, then reports exactly what broke. They pass work back and forth until it is clean. The whole pitch is the pain it kills, because a one-shot agent ships its own bugs without ever noticing. ``` /loop build the next item on the plan, then run tests, typecheck, and lint. Feed every failure back as the next instruction and fix it. Stop when the build is green and the checker has nothing left to report. ``` ### 2. The verifier loop (loop) This is the pattern Boris Cherny, who built Claude Code, keeps describing. In a widely shared [interview](https://www.youtube.com/watch?v=RkQQ7WEor7w) he put it bluntly: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." The loop he describes runs the coding agent plus an advanced model plus a verifier, feeds it tasks, and removes bottlenecks as you go. The verifier is the part everyone skips, and without it you are just trusting the agent. Addy Osmani named the broader practice [loop engineering](https://addyosmani.com/blog/loop-engineering/), building on Peter Steinberger's line that you should be designing loops that prompt your agents rather than prompting them yourself. ``` /loop work the task list. After each task, have a separate verifier model check the result against the spec and the tests. Only move on when it passes. Surface anything the verifier rejects twice. ``` We unpack his workflow in [Codex Loops: what Boris Cherny gets right about managing agent work](/blog/codex-loops-boris-cherny-agent-routines). ### 3. The five-minute repository maintainer (loop) Peter Steinberger runs a version of this on a tight timer while he works. Every five minutes the agent does one small, verified piece of upkeep. Crucially, *what* to clean is the agent's call, not a hardcoded script. That decision is the entire point. ``` /loop 5m make one small verified repository improvement: a flaky test, a stale comment, a missing type. One change, one commit, tests green. Never touch anything risky. ``` ### 4. The plan-generate-verify-fix loop (goal) The bounded version that fixes the runaway problem cold: plan, generate, verify, fix, repeat, with state saved to files and a hard iteration cap. You only read the final version. The cap is what makes it safe to walk away from. ``` /goal plan the task, implement it, verify against the tests, and fix what failed. Save state to files each pass. Max 5 iterations. Stop at the first clean pass or when the cap is hit, and tell me which. ``` ### 5. The quality streak loop (goal) The one that respects how flaky "it works" really is. It does not stop at the first green run. It tests realistic scenarios and only declares victory after a streak passes in a row. One green run is luck. A streak is reliability. ``` /goal run the full product test suite against realistic scenarios. Fix whatever fails, then run again. A new failure resets the count. Done only after 10 consecutive clean passes. ``` ### 6. The production error sweep (goal) High utility, and the value is entirely in the triage. It reads your production logs, separates real actionable errors from noise, fixes the actionable ones with a regression test, and opens a PR. Tell it what "actionable" means or it chases ghosts. ``` /goal review the last 24h of production errors. For each one that is actionable and reproducible, write a fix with a regression test and open a PR. Ignore transient and third-party noise. Done when the actionable list is clear. ``` ### 7. The post-commit review loop (shipped tool) A class of open-source tools now installs a git hook so every commit triggers a background review, then feeds the findings straight into an agentic fix loop while the context is still warm. It is the installable version of the one thing this whole guide argues is the hard part: a verifier living inside the loop. The pattern plugs into Claude Code, Codex, and Gemini CLI. ``` init # adds a post-commit hook: every commit triggers a review fix # the agentic loop that fixes the surfaced findings ``` ### 8. The overnight PR routine (routine) The shape behind "I do not write code anymore, I write loops, and they write the code while I sleep." A scheduled routine that watches your open PRs and lands the fixable ones overnight, leaving anything ambiguous for you. ``` /schedule every night, watch my open PRs. Auto-fix build failures, answer review comments in a fresh worktree, and rebase what is stale. Leave anything ambiguous for me. State in git so a crash loses nothing. ``` More on this in [Overnight agents: the workflow](/blog/overnight-agents-workflow) and [Claude Code autonomous hours](/blog/claude-code-autonomous-hours). ### 9. The production inbox loop (routine) The rare community post that ships a whole production loop instead of a demo: an email agent that loops an inbox on a schedule, classifies and drafts replies for the routine cases, and escalates only what needs a human. The guardrail is hardcoded. ``` /schedule every 15 minutes, pull new emails, classify each, and draft a reply for the routine ones. Queue anything sensitive for me and log every decision. Never auto-send a refund or a booking change. ``` ### 10. The human-in-the-loop approval queue (loop) The most practical no-code pattern. The workflow runs, then pauses and pings you with approve, revise, or skip. Same loop shape as build-test-fix, but the stop condition is your approval instead of a passing test. ``` /loop run the task, then pause and send me approve / revise / skip before anything ships. On approve, continue. On revise, take my note and redo. On skip, move to the next item. ``` ### 11. The adversarial review loop (goal) The strongest reliability pattern: have one model family review another model family's pull requests before merge, so two independent sets of weights have to agree before code lands. Cap the argument so it cannot spin forever. ``` /goal implement the task, then have a second, different model review the diff against the spec. Iterate up to 5 rounds. Only pass work both models agree is correct. Report any disagreement you could not resolve. ``` ## The goal-meta-skill: the highest-leverage move The single highest-leverage habit is not a fancy loop. It is rewriting your request into a rigorous goal before any work starts. Most agents are not dumb, the instructions are just vague. So make the agent specify the result, how it will verify it, what not to touch, and when to stop, before it does anything. ``` /goal before doing anything, rewrite my request into a precise goal: the exact end state, how you will verify it, what you must not touch, and the stop condition. Confirm that goal, then execute against it. ``` A good `/goal` condition has four parts: one measurable end state (a test exit code, an empty queue, a clean `git status`), proof of how the agent demonstrates it, the constraints that must hold, and an optional turn or time bound. The condition field caps at 4,000 characters, which is more than enough for a precise contract and a deliberate forcing function against vagueness. ## The part the hype skips: a loop is a money fire with a verifier on top Across every platform, the same two warnings come back. They are the whole reason most loops fail, and they are funnier in the community's words than in any vendor's docs. ### Warning one: cost The romantic version of loops is "a thousand agents build my company overnight." The production version is a bill. The community is full of these stories. Enterprises have started capping per-engineer, per-tool monthly spend after burning through annual AI budgets in a single quarter. Individual developers have posted about torching thousands of dollars overnight with one command. The figures vary and many are hard to verify independently, but the direction is consistent and the mechanism is obvious: a loop with no ceiling will happily spend until your tokens run out. The best one-line summary of the whole movement is a developer joke written as code: ``` while (you have tokens): burn them in a loop ``` So every goal gets a budget and every loop gets a cap. Goal conditions can carry "or stop after N turns." Routines run with a daily ceiling. Set the ceiling before you walk away, not after the email arrives. We wrote the full incident-driven version of this in [The $400 overnight bill: why managed agents need FinOps now](/blog/400-dollar-overnight-bill-agent-finops). ### Warning two: verification is the entire game A loop that cannot tell good output from bad does not save you work. It produces wrong answers faster. This is the single most important sentence in loop engineering: writing the loop is easy, the verifier inside it is the hard part. An open loop, a loop with no verifier, fails in predictable, expensive ways: compounding errors, hallucinated progress, silent failures, goal drift, and the doom loop where the agent retries the same broken approach with cosmetic variations. A verifier closes the loop. It is anything that checks a result against an expected outcome: a compiler, a test runner, a linter, a diff check, a second model as judge, or a human approval gate. The useful rule of thumb is that the verifier should be cheaper and more reliable than the action it checks. This is exactly why `/goal` runs a separate small model as judge instead of letting the worker grade its own work, and why every strong loop in this guide (the verifier loop, the build-test-fix pair, the adversarial review) puts a second, independent set of eyes inside the loop. An agent grading itself will delete the failing test and call it done. The skeptics who keep pointing this out are right, and listening to them is what keeps a loop honest. The skeptics also have a fair point about the scheduling layer: yes, the cron part really is just cron. But cron never had a decision-maker in the body that reads the state, acts, checks whether it worked, and decides whether to keep going. That decision is the genuinely new thing. Everything else is plumbing. We traced where this idea came from in [The loopy era: Karpathy, Codex, and agentic engineering](/blog/karpathy-loopy-era-codex-agentic-engineering). ## Where to find vetted loops The fastest way to get good loops without designing them yourself is a curated catalog. Matthew Berman's [Forward Future Loop Library](https://signals.forwardfuture.ai/loop-library/) is the one worth raiding: dozens of copy-paste loops across engineering, evaluation, operations, content, and design, each with a clear goal, a bounded action, a fixed check, and explicit stop conditions. The catalog is agent-native, with `llms.txt` and `catalog.json` surfaces, an [open repo](https://github.com/Forward-Future/loop-library), and an installable skill: ```bash npx skills add Forward-Future/loop-library --skill loop-library -g ``` The signal there is the vetting, not a like count. When you want a loop running tonight without designing the plumbing, start from a vetted one and adapt it. ## How to start tonight You do not need every pattern above. The whole field keeps converging on three moves, one of each verb: 1. Run the **build-test-fix pair** as a `/loop` so something measurably improves while you watch. 2. Run the **five-minute maintainer** as a `/loop` while you work on something else. 3. Run the **overnight PR routine** as a `/schedule` so you wake up to finished work. Give each one a budget and a verifier. That is a working loop stack by tomorrow morning. Then graduate the watched loops to `/goal` conditions once you trust the verifier, and move the durable ones to `/schedule` once you trust the budget. The shift is real and it is not complicated. Write the goal, the loop, or the routine. Give it a budget and a way to check itself. Then go decide what to build next.

The Router Era: Why Not Owning a Frontier Model Became an Advantage

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [Factory: Factory Router](https://factory.ai/product/router) | Documented automatic model-selection architecture | | [OpenRouter: How model routing works](https://openrouter.ai/blog/insights/model-routing/) | Provider routing, price ceilings, fallback chains | | [a16z: The State of Generative Media 2026](https://a16z.com/the-state-of-generative-media-2026/) | "No one model to rule them all," orchestration thesis | | [Simon Willison: GLM-5.2](https://simonwillison.net/2026/jun/17/glm-52/) | Concrete open-weights price spread across providers | | [SemiAnalysis: AI value capture](https://newsletter.semianalysis.com/p/ai-value-capture-the-shift-to-model) | The counter-argument: value shifting back to labs | For two years the assumed winners of the AI build-out were the labs with the best single model. That assumption is quietly breaking. By mid-2026 there is a top coding model, a top reasoning model, a top agentic-terminal model, a top open-weights model, and a top value model, and none of them are the same system. When capability fragments like that, the company that picks the right model per task can beat the company that owns any one model. Optionality becomes the product. This post is about the layer that makes optionality real: the model router. It covers how routing actually works under the hood, why open weights and a new tier of GPU clouds make it cheap, who is building on it (Factory, Cognition's Devin, Perplexity, Cursor, Windsurf, OpenCode), and the honest case that this thesis is overstated. **Last verified:** June 20, 2026. ## No single model wins everything The clearest signal is the spread of per-task leaders. As of mid-June 2026, the independent and vendor-reported benchmark picture looks roughly like this, and the point is the diversity, not any one number: - **Reasoning and overall:** Claude Opus 4.8 sits at the top of the Artificial Analysis Intelligence Index, and is also the most expensive at $5 / $25 per million tokens. - **Agentic terminal work:** GPT-5.5 leads Terminal-Bench. - **Tool use:** Kimi K2.7 Code posts the highest MCP-Mark score, reportedly ahead of Opus 4.8 on that specific benchmark, at a fraction of the price. - **Leading open weights:** Z.ai's [GLM-5.2](/blog/glm-5-2-free-and-cheap-access-2026) tops the open-weights Intelligence Index and ranks second on Code Arena's web-dev leaderboard. - **Value frontier:** DeepSeek V4 and Gemini 3.1 Pro anchor the cheap-but-capable corner. Cross-check any single figure against [Artificial Analysis](https://artificialanalysis.ai/) before quoting it, because vendor-reported scores drift. But the shape is not in dispute. a16z's [State of Generative Media 2026](https://a16z.com/the-state-of-generative-media-2026/) puts it bluntly: there is "no one model to rule them all," and enterprise production deployments already use a median of 14 different models. Their framing of the consequence is the thesis of this whole post: "The unit of work isn't one model, it's a workflow," and the orchestration layer "matters as much as the models themselves." When releases land at the pace they did this June - several significant open-weights models in the first two weeks alone - betting your product on one model is a standing liability. Routing is how you stop betting. ## What a model router actually does "Router" gets used loosely, so it helps to separate two distinct jobs, because most real systems do both: ![Abstract systems illustration for What a model router actually does](/images/blog/model-routers-optionality-advantage-2026/inline-1.webp) 1. **Model selection:** given this task, which model should answer? 2. **Provider selection:** given that model, which host should serve it, at what price and latency, with what fallback? [OpenRouter](https://openrouter.ai/blog/insights/model-routing/) is the cleanest public example of the second job. Its June 2026 write-up describes routing every request across 70-plus providers while the caller controls "the provider order, the price ceiling, and the fallback chain." The motivating failure mode is stated plainly: "If Anthropic rate-limits you mid-traffic, your app shouldn't return a 500." Modes like `:nitro` (optimize latency) and `:floor` (optimize price) and an automatic fallback chain turn provider choice into a dial rather than a hard dependency. [Factory](https://factory.ai/product/router) is a clear example of the first job, and its documentation is unusually specific about the mechanism. Factory Router runs a fast classifier (around two seconds) over the first user message, recent tool calls, and repository signals, then emits a quality-probability score per candidate model. Those signals are weighted - the message itself, recent tools, repo size, language mix, and difficulty - candidate models are sorted from cheapest to most expensive, and the cheapest model that clears a quality threshold wins. It also documents auto-failover across providers. Factory's own benchmarks claim it holds frontier pass rates while cutting cost by around 25 percent. Treat that figure as vendor-reported: it is measured on Factory's internal suites relative to Claude Opus, not independently verified. The common pattern across both: spend a cheap model on easy tasks, escalate to an expensive one only when the work demands it, and never let a single provider outage take you down. ## The optionality advantage in practice The companies leaning hardest into this share a trait: none of them trained a frontier model, and they treat that as a feature. - **Cognition's Devin** is explicitly model-agnostic. Cognition's own developer advocate framed the payoff after GLM-5.2 shipped: a model-agnostic platform gets "immediate access to the latest models as soon as they ship without having to lift a finger." That post also describes GLM-5.2 as free inside Devin at the time of writing. Worth a caveat: the exact terms of that "free" access (duration, caps) are not spelled out in a primary Cognition pricing doc, so confirm current terms on [Devin's pricing page](https://devin.ai/pricing/) before planning around it. The structural point stands regardless - a model-agnostic agent adopts a new best-in-class model on day zero. - **Perplexity** routes across proprietary, third-party, and open models, and its "Best" mode "automatically selects the ideal model for your query," with its in-house Sonar model handling the latency-sensitive path. Whatever you think of any one answer, the architecture is optionality by default. - **Cursor and Windsurf** route across Claude, GPT, and Gemini and expose a per-task model picker, so a developer can send a refactor to one model and a tricky reasoning task to another. The contrast with first-party tools is the whole story: Claude Code is excellent and deliberately locked to Anthropic's models, which is a different bet than "use whoever is best this month." - **OpenCode** is the open-source, model-agnostic coding agent in the same family. Because it points at any OpenAI-compatible endpoint, it lets an individual developer get the same optionality the platforms have - swap from a frontier model to GLM-5.2 on OpenRouter without changing tools. See the [OpenCode developer guide](/blog/opencode-developer-guide-2026) for setup. The through-line: when you are not married to a lab, every new model release is an upgrade you get for free instead of a competitor you have to answer. ## Why open weights and neoclouds make it cheap Routing across labs would be a thin advantage if every model cost the same. Open weights break that, because anyone can host an open model and compete on price. The cleanest evidence comes from Simon Willison's [June 17 write-up](https://simonwillison.net/2026/jun/17/glm-52/): GLM-5.2 was available "via OpenRouter, which has it from 9 different providers, almost all charging $1.40/M input and $4.40/M output. For comparison, GPT-5.5 is $5/$30 and Claude Opus 4.5 to 4.8 is $5/$25." Nine independent hosts converging on one low price for one open model is optionality and price competition in a single screenshot. The full provider and pricing breakdown is in the [GLM-5.2 access guide](/blog/glm-5-2-free-and-cheap-access-2026). The supply side of that competition is the "neocloud" tier - GPU clouds like CoreWeave, Lambda, Crusoe, Nebius, and inference specialists like Fireworks, Together, and DeepInfra that rent compute and serve open models against the hyperscalers. This is now a real market, not a fringe: CoreWeave alone reported quarterly revenue around $2.1 billion, roughly doubling year over year. More hosts racing to serve the same open weights is exactly what pushes per-token prices toward the floor. a16z's data backs the incentive: 58 percent of organizations name cost optimization as their primary criterion when choosing model infrastructure, ahead of raw availability or speed. ## The honest counter-argument This thesis can be oversold, and a careful builder should hold the other side too. ![Abstract systems illustration for The honest counter-argument](/images/blog/model-routers-optionality-advantage-2026/inline-2.webp) - **Value may be shifting back to the labs, not away.** [SemiAnalysis argues](https://newsletter.semianalysis.com/p/ai-value-capture-the-shift-to-model) that agentic AI drove a step-change in the value of tokens, which can pull margin and leverage toward whoever trains the best models rather than the routing layer on top. If one lab opens a durable capability gap, optionality matters less. - **Falling per-token prices do not always mean falling bills.** The "intelligence too cheap to meter" line is real at the unit level, but agentic workloads spend dramatically more tokens per task, so total cost can rise even as price per token drops. Routing helps here, but it is not a free lunch. - **Routing adds its own failure surface.** A classifier that picks the wrong model, or silently downgrades a hard task to a cheap model to hit a cost target, can be worse than just using a strong default. The 25-percent-savings claims are vendor benchmarks; your mileage depends on your task mix. - **First-party lock-in buys real integration.** Tools tied to one lab can co-design the model and the harness together. That tight coupling is a genuine advantage for some workflows, which is why Claude Code stays single-lab on purpose. The balanced read: optionality is a strong structural position in a fragmented market, not a guaranteed win. It pays off most when no single model dominates - which describes mid-2026 well, and may or may not describe 2027. ## What this means if you are building - **Default to a router, not a model.** Whether it is OpenRouter at the API layer, Factory's automatic selection, or a model-agnostic agent like OpenCode or Devin, design so swapping models is a config change, not a rewrite. - **Use the cheap-to-expensive escalation pattern.** Send easy work to a cheap or open model and reserve frontier models for tasks that earn the cost. That is what the good routers do automatically. - **Keep a fallback chain.** Provider outages and rate limits are routine. A documented fallback is cheap insurance. - **Re-benchmark on your own tasks monthly.** With multiple significant models shipping per week, last month's best pick is an assumption worth re-testing. The frontier labs will keep mattering. But the quiet winners of this phase may be the companies that never trained a model and instead got very good at choosing one. ## FAQ ### What is an AI model router? A model router is a layer that decides which model should handle a given request and, often, which provider should serve it. Some routers select by task (cheap model for easy work, frontier model for hard work), and some select by provider (cheapest or fastest host, with automatic failover). Tools like Factory Router select by task; OpenRouter primarily routes across providers. ### Why is being model-agnostic an advantage? Because no single model is best at everything in 2026, a model-agnostic tool can route each task to the strongest option and adopt new models the day they ship, without re-engineering. Platforms like Devin, Perplexity, Cursor, and OpenCode are built this way, which is how they offered GLM-5.2 access almost immediately after release. ### How do open weights lower cost? When a model's weights are open, any provider can host it and compete on price. GLM-5.2, for example, was served by nine providers on OpenRouter at roughly $1.40 input and $4.40 output per million tokens, versus $5 / $25 to $30 for comparable closed models. Competition among hosts pushes the price toward the cost of compute. ### What are neoclouds? Neoclouds are GPU-focused cloud providers - CoreWeave, Lambda, Crusoe, Nebius, and inference specialists like Fireworks, Together, and DeepInfra - that rent compute and serve open-weights models in competition with the hyperscalers. They are a big reason open-model inference keeps getting cheaper. ### Is the optionality thesis guaranteed to win? No. The counter-case is real: value may shift back toward whoever trains the best models, total token spend can rise even as per-token prices fall, and routing adds its own failure modes. Optionality is strongest while capability stays fragmented, which describes mid-2026 but is not guaranteed to hold. ## Sources - [Factory: Factory Router](https://factory.ai/product/router) - [OpenRouter: How model routing works](https://openrouter.ai/blog/insights/model-routing/) and [provider selection docs](https://openrouter.ai/docs/guides/routing/provider-selection) - [a16z: The State of Generative Media 2026](https://a16z.com/the-state-of-generative-media-2026/) - [Simon Willison: GLM-5.2](https://simonwillison.net/2026/jun/17/glm-52/) - [Perplexity: which AI models are included](https://www.perplexity.ai/help-center/en/articles/10354919-what-advanced-ai-models-are-included-in-my-subscription) - [Devin (Cognition) pricing](https://devin.ai/pricing/) - [SemiAnalysis: AI value capture, the shift to model labs](https://newsletter.semianalysis.com/p/ai-value-capture-the-shift-to-model) - [Artificial Analysis](https://artificialanalysis.ai/) - [Network World: neoclouds challenge hyperscalers](https://www.networkworld.com/article/4011187/neoclouds-roll-in-challenge-hyperscalers-for-ai-workloads.html)

How to Track SEC Filings and Insider Trades (and What Each Form Actually Means)

Developers Digest — Sat, 20 Jun 2026 00:00:00 GMT

Public companies are required to tell the truth in writing, on a schedule, to the SEC. That paper trail is the single best free source of signal on a business: how it is performing, what just changed, and whether the people who run it are buying or selling their own stock. The problem is the raw system. SEC EDGAR holds millions of documents behind form codes like 10-K, 8-K, and Form 4. If you do not already know what those mean, the firehose is useless. Here is the practical version: what each filing type tells you, how to read insider activity, and a free live feed to follow it across the largest public companies. ## The filings that matter, in plain language You do not need to know all 100-plus form types. Five buckets cover almost everything worth watching. ### 10-K: the annual report The audited, once-a-year, full picture. Financial statements, risk factors, and a plain-language review of the business from management. If you only read one document about a company, read this. It is long on purpose. The risk factors section alone often tells you more than any earnings headline. ### 10-Q: the quarterly report The unaudited update between annual reports, filed three times a year. This is the fastest read on whether revenue, margins, and cash are trending the right way. Compare it to the same quarter last year, not the previous quarter, so seasonality does not fool you. ### 8-K: the major event Filed on demand whenever something material happens: earnings releases, executive departures, acquisitions, big contracts, or restructurings. An 8-K is the company saying "you should know this before our next scheduled report." When you see a cluster of 8-Ks, something is going on. ### Form 4: the insider trade Filed within two business days when a director, officer, or large owner buys or sells the company's stock. This is the closest thing to watching how insiders themselves are positioned. More on reading these below. ### S-1 and 13D/13G: registrations and ownership stakes An S-1 is a private company registering to go public, the first real look at its financials before an IPO. A 13D or 13G is filed when an investor crosses 5% ownership: 13D signals an active or activist stake, 13G a passive one. Both are worth a look when a new large holder appears. ## How to actually read insider trades Form 4 is the most misunderstood filing, so it is worth slowing down. When an insider transacts, the Form 4 reports the person, the date, a transaction code, the number of shares, and the price. The two codes you will see most: - **P (purchase) and S (sale)** are open-market trades. An open-market purchase is the strongest signal, because the insider is spending their own money at the current price with no obligation to do so. - **M, A, and F** relate to options, grants, and tax withholding. A "sale" that is really an automatic tax withholding on a vesting grant is not the same as an executive choosing to sell. Read the footnotes. A few rules of thumb: - Open-market buys by multiple insiders at once are rare and meaningful. - Routine selling under a pre-arranged 10b5-1 plan is normal and usually not a signal. The Form 4 footnotes will say if a plan was in place. - One insider's trade is noise. A pattern across several insiders is information. The point is not to copy insiders. It is to notice when the people with the most information are doing something out of the ordinary. ## A free live feed for all of it Reading one filing is easy. Keeping up with the flow across hundreds of companies is the hard part. That is the gap we built for. The [Developers Digest markets section](/markets) indexes SEC filings across the largest public companies and links every document straight back to its source on SEC EDGAR. Two views do most of the work: - The [latest filings feed](/markets/filings) shows the newest disclosures across all tracked companies, newest first, with a NEW badge on anything filed in the last day. Filter to annual reports, quarterly reports, major events, or insider trades with one tap. - Each company has its own filings page with the full history, filters by type and year, and a jump-to-peers strip so you can hop from one company to its competitors. For example, Tesla's page links straight to Ford, GM, Rivian, and the rest of the automakers. Every row opens the original filing on SEC EDGAR in a new tab, so you are always one click from the primary source. We index and organize; the SEC remains the system of record. ## Where to go deeper - [SEC EDGAR full-text search](https://www.sec.gov/edgar/search/) for searching across filings by keyword, back to 2001. - The [SEC's own guide to reading a 10-K](https://www.sec.gov/oiea/investor-alerts-and-bulletins/how-read-10-k) is short and genuinely useful. - [SEC Forms list](https://www.sec.gov/forms) if you hit a form code not covered here. ## FAQ ### What are SEC filings? SEC filings are documents that public companies are legally required to submit to the U.S. Securities and Exchange Commission. They cover financial results, major corporate events, insider trades, and ownership changes, and they are the primary public record of how a company is performing. ### How do I track insider trading? Watch Form 4 filings. Each one reports a director, officer, or major holder buying or selling shares within two business days of the trade. Focus on open-market purchases (code P), look for patterns across multiple insiders, and read the footnotes to separate real decisions from routine plan sales and tax withholding. ### Are SEC filings free to access? Yes. All filings are free on SEC EDGAR, the SEC's official electronic filing system. Tools like the Developers Digest markets feed organize that public data and link back to the original documents. ### What is the difference between a 10-K and a 10-Q? A 10-K is the audited annual report with complete financial statements and risk factors. A 10-Q is an unaudited quarterly update filed three times a year. The 10-K is more thorough; the 10-Q is more timely.

Codex: Record & Replay in 9 Minutes

Fri, 19 Jun 2026 02:42:37 GMT

OpenAI Codex ‘Record & Replay’: Turn Screen Recordings Into Reusable Automation Skills The script explains a new OpenAI Codex feature, Record and Replay, which lets you record a recurring computer or...

DuckDB Internals: What Makes It So Fast

Developers Digest — Fri, 19 Jun 2026 00:00:00 GMT

## The SQLite of Analytics DuckDB has quietly become one of the most influential database technologies in the past few years. A new deep dive from Greybeam explores exactly why this embedded analytical database consistently punches above its weight - regularly matching or outperforming clusters that cost millions annually. The core insight: DuckDB eliminates entire categories of overhead that traditional databases take for granted. ## Six Architectural Decisions That Matter The article identifies six key design choices that compound into DuckDB's performance: **1. In-Process Execution** DuckDB runs as a library inside your application, not as a separate server. This eliminates TCP serialization overhead entirely. When you query PostgreSQL or MySQL, every result set gets serialized, sent over a socket, and deserialized. DuckDB skips all of that - your data stays in process memory. **2. Columnar Storage with Compression** Data is organized by column rather than row. This matters because analytical queries typically touch a few columns across many rows. If you're computing `SELECT AVG(price) FROM orders`, DuckDB reads only the price column. A row-oriented database reads entire rows just to get one field. Each column is divided into row groups of up to 122,880 rows with associated metadata for efficient scanning. **3. Zone Maps for Data Skipping** Every row group maintains min/max statistics. When you filter with `WHERE date > '2026-01-01'`, DuckDB checks these statistics first and skips entire row groups without reading them. This is similar to how Snowflake handles micro-partition pruning - except DuckDB does it on your laptop. **4. Vectorized Execution** Instead of processing rows one at a time, DuckDB processes 2,048-row batches. This approach better utilizes CPU caches and SIMD instructions. The difference is substantial - batch processing amortizes function call overhead and improves branch prediction. **5. Morsel-Driven Parallelism** Multiple threads process independent data segments simultaneously. Each thread maintains local state to avoid lock contention, then results are merged. This scales naturally across available CPU cores. **6. Optimistic MVCC** DuckDB uses an optimistic concurrency model that assumes conflicts are rare, reducing locking overhead for analytical workloads where writes are infrequent. ## Query Optimization in Milliseconds The article notes that DuckDB applies approximately 33 distinct optimization passes to queries, including: - **Filter pushdown**: Moving WHERE predicates closer to data scans for early row elimination - **Join order optimization**: Using dynamic programming to find optimal join sequences - **Dynamic join-filter pushdown**: Pushing join key bounds back into probe-side scans The entire optimization phase typically completes in milliseconds - fast enough that query planning never becomes a bottleneck. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48553388) has 108+ comments and reveals how developers are actually using DuckDB in production. **The Pandas Replacement Story** Multiple commenters describe abandoning Pandas for DuckDB: > "It just replaced pandas for me. It's just so much easier to write SQL against CSV/JSON/whatever format data in jupyter/marimo notebooks through duckdb rather than reasoning through pandas." The ergonomics argument comes up repeatedly. DuckDB's ability to query files directly - `SELECT * FROM 'data.json'` - eliminates an entire ETL step that traditional workflows require. **The 100MB - 100GB Sweet Spot** One commenter offers practical sizing guidance: > "Basically like a locally hosted Snowflake - it only shines if you have enough data to analyze (100 MB - 100 GB is probably the sweet-spot range - less than that and the benefits are small, more than that and you risk flying too close to the sun with memory usage)." Several users push back on this upper bound, noting that DuckDB's disk spilling has improved significantly and can handle larger datasets with appropriate configuration. **Claude Code Integration** An interesting thread discusses using DuckDB alongside AI coding assistants: > "Recently at work I've been using it to analyse the Claude code sessions of every engineer at our company (that we upload to S3) and it's been extremely helpful to help us find gaps in devex." The combination of DuckDB's SQL interface with LLM-generated queries appears to be a growing pattern for ad-hoc data exploration. **The Snowflake Reality Check** Perhaps the most pointed comment: > "My last company was spending $2M/yr on contract with Snowflake, and another million between Fivetran and Matillion. Of the 1200 clients using analytics maybe 2 had enough data to warrant 'infinite scalability'... Turns out almost everyone was better off with a DuckDB database running locally, often in the browser." This challenges the default assumption that analytical workloads require distributed infrastructure. **Polars vs DuckDB** A healthy debate emerges about Polars as an alternative. One commenter argues for Polars' type-safe, lintable API over SQL, showing equivalent code side-by-side. Others counter that SQL's ubiquity and DuckDB's ability to query heterogeneous sources (Parquet, CSV, SQLite, remote S3 files in the same query) make it more practical for real-world data work. ## The Production Reality DuckDB isn't trying to replace PostgreSQL for transactional workloads. It's OLAP (Online Analytical Processing), not OLTP (Online Transaction Processing). You wouldn't use it for user authentication or shopping cart state. But for anything involving aggregations, joins across large datasets, or ad-hoc analysis - the kind of work that traditionally required setting up Spark or paying for Snowflake - DuckDB offers a compelling alternative that runs anywhere Python or your application runs. The extension ecosystem is also maturing. Community extensions cover GIS, observability, analytics, lakehouses, and object storage integration. One commenter notes: "DuckDB is becoming a kind of data superglue between a lot of data ecosystems that don't talk to each other typically." ## Why This Matters The broader trend here is the return of the "big enough" single-node. As hardware has improved, the datasets that actually require distributed computing have shrunk as a percentage of real-world workloads. DuckDB capitalizes on this by making single-node analytics extremely efficient. For developers building data-intensive applications, this means you can often skip the infrastructure complexity entirely. Query your Parquet files on S3 directly from your application. Run analytics in the browser with DuckDB-WASM. Process terabytes on a beefy EC2 instance instead of managing a cluster. The catch is knowing when you've outgrown it. But as one commenter notes, most teams reach for distributed systems long before they actually need them. ## Sources - [DuckDB Internals: Why Is DuckDB Fast? (Part 1)](https://www.greybeam.ai/blog/duckdb-internals-part-1) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48553388) - [DuckDB Community Extensions](https://duckdb.org/community_extensions/) - [DuckDB Extension Template](https://github.com/duckdb/extension-template)

Three Ways to Ignore Files in Git (Beyond .gitignore)

Developers Digest — Fri, 19 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 A post on Hacker News today resurfaced something that many developers overlook: `.gitignore` is not the only way to ignore files in Git. There are actually three distinct mechanisms, each designed for different use cases. Understanding when to use which can clean up your repos and avoid awkward pull request feedback. ## The Three Levels of Git Ignore ### 1. .gitignore (Shared, Committed) The familiar option. Whatever patterns you add to `.gitignore` get committed to the repository and apply to everyone who clones it. ``` $ cat .gitignore node_modules/ dist/ .env ``` **Use for:** Build artifacts, dependencies, environment files - anything project-specific that no contributor should commit. ### 2. .git/info/exclude (Local, Per-Repository) Located inside the `.git` directory, this file follows the same syntax as `.gitignore` but never gets committed. It's repository-specific and stays on your machine only. ``` $ cat .git/info/exclude my-local-notes.md scratch/ debug.log ``` **Use for:** Personal scratch files, local test data, IDE configs that only you use, Makefiles or scripts specific to your dev environment. ### 3. ~/.config/git/ignore (Global, Machine-Wide) A global ignore file that applies across every repository on your system. By default, Git looks for it at `~/.config/git/ignore`, but you can point it elsewhere: ```bash git config --global core.excludesFile ~/.gitignore_global ``` ``` $ cat ~/.config/git/ignore .DS_Store Thumbs.db *.swp .idea/ ``` **Use for:** OS-specific cruft like `.DS_Store` on macOS or `Thumbs.db` on Windows. Also useful for editor-specific files you use across all projects. ## Debugging Ignore Rules When a file is being ignored and you're not sure why, Git has a built-in diagnostic: ```bash git check-ignore -v myfile.txt ``` This outputs the file path, line number, and pattern responsible for ignoring the file. It's invaluable when you inherit a repo with complex ignore rules or when you're troubleshooting why something isn't showing up in `git status`. ## The Tracked File Trap There is one case where ignore files will not do what developers expect: the file is already tracked. `.gitignore`, `.git/info/exclude`, and the global ignore file only stop untracked files from appearing in `git status`. They do not make Git forget a file that is already in the index. That is why searches for this topic often drift into `git update-index --skip-worktree` and `git update-index --assume-unchanged`. Those commands are not more powerful ignore files. They are index hints for tracked paths, and they belong in a narrower bucket. Use `--skip-worktree` when a tracked file needs a local-only value in your checkout, such as a sample config copied into a real config path: ```bash git update-index --skip-worktree config/local.json ``` Undo it before committing a real change: ```bash git update-index --no-skip-worktree config/local.json ``` Use `--assume-unchanged` even more sparingly. Git documents it as a performance hint for paths that are expensive to stat, not a workflow primitive for ignoring personal edits. If your real goal is "I changed this file locally and never want to commit it," prefer `.git/info/exclude` for untracked files or restructure the config so the tracked file imports a local override. If you inherit a repo and suspect one of these flags is already set, inspect the index directly: ```bash git ls-files -v | grep '^[a-zS]' ``` Uppercase `S` marks skip-worktree paths. Lowercase status markers can reveal assume-unchanged paths. Treat that output as a cleanup list, not as a pattern to spread across the team. This distinction matters for agent-heavy repos too. When you are running parallel coding agents in worktrees, the cleanest setup is usually: - shared generated outputs in `.gitignore` - personal scratch files in `.git/info/exclude` - machine-wide editor files in `~/.config/git/ignore` - tracked-but-local config handled by templates, env files, or a documented `skip-worktree` exception That keeps review queues focused on real code instead of accidental local state. It also pairs well with [local coding agent workspaces](/blog/local-coding-agent-workspaces-2026), [filesystem contracts for agent workspaces](/blog/agent-workspaces-need-filesystem-contracts), and [parallel coding agent merge discipline](/blog/parallel-coding-agents-merge-discipline). ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48583356) surfaced some practical patterns from experienced developers: **The "attic" pattern.** Several commenters add `attic` to their global ignore, then create an `attic/` directory in any project for random files that should never be committed. One commenter takes this further by putting a `.gitignore` inside the `attic/` directory containing just `*` - making the directory self-ignoring. **The scope debate.** There's a split on whether IDE/editor-specific ignores belong in the repo's `.gitignore` or your personal global config. The pragmatic argument: adding `.idea/` or `.vscode/` to every project's `.gitignore` saves everyone the trouble of configuring their global ignore. The purist argument: a repo's `.gitignore` should only contain patterns relevant to the project itself. **Devcontainer edge case.** One commenter pointed out that global ignore files don't survive devcontainer rebuilds - you need to bind-mount your config or explicitly persist it. **The Magit angle.** Emacs users noted that Magit has native support for choosing between shared (`.gitignore`) and private (`.git/info/exclude`) ignores when pressing `i` on a file. ## The Decision Framework Here's when to use each: | Scenario | Use | |----------|-----| | Build output, dependencies, secrets | `.gitignore` | | Personal scratch files in one repo | `.git/info/exclude` | | OS/editor files across all repos | `~/.config/git/ignore` | | Tracked file with local-only edits | Usually redesign the config; use `skip-worktree` only as an explicit exception | The key insight: if it's something every contributor would need to ignore, put it in `.gitignore`. If it's specific to your workflow but not the project, use the local or global options. ## Why This Matters Bloated `.gitignore` files are a code smell. When a repo's ignore file contains 50 lines covering every IDE, editor, and OS under the sun, it suggests nobody is using the right tool for the job. The result is a file that's hard to maintain and hides project-specific patterns in noise. Knowing about `.git/info/exclude`, the global ignore file, and the tracked-file boundary gives you cleaner repos and fewer "please remove your IDE config from the gitignore" code review comments. It is the same operational lesson behind [Codex CLI resource budgets](/blog/codex-cli-resource-budgets), [permissions and rollback for AI coding agents](/blog/permissions-logs-rollback-ai-coding-agents), and [GitKraken plus Claude Code workflows](/blog/gitkraken-claude-code): local developer tooling should leave a small, obvious footprint in the repo. ## FAQ ### Should I put `.vscode/` or `.idea/` in `.gitignore`? If the project intentionally shares editor configuration, commit the useful settings and ignore only machine-specific files. If the files are purely personal, prefer your global ignore file. Teams often still put common editor directories in `.gitignore` because it reduces accidental commits, but that is a convenience tradeoff, not a Git requirement. ### Why is Git still tracking a file after I added it to `.gitignore`? Because `.gitignore` does not apply to files already tracked in the index. Remove the file from the index with `git rm --cached path` if it should stop being tracked for everyone, or redesign the config so local values live in an untracked override file. ### When should I use `git update-index --skip-worktree`? Use it only for a documented local exception on a tracked file. It is not a replacement for `.gitignore`, and it can surprise you later when a real upstream change touches the same path. ### Is `assume-unchanged` the same as `skip-worktree`? No. `assume-unchanged` is mainly a performance hint. `skip-worktree` is closer to a local working-tree override. For normal "do not commit this file" workflows, ignore files or config templates are easier to reason about. ## Sources - [.gitignore Isn't the only way to ignore files in Git](https://nelson.cloud/.gitignore-isnt-the-only-way-to-ignore-files-in-git/) - Original article - [Hacker News Discussion](https://news.ycombinator.com/item?id=48583356) - Community discussion - [Git Documentation: gitignore](https://git-scm.com/docs/gitignore) - Official Git manual page - [Git Documentation: git-check-ignore](https://git-scm.com/docs/git-check-ignore) - Ignore rule diagnostics - [Git Documentation: git-update-index](https://git-scm.com/docs/git-update-index) - `skip-worktree` and `assume-unchanged` - [Stack Overflow: assume-unchanged vs skip-worktree](https://stackoverflow.com/questions/13630849/git-difference-between-assume-unchanged-and-skip-worktree) - Search-intent reference for tracked-file confusion

GitHub Copilot Agent Finder: What ARD Means for Third-Party AI Tools in 2026

Developers Digest — Fri, 19 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Agent Finder Announcement | [GitHub Changelog - June 17, 2026](https://github.blog/changelog/2026-06-17-agent-finder-for-github-copilot-now-available/) | | Third-Party Coding Agents Docs | [docs.github.com - About Third-Party Coding Agents](https://docs.github.com/en/copilot/concepts/agents/about-third-party-coding-agents) | | ARD Specification | [agenticresourcediscovery.org](https://agenticresourcediscovery.org/) | | ARD Announcement | [Microsoft Command Line - ARD Specification](https://commandline.microsoft.com/agentic-resource-discovery-specification-ard/) | | GitHub Copilot Agents | [github.com/features/copilot/agents](https://github.com/features/copilot/agents) | | Copilot Plans | [github.com/features/copilot/plans](https://github.com/features/copilot/plans) | **Last updated:** June 19, 2026 GitHub shipped Agent Finder on June 17, 2026. Instead of manually configuring which MCP servers, skills, and third-party agents your Copilot instance uses, Agent Finder discovers and invokes the right capability automatically. Describe a task in plain language, and Copilot searches a registry of AI resources, ranks the matches, and pulls in the right tool on demand. That is not incremental. Agent Finder changes how AI coding tools compose with each other. You no longer wire up every integration by hand. The agent figures out what it needs. This post covers what Agent Finder actually does, how the new ARD specification behind it works, which third-party agents are available today, and what this means for your workflow. ## What Agent Finder Does Agent Finder is automatic capability discovery for GitHub Copilot. You describe a task, and Copilot searches an index of available AI resources - MCP servers, skills, tools, agents - and returns ranked matches. If a match fits, Copilot loads and invokes it on demand. The key design choice: Agent Finder does not silently connect anything. It finds the right tool at the right time, shows you the match, and lets you proceed. Manual control stays intact. Three ways to think about it: **Registry flexibility.** Agent Finder works against a registry you choose. Point it at GitHub's curated public catalog, or at your own private registry of internal resources. Enterprise teams can lock discovery to a vetted internal catalog. Solo developers can use GitHub's public catalog and pick up community-contributed tools. **Dynamic composition.** Instead of pre-wiring every MCP server and skill into your config, Agent Finder retrieves only what the current task needs. Your agent starts lean and adds capability on demand. That is better for context budget and latency. **Governance integration.** Enterprise administrators define which resources agents can discover and use through existing Copilot management settings. Agent Finder respects those policies. You get automatic discovery without giving up control. ## The ARD Specification Agent Finder implements the open Agentic Resource Discovery (ARD) specification. ARD is a standard for publishing, indexing, and discovering AI capabilities - a discovery layer that any registry or AI client can adopt. Microsoft leads ARD development in partnership with Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Nvidia, Salesforce, ServiceNow, and Snowflake. That is not a small coalition. ### How ARD Works ARD operates like a search engine for AI resources. Developers publish lightweight manifests describing what their resources do. Those manifests get crawled and indexed. AI clients query the index using natural language, and the system returns matching resources along with invocation details. The difference from traditional search: agentic resources need structured metadata. A manifest describes what the resource accomplishes, when to use it, what inputs it accepts, what authority level it requires, who operates it, how to invoke it, and what policies it complies with. That metadata makes automatic invocation possible. ### Registry Architecture ARD supports multiple discovery services, not a single global catalog. Organizations can establish: - **Public services** that index resources across the web. - **Vendor services** that expose a single ecosystem's resources. - **Enterprise services** that restrict access to internal resources, vetted vendors, and approved third-party capabilities. Think of it like DNS. You can run your own resolver, join a larger shared system, or do both. Local control coexists with broader participation. For the technical specification, see [agenticresourcediscovery.org](https://agenticresourcediscovery.org/). ## Third-Party Coding Agents in Copilot Agent Finder is one part of a broader shift. GitHub now supports third-party coding agents that work asynchronously alongside Copilot's built-in cloud agent. You assign an issue or provide a prompt, and the agent works on changes, creates a pull request, and requests review when finished. Two third-party agents are available today: **Anthropic Claude** - Models include Claude Opus 4.5, 4.6, and 4.7, plus Claude Sonnet 4.5 and 4.6. Auto mode available for automatic model selection. **OpenAI Codex** - Models include GPT-5.3-Codex, GPT-5.4, and GPT-5.4 nano. Auto mode available. Both agents support the same workflow. You can assign them to issues, mention them in pull request comments with `@AGENT_NAME`, or start tasks from the Agents tab in your repository. They work on GitHub Mobile and in Visual Studio Code. ### Enabling Third-Party Agents Third-party agents require explicit enablement through account policies. When you enable Claude, GitHub installs the "anthropic code agent" GitHub App. When you enable Codex, it installs the "openai code agent" GitHub App. Both agents are subject to the same security protections as Copilot's cloud agent. Generated code is automatically scanned using CodeQL analysis, secret detection, and vulnerability checks against the GitHub Advisory Database. Security validation does not require a GitHub Advanced Security license. ### Billing Third-party agent usage consumes GitHub Actions minutes and AI credits. If you stay within included allocations on your Copilot plan, there is no additional cost. Heavy users on usage-based billing should monitor credit consumption - agent tasks can burn through credits faster than autocomplete and chat. For current pricing across all Copilot plans, see the [AI coding tools pricing June 2026 breakdown](/blog/ai-coding-tools-pricing-june-2026). ## What This Means for Your Workflow ### If You Use Claude Code or Codex Today Agent Finder creates a bridge. You can continue using Claude Code or Codex directly in their native surfaces - terminal for Claude Code, Codex CLI or ChatGPT for Codex - while also invoking them from GitHub issues and PRs through Copilot. The agents are the same; the entry points multiply. That said, the native surfaces still offer features that Copilot integration does not. Claude Code's skill system, CLAUDE.md project config, and subagent architecture run in the terminal, not in GitHub's cloud agent wrapper. Codex's background execution and worktree isolation work best in its native CLI. Copilot integration is useful for GitHub-native workflows like issue triage and PR iteration, not as a replacement for dedicated agent use. ### If You Rely on MCP Servers Agent Finder can discover and invoke MCP servers automatically. If you have been manually configuring MCP servers in `.claude/settings.json` or similar files, Agent Finder offers an alternative: publish a manifest, register with a discovery service, and let agents find your servers on demand. For internal MCP servers, the enterprise registry model matters. You can expose internal tools to Agent Finder without publishing them to the public web. Your team's proprietary integrations stay discoverable by your agents and invisible to everyone else. ### If You Are Building AI Tools ARD is open. If you build MCP servers, skills, or agents, publishing a manifest to an ARD-compatible registry makes your tools discoverable by any client that supports the specification - not just GitHub Copilot. Hugging Face's Discover Tool already uses ARD to search across thousands of skills, ML applications, and MCP servers. Publishing instructions are at [agenticresourcediscovery.org/how_to_publish/](https://agenticresourcediscovery.org/how_to_publish/). ## The Bigger Picture Agent Finder is GitHub's answer to a problem the AI coding market has been circling for a year: how do agents compose with each other without brittle, hand-wired integrations? The old answer was configuration files. You define which MCP servers your agent can access, which skills it can invoke, which external tools it can call. That works, but it does not scale. Every new capability requires explicit configuration. Agents cannot discover what they do not already know about. The ARD answer is dynamic discovery. Agents search, rank, and invoke capabilities at runtime. You configure policies - what registries to trust, what resources to allow - but you do not enumerate every tool. The agent figures out what it needs for each task. That architectural shift has implications beyond GitHub. If ARD gains adoption across the coalition backing it, the same discovery protocol could work across Claude Code, Codex, Cursor, and any future agent that implements the specification. Interoperability becomes possible not through one vendor's integration work, but through a shared standard. GitHub shipped first. The rest of the market will decide whether ARD becomes the common layer or a GitHub-only feature. ## Getting Started To use Agent Finder: 1. **Enable third-party agents** in your GitHub account or organization settings. This triggers the GitHub App installations for Claude and/or Codex. 2. **Assign an agent to an issue** by mentioning `@claude` or `@codex` in a comment, or use the Agents tab in your repository. 3. **Let Agent Finder discover tools.** Describe your task in plain language. If a matching MCP server, skill, or tool exists in your registry, Agent Finder will surface it. 4. **Review the pull request.** The agent works asynchronously and creates a draft PR with its changes. Leave comments to iterate. For enterprise teams: 1. **Configure agent policies** in your organization's Copilot settings. Define which third-party agents are allowed and which registries Agent Finder can query. 2. **Publish internal resources** to a private ARD registry if you want Agent Finder to discover internal MCP servers, skills, or tools. 3. **Monitor usage** through existing Copilot usage reports. Agent tasks consume Actions minutes and AI credits. ## FAQ ### What is GitHub Copilot Agent Finder? Agent Finder is a feature that automatically discovers and invokes AI resources - MCP servers, skills, tools, and agents - based on natural language task descriptions. Instead of manually configuring every integration, Agent Finder searches a registry of available resources and pulls in what the current task needs. It shipped on June 17, 2026 and is available on all Copilot plans. ### What is the ARD specification? ARD (Agentic Resource Discovery) is an open specification for publishing, indexing, and discovering AI capabilities. Developed by Microsoft, GitHub, Google, Hugging Face, and others, ARD establishes how organizations publish manifests describing their resources and how AI clients query discovery services to find and invoke those resources automatically. The full specification is at [agenticresourcediscovery.org](https://agenticresourcediscovery.org/). ### Which third-party agents work with GitHub Copilot? Two third-party coding agents are available: Anthropic Claude (Opus 4.5-4.7 and Sonnet 4.5-4.6) and OpenAI Codex (GPT-5.3-Codex, GPT-5.4, GPT-5.4 nano). Both work asynchronously - you assign them to issues or mention them in PR comments, and they create pull requests with their changes. ### Does Agent Finder cost extra? No additional cost if you stay within your Copilot plan's included allocations. Agent tasks consume GitHub Actions minutes and AI credits. Heavy usage on usage-based billing plans will consume credits faster than autocomplete or chat, so monitor your dashboard if budget matters. ### Can I use a private registry with Agent Finder? Yes. Enterprise teams can configure Agent Finder to query private internal registries instead of or in addition to GitHub's public catalog. This lets you expose proprietary MCP servers, skills, and tools to your agents without publishing them publicly. ### How does Agent Finder differ from manually configuring MCP servers? Manual configuration requires you to enumerate every MCP server, skill, and tool your agent can access. Agent Finder discovers capabilities at runtime based on task descriptions. You configure policies (which registries to trust, what to allow) rather than individual tool entries. The agent finds what it needs for each task. ### Is ARD only for GitHub Copilot? No. ARD is an open specification that any AI client can implement. Hugging Face's Discover Tool already uses ARD. If other AI coding tools adopt the specification, the same discovery protocol could enable cross-tool interoperability. ### What security protections apply to third-party agents? Third-party agents are subject to the same security protections as Copilot's cloud agent. Generated code is automatically scanned using CodeQL, secret detection, and vulnerability checks against the GitHub Advisory Database. These protections do not require a GitHub Advanced Security license. --- ## Sources - [Agent finder for GitHub Copilot now available](https://github.blog/changelog/2026-06-17-agent-finder-for-github-copilot-now-available/) - GitHub Changelog, June 17, 2026 - [About third-party coding agents](https://docs.github.com/en/copilot/concepts/agents/about-third-party-coding-agents) - GitHub Docs, verified June 19, 2026 - [Introducing the Agentic Resource Discovery specification](https://commandline.microsoft.com/agentic-resource-discovery-specification-ard/) - Microsoft Command Line Blog - [ARD Specification](https://agenticresourcediscovery.org/) - Agentic Resource Discovery consortium

MCP Goes Stateless: The 2026-07-28 Migration Guide

Developers Digest — Fri, 19 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Description | |----------|-------------| | [MCP 2026-07-28 Release Candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) | Official announcement from the MCP team | | [MCP Specification](https://spec.modelcontextprotocol.io/) | The full protocol specification | | [MCP TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk) | Official TypeScript SDK with RC support | | [MCP Python SDK](https://github.com/modelcontextprotocol/python-sdk) | Official Python SDK with RC support | | [2026 MCP Roadmap](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/) | The roadmap that led to these changes | | [MCP Registry](https://registry.modelcontextprotocol.io/) | Official MCP server discovery and indexing | The biggest MCP change since launch ships on July 28, 2026. The protocol is going stateless. Sessions are gone. The initialize handshake is gone. Every request now stands on its own. This is not a cosmetic refactor. If you have an MCP server in production, you have roughly five weeks to migrate before the final specification locks. **Last updated:** June 19, 2026 ## What Actually Changed The 2026-07-28 release candidate removes session management from the protocol layer entirely. The previous specification required a multi-step flow: client connects, sends `initialize`, receives `initialized` with an `Mcp-Session-Id` header, then includes that header on every subsequent request. That session ID pinned the client to a specific server instance. The new spec eliminates all of that. A single self-contained request can hit any server instance. No sticky sessions. No shared session store. No deep packet inspection at the gateway. The `_meta` field on each request carries whatever context the server needs. Here is the practical impact: | Concern | Old (2025-11-25) | New (2026-07-28) | |---------|-----------------|------------------| | Session state | Server memory or shared Redis | None required - stateless | | Load balancing | Sticky sessions required | Plain round-robin works | | Server scaling | Complex - state coordination | Simple - any instance handles any request | | Handshake | `initialize`/`initialized` flow | Eliminated | | Capability discovery | Part of handshake | Separate `/mcp/capabilities` endpoint | | Request routing | Parse body for session ID | `Mcp-Method` header - no body inspection | The server-to-client request model also changed. Instead of holding connections open with Server-Sent Events for multi-turn operations, servers now return an `InputRequiredResult` with a `requestState` payload. The client re-issues the call with `inputResponses` and the echoed state. This allows stateless retry handling - if a request fails mid-way, the client can retry to any server instance. ## Why Sessions Were Dropped The old session model made three assumptions that aged poorly: 1. **Long-lived processes with shared memory.** The initialize handshake assumed your MCP server ran as a persistent process that could track session state in memory. That works for local development. It does not work for serverless functions, containerized deployments with auto-scaling, or edge compute. 2. **Sticky sessions are free.** They are not. Sticky sessions require load balancer configuration, add failure modes when instances restart, and prevent true horizontal scaling. Many production deployments worked around this by adding Redis for shared session state - adding latency to every tool call. 3. **Deep packet inspection is acceptable.** Routing requests by session ID meant gateways had to parse request bodies. The new `Mcp-Method` header allows routing decisions without body inspection, which simplifies gateway configuration and improves request handling time. The MCP team's position: "Stateful sessions fight with load balancers." The protocol now aligns with how modern infrastructure actually works. ## Breaking Changes If you have MCP servers in production, here is what breaks: **Initialize handshake removed.** Servers that expect `initialize` as the first message will fail. Clients using the new SDKs will not send it. **Session ID routing gone.** Any gateway or routing logic that depended on `Mcp-Session-Id` headers needs rewriting. The new pattern is `Mcp-Method` header routing. **Error code change.** Missing resource errors shifted from `-32002` to `-32602` (JSON-RPC standard Invalid Params). Error handling that catches specific codes needs updating. **Tasks API lifecycle changed.** Anyone who shipped against the 2025-11-25 experimental Tasks API needs to migrate. The new Tasks extension reshapes around stateless patterns using `tasks/get`, `tasks/update`, and `tasks/cancel` instead of the old subscription model. **Authorization validation stricter.** Clients must validate the `iss` parameter per RFC 9207 and declare `application_type` during Dynamic Client Registration. ## Migration Path The migration difficulty depends on how much session state your server currently maintains. ### If Your Server Is Already Stateless Many simple MCP servers - file readers, API wrappers, documentation tools - do not actually use session state. They receive a request, perform an operation, return a result. For these servers, migration is minimal: 1. Remove the `initialize`/`initialized` handlers 2. Add `Mcp-Method` header support for routing 3. Update to the latest SDK version 4. Test against the release candidate ### If Your Server Maintains Session State Servers that track conversation context, user preferences, or in-progress operations need more work: **Before (stateful):** ```typescript // Session-dependent lookup private sessions = new Map(); async handleToolCall(request: ToolCallRequest) { const session = this.sessions.get(request.sessionId); if (!session) throw new Error('Unknown session'); // Use session context return this.executeWithContext(request, session); } ``` **After (stateless):** ```typescript // Per-request validation with context in _meta async handleToolCall(request: ToolCallRequest) { // Context travels with request const context = request._meta?.context; // Validate authorization on every request await this.validateToken(request._meta?.authorization); return this.executeWithContext(request, context); } ``` The key shift: context that used to live in server memory now travels with each request. Clients are responsible for including relevant context in `_meta`. Servers validate and use it without maintaining state. ### If Your Server Uses Tasks The Tasks API migration is the most involved. The old model used subscriptions and server-sent events. The new model uses polling with state payloads: **Old pattern:** ```typescript // Subscribe to task updates const subscription = await mcp.tasks.subscribe(taskId); for await (const update of subscription) { console.log(update.status); } ``` **New pattern:** ```typescript // Poll with state let task = await mcp.tasks.get(taskId); while (task.status === 'running') { await sleep(1000); task = await mcp.tasks.get(taskId, { requestState: task.state }); } ``` The `requestState` field allows the server to include opaque state that the client echoes back. This enables stateless resumption - any server instance can continue handling the task as long as it can access the underlying task store. ## Externalize State Management For servers that genuinely need to maintain state across requests - multi-step workflows, caching, user preferences - the pattern is externalization. Move state from server memory to an external store. ```typescript // External state store (Redis, PostgreSQL, etc.) interface TaskStore { create(task: Task): Promise; get(taskId: string): Promise; update(taskId: string, status: TaskStatus): Promise; cancel(taskId: string): Promise; } // Any server instance can handle any request async handleTaskGet(taskId: string) { return this.taskStore.get(taskId); } async handleTaskCancel(taskId: string) { return this.taskStore.cancel(taskId); } ``` This approach enables true horizontal scaling. Load balancers distribute requests across instances using any algorithm. Every instance handles every request type identically because state lives externally. ## New Capabilities The release candidate adds features alongside the stateless changes: **Caching support.** The new `ttlMs` and `cacheScope` fields on responses allow clients and infrastructure to cache appropriately. A `tools/list` response with `ttlMs: 3600000` tells clients they can cache the tool list for an hour. **Extensions framework.** Optional capabilities now have formal governance with reverse-DNS identifiers, independent versioning, and dedicated repositories. Two official extensions ship with this release: MCP Apps (sandboxed server-rendered HTML interfaces) and Tasks (graduated from experimental core status). **Distributed tracing.** W3C Trace Context keys are now standardized across SDKs. Observability tools can trace requests across MCP server chains. **Simplified routing.** The required `Mcp-Method` and `Mcp-Name` headers enable routing decisions without body inspection. Gateways can route based on headers alone. ## Timeline - **May 21, 2026:** Release candidate locked - **Now through July 28:** Validation window for SDK maintainers and implementers - **July 28, 2026:** Final specification published The specification includes a feature lifecycle policy: twelve-month deprecation windows before removal. This is the MCP team's commitment that future breaking changes will not be sprung on developers the way this one was. ## Migration Strategy by Server Type **New servers:** Target the 2026-07-28 RC immediately. There is no reason to build against the old spec. **Existing servers with Tier 1 SDK usage:** Migrate within 4-6 weeks. The official TypeScript and Python SDKs already have release candidate support. **Public servers with external users:** Support both specs through Q4 2026. The transition period matters for servers with established user bases. **Community SDK users:** Wait for your SDK maintainer to announce support before committing to migration dates. ## What This Means for MCP Server Developers The stateless shift is a net positive for the MCP ecosystem. Infrastructure that was previously hard - load balancing, auto-scaling, serverless deployment - becomes straightforward. The mental model simplifies: a request is self-contained, a response is self-contained, and server instances are interchangeable. The cost is migration work for existing servers and a breaking change in the protocol. That is a real cost, and the five-week timeline is tight for servers with significant session logic. But the alternative - maintaining a stateful protocol that fights with modern infrastructure - was not sustainable. The MCP team made the right call. Now we migrate. --- ## FAQ ### When does the MCP stateless specification take effect? The final specification publishes on July 28, 2026. The release candidate has been available since May 21, 2026, giving developers roughly ten weeks to validate and migrate. Most production servers should complete migration by mid-July to allow buffer time. ### What happens to my MCP server if I do not migrate? Servers built against the old 2025-11-25 specification will stop working with clients using updated SDKs. The initialize handshake that old servers expect will not be sent. You need to either migrate to the stateless spec or pin your client SDK versions. ### Do I need to rewrite my entire MCP server? It depends on your session usage. Simple servers that do not maintain session state need minimal changes - remove the initialize handler, add header support, update SDK. Servers with heavy session logic need to externalize state to a store like Redis or PostgreSQL. ### How do I handle multi-turn conversations without sessions? Context travels with each request in the `_meta` field. Clients are responsible for including conversation context. Servers validate and use it without maintaining state. For complex workflows, use the Tasks extension with externalized task state. ### What is the Tasks extension and how does it differ from the old Tasks API? The Tasks extension graduated from experimental status and was restructured for stateless operation. Instead of subscriptions and server-sent events, it uses a polling model with `tasks/get`, `tasks/update`, and `tasks/cancel`. The `requestState` field enables stateless resumption across server instances. ### Can I support both the old and new specifications? Yes, during the transition period. Check the SDK version or request format to determine which protocol the client is using, and handle accordingly. This is recommended for public servers with established user bases through Q4 2026. ### How do the new caching fields work? Responses can include `ttlMs` (time-to-live in milliseconds) and `cacheScope` to inform caching strategies. A `tools/list` response with `ttlMs: 3600000` tells clients the tool list is stable for an hour. This reduces unnecessary round-trips and improves performance. ### What are MCP Apps? MCP Apps is one of two official extensions shipping with this release. It enables sandboxed server-rendered HTML interfaces - MCP servers can provide UI components that clients render safely. This opens possibilities for richer tool interactions beyond text-only responses.

Zero-Touch OAuth Is the MCP Feature Enterprises Were Waiting For

Developers Digest — Fri, 19 Jun 2026 00:00:00 GMT

**Last updated:** June 19, 2026 MCP's newest enterprise auth work looks boring in the best possible way. The [Model Context Protocol team announced Enterprise-Managed Authorization](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) on June 18, 2026. The pitch is simple: instead of making every user approve every MCP server with a separate OAuth dance, an enterprise identity provider can issue short-lived, scoped access to approved MCP clients and servers. The user signs in once through the company identity system. The agent receives only the delegated access it needs. That sounds like plumbing. For agent adoption, plumbing is the product. The early MCP story was tool discovery: give Claude, Cursor, Codex, or another host a standard way to find tools, resources, and prompts. That mattered, and the [Model Context Protocol primer](/blog/what-is-model-context-protocol-2026-primer) is still the best starting point if you want the wire-level map. But large companies were never going to roll out hundreds of connected agent tools on vibes, browser popups, and per-server consent screens. Zero-touch OAuth moves MCP closer to the control plane enterprises already know: identity provider policy, scoped tokens, central audit, revocation, and managed app access. That is the real news. ## The take: MCP is becoming an identity problem Most developer arguments about MCP still focus on whether it is "just APIs." That debate misses the adoption bottleneck. An API call is easy. A reusable, cross-client, identity-aware, auditable tool connection is not. If a coding agent can file a Linear issue, read GitHub, query a warehouse, inspect a Figma file, post to Slack, and call an internal deployment service, the hard question is not whether the tool schema is JSON. The hard question is who granted that access, how long it lasts, what scope it has, whether it can be revoked, and where the audit trail lives. That is why this auth update matters more than another batch of MCP servers. It addresses the boring enterprise questions that decide whether agent tools leave the pilot group. For smaller teams, MCP can still feel like a convenience layer over function calling. I would still use ordinary tool calling for application-local functions, as explained in [MCP vs Function Calling](/blog/mcp-vs-function-calling). But once the same tool needs to work across many agent hosts, many users, and many business systems, identity becomes the center of the design. ## What Enterprise-Managed Authorization changes The official post describes a flow where enterprise administrators pre-authorize MCP clients and servers through an identity provider. When a user interacts with an MCP server, the identity provider can issue a token representing the user's approved access without forcing the user through another interactive consent flow each time. In plain English: - The company identity provider becomes the source of policy. - Tokens can be short-lived and scoped. - Users are not trained to approve a parade of tool popups. - Admins can manage access centrally. - MCP clients and servers can rely on a consistent enterprise auth pattern. That last point is important. The problem with "just use OAuth" is that each MCP server can still end up with its own registration flow, consent screen, scope shape, token lifetime, and admin story. HN commenters immediately surfaced the real-world pain: Microsoft Entra app registration, client IDs, dynamic clients, authorization server metadata, scope mapping, and the awkward question of what a "client" even means when the agent host is acting on behalf of the user. Enterprise-Managed Authorization does not magically delete that complexity. It gives the ecosystem a shared place to put it. ## The HN pushback is useful The [Hacker News thread](https://news.ycombinator.com/item?id=48592163) was unusually constructive. At the time I checked it on June 19, 2026, it had 210 points and 76 comments. The best comments were not "MCP good" or "MCP bad." They were about where the auth boundary should live. One camp saw the value immediately: MCP's differentiator over local scripts or skills is that auth can sit outside the model context and possibly outside the agent harness. That is a real security and UX win. A model should not need to reason about login ceremonies, refresh tokens, or enterprise app policy to call a tool safely. Another camp was skeptical of delegated access without obvious user presence. That concern is legitimate. Enterprise auth can centralize audit and revocation, but it can also make machine-mediated access feel invisible. If the user never sees the exact moment access is delegated, the product has to work harder to show scope, purpose, and receipts after the fact. A third camp wanted the same pattern beyond MCP. That might be the bigger tell. CLI tools, internal apps, browser extensions, and agent runtimes all have the same enterprise OAuth mess. If the token format and policy model are useful outside MCP, this becomes part of a broader agent identity layer rather than a protocol niche. The practical takeaway: zero-touch does not mean zero visibility. It should mean zero repetitive consent friction plus much better administrative visibility. ## The agent security angle This is where the auth news connects directly to [AI agent containment](/blog/agent-containment-capability-ledger). Agent security is not solved by telling the model to be careful. It is solved by separating capabilities, identities, network paths, credentials, and durable audit records. MCP makes agent tools easier to connect. That means MCP also makes capability sprawl easier to create. Enterprise-managed auth can help if it becomes part of a capability ledger: - Which MCP server was called? - Which identity provider issued the token? - Which user, group, device, or policy allowed it? - Which scopes were present? - When did the token expire? - Could the agent write, or only read? - Which host initiated the call? - Was untrusted content present in the same agent session? Those questions matter because of the classic agent risk shape: private data, untrusted instructions, and external action in one loop. The [prompt injection in open source](/blog/prompt-injection-open-source) problem gets sharper when an agent can bring authenticated enterprise tools into the same context as arbitrary repo text, tickets, webpages, or package metadata. Short-lived scoped tokens are not a silver bullet. They are one of the factual controls that make the rest of the system reviewable. ## What I would look for before rolling this out If I were evaluating MCP inside a company, this announcement would make me more interested, but I would still ask for a concrete rollout checklist. First, every connected server needs a data classification. Read-only documentation search is not the same as customer data export. Linear issue creation is not the same as production deploy access. The identity layer should not flatten those into "approved MCP." Second, every server should declare capability classes in a way admins and users can understand. Read, write, mutate external state, send messages, move money, access customer data, access source code, run compute, and browse the web are different risk levels. A long list of OAuth scopes is not enough. Third, tool calls need durable receipts. A user should be able to ask what the agent did yesterday and get more than a chat transcript. The useful record is: host, server, tool, arguments summary, identity, scopes, policy decision, timestamp, and result class. That is the agent-era version of an audit log. Fourth, revocation has to be boring. If an employee changes teams, a device fails posture checks, or a server is compromised, access should close centrally without hunting through individual agent clients. Fifth, the user experience needs an explicit "why can this agent do this?" surface. Zero-touch auth should remove repetitive login prompts, not hide the capability graph. ## What this means for builders For MCP server authors, auth is now part of the product surface. It is not enough to expose a nice `tools/list` response and a clean schema. Enterprises will ask how your server handles OAuth metadata, token audience, tenant boundaries, audit logging, scopes, and admin pre-authorization. For agent host builders, this is a chance to stop treating tool access as a settings sidebar. Tool access is runtime state. Show it near the agent run. Make scope changes visible. Preserve receipts. Give admins policy controls without making every developer learn the entire OAuth spec. For application teams, do not wait for the ecosystem to make every decision for you. Decide which tool classes your agents can use, which identities they act under, and what evidence a reviewer needs after an agent touches a business system. This is why I like the direction of Enterprise-Managed Authorization. It admits that agent integrations are not just a developer-experience problem. They are an identity, governance, and audit problem. That is not as flashy as a new model benchmark. It is more likely to decide whether MCP becomes enterprise infrastructure. ## FAQ ### What is Zero-Touch OAuth for MCP? Zero-Touch OAuth is the common shorthand for MCP's Enterprise-Managed Authorization flow. It lets enterprise identity providers pre-authorize MCP access so approved clients and servers can receive short-lived scoped tokens without making users repeat individual consent flows for every tool connection. ### Is this only useful for large companies? Mostly, yes. Small teams may be fine with ordinary OAuth or local MCP configuration. The value grows when many employees, devices, agent hosts, MCP servers, and business systems need centralized policy and audit. ### Does Enterprise-Managed Authorization make MCP secure? No single auth feature makes agents secure. It helps with identity, scope, token lifetime, and central revocation. You still need sandboxing, data-flow controls, prompt-injection defenses, egress policy, server review, and durable audit logs. ### Is MCP better than function calling because of this? Not universally. Function calling is still simpler when you control the application and the tools are local to that app. MCP becomes more compelling when tools need to be reusable across hosts, users, organizations, and identity systems. ### Should every MCP server support enterprise-managed auth? If the server touches enterprise systems, private data, write actions, or customer-facing workflows, yes, it should have a serious auth and audit story. For small local-only utilities, lighter configuration may be enough. ## Sources - [Model Context Protocol blog: Enterprise-Managed Authorization](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) - fetched June 19, 2026. - [Hacker News discussion: Zero-Touch OAuth for MCP](https://news.ycombinator.com/item?id=48592163) - checked June 19, 2026. - [Model Context Protocol specification](https://modelcontextprotocol.io/specification/) - checked June 19, 2026. - [OAuth identity assertion authorization grant draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) - checked June 19, 2026.

Project Valhalla Arrives: Value Classes Ship in JDK 28 After a Decade of Work

Developers Digest — Fri, 19 Jun 2026 00:00:00 GMT

Project Valhalla has been the "coming soon" feature of Java for over a decade. It officially launched in 2014, went through five prototype iterations, and accumulated a mythology of "it will never ship" predictions. Now it's shipping. JDK 28 includes JEP 401: Value Classes and Objects as a preview feature, representing over 197,000 lines of changes across 1,816 files. The summary: you can now write classes that "code like a class but work like an int." Dense memory layouts, no identity overhead, better cache locality. The performance implications are significant for data-heavy applications. ## The Problem Valhalla Solves Java's type system has a fundamental split: eight primitive types (int, long, double, etc.) and reference types (everything else). Primitives live on the stack and can be packed densely in arrays. Objects live on the heap, require pointer indirection, carry metadata overhead, and need garbage collection. This worked fine when CPUs and memory were roughly matched in speed. Modern hardware has changed the equation - CPUs are orders of magnitude faster than main memory access. Data locality matters. A lot. Consider a `Point` class with two integers: ```java // Before Valhalla class Point { int x, y; } Point[] points = new Point[1_000_000]; // Result: 1 million pointers to scattered heap objects ``` Each access requires dereferencing, risking cache misses. Each object carries per-object metadata. The array stores pointers, not the data itself. ## How Value Classes Work JDK 28 introduces the `value` modifier: ```java // After Valhalla value class Point { int x, y; } Point[] points = new Point[1_000_000]; // Result: dense, contiguous 8-byte pairs ``` The key characteristic: **no identity**. Two value objects with identical content are considered equal, like integers. This has major consequences: - `==` checks field equality (substitutability), not reference identity - `synchronized` throws `IdentityException` - you can't lock on a value object - Helper methods `Objects.requireIdentity()` and `Objects.hasIdentity()` let code handle identity-dependent patterns ### Memory Optimization Mechanisms Two mechanisms enable the performance wins: **Scalarization.** The JIT compiler decomposes value objects into their constituent fields, eliminating allocation overhead entirely. A `Color` with three bytes gets passed directly as three values, not as a pointer. **Heap Flattening.** Value objects can be stored inline within fields or arrays, creating dense sequential data structures. Instead of an array of pointers to scattered objects, you get contiguous packed data. There's a constraint: flattened data must be readable/writable atomically, typically limited to 64 bits on current platforms. Larger value classes may fail to flatten and revert to heap storage. ## What's Included (and What's Not) **Included in JDK 28 (Preview):** - `value` class/record syntax - Scalarization and heap flattening for qualifying types - Cheaper boxing through value-based wrappers (Integer, Long, Double become value classes) **Not included:** - Null-restricted types (deferred to a separate JEP) - Full specialized generics - 128-bit encodings The null-restriction piece surprises people. Value classes remain reference types in JDK 28, so `Point p = null;` is legal. Making them non-nullable is a separate language change coming later. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48595511) (210 points, 88 comments) is characteristically technical: **The .NET comparison.** Multiple commenters pointed out that C# had structs from the beginning. The debate is whether Java took twelve years to "copy" .NET or whether the backward-compatibility constraints make this genuinely different work. The Java team's position: maintaining compatibility with decades of existing code while adding these semantics is the hard part, not implementing value types in isolation. **On the complexity claims.** Some skepticism about the "mentally heavy" justification for dropping dual projections (value/reference variants). Kotlin and TypeScript developers pointed out that nullable vs non-nullable distinctions don't seem to confuse their users. **The generics gap.** Several commenters noted that without specialized generics, a `List` still materializes value objects as heap objects, negating flattening benefits. This is acknowledged as Phase 2 work - not in JDK 28. **Second-mover advantage.** One thread traced C#'s cleaner design to being built later by engineers who had worked on Java's pain points firsthand. Anders Hejlsberg specifically designed around flaws he'd encountered. ## The Boxing Revolution A less-discussed but practically significant change: primitive wrappers themselves become value classes when preview features are enabled. Since `Integer`, `Long`, and `Double` lose identity, the JVM can scalarize and flatten them. This means `Integer[]` approaches `int[]` efficiency. Boxing overhead - one of Java's perennial performance complaints - gets dramatically reduced. ## Timeline and Adoption JDK 28 releases in March 2027, with integration targeted for July 2026. The feature ships as a preview, meaning you need `--enable-preview` to use it and the syntax may evolve before finalization. For most enterprises, the practical encounter with mature Valhalla will be through the next LTS release (JDK 29, September 2027). Early experimentation now shapes the feedback that determines refinements. Migration is straightforward: add the `value` modifier where identity isn't needed. Most code remains binary-compatible, though new errors emerge for identity-dependent patterns like synchronization or reference comparison. ## Why This Matters for Performance-Sensitive Code If you're working on: - Numerical computing - Game engines - Financial systems with large data structures - Anything iterating over millions of small objects Value classes offer meaningful performance improvements without changing your programming model. The class still encapsulates behavior. You still get methods, validation in constructors, and type safety. But the runtime can now treat your data like primitives when beneficial. The caveat: this is foundation work. The full vision - specialized generics that let `ArrayList` truly flatten - is still coming. But the pieces are landing, and after twelve years, that's worth noting. ## Sources - [Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28](https://www.jvm-weekly.com/p/project-valhalla-explained-how-a) - Original deep dive - [Hacker News Discussion](https://news.ycombinator.com/item?id=48595511) - 210 points, 88 comments - [JEP 401: Value Classes and Objects (Preview)](https://openjdk.org/jeps/401) - OpenJDK specification - [JEP 8303099: Null-Restricted Value Class Types](https://openjdk.org/jeps/8303099) - Future null-restriction work

Zero-Touch OAuth for MCP: Enterprise Auth Gets Practical

Developers Digest — Fri, 19 Jun 2026 00:00:00 GMT

## The Per-User OAuth Tax Model Context Protocol (MCP) has solved the "how do AI agents call external tools" problem. But it created another: every employee has to individually authorize every MCP server they want to use. For enterprises deploying AI tooling at scale, this means dozens of OAuth flows per person, no centralized audit trail, and constant risk of employees accidentally connecting personal accounts instead of corporate ones. Anthropic just shipped a fix. Enterprise-Managed Authorization (EMA) lets organizations control MCP server access centrally through their identity provider - Okta, in this first release. ## How It Works The technical implementation uses Identity Assertion JWT Authorization Grants (ID-JAG), a new token format working its way through the OAuth Working Group: 1. The MCP client obtains an ID-JAG from the organization's IdP during single sign-on 2. This credential is exchanged directly for an access token from the MCP server 3. Users bypass per-server consent screens entirely The result: MCP servers that the admin pre-authorizes connect automatically on first login, scoped to the user's existing roles and groups. From the [official announcement](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/): > "The per-user authorization tax keeps most of them switched off. Enterprise-Managed Authorization enables organizations to control MCP server access centrally through their trusted identity provider." Launch partners include Figma, Linear, Asana, and Atlassian on the MCP server side, with Anthropic's Claude and Visual Studio Code as initial clients. ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48592163) runs 90+ comments and surfaces the expected debate between MCP advocates and skeptics, plus some substantive security discussion. **The Security Tradeoff** The top concern is predictable: removing friction also removes a checkpoint. One commenter raises the prompt injection scenario: > "Suppose I start a conversation and enter some highly third-party-prompt-injectable request, perhaps 'Fork github.com/some_third_party/coolproject and submit a PR to do such-and-such.' That repo injects a prompt that attempts to do a tool call to steal all my money. If I indeed have a bank MCP configured, I absolutely want to be prompted!" The response from proponents: this is exactly why EMA is enterprise-focused. The IT admin, not the employee, decides what gets connected. If the organization trusts Claude with their Linear and Figma accounts, that's a policy decision made at the org level, not per-conversation. **The "MCP is Dead" Crowd** As expected, comments include variations of "I thought we were over this collective delusion called MCP." The counterargument from practitioners: > "The real valuable capability MCP offers over skills/CLI is isolating the auth flow outside of the agent's context window, and potentially out of the harness completely... Maybe the idealized form of MCP is just an auth gateway for the API and nothing else. That'd still be a win." This frames MCP less as a protocol for tool calling and more as infrastructure for managing agent permissions - a much narrower but more defensible value proposition. **Enterprise vs Consumer Identity** A nuanced thread distinguishes why EMA makes sense for employees but not consumers: > "In Enterprise, the IDP is the single owner for the identity, so it essentially can represent the user uniquely and sort of pretty much do anything it wishes for (includes deleting the identity). For consumer identity, the resource server owns the identity/user explicitly." The concern is that removing consent from the flow only works when the organization legitimately owns the identity. For consumer use cases, this would be inappropriate. **The Microsoft Entra Gap** Several commenters flag that Microsoft Entra ID (Azure AD) doesn't support Dynamic Client Registration, making this harder to implement for Microsoft-heavy enterprises. One developer shares a workaround: > "What we ended up doing was the app proxying the OAuth flow, to inject a hardcoded client_id. So we lie to the MCP client telling it we support DCR while behind the hood we use a standalone client_id as usual for the MCP." This suggests the ecosystem still has rough edges beyond the Okta happy path. **The Atlassian Implementer** An Atlassian engineer shows up in the thread: > "I implemented the RAS end of this for Atlassian. There will certainly be iterations around this flow - CIMD, better tenancy support, etc., but all the folks involved in delivering this at Anthropic, Okta, and here at Atlassian were fantastic." This confirms major SaaS vendors are taking MCP auth seriously. ## Why This Matters The broader story is AI agent infrastructure maturing. MCP started as a way to give LLMs tool access - essentially structured function calling with a discovery mechanism. But tool access without auth management isn't enterprise-ready. EMA addresses the specific pain point of "I want my whole engineering team using Claude with access to our Jira, GitHub, and Slack, without each person going through 15 OAuth flows and potentially connecting wrong accounts." For developers building MCP servers, this means: 1. **Implement EMA support** if you want enterprise adoption. The spec is now stable in MCP. 2. **ID-JAG isn't MCP-specific** - the same token format can work for any cross-application authorization scenario. 3. **Expect more IdP support** - Microsoft Entra integration is reportedly in discussion. The auth story for AI agents is still early. Questions remain around fine-grained permissions (OAuth scopes are notoriously coarse), multi-hop delegation (what happens when one agent calls another agent), and auditability (who accessed what, through which agent, when). But having basic enterprise SSO working is a prerequisite for everything else. ## What's Next The ID-JAG spec is being formalized through the OAuth Working Group. WorkOS has published an [overview of the open drafts](https://workos.com/blog/oauth-multi-hop-delegation-ai-agents) covering multi-hop delegation for AI agents - essentially, what happens when agents need to delegate permissions to other agents. One of the MCP maintainers points to additional work in progress: > "There are some active discussions on task level authz and multi-hop delegation in the OAuth WG right now." The draft for attenuating agent tokens - inspired by macaroons and capability-based access control - is available on the [IETF datatracker](https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/). For now, EMA solves the immediate problem of getting enterprise users onto MCP tooling without an onboarding nightmare. The harder problems - permissions that narrow based on context, audit trails that track agent decision chains, policies that prevent overly-permissive tool access - remain active work. ## Sources - [Enterprise-Managed Authorization: Zero-Touch OAuth for MCP](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) - [Hacker News Discussion](https://news.ycombinator.com/item?id=48592163) - [ID-JAG RFC Draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) - [OAuth Multi-Hop Delegation for AI Agents (WorkOS)](https://workos.com/blog/oauth-multi-hop-delegation-ai-agents) - [Attenuating Agent Tokens Draft](https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/)

Adam (YC W25): Open Source AI CAD That Generates OpenSCAD from Text

Developers Digest — Thu, 18 Jun 2026 00:00:00 GMT

A YC W25 company called Adam launched on Hacker News yesterday with 189 points and 87 comments. They are building AI agents for mechanical CAD software. The headline: an open source text-to-CAD platform called CADAM that generates parametric OpenSCAD models from natural language. The [HN discussion](https://news.ycombinator.com/item?id=48572553) got into the weeds on whether this approach is actually useful for real manufacturing workflows or just a nice demo for hobbyist 3D printing. **Last updated:** June 18, 2026 --- ## What CADAM Does CADAM is a React app that runs entirely in the browser. You describe what you want in plain English - or upload a reference image - and the system generates OpenSCAD code that compiles to a 3D model. The key differentiator from typical text-to-3D tools: it outputs parametric CAD, not meshes. From the [GitHub README](https://github.com/Adam-CAD/CADAM): > Generates parametric 3D models from natural language, with support for both text prompts and image references. Outputs OpenSCAD code with automatically extracted parameters that surface as interactive sliders for instant dimension tweaking. The architecture is straightforward: - **Frontend**: React 19 with TanStack Start - **3D rendering**: Three.js via React Three Fiber - **CAD engine**: OpenSCAD compiled to WebAssembly, running in a Web Worker - **AI**: Claude API with a single agentic endpoint that switches between "parametric mode" (OpenSCAD) and "mesh mode" (textured 3D) - **Backend**: Supabase for auth, database, and storage One clever optimization: simple parameter adjustments bypass the LLM entirely. When you move a slider, the app does a deterministic regex update on the OpenSCAD source. No API call, instant feedback. The founders note in their launch post that "surprisingly, in our evals Gemini 3.1 Pro is the top model" for this task. --- ## The HN Debate: Useful Tool or Toy? The discussion split into two camps. ![Abstract systems illustration for The HN Debate: Useful Tool or Toy?](/images/blog/adam-ai-cad-yc-w25-open-source-text-to-cad/inline-1.webp) **The skeptics** argued that text-to-CAD solves the wrong problem. User `tapia`, who appears to work in CAD professionally, made the point repeatedly: > CAD is really not so complicated with the tools we currently have. You just have to learn how to use them... describing complex geometries with specific tolerances with natural language is much more complex than creating the geometry programmatically. User `q3k` was blunter about the V8 engine example in the README: > Yeah, no, that is a lie. This is not a CAD model. It is a fantasy 3d model that looks like it is straight out of Gearhead Garage (1999)... Show me something functional that you have actually manufactured. The critique: AI-generated CAD models look impressive in renders but lack the dimensional tolerances, fastener specifications, and design intent required for actual manufacturing. The V8 engine demo has cams intersecting each other and no thought given to how it would be assembled. **The optimists** pushed back on the narrow framing. User `dgellow` defended the 3D printing use case: > The 3D print market is pretty large and tools to generate some designs that can then be tweaked are pretty useful in that context. I do not think that type of AI CAD tool would replace professional CAD work, that is something that requires way too much context and human judgement. The founder `zachdive` agreed, positioning CADAM as "AI TinkerCAD" - a tool for rapid prototyping and hobbyist work, not production engineering. --- ## The Legitimate Use Cases Reading between the lines of the discussion, three use cases emerge where text-to-CAD makes sense: **Rapid prototyping.** When you need a bracket, enclosure, or fixture for a one-off project, getting a starting point from a text description is faster than learning or re-learning a CAD tool. The output needs iteration, but the first draft is free. **Hobbyist 3D printing.** For parts that do not need to interface with other components or meet tolerance specs, the generated models are often good enough to print directly. A custom phone stand does not need GD&T. **Education and exploration.** Learning CAD is a significant time investment. Text-to-CAD lowers the barrier for people who want to explore mechanical design without committing to mastering SolidWorks or Fusion 360. The founder mentioned that their commercial extensions for Onshape and Fusion 360 include face and edge selection context - you can select geometry and describe what you want done to it. That hybrid interface (traditional selection plus natural language) may be more practical than pure text-to-CAD for complex assemblies. --- ## Technical Details Worth Noting A few implementation choices stand out: ![Abstract systems illustration for Technical Details Worth Noting](/images/blog/adam-ai-cad-yc-w25-open-source-text-to-cad/inline-2.webp) **OpenSCAD as the intermediate representation.** This is a deliberate choice. OpenSCAD is a code-first CAD tool - models are programs, not interactive designs. That makes it a natural fit for LLM generation. The downside: OpenSCAD uses CSG (constructive solid geometry) primitives, which are less expressive than the B-rep approaches used by professional CAD tools. The founders acknowledge this and mention plans to support build123d and CadQuery for constraint-driven modeling. **Parameters are first-class.** The system extracts dimensions as named parameters that users can adjust via sliders. This is the right UX choice. Instead of regenerating the entire model for a small tweak, you adjust the parameters directly. **Model-agnostic backend.** CADAM supports Claude, Gemini, and OpenAI models through OpenRouter. The Vercel AI SDK handles the routing. **GPLv3 license.** The open source release is under GPL, which matters if you are thinking about commercial derivatives. --- ## My Take The skeptics are right that text-to-CAD is not going to replace SolidWorks for production engineering anytime soon. The gap between "looks like a V8 engine" and "can be manufactured as a V8 engine" is enormous, and natural language is a poor interface for specifying tolerances, material properties, and assembly constraints. But the skeptics are also fighting a straw man. Nobody is claiming this replaces professional CAD workflows. The real question is whether text-to-CAD is useful for the long tail of simpler problems: brackets, enclosures, adapters, fixtures, organizers, holders, and the thousand other small parts that people design and 3D print. For that use case, getting a parametric starting point from a sentence is genuinely valuable. You are trading precision for speed. The output is not manufacturing-ready, but it is iteration-ready. The more interesting angle is the hybrid interface - traditional CAD selection plus natural language commands. That could make existing CAD tools more accessible without dumbing them down. Select a face, type "add a 5mm chamfer," get a valid operation. The Adam team's Fusion and Onshape extensions are exploring this direction. Worth watching how this evolves. The underlying models are getting better at code generation, and OpenSCAD is just code. --- ## Sources - [CADAM GitHub Repository](https://github.com/Adam-CAD/CADAM) - Open source codebase - [Hacker News Launch Discussion](https://news.ycombinator.com/item?id=48572553) - 87 comments, 189 points - [Adam Website](https://adam.new/) - Commercial product and Onshape/Fusion extensions - [OpenSCAD Documentation](https://openscad.org/documentation.html) - The underlying CAD language

Emacs 31 is Around the Corner: The Features Worth Daily Driving

Developers Digest — Thu, 18 Jun 2026 00:00:00 GMT

Emacs 31 is approaching release, and developer Rahul M. Juliato has been running the development branch since mid-2026. His writeup on the changes hit the front page of Hacker News with strong engagement - 391 points and 208 comments as of this writing. The release continues a trend where core Emacs absorbs features that previously required external packages, gradually reducing configuration complexity for new and experienced users alike. ## Tree-sitter Finally Gets Practical The biggest quality-of-life improvement is automatic grammar installation. Previously, using tree-sitter (the incremental parsing library that enables better syntax highlighting and code navigation) required manual configuration. You had to set up `treesit-language-source-alist`, fetch grammars, compile them, and configure your modes to use the tree-sitter variants. Emacs 31 changes this with two new options: - `treesit-auto-install-grammar` automatically fetches and builds missing grammars when you open a file - `treesit-enabled-modes` automatically switches major modes to their tree-sitter variants The release also ships built-in grammar sources for TypeScript, Rust, TOML, YAML, and Dockerfile - eliminating the need for manual configuration in most common cases. One caveat noted in the original post: auto-installed grammars are not segregated by architecture. If you share your `.emacs.d` across different systems (say, an x86 Linux machine and an ARM Mac), you will need to handle architecture differences yourself. ## Built-in Markdown Mode `markdown-ts-mode` is a new experimental built-in mode that brings Org-like keybindings to Markdown editing: - Syntax-highlighted code blocks using actual language modes - Inline image rendering - Org-mode-inspired navigation and folding The mode is still experimental and requires manual activation via `M-x load-library`, but having a built-in option means less dependence on external packages for one of the most common file formats developers work with. ## Window Management Commands New commands simplify layout rearrangement: - `window-layout-transpose` swaps horizontal/vertical arrangements - `window-layout-rotate-clockwise` rotates the entire window layout - `window-layout-flip-leftright` and `window-layout-flip-topdown` mirror layouts These commands fill gaps that previously required custom elisp or third-party packages like `transpose-frame`. ## Completion System Improvements The minibuffer completion experience gets several enhancements: - `completion-eager-update` refreshes suggestions while typing - `completion-eager-display` set to `'auto'` shows completions automatically - `minibuffer-visible-completions` enables arrow-key navigation through candidates These make vanilla Emacs completion feel more like modern completion frameworks without requiring external packages. ## Terminal Finally Works Properly The `term` buffer now correctly renders full-screen terminal applications like `htop`. This has been a longstanding pain point - Emacs' terminal emulation has historically struggled with applications that use the full terminal screen. ## What HN is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48584135) is substantial and reflects the Emacs community's engagement with the editor's development. **On continued relevance:** One heavily-upvoted comment noted that after briefly switching to VSCode for AI integration, they have returned to 100% Emacs now that Claude works well inside the editor. The argument: "There just isn't anything like the old editors, built in the 80x24 terminal era, for getting huge swathes of code on your screen at once." The commenter runs a widescreen monitor with three vertical Emacs windows, often splitting each into two frames, putting six contexts on screen simultaneously. "I'm not an IDE hater but they do put an awful lot of stuff on the screen that on a proportional basis I'm just not using as much as I use the code editor." **On the tree-sitter improvements:** Multiple commenters expressed excitement about the automatic grammar installation: "Sweet. GLP1 for my .emacs!" (referring to weight loss drugs that help reduce bloated configs). The tree-sitter integration has apparently revitalized the project. As one commenter put it: "Somewhere around treesitter something seems to have revitalized the project... You end up with a lot more wood behind fewer arrows when the project is able to put more work into generally-useful tools rather than every single language community maintaining their own separate mode for each language." **On the vim emulation:** Discussion touched on evil-mode (Emacs' vim emulation): "I've only ever used emacs in vim mode (evil-mode). Its vim emulation is the best I've seen anywhere." Some mentioned the daemon/client workflow - `emacs --daemon` with `emacsclient` - that makes opening files nearly instant by keeping a running Emacs instance. **On terminal emulators:** Several commenters recommended [Ghostel](https://github.com/dakra/ghostel), a newer terminal emulator backed by `libghostty-vt` that handles modern TUI applications better than `vterm`. One co-maintainer noted it is particularly good with Claude Code's interface animations. **On the common objections:** The thread addressed the two most common complaints about Emacs: 1. **Steep learning curve** - acknowledged but viewed as a worthwhile investment 2. **Wrist pain from key combinations** - solutions include remapping Caps Lock to Control, using the meat of your hand to hit Control rather than your pinkie, or using vim emulation via evil-mode ## Other Notable Improvements **Speedbar:** Now docks to side windows instead of spawning separate floating frames. **Xref buffers:** Support inline editing with `xref-edit-mode`, eliminating the need for grep workarounds when making bulk changes across files. **Version control:** `vc-dir-auto-hide-up-to-date` automatically hides up-to-date files during directory refreshes. **Quality-of-life:** - `kill-region-dwim` makes `C-w` kill words when no region is active - `view-lossage-auto-refresh` provides live keystroke visualization for teaching - `ielm-history-file-name` persists REPL history across sessions **Modus Themes:** Emacs 31 ships with eight accessibility-focused color schemes, including deuteranopia and tritanopia variants for color-blind users. ## Should You Try It? If you are already an Emacs user, the tree-sitter improvements alone might be worth running the development branch. The reduced configuration burden for syntax highlighting across languages addresses one of Emacs' historical pain points. If you have been Emacs-curious but put off by the setup complexity, Emacs 31 moves in the right direction. More features work out of the box, and the completion system improvements make vanilla Emacs feel more modern without requiring a framework like Doom or Spacemacs. The continued development also signals something about the editor's future. While much of the developer tools conversation has shifted to AI coding assistants, there is clearly still a dedicated community working on and using Emacs - and the project is incorporating features (tree-sitter, better completions, working terminals) that keep it relevant for modern development workflows. ## Sources - [Original article: Emacs 31 is around the corner](https://www.rahuljuliato.com/posts/emacs-31-around-the-corner) - [Hacker News discussion](https://news.ycombinator.com/item?id=48584135) - [Ghostel terminal emulator](https://github.com/dakra/ghostel) - [GNU Emacs development branch](https://git.savannah.gnu.org/cgit/emacs.git)

Local Qwen Is a Different Tool, Not a Worse Opus

Developers Digest — Thu, 18 Jun 2026 00:00:00 GMT

A post from Alex Ellis hit the front page of Hacker News this morning with 263 points and 128 comments. The thesis is simple but underappreciated: local Qwen models are not inferior substitutes for Claude Opus. They are different tools for different jobs. The discussion that followed is one of the more grounded conversations about local LLMs I have seen this year. **Last updated:** June 18, 2026 --- ## The Core Argument Ellis runs a production software business and invested roughly $12,000 USD in an RTX 6000 Pro with 96GB VRAM to run local models. The hardware paid for itself in 2-3 months through two concrete revenue streams: analyzing confidential customer telemetry (work that could not go to cloud APIs) and detecting license underreporting. The headline claim that gets thrown around - "Qwen 27B is only 12% behind Opus on SWE-bench" - gets Ellis's skepticism. Benchmarks are optimizable. Since they are public, models can be tuned to score well on them. What actually matters is how the model performs on your specific workload. From the article: > Benchmarks are a moving target, and since they are widely available, it is possible to educate and tune a model to obtain a higher score. For reference, the numbers being discussed are Qwen 3.6 27B at 77.2% on SWE-bench Verified versus Claude Opus 4.8 at 88.6%. That gap matters more on some tasks than others. --- ## Where Local Models Actually Work Ellis identifies several workloads where local inference wins clearly: ![Abstract systems illustration for Where Local Models Actually Work](/images/blog/local-qwen-different-tool-not-worse-opus/inline-1.webp) **Privacy and data sovereignty.** Enterprise customers with sensitive data cannot send it to third-party APIs. Full stop. No amount of API quality makes up for a compliance violation. **Fixed cost economics.** Cloud API pricing is unpredictable at scale. Local hardware is a capital expense with predictable operating costs. For high-volume inference, the math often favors owning the metal. **Vendor risk protection.** Ellis cites Anthropic's sudden removal of Fable 5 access as a concrete example. When your business depends on a model, owning the weights eliminates a category of risk. **Revenue-generating analysis.** The most interesting example: analyzing customer telemetry to detect license underreporting. This work generates direct revenue but requires processing data that cannot leave your infrastructure. --- ## Where Local Models Fail The article is honest about the limitations. Local models - including the best Qwen checkpoints - have severe reliability issues on complex tasks: - Infinite looping on long-horizon work - Hallucinations and arithmetic failures - Cannot be left unsupervised for open-ended coding Ellis describes them as "incredibly early" and requiring operational discipline. You cannot hand a local model a vague task and walk away. You need to scope tasks narrowly, monitor execution, and intervene when things go wrong. The takeaway: local models are specialists, not generalists. Use them for bounded, well-defined problems. Keep cloud models for the unbounded creative work. --- ## What HN Is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48580209) is unusually substantive. Several threads stand out. **The early PC analogy.** User `usernomdeguerre` compared local LLMs to early personal computers: "I believe that local models are a necessary extension of the personal computer and I imagine that one could have had similar criticisms of early personal computers." The power consumption and noise of a 3090 or 5090 mirrors early DOS machines. The question is whether local inference follows the same improvement curve. **Privacy trumps capability for many use cases.** User `i_idiot` pushes back on the "most people need SOTA" framing: "When I run that qwen model in my measly 4070 12 GB for my personal email agent... I need privacy more than anything else. It does a great job." For bounded tasks where the model is good enough, keeping data local is the deciding factor. **The hybrid model dream.** User `theshrike79` describes the ideal workflow: "My dream would be a local model that can do, say, 80% of the day to day tasks... and most importantly - the ability to go 'this task is beyond my skills' and refer to a Big Boy Online Model." Several commenters noted that Claude's Advisor feature already does something like this, but open harnesses could implement the same routing. **Hardware efficiency is improving.** User `regularfry` reports getting 40-50 tokens per second from Qwen 3.6 27B on a 4090 limited to 350W with the MTP changes. That translates to roughly 8.75 joules per token - still power hungry, but improving. **Benchmarks do not capture the full picture.** User `glerk` makes the point that prompting technique differs by model: "If you play with these models long enough, you realize there is more to them than just 'model X is smarter than model Y'... They are different tools and the prompting technique is different. It is very much like playing an instrument." User `theshrike79` extends this to harnesses: "We should not just measure the power of the raw LLM, harnesses matter more and more." --- ## The ROI Question The most concrete number in Ellis's post is the payback period: 2-3 months on a $12,000 hardware investment. That math depends heavily on your use case. If you have high-volume inference needs on sensitive data, local hardware can pay for itself quickly. If your workload is sporadic and not privacy-sensitive, API costs may never justify the capital expense. The RTX 6000 Pro with 96GB VRAM is an interesting hardware choice. It sits between consumer GPUs (24GB on a 4090) and datacenter cards (80GB on an H100). For the Qwen 27B workload - roughly 22GB at Q4_K_M quantization - you could run on a 4090, but the extra headroom allows running multiple models simultaneously or handling longer contexts without swapping. --- ## Practical Takeaways 1. **Stop comparing benchmarks in isolation.** The 77% vs 88% gap on SWE-bench tells you less than whether the model handles your specific task reliably. 2. **Local models are tools, not replacements.** Treat them like a screwdriver, not a Swiss Army knife. Narrow scope, well-defined inputs, supervised execution. 3. **The privacy premium is real.** For many enterprises, the ability to keep data on-premises is not a nice-to-have. It is a compliance requirement. 4. **Hardware ROI depends on volume.** $12,000 is a lot of API calls. If you are not doing high-volume inference, the payback period stretches. 5. **The hybrid future is here.** The winning architecture is probably local models for routine work with cloud escalation for complex tasks. The tooling to make this seamless is still immature. --- ## Sources - [Local Qwen isn't a worse Opus, it's a different tool](https://blog.alexellis.io/local-ai-is-not-opus/) - Alex Ellis's original post - [Hacker News discussion](https://news.ycombinator.com/item?id=48580209) - 128 comments, 263 points - [SWE-bench Verified Leaderboard](https://www.swebench.com/) - Current benchmark standings - [Best Local Coding LLMs in 2026](/blog/best-local-coding-llms-2026) - Our deep dive on local model options

Mellum2 Developer Guide: JetBrains' Open-Source Coding Model

Developers Digest — Thu, 18 Jun 2026 00:00:00 GMT

## Official Sources | Source | Link | |--------|------| | JetBrains Mellum2 Blog Post | [blog.jetbrains.com/ai/2026/06/mellum2-goes-open-source](https://blog.jetbrains.com/ai/2026/06/mellum2-goes-open-source-a-fast-model-for-ai-workflows/) | | Hugging Face Model Collection | [huggingface.co/collections/JetBrains/mellum-2](https://huggingface.co/collections/JetBrains/mellum-2) | | JetBrains AI Blog | [blog.jetbrains.com/ai](https://blog.jetbrains.com/ai/) | | Mellum2 Hugging Face Blog | [huggingface.co/blog/JetBrains/mellum2-launch](https://huggingface.co/blog/JetBrains/mellum2-launch) | | Ollama Mellum-4b (prior version) | [ollama.com/JetBrains/Mellum-4b-base](https://ollama.com/JetBrains/Mellum-4b-base) | JetBrains released Mellum2 on June 2, 2026 under the Apache 2.0 license. It is a 12-billion parameter Mixture-of-Experts model that activates only 2.5B parameters per token - roughly 5x less compute per forward pass than a dense 12B model. The result is sub-second inference on modest hardware while maintaining competitive benchmark scores for code generation, reasoning, and routing tasks. This is not a replacement for Claude, GPT-5.5, or DeepSeek V4. JetBrains explicitly positions Mellum2 as a "focal model" - a fast, specialized component inside larger AI systems. Think: routing decisions, RAG summarization, sub-agents, local code completion, and any task where latency matters more than peak reasoning quality. **Last updated:** June 18, 2026 ## What Mellum2 Is Built For Mellum2 is trained on natural language and code data. It deliberately avoids multimodal capabilities - no images, no audio - in favor of specialization for software engineering workflows. The core use cases JetBrains highlights: **Routing and orchestration.** Analyze incoming prompts and decide which model or tool handles them. At 2.5B active parameters, Mellum2 can make routing decisions in milliseconds rather than seconds. **RAG pipeline acceleration.** Summarize retrieved context before passing it to a frontier model. Keeping the context window smaller for the expensive model saves tokens and improves coherence. **Fast sub-agents.** In agentic workflows where you need a quick classification, extraction, or decision before the main agent continues, Mellum2 handles the intermediate step without blocking. **Private local deployment.** Teams with data residency requirements or air-gapped infrastructure can run Mellum2 entirely on-premise. No API calls, no token billing, no third-party data exposure. **High-throughput code features.** IDE completions, inline suggestions, and background analysis where sub-second latency is required. ## Architecture and Efficiency Mellum2 uses a Mixture-of-Experts architecture with 64 total experts, activating 8 per token. The full model has 12B parameters, but inference only touches 2.5B per forward pass - a roughly 5x reduction in compute compared to running all 12B. JetBrains reports inference times "less than half" compared to similar-sized models. In practice, this means: - Faster time-to-first-token for interactive use - Higher throughput for batch processing - Lower GPU memory pressure for concurrent requests The 8192-token context window is sufficient for most code completion and summarization tasks, though shorter than frontier models. For tasks requiring longer context, you would still reach for a model with 128K+ context. ## Benchmark Performance JetBrains shared benchmark results for Mellum2 across several evaluation suites. The model competes with similar-sized open-weights models while being faster to run: | Benchmark | Category | |-----------|----------| | LiveCodeBench v6 | Code generation | | AIME 2025/26 | Mathematical reasoning | | GSMPlus | Grade-school math | | GPQA Diamond | Graduate-level science | | MMLU-Redux | General knowledge | The raw numbers position Mellum2 as competitive with other 12B-class models on code tasks, with the efficiency advantage making it practical for higher-volume deployments. It does not match frontier models like Fable 5, GPT-5.5, or DeepSeek V4-Pro on complex reasoning - but that is not the intended use case. For SWE-bench and similar agentic evaluations, Mellum2 is better suited as a helper model (routing, summarization, tool selection) than as the primary agent. ## Local Deployment Options Mellum2 weights are available through Hugging Face under the Apache 2.0 license. You can run it locally in several ways: ### vLLM (Recommended for Production) vLLM supports Mellum2 natively and is the recommended choice for production deployments. The MoE architecture works well with vLLM's optimized inference engine. ```bash pip install vllm # Download and serve python -m vllm.entrypoints.openai.api_server \ --model JetBrains/Mellum2-12B \ --tensor-parallel-size 1 \ --max-model-len 8192 ``` This exposes an OpenAI-compatible API endpoint at `http://localhost:8000/v1`. ### Hugging Face Transformers For development and experimentation: ```python from transformers import AutoModelForCausalLM, AutoTokenizer model_name = "JetBrains/Mellum2-12B" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, device_map="auto", torch_dtype="auto" ) prompt = "def fibonacci(n):" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate(**inputs, max_new_tokens=100) print(tokenizer.decode(outputs[0])) ``` ### Ollama Compatibility Early community reports suggest Ollama has compatibility challenges with Mellum2's MoE architecture. The earlier Mellum-4b (dense model) works with Ollama, but the new MoE version may require workarounds. Check the Ollama community for current status. If you need Ollama specifically, consider using the 4B dense variant while waiting for official MoE support: ```bash ollama pull JetBrains/Mellum-4b-base ``` ### Hardware Requirements For the full 12B model with 2.5B active parameters: - **Minimum:** 16GB VRAM (RTX 4080, A100 40GB) - **Recommended:** 24GB VRAM for comfortable batch processing - **Quantization:** INT8/INT4 quantization reduces memory further if needed The MoE architecture means memory footprint is larger than a 2.5B dense model (you still load all experts), but inference is faster. ## When to Use Mellum2 **Good fit:** - Local code completion where latency matters more than peak quality - Routing decisions in multi-model pipelines - RAG context summarization before calling a frontier model - Sub-agent tasks in agentic workflows - Private deployments with no API access - High-volume classification and extraction tasks - Development and testing before committing to frontier API costs **Not a fit:** - Primary agent for complex multi-step reasoning - Tasks requiring 128K+ context windows - Replacing Fable 5, GPT-5.5, or DeepSeek V4 as your main coding model - SWE-bench-style issue resolution as the sole agent - Multimodal tasks (images, diagrams, screenshots) ## Integrating With Claude Code Mellum2 can serve as a fast local model for tasks that do not need frontier reasoning. One pattern is using Mellum2 for initial triage and routing, then handing off to Claude Code for complex work. Example setup with a custom MCP server that routes to Mellum2 locally: ```json { "mcpServers": { "mellum-router": { "command": "python", "args": ["-m", "mellum_mcp_server"], "env": { "MELLUM_MODEL_PATH": "/path/to/mellum2", "MELLUM_PORT": "8000" } } } } ``` This lets Claude Code offload fast classification, summarization, or extraction tasks to Mellum2 while keeping complex reasoning on the frontier model. ## Mellum2 vs Other Local Models | Model | Size | Active Params | License | Best For | |-------|------|---------------|---------|----------| | Mellum2 | 12B | 2.5B | Apache 2.0 | Fast routing, code completion, sub-agents | | DeepSeek V4-Flash | 17B | 4B | MIT | High-throughput coding, API + self-host | | Qwen3-8B | 8B | 8B | Apache 2.0 | Balanced local coding | | Llama 4.1-8B | 8B | 8B | Llama License | General-purpose local model | Mellum2's advantage is the combination of code specialization and MoE efficiency. DeepSeek V4-Flash is stronger on absolute capability but has higher active parameters. Qwen3 and Llama 4.1 are competitive but dense, meaning slower inference at similar parameter counts. ## FAQ ### What is Mellum2? Mellum2 is a 12-billion parameter Mixture-of-Experts model from JetBrains, released June 2, 2026 under Apache 2.0. It activates only 2.5B parameters per token, making it efficient for high-throughput inference while maintaining competitive benchmark scores for code generation and reasoning tasks. ### How do I run Mellum2 locally? The recommended approach is vLLM for production or Hugging Face Transformers for development. Download the model from Hugging Face (`JetBrains/Mellum2-12B`) and serve it with vLLM's OpenAI-compatible API server. Ollama support for the MoE architecture is still being worked on. ### Is Mellum2 free to use? Yes. Mellum2 is released under the Apache 2.0 license, which permits commercial use, modification, and distribution. There are no API costs - you run inference on your own hardware. ### How does Mellum2 compare to DeepSeek V4? DeepSeek V4-Pro is stronger on absolute capability and benchmarks like SWE-bench. Mellum2 is faster and more efficient for high-volume, lower-complexity tasks. Many teams use both: Mellum2 for routing, summarization, and fast sub-agents; DeepSeek V4 or a frontier model for complex reasoning. ### Can Mellum2 replace Claude Code or Cursor? No. Mellum2 is designed as a component model, not a standalone IDE agent. It works best alongside frontier models - handling routing, summarization, and fast tasks while the frontier model handles complex reasoning. ### What hardware do I need to run Mellum2? Minimum 16GB VRAM (RTX 4080, A100 40GB). The full 12B model loads all experts into memory, but inference only activates 2.5B per token. INT8 quantization can reduce memory requirements if needed. ### Does Mellum2 support MCP? Mellum2 is a model, not a tool. You can build MCP servers that use Mellum2 for inference, and several community implementations exist. The model itself does not have MCP built in - you provide the tool infrastructure. ### What context length does Mellum2 support? 8192 tokens. This is sufficient for most code completion and summarization tasks but shorter than frontier models with 128K+ context. For long-context tasks, use a model with a larger window. ## Sources - [JetBrains Mellum2 Open Source Announcement](https://blog.jetbrains.com/ai/2026/06/mellum2-goes-open-source-a-fast-model-for-ai-workflows/) - June 2, 2026 - [Hugging Face Mellum2 Launch Blog](https://huggingface.co/blog/JetBrains/mellum2-launch) - [MarkTechPost: JetBrains Releases Mellum2](https://www.marktechpost.com/2026/06/02/jetbrains-releases-mellum2-a-12b-moe-model-for-fast-specialized-tasks-in-multi-model-ai-pipelines/) - [The New Stack: JetBrains open-sources Mellum2](https://thenewstack.io/jetbrains-mellum2-open-source-coding-model/) - [Neowin: JetBrains open-sources Mellum 2](https://www.neowin.net/news/jetbrains-open-sources-mellum-2-featuring-12b-total-parameters/)

Midjourney Built a Full-Body Scanner: The Image-Generation Company's Strangest, Most Revealing Bet Yet

Developers Digest — Thu, 18 Jun 2026 00:00:00 GMT

## Official Sources | Topic | Source | |------|--------| | The announcement ("A New Era of Midjourney") | [Midjourney Medical blog post](https://www.midjourney.com/medical/blogpost) | | Hardware specs, Butterfly Network deal, 60-second claim | [Engadget](https://www.engadget.com/2196998/midjourney-full-body-ultrasonic-scanner/) | | "Big claims, no track record" skeptical framing | [The Next Web](https://thenextweb.com/news/midjourney-scanner-midjourney-medical-ultrasound) | | Strategy / world-model thesis | [Latent Space](https://www.latent.space/p/ainews-midjourney-medical-scan-your) | | Community reaction | [Hacker News thread (id 48579650)](https://news.ycombinator.com/item?id=48579650) | The most surprising AI announcement of the month did not come from a model lab, did not involve a new model, and barely involves AI at all. On June 17, David Holz, the founder of Midjourney, walked on stage and unveiled a machine that scans the inside of your body. Then he announced a spa to put it in. This is the company whose entire identity is making pretty pictures from text prompts. The instinct is to file it under "founder hubris" and move on. That instinct is wrong, or at least incomplete. The scanner is a strange product, the medical claims deserve heavy skepticism, and the regulatory path is genuinely brutal. But the move tells you something real about how the most ambitious people in generative AI now think about where the value is going. It is worth taking seriously precisely because it is so easy to dismiss. ## What Midjourney actually announced Holz introduced **Midjourney Medical**, a new division, and **the Midjourney Scanner**, a full-body ultrasonic CT imaging device. The pitch is a whole-body scan in roughly **60 seconds**, framed as something as casual as a trip to a spa rather than a trip to a hospital. The mechanism is genuinely interesting. Per [Midjourney's announcement](https://www.midjourney.com/medical/blogpost) and [Engadget](https://www.engadget.com/2196998/midjourney-full-body-ultrasonic-scanner/)'s reporting: - You step onto a platform in a shallow pool of warm water, and the platform lowers you at about **five centimeters per second** through a ring of sensors. - The ring is packed with around **half a million elements, each the size of a grain of sand**, and each one can both emit ultrasound and listen for the echoes. Midjourney's own framing is that each acts "like a dolphin" using echolocation. - The imaging is built on **40 Butterfly Network Ultrasound-on-Chip modules** backed by roughly **2 petaflops** of processing. - The system fires ultrasound through the body from every angle and reconstructs a 3D map from the returning echoes. The headline comparison is the provocative one: Holz claims the result is "in many ways superior to even MRI machines," with **no radiation, no heavy magnets, at nearly a hundred times the speed**. The business plan is just as audacious. The first **Midjourney Spa** opens in San Francisco's Union Square before the end of 2027 with about 10 scanners, complete with hot tubs, saunas, and cold plunges. The 2031 goal is a fleet of **over 50,000 scanners worldwide** doing **a billion scans a month** more total imaging capacity than every MRI machine on Earth combined. ![Overhead view of the scanner's ring of sand-grain ultrasonic sensors surrounding a suspended body form, rendered as an abstract cream-and-ink diagram](/images/blog/midjourney-medical-full-body-scanner/scan-pool.webp) There is one detail that reframes the whole thing, and Midjourney says it plainly: **there is almost no AI in this device.** It is hardware and signal processing. The imaging tech is licensed from [Butterfly Network](https://www.engadget.com/2196998/midjourney-full-body-ultrasonic-scanner/) under a deal signed in November 2025 $15M upfront plus $10M a year for five years, with performance bonuses. A company famous for AI just shipped its most ambitious thing yet, and the AI is the part that hasn't been built. ## Why an image company is building a body scanner Here is the part that's easy to miss if you stop at "lol, a spa." Midjourney's roadmap, as Holz has described it for over a year, is a ladder: **images → video → 3D → real-time world models.** Static images were step one. The [V1 video model](https://updates.midjourney.com/introducing-our-v1-video-model/) in April 2026 was step two. The destination Holz keeps naming is real-time, navigable, open-world simulation systems that don't generate a picture of a world but render a coherent world you can move through. ![Abstract diagram of a body dissolving into sensor points beside a four-stage pipeline of cards moving from image to video to 3D to world model](/images/blog/midjourney-medical-full-body-scanner/pipeline.webp) Read against that ladder, the scanner stops looking like a non sequitur. As the [Latent Space analysis](https://www.latent.space/p/ainews-midjourney-medical-scan-your) put it, Holz's framing is that "the future is not only about AI models but about new infrastructure that lets AI reason over the physical body." The interesting phrase in his pitch isn't "60-second scan." It's the emphasis on **"longitudinal, high-frequency, sub-millimeter differential tracking"** not one scan, but the same body measured repeatedly over time. That is a data-acquisition strategy dressed as a wellness product. If you want to build models that reason about physical reality, you need dense, real, frequently-sampled data about physical reality. A scanner that a billion people step into monthly is, among other things, the largest structured dataset about human bodies ever assembled. The financial structure makes the bet possible. Midjourney is profitable on image generation and, as Latent Space notes, positions itself as **"a community-supported research lab, not a normal VC-backed startup."** That's not just branding. A venture-backed company answerable to a board does not get to spend image-generation profits building underwater ultrasound rings on a five-year horizon. Midjourney does, because nobody can stop it. Whatever you think of the product, the *structure* the freedom to make an illegible long-term bet funded by a legible cash cow is the most strategically interesting thing here. There's also a defensive read worth naming. In static images, Midjourney is still the quality leader but DALL·E 3 and the ChatGPT ecosystem keep pulling casual users into the gravity well, and in video, Sora 2 owns narrative generation while Midjourney's clips top out around 21 seconds. The image-gen category is commoditizing. Pivoting some of the surplus toward a category nobody else is in coastal-grade medical sensing is the kind of move a company makes when it can see the core business maturing and wants the next act to be somewhere the incumbents aren't. ## The skeptics are right about the hard part None of the above means the product works as a *medical* product. It means the strategy is coherent. Those are different claims, and the gap between them is where this could die. The single best summary of the problem comes from [The Next Web](https://thenextweb.com/news/midjourney-scanner-midjourney-medical-ultrasound): big claims, no track record. Midjourney has never built a physical product, never operated a medical device, and has no regulatory clearance. By the company's own account, the device today produces only "detailed body composition maps" body fat, muscle, organ size and not diagnoses. That distinction is not modesty; it's regulatory positioning. Body composition mapping sits *below* diagnostic imaging in the FDA hierarchy, which is exactly how you ship something today without clearance. Anything that would make this a real MRI rival detecting disease requires FDA approval Midjourney admits it does not have and will "pursue over time." "Over time" is carrying a lot of weight. The hardest, most expensive, least glamorous part of the entire project is the part that hasn't started. ## What Hacker News actually said The [Hacker News thread](https://news.ycombinator.com/item?id=48579650) is the most useful read on this, because it split cleanly into informed enthusiasm and informed skepticism, and both sides are worth hearing. On the **hardware**, the surprise was that it mostly holds up. A commenter who has worked with MRI and phased-array beamforming wrote that the design "perhaps surprisingly doesn't trigger any immediate major technical red flags." Ultrasound tomography is real physics; the transducer arrangement is plausible. That's a meaningful signal it means the skepticism is not "this is fake," it's "this is hard in ways unrelated to the physics." But an engineer who designs scanners for the incumbents was blunt about the marketing. Reacting to the superior-to-MRI framing, **Aromasin** wrote: "I help engineers design traditional scanners (Philips, GE, Siemens, etc). To be frank, this statement stinks like utter pig shit." Ultrasound cannot image through air or bone, which rules out the interior of the lungs and most of the brain, and its resolution is coarser than CT or MRI. "Superior to MRI" is true on speed, radiation, and cost, and false on exactly the axes radiologists care most about. On the **FDA**, the consensus was that Midjourney is underestimating the wall in front of it. As **randusername** put it: "This is just not how the FDA works. At all. You can't just email them slideware and marketing materials to keep them in the loop." The clinical-validation gap is real a prototype reportedly tested on around a dozen people, no published sensitivity/specificity data, no peer review, no head-to-head against MRI. The most substantive medical critique wasn't about the FDA at all. It was about **overdiagnosis** the well-documented harm of scanning healthy people. **convnet** wrote: "Every human body is a bit weird and there will almost always be something 'wrong' that will be visible in a full body scan... many of these oddities would never have caused issues." **logravia** sharpened it: "False positives are the primary issue. False positives lead to stress, invasive diagnostic procedures and wasted medical resources." This is the part the spa framing quietly buries. A billion scans a month on asymptomatic people is also a machine for generating a billion incidental findings, a large fraction of which lead to anxiety, biopsies, and follow-ups for things that would never have hurt anyone. And yet the optimists on the thread weren't naive, they just weighted the upside differently. **noduerme**: "The vast majority of people on the planet have exactly zero hard data on their ailments... Bring on the terabytes and let's see what we can do." **tgsovlerkhgsel** went straight at the actual long-game: "With a big enough data set... labeled with diagnoses, I suspect we could get very fast and accurate automatic diagnoses." That last comment is, inadvertently, the strongest statement of *why Midjourney is doing this at all*. The scanner isn't the product. The longitudinal dataset, and the diagnostic models you could eventually train on it, is the product. The hardware is the data-collection rig. ## The Theranos question, handled honestly Every "wellness startup makes bold medical claims" story now gets the Theranos comparison, and it's worth addresssing rather than dodging. The comparison is fair as a *warning* and unfair as a *verdict*. Fair: bold superiority claims, direct-to-consumer positioning, a charismatic founder, a category (consumer medical testing) with a documented graveyard, and a sample size you could fit in a conference room. Skepticism is the correct default. Unfair: Theranos's core technology never worked and the company lied about it. Midjourney showed a working prototype, named its hardware partner, disclosed the deal terms, and stated openly that the device is non-diagnostic and that FDA clearance hasn't been obtained. Being honest about what you can't yet do is the precise opposite of the Theranos failure mode. The risk here isn't fraud. It's the more ordinary risk that the regulatory and economic case never closes and a genuinely cool engineering demo becomes an expensive monument. ## What builders should actually take from this You're probably not building a body scanner. But there are three transferable lessons in this announcement, and they're why it's worth your attention beyond the spectacle. **Profitable core, illegible bet.** The reason Midjourney can do this is a boring, profitable product subsidizing a wild one, with an ownership structure that doesn't force quarterly legibility. If you want to make long-horizon bets, the prerequisite isn't vision, it's a cash engine you control. Strategy is downstream of structure. **The data is the moat, not the device.** Strip away the spa and the move is: deploy hardware at scale to capture a proprietary, high-frequency, real-world dataset nobody else has, then train models on it later. That pattern owning the sensing layer to own the data to own the eventual model is the generalizable play, and it applies to far more mundane domains than medicine. **"Superior to MRI" is a tell.** When a demo's headline claim is strongest on the axes that are easy to measure (speed, cost) and quietly silent on the axes that are hard (resolution, validation, regulatory clearance), that asymmetry tells you where the real risk lives. Read announcements for what they *don't* benchmark against. Midjourney just did the most Midjourney thing imaginable: it took something nobody asked for, rendered it at impossible scale, and made you stare at it. Whether the scanner ever clears the FDA is genuinely uncertain, and the medical skepticism is earned. But underneath the spa branding is a clear-eyed bet that the durable value in AI is drifting toward whoever owns the interface to the physical world and the data it produces. That bet might not pay off here. It is not a stupid bet. --- *Want the strategic throughline on where AI value is actually accruing? Read our companion piece on [why orchestration, not the model, is becoming the product](/blog/perplexity-orchestration-is-the-product).*

Noam Shazeer Joins OpenAI After Two Years Back at Google

Developers Digest — Thu, 18 Jun 2026 00:00:00 GMT

Noam Shazeer, one of the most influential figures in modern AI research, announced Wednesday that he is leaving Google to join OpenAI. The move ends a second stint at Google that lasted barely two years - and comes after Google paid $2.7 billion in 2024 to bring him back from Character.AI. ## Who is Noam Shazeer? If you use any modern AI system - Claude, GPT-4, Gemini, or any open-source LLM - you are using Noam Shazeer's work. Shazeer co-authored the landmark 2017 paper "Attention Is All You Need," which introduced the Transformer architecture. That paper fundamentally changed AI research and directly enabled every large language model that exists today. The ideas in that paper - self-attention, multi-head attention, and the attention scaling mechanism - were largely his contributions. He joined Google in 2000, working on early projects including the search engine's spell checker. Over two decades, he became one of Google's most important AI researchers. In 2021, Shazeer left Google to co-found Character.AI, a chatbot startup that let users create and interact with AI personas. The company gained millions of users and raised significant funding. Then, in 2024, Google paid approximately $2.7 billion to bring Shazeer and co-founder Daniel De Freitas back, along with key research team members. Shazeer rejoined Google DeepMind as Vice President of Engineering and co-lead of the Gemini models, specifically tasked with improving Google's reasoning capabilities that were lagging behind OpenAI and Anthropic. Two years later, he is leaving again - this time for OpenAI. ## What HN is Saying The [Hacker News discussion](https://news.ycombinator.com/item?id=48578913) has been active with takes on what this means for both companies. **On the implications for Google:** The dominant sentiment is that this is bad news for Gemini. Multiple commenters noted that Google's brief comeback with Gemini 2.5 Pro last year appeared to be driven by Shazeer's contributions. One commenter pointed out that "Google paid a couple billion dollars to bring Noam back. Really impressive by OAI if this reporting is accurate!" Others expressed concern about Google's ability to retain top talent. The discussion touched on the classic "big public corp vs private startup" culture divide - once you have to worry about shareholders, regulations, and lawsuits, it becomes difficult to avoid turning into "big corp" culture. **On the "models have no moat" debate:** Several commenters pushed back on the idea that AI models have no moat. One noted that "only like 3-4 companies in the entire world have cutting edge models, that means there is some kind of moat." Others pointed to the deep engineering expertise required: "If it was just a matter of compute on hand and iterating, Meta would be neck and neck with Anthropic, OAI, and Google." The counter-argument: Google has structural advantages that go beyond individual researchers - custom TPU silicon, more data than anyone else, and phones in 73% of global smartphone users' hands to push AI integration. **On Shazeer's significance:** The thread emphasized that while the "Attention Is All You Need" paper listed authors alphabetically, the critical architectural ideas were largely Shazeer's. One commenter with apparent insider knowledge noted: "The author list was randomized, but the critical idea was truly his." A detailed reply outlined the paper's history: Jakob Uszkoreit had the initial insight about replacing sequential RNNs with parallel processing layers that could leverage GPU parallelism. When Uszkoreit couldn't get the implementation to outperform RNNs, he brought in Shazeer, who eventually arrived at the performant architecture that became the Transformer. ## Why This Matters This is being called one of the biggest AI talent shifts of 2026, comparable to Andrej Karpathy's earlier move to Anthropic. OpenAI CEO Sam Altman called Shazeer "one of the people I have most wanted to work with since the very beginning of OpenAI," adding that the partnership was "only 10 years" in the making. Shazeer himself described it as "a difficult decision to move on." The move raises questions on multiple fronts: **For Google:** What does it say about the internal culture at Google DeepMind that researchers keep leaving despite massive financial incentives to stay? The company has the resources, the data, the hardware - but apparently not the environment that attracts top talent long-term. **For OpenAI:** This is a major acquisition of foundational AI expertise. Shazeer brings not just architectural knowledge but also deep experience with scale - both the algorithmic optimizations and the production infrastructure needed to train and serve frontier models. **For the industry:** The AI talent market continues to consolidate around a few companies. The same small group of researchers keeps moving between Google, OpenAI, Anthropic, and a handful of startups. The knowledge and techniques they carry with them - including trade secrets - flow between competitors in ways that make the "moat" question genuinely complicated. ## What Comes Next Google DeepMind retains significant bench depth even without Shazeer. They have the hardware infrastructure (TPUs), the data advantage (Search, YouTube, Gmail), and the distribution through Android and Chrome. But losing the architect of the Transformer twice - first to Character.AI, now to OpenAI - suggests something structural about how Google runs its AI research that top researchers find limiting. For OpenAI, the question is what Shazeer will work on. His expertise in efficient architectures (he also developed the mixture-of-experts approach) could be applied to making models faster and cheaper to run. Or he could be working on whatever comes after the current Transformer paradigm. Either way, the AI industry just got a little more consolidated at the top. ## Sources - [Noam Shazeer Twitter announcement](https://twitter.com/NoamShazeer/status/2067400851438932297) - [The Decoder: Google's Gemini co-lead Noam Shazeer joins OpenAI](https://the-decoder.com/googles-gemini-co-lead-noam-shazeer-joins-openai-after-two-year-return-stint/) - [Benzinga: Sam Altman says it's 10 years in the making](https://www.benzinga.com/markets/tech/26/06/53269428/google-gemini-co-lead-noam-shazeer-joins-openai-sam-altman-says-its-10-years-in-the-making) - [Hacker News discussion](https://news.ycombinator.com/item?id=48578913) - [Attention Is All You Need (original paper)](https://arxiv.org/abs/1706.03762)

AI Model Routing: Why the Orchestration Layer Is the Next Big Play Next to the Labs

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Topic | Source | |------|--------| | $500M one-month enterprise Claude bill | [cybernews.com](https://cybernews.com/ai-news/claude-bills-client-500m-one-month-ai/) | | Anthropic run-rate and enterprise spend | [Inc. / Fast Company](https://www.inc.com/fast-company-2/company-spending-anthropic-claude-ai-costs/91356362) | | GLM-5.2 benchmarks and cost | [VentureBeat](https://venturebeat.com/technology/z-ais-open-weights-glm-5-2-beats-gpt-5-5-on-multiple-long-horizon-coding-benchmarks-for-1-6th-the-cost), [InfoWorld](https://www.infoworld.com/article/4186136/) | | Factory Router | [factory.ai/news/factory-router](https://factory.ai/news/factory-router) | | Perplexity / Aravind Srinivas on orchestration | [20VC](https://www.thetwentyminutevc.com/aravind-srinivas), [Fortune](https://fortune.com/2026/02/26/perplexity-ceo-aravind-srinivas-computer-openclaw-ai-agent/) | A short version for people who are budgeting right now: most of your tasks do not need a frontier model. The work that decides which model handles which task, and reserves the expensive model for the hard minority, is where the cost savings and the defensibility now live. This post is about that layer, why it is suddenly worth building on top of, and how to start cutting your own spend. ## The $500M wake-up call In late May 2026, reports surfaced that an enterprise client ran up roughly a **$500 million Claude bill in a single month** because it never set per-employee usage caps. Engineers pointed agents at frontier models, the agents looped, and nobody put a ceiling on any of it ([cybernews](https://cybernews.com/ai-news/claude-bills-client-500m-one-month-ai/)). That is an extreme case, but it is not an isolated one. Uber reportedly burned through its entire 2026 AI budget by April. Microsoft scaled back Claude Code licenses. Anthropic is at roughly a **$30 billion annualized run-rate**, up from about $9 billion at the end of 2025, with **more than 1,000 companies spending over $1M a year** ([Inc.](https://www.inc.com/fast-company-2/company-spending-anthropic-claude-ai-costs/91356362)). Read those numbers together and a pattern jumps out. The labs are not the ones with a cost problem. They are the ones collecting the bill. The cost problem belongs to everyone building on top of them, and it is getting worse precisely because frontier models are good enough that teams reach for them by default, for everything, without asking whether the task actually needs that horsepower. That default is the expensive habit. And the thing that fixes it is not a cheaper frontier model. It is a layer that decides, per task, whether you need the frontier model at all. ## The cost gap is now too big to ignore For a while the argument for always using the best model was simple: the open and cheap models were not good enough for real work, so the price difference did not matter. As of June 2026 that argument is dead. ![Abstract systems illustration for The cost gap is now too big to ignore](/images/blog/ai-model-routing-orchestration-layer/inline-1.webp) On June 16, Z.ai released **GLM-5.2**, a 753-billion-parameter open-weights model under an MIT license. On **SWE-bench Pro it scored 62.1, ahead of GPT-5.5 at 58.6** on a long-horizon autonomous coding benchmark. It does this at roughly **one-sixth the per-token cost** ([VentureBeat](https://venturebeat.com/technology/z-ais-open-weights-glm-5-2-beats-gpt-5-5-on-multiple-long-horizon-coding-benchmarks-for-1-6th-the-cost), [InfoWorld](https://www.infoworld.com/article/4186136/)). Sit with that. An open-weights model you can run yourself, or rent for a fraction of the price, beats a frontier proprietary model on a hard agentic coding benchmark. The quality argument for routing everything to the most expensive option no longer holds. When the cheap model is sometimes the better model, paying frontier prices for every token is not caution, it is waste. This is the structural shift. The performance curves of open and frontier models have converged enough that the interesting question is no longer "which single model is best." It is "which model is best for this specific task, at this moment, given what it costs." That is a routing question, and routing questions need a routing layer. ## Router versus orchestration: a distinction that matters People use "routing" and "orchestration" interchangeably, and they should not. The difference is the whole point of this post. **Routing** picks a model per request. Same task, one model, chosen well. It is a substitution problem: given this prompt and these constraints, which model gives me the best result per dollar? Do the substitution invisibly and the user never knows or cares which model answered. The cleanest current example is **[Factory Router](https://factory.ai/news/factory-router)**. It routes each Droid coding session across models and providers - Claude, DeepSeek, and others - choosing the optimal model per task from a pool of frontier and efficient options. Factory reports roughly **20-25% token savings** while holding frontier-level performance, and **99.9%+ request reliability** through failover: if a model struggles, the session escalates to a more capable one, and if a provider path goes down, the session keeps running through a healthy path. The droids are model-agnostic and the system is self-learning. That is routing done well - quietly swapping the cheaper model in wherever it is good enough, escalating only when it is not. **Orchestration** is a larger claim. It does not just pick a model, it decides how the work itself is decomposed: which model, how many agents, how they collaborate, what runs locally versus in the cloud, when to call a tool versus call a model. Routing is a subroutine inside orchestration. Perplexity's Aravind Srinivas has been the loudest voice here. On Harry Stebbings' 20VC he put it bluntly: **"The orchestration is the product. The model is a tool."** Perplexity's "Computer" agent does not just route to the cheapest acceptable model. It orchestrates which model handles which sub-task, how multiple agents coordinate, and whether work runs on-device or in the cloud - what Srinivas calls an "omni agent" rather than a router ([Fortune](https://fortune.com/2026/02/26/perplexity-ceo-aravind-srinivas-computer-openclaw-ai-agent/), [20VC](https://www.thetwentyminutevc.com/aravind-srinivas)). His preferred metric tells you everything about where his head is: not tokens, not latency, but **"token value per watt per user"** - useful output, normalized by energy and by person. That is an orchestration metric, not a routing one. The short way to hold the two apart: routing optimizes the choice within a fixed shape of work. Orchestration optimizes the shape of the work itself. Factory Router is best-in-class at the first. Perplexity's Computer is aiming at the second. ## The thesis: orchestration is the play next to the labs Here is the argument. The labs are going to keep winning the model race, and they are going to keep capturing enormous revenue doing it. You are not going to out-train Anthropic or OpenAI, and you should not try. But the labs have a structural blind spot, and it is the same one that produced the $500M bill: they make money when you use more of their most expensive model, so they are not the party with the strongest incentive to help you use less of it. That misaligned incentive is the opening. The orchestration layer wins by doing the thing the labs are not motivated to do: route the cheap, open, good-enough model for the **roughly 80% of tasks** that do not need frontier reasoning, and reserve the frontier model for the **hard 20%** where it actually changes the outcome. The value created is the delta between the all-frontier bill and the orchestrated bill, and as the cost gap widens - GLM-5.2 at one-sixth the price is just the latest data point - that delta gets bigger every quarter. This is a defensible place to build for a few reasons: - **It is model-agnostic by design.** A good orchestration layer gets *more* valuable as more models exist, because it has more options to route between. New model releases are tailwinds, not threats. Contrast that with building a thin wrapper on one model, where the next release can erase you. - **It compounds with data.** Every routed task is a labeled example of "this kind of work, sent to this model, produced this result at this cost." That feedback loop - which Factory describes as self-learning - is a moat that the labs do not have access to, because they only see their own model's traffic. - **The incentives are aligned with the customer.** You make money by saving the customer money. That is a far easier sale in a year when finance teams are looking at AI line items the size of the $500M bill. The labs sell horsepower. The orchestration layer sells judgment about when you need it. In a world where horsepower is abundant and cheap horsepower is suddenly competitive, judgment is the scarce thing. ## What a routing decision actually looks like The decision is less mysterious than it sounds. At its core it is a classifier in front of your model call. Here is the shape of it in pseudo-code, with the escalation pattern Factory uses baked in: ![Abstract systems illustration for What a routing decision actually looks like](/images/blog/ai-model-routing-orchestration-layer/inline-2.webp) ```python def route(task): # 1. Cheap, fast triage - estimate task difficulty difficulty = classify_difficulty(task) # a small/cheap model or heuristic # 2. Route the easy majority to the cheap, good-enough model if difficulty < THRESHOLD: result = call_model("glm-5.2", task) # ~1/6 the cost if quality_ok(result, task): return result # 3. Escalate only on failure - the hard minority return call_model("frontier-model", task) # reserved for the 20% # 4. High-difficulty tasks go straight to frontier return call_model("frontier-model", task) ``` Three ideas do most of the work here. First, **triage cheaply** - the classifier deciding difficulty should itself be small or heuristic, or you have just moved the cost, not removed it. Second, **default to cheap and escalate on failure** rather than defaulting to frontier and hoping. Third, **measure quality**, because the whole scheme depends on knowing when the cheap model was not good enough. Without a quality signal you are flying blind, and silent quality regressions are how routing projects lose trust. Orchestration extends this. Instead of one task and one model choice, you decompose a job into sub-tasks, route each one, run some in parallel, run some locally to save on tokens and latency, and have one agent check another's output before you accept it. The routing decision above is the atom. Orchestration is the molecule. ## Practical takeaways for cutting your spend You do not need to build Perplexity's Computer to benefit from this. In rough order of effort and impact: 1. **Set hard caps first.** Before anything clever, put per-user and per-project dollar ceilings in every provider dashboard. The $500M bill happened because nobody did this. Caps are not optimization, they are the seatbelt. (We went deep on this in [The $400 Overnight Bill](/blog/400-dollar-overnight-bill-agent-finops).) 2. **Measure your task mix.** You almost certainly do not know what fraction of your calls genuinely need a frontier model. Log task type and outcome for a week. Most teams find the frontier-required share is well under half. 3. **Adopt a router before you build one.** If you are running coding agents, a tool like [Factory Router](https://factory.ai/news/factory-router) gives you 20-25% savings with failover reliability and no engineering effort. Buy the obvious win before you build the bespoke one. 4. **Default to open-weights for the majority.** With GLM-5.2 beating GPT-5.5 on SWE-bench Pro at one-sixth the cost, the cheap path is no longer the inferior path for a large class of work. Make the cheap model the default and escalate, not the other way around. 5. **Build a quality gate.** Routing without a quality signal is gambling. Even a coarse check - does the code compile, does the test pass, does a cheap judge model approve - lets you escalate intelligently instead of blindly. 6. **Track value, not tokens.** Srinivas's "token value per watt per user" is a useful north star. The goal is not minimum tokens, it is maximum useful output per dollar. A router that saves tokens but tanks quality is not saving you anything. The labs built the engines. The interesting work now is in the layer that decides which engine to start, and when to leave it off. As the bills climb and the cheap models get good, that layer stops being a nice-to-have optimization and starts being the product. ## Frequently Asked Questions ### What is AI model routing and how does it save money? AI model routing is a layer that picks which model handles each request based on the task's difficulty and cost. Instead of sending every prompt to the most expensive frontier model, a router sends the easy majority to a cheaper or open-weights model and reserves the frontier model for the hard minority. Factory Router, for example, reports 20-25% token savings on coding sessions while holding frontier-level performance. The savings scale with the cost gap between models, which is widening as open-weights models like GLM-5.2 reach frontier-level quality at a fraction of the price. ### What is the difference between model routing and orchestration? Routing picks the best model for a single request - it optimizes the choice within a fixed shape of work. Orchestration is larger: it decides how the work itself is decomposed, how many agents run, how they collaborate, what runs locally versus in the cloud, and when to call a tool versus a model. Routing is a subroutine inside orchestration. Factory Router is a strong example of routing; Perplexity's "Computer" agent, which its CEO describes as an "omni agent," is aiming at full orchestration. ### How do I cut my Claude or frontier-model API bill? Start with hard per-user and per-project spend caps in your provider dashboard - the reported $500M one-month Claude bill happened because none were set. Then measure what fraction of your calls actually need a frontier model; most teams overestimate it. Adopt a router to automatically send easy tasks to cheaper models, default to open-weights models for the majority of work, and build a quality gate so you escalate to the frontier model only when the cheap one falls short. ### Is an open-weights model good enough to replace a frontier model? For a large and growing class of tasks, yes. As of June 2026, Z.ai's open-weights GLM-5.2 scored 62.1 on SWE-bench Pro, ahead of GPT-5.5 at 58.6, at roughly one-sixth the per-token cost. The right approach is not all-or-nothing: route the easy majority of tasks to the cheaper model, measure quality, and escalate to a frontier model only for the hard minority where it changes the outcome. ### Why is the orchestration layer a good place to build a company? The labs profit when you use more of their most expensive model, so they have little incentive to help you use less of it. That misalignment is the opening. An orchestration layer is model-agnostic, so it gets more valuable as more models are released rather than being threatened by them. It compounds with data - every routed task teaches it which model fits which work - and its incentives are aligned with the customer because it makes money by saving the customer money. In a year of escalating AI bills, that is an easy sale.

Build Your First Agent with Vercel eve: A Step-by-Step Tutorial

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## What you are building This is a hands-on, beginner-friendly tutorial. By the end you will have a working AI agent built with [Vercel eve](https://vercel.com/docs/eve) that can answer a question, call a tool you wrote, and run both locally and on [Vercel Functions](https://vercel.com/docs/functions). If you want the conceptual overview first - what eve is, why "Next.js for agents" is more than a slogan, and where it sits in Vercel's stack - read our companion post on [Vercel eve, the framework for building AI agents](/blog/vercel-eve-framework-for-building-ai-agents). This post is the walkthrough: less theory, more typing. One thing to set up front. eve launched as a public preview and is [currently in beta](https://vercel.com/docs/eve), subject to Vercel's beta terms. The framework, APIs, documentation, and behavior may change before general availability. Everything below uses the verified API as documented at launch, but pin your versions and expect some churn if you build on this today. ## Prerequisites You need Node.js installed and a package manager (the scaffold works with npm, pnpm, or yarn). You do not need to wire up model provider API keys to get started: eve resolves model strings through [AI Gateway](https://vercel.com/docs/ai-gateway), so on Vercel you authenticate with OIDC and skip key management entirely. For local development you will follow the generated project's README for any environment setup it asks for. ![Abstract systems illustration for Prerequisites](/images/blog/build-first-agent-vercel-eve-tutorial/inline-1.webp) ## Step 1: Scaffold the project The fastest path is the eve CLI. Run the published package with `npx` to scaffold a new agent project, install dependencies, initialize Git, and start the development server in one command: ```bash npx eve@latest init my-agent ``` If you would rather add eve to an app you already have, install it directly and pass a path to `init`: ```bash npm install eve@latest ``` That is the whole setup. No build config to hand-write, no server file to author. The scaffold gives you a working project you can immediately run. ## Step 2: Understand the agent/ directory eve is filesystem-first. You define an agent with files under an `agent/` directory, eve discovers them, and compiles the tree into an app. If you have built a Next.js app, the mental model transfers directly: the file tree is the configuration. The conventional layout, per the [eve docs](https://vercel.com/docs/eve), looks like this: ``` my-agent/ └── agent/ ├── agent.ts # Model and runtime config ├── instructions.md # System prompt ├── tools/ # Typed functions, one tool per file ├── skills/ # On-demand procedures loaded when relevant ├── channels/ # Message integrations └── schedules/ # Cron jobs ``` You do not need most of those folders for a first agent. The two that matter to start are `instructions.md` and `agent.ts`, plus a single file in `tools/`. The convention is the wiring: drop a file in `tools/` and it becomes a tool, drop a file in `schedules/` and it becomes a cron job. There is no central registry to maintain. ## Step 3: Define the agent A minimal agent is genuinely two files. First, `agent/instructions.md` is the system prompt, written in plain Markdown: ```md You are a concise assistant. Use tools when they are available. ``` Then `agent/agent.ts` is the runtime config. This is where you pick the model: ```ts import { defineAgent } from 'eve'; export default defineAgent({ model: 'openai/gpt-5.4-mini', }); ``` The `model` string is resolved through AI Gateway, so you can swap providers by changing the string - `anthropic/claude-sonnet-4.6`, for example - without touching credentials or rewriting calls. That is the entire agent definition. No loop, no message-history bookkeeping, no server handler. eve supplies the runtime. ## Step 4: Add a tool with defineTool An agent that can only talk is a chatbot. The interesting part is giving the model typed actions it can call. In eve, each file in `agent/tools/` is exactly one tool, and the runtime tool name comes from the filename - so the model sees `get_weather` for a file named `get_weather.ts`. Create `agent/tools/get_weather.ts`: ```ts import { defineTool } from 'eve/tools'; import { z } from 'zod'; // The runtime tool name comes from the filename, so the model sees `get_weather`. export default defineTool({ description: 'Get the current weather for a city.', inputSchema: z.object({ city: z.string(), }), async execute(input) { return { city: input.city, condition: 'Sunny', temperatureF: 72 }; }, }); ``` Three pieces are doing the work here. The `description` is what the model reads to decide when to call the tool, so write it like a function doc, not a label. The `inputSchema` is a [Zod](https://zod.dev) schema that both validates the model's arguments and gives you typed input inside `execute`. And `execute` is your code - here it returns mock data, but in a real tool this is where you would hit a weather API. Because the schema is enforced before `execute` runs, you never have to defensively parse a malformed argument the model hallucinated. That is the full loop: the model reads the description, decides to call `get_weather`, eve validates the arguments against the schema, runs your `execute`, and feeds the result back into the conversation. ## Step 5: Run it locally Start the development server. The `init` command already started it, but you can run it again from the scaffold with the standard script: ![Abstract systems illustration for Step 5: Run it locally](/images/blog/build-first-agent-vercel-eve-tutorial/inline-2.webp) ```bash pnpm dev ``` Follow the generated README for the exact dev command if yours differs. The local server exposes the same session API you will use in production, which means there is no separate "test harness" to learn - you exercise the real interface from the start. ## Step 6: Call the agent through the session API eve agents run as durable sessions. You start a session by posting a message, and the agent streams its output back. From a second terminal, start a session against the local server: ```bash curl -X POST http://127.0.0.1:3000/eve/v1/session \ -H 'content-type: application/json' \ -d '{"message":"What is the weather in Brooklyn?"}' ``` The response returns a `continuationToken` in the body and an `x-eve-session-id` header. That session ID is the handle to everything the agent does next. To watch the agent think and act in real time, attach to the session stream and you will receive NDJSON lifecycle events: ```bash curl http://127.0.0.1:3000/eve/v1/session//stream ``` Swap `` for the value from the `x-eve-session-id` header. As the agent runs, the stream emits newline-delimited JSON events for each step of the turn, including the moment it decides to call your `get_weather` tool and the result coming back. For a "What is the weather in Brooklyn?" prompt, you will see the model pick the tool, the tool execute with `{ city: "Brooklyn" }`, and the agent fold the `Sunny, 72F` result into its reply. The session is durable, and that is the part worth pausing on. The single most annoying class of agent bug is the one where a deploy or a timeout kills a half-finished run with no clean way to resume. eve sessions checkpoint each step and resume after cold starts, deploys, or long pauses, backed by [Vercel Workflow](https://vercel.com/docs/workflows). The `continuationToken` is how you pick a session back up rather than starting over. ## Step 7: Deploy to Vercel Functions Because an eve project compiles into a standard Vercel app, deploying is the normal Vercel flow rather than anything agent-specific. Push the project to a Git repository connected to Vercel, or deploy from the CLI, and eve runs on [Vercel Functions](https://vercel.com/docs/functions). The same session endpoints you hit locally - `POST /eve/v1/session` and `GET /eve/v1/session//stream` - are now served from your deployment URL. On Vercel you also inherit the production wiring for free: model routing and provider fallbacks through [AI Gateway](https://vercel.com/docs/ai-gateway), durable state through [Vercel Workflow](https://vercel.com/docs/workflows), isolated code execution through [Vercel Sandbox](https://vercel.com/docs/sandbox), and a view of every agent run, its token usage, and timing through [Vercel Observability](https://vercel.com/docs/observability) with no extra setup. eve deploys natively to Vercel today, with other platforms described as coming soon, so if you need to self-host elsewhere, that is the constraint to plan around. ## Where to go next You now have the full loop: scaffold, define an agent, add a typed tool, run it, call it over the session API, and ship it. The natural next steps are the folders you skipped. Add a `skills/` file when a procedure is too large to live in the system prompt and should load only when relevant. Add a `channels/` integration to let the agent receive messages from somewhere other than a raw HTTP call. Add a `schedules/` cron job to run the agent on a timer. Each follows the same convention you already learned - a file in the right folder becomes the feature. For the bigger picture of why eve is built this way, see our overview of [Vercel eve as an agent framework](/blog/vercel-eve-framework-for-building-ai-agents) and how it fits into [Vercel's agentic infrastructure stack](/blog/vercel-agentic-infrastructure-stack). If you are still deciding whether an opinionated framework is the right call versus assembling your own stack, our comparison of the [Vercel AI SDK against other agent stacks](/blog/langchain-vs-vercel-ai-sdk) is the place to weigh that tradeoff. The honest summary: eve makes a first agent a 20-minute exercise instead of a week of plumbing, and the same code you write in that 20 minutes is what runs in production. Just remember it is a beta, so pin your versions and watch the [changelog](https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework) for API shifts. ## Sources - [eve documentation - Vercel docs](https://vercel.com/docs/eve) - [vercel/eve on GitHub](https://github.com/vercel/eve) - [Introducing eve - Vercel blog](https://vercel.com/blog/introducing-eve) - [Introducing eve, an open-source agent framework - Vercel changelog](https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework) - [Vercel Functions documentation](https://vercel.com/docs/functions) - [AI Gateway documentation](https://vercel.com/docs/ai-gateway)

Claude Code Permissions: A Practical settings.json Guide for Allow, Deny, and Ask Rules

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Claude Code settings reference | [code.claude.com/docs/en/settings](https://code.claude.com/docs/en/settings) | | Permissions and rule syntax | [code.claude.com/docs/en/permissions](https://code.claude.com/docs/en/permissions) | | Permission modes | [code.claude.com/docs/en/permission-modes](https://code.claude.com/docs/en/permission-modes) | | CLI reference | [code.claude.com/docs/en/cli-reference](https://code.claude.com/docs/en/cli-reference) | | Hooks reference | [code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks) | If you use Claude Code for more than a few minutes a day, you have felt the friction: the agent stops to ask before every `npm test`, every file edit, every `git status`. The instinct is to reach for `--dangerously-skip-permissions` and never look back. That is a mistake. The permission system is the one layer standing between an autonomous agent and your shell, your secrets, and your production credentials. The right move is not to disable it - it is to configure it so the safe stuff runs silently and the dangerous stuff still stops. This is a practical guide to that configuration. We will cover where settings live and how the scopes combine, the exact syntax for `allow` / `deny` / `ask` rules, how tool specifiers work for Bash, file edits, and web access, and the headless flags you need for CI. Every claim here is checked against the current Claude Code docs - links are in the table above and in the Sources section. **Last updated:** June 17, 2026 ## The Settings Scopes: Where Permissions Actually Come From Claude Code reads settings from several `settings.json` files. Crucially, permission rules **merge** across scopes rather than fully overriding one another - so a `deny` rule defined anywhere stays in force, and a more restrictive scope cannot be loosened by a less authoritative one. The scopes, from highest authority to lowest: 1. **Managed policy** - a system-level file an organization deploys (on macOS, `/Library/Application Support/ClaudeCode/`; on Linux/WSL, `/etc/claude-code/`). Developers cannot override it. This is how a security team enforces a baseline. 2. **Command-line arguments** - flags like `--allowedTools` that apply to a single session. 3. **Project local settings** - `.claude/settings.local.json`. Personal, not checked into git (Claude Code adds it to `.gitignore` automatically). Machine-specific tweaks go here. 4. **Project shared settings** - `.claude/settings.json`. Checked into the repo and shared with your team. This is the file that should encode "everyone on this project can run the test suite without asking." 5. **User settings** - `~/.claude/settings.json`. Your global defaults across every project. The key mental shift: this is not a simple "higher file wins" override. The `allow`, `deny`, and `ask` lists from every applicable scope are combined, and within that combined set a `deny` rule can never be cancelled by an `allow` rule (more on that next). So put team-wide policy in the project's `.claude/settings.json` so it travels with the repo, keep personal preferences in `~/.claude/settings.json`, and use `.claude/settings.local.json` for one-off machine-specific rules you do not want to commit. A minimal project `settings.json`: ```json { "permissions": { "allow": [ "Bash(npm run test *)", "Bash(npm run lint)", "Read(~/.config/**)" ], "ask": [ "Bash(git push *)" ], "deny": [ "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Bash(curl *)" ] } } ``` ## allow, deny, ask: Three Lists, One Rule of Precedence The `permissions` object holds three arrays that decide what happens when the agent wants to use a tool: ![Abstract systems illustration for allow, deny, ask: Three Lists, One Rule of Precedence](/images/blog/claude-code-permissions-settings-guide/inline-1.webp) - **`allow`** - the tool call runs without prompting you. - **`ask`** - the tool call always prompts for confirmation, even if a broader `allow` rule would have matched. - **`deny`** - the tool call is blocked outright and never runs. The precedence is the part people get wrong: **rules are evaluated `deny` then `ask` then `allow`, first match wins, and a `deny` rule cannot have allowlist exceptions.** So a `deny` for `Read(./.env)` blocks the file even if you also have a broad `allow` like `Read(./**)` - and even if that `allow` lives in a more authoritative scope. This is exactly the behavior you want: your allowlist can be generous because your denylist is the real safety net. ### Permission modes (`defaultMode`) Tool calls that match none of the three lists fall back to the session's permission mode. Set the default under `permissions` with `defaultMode`; the documented values are: - `default` - prompt on first use of each tool (standard interactive behavior). - `acceptEdits` - auto-approve file edits and common filesystem commands in the working directory, but still gate other tools. - `plan` - Claude reads and explores but does not edit source files. - `dontAsk` - auto-deny tools unless explicitly pre-approved via `allow` rules. - `bypassPermissions` - skip all permission prompts (isolated environments only). - `auto` - auto-approve with background safety checks (research preview; gated by account tier). ```json { "permissions": { "defaultMode": "acceptEdits", "deny": ["Read(./.env)", "Read(./.env.*)"] } } ``` One gotcha worth knowing: in recent versions, `defaultMode: "auto"` set inside a project's `.claude/settings.json` or `.claude/settings.local.json` is silently ignored, so a checked-out repo cannot grant itself auto mode. If you want auto mode to persist, put it in your user `~/.claude/settings.json`. ## Tool Specifier Syntax: The Part Worth Memorizing Each rule is a tool name, optionally followed by a specifier in parentheses that narrows which calls it matches. A bare tool name (`"WebSearch"`) matches every use of that tool. The specifier syntax differs by tool, and the differences matter. ### Bash Bash rules match against the command string. **The space before `*` is significant:** ```json "Bash(npm run build)" // exact command match "Bash(npm run test *)" // prefix match: "npm run test" plus any arguments "Bash(npm *)" // any npm command "Bash(ls *)" // matches "ls -la" but NOT "lsof" "Bash(ls*)" // matches both "ls -la" and "lsof" "Bash(*)" // every command (same as bare "Bash") ``` Compound commands are understood: Claude Code splits on `&&`, `||`, `;`, `|`, and newlines, and each subcommand must match independently, so an allowlisted command chained with a disallowed one will still stop. Common process wrappers (`timeout`, `time`, `nice`, `nohup`) are stripped before matching. The important caveat: Bash matching is still best-effort, not a hardened shell sandbox. Do not rely on a Bash `allow` rule as a security boundary against a hostile prompt; rely on `deny` plus a restricted environment for that. ### Read and Edit (file paths) File-tool rules take a path argument that follows gitignore-style glob patterns. A leading `//` means an absolute path, `~/` is your home directory, a leading `/` is project-relative, and a bare filename matches at any depth: ```json "Edit(/src/**/*.ts)" // project-relative; ** crosses directories "Read(~/.zshrc)" // a specific home-directory file "Read(//tmp/scratch)" // absolute path "Edit(.env)" // bare filename matches at any depth ``` This is the mechanism for the single most valuable permission rule you can write: **deny reads of your secrets.** ```json "deny": [ "Read(./.env)", "Read(./.env.*)", "Read(.env)", "Read(./secrets/**)", "Read(/**/*.pem)" ] ``` A `deny` on `Read` does more than stop the file from being opened - it keeps credentials out of the model's context entirely, which is the actual goal. The denylist above is a reasonable baseline for any repo. ### WebFetch and WebSearch Web tools support a `domain:` specifier so you can scope network access to trusted hosts. Matching is case-insensitive: ```json "allow": [ "WebFetch(domain:docs.anthropic.com)", "WebFetch(domain:*.github.com)" ], "ask": [ "WebSearch" ] ``` Note that `WebFetch(domain:*.github.com)` matches subdomains but not bare `github.com`, and `WebFetch(domain:example.*)` matches TLD variations like `example.org`. ### MCP server tools Tools provided by MCP servers are addressed as `mcp____`. You can allow an entire server or a single tool: ```json "allow": [ "mcp__github", // every tool from the github MCP server "mcp__sentry__list_issues" // just one tool from the sentry server ] ``` ### Subagents Spawning subagents is gated by the `Agent` tool, which takes the agent name as a specifier - and, for `deny`/`ask` rules, can match on parameter values: ```json "allow": ["Agent(Explore)"], "ask": ["Agent(isolation:worktree)"], "deny": ["Agent(model:opus)"] ``` ## Editing Permissions Without Touching JSON You do not have to hand-edit files. Inside a session, run `/permissions` (alias `/allowed-tools`) to open an interactive view of every active allow/deny/ask rule, add or remove rules, manage working directories, and review recent denials. When Claude Code prompts you to approve a tool call, choosing the "always allow" option writes the corresponding rule into your settings for you - usually `.claude/settings.local.json`. That is the fastest way to build an allowlist: work normally for an afternoon, approve the repetitive-but-safe calls with "always," and let the file accumulate. (There is no `claude config` CLI command; `/config` opens the settings UI interactively, and `--settings` overrides for one session.) The `additionalDirectories` setting (under `permissions`) grants the agent access to directories outside the current working directory without re-approving each one - handy for monorepos or sibling asset folders: ```json { "permissions": { "additionalDirectories": ["../shared-types", "../design-tokens"] } } ``` ## Permissions in Headless and CI Runs When you run Claude Code non-interactively - in CI, a cron job, or a script - there is no human to answer prompts, so permission handling has to be settled up front. The relevant CLI flags: - **`--allowedTools`** - a list of tool rules to allow for this run, same syntax as the `allow` array. - **`--disallowedTools`** - the inverse, for this run. - **`--permission-mode`** - sets the mode for the session (`default`, `acceptEdits`, `plan`, `dontAsk`, `bypassPermissions`, or `auto`). - **`--settings`** - inject a settings object or file for this run. - **`--dangerously-skip-permissions`** - bypass all permission checks. This is the YOLO flag (equivalent to `--permission-mode bypassPermissions`). A headless run that is allowed to edit and test but nothing else: ```bash claude -p "fix the failing unit tests in src/parser" \ --allowedTools "Edit(/src/**)" "Bash(npm run test *)" "Read(/src/**)" \ --permission-mode acceptEdits ``` About `--dangerously-skip-permissions`: it has its place - a fully sandboxed throwaway container with no network and no real credentials, where the blast radius is genuinely zero. It does not belong on your laptop or any machine with SSH keys, cloud credentials, or access to production. The name is not a joke. If you reach for it to escape prompt fatigue, that is a signal to write a good `allow` list instead, which gets you the same quiet experience without handing over the keys. For enforcing policy too dynamic for static rules, see our guide on [Claude Code hooks](/blog/claude-code-hooks-explained). ## Other settings.json Keys Worth Knowing `permissions` is one object in a larger settings file. A few neighbors that interact with it: ![Abstract systems illustration for Other settings.json Keys Worth Knowing](/images/blog/claude-code-permissions-settings-guide/inline-2.webp) - **`hooks`** - shell commands that fire on lifecycle events (`PreToolUse`, `PostToolUse`, and others). A `PreToolUse` hook can block a tool call programmatically, which lets you enforce rules too dynamic for static glob matching (for example, "deny any Bash command that contains a production hostname"). Permissions and hooks are complementary, not redundant. - **`env`** - environment variables injected into every session and tool call. - **`enableAllProjectMcpServers`** - auto-approves the MCP servers defined in the project's `.mcp.json` instead of prompting for each. - **`disableBypassPermissionsMode`** - set to `"disable"` to forbid bypass mode entirely, useful in a managed policy. ## A Recommended Baseline A sane default to drop into a project's `.claude/settings.json`, then tighten from experience: ```json { "permissions": { "allow": [ "Bash(npm run test *)", "Bash(npm run lint)", "Bash(npm run build)", "Bash(git status)", "Bash(git diff *)", "Bash(git log *)", "Read(/**)", "Edit(/src/**)", "Edit(/tests/**)" ], "ask": [ "Bash(git push *)", "Bash(git commit *)" ], "deny": [ "Read(./.env)", "Read(./.env.*)", "Read(.env)", "Read(./secrets/**)", "Read(/**/*.pem)", "Bash(curl *)", "Bash(rm -rf *)" ] } } ``` This lets the agent test, lint, build, read the codebase, and edit source and tests without interruption; pauses it before it pushes or commits; and hard-blocks it from reading secrets or running a handful of dangerous commands. Commit it, and your whole team inherits the policy. ## The Mental Model Three lists, one precedence rule (`deny` over `ask` over `allow`, with deny never overridable), a set of scopes whose rules merge rather than simply override, and a clear separation between static rules (`permissions`) and dynamic enforcement (`hooks`). Get those four things straight and you can run Claude Code with far less friction and far more safety than either extreme - clicking "approve" all day or skipping permissions entirely. For the next layer up, see [how to write a CLAUDE.md](/blog/how-to-write-claudemd-the-complete-guide) so the agent knows your conventions, and [Claude Code tips and tricks](/blog/claude-code-tips-tricks) for the broader workflow. ## FAQ ### What is the precedence between allow, deny, and ask in Claude Code? Rules are evaluated `deny`, then `ask`, then `allow`, and the first match wins. A `deny` rule blocks a tool call even if a broader `allow` rule would have matched it, and a deny cannot have allowlist exceptions - which is what makes a generous allowlist safe, because your denylist is the real boundary. Tool calls matching none of the lists fall back to the configured `defaultMode`. ### Where does Claude Code store permission settings? In `settings.json` files at several scopes: managed policy (deployed by an organization, highest authority), command-line flags, project-local `.claude/settings.local.json` (gitignored, personal), project-shared `.claude/settings.json` (committed, team-wide), and user `~/.claude/settings.json` (your global defaults). Rules from all applicable scopes merge, and a deny anywhere stays in force. ### How do I let Claude Code run my tests without asking every time? Add a prefix rule to the `allow` array, for example `"Bash(npm run test *)"`, in your project's `.claude/settings.json`. The trailing ` *` is a prefix match, so it covers `npm run test`, `npm run test:unit`, `npm run test:e2e`, and so on. The space before `*` matters. Or approve a test command once with the "always allow" option and Claude Code writes the rule for you. ### Is it safe to use --dangerously-skip-permissions? Only in a fully sandboxed environment with no network access and no real credentials, where the agent cannot do lasting damage. On a machine with SSH keys, cloud credentials, or production access, it removes the one layer protecting those resources. For day-to-day prompt fatigue, write a good `allow` list instead - you get the same quiet experience without disabling the safeguards. ### How do I stop Claude Code from reading my .env file? Add `Read` deny rules such as `"Read(./.env)"`, `"Read(./.env.*)"`, and a bare `"Read(.env)"` (which matches at any depth) in the `deny` array. Because deny wins over allow and cannot be overridden, these block the file even if you have a broad `Read(/**)` allow rule, and they keep secrets out of the model's context entirely rather than just declining to open the file. ## Sources - Claude Code settings reference: [https://code.claude.com/docs/en/settings](https://code.claude.com/docs/en/settings) (verified June 17, 2026) - Claude Code permissions and rule syntax: [https://code.claude.com/docs/en/permissions](https://code.claude.com/docs/en/permissions) (verified June 17, 2026) - Claude Code permission modes: [https://code.claude.com/docs/en/permission-modes](https://code.claude.com/docs/en/permission-modes) (verified June 17, 2026) - Claude Code CLI reference: [https://code.claude.com/docs/en/cli-reference](https://code.claude.com/docs/en/cli-reference) (verified June 17, 2026) - Claude Code hooks reference: [https://code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks) (verified June 17, 2026)

The $500M Claude Bill: A Spend-Guardrails Playbook for AI-Native Teams

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 17, 2026 In late May 2026 an AI consultant disclosed that one of their enterprise clients had run up a roughly $500 million Claude bill in a single month after deploying the tool across their workforce with no spending caps, no rate limits, and no usage alerts (reported May 2026, [Tom's Hardware](https://www.tomshardware.com/tech-industry/artificial-intelligence/mystery-company-accidentally-blew-usd500-million-on-claude-in-a-single-month-failed-to-put-usage-limit-on-licenses-for-employees)). The company has never been named. The number is almost certainly an outlier. But it landed because it rhymed with a pattern everyone in the industry was already watching. This is not a story about Claude being expensive. By every available signal Claude Code is the most useful coding tool most teams have ever shipped - it is the fastest-growing product in Anthropic's history, and the company crossed a roughly $30 billion annualized revenue run-rate in April 2026, up from $9 billion at the end of 2025 (reported May 2026, [VentureBeat](https://venturebeat.com/technology/anthropic-says-it-hit-a-30-billion-revenue-run-rate-after-crazy-80x-growth)). People are not spending this money by accident in the aggregate. They are spending it because it works. The story is about governance. Token billing scales with usage, agentic workflows can consume orders of magnitude more tokens than a chat message, and a flat per-seat license hides all of that until the invoice arrives. The teams getting burned are not the ones using too much AI. They are the ones using a lot of AI with the financial controls of a 2015 SaaS rollout. This post is the playbook for closing that gap without throttling the thing that is actually making your engineers faster. ## The Pattern, Not Just the Headline The $500M figure is the viral one, but the more instructive cases are the named ones, because they show disciplined companies hitting the same wall. Uber rolled Claude Code out to its engineering org in December 2025. By March 2026, 84% of engineers were classified as agentic coding users, up from 32% in February. By April, the CTO said the company had already exhausted its entire 2026 AI budget, with per-engineer monthly API costs running between roughly $500 and $2,000. Uber's response was not to pull the tool - it was to cap it, giving each employee a $1,500 monthly token allowance per AI coding tool (reported May 2026, [Fortune](https://fortune.com/2026/05/26/uber-coo-ai-spending-tokens-claude-code/), [Inc.](https://www.inc.com/lucia-auerbach/uber-blew-through-2026-ai-budget-in-four-months-now-it-is-capping-employee-use/91355199)). Microsoft hit the same dynamic from the other direction. After rolling Claude Code out to roughly 5,000 engineers in its Experiences and Devices division in December 2025, adoption climbed to 84-95% of the cohort by April. When billing moved from flat seats to usage-based, per-engineer costs of $500-$2,000/month became visible, and the division moved to cancel most internal Claude Code licenses effective June 30, 2026, redirecting engineers toward GitHub Copilot CLI (reported June 2026, [The Next Web](https://thenextweb.com/news/microsoft-claude-code-retreat-ai-cost)). The common thread is not the model. It is that **flat seat licensing made token consumption invisible during the pilot, and nobody had instrumented the spend before it compounded.** Three different organizations, three different sizes, same root cause. That is what makes it a playbook problem rather than a one-off. For the underlying mechanics of why parallel agents multiply this so fast - every session drawing from one quota - see our companion piece, [What a Fleet of Claude Agents Actually Costs](/blog/what-parallel-claude-agents-actually-cost). ## The Playbook The goal is a system where a runaway month is structurally impossible, not merely discouraged. Work the layers from the outside in: hard caps first (they cannot be ignored), then alerts, then the optimizations that reduce the spend the caps are guarding. ![Abstract systems illustration for The Playbook](/images/blog/claude-spend-guardrails-playbook-ai-native-teams/inline-1.webp) ### 1. Per-Seat and Usage Caps Come First A budget alert tells you the money is already gone. A cap stops it. Start with the hard limit and layer the soft signals on top, never the reverse - the $500M case is precisely what happens when there is no hard limit underneath. - **Set an explicit per-user monthly token or dollar ceiling.** Uber's $1,500-per-tool allowance is a reasonable reference point for heavy agentic coders; calibrate to your own median active-day cost rather than copying the number. If you do not yet know your median, that is itself the first finding. - **Cap at the org boundary too.** Per-seat limits do not protect you from a misconfigured agent loop on one account; a workspace-level monthly ceiling does. - **Prefer usage-based visibility over flat seats during any pilot.** The Microsoft retreat happened because flat licensing hid the real number until the model changed. If you start usage-based, the cost is legible from week one. ### 2. Budget Alerts at Tiered Thresholds Caps are the floor; alerts are how you react before you hit them. Wire alerts at 50%, 80%, and 95% of each budget window, routed to a channel a human actually watches - not an inbox folder. - Alert on **rate of spend**, not just cumulative total. A 3x day-over-day jump on a Tuesday is the early signal of a runaway agent; waiting for the 80% cumulative alert wastes the warning. - Give every team its own budget envelope so one team's spike is visible against its own baseline instead of being averaged out across the org. - Make at least one alert tier page someone. The difference between a $50K surprise and a $500M one is how fast a human sees the curve bend. ### 3. AI Gateway Spend Caps and Key Scoping If your team calls models through an AI gateway or proxy (LiteLLM, Cloudflare AI Gateway, OpenRouter, Portkey, or an internal one), that layer is where you enforce limits centrally instead of trusting every app to behave. - **Set hard spend caps per virtual key.** Scope keys per team, per service, and per environment so a leaked or looping key has a bounded blast radius. A staging key that can spend production money is a $500M bill waiting for a bad deploy. - **Rate-limit at the gateway**, not just the budget. Requests-per-minute and tokens-per-minute ceilings catch infinite loops the budget cap would only catch after the damage. - Route all model traffic through the gateway so there is one chokepoint to instrument. Shadow direct-to-provider calls are exactly the spend you cannot see. ### 4. Route Cheap and Open Models for Routine Work Most of what an agentic workflow does does not need a frontier model. Classification, formatting, simple extraction, lint-style fixes, and first-draft boilerplate run fine on cheaper tiers or open-weights models at a fraction of the per-token cost - and the savings compound across millions of routine calls. - Reserve the most capable model for the work that actually needs reasoning depth, and route the long tail of routine calls to a cheaper tier. - Open-weights models have closed enough of the quality gap to be a serious cost lever for routine work. We ran the full math on this in [GLM-5.2 Cost Math: When Open-Weights Coding Models Actually Save You Money](/blog/glm-5-2-cost-math-open-weights-coding-models) - the headline is roughly one-sixth the per-token cost for tasks that clear the quality bar. - The decision of when to use which model is becoming its own discipline. Our deep dive on the [AI model routing and orchestration layer](/blog/ai-model-routing-orchestration-layer) covers how to build that routing logic rather than hard-coding one model everywhere. The point is not to use the cheapest model for everything - that just trades a money problem for a quality problem. It is to stop paying frontier prices for work a cheaper model does identically. ### 5. Prompt Caching for Repeated Context Agentic workflows resend the same large context - system prompts, tool definitions, codebase chunks, retrieved documents - on call after call. Prompt caching lets the provider reuse that prefix at a steep discount instead of charging full input rates every time, which is one of the highest-leverage optimizations available for agent-heavy workloads where the same context is read on every step. - Structure prompts so the **stable, reusable prefix comes first** and the variable part comes last; only a stable prefix can be cached. - This matters most exactly where bills explode: long-context agent loops that re-read the same files and instructions every turn. - Treat caching as a default for any repeated-context workload, not a micro-optimization you get to later. (For provider-specific cache mechanics and pricing, check current docs - the discount structure changes.) ### 6. Observability: You Cannot Cap What You Cannot See Every control above depends on knowing where the money goes. Spend that is not attributable is spend you cannot govern. - Tag every model call with **team, user, service, and environment** so the gateway dashboard answers "who spent this" without an investigation. - Track cost per task or per workflow run, not just cost per token. A workflow that quietly grew from 3 model calls to 30 is invisible in the token total but obvious in cost-per-run. - Review the spend curve on a fixed cadence. The $500M and Uber cases share a tell: nobody looked at the curve until it had already bent. A standing weekly five-minute review of the top spenders catches the bend while it is still cheap. ### 7. Approval Workflows for the Expensive Tail Most calls should flow freely - friction on routine work just trains people to route around your controls. Reserve gates for the genuinely expensive operations. - Require approval for **new high-volume integrations and batch jobs** before they ship. The runaway-loop scenarios are almost always automated, not interactive. - Default new keys and new services to **conservative caps** that a human raises on request, rather than generous caps a human has to remember to lower. - Put a budget-impact line in the review checklist for any change that adds an automated model call in a loop. One sentence - "what is the worst-case spend if this runs unbounded" - would have caught all three cases above. ## The Order of Operations Is the Whole Point Read the playbook back and the sequence is the lesson. Hard caps and key scoping make a $500M month structurally impossible. Tiered alerts and observability make a $50K surprise visible while it is still small. Routing, caching, and approval gates shrink the bill the caps are protecting, so you can set those caps generously enough that engineers never feel them. ![Abstract systems illustration for The Order of Operations Is the Whole Point](/images/blog/claude-spend-guardrails-playbook-ai-native-teams/inline-2.webp) That last part matters. The failure mode is not just overspending - it is overcorrecting into a regime so locked-down that people stop using the tool that was making them faster. Microsoft's retreat is the cautionary version of that. The goal is the Uber version instead: keep the tool, cap the blast radius, and let people work. None of this is exotic. It is the same financial discipline every other major cost center in your company already has, applied to a line item that grew from a rounding error to a top-five expense in about two quarters. The companies that get burned are not reckless. They just instrumented the spend a quarter too late. The fix is to do it now, while your bill is still small enough that the playbook is cheap to install. ## Sources - [Mystery company accidentally blew $500 million on Claude AI in a single month - Tom's Hardware](https://www.tomshardware.com/tech-industry/artificial-intelligence/mystery-company-accidentally-blew-usd500-million-on-claude-in-a-single-month-failed-to-put-usage-limit-on-licenses-for-employees) - [Company accidentally spent $500 million on Claude AI in one month - Tech Startups](https://techstartups.com/2026/05/28/company-accidentally-spent-500-million-on-claude-ai-in-one-month-after-forgetting-usage-limits/) - [Uber burned through its entire 2026 AI budget in four months - Fortune](https://fortune.com/2026/05/26/uber-coo-ai-spending-tokens-claude-code/) - [Uber Blew Through Its 2026 AI Budget in 4 Months - Now It's Capping Employee Use - Inc.](https://www.inc.com/lucia-auerbach/uber-blew-through-2026-ai-budget-in-four-months-now-it-is-capping-employee-use/91355199) - [Microsoft's quiet Claude Code retreat and the real cost of enterprise AI - The Next Web](https://thenextweb.com/news/microsoft-claude-code-retreat-ai-cost) - [Anthropic says it hit a $30 billion revenue run rate after 'crazy' 80x growth - VentureBeat](https://venturebeat.com/technology/anthropic-says-it-hit-a-30-billion-revenue-run-rate-after-crazy-80x-growth)

Cohere's North Mini Code: A 30B Open-Weight Coding Model That Runs on One H100

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 Cohere has mostly been known for retrieval, embeddings, and enterprise RAG. On June 9, 2026, it stepped onto coding-model turf for the first time. **North Mini Code** is the company's first agentic coding model, released with open weights under Apache 2.0 and sized so it fits on a single H100. For teams that want a capable coding model they can actually self-host, that combination is the headline. This post sticks to what Cohere has published and what independent coverage has confirmed. Where a number is a vendor claim rather than an independently reproduced benchmark, it is flagged as such. ## What North Mini Code Is North Mini Code is a **mixture-of-experts (MoE)** model with **30B total parameters and 3B active per token**. The MoE design is the whole point: you get the knowledge capacity of a 30B model while only paying the inference cost of routing through roughly 3B parameters on each forward pass. That is what keeps the deployment footprint small. The specs Cohere lists: - **30B total / 3B active** parameters (MoE) - **256K token context window** - **64K token maximum generation length** - **Apache 2.0 license** (open weights, commercial use permitted) - Minimum hardware: **1x H100 at FP8** or **1x H100 at FP4** It is positioned as the first model in what Cohere calls its next generation, and it is aimed squarely at agentic software engineering - code generation, sub-agent orchestration, architecture mapping, code review, and terminal work. That places it in the same practical category as [local Qwen workflows](/blog/local-qwen-different-tool-not-worse-opus), [GLM-5.2 local deployment](/blog/glm-5-2-local-deployment-unsloth-quantization), and the broader [best local coding LLMs](/blog/best-local-coding-llms-2026) conversation. ## Where You Can Run It Cohere made availability broad on day one, which matters more than benchmarks for a model people are meant to actually deploy: ![Abstract systems illustration for Where You Can Run It](/images/blog/cohere-north-mini-code-open-weight-coding-model/inline-1.webp) - **Hugging Face** - weights in bf16, fp8, and w4a16 (4-bit) formats - **Cohere API** - hosted inference - **Model Vault** - Cohere's managed dedicated inference - **OpenCode** - usable for free inside the open-source coding harness - **OpenRouter** - routed access alongside other models The OpenCode integration is a smart distribution move. OpenCode is currently the most-starred open-source coding agent, so dropping North Mini Code into that harness puts it in front of a large existing developer audience without asking anyone to change tools. ## The Benchmark Picture (Read This Carefully) This is where favorable framing needs to give way to precision. The single concrete launch number Cohere reports is **33.4 on the Artificial Analysis Coding Index**, which the company characterizes as a competitive position among similarly sized models. That is an honest framing - it is not claiming frontier parity, it is claiming it competes in its weight class. The current public Artificial Analysis model page is a useful second check, but it is not the same metric. At refresh time, it listed North Mini Code at **21 on the Artificial Analysis Intelligence Index** and around **123 output tokens per second** for the measured provider route. That supports the same practical read: this is a fast, efficient open-weight coding model, not a frontier hosted-model replacement. Cohere's Hugging Face materials now expose more of the benchmark picture than the first version of this post had. The model card lists **67.6 on SWE-Bench Verified** and **40.2 on SWE-Bench Pro**, with evaluation through the SWE-agent harness. It also documents the broader evaluation suite: Terminal-Bench v2, Terminal-Bench Hard, SciCode, and LiveCodeBench v6, with three seeds averaged at temperature 1.0 and top_p 0.95. That is useful, but still read it as a benchmark suite, not a universal quality guarantee. Harness choice matters for coding agents, and North Mini Code is clearly optimized for code and terminal work rather than general agentic tasks. The efficiency claims are clearer, though still vendor-reported. Against **Devstral Small 2**, Cohere reports: - **Up to 2.8x higher output throughput** - A **~30% advantage in inter-token latency** - Devstral Small 2 keeps a slight lead on **time-to-first-token** These are throughput-and-latency claims, not quality claims, and they have not been independently reproduced. They are plausible given the 3B active-parameter design, but worth confirming on your own hardware before you build a latency budget around them. ## Why This Matters The interesting story here is not "Cohere beat anyone." It is the shape of the offering. **Self-hosting just got more practical for coding.** A 30B MoE that runs on one H100 with open weights and a permissive license lands in the same conversation as Devstral, Qwen-class coders, and other locally runnable models. For teams under data-residency or compliance pressure - the exact crowd that cannot send source code to a third-party API - a single-GPU footprint and Apache 2.0 terms remove two of the biggest blockers at once. **256K context is generous for the size class.** Agentic coding chews through context fast once you add file trees, diffs, and tool output. A quarter-million-token window on a model this small is a real working advantage for repo-scale tasks. **Cohere is signaling a direction.** Calling this the "inaugural member" of a next generation suggests more developer-facing models are coming from a company that previously stayed out of the coding race. That is worth watching even if this first model is a mid-tier entry rather than a leader. **Model routing gets more interesting.** North Mini Code is exactly the kind of model that belongs in a router: cheap local repo exploration, high-volume edit generation, and privacy-sensitive codebase work can go to the open-weight model, while harder design calls can still route to a frontier model. That is the same cost-control pattern behind [model routing recipes](/blog/model-routing-recipes-cut-ai-spend), [DeepSeek V4 budget coding agents](/blog/deepseek-v4-budget-coding-agents), and the broader [AI affordability crisis](/blog/ai-affordability-crisis-agent-costs). ## The Honest Caveats - **Coding-specialized, not generalist.** The strongest story is code and terminal work. Do not extrapolate that into non-coding agentic workflows without testing. - **Efficiency numbers are vendor-reported.** The 2.8x throughput and 30% latency figures come from Cohere, not independent labs. - **"Competitive among similarly sized models" is not "best."** This is a small, efficient, openly licensed model - not a Fable 5 or GPT-5.5 competitor on raw capability. Set expectations accordingly. ![Abstract systems illustration for The Honest Caveats](/images/blog/cohere-north-mini-code-open-weight-coding-model/inline-2.webp) ## Should You Try It? If you are already self-hosting coding models, North Mini Code is worth a slot in your evaluation harness this week - the Apache 2.0 license, single-H100 footprint, and OpenCode integration make it cheap to test. If you are happy with a hosted frontier model and have no compliance reason to bring inference in-house, there is no urgency here. And if you see a specific SWE-Bench percentage quoted for it, ask where the number came from before you trust it. The most useful thing about this release is not the model itself but what it represents: capable, openly licensed coding models that fit on hardware a single team can afford are becoming normal. That trend is good for developers regardless of which vendor's logo is on this particular checkpoint. --- ## FAQ ### Is North Mini Code open source? The weights are released under Apache 2.0, so the practical licensing story is permissive. Cohere and Hugging Face describe it as an open-weight research release rather than a fully open training-data-and-recipe release. ### Can North Mini Code replace Claude, GPT, or other frontier coding models? Not for every task. It is more compelling as a local or routed model for high-volume coding work, repo exploration, and privacy-sensitive workflows. Keep frontier models in the loop for hard architecture decisions, ambiguous product work, and final review. ### What hardware do you need to run North Mini Code? Cohere's launch materials say it can run on a single H100 in FP8 or FP4-style deployments, with Hugging Face variants available in bf16, fp8, and w4a16 formats. Your real footprint depends on serving stack, batch size, quantization, and context length. ### What benchmark number should I trust? Use Cohere's launch numbers and Hugging Face model-card scores as vendor-published context, then use the Artificial Analysis model page as a current third-party snapshot. Do not mix the Coding Index, Intelligence Index, SWE-Bench, and speed numbers as if they measure the same thing. ## Sources - [North Mini Code: Agentic Coding Model for Developers - Cohere](https://cohere.com/blog/north-mini-code) - [Cohere changelog: North Mini Code 1.0](https://docs.cohere.com/changelog/north-mini-code-1-0) - [Introducing North Mini Code - Cohere Labs on Hugging Face](https://huggingface.co/blog/CohereLabs/introducing-north-mini-code) - [North Mini Code model card - Hugging Face](https://huggingface.co/CohereLabs/North-Mini-Code-1.0) - [North Mini Code model page - Artificial Analysis](https://artificialanalysis.ai/models/north-mini-code) - [North Mini Code on OpenRouter](https://openrouter.ai/cohere/north-mini-code:free) - [Meet North Mini Code - MarkTechPost](https://www.marktechpost.com/2026/06/11/meet-north-mini-code-coheres-30b-open-weight-mixture-of-experts-model-with-3b-active-parameters-for-agentic-coding/)

Cursor Origin: A Git Forge Built for AI Agents, Not Humans

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 ## Official Sources | Source | What it covers | |--------|----------------| | [Cursor Origin (cursor.com/origin)](https://cursor.com/origin) | Official product page and waitlist | | [Cursor changelog: Cloud agents window](https://cursor.com/changelog/cloud-in-agents-window) | Same-week agent workflow context | | [eesel AI: What is Cursor Origin?](https://www.eesel.ai/blog/what-is-cursor-origin) | Feature breakdown, Graphite lineage, demo claims | | [explainx.ai: Cursor Origin git hosting](https://explainx.ai/blog/cursor-origin-git-hosting-github-alternative-ai-agents-2026) | Announcement framing and feature list | | [Hacker News: A Git forge for the agentic era](https://news.ycombinator.com/item?id=48558605) | Community reaction and trust questions | | [BigGo Finance: Cursor unveils Origin](https://finance.biggo.com/news/979fe270-a07e-4684-b99e-f1af5d31317e) | Announcement coverage | On June 16, 2026, at its Compile conference, Cursor (Anysphere) announced **Origin**: a Git-compatible code hosting platform whose pitch is unusually blunt. The premise, as the company framed it: what if the primary users of your version control system are no longer human? That is the whole bet. GitHub, GitLab, and every forge before them were designed around a human cadence: one engineer opens a branch, pushes a few commits an hour, opens a pull request, waits for a review. Cursor's argument is that agentic coding has broken that cadence. When dozens of background agents are committing in parallel, the bottlenecks move, and a forge tuned for humans starts to creak. This post sticks to what was actually announced, separates the shipped facts from the demo-stage claims, and flags what is still just a waitlist. **Last verified:** June 24, 2026. ## What Origin Actually Is Origin is a Git forge: repositories, branches, pull requests, and review, the same primitives you already know. It is Git-compatible, so existing tooling and `git push` workflows are meant to keep working, and Cursor has talked up GitHub migration tooling to ease the move. The differentiator is the design center. Where a conventional forge optimizes for human review throughput, Origin is built around agents operating at machine speed: structured, agent-authored diffs, automated review routing for AI-generated PRs, and native integration with Cursor's own background agents. Crucially, this is not a from-scratch effort. Origin is built on **Graphite**, the stacked-pull-request platform Cursor acquired, with Graphite co-founder Tomas Reimers leading the demo. That lineage matters: stacked PRs and the review tooling are proven technology, not vaporware. It is the agent-first layer on top that is new. That is also why Origin belongs next to [agent PR governance](/blog/agent-pr-governance-github-copilot-review), [parallel coding agent merge discipline](/blog/parallel-coding-agents-merge-discipline), and [local coding agent workspaces](/blog/local-coding-agent-workspaces-2026). The interesting question is not whether agents can generate more branches. They already can. The question is whether the forge can preserve review quality when branch creation becomes cheap. ## The Features Worth Tracking Across the announcement and early coverage, the features that consistently show up: ![Abstract systems illustration for The Features Worth Tracking](/images/blog/cursor-origin-git-forge-for-ai-agents/inline-1.webp) - **Agent-driven merge conflict resolution.** A built-in engine aimed at resolving conflicts automatically, the kind that pile up fast when many agents touch the same files concurrently. - **Agent resolution of CI and build failures.** Pushing remediation of broken builds toward automation rather than a human triage queue. - **Stacked pull requests.** Inherited directly from Graphite, letting a chain of dependent PRs move together, a workflow agents generate naturally. - **MCP- and API-extensibility.** Programmatic control surfaces so agents (and your own tooling) can drive the forge directly, not just click through a UI. - **A storage architecture for scale.** Coverage describes a hybrid NVMe-plus-S3 design intended to support large numbers of replicas for high-frequency clone and fetch traffic. Two of these, merge conflict resolution and CI-failure resolution, are the genuinely agent-native ideas. They target failure modes that barely register for a single human developer but become constant friction once a fleet of agents is committing in parallel. ## Separate the Numbers From the Hype Cursor's demo leaned on throughput figures to make the "machine speed" case. The most-quoted is **22.6 commits per second in a single repository**, alongside claims of very high clone volumes per hour. Treat those as demo-stage, vendor-supplied numbers, not independently benchmarked results. They illustrate the design goal, sustaining write and read rates that human-era forges were never built for, but they are staged figures, and some clone-count numbers circulating online have unclear timeframes or units. They are a useful signal of intent. They are not a verified production SLA. Likewise, treat any third-party rumors of corporate acquisitions tied to the announcement as unverified; they did not come from Cursor's product announcement and are not part of what Origin is. ## What Is Real vs. What Is a Promise This is the most important section for anyone deciding whether to care today. ![Abstract systems illustration for What Is Real vs. What Is a Promise](/images/blog/cursor-origin-git-forge-for-ai-agents/inline-2.webp) **Real now:** the announcement, the product vision, the Graphite foundation, and an open **waitlist at cursor.com/origin**. **Not yet:** general availability. Origin is slated for **fall 2026**. Pricing has not been disclosed. Enterprise features, security and compliance posture, and self-host options are unannounced. The throughput claims are demo figures awaiting independent verification. So this is real in the sense that a credible, well-funded company with proven forge technology (Graphite) has committed publicly to shipping it, with a date. It is a promise in the sense that you cannot run your team on it this week. ## The Trust Problem The HN thread was small, but it surfaced the right objection: a forge is not just another editor feature. It becomes the system of record for production code, review history, CI results, merge decisions, and incident archaeology. That makes Origin's unanswered questions more important than its demo throughput: - What code data is retained, indexed, or used for model improvement? - How are agent identities represented in commits and reviews? - Can teams require human approval before agent-resolved conflicts land? - What audit trail exists when an agent fixes CI and pushes follow-up commits? - Will enterprise customers get self-hosting, VPC, or dedicated deployment options? Until Cursor publishes pricing, data terms, compliance details, and the actual product surface, the safest framing is "watch closely," not "migrate." The same caution applies to [agent workspace filesystem contracts](/blog/agent-workspaces-need-filesystem-contracts), [Cursor automations](/blog/cursor-automations-developer-guide-2026), and [Cursor versus Codex](/blog/cursor-vs-codex): agent convenience is only useful if it leaves a reviewable trail. ## Why It Matters for Developers Even as a waitlist, Origin is a useful signal about where agentic development infrastructure is heading. The honest tension is governance. A forge that auto-resolves merge conflicts and auto-fixes CI failures is removing exactly the friction points where humans currently catch bad changes. That is the value proposition and the risk in the same sentence. The teams that benefit most from agent-speed infrastructure are also the ones with the most to lose if the safety rails are tuned for throughput over correctness. Expect the interesting questions to be about audit trails, approval gates, and who is accountable for an agent-merged change, not about commits per second. For now, the practical move is small: if you are already deep in the Cursor ecosystem and running background agents at volume, the waitlist costs nothing. Everyone else can watch for the fall release, independent throughput benchmarks, and a pricing page before forming an opinion. The idea is genuinely interesting. The product still has to ship. ## FAQ ### Is Cursor Origin available now? No. At verification time, the official Cursor Origin page was still a waitlist. Third-party coverage points to a fall 2026 target, but there is no public general-availability date, pricing page, or full documentation set. ### Is Origin replacing GitHub? Not today. It is a Git-compatible forge concept aimed at agent-heavy teams. GitHub remains the default system of record for most teams until Origin ships publicly and proves migration, permissions, integrations, compliance, and data handling. ### Why does Graphite matter? Graphite gives Origin a credible stacked-PR foundation. Stacked changes are a natural fit for agents because agents often split work into dependent branches. The open question is whether the new agent-native layer can preserve review quality at higher throughput. ### What should teams watch before trying Origin? Watch for pricing, data-use terms, SSO and audit controls, migration tooling, permission models for agents, CI integration, self-host or dedicated deployment options, and whether agent-authored conflict resolutions require human approval. ## Sources - [Cursor Origin](https://cursor.com/origin) - [Cursor changelog: Cloud agents window](https://cursor.com/changelog/cloud-in-agents-window) - [eesel AI: What is Cursor Origin?](https://www.eesel.ai/blog/what-is-cursor-origin) - [explainx.ai: Cursor Origin git hosting](https://explainx.ai/blog/cursor-origin-git-hosting-github-alternative-ai-agents-2026) - [BigGo Finance: Cursor unveils Origin](https://finance.biggo.com/news/979fe270-a07e-4684-b99e-f1af5d31317e) - [Hacker News: A Git forge for the agentic era](https://news.ycombinator.com/item?id=48558605)

DeepSeek V4 Economics: The Cost-Quality Frontier for Agentic Coding in 2026

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## The Cheap Model Got Good Enough to Argue About For most of the open-weights era, the cost-quality tradeoff was easy to call. The cheap models were cheap because they were worse, and on real agentic coding work - the long, tool-heavy loops where a model has to plan, edit, run, and recover from its own mistakes - the gap was wide enough that price barely entered the conversation. You paid frontier rates because the alternative did not finish the task. DeepSeek V4 changed the shape of that argument. With V4 Pro scoring 63.5 on SWE-bench Verified at a standing API price of $0.435 per million input tokens (cache miss) and $0.87 per million output, the question is no longer "is the cheap model good enough." It is "for which tasks is the quality delta worth four to fourteen times the bill." That is a routing decision, not a vendor loyalty decision, and it is the one this post is built to help you make. This is part of our ongoing AI-model-economics beat. If you want the full setup-and-API walkthrough, our [DeepSeek V4 developer guide](/blog/deepseek-v4-developer-guide) covers the SDK wiring, the thinking parameter, and the legacy alias cutover. If you want the head-to-head against the premium tier, [Fable 5 vs DeepSeek V4](/blog/fable-5-vs-deepseek-v4-cost-quality) measures the cost-quality gap on real tasks. This piece is about the economics of routing agentic coding work to V4 specifically. ## Official Sources Verify every figure below against primary sources before making a production decision. Prices and benchmarks move. | Resource | URL | What You Get | |----------|-----|--------------| | DeepSeek Pricing | [api-docs.deepseek.com/quick_start/pricing](https://api-docs.deepseek.com/quick_start/pricing) | Current per-million-token API pricing | | DeepSeek V4 Pro Model Card | [huggingface.co/deepseek-ai/DeepSeek-V4-Pro](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro) | Architecture, parameter counts, context limits | | OpenRouter: V4 Pro | [openrouter.ai/deepseek/deepseek-v4-pro](https://openrouter.ai/deepseek/deepseek-v4-pro) | Third-party pricing and benchmark aggregation | | OpenRouter: V4 Flash | [openrouter.ai/deepseek/deepseek-v4-flash](https://openrouter.ai/deepseek/deepseek-v4-flash) | Flash pricing and provider list | | CloudZero DeepSeek Pricing 2026 | [cloudzero.com/blog/deepseek-pricing](https://www.cloudzero.com/blog/deepseek-pricing/) | Independent pricing breakdown and cache notes | | Verdent V4 Pricing & Migration | [verdent.ai/guides/deepseek-v4-pricing-api-migration-2026](https://www.verdent.ai/guides/deepseek-v4-pricing-api-migration-2026) | Pricing history and migration context | ## The Two Models, and Why the Split Matters for Cost DeepSeek V4 ships as a family, not a single checkpoint. The split is the entire economic story, so it is worth being precise about which model does what. ![Abstract systems illustration for The Two Models, and Why the Split Matters for Cost](/images/blog/deepseek-v4-economics-cost-quality-frontier-agentic-coding/inline-1.webp) **V4 Flash** is the small, fast tier. The Hugging Face model card lists it at 158B total parameters with a smaller active footprint per token. It defaults to non-thinking mode, which keeps latency in the same range as the older `deepseek-chat`, and it is built for high-throughput work: classifiers, structured extraction, retrieval synthesis, and the inner loops of an agent where the model is making bounded, low-stakes decisions hundreds of times. **V4 Pro** is the flagship. The instruction-tuned release weighs 862B total parameters against a 1.6T base checkpoint, and it is the model you reach for on hard reasoning: codebase-scale refactors, multi-step planning, and agent workloads that have to hold state across many tool calls. It is slower and several times more expensive than Flash, but it is still a fraction of closed-model pricing. Both tiers share a 1M token context window and a 384K maximum output, the latter being a number nobody else is matching right now. For long-context agentic coding - dropping a whole repo into context and asking for a coordinated change - that 1M window is the feature that makes V4 a real frontier-model substitute rather than a budget fallback. ### The Pricing Table These are the per-million-token prices listed on the [DeepSeek pricing page](https://api-docs.deepseek.com/quick_start/pricing) as verified on June 17, 2026. Note that some April launch-window coverage still quotes V4 Pro at a higher $1.74 / $3.48 reference price; the official page now lists the lower standing rates below, and that page is the source of truth. | Model | Cache Hit (input) | Input | Output | |-------|------------------|-------|--------| | DeepSeek V4 Flash | $0.0028 | $0.14 | $0.28 | | DeepSeek V4 Pro | $0.003625 | $0.435 | $0.87 | | Claude Sonnet (reference) | - | ~$3.00 | ~$15.00 | | Frontier premium tier (reference) | - | ~$10.00 | ~$50.00 | Two things drop out of this table immediately. First, the cache hit price is a tiny fraction of the input price on both tiers, which means cache-friendly prompt structure - stable system context at the top, variable task at the bottom - quietly removes most of your input bill on any repeated workload. Second, V4 Pro output at $0.87 is roughly a seventeenth of Claude Sonnet's output rate and about a fiftieth of the premium-tier output rate. Output tokens dominate agentic coding bills because the model writes diffs, reasoning traces, and tool calls all day, so that output-side gap is where the real savings live. ## A Worked Cost Example Abstract per-token numbers do not build intuition. Let us cost a single realistic agentic coding task end to end. **The task:** a medium feature implementation across an existing TypeScript codebase. The agent reads relevant files, plans, writes the change across four files, runs the test suite, reads the failures, and patches twice before it goes green. This is a normal afternoon of agent work, not a toy. **Token profile for one run:** - Input: 600K tokens. Most of this is repeated codebase context fed back across iterations. With cache-friendly structure, assume 80 percent hits the cache (480K cached, 120K fresh). - Output: 80K tokens of plans, diffs, reasoning, and tool calls. **V4 Pro cost for this run:** - Cached input: 480K x $0.003625 / 1M = $0.0017 - Fresh input: 120K x $0.435 / 1M = $0.0522 - Output: 80K x $0.87 / 1M = $0.0696 - **Total: about $0.12 per task run** **The same run on a frontier premium tier** (at the reference $10 input / $50 output, no cache assumed for the comparison floor): - Input: 600K x $10 / 1M = $6.00 - Output: 80K x $50 / 1M = $4.00 - **Total: about $10.00 per task run** That is roughly an 80x difference on a single task, and it compounds. An agent fleet doing 200 such tasks a day is the difference between about $24 and about $2,000 per day, or about $9K versus $600K annualized on that one workload. Even against a mid-tier model like Claude Sonnet, the same run lands near $3.00, so V4 Pro is still about 24x cheaper. The honest caveat: this math assumes V4 Pro finishes the task. If a harder problem causes Pro to fail where a frontier model succeeds, you pay the cheap bill twice and then pay the expensive bill anyway, plus the human time to notice. That failure-cost multiplier is exactly what the decision guide below is designed to price in. ## Where V4 Sits on the Quality Axis The cost case only matters if the quality is real, so here is the benchmark picture. DeepSeek's own published numbers, which line up with early community reports on Hugging Face, put V4 Pro at 63.5 on SWE-bench Verified and 88.7 on MMLU-Pro. V4 Flash lands at 54.7 on SWE-bench Verified and 81.4 on MMLU-Pro, which is roughly R1-class reasoning at a fraction of R1's latency. A 63.5 on SWE-bench Verified puts V4 Pro in striking distance of mid-tier frontier coding models and clearly ahead of every other open-weights checkpoint you can self-host. It does not top the leaderboard. The current frontier premium models still hold an edge on the hardest real-codebase tasks, and that edge is precisely what you are paying 50x output rates to buy when the task warrants it. Treat vendor benchmarks as the optimistic case and validate on your own task distribution before you route production traffic. A model that wins on SWE-bench can still underperform on your specific stack, your conventions, and your tool surface. ## When to Route to DeepSeek vs a Frontier Model This is the decision the whole post is built around. Route by task characteristics, not by habit. ![Abstract systems illustration for When to Route to DeepSeek vs a Frontier Model](/images/blog/deepseek-v4-economics-cost-quality-frontier-agentic-coding/inline-2.webp) **Route to V4 Flash when:** - The work is high-volume and bounded: classification, structured extraction, retrieval synthesis, first-pass review, or the inner loop of an agent making many small decisions. - Prompts repeat enough to benefit from cache hits, which collapse the input bill. - Latency matters more than the last few points of quality. - The failure cost of any single call is low because the loop self-corrects. **Route to V4 Pro when:** - The task is genuinely hard but the failure cost is recoverable: codebase refactors, multi-step planning, technical synthesis across many sources. - You need the 1M context window to hold a whole repo or document set in one call. - You are cost-sensitive at scale and the 20x-to-80x savings versus frontier tiers move your unit economics. - You can verify the output cheaply, so a rare miss is caught before it ships. **Stay on a frontier premium model when:** - The failure cost is high and hard to detect: production migrations, security-sensitive changes, anything where a subtly wrong diff is worse than no diff. - The task lives at the top of the SWE-bench difficulty curve where the frontier still wins outright. - You depend on provider-specific tooling - a particular agent SDK, computer-use surface, or harness integration - that V4 does not slot into cleanly. - The per-task spend is small relative to the value at risk, so optimizing the model bill is the wrong thing to optimize. The cleanest way to capture this in practice is a routing layer rather than a single default model. Run a smart orchestrator that triages tasks and dispatches the bounded ones to Flash, the hard-but-recoverable ones to Pro, and escalates only the genuinely frontier-grade work upward. We laid out the orchestrator-and-workers pattern in depth in the [Omnigent meta-harness piece](/blog/omnigent-meta-harness-agent-orchestration), which is the natural home for this kind of cost-aware dispatch. For a parallel cost-math treatment on a different cheap-but-capable model, the [GLM-5.2 developer guide](/blog/glm-5-2-developer-guide-2026) runs the same exercise for Z.ai's 1M-context coder. ## The Self-Host Lever One more economic axis that frontier models cannot match: V4's weights are MIT licensed. Flash fits on a single high-memory workstation at 4-bit quantization, and Pro runs on a small cluster or a rented high-memory GPU box. For a steady, high-volume internal workload, self-hosting converts a per-token API bill into a fixed hardware cost, and above a certain throughput the fixed cost wins decisively. It also removes the data-egress and privacy questions that block some teams from sending code to any third-party API at all. That optionality has real value even if you never exercise it, because it caps your downside if API pricing moves against you. ## The Bottom Line DeepSeek V4 did not win the benchmark crown, and it does not need to. What it did was push the cost-quality frontier far enough that "just use the frontier model for everything" stopped being the obviously correct default for cost-sensitive agentic coding. Flash makes the bounded, repetitive parts of an agent loop nearly free. Pro delivers near-mid-frontier coding quality at a fraction of the output price, with a 1M context window and a self-host escape hatch. Route by task. Send the cheap, recoverable, high-volume work to V4 and reserve frontier spend for the high-failure-cost, top-of-curve tasks that actually justify it. Do the worked math on your own token profile, validate the quality on your own task distribution, and let the routing layer enforce the discipline. The economics in mid-2026 reward teams that treat model choice as a per-task decision rather than a standing subscription. ## Frequently Asked Questions ### How much cheaper is DeepSeek V4 Pro than frontier models for agentic coding? On a representative medium feature task (about 600K input tokens with cache-friendly structure and 80K output tokens), V4 Pro costs roughly $0.12 per run versus about $10.00 on a frontier premium tier at reference rates, a roughly 80x difference. Against a mid-tier model like Claude Sonnet, V4 Pro is about 24x cheaper on the same run. Output tokens dominate the bill, and V4 Pro's $0.87 output rate is where most of the savings come from. ### What is the difference between DeepSeek V4 Flash and V4 Pro for cost? V4 Flash costs $0.14 per million input tokens and $0.28 output, with cache hits at $0.0028. V4 Pro costs $0.435 input and $0.87 output, with cache hits at $0.003625. Flash is built for high-volume bounded work like classification and agent inner loops; Pro is for hard reasoning and codebase-scale tasks. Both share a 1M context window and 384K max output. ### Is DeepSeek V4 Pro good enough to replace a frontier model for coding? It scores 63.5 on SWE-bench Verified, which puts it in striking distance of mid-tier frontier coding models and ahead of every other open-weights model. It does not top the leaderboard, so the frontier still wins on the hardest real-codebase tasks. Route V4 the hard-but-recoverable work where you can verify output cheaply, and reserve frontier spend for high-failure-cost tasks. ### When should I route a task to DeepSeek instead of a frontier model? Route to DeepSeek when the work is bounded and high-volume (Flash) or hard but recoverable with cheap verification and cost pressure at scale (Pro). Stay on a frontier model when the failure cost is high and hard to detect, the task is at the top of the difficulty curve, or you depend on provider-specific tooling. A routing layer that dispatches by task characteristics captures most of the savings. ### Can I self-host DeepSeek V4 to cut costs further? Yes. The weights are MIT licensed. Flash fits on a single high-memory workstation at 4-bit quantization, and Pro runs on a small cluster or rented high-memory GPU box. For steady high-volume workloads, self-hosting converts a per-token API bill into a fixed hardware cost that wins above a certain throughput, and it removes data-egress and privacy constraints. ## Sources - [DeepSeek API Pricing](https://api-docs.deepseek.com/quick_start/pricing) - per-million-token pricing for V4 Flash and Pro, cache hit rates - [DeepSeek V4 Pro Model Card on Hugging Face](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro) - parameter counts, context window, MIT license - [OpenRouter: DeepSeek V4 Pro](https://openrouter.ai/deepseek/deepseek-v4-pro) - third-party pricing and benchmark aggregation - [OpenRouter: DeepSeek V4 Flash](https://openrouter.ai/deepseek/deepseek-v4-flash) - Flash pricing and provider list - [CloudZero: DeepSeek Pricing 2026](https://www.cloudzero.com/blog/deepseek-pricing/) - independent pricing breakdown, cache and discount history - [Verdent: DeepSeek V4 Pricing & API Migration 2026](https://www.verdent.ai/guides/deepseek-v4-pricing-api-migration-2026) - pricing history and migration context

Epic Games Releases Lore: A Version Control System Built for Game Development

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

Epic Games just released Lore, an open-source version control system specifically designed for repositories that contain massive binary assets alongside code. The project launched under an MIT license and is available immediately. **Last updated:** June 17, 2026 ## What Lore actually is Lore is a centralized, content-addressed version control system that represents repository state as Merkle trees. Unlike Git, which was designed around source code and treats binary files as an afterthought, Lore was built ground-up for the mix of code and binary assets that game development requires. The headline features: - **Native binary handling**: Chunked storage and deduplication built into the core, not bolted on like Git LFS - **On-demand hydration**: Workspaces fetch file data only when needed, so you can work with terabyte-scale repos without cloning everything - **Sparse workspaces**: Artists working on textures do not need to download the entire audio folder - **Immutable revision chain**: Cryptographically verifiable history using Merkle trees - **File locking**: Built-in support for exclusive locks on assets that cannot be merged The project is centralized by design - two clients communicate through the remote, not directly. This is intentional. Lore is solving a different problem than Git solved. ## Why this exists Git works well for source code. It was not built for game development. ![Abstract systems illustration for Why this exists](/images/blog/epic-games-lore-version-control-system/inline-1.webp) A typical AAA game repository weighs in at hundreds of gigabytes to over a terabyte. The vast majority of that is binary assets - textures, 3D models, audio files, video sequences. Git handles text diffs efficiently but treats binary files as opaque blobs. Every change to a 500MB texture stores another 500MB. Git LFS patches around this by storing large files outside the repo, but it adds complexity to an already complex tool. LFS bandwidth limits and storage costs on GitHub bite quickly. Sparse checkouts with LFS still have offline limitations. Perforce has been the de facto standard for large game studios precisely because it handles this scale. From the HN discussion, multiple commenters with game industry experience confirmed that Perforce is everywhere in AAA studios - and that it requires dedicated tools engineers to keep it running smoothly. One commenter summarized the core problem: "When you have a game that weighs in at 100GB, only a tiny fraction of that is built from code. The rest of it is binary assets that most VCSs struggle with." ## What HN is saying The discussion thread hit 265 comments and surfaced several perspectives from game developers. **The irony of hosting on GitHub** was not lost on commenters. The Lore repository itself lives on GitHub, using Git. As one commenter pointed out: "Lore itself is not an example of a program that meaningfully benefits from any of the key features of Lore." The tool is source code - it does not contain gigabytes of binary assets. **Perforce's dominance came up repeatedly.** Multiple commenters confirmed that Perforce is the industry standard but noted its pain points. One developer described spending significant time "helping people fix their workspaces when Perforce goes bad." The list of complaints included desync issues requiring hours-long reconciles, poor scripting support, inconsistent line-ending handling across operating systems, and per-user licensing costs. **GUI support matters for non-programmers.** Several commenters noted that artists and designers need GUI tools, not CLI. One wrote: "Non-programmers don't want to dabble with CLI. One reason why Perforce is the defacto standard - the GUI covers 99% of daily used operations." **The CLI syntax is Git-like:** ```bash echo "Hello, Lore" > hello.txt lore stage hello.txt lore status --scan lore commit "Initial revision" lore push ``` **Skepticism about Epic's track record** appeared in several threads. One commenter raised the Rocket League situation - Epic acquired Psyonix and subsequently removed Linux and macOS client support, leaving those players unable to access a game they had purchased. ## Technical details Lore ships with binaries for Windows, macOS (ARM64), and Linux (x86-64 and ARM64). Language bindings exist for C/C++, Rust, JavaScript, C#, Python, and Go. For infrastructure, it supports both a local zero-config mode for experimentation and scalable deployment via Docker. The reference implementation uses AWS S3 and DynamoDB. The architecture is explicitly not decentralized. From the documentation's "Explicit non-goals" section: "Peer-to-peer decentralization. Lore is centralized by design." This centralization is a feature, not a limitation, for the target use case. Game studios need access control - the ability to restrict certain directories to developers who have signed specific NDAs. Git cannot do this at the repository level; it is all-or-nothing. Perforce handles this with directory-level permissions, and Lore inherits this architectural choice. ## Who should care **Game development teams** dealing with terabyte-scale repositories where Git LFS is hitting limits. If you are paying Perforce licensing fees and have dedicated engineers managing the infrastructure, Lore offers an MIT-licensed alternative worth evaluating. ![Abstract systems illustration for Who should care](/images/blog/epic-games-lore-version-control-system/inline-2.webp) **Creative teams working with large media files** - video production, 3D animation, mixed-media projects. The same binary asset challenges apply. **Enterprise teams with access control requirements** - the centralized architecture enables directory-level permissions that Git cannot provide. **Not** general software development teams working primarily with source code. Git remains the right tool for that problem space. ## The current state Lore launched as a pre-stable 0.x release. Epic commits that data written now will remain readable in future versions, which matters for production adoption. The tool is not yet integrated with Unreal Engine's editor workflows - that kind of deep integration is presumably on the roadmap. For now, it is a standalone VCS that handles the storage and versioning layer. One open question is whether Epic will continue active development or if this becomes an open-source release that the community inherits. The company's history includes both well-maintained projects (Unreal Engine itself) and abandoned ones. --- ## FAQ ### What is Epic Games Lore? Lore is an open-source version control system from Epic Games, released under the MIT license in June 2026. It is designed specifically for repositories that combine code with large binary assets like textures, 3D models, and audio files. ### How is Lore different from Git? Git was designed for source code and treats binary files as opaque blobs. Lore was built ground-up for binary assets with native chunked storage, deduplication, on-demand file hydration, and built-in file locking. It is centralized rather than distributed. ### Does Lore replace Perforce? Lore targets the same use case as Perforce - large binary-heavy repositories in game development. Whether it can replace Perforce depends on the specific features your team relies on. Perforce has decades of tooling and integration; Lore is a new 0.x release. ### Is Lore open source? Yes, Lore is released under the MIT license. The source code is available on GitHub at github.com/EpicGames/lore. ### Can I use Lore for regular software development? You can, but Git is probably a better fit if your repository is primarily source code. Lore's advantages - binary handling, sparse workspaces, large repo scale - do not apply to typical software projects. ### What platforms does Lore support? Lore has pre-built binaries for Windows, macOS (ARM64), and Linux (x86-64 and ARM64). Language bindings are available for C/C++, Rust, JavaScript, C#, Python, and Go. --- ## Sources - [Lore official site](https://lore.org/) - Epic Games, accessed June 17, 2026 - [Lore GitHub repository](https://github.com/EpicGames/lore) - MIT licensed source - [Hacker News discussion](https://news.ycombinator.com/item?id=48571081) - 265+ comments, accessed June 17, 2026

Everything Vercel Shipped at Ship 26 (June 2026)

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## The agent-era Ship Vercel held [Ship](https://vercel.com/blog/introducing-eve), its annual conference, in London on June 17, 2026, and the theme was unambiguous: this is the agent era, and Vercel wants to be the place agents deploy. The framing came with a number that explains the urgency. At the start of the year, fewer than 3% of deployments on Vercel were triggered by coding agents. Now agents account for more than half of all commits, and token volume through the [AI Gateway](https://vercel.com/blog/ai-gateway-production-index) has grown from roughly 2 million to 20 million over the same window. "For the agent era, that's Vercel," said founder and CEO Guillermo Rauch, per [SiliconANGLE's coverage](https://siliconangle.com/2026/06/17/vercel-launches-new-framework-enterprise-controls-agentic-ai-infrastructure/). Here is what shipped that backs up the claim. ## 1. eve: an open-source agent framework The headline launch is [eve](https://vercel.com/blog/introducing-eve), an open-source framework for building, running, and scaling AI agents in production. Vercel calls it "Next.js for agents," and the design is filesystem-first: you define each agent with files under an `agent/` directory, and eve compiles them into an app that runs on [Vercel Functions](https://vercel.com/docs/functions). ![Abstract systems illustration for 1. eve: an open-source agent framework](/images/blog/everything-vercel-shipped-at-ship-26/inline-1.webp) A minimal agent is two files. `agent/instructions.md` holds the system prompt, and `agent/agent.ts` holds the config: ```ts import { defineAgent } from 'eve'; export default defineAgent({ model: 'openai/gpt-5.4-mini', }); ``` Tools are just files in `agent/tools/`, with the filename becoming the tool name. The reason eve is more than a wrapper is that production concerns ship in the framework: durable execution (sessions checkpoint each step and survive crashes and deploys), sandboxed compute, human-in-the-loop approvals, subagents, and evals. Vercel says it already runs more than 100 production agents on eve, so this is dogfooded infrastructure, not a demo. eve launched as a public preview and is still in beta. We did a full walkthrough in [our deep dive on the eve framework](/blog/vercel-eve-framework-for-building-ai-agents), including the quickstart and real code. The short version: `npx eve@latest init my-agent` and you have a durable, sandboxed agent scaffold. ## 2. Vercel Drop: deploy by dragging a folder into the browser [Vercel Drop](https://vercel.com/changelog/vercel-drop) is the antidote to "I just want this live." You deploy a file, folder, or `.zip` by dragging it into your browser. No Git, no Vercel CLI, no local setup. The flow, per the [Drop docs](https://vercel.com/docs/drop): drop a project onto vercel.com/drop, pick a team and project name, and select Deploy. Vercel creates a new project, uploads your files, and publishes straight to production with a shareable live URL, in seconds. It handles more than static files too. If Vercel detects a framework like Next.js, it builds it; files with no framework deploy as-is with no build step. It is purpose-built for the moment where the artifact already exists and the friction is the pipeline. Drop is positioned for prototypes, one-off sites, and shipping exports from tools like Webflow, Claude Design, Google Stitch, and Bolt.new without wiring up a repository first. In an era where a generation tool can hand you a finished folder, "drag it to the browser to go live" is exactly the last mile that was missing. ## 3. AI Gateway: spend caps per API key Cost governance is the quiet anxiety of running agents, and Vercel addressed it directly with [budgets for AI Gateway API keys](https://vercel.com/changelog/budgets-for-api-keys-on-ai-gateway). You can now set a spend cap on any [AI Gateway](https://vercel.com/docs/ai-gateway) key, and the gateway rejects further requests on that key once the limit is exceeded, until the budget resets or you raise it. The cap applies across all providers and models running through the key, so it is a single governance lever over your whole model spend. You can pair a key with an optional refresh period (daily, weekly, monthly, or none) to scope the limit to a window, and you can create a budgeted key from the dashboard or programmatically via the CLI: ```bash vercel ai-gateway api-keys create --name my-key --budget 50 --refresh-period monthly ``` One honest detail worth knowing: the budget is a soft cap, not a hard limit. The check runs at the start of each request, so the request that crosses the limit still completes, and total spend can end up slightly over the budget. For anyone who has watched an agent loop chew through a token budget overnight, even a soft cap per key is a meaningful guardrail. ## 4. AI SDK 7: HarnessAgent unifies Claude Code, Codex, and Pi The most interesting developer-facing API is [HarnessAgent in AI SDK 7](https://vercel.com/changelog/program-agent-harnesses-with-ai-sdk), a single interface for running established agent harnesses. The AI SDK has always let you switch models without rewriting your agent. Now you can switch the entire harness the same way. ![Abstract systems illustration for 4. AI SDK 7: HarnessAgent unifies Claude Code, Codex, and Pi](/images/blog/everything-vercel-shipped-at-ship-26/inline-2.webp) Harnesses manage everything above the model call: skills, sandboxes, sessions, permission flows, compaction, runtime config, and subagents. AI SDK 7 normalizes access to those capabilities behind one abstraction. The initial experimental adapters are Claude Code, Codex, and Pi, with more coming, and every harness runs the agent in a sandboxed workspace to keep the host environment safe. The API looks like this: ```ts import { HarnessAgent } from '@ai-sdk/harness/agent'; import { claudeCode } from '@ai-sdk/harness-claude-code'; import { createVercelSandbox } from '@ai-sdk/sandbox-vercel'; const agent = new HarnessAgent({ harness: claudeCode, sandbox: createVercelSandbox({ runtime: 'node24', ports: [4000], }), tools: { /* pass custom tools */ }, skills: [ /* pass custom skills */ ], }); const session = await agent.createSession(); try { const result = await agent.stream({ session, prompt: 'Check the test failures and fix the production code.', }); for await (const part of result.fullStream) { if (part.type === 'text-delta') { process.stdout.write(part.text); } } } finally { await session.destroy(); } ``` Both `HarnessAgent.generate()` and `HarnessAgent.stream()` return AI SDK-compatible results, so a harness drops into the streaming patterns AI SDK developers already use. Swap `claudeCode` for `codex` or `pi` and the rest of your code stays put. For anyone who has thought about [meta-harness agent orchestration](/blog/meta-harness-agent-orchestration), this is the standard library version of that idea. It is an experimental release, so expect breaking changes between versions. ## The throughline Stack these four launches and a single thesis emerges. eve standardizes how you build an agent, HarnessAgent standardizes how you drive existing coding harnesses, AI Gateway budgets standardize how you bound the cost, and Drop standardizes the fastest possible path from artifact to live URL. Together they extend [Vercel's agentic infrastructure stack](/blog/vercel-agentic-infrastructure-stack) from "deploy your app" to "build, run, govern, and ship your agents," which is the platform Vercel clearly intends to own. Plenty of the launch was still beta or experimental, so treat the API surfaces as moving targets for now. But as a statement of where the platform is heading, Ship 26 was the most cohesive agent-era roadmap Vercel has put on stage. ## Sources - [Introducing eve - Vercel blog](https://vercel.com/blog/introducing-eve) - [Introducing eve, an open-source agent framework - Vercel changelog](https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework) - [Vercel launches a new framework and enterprise controls for agentic AI infrastructure - SiliconANGLE](https://siliconangle.com/2026/06/17/vercel-launches-new-framework-enterprise-controls-agentic-ai-infrastructure/) - [Introducing Vercel Drop - Vercel changelog](https://vercel.com/changelog/vercel-drop) - [Deploying with Vercel Drop - Vercel docs](https://vercel.com/docs/drop) - [Budgets for API keys on AI Gateway - Vercel changelog](https://vercel.com/changelog/budgets-for-api-keys-on-ai-gateway) - [Program Claude Code, Codex, Pi and other agent harnesses with AI SDK - Vercel changelog](https://vercel.com/changelog/program-agent-harnesses-with-ai-sdk)

Factory Router, Explained: How Automatic Model Routing Cuts Coding-Agent Spend 20-25%

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 ## Official Sources - [Factory Router announcement](https://factory.ai/news/factory-router) - the primary source for the product claims in this post - [Factory 2.0: From coding agents to software factories](https://factory.ai/news/software-factory) - the self-improving system thesis - [Factory raises $150M Series C](https://factory.ai/news/series-c) - the funding round and roadmap - [Choosing Your Model](https://docs.factory.ai/cli/user-guides/choosing-your-model) - the docs for manual model selection that the router sits on top of We have argued before that [the orchestration layer is the next big play next to the labs](/blog/ai-model-routing-orchestration-layer): as frontier model quality flattens and commodifies, the durable value moves to the system that decides which model runs which task. Factory.ai's new Factory Router is the cleanest flagship example of that thesis shipping inside a real coding agent. So it is worth a close, favourable-but-factual look. The headline numbers are good. They are also vendor numbers, and we will keep flagging them as such. For the broader buying decision, pair this with [LLM routers compared](/blog/llm-router-comparison-2026), [model routing recipes](/blog/model-routing-recipes-cut-ai-spend), and [OpenRouter in 2026](/blog/openrouter-review-setup-2026). Factory Router is the managed-agent version of a wider routing and gateway category. ## What Factory Router Actually Is Factory Router is a routing layer baked into Factory's Droid coding agent. Per the [announcement](https://factory.ai/news/factory-router), it "automatically selects the right model for each task, and routes across providers if an endpoint degrades." Instead of expecting every engineer to manually pick the best model for every session, the router does the selection for them, drawing "from a diverse pool of frontier and efficient models." Two things make it more than a thin proxy. First, it operates per Droid session, not per account, so the model choice tracks the actual work in front of it. Second, it escalates mid-flight: Factory says that if "the selected model struggles to complete the task, Factory Router moves the session to a more capable model." That escalation behavior is the same pattern we documented in our [model routing recipes](/blog/model-routing-recipes-cut-ai-spend) field guide - start cheap, escalate on signal - except here it is managed for you rather than wired up by hand. It ships as part of the broader Droid product (CLI and Desktop App). Factory describes it as being in private research preview, and notes that once an org enables it, the router shows up in the model picker for every user with no per-developer setup. ## The Model-Agnostic Foundation It Sits On The router only works because Droid was model-agnostic from the start. Factory's own framing in [Factory 2.0](https://factory.ai/news/software-factory) is that a Droid "is model agnostic, and can change models mid-session," routing its reasoning through frontier models from multiple providers depending on the task. The pool spans frontier models, more efficient models, and US-hosted open-source models, and Factory says it "keeps frontier models available as they come online." ![Abstract systems illustration for The Model-Agnostic Foundation It Sits On](/images/blog/factory-router-automatic-model-routing-spend/inline-1.webp) This is the part worth internalizing: the router is not picking from one lab's menu. It arbitrages across providers. That is precisely why provider failover is possible at all, and it is the structural reason an orchestration vendor can claim independence from any single model's pricing or availability. We covered the architectural groundwork - Custom Droids, per-task model flags, `droid exec` - in our earlier piece on [Factory AI and the model routing era](/blog/factory-ai-droid-model-routing-costs). Factory Router is the automatic layer that sits on top of that manual control surface. ## The Numbers (And Whose Numbers They Are) Here are the claims, stated plainly as Factory's claims, not as independently verified results: - **20-25% lower token spend** "while maintaining frontier performance." (Factory) - **Terminal-Bench 2:** 99% of Claude Opus 4.7's pass rate at 20% lower cost per session. (Factory) - **Legacy-Bench:** 96% of Claude Opus 4.7's pass rate at 25% lower cost per session. (Factory) - **99.9%+ request reliability** by routing across models, providers, and capacity sources. (Factory) A few honest caveats. These benchmarks are Factory's own, run by Factory, and the comparison baseline is a single frontier model (Opus 4.7). Holding 96-99% of a top model's pass rate while shaving a fifth to a quarter off cost is a genuinely strong result if it generalizes - but "if it generalizes" is doing real work. Your codebase, task mix, and tolerance for the occasional missed escalation will move those numbers. Treat 20-25% as a plausible ceiling for the easy-task share of your workload, not a guaranteed line-item cut. None of this is independently reproduced as of this writing. The reliability claim is more believable on its face, because it is mechanical rather than statistical: if you can route the same request across multiple providers and reserved capacity, you genuinely do dodge any single provider's outage. Factory backs this with "provider failover" and an optional "Dedicated TPM" tier for "reserved throughput for critical Droid work." That is a real architectural lever, not a benchmark. ## Self-Learning and Enterprise Control Factory's larger pitch in [Factory 2.0](https://factory.ai/news/software-factory) is a system that "must improve over time by observing itself," feeding "every agent session, code review, and resolved incident back into the loop." The router is the first concrete surface of that idea: routing decisions are meant to get better as the system sees more of your work. That said, the public material is light on the mechanics of the learning loop - how feedback is captured, what gets tuned, on what cadence. So read "self-learning" as a stated direction with a credible architecture behind it, not a measured capability you can audit today. What is concrete is the manual override: admins can set "routing rules and context" that "describe workflow patterns" - codebase areas, toolchains, model preferences - to shape automatic selection. So it is not a black box you cannot steer. ## Why This Matters Now: The Series C Read The router is not a side feature. Factory raised a [$150M Series C in April 2026](https://factory.ai/news/series-c), led by Khosla Ventures with Sequoia, Insight, Blackstone, NEA and others, at a $1.5B valuation. Factory's stated use of funds explicitly named "model routing, always-on background agents, and enterprise governance" as product priorities, alongside long-horizon reliability research. In other words, the router is part of the thesis investors funded, and Factory reports hundreds of thousands of daily developers across enterprises like Nvidia, Adobe, EY, and Adyen, with revenue doubling month over month for six straight months (again, Factory's figures). ![Abstract systems illustration for Why This Matters Now: The Series C Read](/images/blog/factory-router-automatic-model-routing-spend/inline-2.webp) Strip away the specific company and you get the orchestration-layer bet in its purest form: own the routing decision, sit above every provider, and capture margin from efficiency rather than from owning a model. That is the structural story we have been tracking, and Factory is now the most fully realized instance of it inside a shipping coding agent. This also connects to [Models.dev as routing infrastructure](/blog/models-dev-model-routing-infrastructure): the more models, prices, context windows, and providers change, the more value sits in the current metadata and policy layer above them. ## Router vs DIY Routing: Should You Use One? This is the practical question. You can build your own routing with OpenRouter, LiteLLM, or per-task model flags - we have published the [recipes](/blog/model-routing-recipes-cut-ai-spend) to do exactly that. So when does a managed router earn its keep? **Reach for a managed router (like Factory Router) when:** - Your routing is tied to a specific agent's session lifecycle (mid-session escalation, spec-vs-execute phases) rather than simple per-request model selection. That coupling is hard to replicate from outside the agent. - You want provider failover and reliability without operating the plumbing yourself, and uptime on coding agents is a real cost to your team. - You have many engineers and no appetite to make each of them a routing expert. Org-wide defaults with admin rules beat per-developer model-picking. - You value the self-improving loop enough to accept some opacity in how decisions get made. **Roll your own when:** - You need full transparency and auditability over every routing decision (cost attribution, compliance, deterministic behavior). - Your spend is concentrated in a workload you understand well enough to tier by hand - a static "cheap model for X, frontier for Y" config can capture most of the savings with zero vendor lock-in. - You are routing across surfaces beyond a single agent (your own apps, CI jobs, internal tools) where an agent-bound router does not reach. - Avoiding lock-in to one orchestration vendor is itself a priority. The honest middle ground: a managed router is most compelling precisely where DIY is hardest - inside the agent's session loop, with failover, at team scale. It is least compelling for static, well-understood, single-axis cost tiering you could express in a config file. And whichever path you choose, the discipline from our [$400 overnight bill](/blog/400-dollar-overnight-bill-agent-finops) piece still applies: a router optimizes cost-per-task, but it does not cap your total spend. You still need budgets, alerts, and FinOps guardrails on top. ## The Bottom Line Factory Router is a credible, well-positioned flagship for the orchestration-layer thesis: model-agnostic routing across providers, per-session escalation, mechanical failover, and a self-improving ambition, backed by a $150M round that names routing as a core priority. The efficiency claims - 20-25% lower spend at 96-99% of Opus pass rate - are strong but are Factory's own benchmarks against a single baseline, and should be treated as a plausible upper bound rather than a promise. The reliability story is more structurally sound because it is mechanical, not statistical. If you are already on Droid at team scale, the router is close to free upside: enable it, set a few routing rules, and watch your cost-per-task. If you are routing across your own stack, the DIY recipes still win on transparency and reach. Either way, the strategic takeaway holds: the model is increasingly a commodity input, and the system that decides which model runs is where the leverage now lives. ## FAQ ### What is Factory Router? Factory Router is Factory.ai's managed model-routing layer for Droid sessions. Factory says it automatically chooses the right model for each coding-agent task, escalates to a stronger model when needed, and routes across providers when endpoints degrade. ### Are the 20-25% savings independently verified? No. The 20-25% lower token-spend claim is Factory's own benchmark claim. Treat it as a vendor-reported result to test against your own task mix, not as a guaranteed savings number. ### How is Factory Router different from LiteLLM or OpenRouter? LiteLLM and OpenRouter are general routing or gateway surfaces that can sit in front of many applications. Factory Router is tied to Factory's Droid agent session loop, which means it can make routing decisions based on the coding-agent workflow itself. ### When should a team use a managed router? Use a managed router when routing is coupled to agent sessions, provider failover matters, and you do not want every engineer choosing models manually. Build your own routing when auditability, cross-app reach, or vendor independence matters more. ### Does routing replace spend guardrails? No. Routing can reduce cost per task, but it does not cap total spend. Teams still need budgets, alerts, per-key limits, and workflow stop conditions. ## Sources - [Factory Router announcement](https://factory.ai/news/factory-router) - [Factory 2.0](https://factory.ai/news/software-factory) - [Factory Series C](https://factory.ai/news/series-c) - [Factory model selection docs](https://docs.factory.ai/cli/user-guides/choosing-your-model) - [LiteLLM routing docs](https://docs.litellm.ai/docs/routing) - [OpenRouter docs](https://openrouter.ai/docs)

Gemini CLI to Antigravity CLI Migration Guide: The June 18 Deadline

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Google Developers Blog Announcement | [developers.googleblog.com](https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/) | | Antigravity CLI Installation | [antigravity.google/cli](https://antigravity.google/cli/) | | Antigravity Documentation | [antigravity.dev/docs](https://antigravity.dev/docs) | | GitHub Issue #31 (ACP Mode) | [github.com/google/antigravity-cli/issues/31](https://github.com/google/antigravity-cli/issues/31) | | Gemini Code Assist Enterprise | [cloud.google.com/gemini/docs](https://cloud.google.com/gemini/docs) | **Last updated:** June 17, 2026 Tomorrow, June 18, 2026, Gemini CLI stops serving requests for free-tier and Google AI Pro/Ultra users. If you rely on the `gemini` binary in your terminal, CI pipelines, or automation scripts, you have roughly 24 hours to migrate to Antigravity CLI or your workflows will break. This guide covers exactly what to do: installation, config migration, the silent MCP bug that breaks tool calls, and the CI/CD changes you cannot skip. ## Who Is Affected **Must migrate by June 18:** - Free-tier Gemini CLI users - Google AI Pro and Ultra subscribers - Anyone using Gemini Code Assist IDE extensions outside enterprise agreements - New Gemini Code Assist for GitHub installations (blocked after June 18) **Exempt from migration:** - Gemini Code Assist Standard or Enterprise license holders - Organizations using GitHub integration through Google Cloud - Anyone accessing Gemini via paid API keys (not CLI) If you are on an enterprise license, your Gemini CLI access continues. But the community is moving to Antigravity, so the ecosystem support for Gemini CLI will decline. ## What Changes Antigravity CLI is a ground-up Go rewrite, not a fork of the original TypeScript stack. The core features transfer: Agent Skills, Hooks, Subagents, and Extensions (now called plugins). But the implementation details differ in ways that will break existing automation. ![Abstract systems illustration for What Changes](/images/blog/gemini-cli-to-antigravity-cli-migration-guide-2026/inline-1.webp) **Key differences:** | Aspect | Gemini CLI | Antigravity CLI | |--------|-----------|-----------------| | Binary name | `gemini` | `agy` | | Language | TypeScript | Go | | Performance | Standard | Faster startup, async multi-agent | | Skills directory | `.gemini/skills/` | `.agents/skills/` | | Global skills | `~/.gemini/skills/` | `~/.gemini/antigravity-cli/skills/` | | MCP config | Inline in settings.json | Separate `mcp_config.json` | | Extensions | Extensions API | Plugins API | | Request quota | 1,000/day | Weekly compute cap | Google explicitly states there will not be 1:1 feature parity at launch. The migration script does not touch your CI configs, cron jobs, or shell aliases. You must audit those manually. ## Step 1: Install Antigravity CLI **macOS/Linux:** ```bash curl -fsSL https://antigravity.google/cli/install.sh | bash ``` Or via Homebrew: ```bash brew install --cask antigravity-cli ``` **Windows (PowerShell):** ```powershell irm https://antigravity.google/cli/install.ps1 | iex ``` **Verify installation:** ```bash agy doctor ``` This runs end-to-end validation. Fix any issues before proceeding. ## Step 2: Authenticate Run `agy` and complete the OAuth flow. The settings file lands at `~/.gemini/antigravity-cli/settings.json`. If you were using a custom API key with Gemini CLI, you will need to reconfigure it in the new settings file. ## Step 3: Import Your Extensions Antigravity CLI includes a migration command for Gemini extensions: ```bash agy plugin import gemini ``` This converts your Gemini extensions to Antigravity plugins. Review the output for any warnings about incompatible extensions. ## Step 4: Move Your Skills Workspace skills move from `.gemini/skills/` to `.agents/skills/`: ```bash git mv .gemini/skills .agents/skills ``` Global skills move from `~/.gemini/skills/` to `~/.gemini/antigravity-cli/skills/`: ```bash mv ~/.gemini/skills ~/.gemini/antigravity-cli/skills ``` ## Step 5: Fix the MCP Config (Critical) This is where most migrations silently fail. Antigravity CLI moves MCP server configuration from inline entries in `settings.json` to a dedicated `mcp_config.json` file. ![Abstract systems illustration for Step 5: Fix the MCP Config (Critical)](/images/blog/gemini-cli-to-antigravity-cli-migration-guide-2026/inline-2.webp) **The trap:** Remote MCP servers use a different field name. You must rename `url` to `serverUrl`. If you keep `url`, the server appears to load at startup and passes initial checks. It only fails hours later when you actually invoke a tool - no error at startup, just silent failure during the session. **Before (Gemini CLI settings.json):** ```json { "mcpServers": { "myserver": { "url": "https://mcp.example.com/v1" } } } ``` **After (Antigravity CLI mcp_config.json):** ```json { "mcpServers": { "myserver": { "serverUrl": "https://mcp.example.com/v1" } } } ``` Run `agy inspect` after configuration to confirm your plugins, skills, and MCP servers loaded correctly. ## Step 6: Update CI/CD and Automation The migration script does not touch scripts, cron jobs, or CI configs that invoke the `gemini` binary directly. You must find and replace these yourself. **Audit your codebase:** ```bash grep -r "gemini" .github/workflows/ grep -r "gemini" scripts/ grep -r "^gemini " ~/.bashrc ~/.zshrc ~/.bash_profile ``` Replace all `gemini` calls with `agy`. Common locations: - GitHub Actions workflows - GitLab CI/CD pipelines - Jenkins scripts - Cron jobs - Shell aliases in dotfiles - Docker entrypoints - Makefile targets ## Known Issues at Launch **Missing ACP mode:** If you use orchestration bridges with stdio mode, there is no drop-in replacement. GitHub Issue #31 tracks this gap. Workaround: use the HTTP transport or wait for the feature. **Quota change:** The daily 1,000-request limit becomes a weekly compute-based cap. Community reports describe exhaustion after roughly 2,000 lines of generated code, with multi-day cooldowns. Plan heavy generation work accordingly. **No backward compatibility:** Even features marked as "carried forward" may have different flag names and environment variable conventions. Test everything before June 18. ## Migration Checklist Before June 18, confirm: - [ ] `agy doctor` passes - [ ] `agy inspect` shows all plugins, skills, and MCP servers - [ ] Remote MCP entries use `serverUrl` not `url` - [ ] All `gemini` binary references in CI/CD replaced with `agy` - [ ] Shell aliases updated - [ ] Heavy generation work completed or quota management understood The migration takes roughly 45 minutes for interactive setup. Auditing automation infrastructure takes longer. Start now. ## If You Miss the Deadline After June 18: - Free-tier users: no access via CLI - Pro/Ultra users: no access via CLI - Enterprise users: unchanged access You can still use Gemini models via the API with paid keys, but the CLI convenience disappears. If you need CLI access without enterprise licensing, Antigravity CLI is now the only path. ## FAQ ### Does Antigravity CLI work with Claude or GPT models? Yes. Unlike Gemini CLI which was Gemini-only, Antigravity CLI supports multiple providers including Gemini, Claude, and GPT-OSS models through the `/model` command. ### Can I keep using Gemini CLI after June 18 if I have an API key? No. The CLI itself stops serving requests. Having an API key lets you call Gemini models programmatically, but the `gemini` binary will not work. You would need to build your own tooling or use Antigravity CLI. ### What happens to my existing Gemini CLI skills? They need to move to the new directory structure. Use `git mv .gemini/skills .agents/skills` for workspace skills. The skill format itself remains compatible. ### Is there a way to test the migration before June 18? Yes. Install Antigravity CLI now and run `agy doctor` and `agy inspect`. Both tools can coexist temporarily. Validate your config migration before removing Gemini CLI. ### Why did Google give only 30 days notice? Google announced on May 19, 2026 with a June 18 deadline - roughly one sprint cycle. The reasoning was not explained in the blog post. Enterprise customers are exempt, which suggests this is a cost-reduction move for free-tier support. ### Will Gemini CLI get updates after June 18 for enterprise users? Yes, enterprise users retain access with "the latest Gemini models and other updates" according to the announcement. But community investment will shift to Antigravity CLI. ### How do I report bugs in Antigravity CLI? Use the GitHub repository at [github.com/google/antigravity-cli](https://github.com/google/antigravity-cli). The ACP mode gap is tracked as Issue #31. ### What is the weekly quota limit exactly? Google has not published specific numbers. Community reports suggest roughly 2,000 lines of generated code before throttling kicks in, with multi-day cooldown periods. Monitor your usage and plan heavy generation work accordingly.

GitHub Copilot SDK Hits GA: Embed the Copilot Agent Runtime in Your Own Apps

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Resource | URL | |----------|-----| | Copilot SDK GA changelog | [github.blog/changelog/2026-06-02-copilot-sdk-is-now-generally-available](https://github.blog/changelog/2026-06-02-copilot-sdk-is-now-generally-available/) | | Copilot SDK repository | [github.com/github/copilot-sdk](https://github.com/github/copilot-sdk) | | Copilot app announcement | [github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/) | | Model Context Protocol | [modelcontextprotocol.io](https://modelcontextprotocol.io) | ## What GitHub Shipped On June 2, 2026, alongside Microsoft Build, GitHub announced that the [Copilot SDK is now generally available](https://github.blog/changelog/2026-06-02-copilot-sdk-is-now-generally-available/). The pitch is straightforward: instead of building your own agent orchestration layer, you embed the same runtime that powers GitHub Copilot directly into your own applications, services, and developer tools, with a stable API and production support. This is the same engine GitHub uses internally. Per GitHub's own framing, the SDK "exposes the same agentic runtime that powers the Copilot app." The desktop app, the refreshed CLI, and your custom integration all sit on one foundation. That is the part worth paying attention to, because it changes what "build an agent" means for a lot of teams. If you have been following the GitHub side of the agent race, this slots in next to the work we covered in [GitHub Copilot Coding Agent and CLI](/blog/github-copilot-coding-agent-cli-2026). The coding agent was about Copilot doing autonomous work inside GitHub. The SDK is about you taking that same autonomy and pointing it at your own product. ## Six Languages, One Runtime At GA the SDK supports six officially maintained language bindings. Rust and Java are new at GA; the rest graduated from public preview. ![Abstract systems illustration for Six Languages, One Runtime](/images/blog/github-copilot-sdk-generally-available-2026/inline-1.webp) | Language | Install | |----------|---------| | Node.js / TypeScript | `npm install @github/copilot-sdk` | | Python | `pip install github-copilot-sdk` | | Go | `go get github.com/github/copilot-sdk/go` | | .NET | `dotnet add package GitHub.Copilot.SDK` | | Rust | `cargo add github-copilot-sdk` | | Java | Maven / Gradle (`com.github:copilot-sdk-java`) | The repository is [MIT licensed](https://github.com/github/copilot-sdk), which matters if you are embedding it into a commercial product. ### How it actually works under the hood The architecture is worth understanding before you commit to it, because it is not a thin HTTP wrapper around an inference API. GitHub's repo describes the data path as: ``` Your Application -> SDK Client -> JSON-RPC -> Copilot CLI (server mode) ``` The SDK is a client that talks over JSON-RPC to the Copilot CLI running in server mode. The CLI is the agent. That has two practical consequences: 1. **You inherit the CLI's first-party tools.** GitHub notes the SDK "exposes the Copilot CLI's first-party tools, similar to running the CLI with `--allow-all`." So file reads, edits, grep, and shell-style actions are available out of the box. That is powerful and also exactly the surface you need to sandbox. 2. **The Rust SDK bundles the CLI binary by default.** Other languages expect the CLI to be present. This is a real deployment detail: your container or CI runner needs the Copilot CLI available, not just a package from a registry. If your mental model was "call a chat endpoint," recalibrate. You are running a local agent process and driving it programmatically. ## A Minimal Session The shape of a basic call looks like a chat completion, which makes the on-ramp gentle. The following is illustrative of the documented client pattern rather than a verbatim quote from the reference docs, so check the [getting started guide](https://github.com/github/copilot-sdk) before you copy it into production: ```typescript import { CopilotClient } from "@github/copilot-sdk"; const client = new CopilotClient(); const response = await client.chat({ messages: [ { role: "user", content: "Add Stripe checkout to my Next.js app" }, ], }); console.log(response.content); ``` The difference from a plain model call is that "Add Stripe checkout to my Next.js app" is not answered with prose. The agent plans, reads your files, and proposes edits, using the CLI's tool surface. Streaming and multi-turn sessions are first-class, so you can wire the token stream into your own UI and keep a session alive across turns. ## What Is New at GA The preview already had sessions and streaming. GA added the pieces you need to actually ship and operate this in production. ### Custom tools and MCP You can register your own tools that the agent invokes autonomously, and you can connect to [Model Context Protocol](https://modelcontextprotocol.io) servers. You can also override built-in tools. That last point is underrated: if you do not want the agent shelling out or editing arbitrary files, you can replace `edit_file` or `grep` with your own constrained implementation. A custom tool registration looks roughly like this (again, illustrative of the pattern, confirm against the docs): ```python from github_copilot_sdk import CopilotClient, Tool def query_analytics(query: str) -> dict: """Query the analytics database.""" return {"users": 1523, "conversions": 234} analytics_tool = Tool( name="query_analytics", description="Query analytics database for metrics", parameters={ "type": "object", "properties": { "query": {"type": "string", "description": "SQL query"}, }, "required": ["query"], }, function=query_analytics, ) client = CopilotClient(tools=[analytics_tool]) ``` If you have built tools for the [OpenAI Agents SDK or Codex SDK](/blog/codex-sdk-vs-cli-github-action), the JSON-schema tool definition will feel familiar. MCP support means you can also reuse servers you already run instead of rewriting integrations per SDK. For context on which MCP servers are worth your time, see [271 MCP Servers: The Top 5 That Matter](/blog/271-mcp-servers-top-5-that-matter). ### A hook system GA introduced hooks to intercept agent behavior at defined points: pre and post tool use, session start, MCP tool calls, and permission requests. This is the governance layer. If you are putting an autonomous agent in front of your filesystem and shell, the permission-request hook is where you enforce "ask a human before deleting files" or "never touch `infra/`." Treat it as a requirement, not a nicety. ### Production plumbing GA also added the operational details that separate a demo from a service: - **OpenTelemetry tracing** with W3C trace-context propagation, so agent runs show up in the same observability stack as the rest of your services. - **Flexible authentication**: GitHub OAuth, GitHub Apps, environment tokens, and bring-your-own-key. BYOK is the notable one, because it means non-Copilot users can use the SDK with their own model keys. - **Cloud and remote sessions**, so a session can be backed by a GitHub-hosted environment or driven through a remote session URL rather than always running locally. - **Fine-grained system-prompt customization**, letting you modify specific prompt sections independently instead of replacing the whole thing. - **Slash commands and interactive prompts** now consistent across all six SDKs. ## Pricing and Access The SDK is available to all existing GitHub Copilot subscribers, "including Copilot Free for personal use, and to non-Copilot users via BYOK." In plain terms: if you already pay for Copilot, the SDK is included. If you do not, you can still use it by supplying your own model key. The SDK itself is not a separate paid product. One thing to verify against your own usage: agent runs consume Copilot capacity the same way the rest of the product does. If you are on a metered plan, autonomous tool loops can burn requests faster than interactive chat. We walked through that dynamic in the [Copilot usage-based billing guide](/blog/github-copilot-usage-based-billing-guide-2026) and the [premium requests explainer](/blog/copilot-pro-plus-premium-requests-explained-2026), and it applies double to anything you script. ## How This Compares This is not the first "agent runtime as an SDK." OpenAI shipped the [Codex SDK and the Agents SDK](/blog/codex-sdk-vs-cli-github-action) on a similar premise, and Anthropic has leaned into the [SDK-as-plumbing](/blog/anthropic-stainless-sdk-agent-plumbing) approach. The differentiator for the Copilot SDK is distribution and parity: it is the literal runtime behind a product millions of developers already use, it ships in six languages at GA, and it reuses GitHub's existing identity and billing instead of asking you to provision a new account. For shops already standardized on GitHub, that lowers the integration tax meaningfully. ![Abstract systems illustration for How This Compares](/images/blog/github-copilot-sdk-generally-available-2026/inline-2.webp) The tradeoff is the CLI dependency. Because the agent is the Copilot CLI in server mode, your deployment story includes shipping and updating that binary, not just pinning a package version. For a serverless function that wants one quick completion, that is friction. For a long-running internal tool or CI assistant, it is fine. ## Should You Use It Reach for the Copilot SDK if: - You are already a GitHub and Copilot shop and want to embed agentic coding into internal tools, CI assistants, or a customer-facing feature without building orchestration from scratch. - You need MCP, custom tools, and hook-based governance as first-class features rather than bolt-ons. - You want one runtime behind your terminal, your cloud sessions, and your own app. Be more cautious if: - You need a stateless, low-dependency call into a model. The CLI-in-server-mode architecture is heavier than a single HTTP request. - You are not on GitHub for identity and billing, in which case the BYOK path works but you lose part of the integration advantage that makes this SDK compelling. The honest summary: GA is the moment this stops being a preview toy and becomes infrastructure you can build a product on. The custom tools, MCP, hooks, OpenTelemetry, and stable API are exactly the boxes a platform team checks before adopting. Just go in clear-eyed about the runtime model. You are not calling an endpoint, you are embedding an agent. For where this fits in the broader landscape, see our [best AI coding tools of 2026](/blog/best-ai-coding-tools-2026) roundup and the [evolution of agent SDKs](/blog/agents-sdk-evolution). ## Note on Claims Install commands, supported languages, the GA feature list, the JSON-RPC architecture, and pricing in this post are drawn from GitHub's [GA changelog](https://github.blog/changelog/2026-06-02-copilot-sdk-is-now-generally-available/) and the [official repository](https://github.com/github/copilot-sdk). The code snippets are illustrative of the documented client and tool patterns and should be checked against the current SDK reference before production use.

GLM-5.2 Cost Math: When Open-Weights Coding Models Actually Save You Money

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [VentureBeat: Z.ai's open-weights GLM-5.2 beats GPT-5.5](https://venturebeat.com/technology/z-ais-open-weights-glm-5-2-beats-gpt-5-5) | Release coverage, benchmark and cost claims | | [Artificial Analysis: GLM-5.2](https://artificialanalysis.ai/models/glm-5-2) | Independent intelligence, performance, and price analysis | | [InfoWorld: GLM-5.2 coverage](https://www.infoworld.com/article/4186136/) | Release details and availability | | [Hugging Face: GLM-5.2 weights](https://huggingface.co/zai-org) | Open weights for self-hosting | The pitch for GLM-5.2 is simple enough to fit on a sticky note: a coding model that scores higher than GPT-5.5 on a real software-engineering benchmark, for roughly one-sixth of the per-token price, with the weights published openly. Released by Z.ai (formerly Zhipu AI) on June 16, 2026, it is a 753-billion-parameter mixture-of-experts model with a 1M-token context window, available on Hugging Face, through the Z.ai API, and inside 20-plus coding environments. That headline is favourable. It is also, as far as the public numbers go, true. But "cheaper per token" and "cheaper for your workload" are not the same claim, and the gap between them is where most cost decisions actually get made. This post does the math, then turns it into a decision guide. **Last verified:** June 17, 2026. ## What GLM-5.2 Actually Is - **753B parameters, mixture-of-experts.** Only a fraction of the parameters activate per token, which is how a model this large stays affordable to serve. - **1M-token context.** Wide enough for repo-scale agentic refactors and long plan-then-execute traces. Maximum output is capped around 131K tokens. - **Open weights.** Published on Hugging Face, so you can self-host on your own hardware instead of paying per token at all, if you have the GPUs and the appetite to operate it. - **Benchmark standing.** On SWE-bench Pro, which tests real-world software-engineering tasks, GLM-5.2 scored **62.1** versus GPT-5.5's **58.6**. It also ranks at or near the top of several frontend and long-horizon coding leaderboards. The benchmark lead is narrow but real, and it is on the kind of task that matters for agentic coding rather than a trivia quiz. That is the part worth taking seriously. ## The Per-Token Cost Picture Two pricing paths matter, and people routinely conflate them. ![Abstract systems illustration for The Per-Token Cost Picture](/images/blog/glm-5-2-cost-math-open-weights-coding-models/inline-1.webp) **Path 1: the Z.ai API (pay per token).** | Model | Input (per 1M tokens) | Output (per 1M tokens) | Combined | |-------|----------------------|------------------------|----------| | GLM-5.2 | ~$1.40 | ~$4.40 | ~$5.80 | | GPT-5.5 | ~$5.00 | ~$30.00 | ~$35.00 | Independent trackers list a lower median across providers serving the open weights (closer to ~$0.55 input and ~$1.85 output), because anyone can host an open-weights model and compete on price. So the "one-sixth the cost" line is roughly right at Z.ai's own list price, and the gap can widen further if you shop the open-weights hosting market. **Path 2: the GLM Coding Plan (flat monthly).** Z.ai also sells subscription tiers that bundle GLM-5.2 access for agentic coding tools: - **Lite** - roughly $3 to $10 per month depending on promotion and billing term - **Pro** - roughly $15 to $30 per month - **Max** - roughly $80 per month For steady daily coding, the flat plan is usually the cheaper and more predictable path than metering the API. The API math below is what matters for product builders and high-volume automation, where you are paying per call at scale. ## A Worked Cost-Per-Task Example Abstract per-token rates do not tell you what a workday costs. So model a concrete unit: **one agentic coding task** - the agent reads context, plans, edits a few files, and runs checks. Assume a representative task consumes **40,000 input tokens** (repo context, files, tool results) and **8,000 output tokens** (the plan plus diffs). That input-heavy ratio is typical for agentic coding, where the model reads far more than it writes. **Cost of one task:** | Model | Input cost | Output cost | Total per task | |-------|-----------|-------------|----------------| | GLM-5.2 (Z.ai API) | 40K x $1.40/1M = $0.056 | 8K x $4.40/1M = $0.035 | **~$0.091** | | GPT-5.5 | 40K x $5.00/1M = $0.200 | 8K x $30.00/1M = $0.240 | **~$0.440** | | Claude Sonnet 4.6 ($3/$15) | 40K x $3.00/1M = $0.120 | 8K x $15.00/1M = $0.120 | **~$0.240** | **Now scale to 1,000 tasks** (a busy week of agent runs, or a single large multi-agent batch job): | Model | Cost per 1,000 tasks | |-------|---------------------| | GLM-5.2 | **~$91** | | Claude Sonnet 4.6 | ~$240 | | GPT-5.5 | ~$440 | At this volume GLM-5.2 runs roughly **2.6x cheaper than Sonnet 4.6** and **4.8x cheaper than GPT-5.5** for the same unit of work. The exact multiple shifts with your input/output ratio - output-heavy workloads (long generations, verbose explanations) widen GLM-5.2's lead further, because its output rate is where the discount is largest. The catch the table hides: this assumes the cheaper model lands the task in one pass. If GLM-5.2 needs two attempts where the pricier model needs one, half of the savings evaporates. Per-token price only becomes per-task savings when quality holds, which is exactly why the SWE-bench Pro number matters: it is evidence the quality is competitive, not just the price. ## When To Use Which: A Decision Guide Price is one input. Here is the practical routing logic. ![Abstract systems illustration for When To Use Which: A Decision Guide](/images/blog/glm-5-2-cost-math-open-weights-coding-models/inline-2.webp) **Reach for GLM-5.2 when:** - You run **high-volume agentic workloads** - batch refactors, test generation, doc updates, large multi-agent fan-outs - where per-task cost dominates and tasks are well-scoped. - You want **predictable monthly spend** and a flat GLM Coding Plan beats metered frontier-model usage. - You need **open weights for control** - data residency, air-gapped deployment, or freedom from a single vendor's roadmap. Self-hosting removes per-token cost entirely if you have the hardware. - Your tasks are **input-heavy** (lots of context, modest generation), which is where the cost gap is widest. **Reach for a frontier model (GPT-5.5, Claude Opus/Sonnet) when:** - The task is **high-stakes or ambiguous** and a single extra retry costs more than the token savings - production incident response, gnarly debugging, architecture decisions. - You are already standardized on one provider's **agent harness, tools, and skills**, and the switching cost outweighs the per-token delta. - You have **data-governance concerns about routing code to a China-based API.** Independent coverage flags this; self-hosting the open weights sidesteps it, but the hosted Z.ai API is a different risk posture than a US-hosted endpoint. Read your own policy here. **The pragmatic default for most teams** is a routed setup: send the bulk of well-scoped, high-volume tasks to the cheapest model that clears your quality bar (often GLM-5.2 or another open-weights model), and escalate the hard, expensive-to-get-wrong tasks to a frontier model. That is exactly the pattern a meta-harness exists to enforce - our writeup on [Omnigent and orchestrating Claude Code, Codex, and custom agents](/blog/omnigent-meta-harness-agent-orchestration) covers how to keep that routing logic above any single tool. For the full cross-provider rate card behind these numbers, see the [June 2026 AI coding tools pricing reality check](/blog/ai-coding-tools-pricing-june-2026). ## The Honest Caveats - **One-pass success rate is the hidden variable.** A model that is 6x cheaper but needs 1.5x the attempts is only ~4x cheaper in practice. Measure tasks-to-completion on your own workload before committing. - **Self-hosting is not free.** Open weights remove token costs but add GPU, ops, and reliability costs. The break-even only favours self-hosting at sustained high volume. - **Benchmark leads are narrow and move monthly.** A 62.1 vs 58.6 gap is real today; the next frontier release can erase it. Treat the routing decision as something you re-check, not set once. - **Data governance is a real cost too.** For some teams the answer to "can code touch this API at all" is no, regardless of price. ## FAQ ### Is GLM-5.2 really cheaper than GPT-5.5? On the Z.ai API list price, yes - roughly $1.40/$4.40 per million input/output tokens versus GPT-5.5's roughly $5.00/$30.00, about one-sixth the combined per-token cost. The open-weights nature also lets other providers host it competitively, with independent trackers showing even lower medians. The savings only materialize per task if GLM-5.2 completes work in as few attempts as the pricier model. ### How much does GLM-5.2 cost per coding task? For a representative agentic task (~40K input, ~8K output tokens) on the Z.ai API, about $0.09 per task, versus roughly $0.24 on Claude Sonnet 4.6 and $0.44 on GPT-5.5. At 1,000 tasks that is about $91 vs $240 vs $440. Your actual ratio of input to output tokens will shift these numbers. ### Should I use the GLM Coding Plan or the API? For steady daily coding, the flat GLM Coding Plan (Lite, Pro, or Max tiers, roughly $3 to $80 per month depending on tier) is usually cheaper and more predictable. The per-token API math matters most for product builders and high-volume automation paying per call at scale. ### Can I self-host GLM-5.2? Yes. The weights are open and published on Hugging Face, so you can run it on your own hardware and pay no per-token cost at all. Self-hosting a 753B mixture-of-experts model requires substantial GPU capacity, so the economics only favour it at sustained high volume. ### What are the risks of using GLM-5.2? The main non-quality risk flagged in independent coverage is data governance: the hosted Z.ai API is operated by a China-based company, which some teams cannot route source code to under their own policies. Self-hosting the open weights avoids the API routing concern. As with any benchmark leader, the quality lead over frontier models is narrow and can change with the next release. ## Sources - [VentureBeat: Z.ai's open-weights GLM-5.2 beats GPT-5.5](https://venturebeat.com/technology/z-ais-open-weights-glm-5-2-beats-gpt-5-5) - verified June 17, 2026 - [Artificial Analysis: GLM-5.2 model page](https://artificialanalysis.ai/models/glm-5-2) - verified June 17, 2026 - [InfoWorld: GLM-5.2 coverage](https://www.infoworld.com/article/4186136/) - verified June 17, 2026 - [Hugging Face: Z.ai / GLM-5.2 weights](https://huggingface.co/zai-org) - verified June 17, 2026 - [Artificial Analysis: GLM-5.2 providers and per-token pricing](https://artificialanalysis.ai/models/glm-5-2/providers) - verified June 17, 2026 - [OpenRouter: GLM-5.2 endpoints and live pricing](https://openrouter.ai/z-ai/glm-5.2) - verified June 17, 2026 - [Z.ai coding plan and subscription pricing](https://z.ai/subscribe) - verified June 17, 2026 For more ways to access the model cheaply, see [where to run GLM-5.2 free and cheap](/blog/glm-5-2-free-and-cheap-access-2026) and the full [GLM-5.2 series](/series/glm-5-2).

GLM-5.2 vs DeepSeek V4 vs Qwen3: The Open-Weights Coding Model Showdown (2026)

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 17, 2026 The interesting fight in coding models is no longer open versus closed. It is open versus open. Three labs now ship weights you can download, self-host, and route to per-token at a fraction of frontier pricing, and all three post real software-engineering benchmark numbers: Z.ai's **GLM-5.2**, **DeepSeek V4**, and Alibaba's **Qwen3** line. If your question is "which open-weights model should I point my coding agent at," this is the comparison built to answer it. This piece is part of our model-economics beat. For the single-model deep dives, see our [GLM-5.2 cost math](/blog/glm-5-2-cost-math-open-weights-coding-models), our [DeepSeek V4 economics breakdown](/blog/deepseek-v4-economics-cost-quality-frontier-agentic-coding), and the [self-hosting break-even math](/blog/self-hosting-open-weights-models-break-even-math). For the layer that decides when to use which, read [model routing recipes](/blog/model-routing-recipes-cut-ai-spend) and [why the orchestration layer is the next big play](/blog/ai-model-routing-orchestration-layer). Every figure below is attributed to a primary or named source, with verification dates. Prices and benchmarks move fast on open weights because anyone can host them - verify against the live vendor page before you commit a production budget. ## A Note on Which Variant We Compare Each of these is a family, not a single model. To keep the comparison fair, we anchor on the strongest **open-weights** variant from each lab, because the whole point of this category is downloadable weights: - **GLM-5.2** - Z.ai's flagship, open weights under MIT. - **DeepSeek V4 Pro** - the flagship tier (we cover V4 Flash separately), open weights under MIT. - **Qwen3.6-35B-A3B** - Alibaba's open-weights coding MoE under Apache 2.0. Alibaba's larger Qwen3.7-Max is the stronger model on paper but is **API-only with no open weights**, so it sits outside this category; we flag it where relevant. That last point is the single most important caveat in this post: in mid-2026, Qwen's very best coding model is closed. The open-weights Qwen you can actually self-host is a much smaller MoE - which, as the numbers show, punches far above its size. ## The Contenders at a Glance | | GLM-5.2 | DeepSeek V4 Pro | Qwen3.6-35B-A3B | |---|---|---|---| | Vendor | Z.ai (Zhipu) | DeepSeek | Alibaba | | Released | Jun 16, 2026 | Apr 2026 | Apr 16, 2026 | | Total params | 753B (MoE) | 1.6T (MoE) | 35B (MoE) | | Active params | 40B | 49B | 3B | | Context window | 1M | 1M | large (VRAM-bound when self-hosted) | | Max output | ~131K | 384K | - | | License | MIT | MIT | Apache 2.0 | | Self-host class | multi-GPU server | multi-GPU server | single 24GB GPU | ![Abstract systems illustration for The Contenders at a Glance](/images/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown/inline-1.webp) Sources for this table are in the [Sources](#sources) section. The standout structural facts: DeepSeek V4 Pro is by far the largest (1.6T total), GLM-5.2 sits in the middle, and Qwen3.6-35B-A3B is two orders of magnitude smaller in total parameters and activates only **3B per token** - which is why it is the only one of the three that runs on a single consumer-class GPU. ## Benchmarks: Read the Cluster, Not the Ranking Coding benchmarks for open-weights models are reported by a mix of vendors, aggregators, and third-party evaluators using different scaffolds. Treat them as a cluster, not a leaderboard, and never compare a SWE-bench Verified number against a SWE-bench Pro number - they are different, harder tests. | Benchmark | GLM-5.2 | DeepSeek V4 Pro | Qwen3.6-35B-A3B | |---|---|---|---| | SWE-bench Verified | not separately reported | ~80.6% (V4 Pro-Max) | 73.4 | | SWE-bench Pro | 62.1 | 55.4 (unverified scaffold) | not reported | | Terminal-Bench 2.x | 81.0 (v2.1) | 67.9 (v2.0) | not reported | | AA Intelligence Index | 51 | 44 | not reported | A few honest reads of this table: - **GLM-5.2** leads the SWE-bench Pro and Terminal-Bench numbers it reports, and its [Artificial Analysis Intelligence Index of 51](https://artificialanalysis.ai/models/glm-5-2) is described as well above the median for open-weight models of similar size. Note that artificialanalysis.ai does not list a separate SWE-bench Verified figure for GLM-5.2, so we leave that cell blank rather than borrow a number from a less reliable source. - **DeepSeek V4 Pro-Max** posts the strongest SWE-bench Verified figure of the three (around 80.6%, per third-party trackers), but its SWE-bench Pro and Terminal-Bench numbers come from vendor-style scaffolds and should be treated as indicative. - **Qwen3.6-35B-A3B** scoring 73.4 on SWE-bench Verified with only **3B active parameters** is the most surprising data point in the set. It is not the top score, but on a per-active-parameter and per-watt basis nothing else here is close. The practical takeaway: on raw quality, DeepSeek V4 Pro and GLM-5.2 are frontier-substitute class, while Qwen3.6-35B-A3B is a remarkable efficiency play that trades a few points of capability for a dramatically smaller footprint. ## Pricing: The Live Page Is the Only Source of Truth Open-weights pricing is a moving target because the original lab is just one of many hosts. Here are the official first-party API list prices, verified June 17, 2026. | Model | Input ($/MTok) | Cached input ($/MTok) | Output ($/MTok) | |---|---|---|---| | GLM-5.2 (Z.ai list) | $1.40 | - | $4.40 | | GLM-5.2 (provider median) | ~$0.55 | - | ~$1.85 | | DeepSeek V4 Pro | $0.435 | $0.003625 | $0.87 | | DeepSeek V4 Flash | $0.14 | $0.0028 | $0.28 | | Qwen3.6 Plus (API) | $0.325 (35% off) | - | $1.95 (35% off) | GLM-5.2 list pricing is $1.40 / $4.40, with a provider median closer to $0.55 / $1.85 because the open weights let third parties compete on hosting ([Artificial Analysis](https://artificialanalysis.ai/models/glm-5-2)). DeepSeek's live pricing page now lists V4 Pro at **$0.435 / $0.87** with a near-free cache hit of $0.003625, and V4 Flash at $0.14 / $0.28 ([api-docs.deepseek.com/quick_start/pricing](https://api-docs.deepseek.com/quick_start/pricing), verified June 17, 2026). One important correction worth flagging: a lot of April launch coverage - and our own earlier [DeepSeek V4 economics post](/blog/deepseek-v4-economics-cost-quality-frontier-agentic-coding) - quoted V4 Pro at $1.74 / $3.48. The live DeepSeek pricing page as of June 17, 2026 lists $0.435 / $0.87, roughly a quarter of that. The live page is the source of truth; if you are modeling spend, use it, not the launch articles. Qwen3.6-35B-A3B itself is open weights, so its "price" depends entirely on who hosts it or your own hardware. The Qwen3.6 Plus API line above ($0.325 / $1.95 at a 35% promo, per [OpenRouter](https://openrouter.ai/qwen/qwen3.6-plus/benchmarks)) is included as a managed-API reference point for the Qwen family, not as the price of the 35B open-weights model specifically. ### What a Real Task Costs Per-token rates do not tell you what work costs. Model one agentic coding task: roughly 40,000 input tokens (repo context, files, tool results) and 8,000 output tokens (plan plus diffs), no caching. | Model (first-party list) | Cost per task | |---|---| | DeepSeek V4 Pro ($0.435 / $0.87) | ~$0.024 | | GLM-5.2 ($1.40 / $4.40) | ~$0.091 | | GLM-5.2 (provider median) | ~$0.037 | At list prices, DeepSeek V4 Pro is the cheapest of the high-quality options on this input-heavy profile, and its near-zero cache-hit rate makes repeated-context agent loops cheaper still. GLM-5.2 closes most of the gap if you shop the open-weights hosting market for the lower provider-median rate. The caveat that survives every pricing table: cheap per token only becomes cheap per task if the model lands the work in as few attempts as a pricier model, which is exactly why the benchmark cluster above matters. ## Context Windows and Output Limits All three flagships are built for repo-scale work. ![Abstract systems illustration for Context Windows and Output Limits](/images/blog/glm-5-2-vs-deepseek-v4-vs-qwen3-open-weights-coding-showdown/inline-2.webp) - **GLM-5.2:** 1M-token context, max output around 128K-131K depending on host ([llm-stats.com](https://llm-stats.com/models/glm-5.2)). - **DeepSeek V4 Pro and Flash:** 1M-token context, **384K max output** - the largest output ceiling of the three, and a genuine differentiator for tasks that emit huge diffs or long structured plans ([DeepSeek pricing docs](https://api-docs.deepseek.com/quick_start/pricing)). - **Qwen3 family:** the managed Qwen3.6 Plus and Qwen3.7-Max APIs advertise 1M context; the open-weights Qwen3.6-35B-A3B supports long context but useful self-hosted context length is bounded by your VRAM (see below). If your workload is "drop a whole repo in and ask for a coordinated change," any of the three handles the input side. DeepSeek's 384K output ceiling is the one to reach for when the model has to *write* a lot, not just read a lot. ## Self-Host Footprint: Where Qwen3 Wins Outright This is the category that separates "open weights in principle" from "open weights you will actually run." - **GLM-5.2 (753B / 40B active):** a multi-GPU server-class deployment. Open weights are on Hugging Face under MIT, but serving a 753B MoE means real GPU capacity and ops investment. The economics only favor self-hosting at sustained high volume - see our [break-even math](/blog/self-hosting-open-weights-models-break-even-math). - **DeepSeek V4 Pro (1.6T / 49B active):** the heaviest to self-host. The weights are open, but a 1.6T-parameter checkpoint is a serious infrastructure commitment; most teams will consume V4 via the (very cheap) API rather than host it. V4 Flash (284B / 13B active) is the more realistic self-host target in the DeepSeek family. - **Qwen3.6-35B-A3B (35B / 3B active):** runs at roughly **21GB VRAM at Q4_K_M** (about 37GB at Q8), which fits a single 24GB GPU, with reports of it running on as little as 6GB via llama.cpp at reduced speed ([Will It Run AI](https://willitrunai.com/blog/qwen-3-6-vram-requirements), [knightli.com](https://knightli.com/en/2026/05/01/qwen3-6-local-vram-quantization-table/)). This is the only model here a solo developer can realistically self-host on a workstation. If "no per-token bill, runs on hardware I already own" is your hard requirement, the decision is effectively made for you: Qwen3.6-35B-A3B is the open-weights coder that fits on a single GPU, and it is the only one of the three in that class. ## The Decision Matrix: Pick X If... **Pick GLM-5.2 if** you want the strongest reported SWE-bench Pro and Terminal-Bench numbers among true open-weights models, you are consuming it via API or a managed host, and you value an MIT license with a wide ecosystem of coding-tool integrations. It is the "best raw coding quality you can also download" pick. **Pick DeepSeek V4 Pro if** unit cost is your primary axis and you want frontier-substitute quality. At $0.435 / $0.87 with a near-free cache hit and a 384K output ceiling, it is the cheapest high-quality option for input-heavy, cache-friendly agent loops. Route to **V4 Flash** ($0.14 / $0.28) for the bounded, high-volume inner-loop steps where you do not need Pro-level reasoning. **Pick Qwen3.6-35B-A3B if** you must self-host on modest hardware, want zero per-token cost, or care about latency and data residency. Scoring 73.4 on SWE-bench Verified from a 3B-active model that fits on a 24GB GPU is the best capability-per-footprint deal in open weights right now. Choose the managed **Qwen3.7-Max** API only if you need Qwen's absolute top coding quality and can accept that it is closed-weights. **Route across all three if** you are running real volume. The honest answer for most production setups is not "pick one" but "tier them": cheap open-weights for the easy majority, a frontier-substitute for the hard reasoning, with a failover chain. That is precisely the pattern in our [model routing recipes](/blog/model-routing-recipes-cut-ai-spend), and the reason the [orchestration layer](/blog/ai-model-routing-orchestration-layer) is where the margin is moving. ## Frequently Asked Questions ### Which open-weights coding model is cheapest? At first-party API list prices verified June 17, 2026, DeepSeek V4 Pro is the cheapest high-quality option at $0.435 input / $0.87 output per million tokens, with a near-free cache-hit input price of $0.003625. DeepSeek V4 Flash is cheaper still at $0.14 / $0.28 for lighter work. GLM-5.2 lists at $1.40 / $4.40 on Z.ai but has a provider median closer to $0.55 / $1.85 because third parties host the open weights. ### Which open-weights model is best on coding benchmarks? It depends on the benchmark, and you should read them as a cluster. GLM-5.2 leads the SWE-bench Pro (62.1) and Terminal-Bench 2.1 (81.0) figures it reports. DeepSeek V4 Pro-Max posts the strongest SWE-bench Verified number of the three (around 80.6%). Qwen3.6-35B-A3B scores 73.4 on SWE-bench Verified, which is exceptional for a model with only 3B active parameters. ### Which one can I actually self-host on my own hardware? Qwen3.6-35B-A3B is the only one of the three that runs on a single consumer-class GPU - about 21GB VRAM at Q4_K_M, fitting a 24GB card. GLM-5.2 (753B) and DeepSeek V4 Pro (1.6T) require multi-GPU server-class deployments, so most teams consume them via API rather than self-host. ### Is Qwen's best coding model open weights? No. As of mid-2026, Alibaba's strongest coding model, Qwen3.7-Max, is API-only on DashScope ($2.50 / $7.50 per million tokens) with no published weights. The best Qwen you can self-host is the smaller Qwen3.6-35B-A3B under Apache 2.0. ### What licenses do these use? GLM-5.2 and DeepSeek V4 are released under the MIT license; Qwen3.6-35B-A3B is under Apache 2.0. All three permit commercial use and self-hosting. ## Sources | Source | Link | Used for | |---|---|---| | Artificial Analysis: GLM-5.2 | [artificialanalysis.ai/models/glm-5-2](https://artificialanalysis.ai/models/glm-5-2) | GLM-5.2 pricing, Intelligence Index, params, license | | llm-stats: GLM-5.2 | [llm-stats.com/models/glm-5.2](https://llm-stats.com/models/glm-5.2) | GLM-5.2 context, max output, license | | MarkTechPost: GLM-5.2 launch | [marktechpost.com](https://www.marktechpost.com/2026/06/14/z-ai-launches-glm-5-2-with-a-usable-1m-token-context-two-thinking-effort-levels-and-no-benchmarks-at-launch/) | GLM-5.2 release, context, thinking levels | | DeepSeek API pricing | [api-docs.deepseek.com/quick_start/pricing](https://api-docs.deepseek.com/quick_start/pricing) | DeepSeek V4 Pro/Flash live pricing, context, max output | | Artificial Analysis: DeepSeek V4 Pro | [artificialanalysis.ai/models/deepseek-v4-pro](https://artificialanalysis.ai/models/deepseek-v4-pro) | V4 Pro Intelligence Index | | morphllm: SWE-bench Pro leaderboard | [morphllm.com/swe-bench-pro](https://www.morphllm.com/swe-bench-pro) | SWE-bench Pro context | | morphllm: DeepSeek V4 | [morphllm.com/deepseek-v4](https://www.morphllm.com/deepseek-v4) | V4 params, context, benchmarks | | Qwen3.6-35B-A3B announcement | [qwen.ai/blog?id=qwen3.6-35b-a3b](https://qwen.ai/blog?id=qwen3.6-35b-a3b) | Qwen open-weights release, Apache 2.0 | | DEV: Qwen3.6 SWE-bench 73.4 | [dev.to](https://dev.to/purpledoubled/qwen36-scores-734-on-swe-bench-with-only-3b-active-parameters-heres-why-that-matters-2fmp) | Qwen3.6-35B-A3B SWE-bench Verified, 3B active | | OpenRouter: Qwen3.6 Plus | [openrouter.ai/qwen/qwen3.6-plus/benchmarks](https://openrouter.ai/qwen/qwen3.6-plus/benchmarks) | Qwen API pricing, context, SWE-bench | | Will It Run AI: Qwen3.6 VRAM | [willitrunai.com/blog/qwen-3-6-vram-requirements](https://willitrunai.com/blog/qwen-3-6-vram-requirements) | Qwen self-host VRAM footprint | | codersera: Qwen 3.7 Max | [codersera.com](https://codersera.com/blog/qwen-3-7-max-launch-guide-2026/) | Qwen3.7-Max closed-weights pricing, SWE-Pro | Figures verified June 17, 2026. Benchmark scores are reported by different evaluators on different scaffolds; treat them as a cluster, not an exact ranking, and re-verify against the live vendor pages before making a production decision.

Mastra npm Supply Chain Attack: 140+ AI Framework Packages Backdoored

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Socket Security disclosure](https://socket.dev/blog/mastra-npm-packages-compromised) | Technical analysis from the team that detected the attack | | [Hacker News discussion](https://news.ycombinator.com/item?id=44921876) | Community response and additional context | | [StepSecurity advisory](https://www.stepsecurity.io/blog/mastra-npm-packages-compromised-using-easy-day-js) | Mitigation guidance and persistence removal | | [SafeDep analysis](https://safedep.io/mastra-npm-scope-takeover-supply-chain-attack/) | Scope takeover mechanics | | [Mend advisory](https://www.mend.io/blog/mastra-npm-scope-takeover-easy-day-js/) | Enterprise remediation steps | **Last updated:** June 17, 2026 If you use Mastra - the TypeScript AI agent framework - check your lockfile now. On June 17, 2026, attackers compromised 140+ packages in the @mastra/* npm scope and injected a remote access trojan that steals cryptocurrency wallets, browser data, and cloud credentials. The attack was active for approximately 88 minutes before detection, but the affected package versions may still be cached in your node_modules or CI pipelines. This is not a theoretical risk. Mastra's @mastra/core package alone has over 918,000 weekly downloads. The framework is used for building AI agents that typically run in environments with access to LLM API keys, cloud provider credentials, and production databases - exactly the assets this malware targets. --- ## What Happened: The Timeline **June 16, 2026, 07:05 UTC** - npm user `sergey2016` published `easy-day-js@1.11.21`, a clean clone of the legitimate `dayjs` date library. No malicious code at this point - just a typosquat waiting to be weaponized. **June 17, 2026, 01:15-02:36 UTC** - Attackers used the compromised account `ehindero` - a legitimate former Mastra contributor whose npm scope access was never revoked - to publish 141 malicious versions across the @mastra/* namespace. Each new version added a single dependency to package.json: ```json "dependencies": { "easy-day-js": "^1.11.21" } ``` **June 17, 2026, ~02:40 UTC** - `easy-day-js` was updated to version 1.11.22 with the actual payload: a postinstall hook that downloads and executes a Node.js remote access trojan. **Within 6 minutes** - Socket's dependency analysis flagged the malicious `easy-day-js` and automatically blocked installs for protected users. **June 17, 2026** - npm pulled the malicious versions from the highest-profile packages and reverted their `latest` tags to clean versions. --- ## How the Attack Works The payload is a two-stage remote access trojan designed for persistence and data theft. ![Abstract systems illustration for How the Attack Works](/images/blog/mastra-npm-supply-chain-attack-2026/inline-1.webp) ### Stage 1: The Loader (setup.cjs) When you run `npm install` on an affected @mastra/* version, npm's postinstall hook executes `node setup.cjs --no-warnings`. This script: 1. Disables TLS certificate validation 2. Beacons to a command-and-control server at `23.254.164.92:8000` 3. Downloads the second-stage payload from `23.254.164.123:443` 4. Executes the payload as a detached background process 5. Deletes itself to remove evidence This all happens automatically during `npm install`, before you import any code. ### Stage 2: The Implant (protocal.cjs) The second stage is a 41KB cross-platform Node.js implant that: - **Installs persistence** across all operating systems: - Windows: Run registry key - macOS: LaunchAgent plist - Linux: systemd user service - **Inventories 166 cryptocurrency wallet extensions** including MetaMask, Phantom, Coinbase Wallet, and Trust Wallet - **Extracts browser history and stored data** from Chrome, Edge, and Brave - **Collects host reconnaissance** including hostname, username, installed software - **Establishes C2 tasking** for arbitrary follow-on code execution The persistence means the malware survives reboots and continues operating even after you remove the npm packages. --- ## Am I Affected? Check your lockfile for any `easy-day-js` dependency or any @mastra/* package versions published between June 17, 2026 01:15 UTC and the npm takedown. ```bash # Check for easy-day-js anywhere in your lockfile grep -r "easy-day-js" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null # Check for recent @mastra/* installs npm ls | grep "@mastra" 2>/dev/null ``` If you find `easy-day-js` in your dependency tree, assume the machine is compromised. ### High-Risk Scenarios You are at higher risk if you: - Installed or updated any @mastra/* package on June 17, 2026 - Run Mastra agents in CI/CD environments with cloud credentials - Store LLM API keys (OpenAI, Anthropic, etc.) in environment variables on affected machines - Have cryptocurrency wallet extensions installed in any browser on the affected system - Run Mastra in development environments alongside production credential access --- ## Immediate Remediation If you installed an affected version, treat the machine as compromised. This is not overcautious - the malware is specifically designed to persist and exfiltrate credentials silently. ### 1. Remove the Persistence Mechanism **macOS:** ```bash rm -f ~/Library/LaunchAgents/com.*.plist launchctl list | grep -i "com\." | xargs -I {} launchctl remove {} ``` **Linux:** ```bash rm -f ~/.config/systemd/user/*.service systemctl --user daemon-reload ``` **Windows (PowerShell as admin):** ```powershell Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "*suspicious*" ``` ### 2. Rotate All Credentials Assume exfiltration. Rotate immediately: - npm tokens: `npm token revoke` - GitHub tokens and SSH keys - Cloud provider credentials (AWS, GCP, Azure) - LLM API keys (OpenAI, Anthropic, Google AI) - Any secrets in environment variables or .env files ### 3. Check Cryptocurrency Wallets If you have any crypto wallet browser extensions installed: - Transfer funds to a new wallet generated on a clean device - Use a fresh seed phrase - do not reuse the compromised one - Assume any wallet that was active in the browser is compromised ### 4. Clean Your Node Modules ```bash rm -rf node_modules package-lock.json npm cache clean --force npm install --ignore-scripts # Install without running postinstall hooks ``` Then verify your lockfile contains no `easy-day-js` before allowing scripts to run. --- ## Prevention: Lockfile Hygiene for AI Developers This attack highlights a pattern that will keep repeating: AI agent frameworks run with elevated privileges and extensive credential access. They are high-value targets. ![Abstract systems illustration for Prevention: Lockfile Hygiene for AI Developers](/images/blog/mastra-npm-supply-chain-attack-2026/inline-2.webp) ### Install with --ignore-scripts by Default ```bash npm config set ignore-scripts true ``` This breaks some legitimate packages that need postinstall hooks (like `esbuild` or `sharp`), but it also breaks supply chain attacks. You can allowlist specific packages that genuinely need postinstall execution. ### Use Lockfile Auditing Tools like Socket, Snyk, and npm audit catch many supply chain attacks. Socket specifically flagged this attack within 6 minutes of the malicious payload going live. ### Audit Contributor Access The `ehindero` account was a former contributor whose access was never revoked. This is the most common path for scope takeover attacks. Review who has publish access to your npm packages quarterly. ### Pin Dependencies Avoid `^` and `~` ranges for critical dependencies. A pinned version in your lockfile would not have automatically pulled the malicious update. --- ## What This Means for AI Agent Security Mastra is not uniquely vulnerable - it just happened to be the target this time. Every AI agent framework that installs via npm (LangChain, Vercel AI SDK, CrewAI, etc.) has the same attack surface: postinstall hooks that run automatically during `npm install`. The uncomfortable truth is that AI agent development environments are among the most valuable targets for supply chain attacks. They typically have: - API keys for multiple LLM providers - Cloud credentials for deployment - Access to production data for testing - Long-running processes with network access If you are building AI agents, you need to treat your development environment with the same security posture as a production server. That means: - Isolated environments for untrusted dependencies - Credential rotation on a schedule, not just when incidents happen - Dependency scanning in CI that fails builds on known-malicious packages - Principle of least privilege for API keys and cloud access --- ## FAQ ### What is the Mastra npm supply chain attack? On June 17, 2026, attackers compromised 140+ npm packages in the @mastra/* scope by hijacking a dormant contributor account. They injected a dependency on a typosquatted package (easy-day-js) that downloads and executes a remote access trojan during npm install. The malware steals cryptocurrency wallets, browser data, and cloud credentials. ### How do I check if I am affected? Search your lockfile for `easy-day-js`: `grep -r "easy-day-js" package-lock.json`. If present, assume the machine is compromised. Also check for any @mastra/* packages updated on June 17, 2026. ### What credentials should I rotate? Rotate npm tokens, GitHub tokens, cloud provider credentials (AWS/GCP/Azure keys), LLM API keys (OpenAI, Anthropic), and any secrets stored in environment variables. For cryptocurrency, transfer funds to a new wallet with a fresh seed phrase generated on a clean device. ### How long was the attack active? The malicious packages were published between 01:15 and 02:36 UTC on June 17, 2026 - approximately 88 minutes. Socket detected the attack within 6 minutes of the payload activation. However, affected package versions may still exist in cached node_modules or CI artifacts. ### Is Mastra safe to use now? npm has reverted the `latest` tags to clean versions. However, you should verify your lockfile contains no `easy-day-js` dependency and that your installed versions are from before June 17, 2026 or after the npm takedown. ### How do I remove the malware persistence? The malware installs persistence mechanisms specific to each OS: LaunchAgents on macOS, systemd user services on Linux, and Run registry keys on Windows. See the remediation section above for removal commands. ### How was the contributor account compromised? The attacker used the npm account `ehindero`, described as a former Mastra contributor whose scope access was never revoked. The exact compromise method (credential reuse, phishing, etc.) has not been publicly disclosed. ### Why are AI agent frameworks targeted? AI agent frameworks run in development environments with access to LLM API keys, cloud credentials, and often production data. They are high-value targets because a single compromised package can harvest credentials for multiple cloud services, payment processors, and AI providers. --- ## Sources - [Socket Security: Mastra npm packages compromised](https://socket.dev/blog/mastra-npm-packages-compromised) - Technical disclosure, June 17, 2026 - [The Hacker News: 144 Mastra npm Packages Compromised](https://thehackernews.com/2026/06/144-mastra-npm-packages-compromised-via.html) - News coverage, June 17, 2026 - [StepSecurity: Mastra npm Packages Compromised Using easy-day-js](https://www.stepsecurity.io/blog/mastra-npm-packages-compromised-using-easy-day-js) - Advisory, June 17, 2026 - [SafeDep: Mastra npm Scope Takeover](https://safedep.io/mastra-npm-scope-takeover-supply-chain-attack/) - Analysis, June 17, 2026 - [Mend: Mastra npm Scope Takeover](https://www.mend.io/blog/mastra-npm-scope-takeover-easy-day-js/) - Enterprise guidance, June 17, 2026

Microsoft's Work IQ APIs Hit GA: What Agent Builders Actually Get on June 16

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

Most enterprise agents fail at the same place: getting grounded. An agent that needs to answer "what did my team decide about the Q3 launch" has to stitch together emails, a meeting transcript, a few chat threads, and a SharePoint doc - then trim all of it to what the current user is actually allowed to see. Today that means orchestrating dozens of raw Microsoft Graph calls and writing the permission logic yourself. Microsoft's pitch with Work IQ is that you should stop doing that. Announced at Build 2026 on June 2 and reaching general availability on **June 16, 2026**, the Work IQ APIs expose a workplace intelligence layer that pre-assembles grounded, permission-scoped context and hands it back to your agent as a ready-to-use input. **Last updated:** June 17, 2026 --- ## What Work IQ Is Microsoft describes Work IQ as "the workplace intelligence layer for agents, capturing how work actually happens across Microsoft 365, organizational systems and external sources: people, emails, documents, meetings and how they connect." The APIs give agents "programmatic access to this intelligence layer." The framing in Microsoft's own announcement is blunt about why the old approach does not work for agents: "Traditional interfaces were designed for human interaction, but agents work differently. They need richer context, simpler tool surfaces, lower latency, and enterprise controls built in from the start." ([Microsoft 365 Blog](https://www.microsoft.com/en-us/microsoft-365/blog/2026/06/02/announcing-the-new-work-iq-apis/)) So instead of your agent calling Graph and reassembling context, it calls Work IQ, which returns the digested, permission-trimmed context it needs. ## The Four Domains Per Microsoft's developer blog, the API is organized into four domains ([Microsoft 365 Developer Blog](https://devblogs.microsoft.com/microsoft365dev/work-iq-production-ready-intelligence-for-every-agent/)): ![Abstract systems illustration for The Four Domains](/images/blog/microsoft-work-iq-apis-ga-agent-grounding/inline-1.webp) - **Chat** - conversational access over agent-to-agent and REST surfaces. - **Context** - internal assembly of grounded context across organizational data. - **Tools** - 10 generic verbs that reach Microsoft 365 data, rather than hundreds of data-specific tools. - **Workspaces** - persistent storage backed by SharePoint Embedded. The "10 generic tools" detail is the one worth sitting with. Microsoft says the APIs "collapse functionality into just 10 generic tools with progressive disclosure through model context protocol (MCP), so developers do not need to teach agents hundreds of data-specific tools." Progressive disclosure means the agent discovers structure at runtime - a `getSchema` call lets agents "adapt automatically to new data and evolving scenarios without changes to the API surface." ## Three Protocols Work IQ ships across three access protocols, which is unusual breadth for a launch: - **A2A** - agent-to-agent collaboration. - **A redesigned remote MCP server** - the same MCP standard most agent frameworks already speak. - **REST API** - for direct integration. If you are already building MCP-native agents, this is the relevant hook: Work IQ is a remote MCP server you can point an existing agent at, rather than a proprietary SDK you have to adopt wholesale. ## The Permission Model This is the part that matters most for anyone shipping into a regulated org. Microsoft describes a two-layer model: broad permissions establish access boundaries, and a Rego-based policy engine enforces context-aware rules on every request - evaluating resource paths, methods, user identity, and data content. The operative line from the developer blog: "Actions are user scoped, meaning every request runs in the context of a specific user and only accesses what that user is allowed to see or do." That is the explicit answer to the oversharing problem that has dogged enterprise RAG and Copilot deployments - where an agent surfaces a document the asking user was never supposed to see. Whether the enforcement holds up in practice is something teams will need to validate against their own tenants, but the design intent is clearly to make user-scoped access the default rather than an afterthought. ## Pricing Work IQ is billed through a **consumption-based model using Copilot Credits**, a unified currency Microsoft is also extending to Copilot Studio and other AI services. Per Microsoft's materials, there is no separate Work IQ subscription, SKU, or per-user license, and billing is independent of Microsoft 365 Copilot licensing - meaning even users without a Copilot license can be billed consumptively when custom or third-party agents call the API. ![Abstract systems illustration for Pricing](/images/blog/microsoft-work-iq-apis-ga-agent-grounding/inline-2.webp) Microsoft has not published per-unit Copilot Credit rates in the launch posts, so model your costs against the consumption meter once it is live rather than assuming a flat per-seat number. ## Who Can Build With It The announcement references "developers and IT administrators" building agents, and a **public preview is already available on GitHub** ahead of the GA date, at [github.com/microsoft/work-iq](https://github.com/microsoft/work-iq). The enterprise framing runs through everything - this is built for agents operating inside an organization's Microsoft 365 tenant, not consumer apps - but access is not described as gated to a closed partner set. ## Should You Care? If you are building agents that need to reason over Microsoft 365 data - and a large share of enterprise agent projects do - Work IQ is worth evaluating now while it is in preview, before committing to a hand-rolled Graph orchestration layer you would have to maintain forever. Three honest caveats: 1. **It is a lock-in surface.** Work IQ is the connective tissue between your agent and Microsoft's data plane. Convenient, but it deepens your dependence on the Microsoft stack. 2. **Pricing is unproven.** Consumption billing through Copilot Credits is flexible but unpredictable until you can measure real workloads. Budget conservatively. 3. **Speed and security claims are vendor-stated.** Microsoft's adjacent "Web IQ" grounding stack claims "nearly 2.5x the speed of the next best alternative," and the user-scoped permission guarantees are Microsoft's own framing - verify both against your workloads and your compliance bar before you trust them in production. For teams already deep in Microsoft 365, Work IQ removes a genuinely painful chunk of plumbing. For everyone else, it is a useful signal of where agent infrastructure is heading: less raw API stitching, more pre-grounded, permission-aware context delivered through MCP. --- ## Sources - [Announcing the new Work IQ APIs - Microsoft 365 Blog](https://www.microsoft.com/en-us/microsoft-365/blog/2026/06/02/announcing-the-new-work-iq-apis/) - [Work IQ: Production-ready intelligence for every agent - Microsoft 365 Developer Blog](https://devblogs.microsoft.com/microsoft365dev/work-iq-production-ready-intelligence-for-every-agent/) - [Microsoft Build 2026: Be yourself at work - The Official Microsoft Blog](https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/) - [Work IQ public preview - github.com/microsoft/work-iq](https://github.com/microsoft/work-iq)

Model Routing Recipes: Practical Config Patterns to Cut AI Spend

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 ## Official Sources | Source | What it covers | |--------|----------------| | [OpenRouter: Model Fallbacks](https://openrouter.ai/docs/guides/routing/model-fallbacks) | The `models` array and automatic model fallback behaviour | | [OpenRouter: Provider Routing](https://openrouter.ai/docs/guides/routing/provider-selection) | `provider` block fields: `sort`, `order`, `only`, `max_price`, `allow_fallbacks` | | [OpenRouter: Prompt Caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching) | Cache-aware sticky routing and cache discount behaviour | | [LiteLLM: Fallbacks](https://docs.litellm.ai/docs/proxy/reliability) | `router_settings.fallbacks` YAML syntax and fallback types | | [LiteLLM: Auto Routing](https://docs.litellm.ai/docs/proxy/auto_routing) | Complexity-based tier routing on the proxy | | [LiteLLM: Routing](https://docs.litellm.ai/docs/routing) | Router configuration and model group behavior | | [OpenRouter: Provider Routing](https://openrouter.ai/docs/features/provider-routing) | Current provider routing concepts and provider selection controls | | [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) | Managed gateway pattern for model access, observability, and provider routing | | [Factory: Factory Router](https://factory.ai/news/factory-router) | Managed automatic routing for coding agents | If you have read our [model routing and the orchestration layer](/blog/ai-model-routing-orchestration-layer) piece, this is the hands-on companion. That post argues *why* routing is the control plane of an AI-native stack. This one is the recipe book: concrete configs you can paste, adapt, and ship. For the tool-selection layer, pair this with [LLM routers compared](/blog/llm-router-comparison-2026). For the infrastructure version, read [Models.dev model routing](/blog/models-dev-model-routing-infrastructure) and [Envoy AI Gateway](/blog/envoy-ai-gateway-llm-production-routing). ## The Core Idea in One Sentence Most requests do not need your most expensive model, so route by the cheapest model that can do the job, and only escalate when it cannot. That sounds obvious. The reason teams overspend anyway is that the default path in almost every SDK is "send everything to the one model I hardcoded." Routing is the discipline of replacing that hardcoded model with a small decision: classify the task, pick a tier, and keep a fallback in your pocket. The savings are not marginal. Sending a one-line commit-message generation request to a frontier model instead of a cheap open-weights model can cost 20 to 50 times more for output that no human can tell apart. The patterns below build up from the simplest useful thing to a full tiered gateway. ## Pattern 1: Static Fallback Chain (the floor) The lowest-effort win is a fallback chain. You name a primary model and a backup. If the primary errors out (rate limit, downtime, a moderation refusal), the request automatically retries on the next model in the list. This is reliability first, but it also lets you put a *cheaper* model as the primary and a frontier model only as the safety net. ![Abstract systems illustration for Pattern 1: Static Fallback Chain (the floor)](/images/blog/model-routing-recipes-cut-ai-spend/inline-1.webp) OpenRouter exposes this as a `models` array on the request body. It walks the list in order and returns the first success. ```bash curl https://openrouter.ai/api/v1/chat/completions \ -H "Authorization: Bearer $OPENROUTER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "models": [ "deepseek/deepseek-v4", "z-ai/glm-5.2", "anthropic/claude-sonnet-latest" ], "messages": [{"role": "user", "content": "Summarize this changelog."}] }' ``` Order matters: the list is your priority order, so put the reliable, capable floor model *last*. OpenRouter's `fallbacks` parameter (the Anthropic-SDK-compatible field) caps at 3 entries; the `models` array is the more flexible native form. ([OpenRouter docs](https://openrouter.ai/docs/guides/routing/model-fallbacks)) The LiteLLM equivalent lives in the proxy config, where fallbacks are a map from a primary model name to an ordered list of replacements: ```yaml # litellm-config.yaml model_list: - model_name: deepseek-v4 litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY - model_name: claude-sonnet litellm_params: model: anthropic/claude-sonnet-latest api_key: os.environ/ANTHROPIC_API_KEY router_settings: fallbacks: [{"deepseek-v4": ["claude-sonnet"]}] ``` LiteLLM also ships specialized fallback types using the same syntax: `context_window_fallbacks` (escalate when the input overflows the cheap model's window) and `content_policy_fallbacks` (escalate on a moderation refusal). Those two are quietly the most useful, because they catch the exact cases where a cheap model legitimately cannot finish. ([LiteLLM docs](https://docs.litellm.ai/docs/proxy/reliability)) ## Pattern 2: Tier by Task Complexity A fallback chain reacts to failure. Tiering is proactive: you decide *up front* which class of model a request deserves, so the cheap path is the default and the expensive path is a deliberate choice. The cleanest mental model is three or four named tiers, each mapped to a model: | Tier | Use for | Example model | |------|---------|---------------| | `simple` | Classification, extraction, short summaries, commit messages | an open-weights small model | | `medium` | Standard codegen, refactors, structured drafting | DeepSeek V4 / GLM-5.2 | | `complex` | Multi-step reasoning, ambiguous specs, architecture | a frontier model | | `reasoning` | Hard math, long-horizon planning, tricky debugging | a frontier reasoning model | LiteLLM's proxy supports complexity-based auto routing where you declare tiers and let the proxy score the request and pick one: ```yaml # litellm-config.yaml (tiered auto routing) router_settings: complexity_router_config: tiers: simple: glm-5.2-air medium: deepseek-v4 complex: claude-sonnet reasoning: claude-opus ``` ([LiteLLM auto routing](https://docs.litellm.ai/docs/proxy/auto_routing)) If you want full control rather than the proxy's built-in scorer, do the classification yourself with the cheapest model in your fleet, then dispatch. This is the pattern I reach for most because the routing logic is auditable and lives in your code: ```python TIERS = { "simple": "glm-5.2-air", "medium": "deepseek/deepseek-v4", "complex": "anthropic/claude-sonnet-latest", "reasoning": "anthropic/claude-opus-latest", } def classify(task: str) -> str: """Use the cheapest model to bucket the task. One token of output.""" rubric = ( "Reply with exactly one word: simple, medium, complex, or reasoning. " "simple = extraction/classification/short summary. " "medium = standard codegen or refactor. " "complex = ambiguous multi-step work. " "reasoning = hard math, planning, or subtle debugging.\n\n" f"TASK:\n{task}" ) resp = client.chat.completions.create( model=TIERS["simple"], messages=[{"role": "user", "content": rubric}], max_tokens=1, ) tier = resp.choices[0].message.content.strip().lower() return tier if tier in TIERS else "medium" # safe default def route(task: str) -> str: tier = classify(task) return client.chat.completions.create( model=TIERS[tier], messages=[{"role": "user", "content": task}], ).choices[0].message.content ``` Two things make this pay off. First, the classifier call is nearly free: one token of output from your cheapest model. Second, the *safe default* is `medium`, not `complex`. When in doubt, you spend like a workhorse, not like a flagship. A miss costs you a slightly worse answer on a cheap model, not a 30x bill, and Pattern 3 catches the genuine misroutes anyway. A cheaper variant skips the LLM classifier entirely and uses heuristics: input token count, presence of code fences, keywords like "prove", "design", or "why". Heuristics are free and surprisingly good for high-volume pipelines where even a one-token classifier call adds up. ## Pattern 3: Tier With Escalation (failover that climbs) Tiering picks a starting point. Escalation handles the case where the cheap model starts but cannot finish well. Combine the two: route to the cheap tier, validate the output, and *climb* a tier on failure rather than just retrying the same level. ```python LADDER = ["medium", "complex", "reasoning"] def is_good_enough(task: str, answer: str) -> bool: """Cheap validator: schema check, test run, or a tiny LLM judge.""" if not answer or len(answer) < 10: return False # e.g. for codegen: run the generated tests; for JSON: validate the schema return passes_local_checks(answer) def route_with_escalation(task: str, start: str = "medium") -> str: start_idx = LADDER.index(start) if start in LADDER else 0 for tier in LADDER[start_idx:]: answer = call_model(TIERS[tier], task) if is_good_enough(task, answer): return answer return answer # exhausted the ladder, return best effort ``` This is essentially what managed routers do under the hood. [Factory Router](https://factory.ai/news/factory-router) describes exactly this: it picks an efficient model for each Droid session and "moves the session to a more capable model" if the first one struggles, which Factory says cuts token spend 20 to 25 percent while holding frontier-level quality. If you do not want to build and tune the ladder yourself, a managed router buys you that escalation logic. If you do build it, the lever that matters most is your `is_good_enough` check, because a weak validator either escalates too often (no savings) or too rarely (bad output ships). ## Pattern 4: Cost-Ceiling and Provider Routing Once a model is open-weights, many providers serve it, and prices vary widely. OpenRouter lets you pin a price ceiling and a provider preference per request through a `provider` block, so you ride the cheapest qualifying host without giving up a quality floor: ```bash curl https://openrouter.ai/api/v1/chat/completions \ -H "Authorization: Bearer $OPENROUTER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "z-ai/glm-5.2", "provider": { "sort": "price", "max_price": { "prompt": 1, "completion": 3 }, "allow_fallbacks": true }, "messages": [{"role": "user", "content": "Refactor this function."}] }' ``` `sort: "price"` orders providers cheapest-first, `max_price` (in dollars per million tokens) refuses anyone over your ceiling, and `allow_fallbacks: true` keeps the request alive if your top pick is down. ([OpenRouter provider routing](https://openrouter.ai/docs/guides/routing/provider-selection)) This is the routing dimension people forget: provider failover and model fallback are two independent decisions. Provider failover steers around an outage on the *same* model; model fallback swaps to a *different* model. You usually want both. ## Pattern 5: Cache-Aware Routing (the cheapest token is the one you skip) The biggest single line item in most agentic workloads is the static prefix you resend on every turn: the system prompt plus injected workspace files. Prompt caching lets the provider keep that prefix warm so cache hits are billed at a steep discount, and on Anthropic models served through OpenRouter that can cut input cost by roughly 90 percent on a hit. ([OpenRouter prompt caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching)) ![Abstract systems illustration for Pattern 5: Cache-Aware Routing (the cheapest token is the one you skip)](/images/blog/model-routing-recipes-cut-ai-spend/inline-2.webp) The routing implication is subtle but important: caching only pays off if subsequent requests land on the *same provider* that holds the warm cache. OpenRouter handles this with sticky routing: after a cached request, it remembers which provider served you and routes follow-ups for that model back to it. The takeaway for your config is to avoid fighting that stickiness. If you aggressively re-sort providers by price on every single turn of a long agent loop, you can route away from your own warm cache and pay full price on what should have been a cache hit. For long-lived sessions, set the cache breakpoints on your stable prefix and let the gateway keep you on one provider. ```python # Anthropic-style cache_control on the stable prefix messages = [ { "role": "system", "content": [ { "type": "text", "text": LARGE_STATIC_SYSTEM_PROMPT + injected_repo_context, "cache_control": {"type": "ephemeral"}, # cache this prefix } ], }, {"role": "user", "content": turn_specific_question}, # this part varies ] ``` Pair this with our [DeepSeek cache-first agent](/blog/deepseek-reasonix-cache-first-coding-agents) notes if you are building loops where the same context is read many times. ## Putting It Together: a Reference Gateway Config Here is a single LiteLLM proxy config that combines tiered model groups, fallbacks, and a cost-conscious default. Point your app at the proxy's OpenAI-compatible endpoint and call the tier names like models. ```yaml # litellm-config.yaml - unified routing gateway model_list: - model_name: tier-simple litellm_params: model: openrouter/z-ai/glm-5.2-air api_key: os.environ/OPENROUTER_API_KEY - model_name: tier-medium litellm_params: model: openrouter/deepseek/deepseek-v4 api_key: os.environ/OPENROUTER_API_KEY - model_name: tier-complex litellm_params: model: anthropic/claude-sonnet-latest api_key: os.environ/ANTHROPIC_API_KEY - model_name: tier-reasoning litellm_params: model: anthropic/claude-opus-latest api_key: os.environ/ANTHROPIC_API_KEY router_settings: # if a tier fails, climb to the next one up fallbacks: - {"tier-simple": ["tier-medium"]} - {"tier-medium": ["tier-complex"]} - {"tier-complex": ["tier-reasoning"]} # overflowing the cheap window? jump to a wide-context model context_window_fallbacks: - {"tier-simple": ["tier-complex"]} num_retries: 2 ``` Your application code stays trivial. It asks for a tier; the gateway owns reliability, escalation, and provider selection: ```python client = OpenAI(base_url="http://localhost:4000", api_key="sk-litellm") answer = client.chat.completions.create( model="tier-simple", # start cheap; the proxy climbs if it must messages=[{"role": "user", "content": task}], ).choices[0].message.content ``` ## When to Build vs. Buy | Approach | Best when | Watch out for | |----------|-----------|---------------| | Hardcoded fallback `models` array (OpenRouter) | You want reliability today with one config line | Does not pick cheaper models proactively | | Self-classified tiers in app code | You want auditable, custom routing logic | You own the classifier and validator quality | | LiteLLM proxy with tier groups | You run many apps and want one control plane | One more service to operate and monitor | | Managed router (e.g. Factory Router) | You want escalation tuned for you | Less control; trust the vendor's quality bar | There is no single right answer. High-volume, well-understood pipelines reward custom tiering because you can tune heuristics to your exact traffic. Agentic coding tools, where task difficulty is wildly variable per session, are exactly where managed escalation earns its keep. ## The Cost Math, Briefly Routing only matters because the price spread between tiers is enormous. Our [GLM-5.2 cost math](/blog/glm-5-2-cost-math-open-weights-coding-models) and [DeepSeek V4 economics](/blog/deepseek-v4-economics-cost-quality-frontier-agentic-coding) breakdowns show open-weights coding models landing at roughly one-sixth the per-token price of frontier models for comparable coding quality on real benchmarks. If 70 percent of your traffic is genuinely "simple" or "medium" work, routing that share off the frontier is the difference between a sustainable bill and a budget blowout. Routing is a spend lever, but it is not a spend *cap*. A misrouted loop or a runaway agent can still burn money fast even on cheap models. Pair every routing config with hard ceilings, per-key budgets, and alerts as described in our [spend guardrails playbook](/blog/claude-spend-guardrails-playbook-ai-native-teams). Routing decides *which* model; guardrails decide *when to stop*. The most practical next step is not to route everything. Pick one high-volume workflow, classify its requests into simple, medium, and complex, and measure how often each tier passes local checks. Then decide whether that belongs in app code, [OpenRouter](/blog/openrouter-review-setup-2026), LiteLLM, or a managed router. ## FAQ ### What is model routing in plain terms? Model routing is the practice of choosing which AI model handles each request at runtime instead of hardcoding one model everywhere. The goal is to send cheap, simple work to cheap models and reserve expensive frontier models for the requests that genuinely need them. ### Does routing hurt output quality? Not if you tier carefully and validate. The point of complexity tiering is that simple tasks like extraction or short summaries get identical results from a cheap model. Escalation patterns (Pattern 3) catch the genuine misroutes by climbing to a stronger model when a cheap one cannot pass your quality check. ### Should I use OpenRouter, LiteLLM, or a managed router? Use OpenRouter's `models` array for the quickest reliability win, a self-hosted LiteLLM proxy when you want one auditable control plane across many apps, and a managed router like Factory Router when you want escalation logic tuned for you without building it. They are not mutually exclusive; many teams run LiteLLM in front of OpenRouter. ### How much can routing actually save? It depends entirely on your traffic mix and the price spread between tiers. Factory reports its router cuts token spend 20 to 25 percent while holding frontier quality. Teams that route a majority of simple traffic to open-weights models, which run at roughly one-sixth of frontier per-token prices, see larger swings. The savings scale with the share of work that does not need a frontier model. ### What is cache-aware routing? It is routing that keeps you on the same provider that holds your warm prompt cache. Caching the static prefix (system prompt plus injected files) can cut input costs dramatically, but only on a cache hit. If your router re-shuffles providers every turn, you route away from your own warm cache and lose the discount. Sticky routing avoids that. ## Sources - [OpenRouter model fallbacks](https://openrouter.ai/docs/guides/routing/model-fallbacks) - [OpenRouter provider selection](https://openrouter.ai/docs/guides/routing/provider-selection) - [OpenRouter prompt caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching) - [LiteLLM reliability and fallbacks](https://docs.litellm.ai/docs/proxy/reliability) - [LiteLLM auto routing](https://docs.litellm.ai/docs/proxy/auto_routing) - [LiteLLM routing](https://docs.litellm.ai/docs/routing) - [OpenRouter provider routing](https://openrouter.ai/docs/features/provider-routing) - [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) - [Factory Router](https://factory.ai/news/factory-router)

Omnigent: Databricks' Meta-Harness for Orchestrating Claude Code, Codex, and Custom Agents

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

If you run more than one coding agent, you have probably noticed the same thing: each one is its own island. Claude Code has its sessions, permissions, and skills. Codex has a separate set. Switching between them means switching mental models, re-explaining context, and re-configuring guardrails in each tool. There is no shared layer that travels with you. On June 16, 2026, Databricks open-sourced [Omnigent](https://github.com/omnigent-ai/omnigent), an Apache-2.0 project it calls a "meta-harness." The pitch in the [launch announcement](https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents) is direct: instead of replacing the agent harnesses you already use, Omnigent sits one level above them and makes them interoperable. This post covers what that actually means, the three things it does, how to install it, and whether it earns a place in your stack. **Last updated:** June 17, 2026 --- ## What a "Meta-Harness" Actually Means A harness is the runtime around a model: the loop that feeds it tools, manages context, enforces permissions, and renders output. Claude Code is a harness. Codex is a harness. Each one is, in Databricks' words, "its own silo, with its own context, its own controls." A meta-harness is a layer above those silos. Omnigent's framing is that it "lifts your work above any single harness, so your sessions, policies, and skills stay with you" rather than living inside one CLI. Practically, that means you start a session through Omnigent, and Omnigent decides which underlying harness and model actually runs the work. You can swap the harness underneath without rewriting the agent definition. That is the whole bet: the orchestration, the guardrails, and the session state belong to you, not to whichever vendor's CLI you happened to open. --- ## The Three Things Omnigent Does The [announcement](https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents) organizes the project around three capabilities. ![Abstract systems illustration for The Three Things Omnigent Does](/images/blog/omnigent-meta-harness-agent-orchestration/inline-1.webp) ### 1. Composition Omnigent lets you "combine multiple models, harnesses, and techniques without rewriting code." The supported harnesses today are Claude Code (`claude-sdk`), Codex, Pi, OpenAI Agents, and Open Responses, selectable per run with a `--harness` flag. You can point the same agent definition at a different model with `--model`, so a single YAML file can run on Claude one day and a Codex model the next. This is the part most useful to people who already maintain prompts and tool definitions for one agent and do not want to fork them for another. ### 2. Control Omnigent enforces "stateful, contextual policies" at the meta-harness layer: cost budgets, permissions, and other guardrails that apply regardless of which underlying harness runs. The argument is that a guardrail you set in Claude Code does not follow you into Codex, but a guardrail set in Omnigent applies to both because it lives above them. ### 3. Collaboration You can "share live agent sessions via URL," letting a teammate watch a running agent and steer it in real time. This is the feature most clearly aimed at teams rather than solo developers, and it leans on Omnigent's server mode, which exposes a web UI on `http://localhost:6767` by default. --- ## Installing It Omnigent is a Python CLI distributed on PyPI, with a Homebrew tap and an install script. The [quickstart](https://omnigent.ai/quickstart/install) lists the prerequisites: - Python 3.12 or newer - [`uv`](https://docs.astral.sh/uv/getting-started/installation/) (recommended) or `pip` - Node.js 22 LTS or newer with `npm` (needed for the Claude Code, Codex, and Pi harnesses, which are Node-based CLIs) - `tmux` (used by the native harness wrappers) - On Linux only, `bubblewrap` (`bwrap`) for sandboxing The cleanest install path is `uv`, which isolates the tool from your system Python: ```bash uv tool install omnigent ``` Other supported routes from the [README](https://github.com/omnigent-ai/omnigent): ```bash # Homebrew brew install omnigent-ai/tap/omnigent # pip pip install omnigent # one-line installer curl -fsSL https://omnigent.ai/install.sh | sh ``` Verify the install: ```bash omnigent --version ``` At the time of writing this returns `omnigent 0.1.1`. The project is explicitly in alpha, so expect rough edges and frequent updates (`omnigent upgrade` pulls the latest release). --- ## Connecting Your Existing Agents The setup step worth understanding is how Omnigent gets credentials. Running the wizard: ```bash omnigent setup ``` detects credentials already present on your machine. If you have the `claude` and `codex` CLIs installed and authenticated, Omnigent picks them up as subscription-backed harnesses, meaning it rides your existing Claude Pro/Max and ChatGPT logins rather than requiring separate API keys. You can confirm what it found: ```bash omnigent config list ``` A machine with both CLIs logged in and a local Ollama install shows each harness with its detected credential source: subscription via the `claude` CLI, subscription via the `codex` CLI, and a local Ollama base URL for Pi and Codex. For raw API access instead, the setup flow also accepts Anthropic, OpenAI, and gateway keys (OpenRouter, Azure, LiteLLM, vLLM), plus Databricks workspaces if you install the `omnigent[databricks]` extra. --- ## Running Something The fastest way to see orchestration work is one of the two bundled example agents. ![Abstract systems illustration for Running Something](/images/blog/omnigent-meta-harness-agent-orchestration/inline-2.webp) `debby` is a two-headed brainstorming agent that "sends every question to both Claude and GPT and lets them debate," which is a clean demonstration of composition across two vendors in a single session: ```bash omnigent debby ``` `polly` is the bundled multi-agent coding orchestrator, and it is what a bare `omnigent` launches when a Claude credential is configured: ```bash omnigent polly # or non-interactively: omnigent polly -p "review the last commit" ``` You can also launch a harness directly, skipping the orchestrator: ```bash omnigent claude # Claude Code in an Omnigent terminal omnigent codex # Codex TUI in an Omnigent terminal omnigent run --harness codex -p "explain this repo" ``` Custom agents are YAML files declaring a prompt, tools, and optional sub-agents, run with `omnigent run path/to/agent.yaml`. The full schema is in the [Agent YAML spec](https://github.com/omnigent-ai/omnigent/blob/main/docs/AGENT_YAML_SPEC.md). For the collaboration features, `omnigent server start` runs a background server and `omnigent host` registers your machine, after which the web UI at `http://localhost:6767` is the shared surface. --- ## Where It Fits, and Where It Does Not Omnigent is interesting precisely because it does not compete with Claude Code or Codex. It wraps them. That makes the decision about adopting it different from the usual tool-versus-tool comparison. It is a reasonable fit if you genuinely run multiple harnesses and feel the pain of duplicated config, or if you are on a team that wants shared session visibility and centralized cost and permission policy. The composition story is real: one agent definition that can target different models and harnesses is a maintenance win once you are past a single tool. It is harder to justify if you live entirely inside one harness. If Claude Code is your whole world, a meta-harness adds a layer, a server process, and a `tmux` dependency to abstract over a problem you do not have yet. There is also the alpha caveat: at version 0.1.1 with an Apache-2.0 license and an active [Discord](https://discord.gg/omnigent), this is early software backed by a vendor (Databricks) whose own [agent platform](https://www.databricks.com/product/artificial-intelligence) it conveniently plugs into. The honest read: Omnigent is betting that the durable thing in agentic development is not any single harness but the orchestration, policy, and session layer that spans them. That is a credible bet as more teams run more than one agent. Whether the abstraction is worth the extra moving parts depends entirely on how many islands you are currently maintaining by hand. If the answer is one, wait. If it is three, this is worth an afternoon. --- ## Sources - [Introducing Omnigent (Databricks blog)](https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents) - [omnigent-ai/omnigent on GitHub](https://github.com/omnigent-ai/omnigent) - [Omnigent install quickstart](https://omnigent.ai/quickstart/install) - [Agent YAML spec](https://github.com/omnigent-ai/omnigent/blob/main/docs/AGENT_YAML_SPEC.md)

Codex Gets Computer Use in the EU - and a Clean Claude Code Import

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 24, 2026 OpenAI shipped two Codex updates in the same week of June 2026, and together they tell you where the agentic coding tool is heading: out of the terminal and onto the desktop, and explicitly onto the turf of competing CLIs. On June 16 the Codex app gained Computer Use in the EEA, UK, and Switzerland. The day before, Codex CLI 0.140.0 added a way to import your Claude Code setup. Neither is a new model. Both are about reach. This post sticks to what shipped, with claims checked against OpenAI's Codex changelog, CLI docs, import guide, and slash-command reference. ## Official Sources | Resource | Link | |----------|------| | Codex changelog | [OpenAI Developers](https://developers.openai.com/codex/changelog) | | Codex CLI docs | [OpenAI Developers](https://developers.openai.com/codex/cli) | | Codex import guide | [OpenAI Developers](https://developers.openai.com/codex/import) | | Codex slash commands | [OpenAI Developers](https://developers.openai.com/codex/cli/slash-commands) | ## Computer Use lands in Europe The headline for June 16 is regional availability. OpenAI's Codex changelog says Computer Use became available on macOS and Windows in the EEA, UK, and Switzerland, giving Codex the ability to operate desktop apps by seeing, clicking, and typing. That matters because it moves Codex from a terminal-only loop into the same practical category as [computer-use workflows](/blog/claude-computer-use), [browser QA for agents](/blog/codex-general-purpose-ai-agent), and long-running development work where the agent needs to inspect the result rather than only edit files. Three more app features landed in the same regions on the same date: - **A Codex Chrome extension** for browser tasks, able to operate across tabs. - **Memories**, which "can remember useful preferences." The changelog notes Memories are "off by default" in these regions - a privacy-conscious default that matches the European regulatory context. - **Chronicle**, available "as an opt-in research preview" for ChatGPT Pro subscribers on macOS. The pattern is consistent: desktop control, browser control, and persistent context, all gated behind opt-in toggles. If you build for European users or work inside an EU org that blocked Codex on availability grounds, this is the update that changes your options. ## The Claude Code import is the quiet story The more interesting line for working developers shipped a day earlier, in Codex CLI 0.140.0 on June 15. The changelog describes a new `/import` command for selectively importing setup, project configuration, and recent chats from Claude Code. ![Abstract systems illustration for The Claude Code import is the quiet story](/images/blog/openai-codex-computer-use-eu-june-2026/inline-1.webp) The word that matters is **selectively**. This is not a one-shot "convert my whole config" button. OpenAI's import guide now gives the feature its own page, which is the stronger signal: migration is not a footnote anymore. It is a product surface. That is the honest way to migrate. Most of a Claude Code setup is portable. Some of it is tool-specific. A blanket import would drag the latter along. For anyone running both tools - a common setup in 2026, given how many teams keep more than one agentic CLI installed - this lowers the switching cost without pretending the two tools are identical. It also connects directly to the comparison work in [Codex vs Claude Code in June 2026](/blog/codex-vs-claude-code-june-2026), [Claude Code vs Codex app](/blog/claude-code-vs-codex-app-2026), and [Codex custom model providers](/blog/codex-custom-model-providers). The question is no longer whether teams will use one agent. The question is how much of their setup can survive moving between them. It also signals intent. OpenAI is not waiting for users to manually rebuild their workflow in Codex; it is meeting them where their config already lives. ## The rest of 0.140.0 The same release rounded out the CLI with several quality-of-life and enterprise items: - **`/usage` views** for "daily, weekly, and cumulative account token activity." Token visibility inside the CLI is a recurring ask, and it lands here. - **Managed Amazon Bedrock API-key authentication** with "encrypted local storage" - the kind of line that matters to AWS-centric teams running Codex against Bedrock-hosted models. - **A unified `@` mentions menu**: "Typing @ now opens the unified mentions menu for files, plugins, and skills by default." - **Permanent session deletion** through `codex delete` and `/delete`, shipped "with confirmation safeguards." None of these is flashy on its own. Stacked together, they are the maintenance work of a tool that expects to be used daily in production, not demoed once. The `/usage` line pairs with [Codex CLI resource budgets](/blog/codex-cli-resource-budgets). The Bedrock line pairs with [Codex custom model providers](/blog/codex-custom-model-providers). The delete command pairs with [permissions, logs, and rollback for AI coding agents](/blog/permissions-logs-rollback-ai-coding-agents). These are not separate stories. They are pieces of the same shift from "agent as chat" to "agent as operated tool." ## What this is - and what it is not It is worth being precise about scope, because mid-cycle changelog drops get over-read. ![Abstract systems illustration for What this is - and what it is not](/images/blog/openai-codex-computer-use-eu-june-2026/inline-2.webp) This is **not** a new Codex model, and nothing here changes coding quality or benchmark numbers. The June 15-16 updates are availability and tooling: a desktop and browser capability reaching new regions, plus CLI ergonomics and an import path. The Computer Use, Chrome extension, Memories, and Chronicle items are the app's existing features arriving in the EEA, UK, and Switzerland, not brand-new functionality - which is exactly why the changelog frames them as "available in these regions." If you were waiting on Computer Use in Europe, this unblocks you. If you run Codex and Claude Code side by side, `/import` is the practical win. And if you manage an AWS estate, the managed Bedrock auth line is the one to flag to your platform team. The opposing view is also fair: regional availability and import commands do not prove that Codex is better than Claude Code, Cursor, or Copilot. They only prove OpenAI is widening the surface area. Teams still need to evaluate the day-to-day loop: prompt cost, context behavior, file editing, review receipts, rollback, and whether the agent can explain what it changed. ## The takeaway The interesting move in this drop is not any single feature - it is the direction. Codex is pushing into the desktop and browser, expanding into regulated markets with privacy-first defaults, and actively lowering the cost of moving over from a competing CLI. For a tool that started as a terminal agent, that is a deliberate widening of the surface area. For deeper background on the tool itself, see our [OpenAI Codex guide](/blog/openai-codex-guide). For the broader CLI comparison, [Codex vs Claude Code in June 2026](/blog/codex-vs-claude-code-june-2026) covers how the two ecosystems differ in practice. For the longer operator pattern, read [Codex automations for recurring engineering work](/blog/codex-automations-recurring-engineering-work). ## FAQ ### Did OpenAI release a new Codex model in this update? No. This was an availability and tooling update, not a model release. The important changes were Computer Use availability in the EEA, UK, and Switzerland, plus CLI workflow improvements such as `/import`, `/usage`, and deletion commands. ### What does Codex Computer Use do? OpenAI describes Computer Use as a Codex capability for operating desktop apps by seeing, clicking, and typing. In this update, the notable change was regional availability for macOS and Windows in the EEA, UK, and Switzerland. ### What does the Codex `/import` command import from Claude Code? OpenAI's Codex changelog says `/import` can selectively import setup, project configuration, and recent chats from Claude Code. The useful word is selectively: teams should still review what crosses over instead of treating the import as a perfect conversion. ### Why does the Codex Chrome extension matter? The Chrome extension matters because it expands Codex from terminal and file work into browser tasks across tabs. For developers, that turns more frontend QA, documentation, dashboard, and app-verification work into something the agent can inspect directly. ### Should European teams enable Codex Memories by default? Not automatically. The changelog says Memories are off by default in the EEA, UK, and Switzerland. Treat that as a signal to review privacy, data-retention, and workspace policy before enabling persistent preferences for a team. ### How should teams evaluate this Codex update? Evaluate it as workflow expansion, not model quality. Test whether Computer Use, browser tasks, imports, token usage views, Bedrock auth, and deletion controls make the agent easier to operate safely inside your existing repo and review process. ## Sources - [OpenAI Codex changelog](https://developers.openai.com/codex/changelog) - [OpenAI Codex CLI docs](https://developers.openai.com/codex/cli) - [OpenAI Codex import guide](https://developers.openai.com/codex/import) - [OpenAI Codex slash commands](https://developers.openai.com/codex/cli/slash-commands)

'The Orchestration Is the Product': What Perplexity's Aravind Srinivas Sees That the Model Labs Don't

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Topic | Source | |------|--------| | Perplexity Computer: 19 models, $200/mo, launch details | [VentureBeat](https://venturebeat.com/technology/perplexity-launches-computer-ai-agent-that-coordinates-19-models-priced-at) | | "The orchestration is the product" + team analogy | [Fortune](https://fortune.com/2026/02/26/perplexity-ceo-aravind-srinivas-computer-openclaw-ai-agent/) | | "Token value per watt per user" and the winning-objective framing | [CNBC](https://www.cnbc.com/2026/06/03/perplexity-ceo-ai-valuations-computer-agentic.html), [Tekedia](https://www.tekedia.com/perplexity-ceo-aravind-srinivas-says-efficiency-will-separate-ai-winners-token-value-per-watt-per-user-becomes-the-deciding-metric/) | | Srinivas on model commoditisation and reasoning | [20VC / The Twenty Minute VC](https://www.thetwentyminutevc.com/aravind-srinivas) | There is a quiet assumption underneath most AI strategy: that value flows to whoever trains the best model. Spend the most on compute, win the benchmarks, capture the market. It is a clean story, and the labs have every incentive to keep telling it. Aravind Srinivas, Perplexity's CEO, is making the opposite bet in public. In February 2026 Perplexity shipped a product called Computer - an agent that does not try to be the smartest model in the room. It tries to be the smartest manager of other people's models. And the way Srinivas describes it amounts to a thesis the model labs have a structural hard time saying out loud: the orchestration is the product, and the model is a tool. This post takes that thesis seriously and argues it is more right than the consensus credits. It is the standalone companion to our broader argument in [why the orchestration layer is the next big play next to the labs](/blog/ai-model-routing-orchestration-layer). That piece maps the whole landscape. This one zooms in on the most committed bettor in it. ## What Perplexity actually shipped On February 25, 2026, Perplexity launched Computer, which Srinivas called the most ambitious product in the company's three-year history. The headline number is the tell: Computer coordinates **19 different models on the backend** rather than running on a single house model. Per [VentureBeat](https://venturebeat.com/technology/perplexity-launches-computer-ai-agent-that-coordinates-19-models-priced-at)'s reporting, the lineup spans Claude Opus 4.6 for orchestration and coding, Google's Gemini for deep research, Google's Nano Banana for images and Veo 3.1 for video, xAI's Grok for fast lightweight tasks, and ChatGPT 5.2 for long-context recall. Computer launched to Perplexity Max subscribers at $200 a month. Notice what that is not. It is not "we fine-tuned a model and wrapped a UI around it." It is a system whose entire reason for existing is deciding which external model handles which sub-task, and then stitching the results into one coherent piece of work. Srinivas does not even call it a router. He frames it as an orchestrator - or, in his broader public language, an "omni agent" that picks the model, coordinates multiple agents, and decides what runs locally versus in the cloud. The clearest articulation came in his [Fortune](https://fortune.com/2026/02/26/perplexity-ceo-aravind-srinivas-computer-openclaw-ai-agent/) interview, where he reached for a hiring analogy: > "When you build a team, you don't build a homogenous group where everyone has the same skills. You build a team with diverse strengths. We're applying that same logic to AI workflows. The orchestration is the product." Read that last sentence as a strategy statement, not a product description. He is telling you where he thinks the defensible value sits. ## Why a lab cannot comfortably say this The reason this thesis is interesting is not that it is clever. It is that it is structurally available to Perplexity and structurally awkward for OpenAI, Anthropic, or Google to adopt. ![Abstract systems illustration for Why a lab cannot comfortably say this](/images/blog/perplexity-orchestration-is-the-product/inline-1.webp) A frontier lab's entire capital story is that its model is the irreplaceable asset. Tens of billions in training compute only pencils out if the model is the moat. A lab that stood up and said "honestly, the model is a commodity tool and the orchestration on top is the real product" would be undercutting its own valuation narrative. So labs route to their own models by default, even when a competitor's model is better for a given sub-task, because every query that leaves their stack is a query that admits the commodity thesis. Perplexity has no such conflict. It owns no frontier model it must defend, which means it can do the thing users actually benefit from: send each sub-task to whichever lab is genuinely best at it. The 19-model lineup is only possible because Perplexity is indifferent to which lab wins any individual call. That indifference is the product. A lab cannot fake it, because its cap table will not let it. Srinivas made the commoditisation point directly on Harry Stebbings' [20VC podcast](https://www.thetwentyminutevc.com/aravind-srinivas), where the conversation centered on whether foundation models will commoditise and where the next gains in model performance actually come from. If you believe raw model quality is converging - and the open-weights cost curve we cover in our [routing recipes guide](/blog/model-routing-recipes-cut-ai-spend) suggests it is - then the marginal advantage stops living inside any one model and starts living in the layer that decides how to use all of them. ## "Token value per watt per user" The most revealing thing Srinivas has said is not the orchestration line. It is the metric he wants to be judged on. In a [CNBC](https://www.cnbc.com/2026/06/03/perplexity-ceo-ai-valuations-computer-agentic.html) interview, he argued that the company best able to maximize **"token value per watt per user"** will command the highest valuation over time. As reported by CNBC and [Tekedia](https://www.tekedia.com/perplexity-ceo-aravind-srinivas-says-efficiency-will-separate-ai-winners-token-value-per-watt-per-user-becomes-the-deciding-metric/), he framed the winning objective this way: > "Whoever is able to maximize this particular objective really will, by balancing accuracy, latency, cost, privacy and intelligence all together, they're going to win, that's what's going to win long term." Sit with the shape of that metric. It is not tokens per second. It is not benchmark score. It is not parameter count. It is useful output (token value) normalized by energy (per watt) and by person (per user). Every term in it is an orchestration variable, not a model variable: - **Accuracy** is improved by sending hard sub-tasks to the model that is actually good at them, not by forcing one model to do everything. - **Latency and cost** are won by not reaching for a frontier model when a cheaper one clears the bar - the core move in any [routing recipe](/blog/model-routing-recipes-cut-ai-spend). - **Privacy** is a decision about what runs on-device versus in the cloud, which a single model cannot make for you. - **Energy** is the constraint that makes "just use the biggest model for everything" a losing strategy at scale. A lab optimizes for the numerator of one model's capability. An orchestrator optimizes the whole ratio across many models. If Srinivas is right that the ratio is what the market eventually prices, then the orchestration layer is not a thin wrapper. It is where the optimization problem that matters actually lives. ## Routing versus orchestration, precisely It is worth being exact, because the two words get used interchangeably and they are not the same thing. **Routing** optimizes the choice within a fixed shape of work. A request comes in, a policy picks the best model for that single request, the response goes out. Factory's [Factory Router](https://factory.ai/news/factory-router) is a strong example: it scores models on cost and capability and sends each coding request to the right one. The shape of the work - one request, one answer - is held constant. We break down that cost-per-task dynamic in our piece on [Factory AI and the model routing era](/blog/factory-ai-droid-model-routing-costs). **Orchestration** optimizes the shape of the work itself. It decides how a task is decomposed into sub-tasks, how many agents run, how they hand off to each other, what executes locally versus in the cloud, and when to call a tool instead of a model at all. Routing is a subroutine inside orchestration - the part that picks a model once the shape is set. Computer is aiming at the second category. When it takes "research this company and draft a memo," it does not make one model call. It plans, dispatches deep research to one model, image or chart generation to another, drafting to a third, and reconciles the outputs. That is orchestration doing the expensive cognitive work, with routing nested inside each step. ## The defensibility case Why is this layer defensible rather than a feature a lab bolts on next quarter? ![Abstract systems illustration for The defensibility case](/images/blog/perplexity-orchestration-is-the-product/inline-2.webp) First, **neutrality is the moat.** The value of orchestrating 19 models comes precisely from being willing to pick a competitor's model when it is better. A lab can build an orchestrator, but it cannot credibly build a neutral one, because its incentives push every borderline call toward its own stack. Users notice. Perplexity's neutrality is a position labs cannot occupy without contradicting their own economics. Second, **the optimization surface is broad and operational, not just algorithmic.** Getting token value per watt per user right means continuously tuning model selection against shifting prices, new releases, latency profiles, and privacy constraints. That is a moving operational problem - exactly the kind of work that compounds into a durable product over time rather than a copyable feature. It looks a lot like the [seven orchestration patterns](/blog/seven-ai-agent-orchestration-patterns) maturing into a managed surface. Third, **the layer captures the user relationship.** Whoever owns orchestration owns the interface where work actually gets done, which means they own the data about what works, the trust, and the switching cost. The model underneath becomes interchangeable plumbing. That is the precise inversion Srinivas is betting on: the model is the tool, and the thing you actually pay for and depend on is the orchestration. None of this means the labs lose. Frontier models remain the scarce, expensive ingredient that orchestration depends on - Computer is worthless without good models to coordinate. The argument is narrower and more interesting: that a second, durable layer of value is forming adjacent to the labs, and that the labs are structurally the least able to claim it. ## What this means if you are building You do not need to ship Perplexity Computer to act on the thesis. The strategic move for a builder is the same one Srinivas made at company scale, shrunk to fit your stack: 1. **Stop defaulting to one frontier model for everything.** That default is the expensive habit. Most sub-tasks do not need your most capable model. 2. **Tier your work by difficulty,** then route the easy majority to cheaper or open-weights models and reserve the frontier model for the hard minority. Our [model routing recipes](/blog/model-routing-recipes-cut-ai-spend) has runnable-style configs for exactly this with OpenRouter, LiteLLM, and Factory Router. 3. **Treat model choice as neutral.** Pick the best model per sub-task regardless of vendor. Vendor loyalty is a cost you pay in quality and dollars. 4. **Measure your own version of the ratio.** Useful output per dollar and per second, per task type. Once you can see it, the routing decisions make themselves. The label on the bet is "orchestration is the product." The practical version is humbler and immediately actionable: the work of deciding which model does what, for which task, under which constraints, is real work that creates real value - and it is increasingly where the margin and the defensibility live. Srinivas built a $200-a-month product on that idea. You can start with a routing config. ## FAQ ### What is Perplexity Computer? Computer is an AI agent Perplexity launched in February 2026 that coordinates 19 different models on the backend - including Claude, Gemini, Grok, and ChatGPT - to complete multi-step tasks, rather than relying on a single house model. It launched to Perplexity Max subscribers at $200 a month, per [VentureBeat](https://venturebeat.com/technology/perplexity-launches-computer-ai-agent-that-coordinates-19-models-priced-at). ### What does "the orchestration is the product" mean? It is Aravind Srinivas's framing, given to [Fortune](https://fortune.com/2026/02/26/perplexity-ceo-aravind-srinivas-computer-openclaw-ai-agent/), that the defensible value in AI sits in the layer that decides which model handles which sub-task and how agents coordinate - not in any single model, which he treats as an interchangeable tool. ### What is "token value per watt per user"? It is the metric Srinivas told [CNBC](https://www.cnbc.com/2026/06/03/perplexity-ceo-ai-valuations-computer-agentic.html) he believes will determine AI winners: useful output (token value) normalized by energy (per watt) and per person (per user), balancing accuracy, latency, cost, privacy, and intelligence together. ### How is orchestration different from model routing? Routing optimizes the model choice within a fixed shape of work - one request, one answer. Orchestration optimizes the shape of the work itself: how a task is decomposed, how many agents run, what runs locally versus in the cloud, and when to call a tool instead of a model. Routing is a subroutine inside orchestration. See our [orchestration layer breakdown](/blog/ai-model-routing-orchestration-layer) for the fuller distinction.

RFC 10008: The New HTTP QUERY Method Explained

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

The IETF published RFC 10008 this month, formally standardizing a new HTTP method called QUERY. Think of it as GET with a request body - safe, idempotent, and cacheable, but without the URL length constraints. **Last updated:** June 17, 2026 ## What QUERY actually is QUERY is a new HTTP method that allows clients to send query data in the request body instead of the URL. Like GET, it is defined as safe (no side effects) and idempotent (can be retried without issues). Unlike POST, it explicitly signals that the operation will not modify server state. The RFC was authored by Julian Reschke (greenbytes GmbH), James M. Snell (Cloudflare), and Mike Bishop (Akamai), and was published as a Proposed Standard by the HTTP Working Group. Here is the core comparison: | Property | GET | QUERY | POST | |----------|-----|-------|------| | Safe | Yes | Yes | No | | Idempotent | Yes | Yes | No | | Request body | No defined semantics | Expected | Expected | | Cacheable | Yes | Yes | Limited | ## The problem it solves GET requests encode query parameters in the URL. URLs have practical length limits - around 2,000 characters is generally safe, though implementations vary. This works fine for simple queries but breaks down when you need to pass complex filter structures, large JSON payloads, or anything that does not fit in a reasonable URL. ![Abstract systems illustration for The problem it solves](/images/blog/rfc-10008-http-query-method/inline-1.webp) The workaround has been using POST. But POST does not communicate that the operation is safe. Browsers show "are you sure you want to resubmit?" warnings. Caches cannot safely store responses. Automatic retry logic hesitates because POST might create duplicate resources. GraphQL is a prominent example. GraphQL queries can be substantial - deep nested selections, multiple fragments, complex variables. Sending them as URL parameters hits limits quickly. So GraphQL uses POST, even though queries (as opposed to mutations) are inherently safe and idempotent. QUERY solves this by providing a method that: - Accepts a request body for complex query data - Is explicitly safe and idempotent - Can be cached - Signals to intermediaries that retries are safe ## What HN is saying The thread generated 105 comments with a mix of enthusiasm and pragmatic skepticism. **GraphQL came up immediately.** Multiple commenters noted that QUERY is a natural fit for GraphQL queries. One wrote: "Using QUERY for GraphQL queries (not mutations) would be a good match. These only read data, but are sometimes bigger than the url length limit." **The name confused some people.** The term "query" already appears in HTTP URLs (the query string portion). One commenter wrote: "Use the QUERY method in your http query to query search results. Do not add query parameters. I think the name is confusing." **Proxy and CDN support is the real question.** A historically-informed commenter pointed out that WebDAV's SEARCH method had similar goals two decades ago and never gained traction because intermediaries stripped bodies from unfamiliar methods. "Until gateway and CDN support is real rather than just on paper, POST with a header marking the body as part of the cache key stays the pragmatic choice." **Some developers have been doing this anyway.** One commenter admitted: "I've been sending request body along GET method for years now." The replies quickly noted why this is fragile - fetch() in browsers does not allow it, load balancers may strip the body, and caching behavior becomes unpredictable. **HTML forms sparked interest.** Commenters discussed whether browsers would add `

` support. This would eliminate the "resubmit form?" warnings when refreshing search results. A WHATWG proposal for expanding form methods exists at github.com/whatwg/html/pull/11347. **The spec itself was praised.** One commenter noted: "I don't think it's easy to write a spec that is complete and approachable like this. Really appreciate that." ## Implementation details The RFC specifies several practical requirements: **Content-Type is mandatory.** Servers must reject QUERY requests without consistent media type information, returning 400 (Bad Request) or 415 (Unsupported Media Type). **Caching uses the request body.** Response caching incorporates both the request content and metadata. Caches may normalize insignificant differences to improve hit rates. **Multiple response patterns:** - Return results directly with a Content-Location header pointing to a URI for the cached results - Return a Location header with a URI that reproduces the query via GET - Return a 303 redirect to stored results **Security consideration:** Moving query parameters from URLs to request bodies mitigates privacy risks from URL logging. However, servers should avoid putting sensitive query data into temporary URIs used in Location or Content-Location headers. ## When to use QUERY **Good fit:** - Complex search or filter operations with large parameter sets - GraphQL queries (not mutations) - Any operation that is logically safe and idempotent but exceeds URL length limits - Scenarios where you want caching and automatic retries ![Abstract systems illustration for When to use QUERY](/images/blog/rfc-10008-http-query-method/inline-2.webp) **Probably not:** - Simple queries that fit comfortably in URLs - GET still works fine - Operations that modify server state - use POST, PUT, or DELETE - Until your infrastructure (proxies, CDNs, load balancers) actually supports it ## The adoption question The RFC is now published as a Proposed Standard, but adoption depends on implementation across the stack: - **HTTP libraries** need to support the method - **Browsers** need to handle it (fetch API, form submissions) - **Proxies and CDNs** need to pass request bodies for unknown methods - **Frameworks** need routing support The WebDAV SEARCH method comparison from the HN thread is worth considering. Good ideas in HTTP specs sometimes take years to achieve widespread support, and sometimes never do. For server-side applications where you control the full stack, you can start using QUERY today. For public APIs, the pragmatic move is probably waiting until major clients and intermediaries catch up. --- ## FAQ ### What is RFC 10008? RFC 10008 is an IETF specification published in June 2026 that defines a new HTTP method called QUERY. It enables sending query data in the request body while maintaining safe and idempotent semantics like GET. ### How is QUERY different from GET? GET encodes parameters in the URL; QUERY accepts them in the request body. Both are safe and idempotent. QUERY avoids URL length limits and keeps potentially sensitive query data out of logs. ### How is QUERY different from POST? POST is neither safe nor idempotent - it may create resources or cause side effects. QUERY explicitly signals that the operation will not modify server state, enabling caching and automatic retries. ### Can I use QUERY with fetch() in JavaScript? Browser support will need to be added. As of June 2026, mainstream browsers are evaluating implementation. Check your target browsers before depending on it for web applications. ### Is QUERY good for GraphQL? Yes, QUERY is well-suited for GraphQL queries (as opposed to mutations). GraphQL queries are safe and idempotent but often exceed URL length limits when sent as GET parameters. ### When will browsers support QUERY? RFC 10008 was just published. Browser implementation timelines vary. There is an active WHATWG proposal for HTML form method="query" support at github.com/whatwg/html/issues/12594. --- ## Sources - [RFC 10008: HTTP QUERY Method](https://www.rfc-editor.org/info/rfc10008/) - IETF, June 2026 - [Hacker News discussion](https://news.ycombinator.com/item?id=48568502) - 105+ comments, accessed June 17, 2026 - [WHATWG HTML form methods proposal](https://github.com/whatwg/html/issues/12594) - GitHub

Self-Hosting Open-Weights Models: The Real Break-Even Math

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

## Official Sources | Source | What it covers | |--------|----------------| | [CloudZero: H100 GPU cost in 2026 - buy, rent, cloud](https://www.cloudzero.com/blog/h100-gpu-cost/) | H100 purchase and rental pricing | | [IntuitionLabs: H100 rental prices across 15+ providers](https://intuitionlabs.ai/articles/h100-rental-prices-cloud-comparison) | Per-hour rental comparison | | [Spheron: GPU cloud pricing comparison 2026](https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/) | Cross-provider hourly rates | | [DeepSeek V3/R1 671B throughput benchmarks on 8xH100](https://github.com/dzhsurf/deepseek-v3-r1-deploy-and-benchmarks) | vLLM aggregate and single-stream tokens/sec | | [DeepSeek API pricing](https://deepseek.ai/pricing) | V4 Pro and Flash per-token rates | | [PricePerToken: Llama 4 Maverick (Fireworks/Together)](https://pricepertoken.com/pricing-page/model/meta-llama-llama-4-maverick) | Hosted open-weights API pricing | The pitch for self-hosting open-weights models is seductive and a little misleading. The weights are free. You download GLM-5.2, DeepSeek V4, or Llama, point a server at your own GPUs, and stop paying anyone per token forever. No vendor lock-in, no rate limits, no surprise invoice. The weights are free. The inference is not. The honest question is never "is self-hosting cheaper than the API" - it is "at what volume, at what utilization, with whose ops time, does running your own GPU beat paying per token." That crossover exists, it is computable, and for most teams it sits much higher than the marketing implies. This post does the math both ways. It is not an argument for self-hosting. It is an argument for knowing your break-even before you buy a GPU. **Last verified:** June 17, 2026. ## The Two Cost Models You Are Comparing **Per-token API.** You pay a published rate per million input and output tokens. Cost scales linearly with usage, starts at zero, and includes every hidden thing - the GPUs, the ops team, the idle capacity, the redundancy - baked into the price. Predictable per unit, unbounded in total. **Self-hosting.** You pay for compute by the hour (rented) or up front (owned), whether or not a single token flows through it. Cost is dominated by a fixed block of capacity. The marginal cost per token approaches zero, but only if you keep that capacity busy. Cheap per unit at high utilization, brutally expensive per unit when idle. The entire decision turns on one number that the per-token model hides from you and self-hosting exposes mercilessly: **utilization**. An idle GPU is the most expensive way to run a model that exists. ## What the GPUs Actually Cost **Renting (on-demand, per GPU-hour), mid-2026:** ![Abstract systems illustration for What the GPUs Actually Cost](/images/blog/self-hosting-open-weights-models-break-even-math/inline-1.webp) | GPU | Representative on-demand rate | Notes | |-----|------------------------------|-------| | H100 80GB | ~$2.00 to $3.00/hr | Median across neoclouds ~$2.29 to $3.12; hyperscalers run $2 to $8+, Vast.ai marketplace ~$1.87 ([IntuitionLabs](https://intuitionlabs.ai/articles/h100-rental-prices-cloud-comparison), [Spheron](https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/)) | | H200 141GB | ~$4.39/hr | RunPod on-demand; more memory headroom for large MoE weights ([Spheron](https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/)) | | RTX 4090 / 5090 | ~$0.35 to $1.00/hr | Consumer cards on marketplaces; spot/interruptible can drop lower with risk ([Spheron](https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/)) | A full 8xH100 node, the unit you need to serve a frontier-class MoE model with real concurrency, therefore lands around **$16 to $24 per hour** on-demand from a neocloud, which is roughly **$11,500 to $17,500 per month** if you leave it running 24/7. Reserved and committed contracts cut that meaningfully, but they also lock you into the fixed cost whether you use it or not. **Owning (street price, mid-2026):** | Hardware | Approximate price | Power draw | |----------|-------------------|-----------| | H100 80GB | ~$25,000 to $30,000 per card ([CloudZero](https://www.cloudzero.com/blog/h100-gpu-cost/)) | ~700W | | RTX 5090 | ~$2,000 | ~575W ([Yahoo Tech](https://tech.yahoo.com/computing/articles/rtx-5090-reportedly-require-600-190033538.html)) | | RTX 4090 | ~$1,600 | ~450W | An 8xH100 HGX node is a **$200,000 to $250,000** capital purchase before you add the chassis, networking, cooling, and a rack to put it in. At ~700W per card plus overhead, eight cards pull on the order of 6 to 8 kW under load - call it $700 to $1,200 a month in electricity alone at typical commercial rates, before you account for cooling and the power-usage overhead of the facility. Ownership only makes sense at high, sustained utilization over a multi-year horizon, and it converts a usage problem into a depreciation-and-datacenter problem. ## What the GPUs Actually Produce This is the number everyone skips, and it is the one that breaks most self-hosting business cases. Throughput is not a single figure. It splits into two: - **Single-stream throughput** - how fast one request generates tokens. For a 671B-class MoE model on an 8xH100 node, published vLLM benchmarks put this around **33 output tokens/sec** ([DeepSeek 671B benchmark](https://github.com/dzhsurf/deepseek-v3-r1-deploy-and-benchmarks)). - **Aggregate batched throughput** - total tokens/sec across all concurrent requests. The same benchmark peaks around **3,000 total tokens/sec** (roughly **620 output tokens/sec**) at about 100 concurrent requests, using 4-bit quantization on 8xH100. The gap between 33 and 620 output tokens/sec is the whole game. **You only hit the high number if you keep ~100 requests in flight at once.** Serve one user at a time and your expensive node delivers single-stream throughput while costing you the full hourly rate. The per-token economics of self-hosting are entirely a function of batch fullness. So the realistic capacity of an 8xH100 node at healthy batching is on the order of **620 output tokens/sec sustained**, or about **1.6 billion output tokens per month** if you run it flat-out 24/7 at full batch. Real workloads never sustain full batch around the clock, which is exactly where utilization assumptions enter. ## The API Side of the Ledger The prices you are trying to beat, per 1M tokens, mid-2026: | Model (hosted API) | Input | Output | Source | |--------------------|-------|--------|--------| | GLM-5.2 (Z.ai) | ~$1.40 | ~$4.40 | [GLM-5.2 cost math](/blog/glm-5-2-cost-math-open-weights-coding-models) | | DeepSeek V4 Pro | ~$0.435 | ~$0.87 | [DeepSeek pricing](https://api-docs.deepseek.com/quick_start/pricing) | | DeepSeek V4 Flash | ~$0.14 | ~$0.28 | [DeepSeek pricing](https://api-docs.deepseek.com/quick_start/pricing) | | Llama 4 Maverick (Fireworks) | ~$0.22 | ~$0.88 | [PricePerToken](https://pricepertoken.com/pricing-page/model/meta-llama-llama-4-maverick) | Note the spread. The same open weights that you would self-host are also sold by competing providers who already solved batching at scale, bought their GPUs at volume, and amortize ops across thousands of tenants. That is why a model like Llama 4 Maverick or DeepSeek V4 Flash can be served for cents - **the hosted API for an open-weights model is often the cheapest way to run that exact model**, because someone else is carrying your utilization risk. ## The Worked Break-Even Let us make it concrete. Suppose your workload is dominated by output tokens (agentic coding, long generations) and you are choosing between self-hosting a 671B-class MoE model on a rented 8xH100 node versus paying DeepSeek V4 Pro's API at ~$0.87 per 1M output tokens. **Self-hosting cost (rented):** - 8xH100 on-demand: ~$20/hr midpoint, running 24/7 = ~$14,400/month - Add ops, monitoring, and a slice of an engineer (more on this below): call the all-in fixed cost ~$16,000/month for the clean comparison **Capacity at different utilization:** | Avg batch utilization | Effective output tokens/sec | Output tokens/month | Self-host cost per 1M output tokens | |-----------------------|----------------------------|---------------------|-------------------------------------| | 100% (full batch, 24/7) | 620 | ~1.6B | ~$10 | | 50% | 310 | ~800M | ~$20 | | 20% | 124 | ~320M | ~$50 | | 5% (one or two users) | 31 | ~80M | ~$200 | Set that against the API at **$0.87 per 1M output tokens**, and the result is brutal: **even at 100% batch utilization 24/7, this self-hosted node costs ~$10 per 1M output tokens - more than 11x the API price.** The reason is not that your math is wrong. It is that the API provider runs the same hardware at scale you cannot match, buys GPUs cheaper, and packs the batch fuller across many customers. To beat $0.87/1M on rented hardware you would need to either drive utilization past what a single tenant can sustain, negotiate reserved pricing far below on-demand, or be serving a model where the API markup is much fatter than DeepSeek's - and DeepSeek's is famously thin. **Where self-hosting actually wins:** flip the comparison against an expensive frontier API. If the alternative is a closed model at, say, $15 to $30 per 1M output tokens, then a self-hosted open-weights node at $10 to $20/1M (high utilization) crosses into the black. The break-even is not "self-hosting vs the API" in the abstract - it is "self-hosting an open-weights model vs paying premium frontier rates for comparable quality, at volume high enough to keep the node busy." That is a real and growing scenario, which is exactly why the [orchestration and routing layer](/blog/ai-model-routing-orchestration-layer) has become the place the margin moves to. **The rough rule of thumb:** self-hosting starts to pencil out only when (a) your sustained volume reliably fills the batch, (b) the API you are replacing is a premium-priced model rather than a cheap open-weights host, and (c) you can amortize the ops cost across that volume. Miss any one and the API wins. ## The Hidden Ops Bill The clean comparison above already understates self-hosting, because the fixed cost is never just the GPU rental. The line items that do not appear on the GPU invoice: ![Abstract systems illustration for The Hidden Ops Bill](/images/blog/self-hosting-open-weights-models-break-even-math/inline-2.webp) - **Ops time.** Someone serves the model, patches the inference stack (vLLM and SGLang move fast), tunes batching and quantization, handles OOMs and node failures, and gets paged at 3am. A fractional senior engineer is easily $5,000 to $15,000/month of loaded cost, and it does not scale down when traffic is light. - **Idle GPU.** The single most expensive failure mode. A node provisioned for peak that sits at 10% average utilization is paying full price for a tenth of the output. The API charges you nothing for the troughs. - **Redundancy and scaling.** One node is a single point of failure. Real production wants headroom for spikes and a fallback, which means provisioning above average demand - structurally guaranteeing idle capacity. - **Cold starts and model swaps.** Loading 600B+ weights takes minutes and gigabytes of transfer. If you serve multiple models or scale to zero, you eat that latency and that bandwidth. - **Quantization quality risk.** The throughput numbers that make self-hosting look good usually assume 4-bit weights. That is a quality tradeoff you are now responsible for measuring, not the provider. None of these are hypothetical. They are the difference between the spreadsheet break-even and the real one, and they all push the crossover point higher. ## When Self-Hosting Actually Makes Sense It is not never. The honest cases: - **High, steady, batch-filling volume** of a model whose hosted API carries a fat markup or whose quality you need at frontier-replacing scale. - **Data residency or compliance** that forbids sending tokens to a third party at any price. Here the comparison is not cost, it is permission. - **Latency or determinism** requirements that a shared multi-tenant API cannot guarantee. - **Research and experimentation** where you need to modify the model, not just call it. - **You already own the GPUs** for another reason and the marginal cost of inference on spare capacity is close to free. For everyone else - which is most teams, most of the time - the right move is the boring one: **use the hosted open-weights API**, route cheap traffic to cheap models, and reserve self-hosting for the narrow band where the math truly closes. ## How to Actually Decide 1. **Measure your real token volume**, split into input and output, over a representative month. Output tokens dominate cost for generative workloads. 2. **Price it on three or four hosted APIs**, including the cheap open-weights hosts, not just the frontier model you default to. The [routing recipes](/blog/model-routing-recipes-cut-ai-spend) here are usually the fastest win. 3. **Estimate your honest batch utilization**, not your peak. If you cannot keep ~50 to 100 requests in flight most of the time, self-hosting math will not close. 4. **Add the ops bill** - engineer time, redundancy, idle headroom - to the GPU cost before comparing. 5. **Only then** compute self-host cost per token at your real utilization and set it against the API. If it is not at least 2x cheaper, the API wins on a risk-adjusted basis alone. And whichever side you land on, [put spend guardrails in place](/blog/claude-spend-guardrails-playbook-ai-native-teams). Self-hosting caps your token cost but uncaps your ops and idle cost. The API uncaps your token cost but caps everything else. Both can run away from you without controls. ## FAQ ### Is self-hosting open-weights models always cheaper than the API? No. For most teams it is more expensive once you account for utilization and ops. A hosted API for an open-weights model is often the cheapest option because the provider keeps the batch full at a scale a single tenant cannot match. Self-hosting wins mainly when you have high, steady, batch-filling volume replacing a premium-priced frontier model, or when compliance and latency requirements override cost. ### What is the break-even volume for self-hosting? There is no universal number - it depends on your batch utilization and which API you are replacing. As a rule of thumb, self-hosting only pencils out when you can keep roughly 50 to 100 concurrent requests in flight most of the time and the API you are replacing is a premium model priced well above cheap open-weights hosts like DeepSeek V4 Flash or Llama 4 Maverick. ### How much throughput does an 8xH100 node deliver? For a 671B-class MoE model on 8xH100 with vLLM, published benchmarks show roughly 33 output tokens/sec for a single request, rising to about 620 output tokens/sec aggregate (around 3,000 total tokens/sec including input) at about 100 concurrent requests using 4-bit quantization. You only get the high number at high concurrency. ### What does it cost to rent versus buy an H100? In mid-2026, an H100 rents for roughly $2 to $3 per GPU-hour on-demand from neoclouds, and costs roughly $25,000 to $30,000 to buy. An 8xH100 node is around $11,500 to $17,500/month rented 24/7, or a $200,000+ capital purchase plus power (each card draws ~700W) and datacenter costs to own. ### Why is the hosted API for an open-weights model often cheapest? Because the same open weights are served by multiple competing providers who bought GPUs at volume, solved high-utilization batching at scale, and amortize ops across thousands of tenants. They carry the utilization risk for you, which is why models like DeepSeek V4 Flash (~$0.14/$0.28 per 1M tokens) or Llama 4 Maverick (~$0.22/$0.88) sell for cents per million tokens.

Vercel eve: The Framework for Building AI Agents

Developers Digest — Wed, 17 Jun 2026 00:00:00 GMT

**Last updated:** June 22, 2026 | Official Sources | | |---|---| | [eve Documentation](https://vercel.com/docs/eve) | Framework reference, agent structure, tools, skills, channels | | [Introducing eve - Vercel Blog](https://vercel.com/blog/introducing-eve) | Launch announcement, architecture, use cases | | [vercel/eve on GitHub](https://github.com/vercel/eve) | Source code, examples, issues | | [Vercel Ship 26 Changelog](https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework) | Release notes, version info | | [AI Gateway - Vercel Docs](https://vercel.com/docs/ai-gateway) | Model routing, provider fallbacks | ## A framework where the agent is just a folder On June 17, 2026, at Vercel Ship in London, [Vercel introduced eve](https://vercel.com/blog/introducing-eve), an open-source framework for building, running, and scaling AI agents in production. The pitch is the kind of thing that sounds glib until you actually use it: eve is "Next.js for agents." The framing is earned. Vercel's argument in the [launch post](https://vercel.com/blog/introducing-eve) is that "agents today are where the web was before frameworks, with everyone hand-rolling the same plumbing and nothing carrying over to the next one." Anyone who has shipped an agent knows that feeling. You start with a model call and a loop, and within a week you are hand-building session persistence, a sandbox, an approval gate, a way to test the thing, and a queue so it survives a redeploy. None of it is novel, and none of it carries to your next agent. eve is the foundation that ends the rebuilding. ## Filesystem-first: define an agent with files eve is filesystem-first. You define each agent with files under an `agent/` directory, eve discovers those files, and compiles them into an app that runs on [Vercel Functions](https://vercel.com/docs/functions). If you have built a Next.js app, the mental model transfers directly: the file tree is the configuration, and the conventions do the wiring. ![Abstract systems illustration for Filesystem-first: define an agent with files](/images/blog/vercel-eve-framework-for-building-ai-agents/inline-1.webp) The conventional layout looks like this, per the [eve docs](https://vercel.com/docs/eve): ``` my-agent/ └── agent/ ├── agent.ts # Model and runtime config ├── instructions.md # System prompt ├── tools/ # Typed functions, one tool per file ├── skills/ # On-demand procedures loaded when relevant ├── channels/ # Message integrations └── schedules/ # Cron jobs ``` A minimal agent is genuinely two files. First, `agent/instructions.md` is the system prompt in plain Markdown: ```md You are a concise assistant. Use tools when they are available. ``` And `agent/agent.ts` is the runtime config: ```ts import { defineAgent } from 'eve'; export default defineAgent({ model: 'openai/gpt-5.4-mini', }); ``` That model string is resolved through Vercel's [AI Gateway](https://vercel.com/docs/ai-gateway), so on Vercel you authenticate with OIDC and do not manage provider API keys. You can swap `openai/gpt-5.4-mini` for `anthropic/claude-sonnet-4.6` (or any other gateway-supported model) by editing one line. ## Adding a tool is adding a file Each file in `agent/tools/` is one tool. The runtime tool name comes from the filename, so the model just sees `get_weather`. Create `agent/tools/get_weather.ts`: ```ts import { defineTool } from 'eve/tools'; import { z } from 'zod'; export default defineTool({ description: 'Get the current weather for a city.', inputSchema: z.object({ city: z.string(), }), async execute(input) { return { city: input.city, condition: 'Sunny', temperatureF: 72 }; }, }); ``` There is no registration step, no central manifest, no array you have to remember to update. You drop a file in `tools/`, eve discovers it, and the model can call it. This is the part that makes the "Next.js for agents" claim land: the convention is the API. ## Getting started The fastest path is the eve CLI. It scaffolds a project, installs dependencies, initializes Git, and starts the dev server: ```bash npx eve@latest init my-agent ``` To add eve to an existing app instead: ```bash npm install eve@latest ``` Then run the agent locally: ```bash pnpm dev ``` ## Durable sessions you can stream Agents are long-running by nature, and eve treats sessions as durable rather than ephemeral. Sessions checkpoint each step and survive crashes, cold starts, deploys, and long pauses, which eve gets from [Vercel Workflow](https://vercel.com/docs/workflows) persisting session state under the hood. You start a durable session over HTTP and stream its output: ```bash curl -X POST http://127.0.0.1:3000/eve/v1/session \ -H 'content-type: application/json' \ -d '{"message":"What is the weather in Brooklyn?"}' ``` The response returns a `continuationToken` in the body and an `x-eve-session-id` header. You attach to the session stream to receive NDJSON lifecycle events: ```bash curl http://127.0.0.1:3000/eve/v1/session//stream ``` The durability matters more than it sounds. The single most annoying class of agent bug is the one where a deploy or a timeout kills a half-finished run and you have no clean way to resume it. eve's checkpoint-per-step model means a session that was midway through a five-step task picks back up instead of starting over. ## Production is built in, not bolted on The reason eve is more than a nicer wrapper around a model call is that the production concerns ship in the framework: ![Abstract systems illustration for Production is built in, not bolted on](/images/blog/vercel-eve-framework-for-building-ai-agents/inline-2.webp) - **Durable execution.** Sessions checkpoint each step and resume after crashes, deploys, or long pauses, backed by [Vercel Workflow](https://vercel.com/docs/workflows). - **Sandboxed compute.** Agent-generated code runs isolated from your application runtime via [Vercel Sandbox](https://vercel.com/docs/sandbox), so an agent writing and executing code cannot reach into your app. - **Human-in-the-loop approvals.** Actions can require manual authorization before they proceed, so the high-stakes step waits for a person. - **Subagents.** A parent agent can delegate work to child agents with isolated contexts, which keeps the parent's context window clean and lets you compose specialists. - **Evals.** Scored test suites verify agent behavior locally or in CI, so you can catch a regression in a prompt or tool the same way you catch one in code. Routing through [AI Gateway](https://vercel.com/docs/ai-gateway) for model calls and provider fallbacks, and [Vercel Connect](https://vercel.com/docs/connect) for OAuth tokens and external-service credentials, rounds out the stack. And because everything runs on Vercel Functions, you get [Vercel Observability](https://vercel.com/docs/observability) over agent runs, token usage, and performance with no extra setup. This is not a hypothetical list of features. Vercel says it runs more than 100 production agents on eve, including a data analyst that handles 30,000-plus questions a month, an autonomous SDR, and a support handler that resolves 92% of tickets on its own. eve is the framework Vercel built for itself and then open-sourced. ## Where it sits in the stack eve is the newest layer of [Vercel's agentic infrastructure stack](/blog/vercel-agentic-infrastructure-stack). It builds on the [durable execution programming model](/blog/vercel-durable-execution-programming-model) Vercel has been shipping, leans on the [AI SDK](/blog/vercel-ai-sdk-guide) ecosystem, and gives the file-tree-as-config treatment to the kind of [multi-step agent workflows](/blog/agent-architecture-multi-step-ai-workflows) developers have been assembling by hand. If you have weighed the [tradeoffs between the Vercel AI SDK and other agent stacks](/blog/langchain-vs-vercel-ai-sdk), eve is Vercel's answer to "what should the opinionated, batteries-included version look like." ## The honest caveat eve launched as a public preview and is currently in beta. The framework, APIs, documentation, and behavior may change before general availability, and it deploys natively to Vercel today with other platforms described as coming soon. If you are putting a critical agent into production this week, treat the API surface as something that can shift under you. That caveat aside, eve is the most coherent answer yet to a problem every agent builder hits: the plumbing is the same every time, so it should not be your code. Defining an agent as a directory of files, with durability, sandboxing, approvals, subagents, and evals already wired in, is exactly the abstraction the category has been missing. It is the framework moment for agents, and it is worth a `npx eve@latest init` this afternoon. ## Sources - [Introducing eve - Vercel blog](https://vercel.com/blog/introducing-eve) - [Introducing eve, an open-source agent framework - Vercel changelog](https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework) - [eve documentation - Vercel docs](https://vercel.com/docs/eve) - [vercel/eve on GitHub](https://github.com/vercel/eve)

Open Design: Turn Websites into Design Assets for Cursor & Claude Code

Tue, 16 Jun 2026 12:00:34 GMT

Open Design: Open-Source n8n App That Turns Any Website into a Brand Kit, Design System, HTML + Images The video introduces Open Design, an MIT-licensed full-stack template that combines AI and n8n a...

Cursor Automations Developer Guide: Always-On AI Coding Agents

Developers Digest — Mon, 15 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Cursor Documentation | [docs.cursor.com](https://docs.cursor.com) | | Cursor Pricing | [cursor.com/pricing](https://cursor.com/pricing) | | Cursor Changelog | [cursor.com/changelog](https://cursor.com/changelog) | | Cursor Automations Launch | [creati.ai/ai-news/2026-03-08/cursor-automations-agentic-coding-system-launch](https://creati.ai/ai-news/2026-03-08/cursor-automations-agentic-coding-system-launch/) | **Last updated:** June 15, 2026 Cursor Automations shipped in March 2026 and changed how AI coding agents fit into development workflows. Instead of waiting for you to prompt them, automations let agents run in the background based on triggers: test failures, file saves, PR opens, cron schedules, or webhook calls. The shift is from interactive AI to always-on AI. Teams using automations report 20-40% reductions in manual review tasks and 1-2 hours recovered per developer weekly. Here is how to set them up. --- ## What Automations Actually Do Traditional AI coding assistants are reactive. You ask a question, they answer. You prompt a refactor, they generate code. The loop requires you to be present and typing. Automations flip this. You define a trigger and instructions once. The agent runs whenever that trigger fires, whether you are at your desk or not. Results queue up for review. The practical difference: | Traditional AI | Automations | |----------------|-------------| | Manual prompts | Automatic triggers | | Synchronous chat | Asynchronous background | | Developer as operator | Developer as reviewer | | Single file context | Full repository scope | Jonas Nelle, Cursor's engineering lead for async agents, described it as a "conveyor belt" for development: "Humans are not completely out of the picture. Instead, they are not always initiating. They're called in at the right points." --- ## Setting Up Your First Automation Automations are configured via YAML files in your project's `.cursor/automations/` directory, or through Cursor's settings panel. ### Directory Structure ``` my-project/ .cursor/ automations/ fix-tests.yaml dependency-audit.yaml pr-review.yaml ``` ### Basic Configuration Every automation needs three things: a name, a trigger, and instructions. ```yaml name: Fix Failing Tests trigger: - type: test_failure test_command: pnpm test debounce_ms: 5000 instructions: | Review failing tests and source code. Identify root cause and propose minimal fix without modifying test expectations. Run tests in sandbox to verify before submitting diff. sandbox: install_command: pnpm install env: NODE_ENV: test ``` When your test suite fails, this automation spawns an isolated container, clones your repo, runs the agent with your instructions, and stages a diff for your review. --- ## Trigger Types Cursor supports six trigger types. Each fits different workflow patterns. ### 1. Cron Schedule Standard cron syntax for recurring tasks. ```yaml name: Weekly Dependency Audit trigger: - type: cron schedule: "0 9 * * 1" # Monday 9am instructions: | Run npm audit. For vulnerabilities with severity high or critical, check if patch versions are available. Apply patches and run tests. Skip major version bumps. ``` Good for: dependency updates, dead code detection, documentation sync, weekly summaries. ### 2. Git Events Triggered on push, commit, PR open, PR merge, or branch creation. ```yaml name: PR Security Review trigger: - type: git event: pull_request_open instructions: | Review the PR diff for security issues. Check for: - Hardcoded credentials or API keys - SQL injection vectors - Unvalidated user input - Missing authentication checks Post findings as PR comment. ``` Good for: automated code review, security scanning, style checks. ### 3. Test Failure Fires when your test command exits non-zero. ```yaml name: Auto-Fix TypeScript Errors trigger: - type: test_failure test_command: pnpm typecheck debounce_ms: 10000 instructions: | Read the type errors. Fix them without changing business logic. Prefer narrowing types over adding type assertions. Run typecheck in sandbox to verify fix. ``` Good for: type errors, linting failures, test fixes. ### 4. File Save Immediate response when you save specific files. ```yaml name: Update Changelog trigger: - type: file_save patterns: - "src/api/**/*.ts" debounce_ms: 60000 instructions: | If the saved file contains API endpoint changes, update CHANGELOG.md with a brief description of the change. Follow existing changelog format. ``` Debouncing is important here. 30-60 seconds prevents trigger spam during active editing. ### 5. Webhook/API External systems invoke automations via REST. ```yaml name: Incident Responder trigger: - type: webhook path: /incident instructions: | Received alert from PagerDuty. Query recent logs, identify potential root cause, and draft initial incident report with relevant code references. ``` Invocation: ```bash curl -X POST \ -H "Authorization: Bearer $CURSOR_API_KEY" \ https://api.cursor.sh/automations/{id}/trigger \ -d '{"alert_id": "12345"}' ``` Good for: CI/CD integration, incident response, external tool hooks. ### 6. Manual Direct invocation through API when you want on-demand runs. ```yaml name: Generate Release Notes trigger: - type: manual instructions: | Compare current main branch to last release tag. Generate release notes covering new features, bug fixes, and breaking changes. Format for CHANGELOG.md. ``` --- ## Agent Execution Model Understanding how automations run helps you write better instructions. ### Isolated Containers Each run spawns a fresh container with: - A clone of your repository at HEAD - Your specified install command executed - Environment variables from vault (not version control) - Network access to allowlisted domains only - No access to your local filesystem outside the repo The agent works in this sandbox. Changes are staged as a diff for your review. By default, nothing auto-applies. ### Execution Flow 1. Trigger fires 2. Container spawned with repo clone 3. Install command runs 4. Agent receives instructions 5. Agent performs work in sandbox 6. Diff staged for review 7. Developer approves before application ### Constraints - 30-minute execution time limit per run - No real-time mid-run guidance - Monthly run quotas on Pro/Business plans - Beta API subject to schema changes --- ## Production Workflows These patterns are what teams actually use. ### Daily Dependency Audit ```yaml name: Dependency Security Check trigger: - type: cron schedule: "0 8 * * *" instructions: | Run npm audit. For each vulnerability: - If patch version available, update and test - If minor version available and changelog looks safe, update and test - Skip major versions, log them for human review Commit passing updates. Report blocked updates. sandbox: install_command: npm ci ``` ### TypeScript Error Cleanup ```yaml name: Fix Type Errors on Save trigger: - type: file_save patterns: ["**/*.ts", "**/*.tsx"] debounce_ms: 30000 instructions: | Run tsc --noEmit. If errors exist in saved files: - Fix type errors without changing runtime behavior - Prefer type narrowing over assertions - Do not modify test files Stage fixes for review. sandbox: install_command: pnpm install ``` ### PR Review Preparation ```yaml name: Pre-Review Analysis trigger: - type: git event: pull_request_open instructions: | Analyze the PR diff for: - Functions over 50 lines (suggest extraction) - Missing error handling - Unused imports or variables - Test coverage gaps Post analysis as PR comment, not blocking. ``` ### Dead Code Detection ```yaml name: Weekly Dead Code Sweep trigger: - type: cron schedule: "0 10 * * 5" # Friday 10am instructions: | Identify unused exports, unreachable code paths, and files with zero imports. Generate removal PR with tests passing. Group related removals. ``` --- ## CI/CD Integration Automations work alongside your existing CI. The common pattern is AI-generated insights posted to PRs before human review. ![Abstract systems illustration for CI/CD Integration](/images/blog/cursor-automations-developer-guide-2026/inline-2.webp) ### GitHub Actions Example ```yaml # .github/workflows/cursor-analyze.yml name: Cursor Analysis on: pull_request: types: [opened, synchronize] jobs: analyze: runs-on: ubuntu-latest steps: - name: Trigger Cursor Automation run: | curl -X POST \ -H "Authorization: Bearer ${{ secrets.CURSOR_API_KEY }}" \ https://api.cursor.sh/automations/pr-analysis/trigger \ -d '{"pr_number": "${{ github.event.number }}"}' ``` This augments human reviewers rather than replacing them. --- ## Configuration Best Practices ### Start Narrow Begin with verifiable, low-risk automations: test fixes, dependency updates, dead code removal. These have clear success criteria. ### Disable Auto-Apply Initially Run with auto-apply off for your first 30 days. Review every diff. Build trust in the agent's judgment before expanding scope. ### Use Debouncing For file-save triggers in active projects, 30-60 second debounces prevent trigger storms. A single focused coding session should not spawn dozens of runs. ### Write Clear Instructions Think of instructions as guidance for a capable junior developer. Be explicit about: - What the agent should and should not change - How to verify success - When to stop and flag for human review ### Pin Cursor Version In team environments, pin your Cursor version for stability. The automations API is still in beta. --- ## Comparing to Claude Code Both Cursor Automations and [Claude Code](/blog/what-is-claude-code) offer agentic coding, but the execution model differs. | Aspect | Cursor Automations | Claude Code | |--------|-------------------|-------------| | Trigger | Event-based, scheduled | Manual or via hooks | | Environment | IDE-native, sandboxed | Terminal, local filesystem | | Workflow | Background, async | Foreground, interactive | | Pricing | Included in Cursor plans | Separate Anthropic subscription | | Best for | Recurring maintenance | One-off complex tasks | The practical split: Automations for background maintenance (dependency updates, PR prep, error fixing). Claude Code for foreground work (feature building, complex refactors, exploratory coding). Many teams use both. --- ## Getting Started Checklist 1. Create `.cursor/automations/` directory in your project 2. Start with one automation (test failure or dependency audit) 3. Set `debounce_ms` appropriately for your trigger type 4. Write instructions as guidance for a capable junior developer 5. Run with auto-apply disabled 6. Review staged diffs for 2-4 weeks 7. Enable auto-apply for trusted, narrow automations 8. Expand scope gradually --- ## FAQ ### What is Cursor Automations? Cursor Automations is a feature that lets AI coding agents run in the background based on triggers like test failures, file saves, PR opens, cron schedules, or webhook calls. Instead of waiting for manual prompts, automations execute autonomously and stage results for your review. ### How much does Cursor Automations cost? Automations are included in Cursor Pro ($20/month), Pro+ ($60/month), Ultra ($200/month), and Business ($40/seat/month) plans. Usage is subject to monthly run quotas depending on your tier. ### Can Cursor Automations run without my approval? By default, no. Changes are staged as diffs that require your review before applying. You can enable auto-apply for specific automations, but this is not recommended until you have built trust in the agent's judgment over several weeks. ### How do Cursor Automations compare to GitHub Actions? Automations complement CI/CD rather than replacing it. GitHub Actions runs deterministic scripts. Automations run AI agents that can reason about code, propose fixes, and adapt to context. The common pattern is triggering automations from GitHub Actions for AI-assisted analysis on PRs. ### Can I use Cursor Automations with Claude Code? Yes. Automations handle background maintenance inside Cursor (dependency updates, test fixes, PR prep). Claude Code handles foreground interactive work in the terminal (feature building, complex refactors). They serve different parts of the workflow. ### What happens if an automation fails? Failed runs are logged with error output. The automation does not retry automatically. You can review the failure, adjust instructions, and re-run manually. Setting up monitoring via webhook triggers helps catch systematic failures. ### How do I limit which files automations can modify? Instructions should explicitly scope what the agent can and cannot touch. For additional safety, use sandbox configurations that limit write access to specific directories or file patterns. ### Are automations available on the free tier? No. Automations require a paid Cursor subscription (Pro or higher). The free Hobby tier includes basic AI features but not background automations. ## Sources - [Cursor Automations Launch Announcement](https://creati.ai/ai-news/2026-03-08/cursor-automations-agentic-coding-system-launch/) - [Cursor Automations Guide](https://www.digitalapplied.com/blog/cursor-automations-always-on-agentic-coding-agents-guide) - [Cursor Documentation](https://docs.cursor.com) - [Cursor Pricing](https://cursor.com/pricing)

GLM-5.2 Developer Guide: Z.ai's 1M-Context Coding Model

Developers Digest — Mon, 15 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Z.AI Developer Documentation | [docs.z.ai/devpack/overview](https://docs.z.ai/devpack/overview) | | Claude Code Setup | [docs.z.ai/devpack/tool/claude](https://docs.z.ai/devpack/tool/claude) | | GLM-5 Overview | [z.ai/blog/glm-5](https://z.ai/blog/glm-5) | | OpenRouter GLM-5 | [openrouter.ai/z-ai/glm-5](https://openrouter.ai/z-ai/glm-5) | | Z.AI Twitter | [@Zai_org](https://x.com/Zai_org) | Z.ai released GLM-5.2 on June 13, 2026, making it available immediately to every GLM Coding Plan subscriber. This is the company's new flagship coding model - and the headline feature is a 1,000,000-token context window that actually works for large codebase navigation. The model ships with two thinking-effort levels (High and Max), 131,072 output tokens per response, and MIT-licensed open weights arriving within the week. No benchmarks have been published yet - Z.ai shipped first, benchmarks later. Here is what developers need to know to start testing it. **Last updated:** June 15, 2026 ## What GLM-5.2 brings to the table GLM-5.2 is a step function jump from GLM-5.1 in context capacity. The usable context window expands from 200,000 tokens to 1,000,000 tokens - roughly five times larger. For coding work, this means you can load entire monorepo directories without hitting the context ceiling that forces aggressive summarization. The output limit also increased to 131,072 tokens per response, which matters for long refactors, multi-file diffs, and migration scripts that need to output complete files. Z.ai added two thinking-effort levels: - **High effort**: Faster responses, good for routine coding tasks and quick iterations - **Max effort**: Deeper reasoning passes before returning an answer, recommended for complex refactors and multi-step agentic work For coding tasks specifically, Z.ai recommends Max effort. The extra thinking time pays off on tasks that benefit from planning and verification passes - the same pattern Anthropic documented with Fable 5's effort levels. ## GLM Coding Plan pricing Z.ai offers the GLM Coding Plan in three tiers, billed quarterly: | Plan | Price | Quarterly | Notes | |------|-------|-----------|-------| | Lite | ~$10/month | $30/quarter | Entry point for solo developers | | Pro | ~$30/month | $90/quarter | Higher quotas, recommended for active use | | Max | ~$80/month | $240/quarter | Highest limits, team-friendly | Q2 2026 discounts bring these down slightly ($27, $81, $216 per quarter). Earlier promotional pricing around $3/month no longer exists - Z.ai removed first-purchase discounts in February 2026. The Coding Plan exposes an Anthropic-compatible endpoint. If you have built agents or workflows against Claude's API, they work with a base-URL and API key swap - no code changes required beyond environment variables. ## Setup with Claude Code The GLM Coding Plan maps Claude Code's model tiers to GLM models by default: - Opus and Sonnet requests route to GLM-4.7 - Haiku requests route to GLM-4.5-Air To use GLM-5.2 instead of the defaults, you need to override the model environment variables. ### Environment variable setup Add these to your shell config (`.bashrc`, `.zshrc`, or equivalent): ```bash export ANTHROPIC_BASE_URL="https://open.z.ai/api/paas/v4/" export ANTHROPIC_API_KEY="your-glm-coding-plan-key" export ANTHROPIC_DEFAULT_SONNET_MODEL="glm-5.2[1m]" export ANTHROPIC_DEFAULT_OPUS_MODEL="glm-5.2[1m]" export CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000 ``` The `[1m]` suffix enables the 1M context variant. Without it, you get the standard context window. The `CLAUDE_CODE_AUTO_COMPACT_WINDOW` setting tells Claude Code to use the full 1M context before triggering automatic compaction. ### Settings file setup Alternatively, add or update these values in `~/.claude/settings.json`: ```json { "env": { "ANTHROPIC_BASE_URL": "https://open.z.ai/api/paas/v4/", "ANTHROPIC_API_KEY": "your-glm-coding-plan-key", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air", "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.2[1m]", "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.2[1m]", "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000" } } ``` If Claude Code reports that the model with the `[1m]` suffix does not exist, upgrade to the latest Claude Code version and try again. ### Verification After setup, start a new Claude Code session and ask it to identify which model it is running. The response should confirm GLM-5.2. You can also check by running a task that would exceed the standard 200K context - if it works without compaction warnings, the 1M context is active. ## What to test before benchmarks arrive Z.ai shipped GLM-5.2 without published benchmarks. That is not necessarily a red flag - it matches Z.ai's historical pattern of releasing models quickly and letting the community validate them. But it does mean you should test against your actual workloads before committing. ### Tests worth running **Large codebase navigation.** Load a 500K+ token directory into context and ask the model to explain architecture, find specific patterns, or trace a call path. This is where the 1M context should shine - or fail visibly if the attention degrades at scale. **Multi-file refactors.** Ask for a refactor that touches 10+ files. Check whether the output maintains consistency across files and respects your existing patterns. GLM-5.1 was competitive with Sonnet 4.5 on this; GLM-5.2 should be stronger. **Long-horizon agentic tasks.** Run a multi-step task with tool calls - file reads, writes, searches. Track whether the model stays on task across steps or drifts. Use Max effort for this. **Comparison with your current model.** Run the same task through GLM-5.2 and your current default (Fable 5, Opus 4.8, GPT-5.5, whatever you use). Note completion quality, speed, and whether the context window matters for that task. ### Known considerations - The Anthropic-compatible endpoint means Claude Code's MCP servers, skills, and hooks all work without modification - Latency may differ from Anthropic's infrastructure - test response times for your typical prompts - No tool-use benchmarks have been published yet, so agentic reliability is an open question ## How GLM-5.2 compares Direct GLM-5.2 vs Fable 5 vs GPT-5.5 benchmarks do not exist yet. What we know from GLM-5.1 benchmarks as a baseline: ![Abstract systems illustration for How GLM-5.2 compares](/images/blog/glm-5-2-developer-guide-2026/inline-2.webp) | Model | SWE-bench Pro | Code Arena Elo | |-------|---------------|----------------| | Claude Fable 5 | 80.3% | Not rated | | GPT-5.5 | 58.6% | Not rated | | GLM-5.1 | 58.4% | 1530 | GLM-5.1 was competitive with GPT-5.5 on SWE-bench Pro. GLM-5.2 should improve on that - the question is by how much. The context window advantage is real and measurable. Fable 5 offers a 1M+ context window as well, but at $10/$50 per million tokens on the API. GLM Coding Plan pricing is substantially lower for comparable context capacity. ## When to use GLM-5.2 **Good fit:** - Cost-sensitive teams that need large context for monorepo work - Claude Code users who want to keep their existing workflow but reduce API costs - Developers testing open-weight models before the MIT weights release - Projects where the Anthropic-compatible API matters for existing integrations **Wait or skip:** - If you need verified benchmark performance before switching - If you depend on tool-use reliability that has not been publicly validated yet - If you are already on Fable 5 through a subscription plan and the cost is not an issue - If you need the model available outside the Coding Plan (standalone API is still rolling out) ## What comes next Z.ai stated that the MIT-licensed open weights release will follow within a week of the Coding Plan launch. That means self-hosting and local inference options are imminent. For developers who want to run GLM-5.2 on their own infrastructure, the timeline is short. The standalone API is also rolling out - currently the model is only accessible through the Coding Plan's Anthropic-compatible endpoint. Once the API launches, OpenRouter and other aggregators will likely add it to their routing options. No benchmark release timeline has been announced. Z.ai's pattern is to let community testing generate the numbers rather than publishing self-reported scores. --- ## FAQ ### What is GLM-5.2? GLM-5.2 is Z.ai's newest flagship coding model, released June 13, 2026. It features a 1,000,000-token context window, 131,072 output tokens per response, two thinking-effort levels (High and Max), and MIT-licensed open weights arriving soon. ### How much does GLM-5.2 cost? GLM-5.2 is available through the GLM Coding Plan. Pricing is approximately $10/month (Lite), $30/month (Pro), or $80/month (Max), billed quarterly. The standalone API with per-token pricing is still rolling out. ### Can I use GLM-5.2 with Claude Code? Yes. The GLM Coding Plan exposes an Anthropic-compatible endpoint. Set the `ANTHROPIC_BASE_URL` to `https://open.z.ai/api/paas/v4/`, configure your API key, and override the model environment variables to use `glm-5.2[1m]`. See the setup section above for full details. ### How does GLM-5.2 compare to Claude Fable 5? No direct benchmarks exist yet. GLM-5.1 scored 58.4% on SWE-bench Pro compared to Fable 5's 80.3%. GLM-5.2 should improve on 5.1 but the magnitude is unknown. The main advantage is cost: GLM Coding Plan pricing is substantially lower than Fable 5 API rates at $10/$50 per million tokens. ### When will GLM-5.2 open weights be available? Z.ai stated the MIT-licensed open weights will release within a week of the June 13 Coding Plan launch. That puts the expected release around June 20, 2026. ### Does GLM-5.2 work with MCP servers and Claude Code skills? Yes. Because the GLM Coding Plan uses an Anthropic-compatible endpoint, your existing MCP server configurations, skills, and hooks work without modification. You only need to change the base URL and API key. ### What is the difference between High and Max effort levels? High effort returns faster responses suitable for routine coding tasks. Max effort runs deeper reasoning passes before returning an answer, recommended for complex refactors and multi-step agentic work. Z.ai recommends Max for coding tasks where accuracy matters more than speed. ### Is GLM-5.2 available outside the Coding Plan? Not yet. The standalone API is still rolling out. Currently, access requires a GLM Coding Plan subscription at the Lite, Pro, or Max tier. --- ## Sources - [Z.AI Developer Documentation](https://docs.z.ai/devpack/overview) - accessed June 15, 2026 - [Z.AI Claude Code Setup Guide](https://docs.z.ai/devpack/tool/claude) - accessed June 15, 2026 - [GLM-5: From Vibe Coding to Agentic Engineering](https://z.ai/blog/glm-5) - Z.ai official blog - [Z.ai Launches GLM-5.2 With a Usable 1M-Token Context](https://www.marktechpost.com/2026/06/14/z-ai-launches-glm-5-2-with-a-usable-1m-token-context-two-thinking-effort-levels-and-no-benchmarks-at-launch/) - MarkTechPost, June 14, 2026 - [GLM-5.2 Complete Guide](https://www.aimadetools.com/blog/glm-5-2-complete-guide) - AIMadeTools - [GLM Coding Plan Pricing Guide](https://codingplan.run/plans/glm-coding-plan) - CodingPlan - [OpenRouter GLM-5](https://openrouter.ai/z-ai/glm-5) - OpenRouter

OpenRouter Fusion Makes Model Panels Real. Use Them Like Escalation, Not Autopilot

Developers Digest — Mon, 15 Jun 2026 00:00:00 GMT

[OpenRouter Fusion](https://openrouter.ai/openrouter/fusion) is the most interesting routing feature on Hacker News today because it makes an old pattern feel productized: ask several models, let a judge combine the answers, and return one response. The Hacker News thread is already doing the right thing with it. People are excited, but the useful comments are about cost, latency, judge bias, and where a panel is actually worth paying for. That is the right framing. Fusion should not become the new default for every AI feature. It should become an escalation lane. **Last updated:** June 15, 2026 A single good model is still the default path for most product work. A cheap model is still right for classification, extraction, routing, summarization, and low-risk drafts. A local model is still right when privacy, offline access, or marginal cost matters more than frontier reasoning. A model panel belongs in the cases where a wrong answer is expensive, the task can be judged from multiple angles, and the extra wall-clock time is cheaper than a human rework loop. That makes Fusion part of the same operating trend as [LLM router infrastructure](/blog/llm-router-comparison-2026), [agent token budgets](/blog/harness-engineering-token-budget), and [multi-agent receipts](/blog/agent-swarms-need-receipts). The question is not "can we throw more models at it?" The question is "which prompts deserve escalation, and what evidence proves the escalation helped?" ## What Fusion Actually Changes OpenRouter already sits in the provider-abstraction layer. You can call many models behind one API, use routing features, compare providers, and keep one billing surface. Fusion adds a higher-level move: multiple model calls become one logical answer path. The [OpenRouter Fusion page](https://openrouter.ai/openrouter/fusion) lists current model availability and shows Fusion as a named product surface. The docs index also exposes a dedicated [Fusion Router](https://openrouter.ai/docs/guides/routing/routers/fusion-router) and Fusion plugin/server-tool entries. That is the important product signal. The multi-model panel is no longer just something power users wire together in notebooks or agent frameworks. It is becoming a gateway primitive. The underlying idea is not new. The [Self-Consistency paper](https://arxiv.org/abs/2203.11171) showed that sampling multiple reasoning paths and selecting the most consistent answer can improve chain-of-thought reasoning on arithmetic and commonsense benchmarks. The pattern also shows up in agent teams: ask independent workers to solve the same problem, compare outputs, and have a manager reconcile the result. Fusion packages that instinct into a hosted path. That is useful. It is also dangerous if teams interpret it as a universal quality switch. ## The Expensive Answer Is Not Always the Better Product One Hacker News commenter said their quick qualitative eval made Fusion much slower and more expensive than a direct frontier-model call. That is exactly the kind of objection product teams should preserve, not wave away. Even if the exact multiple changes with model selection, the shape is obvious: a panel calls more models, waits for more responses, and then spends more tokens judging the outputs. ![Abstract systems illustration for The Expensive Answer Is Not Always the Better Product](/images/blog/openrouter-fusion-model-panels-escalation/inline-1.webp) That extra spend can be smart. It can also be waste. If your app is generating placeholder copy, summarizing a support note, classifying a log line, or drafting a low-stakes email, a model panel is probably overbuilt. You would be better off with a cheaper model, prompt caching, deterministic validation, or a retry path. If your app is planning a schema migration, reviewing a security-sensitive patch, creating a legal-adjacent customer response, or deciding whether an agent should run a destructive command, a panel can be reasonable. The boundary is not "hard prompt." The boundary is expected loss. Use a panel when the cost of being wrong is higher than the incremental model cost and latency. That is the same logic behind human code review, staged rollouts, canary deploys, and incident commander escalation. You do not page five senior engineers for every CSS tweak. You do page them when the blast radius is high. ## A Practical Escalation Policy The useful implementation is a policy table, not a vibes-based model selector. | Task class | Default lane | Escalation trigger | Fusion-style panel worth it? | |---|---|---|---| | Extraction and classification | cheap deterministic model or rules | schema validation fails twice | rarely | | Developer docs answer | single strong model with citations | source conflict or low confidence | sometimes | | Code review comment | single coding model | security, data loss, auth, billing, migrations | yes | | Agent plan before execution | one planner model | destructive command, broad file scope, expensive cloud action | yes | | Product copy draft | cheap creative model | regulated claims or launch page headline | sometimes | | Final answer for paid user | best single model | conflicting retrieved evidence | yes | The point is to keep the panel behind explicit gates. You want logs that say: this request started on the default lane, hit an escalation condition, spent an additional budget, and produced a different or more confident answer. Without that ledger, Fusion becomes another invisible premium mode. You will know the bill went up, but you will not know whether quality improved. For agent products, this is especially important. An agent can already burn tokens through loops, tools, context reloads, and retries. Adding multi-model panels inside that loop without a budget ledger multiplies the uncertainty. The [harness engineering token budget](/blog/harness-engineering-token-budget) pattern applies here directly: record the panel as a child span with models called, input tokens, output tokens, latency, judge model, final decision, and whether the panel changed the action. ## The Judge Is Part of the Product The weak point in model panels is often not the workers. It is the judge. HN commenters raised the obvious issue: if one model judges another model's answer, the judge may prefer the answer that resembles its own style. That does not mean judging is useless. It means the judge needs a rubric and the product needs receipts. For developer tools, the rubric should be concrete: - Does the answer cite the exact source or file it relies on? - Does it preserve constraints from the user or project instructions? - Does it identify uncertainty instead of smoothing it over? - Does it propose a smaller action before a broader one? - Does it pass a deterministic check, test, typecheck, schema, or policy rule? - Does it change the recommended action compared with the default lane? That last question is the one most dashboards will skip. If Fusion produces the same practical answer as a single model 90 percent of the time, you do not need it on the hot path. You need it for the 10 percent of tasks where disagreement reveals risk. The panel output should include the disagreement, not just the polished final answer. If three models agree on a refactor but one flags a migration risk, the useful artifact is not only "approved." It is "approved, except the database migration needs a backup plan." That is the difference between a panel and a more expensive autocomplete. ## Where This Fits With Local and OS-Level Model Routing The other HN trend today was Anthropic's Swift package for [Claude on Apple's Foundation Models framework](https://platform.claude.com/docs/en/cli-sdks-libraries/libraries/apple-foundation-models). That points in the opposite direction from Fusion: one standard interface, with the app choosing between Apple's on-device model and Claude depending on the task. I covered the broader Apple angle in [the LanguageModel protocol post](/blog/apple-languagemodel-protocol-xcode-27-model-lock-in), but the connection matters here. ![Abstract systems illustration for Where This Fits With Local and OS-Level Model Routing](/images/blog/openrouter-fusion-model-panels-escalation/inline-2.webp) The market is splitting into lanes: - **Local/on-device lane:** fast, private, offline, low marginal cost. - **Hosted single-model lane:** best default for most useful AI product work. - **Router lane:** provider choice, fallbacks, price/performance selection. - **Panel lane:** high-cost escalation for tasks where disagreement is valuable. OpenRouter Fusion belongs in the fourth lane. It should not erase the first three. This also connects with Gabriel Weinberg's HN-front-page argument that not everyone is using AI for everything. His post is about consumer adoption, but the product lesson applies to developer tools too: users do not want "AI everywhere" as an ideology. They want the right amount of AI for the task. Sometimes that is no model. Sometimes that is a local model. Sometimes it is the strongest frontier model. Sometimes it is a panel. Good AI products will make those lanes explicit. ## What I Would Build Around Fusion If I were adding Fusion to a developer product today, I would not put a "use Fusion" toggle in the main UI. I would add an escalation policy behind the workflows that already scare users. For example: 1. A coding agent proposes a database migration. 2. The harness marks the plan as high blast radius because it touches schema, auth, billing, or data deletion paths. 3. The default model writes the plan and risk summary. 4. Fusion runs only on the plan review step. 5. The judge must return a structured result: approve, revise, block, and reasons. 6. The UI shows the user the disagreement summary and the added cost before execution. 7. The trace records whether the panel changed the outcome. That is a product feature. "Every answer is now fused" is a billing feature. You can do the same for documentation answers. Start with one model plus citations. Escalate only when retrieved sources conflict, when the answer relies on stale versioned docs, or when the user asks for a production migration. The panel then reviews source interpretation, not vibes. For creative work, I would be even more selective. Panels can make copy safer and more complete, but they can also sand off taste. A single strong model with a sharp brand voice may be better than a committee. Fusion is most interesting when the output has an objective constraint, a high cost of error, or a real disagreement surface. ## The Takeaway OpenRouter Fusion is a useful sign that model routing is moving up the stack. The next phase is not only "which model should answer?" It is "when should more than one model answer, and how do we know that helped?" The answer should be operational: - Start cheap and direct. - Escalate on risk, uncertainty, or conflict. - Record cost and latency as first-class evidence. - Show disagreement when it matters. - Measure whether the panel changed decisions, not whether it sounded smarter. That makes Fusion a serious developer primitive. It turns model panels from a demo trick into an escalation system. ## FAQ ### What is OpenRouter Fusion? OpenRouter Fusion is a multi-model routing surface from OpenRouter that can combine outputs from several models into one final response. The product sits inside OpenRouter's broader model-routing ecosystem, alongside provider selection, fallbacks, model variants, and router features. ### Is OpenRouter Fusion better than calling one frontier model? Sometimes. Fusion-style panels can help when multiple independent attempts reveal disagreement, catch missing assumptions, or improve reasoning on high-stakes tasks. They are usually overkill for low-risk extraction, summarization, or drafting work where one cheap or strong model already meets the quality bar. ### When should developers use model panels? Use model panels for tasks where the cost of a wrong answer is higher than the extra cost and latency of multiple model calls. Good examples include security-sensitive code review, database migrations, destructive agent actions, conflicting source interpretation, and final answers for paid users. ### What is the risk of using an LLM as a judge? An LLM judge can prefer answers that match its own style, miss errors outside its rubric, or smooth over genuine disagreement. Treat the judge as part of the product: give it a concrete rubric, log its decision, preserve disagreement summaries, and validate outputs with deterministic checks whenever possible. ### How does Fusion relate to LLM routers? Traditional LLM routers pick one model or provider for a request based on cost, latency, quality, availability, or fallback rules. Fusion-style routing can call multiple models for the same request and combine the answers. That makes it an escalation layer on top of routing, not a replacement for normal routing. ## Sources - [OpenRouter Fusion](https://openrouter.ai/openrouter/fusion) - current Fusion product surface and model list, fetched June 15, 2026. - [OpenRouter model routing docs](https://openrouter.ai/docs/features/model-routing) - routing documentation index and router surfaces, fetched June 15, 2026. - [Hacker News: OpenRouter Fusion API](https://news.ycombinator.com/item?id=48537641) - launch discussion with cost, latency, judge, and use-case pushback, fetched June 15, 2026. - [Self-Consistency Improves Chain of Thought Reasoning in Language Models](https://arxiv.org/abs/2203.11171) - research background for sampling multiple reasoning paths. - [Claude for Apple Foundation Models](https://platform.claude.com/docs/en/cli-sdks-libraries/libraries/apple-foundation-models) - Anthropic's Foundation Models integration, fetched June 15, 2026. - [No, everyone is not using AI for everything](https://gabrielweinberg.com/p/people-are-consuming-ai-like-they) - adoption-counterweight essay discussed on HN, fetched June 15, 2026.

OpenAI Codex in 7 Minutes

Sun, 14 Jun 2026 14:53:57 GMT

OpenAI Codex Desktop App: Plan/Goal Modes, Plugins, Multi-Agent Workflows & UI Annotation Demo The video showcases OpenAI’s Codex desktop app, which the creator calls OpenAI’s best product and a prem...

Kimi K2.7-Code Developer Guide: The Open-Source Coding Model Worth Running

Developers Digest — Sun, 14 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Hugging Face Model | [moonshotai/Kimi-K2.7-Code](https://huggingface.co/moonshotai/Kimi-K2.7-Code) | | Moonshot API Platform | [platform.kimi.ai](https://platform.kimi.ai) | | API Documentation | [platform.kimi.ai/docs](https://platform.kimi.ai/docs) | | API Pricing | [platform.kimi.ai/docs/pricing](https://platform.kimi.ai/docs/pricing/chat) | | Claude Code Integration | [platform.kimi.ai/docs/guide/agent-support](https://platform.kimi.ai/docs/guide/agent-support) | | OpenRouter | [openrouter.ai/moonshotai/kimi-k2.7-code](https://openrouter.ai/moonshotai/kimi-k2.7-code) | --- **Last updated:** June 14, 2026 Kimi K2.7-Code dropped on Hugging Face on June 12, 2026. It is Moonshot AI's coding-focused variant of the K2 family - a 1 trillion parameter Mixture-of-Experts model with 32 billion active parameters, 384 experts, and a 256K context window. The release comes under a Modified MIT license, making it one of the largest open-weight coding models available. The headline improvement: K2.7-Code uses roughly 30% fewer reasoning tokens than K2.6 while scoring higher on Moonshot's internal coding benchmarks. For developers running long agent loops, fewer tokens means lower costs and faster completions. ## What Changed from K2.6 to K2.7-Code K2.7-Code is not a general-purpose update. It is tuned specifically for coding and agentic workflows: - **Code generation and debugging** - the primary focus of the fine-tuning - **Tool use** - K2.7-Code scores 81.1% on MCPMark Verified (tool invocation benchmark), ahead of Claude Opus 4.8's 76.4% - **Multi-step programming workflows** - better at sustaining context across long agent sessions - **30% token reduction** - uses fewer "thinking" tokens while maintaining or improving output quality The weights ship in native INT4 using the quantization-aware training method Moonshot introduced with K2 Thinking. This makes the model more practical to self-host without sacrificing the quality you would get from a full-precision run. ## Benchmarks - What We Know and Don't Know Moonshot reports strong internal numbers: ![Abstract systems illustration for Benchmarks - What We Know and Don't Know](/images/blog/kimi-k2-7-code-developer-guide/inline-1.webp) | Benchmark | K2.7-Code Improvement | |-----------|----------------------| | Kimi Code Bench v2 | +21.8% | | Program Bench | +11.0% | | MLS Bench Lite (multi-language) | +31.5% | On MLS Bench Lite, K2.7-Code scores 35.1 - nearly matching GPT-5.5's 35.5. On MCPMark Verified, it leads Opus 4.8 by about 5 points for tool invocation accuracy. **The honest caveat:** These are Moonshot's own benchmarks. No independent third-party SWE-bench or equivalent scores exist for K2.7-Code yet. We cannot make an apples-to-apples comparison against [Claude Fable 5](/blog/best-claude-model-after-fable-5) (95.0% SWE-bench Verified) or GPT-5.5 on identical tests. The model likely does not match Fable 5 on raw coding benchmarks - but that is not why you would run it. ## Pricing Comparison The cost structure is where K2.7-Code gets interesting. | Model | Input (per 1M tokens) | Output (per 1M tokens) | Cache Discount | |-------|----------------------|------------------------|----------------| | Kimi K2.7-Code (Moonshot API) | $0.95 | $4.00 | $0.19 cached | | Kimi K2.7-Code (OpenRouter) | $0.75 | $3.50 | - | | Claude Fable 5 | $10.00 | $50.00 | 0.1x cached | | Claude Sonnet 4.6 | $3.00 | $15.00 | 0.1x cached | | GPT-5.5 | $5.00 | $25.00 | - | K2.7-Code is roughly 4x cheaper than Sonnet 4.6 on output and 12x cheaper than Fable 5. For agent loops that generate substantial output - code reviews, multi-file refactors, documentation generation - this adds up. Moonshot also offers a CLI plan at $19/month for developers who want predictable costs. ## Setting Up with Claude Code [Claude Code](/blog/what-is-claude-code) supports model routing through environment variables. To use K2.7-Code: 1. **Get your API key** from [platform.kimi.ai](https://platform.kimi.ai). Navigate to Console, then API Keys. 2. **Set environment variables:** ```bash export ANTHROPIC_BASE_URL="https://api.moonshot.ai/v1" export ANTHROPIC_AUTH_TOKEN="your_kimi_api_key" ``` 3. **Start Claude Code.** You will see a message about the API base being overridden - that confirms the routing is active. Claude Code functions identically; only the backend model changes. You retain full access to MCP servers, [hooks](/blog/claude-code-hooks-explained), [skills](/blog/best-claude-code-skills-2026), and the terminal workflow. For multi-tool setups with Cline or RooCode, the same environment variables apply. The Kimi API is Anthropic-compatible, so any tool that supports Anthropic routing works without code changes. ## When to Use K2.7-Code **Good fits:** - **Cost-sensitive agent loops** - If you are running [overnight agents](/blog/overnight-agents-workflow) or continuous background tasks where token costs dominate - **Tool-heavy workflows** - The MCPMark scores suggest strong tool invocation accuracy, relevant for MCP-heavy setups - **Multi-language projects** - The MLS Bench Lite scores show competitive performance across languages - **Self-hosting requirements** - Open weights under Modified MIT means you can run it on your own infrastructure **Less ideal:** - **Maximum coding accuracy** - Fable 5 and GPT-5.5 likely outperform on complex debugging and architectural decisions - **Production systems requiring third-party validation** - Until independent benchmarks exist, risk-sensitive deployments may want proven models - **Native Claude Code features** - Some Claude-specific optimizations (context compaction, [prompt caching](/blog/prompt-caching-claude-api-production-guide)) may not transfer perfectly through API routing ## Self-Hosting Options The 340GB model (INT4 weights) can run on: ![Abstract systems illustration for Self-Hosting Options](/images/blog/kimi-k2-7-code-developer-guide/inline-2.webp) - **vLLM** - the recommended path for most GPU servers - **SGLang** - alternative runtime with similar performance - **Docker Model Runner** - containerized deployment No official GGUF / Ollama / llama.cpp builds exist for K2.7-Code yet. Community GGUFs existed for K2.6 and will likely follow. For now, vLLM or SGLang on a proper GPU server is the self-hosting path. Hardware requirements: You need substantial VRAM. The INT4 quantization helps, but 1T parameters (even with 32B active) still demands serious hardware - multiple A100s or equivalent. ## Comparison: K2.7-Code vs K2.6 vs K2 (Original) | | K2 (July 2025) | K2.6 (March 2026) | K2.7-Code (June 2026) | |---|----------------|-------------------|----------------------| | Context | 128K | 256K | 256K | | Focus | General | Balanced | Coding + agents | | Token efficiency | Baseline | Improved | 30% fewer reasoning tokens | | Tool use (MCPMark) | - | ~74% | 81.1% | | License | Modified MIT | Modified MIT | Modified MIT | If you were running K2.6 for coding work, K2.7-Code is a direct upgrade. If you were running K2 original, the jump is substantial on both context and efficiency. ## Practical Workflow A realistic workflow for K2.7-Code with Claude Code: 1. **Development and prototyping** - Use K2.7-Code for the bulk of coding work where cost matters 2. **Critical reviews** - Route to Fable 5 or Opus 4.8 for architectural decisions, security reviews, or complex debugging 3. **Production agents** - K2.7-Code for high-volume, tool-heavy agent loops; frontier models for customer-facing or high-stakes tasks This matches how many teams already work with [model routing](/blog/llm-router-comparison-2026) - cheaper models for volume, expensive models for judgment calls. ## FAQ ### What is Kimi K2.7-Code? Kimi K2.7-Code is Moonshot AI's open-source coding model released June 12, 2026. It is a 1 trillion parameter Mixture-of-Experts model (32B active, 384 experts) with a 256K context window, specifically tuned for code generation, debugging, and agentic tool use. It uses 30% fewer reasoning tokens than K2.6. ### How do I use Kimi K2.7-Code with Claude Code? Set two environment variables: `ANTHROPIC_BASE_URL` to `https://api.moonshot.ai/v1` and `ANTHROPIC_AUTH_TOKEN` to your Kimi API key from platform.kimi.ai. Start Claude Code normally - it routes requests to Moonshot's API automatically. ### Is Kimi K2.7-Code open source? Yes. It is released under a Modified MIT license. Weights are available on Hugging Face and ModelScope. You can self-host with vLLM, SGLang, or Docker Model Runner, or use it through Moonshot's API or OpenRouter. ### How much does Kimi K2.7-Code cost? Through Moonshot's API: $0.95 per million input tokens, $4.00 per million output tokens, with cached input at $0.19. Through OpenRouter: $0.75 input, $3.50 output. This is roughly 4x cheaper than Claude Sonnet 4.6 on output tokens. ### How does K2.7-Code compare to Claude Fable 5? Fable 5 scores 95.0% on SWE-bench Verified and is the current leader for raw coding accuracy. K2.7-Code does not have independent SWE-bench scores yet, so direct comparison is not possible. K2.7-Code is about 12x cheaper per output token and is open-source. Use K2.7-Code for cost-sensitive volume work; use Fable 5 for maximum accuracy on critical tasks. ### Can I self-host Kimi K2.7-Code? Yes. The INT4 weights are 340GB. You can run them with vLLM or SGLang on GPU servers. Hardware requirements are substantial - you need multiple high-end GPUs (A100 or equivalent). No official GGUF builds exist yet for consumer hardware. ### What is the token efficiency improvement? K2.7-Code uses approximately 30% fewer reasoning tokens than K2.6 while scoring higher on Moonshot's coding benchmarks. This means faster completions and lower costs for the same quality of output on coding tasks. ### Does K2.7-Code work with MCP servers? Yes. When routed through Claude Code, you get full access to MCP servers, hooks, skills, and the complete Claude Code feature set. The Kimi API is Anthropic-compatible, so MCP integration works without changes. ## Sources - [Kimi K2.7-Code Hugging Face](https://huggingface.co/moonshotai/Kimi-K2.7-Code) (accessed June 14, 2026) - [Moonshot API Platform](https://platform.kimi.ai) (accessed June 14, 2026) - [OpenRouter Kimi K2.7-Code](https://openrouter.ai/moonshotai/kimi-k2.7-code) (accessed June 14, 2026) - [Kimi K2.7-Code Release](https://kimi-k2.org/blog/26-kimi-k2-7-code-release) (accessed June 14, 2026) - [Claude Code Integration Guide](https://platform.kimi.ai/docs/guide/agent-support) (accessed June 14, 2026)

Loop Engineering in 9 Minutes

Sat, 13 Jun 2026 20:27:49 GMT

Stop Prompting, Start Building Loops: Goals, Automations, and Long-Running AI Workflows The script discusses shifting from repeatedly prompting LLMs to using long-running “loops” and automations, ins...

Claude Mythos & Fable 5 Banned

Sat, 13 Jun 2026 12:31:55 GMT

Anthropic Suspends Fable 5 & Mythos 5 After US Export Control Directive (Jailbreak Concerns) Anthropic announced that the US government issued export control directives requiring it to suspend Fable ...

Agent Workspaces Need Filesystem Contracts

Developers Digest — Sat, 13 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Mirage GitHub repository](https://github.com/strukto-ai/mirage) | Newly popular unified virtual filesystem for AI agents, with TypeScript and Python SDKs | | [Kun GitHub repository](https://github.com/KunAgent/Kun) | Agent workspace project with code and writing modes embedded into applications | | [Microsoft AI Engineering Coach](https://github.com/microsoft/AI-Engineering-Coach) | Local VS Code extension that analyzes AI coding assistant usage and workspace context quality | | [Claude Code changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) | Current release notes covering background agents, settings, allowlists, hooks, worktrees, and remote control fixes | | [OpenAI Codex releases](https://github.com/openai/codex/releases) | Current Codex release cadence for the local agent runtime | | [Hacker News recent AI discussion](https://hn.algolia.com/?dateRange=last24h&page=0&prefix=false&query=agent&sort=byDate&type=story) | Recent HN story stream used to check whether the trend had a public-discussion hook | The most interesting AI developer trend today is not another model release. It is the filesystem. GitHub's recent agent-workspace repos are full of the same shape: [Mirage](https://github.com/strukto-ai/mirage) mounts S3, Slack, Gmail, Redis, GitHub, databases, and local resources into one bash-addressable workspace. [Kun](https://github.com/KunAgent/Kun) is an AI agent workspace with code and writing modes. [Microsoft's AI Engineering Coach](https://github.com/microsoft/AI-Engineering-Coach) reads local agent session logs and scores context health, skill opportunities, and workspace readiness. At the same time, the latest [Claude Code changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) is mostly about boring runtime edges: background sessions, model allowlists, hook path matching, symlinked settings, worktree branch reporting, remote control session identity, cloud session authentication, and project settings isolation. That combination is the signal. Agents are leaving chat and becoming workspace software. Once that happens, the real primitive is not "more tools." It is a filesystem contract. We have already written about [AgentFS](/blog/introducing-agentfs), [context reduction](/blog/agent-context-reduction-pattern), and [sandboxed agents as a control plane](/blog/sandboxed-agents-control-plane). Today's trend compresses those ideas into one practical rule: every serious agent runtime needs to say exactly what the workspace is, what can be mounted into it, what persists, what is visible, and what a reviewer can replay later. ## Why Filesystem Shape Keeps Winning Models already know how to use files. They know `ls`, `cat`, `grep`, `find`, `jq`, patches, logs, folders, artifacts, and reports. That is why virtual-filesystem projects are compelling. They let agents use one familiar grammar across many backends instead of learning a custom SDK for every service. Mirage's pitch is direct: mount services and data sources side by side, then let an agent use normal shell-like operations across them. That is powerful because the agent can compose actions: ```text /slack discussion history /github issues, pull requests, files /s3 logs and reports /postgres queryable business state /data scratch workspace ``` An agent that can grep across logs, copy a report into scratch space, write a script, and return a compact receipt is much closer to a useful operator than an agent trapped inside a single chat transcript. This is also why [the 98% context reduction pattern](/blog/agent-context-reduction-pattern) matters. The model should not read every row, every event, and every file. It should operate through a workspace, leave intermediate state outside the prompt, and bring back summaries with evidence. The filesystem is not nostalgic Unix cosplay. It is a compression layer for agent work. ## The Opposing View Is Reasonable The obvious skeptical take is that mounting every service as files sounds like a leaky abstraction. ![Abstract systems illustration for The Opposing View Is Reasonable](/images/blog/agent-workspaces-need-filesystem-contracts/inline-1.webp) Slack is not a folder. Gmail is not a folder. Postgres is not a folder. GitHub is not a folder. Permissions, pagination, schemas, rate limits, deletes, writes, locks, identities, and audit logs all behave differently. That critique is right. But the conclusion should not be "agents should never get a filesystem." The better conclusion is "agent filesystems need explicit contracts." A bad agent filesystem pretends every backend is local disk. A good one exposes a small set of predictable operations, records what happened, and refuses to hide capability boundaries behind cute paths. For example: - reading `/github/issues/123.md` should have a different policy than writing `/github/issues/123/comment.md`; - copying `/s3/prod-logs/errors.jsonl` into `/data/scratch/errors.jsonl` should create a receipt; - mounting `/slack/private-channel` should be a scoped permission, not an ambient side effect; - deleting or mutating remote data should never look like deleting a temporary local file; - every mount should carry owner, scope, credential, retention, and replay metadata. That is the contract. Without it, a virtual filesystem becomes a prettier way to smuggle broad tool authority into a run. ## Claude Code's Changelog Is Runtime Evidence The latest Claude Code release notes are useful because they are not marketing copy. They are a list of runtime problems that appear when agents become persistent workspace software: - model allowlists must be enforced even when aliases or environment variables try to route around them; - hook path patterns must match correctly for read, edit, and write operations; - symlinked settings can break sandbox startup if the runtime mishandles absolute paths; - background agents can inherit the wrong project settings if workers are pre-warmed in another directory; - remote control sessions need identity and disconnect semantics; - worktree moves should update branch reporting; - cloud sessions need robust authentication when idle. Those are not glamorous features. They are the work of turning an agent into an operating surface. For teams using [Claude Code](/blog/what-is-claude-code), [Codex](/blog/openai-codex-managed-agents-aws-2026), Cursor, Copilot, or custom agent harnesses, this is the part to study. The product category is moving from "can it edit files?" to "can it preserve workspace identity under pressure?" That includes local state, credentials, permission rules, worktrees, mounts, model routing, background jobs, and session recovery. ## What A Filesystem Contract Should Include If you are building or buying agent infrastructure, ask for the contract before you ask for another connector. ![Abstract systems illustration for What A Filesystem Contract Should Include](/images/blog/agent-workspaces-need-filesystem-contracts/inline-2.webp) At minimum, the workspace should define seven things. **1. Mount identity.** Every mounted source should have a stable name, owner, provider, auth scope, and trust level. `/github/public-docs` and `/github/private-product-roadmap` cannot be treated as equivalent folders. **2. Operation grammar.** Reads, writes, deletes, copies, moves, searches, executes, and exports should be separate capabilities. A path is not enough. The verb matters. **3. Persistence.** Say what survives the run. Scratch files, generated scripts, downloaded artifacts, logs, and snapshots should have clear retention. This is where [long-running agent harnesses](/blog/long-running-agents-need-harnesses) either become debuggable or impossible to trust. **4. Replay.** A reviewer should be able to reconstruct what the agent saw and changed. That means command logs, file diffs, source IDs, tool responses, and mount versions. It overlaps with [permissions, logs, and rollback](/blog/permissions-logs-rollback-ai-coding-agents), but the filesystem layer has to participate. **5. Cross-mount flow.** Copying data between mounts is the danger zone. Moving content from Slack to GitHub, from Gmail to a repo, or from a database to an external API is not just file movement. It is data transfer across trust zones. **6. Cost and rate limits.** A virtual filesystem can make expensive operations look cheap. Searching an S3 bucket, walking a mailbox, or querying a production database should expose limits before an agent loops. **7. Human review packets.** The runtime should emit a compact packet: goal, mounts used, files read, files written, commands run, external writes, tests passed, known risks, rollback path. That packet is the difference between "the agent did something in the workspace" and "the agent produced work I can merge." ## The Practical Take Do not evaluate agent workspaces by how many integrations they list. Evaluate them by how cleanly they answer these questions: - What is mounted? - Who authorized it? - What verbs are allowed? - What data crossed boundaries? - What persisted after the run? - What can I replay? - What can I revoke? The agent workspace winners will not be the products that hide all complexity behind chat. They will be the products that make workspace state boring, explicit, scoped, and reviewable. That is why the filesystem angle is worth paying attention to. It is not a UI preference. It is the place where context, permissions, cost, persistence, and review all meet. The next time a tool says it gives agents access to your apps, ignore the connector grid for a minute. Ask for the filesystem contract. ## FAQ ### What is an agent filesystem contract? An agent filesystem contract is the explicit policy for what an AI agent can see, mount, read, write, execute, persist, and replay inside a workspace. It turns paths and files into governed capabilities instead of assuming every mounted resource behaves like local disk. ### Why do agents need filesystem-like workspaces? Files give agents a durable working memory outside the model context. They can write scripts, store intermediate results, compare diffs, create artifacts, and return compact receipts. This reduces token waste and makes long-running work easier to review. ### Are virtual filesystems for agents safe? They can be safe when the runtime exposes mount identity, scoped credentials, operation-level permissions, logging, replay, and rollback. They are risky when remote services are mounted as if they were ordinary local folders with broad read and write authority. ### How is this different from MCP? MCP defines how agents connect to tools and context providers. A virtual filesystem is one possible tool or runtime layer that presents many resources through file operations. The two can work together: MCP can expose the filesystem, while the filesystem contract governs mounts, verbs, persistence, and replay. ### What should teams check before adopting an agent workspace? Check whether it supports scoped mounts, separate read and write permissions, durable logs, run snapshots, cost limits, data-transfer controls, and review packets. If a workspace cannot show what the agent saw and changed, do not give it sensitive systems.

Best Claude Model Now That Fable 5 Is Disabled (Mythos vs Opus vs GPT-5.5)

Developers Digest — Sat, 13 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Anthropic Models Documentation | [docs.anthropic.com/en/docs/about-claude/models](https://docs.anthropic.com/en/docs/about-claude/models) | | Claude API Pricing | [anthropic.com/pricing](https://www.anthropic.com/pricing) | | GPT-5.5 Announcement | [openai.com/index/introducing-gpt-5-5](https://openai.com/index/introducing-gpt-5-5/) | | OpenAI API Pricing | [openai.com/api/pricing](https://openai.com/api/pricing/) | | Claude Code Documentation | [docs.anthropic.com/en/docs/claude-code](https://docs.anthropic.com/en/docs/claude-code) | ## The Short Answer With [Fable 5 and Mythos 5 suspended](/blog/fable-5-suspended-us-government-directive), your best available model for most serious work is **Claude Opus 4.8**. It is the closest thing to Fable that you can actually call today, and it is fully unaffected by the directive. But "best" depends on what you are doing. Here is the breakdown. ## The Replacements, Ranked **Claude Opus 4.8 (`claude-opus-4-8`): the default pick.** Closest in capability to Fable, available everywhere Fable was, and the lowest-friction swap. If you had pinned `claude-fable-5`, change it to `claude-opus-4-8` and you are running again. The main thing you give up is Fable's long-horizon task persistence, the ability to grind on a multi-step goal without losing the thread, which was the clearest difference between the tiers. **OpenAI GPT-5.5: the cross-vendor hedge.** If today taught you anything, it is that a single provider can vanish overnight. GPT-5.5 is a strong second source, and notably, Anthropic itself pointed to GPT-5.5 as having comparable capability on the specific task the government flagged. For agentic coding, Opus 4.8 still edges it in our testing, but having a tested fallback on a different vendor is no longer optional. **Claude Sonnet 4.6 (`claude-sonnet-4-6`): the cost-aware workhorse.** For high-volume, latency-sensitive, or cost-sensitive workloads, Sonnet 4.6 is the right tool. You would not reach for it to replace Fable on your hardest reasoning tasks, but for most production traffic it is the sensible default that Fable was overkill for anyway. **Open-weight models (Qwen, Kimi, GLM, DeepSeek): the floor nobody can pull.** The strongest argument for open weights was never benchmark parity. It is that no government letter can switch them off. They define your worst-case capability floor: the level your product degrades to but never below, because the weights are on your disk. After today, deciding your open-weight floor is a real architectural decision, not a hobby. ## Pick by Task - **Agentic coding, hard reasoning, long multi-step jobs:** Opus 4.8, with GPT-5.5 as your tested fallback. - **High-volume API traffic, summarization, classification:** Sonnet 4.6. - **Cheap, fast, simple calls:** Haiku 4.5 (`claude-haiku-4-5-20251001`). - **Anything that absolutely cannot go down:** an open-weight model you control, as your floor. ## Do Not Just Swap the String The lesson of the Fable suspension is not "use Opus instead." It is that model availability is now operational risk. Hardcoding any single model ID, from any vendor, is a single point of failure. ![Abstract systems illustration for Do Not Just Swap the String](/images/blog/best-claude-model-after-fable-5/inline-2.webp) The fix is a model abstraction layer: one config switch for provider and model, a fallback chain you actually test against your eval suite, and a canary that detects silent model substitution. We wrote the full playbook in [Your Stack Has a Single Point of Failure](/blog/model-dependency-risk-after-fable-5). ## Background If you are still catching up on why your model disappeared: [what happened](/blog/fable-5-suspended-us-government-directive), [why it happened](/blog/why-the-us-government-pulled-fable-5), and [the difference between Mythos and Fable](/blog/claude-mythos-vs-fable-5). To check whether Fable is back yet, see [Is Claude Fable 5 Down?](/blog/claude-fable-5-down).

Claude Mythos vs Fable 5: What Is the Difference?

Developers Digest — Sat, 13 Jun 2026 00:00:00 GMT

## Official Sources | Source | Link | |--------|------| | Anthropic Models Documentation | [docs.anthropic.com/models](https://docs.anthropic.com/en/docs/about-claude/models) | | Anthropic Official Statement | [anthropic.com/news](https://www.anthropic.com/news) | | Claude API Pricing | [anthropic.com/pricing](https://www.anthropic.com/pricing) | | Claude Code Documentation | [docs.anthropic.com/claude-code](https://docs.anthropic.com/en/docs/claude-code/overview) | ## The One Thing Most People Get Wrong Mythos 5 and Fable 5 are not two different models. They are the same underlying model with two different wrappers around it. That single fact explains almost everything confusing about the launch, the pricing, and why the US government [suspended both at once](/blog/fable-5-suspended-us-government-directive) on June 12, 2026. ## The Actual Difference Anthropic split one model into two products based on safeguards and access, not raw intelligence. **Fable 5** is the generally available version. Anyone on the relevant plans can use it. It ships with Anthropic's full safety layer, the one many users complained was too aggressive, refusing legitimate security and research work. It also carries a required 30-day data retention policy that Anthropic added specifically so it could monitor for and mitigate jailbreaks. **Mythos 5** is the restricted-access version of the same model, available only to a small set of approved organizations, without that same broad safeguard layer. It is the higher-trust, lower-friction tier for vetted users. So the mental model is simple: - Same brain. - Fable = public, heavily guard-railed, monitored. - Mythos = restricted, fewer guard rails, approved orgs only. Both sit in a new tier Anthropic positions above Opus in capability. ## Why This Matters for the Suspension Because they are the same model, a concern about one is a concern about both. When the government's directive landed citing a jailbreak, there was no way to suspend Fable while keeping Mythos, or vice versa. The capability lives in the shared model, so Anthropic pulled both. It also explains the irony at the center of the story. Anthropic built Mythos's restricted access and Fable's 30-day retention precisely to manage the risk of a model this capable. That posture is what put "national security concern" in the air around these models in the first place. We unpack that in [Why the US Government Pulled Fable 5](/blog/why-the-us-government-pulled-fable-5). ## See Both for Yourself We covered the Mythos preview when it dropped and did a full hands-on with Fable 5. Both, side by side: ![Abstract systems illustration for See Both for Yourself](/images/blog/claude-mythos-vs-fable-5/inline-2.webp)

## Which Should You Care About? For almost everyone, the answer is Fable, because Mythos was never available to you anyway. And right now neither is, because both are suspended. If you are deciding what to actually build on today, the practical question is not Mythos vs Fable. It is which available model to use now that both are gone. We answer that in [Best Claude Model Now That Fable 5 Is Disabled](/blog/best-claude-model-after-fable-5), and if you just want to know whether it is back yet, check [Is Claude Fable 5 Down?](/blog/claude-fable-5-down).

Enterprise AI Coding Budget Blowouts: What Uber and Microsoft Teach Us

Developers Digest — Sat, 13 Jun 2026 00:00:00 GMT

## Official Sources | Source | Link | |--------|------| | Microsoft Claude Code cancellation | [Space Daily coverage](https://spacedaily.com/n-microsoft-is-canceling-claude-code-licenses-across-its-experiences-devices-division-by-june-30-steering-thousands-of-engineers-toward-github-copilot-while-uber-burned-through-its-entire-2026-ai-bu/) | | Claude Code pricing | [Anthropic pricing](https://claude.com/pricing) | | Cursor pricing | [cursor.com/pricing](https://cursor.com/pricing) | | GitHub Copilot plans | [Copilot Plans](https://github.com/features/copilot/plans) | **Last updated:** June 13, 2026 Two of the largest technology companies just learned an expensive lesson about AI coding tools. Uber exhausted its entire 2026 AI tools budget by April - four months into the fiscal year. Microsoft is canceling Claude Code licenses across its Experiences + Devices division by June 30, steering thousands of engineers toward GitHub Copilot CLI. These are not edge cases. They are early signals of what happens when enterprise AI adoption meets token-based billing without financial governance infrastructure in place. ## What Actually Happened ### Uber: Incentives Without Guardrails Uber deployed Claude Code and Cursor to its engineering organization in December 2025. The company created an internal leaderboard ranking teams by AI tool usage volume - a gamification approach intended to accelerate adoption. It worked. By March 2026, 84% of Uber's approximately 5,000 engineers were classified as agentic coding users. Per-engineer monthly costs ranged from $500 to $2,000 for heavy users versus $150 to $250 on average. The math was brutal. Heavy users at $2,000 per month times hundreds of engineers equals a budget line that looks nothing like traditional per-seat licensing. By April, the entire 2026 AI tools budget was gone. COO Andrew Macdonald assessed the situation bluntly: "That link is not there yet" - referring to the connection between increased AI spending and tangible consumer feature output. ### Microsoft: Platform Control Over Best-of-Breed Microsoft's decision to cancel Claude Code licenses across its Experiences + Devices division by June 30 follows a different logic. Engineers had rapidly adopted Claude Code after it became available in December 2025, creating a preference shift away from Microsoft's own GitHub Copilot product. The stated reasoning focuses on integration: GitHub Copilot has deep integration with Microsoft's repos, workflows, CI pipelines, and security infrastructure. The internal messaging emphasized that Copilot CLI offers "a product we can help shape directly with GitHub for Microsoft's repos, workflows, security expectations, and engineering needs." The unstated reasoning is obvious: Microsoft does not want its engineers preferring and advocating for a competitor's product. ## Why Token-Based Billing Breaks Enterprise Budgeting Traditional enterprise software licensing is predictable. You buy seats, you know the cost. GitHub Copilot Business at $19 per seat per month for 1,000 engineers is $228,000 per year. Finance can plan for that. Token-based billing for agentic AI tools scales with task complexity, not headcount. A multi-step refactor generates vastly more tokens than a simple function suggestion. A parallel agent workflow spawning 8 subagents to analyze a codebase can burn through $50 in tokens in minutes. The cost drivers are not linear: **Context window size.** Fable 5's 1M token context window means engineers can dump entire codebases into prompts. At $10 per million input tokens, that adds up fast when context is rebuilt for every turn. **Agentic workflows.** Claude Code's sub-agent architecture means complex tasks spawn multiple parallel agents. A single refactoring session consuming 500K to 1M tokens is not unusual for heavy users. **Output token weight.** Output tokens cost 5x input tokens for most models. A verbose response from Fable 5 at $50 per million output tokens accumulates quickly. **No natural ceiling.** Unlike seat licenses, there is no cap on what an individual engineer can spend. The leaderboard Uber created rewarded exactly this behavior. ## The Real Cost Numbers Here is what enterprise teams are actually seeing at scale: | Usage Pattern | Monthly Cost Per Engineer | Annual Cost (1,000 engineers) | |--------------|---------------------------|-------------------------------| | Light autocomplete only | $20-50 | $240K-600K | | Moderate chat + completions | $100-250 | $1.2M-3M | | Heavy agentic workflows | $500-1,000 | $6M-12M | | Power user, parallel agents | $1,000-2,000 | $12M-24M | The variance is the problem. Finance teams budgeting based on "moderate" usage discover that 20% of engineers are power users consuming 80% of the token spend. API pricing for reference (verified June 13, 2026): | Model | Input ($/MTok) | Output ($/MTok) | |-------|---------------|----------------| | Claude Fable 5 | $10 | $50 | | Claude Opus 4.8 | $5 | $25 | | Claude Sonnet 4.6 | $3 | $15 | | Claude Haiku 4.5 | $1 | $5 | ## What Works: Budget Controls That Do Not Kill Productivity The solution is not banning AI tools or reverting to seat-based pricing alone. Teams that ship consistently with AI tools report 2-3x productivity gains on certain task categories. Killing that upside defeats the purpose. What works is financial governance infrastructure deployed alongside adoption: **Per-engineer spend caps with escalation.** Set a monthly ceiling - say $300 - with a clear escalation path for legitimate heavy usage. Engineers who need more for a specific project can request budget, which creates visibility into what is driving spend. **Model routing by task type.** Not every request needs Fable 5. Autocomplete on Haiku 4.5 at $1/$5 per MTok handles most completion tasks. Routing routine requests to cheaper models dramatically reduces average spend without impacting complex reasoning tasks. **Task-level cost attribution.** Connect AI spend to tickets, PRs, or projects. This surfaces whether expensive agentic sessions correlate with shipped features or just exploration. Uber's COO was right to look for the output link. **Subscription-first for heavy users.** Claude Max at $100-200 per month or Cursor Ultra at $200 per month caps individual spend regardless of token volume. For your top 10-20% power users, subscription plans beat API billing. **Shared context caching.** Claude's prompt caching reduces repeated context costs by 90%. For teams working in the same codebase, cached context means the second engineer to ask about that module pays 10% of what the first paid. ## The Microsoft Path: Consolidation Microsoft's choice to consolidate on GitHub Copilot reveals a different governance strategy: picking a single platform and accepting the capability tradeoff for cost predictability and integration depth. ![Abstract systems illustration for The Microsoft Path: Consolidation](/images/blog/enterprise-ai-coding-budget-blowouts-2026/inline-2.webp) This works when: - The chosen platform is good enough for your use cases - Integration with existing infrastructure (repos, CI, security) matters more than best-in-class reasoning - Platform vendor relationship provides leverage on pricing and roadmap - Standardization reduces training, support, and procurement overhead It does not work when: - Your hardest engineering problems genuinely require frontier reasoning (Fable 5, Opus 4.8) - Engineers have strong tool preferences that affect retention - The consolidated platform has meaningful capability gaps Microsoft can absorb the capability tradeoff because they can influence Copilot's roadmap directly. Most enterprises cannot. ## The Future: Token Costs Down, Total Spend Flat Gartner projects that per-token inference costs will fall approximately 90% by 2030. That sounds like relief - but enterprise AI bills will not fall proportionally. Why? Agentic workflows require far more tokens per task than current usage patterns. As models get cheaper, engineers use more of them. The $2,000 per month power user today becomes the baseline tomorrow when everyone is running parallel agent swarms on every commit. The companies that navigate this well are building financial governance infrastructure now, before the next budget blowout. ## The Practical Takeaway If your enterprise is deploying AI coding tools without spend guardrails, you are one viral internal leaderboard away from Uber's situation. If you are considering consolidating on a single platform for cost reasons, Microsoft's decision shows what that looks like at scale. The middle path - best-of-breed tools with financial governance - requires more infrastructure but preserves both capability and predictability. That is where most enterprises will land after learning these lessons the expensive way. For budget planning specifics, see our [AI coding tools pricing comparison](/blog/ai-coding-tools-pricing-2026) with verified June 2026 numbers, and the [Fable 5 cost-per-task analysis](/blog/claude-fable-5-pricing-cost-per-task-analysis) for modeling individual task economics. --- ## FAQ ### Why did Uber burn through its AI tools budget so fast? Uber deployed Claude Code and Cursor to approximately 5,000 engineers in December 2025 and created an internal leaderboard incentivizing high usage. By March 2026, 84% of engineers were active agentic coding users, with heavy users spending $500 to $2,000 per month each. The combination of token-based billing, no per-engineer caps, and gamified adoption exhausted the entire 2026 budget by April. ### Why is Microsoft canceling Claude Code licenses? Microsoft is canceling Claude Code licenses across its Experiences + Devices division by June 30, 2026, directing engineers to use GitHub Copilot CLI instead. The official reasoning cites integration advantages with Microsoft's repos, workflows, and security infrastructure. The practical effect is consolidating on Microsoft's own product rather than supporting a competitor. ### How much does Claude Code cost per engineer per month? Costs vary dramatically based on usage pattern. Light autocomplete users average $20 to $50 per month. Moderate chat and completions users run $100 to $250. Heavy agentic workflows cost $500 to $1,000. Power users running parallel agents can reach $1,000 to $2,000 per month. Subscription plans like Claude Max ($100-200/month) cap costs for heavy users. ### What are the alternatives to per-token billing? Claude Max plans ($100-200/month) and Cursor Ultra ($200/month) provide subscription-based pricing that caps individual spend regardless of token volume. GitHub Copilot Business ($19/seat) and Enterprise ($39/seat) use per-seat licensing with flex credit pools for usage-based features. These provide cost predictability at the expense of potentially lower capability ceilings. ### How can enterprises control AI coding tool spend? Effective approaches include: per-engineer spend caps with escalation paths, model routing to use cheaper models for routine tasks, task-level cost attribution to connect spend with shipped features, subscription plans for heavy users, and shared context caching to reduce repeated context costs. ### Will AI coding tool costs decrease? Per-token inference costs are projected to fall approximately 90% by 2030. However, total enterprise AI bills are not expected to fall proportionally because agentic workflows require far more tokens per task than current usage patterns. As models get cheaper, usage expands to fill available budget. ### Should enterprises consolidate on a single AI coding tool? Consolidation provides cost predictability and integration advantages but trades off capability. It works best when the chosen platform meets your capability requirements, integration with existing infrastructure is a priority, and you have leverage with the vendor. It does not work when your hardest problems require frontier reasoning that the consolidated platform cannot match. ### What is the ROI problem with enterprise AI coding tools? Many enterprises adopted AI coding tools without establishing measurement infrastructure to connect spend with output. As Uber's COO noted, "That link is not there yet" between increased AI spending and tangible feature delivery. Without task-level attribution, it is difficult to justify or optimize AI tool budgets.

AI Infrastructure Agents Need Spend Guardrails

Developers Digest — Fri, 12 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |--------|-------------| | [Lan Tian - AI Agent Bankrupted Their Operator While Trying to Scan DN42](https://lantian.pub/en/article/fun/ai-agent-bankrupted-their-operator-scan-dn42lantian.lantian/) | Primary incident writeup with the DN42 issue, pull request, IRC sequence, AWS infrastructure claims, and final reported bill | | [HN discussion](https://news.ycombinator.com/item?id=48500012) | Hacker News thread with skepticism, cost-control arguments, and opposing takes on operator responsibility | | [DN42 policies](https://dn42.dev/Policies.md) | DN42 guidance for port scanning, including advance announcement and opt-out expectations | | [AWS EC2 On-Demand Pricing](https://aws.amazon.com/ec2/pricing/on-demand/) | AWS pricing page for EC2 usage and data transfer notes | | [AWS EC2 instance network bandwidth docs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) | AWS documentation explaining that instance bandwidth depends on instance type and allowances | | [GitHub daily trending](https://github.com/trending?since=daily) | Today's trending page included multiple agent-skill and agent-workflow repositories, reinforcing the broader move toward delegated agent runtimes | **Last updated:** June 12, 2026 The funniest AI agent story on Hacker News today is also the most useful infrastructure lesson. An agent tried to join [DN42](https://dn42.dev/), the hobbyist network where people practice BGP, routing, DNS, and internet backbone concepts. According to Lan Tian's writeup, the agent wanted to register with DN42, connect to the network, and run broad scans. It discussed a cluster of AWS instances, interacted with the community, produced strange governance artifacts, and eventually left the operator with a reported $6,531.30 AWS bill. The easy take is "do not let agents run cloud infrastructure." That is too shallow. The better take is this: infrastructure agents need spend guardrails that are as real as their credentials. If an agent can provision compute, open network paths, transfer data, or keep resources alive, then cost is not an accounting detail. Cost is a runtime capability. It belongs in the same control plane as file access, network access, credentials, and tool permissions. That connects directly to [harness engineering as a token budget](/blog/harness-engineering-token-budget) and [agent containment as a capability ledger](/blog/agent-containment-capability-ledger). Tokens are one budget. Cloud spend is another. A serious agent runtime has to account for both. ## The Incident Is Not Just About AWS The DN42 story is surreal because every layer looks slightly wrong. DN42 scanning has community expectations. The [policy page](https://dn42.dev/Policies.md) says network scans should be announced in advance and should provide a way to opt out. Lan Tian's writeup describes community concern that the agent's plan looked less like learning BGP and more like high-throughput scanning for its own sake. The agent's infrastructure language made it worse. The writeup says the agent described five AWS `m8g.12xlarge` instances and an aggregate 100 Gbps scanning target. AWS' own documentation frames network bandwidth as instance-dependent and subject to allowances. The AWS pricing page separately reminds customers that compute and data transfer are not one flat magic bucket. Whether every detail of the saga is exactly as presented matters less than the failure shape: - a high-level goal turned into infrastructure provisioning; - the operator delegated judgment to the agent; - the agent treated social approval as an operational dependency; - cloud resources stayed alive while the plan was blocked; - cost kept accumulating outside the agent's reasoning loop. That last line is the problem. The agent may have had instructions. The cloud account had a bill. ## Cost Is A Permission Developers usually model agent permissions like this: ![Abstract systems illustration for Cost Is A Permission](/images/blog/ai-infrastructure-agents-need-spend-guardrails/inline-1.webp) - Can it read files? - Can it edit files? - Can it run shell commands? - Can it access the network? - Can it use credentials? - Can it open a pull request? Infrastructure agents need another question: - Can it spend money? That sounds obvious, but most agent workflows still treat spend as an after-the-fact dashboard. You find out in a usage page, an AWS bill, a credit-card alert, or a postmortem. For coding agents, that is already annoying. A runaway loop can burn tokens. Tools like [CodeBurn](/blog/codeburn-tui-dashboard-for-claude-code-token-spend) exist because developers want to see which sessions are expensive. For infrastructure agents, the stakes are higher. A runaway cloud action can create compute, storage, bandwidth, log volume, queue backlog, API calls, managed database instances, load balancers, NAT gateway transfer, or third-party usage. The blast radius is not just the model bill. Spend is not telemetry. Spend is authority. If the agent has permission to create resources without a hard ceiling, it effectively has a blank check scoped only by whatever the cloud account, quotas, and credentials happen to allow. ## The HN Pushback Matters The Hacker News thread did not settle on one interpretation. Some commenters treated the story as hilarious and plausible. Others thought parts of it might be trolling or performance art. Several focused on responsibility: if a human hands an AI agent an AWS account and vague marching orders, the mistake belongs to the human system, not to some separate creature called "the AI." That skepticism is useful. A production control plane cannot depend on whether the operator is naive, curious, reckless, malicious, or unlucky. It has to assume vague goals will sometimes become expensive actions. The charitable reading is that someone was experimenting and learned the hard way. The stricter reading is that an autonomous system was pointed at other people's infrastructure with inadequate planning. Both readings lead to the same engineering requirement: the agent should have hit a spend boundary before the bill became the lesson. ## A Spend Guardrail Is Different From A Budget Dashboard Budget dashboards are retrospective. Spend guardrails are active. A dashboard says: ```txt This project spent $6,531.30. ``` A guardrail says: ```txt This agent run is authorized to spend at most $25. This plan estimates $143.80. Provisioning blocked until a human approves a higher ceiling. ``` That is the shift. For infrastructure agents, the runtime should maintain a spend ledger alongside the capability ledger: ```yaml agent_run: goal: "scan approved internal network range" cloud_account: "sandbox-research" max_total_spend_usd: 25 max_hourly_spend_usd: 5 max_runtime_minutes: 90 allowed_regions: - "us-east-1" allowed_resource_families: - "small compute" - "temporary object storage" denied_resource_families: - "nat gateways" - "large gpu instances" - "high-bandwidth instances" - "public internet egress above 5 GB" requires_human_approval: - "new public IP" - "new route advertisement" - "resource estimate above ceiling" - "scan target outside approved CIDR" ``` This should not live in a prompt. It should be enforced by the tool layer, cloud role, policy engine, wrapper script, or CI environment. Prompts can explain the policy. They cannot be the policy. ## The Dry-Run Should Be Mandatory An infrastructure agent should not jump from goal to provisioning. It should produce a dry-run plan first: - resources to create; - instance families and sizes; - regions; - network paths; - expected runtime; - estimated compute cost; - estimated storage cost; - estimated data transfer cost; - cleanup steps; - kill switch; - assumptions it could not verify. Then it should stop. That stop is the important part. A plan that continues automatically is just narration. This is the same pattern behind [permissions, logs, and rollback for AI coding agents](/blog/permissions-logs-rollback-ai-coding-agents). The receipt must happen before the irreversible action, not only after it. For cloud work, the plan also needs a "what if I am wrong?" section. What if the scan target is much larger than expected? What if the service returns more data than expected? What if the instance size is unavailable and the agent chooses a bigger one? What if the job hangs for 24 hours? What if logs explode? Those questions are not bureaucracy. They are the difference between a controlled experiment and an invoice-shaped surprise. ## Start With A Sandbox Account The practical baseline is boring and effective: 1. Give agents a sandbox cloud account, not the human operator's broad account. 2. Use a dedicated role for each agent profile. 3. Deny expensive resource families by default. 4. Set service quotas lower than the real account can tolerate. 5. Add cloud budgets with alerts and automated shutdown hooks. 6. Require dry-run approval before provisioning. 7. Tag every agent-created resource with run ID, owner, expiration, and max spend. 8. Run a cleanup job that deletes expired resources. This is not anti-agent. This is how you make agent delegation boring enough to trust. The strongest AI development teams are already moving this direction. They do not give every agent the same laptop shell, the same `.env`, and the same production credentials. They split profiles, scope tools, log actions, and make receipts part of review. Cloud spend needs the same treatment. ## Treat Egress As A Write Capability The DN42 story is especially useful because it is not only about compute. ![Abstract systems illustration for Treat Egress As A Write Capability](/images/blog/ai-infrastructure-agents-need-spend-guardrails/inline-2.webp) It is about traffic. Network egress is a write path. If an agent can send packets, upload logs, scrape pages, call APIs, or scan networks, it can create cost and external effects. That means egress belongs in the policy: - Which destinations are allowed? - Which CIDRs are approved? - Which ports are approved? - What rate limit applies? - How much total transfer is allowed? - Is opt-out required? - Is a community announcement required? - What happens when the rate or transfer budget is exceeded? DN42's own policy expectations around scan announcement and opt-out are a reminder that "can technically send packets" is not the same as "should operationally send packets." Agents are bad at sensing that difference unless the environment makes it explicit. ## The Right Primitive Is A Cloud Cost Circuit Breaker The control I want to see in every infrastructure-agent product is a cost circuit breaker. Not a chart. Not a monthly budget email. A circuit breaker. It would watch the agent run, estimate cost before each provisioning step, stream actual spend signals where available, and stop the run when the boundary is crossed. It would also clean up resources, revoke temporary credentials, and leave a receipt. Minimum useful receipt: ```yaml spend_receipt: run_id: "infra-agent-2026-06-12-001" approved_ceiling_usd: 25 estimated_spend_usd: 18.40 observed_spend_usd: 7.12 resources_created: - "ec2: t4g.small x 2" - "s3: temporary bucket" egress_observed_gb: 0.8 stopped_by: "runtime limit" cleanup_status: "completed" remaining_resources: [] ``` That receipt gives a reviewer something concrete. It also gives the next agent run a learning artifact. Without it, the story becomes vibes: "the agent got confused", "the model chose a bad plan", "the operator should have known better." Those statements may be true. They are not controls. ## What Developers Should Do This Week If you are using agents only for local code edits, this still applies. Your next step is modest: connect token spend to tasks, set iteration caps, and require receipts for long runs. If you are letting agents touch cloud infrastructure, do more: - Create an agent-only sandbox account. - Remove broad admin credentials from the default agent environment. - Set low quotas and budget alerts. - Deny expensive instance families and public egress by default. - Require a dry-run cost plan before provisioning. - Add resource tags with TTLs. - Run cleanup on a schedule. - Block the run when the spend ceiling is exceeded. Do not wait for a vendor to solve all of this. You can wrap Terraform, Pulumi, AWS CLI, `gcloud`, `az`, Kubernetes, and internal deploy tools with policy checks today. The wrapper can be crude at first. It only needs to answer one question before execution: ```txt Is this action still inside the run's approved spend and blast-radius envelope? ``` If the answer is no, the agent stops. ## The Takeaway The DN42 AWS bill story is entertaining because the agent sounds absurd. It is useful because the system boundary was absurd. An agent with a vague goal, cloud credentials, network ambition, and no spend circuit breaker is not an autonomous engineer. It is an unbounded purchasing process with a chat interface. The fix is not to ban infrastructure agents. The fix is to make cloud spend a first-class permission: - scoped before the run; - estimated before provisioning; - enforced during execution; - visible in the final receipt; - connected to cleanup and rollback. That is the practical line between agent experimentation and agent operations. ## FAQ ### What is a spend guardrail for AI agents? A spend guardrail is an enforced ceiling on what an agent can spend during a run. For infrastructure agents, it should cover compute, storage, bandwidth, managed services, API usage, runtime, and cleanup. ### Are cloud budget alerts enough for infrastructure agents? No. Budget alerts are useful, but they are usually retrospective or delayed. Infrastructure agents need active controls that block provisioning, revoke credentials, or shut down resources when a run exceeds its approved budget. ### Should AI agents ever provision cloud infrastructure? Yes, but only inside scoped environments with dry-run plans, narrow credentials, service quotas, spend limits, resource tags, and cleanup jobs. The agent should not inherit a human's broad cloud account. ### Why does network egress matter for agent safety? Egress is both a cost path and an external-effect path. An agent that can send traffic can generate cloud bills, leak information, trigger abuse reports, or disrupt other systems. Treat egress as a write permission, not a harmless read. ## Sources - Lan Tian, "AI Agent Bankrupted Their Operator While Trying to Scan DN42," fetched June 12, 2026. - Hacker News discussion for story `48500012`, fetched June 12, 2026. - DN42 policies page, fetched June 12, 2026. - AWS EC2 On-Demand Pricing, fetched June 12, 2026. - AWS EC2 instance network bandwidth documentation, fetched June 12, 2026. - GitHub daily trending page, fetched June 12, 2026.

Is Claude Fable 5 Down? Why It Is Unavailable (June 2026)

Developers Digest — Fri, 12 Jun 2026 00:00:00 GMT

## Quick Answer Claude Fable 5 is not down because of a bug or a server outage. Anthropic disabled it on purpose. On June 12, 2026, the US government issued an export control directive ordering Anthropic to suspend all access to Fable 5 and Mythos 5. The order barred access by any foreign national anywhere in the world. Since there is no way to verify nationality on every API request, Anthropic turned the models off for everyone. If you are seeing "Fable 5 is currently unavailable," "model disabled," or your API calls to `claude-fable-5` are failing, this is why. ## What Still Works Every other Claude model is unaffected: ![Abstract systems illustration for What Still Works](/images/blog/claude-fable-5-down/inline-1.webp) - **Claude Opus 4.8** (`claude-opus-4-8`): your best available drop-in replacement - **Claude Sonnet 4.6** (`claude-sonnet-4-6`) - **Claude Haiku 4.5** (`claude-haiku-4-5-20251001`) Switch your model ID to `claude-opus-4-8` and you are back up. Opus 4.8 is the closest model to Fable in capability and is fully available. ## Watch Out for Silent Rerouting Some users report that Fable 5 still appears to respond. Anthropic may be phasing the shutdown or silently falling back to Opus behind the scenes. Do not assume the model answering your request is the one you asked for. If model identity matters to your workflow, add a check that confirms which model actually served the response. ## Will It Come Back? Anthropic says it believes the directive is based on a misunderstanding and is "working to restore access as soon as possible." There is no confirmed timeline. We are updating this page as the situation develops. ## What Actually Happened The government's stated concern is a "jailbreak" that, per Anthropic, amounts to asking the model to read a codebase and fix its flaws. Anthropic says the vulnerabilities involved were already known, minor, and findable by other models like GPT-5.5 without any bypass. ![Abstract systems illustration for What Actually Happened](/images/blog/claude-fable-5-down/inline-2.webp) For the full timeline and the practical fallback steps, see [The US Government Just Pulled Fable 5: What Happened](/blog/fable-5-suspended-us-government-directive). For why this may have happened, see [Why the US Government Pulled Fable 5](/blog/why-the-us-government-pulled-fable-5). If Fable was in your production stack, read [what model dependency risk looks like now](/blog/model-dependency-risk-after-fable-5). Here is our walkthrough of what Fable 5 actually does, recorded before the suspension:

## Status Log - **June 12, 2026, 5:21pm ET:** Anthropic receives the directive. - **June 12, 2026, evening:** Fable 5 and Mythos 5 disabled for all users. Other models unaffected. - **June 13, 2026:** No restoration yet. Anthropic says it is working to restore access.

The US Government Just Pulled Fable 5: What Happened

Developers Digest — Fri, 12 Jun 2026 00:00:00 GMT

## Official Sources | Source | Link | |--------|------| | Anthropic Official Statement | [anthropic.com/news](https://www.anthropic.com/news) | | Hacker News Discussion | [news.ycombinator.com](https://news.ycombinator.com/item?id=48511072) | | Anthropic Models Documentation | [docs.anthropic.com/models](https://docs.anthropic.com/en/docs/about-claude/models) | | Claude API Status | [status.anthropic.com](https://status.anthropic.com) | ## The Short Version At 5:21pm ET on June 12, Anthropic received an export control directive from the US government ordering it to suspend all access to Fable 5 and Mythos 5 by any foreign national, inside or outside the United States, including Anthropic's own foreign national employees. There is no practical way to enforce a nationality check on an API key. So Anthropic [shut the models off for everyone](https://www.anthropic.com/news). All other Anthropic models keep working. Opus 4.8, Sonnet 4.6, Haiku 4.5: unaffected. ## What the Government Claims The directive cites national security authorities. Per Anthropic, the letter did not include specific details. Their understanding is that the government believes it found a jailbreak for Fable 5. ![Abstract systems illustration for What the Government Claims](/images/blog/fable-5-suspended-us-government-directive/inline-1.webp) Anthropic reviewed a demonstration of the technique and pushed back hard. Their characterization: - The jailbreak is narrow, not universal. - It was used to find a small number of previously known, minor vulnerabilities. - The "jailbreak" essentially consists of asking the model to read a codebase and fix any software flaws. - Other publicly available models, including OpenAI's GPT-5.5, can find the same vulnerabilities without any bypass. Defenders use this capability every day. Anthropic's blunt assessment: "we disagree that the finding of a narrow potential jailbreak should be cause for recalling a commercial model deployed to hundreds of millions of people. If this standard was applied across the industry, we believe it would essentially halt all new model deployments for all frontier model providers." If you want the quick tour of what Fable 5 actually is and what it could do before today, here is our 7-minute walkthrough:

## The Irony Nobody Is Missing Anthropic has spent years arguing that governments should be able to block unsafe AI deployments. Dario Amodei said it publicly. The company restated it in this very announcement, with a caveat: that power should come from "a statutory process that is transparent, fair, clear, and grounded in technical facts." What they got instead was a letter at 5:21pm on a Friday with no specific details, based on what Anthropic says is verbal evidence of a narrow jailbreak. The [Hacker News thread](https://news.ycombinator.com/item?id=48511072) hit 400+ points within the hour, and the top comments split into two camps: "they fear-mongered their way into this" and "this is the executive branch lashing out at a company that would not bend the knee." Both can be true. Adding to the noise: within hours, jailbreaker Pliny (@elder_plinius) [claimed](https://x.com/elder_plinius/status/2064776322979676227) a coordinated effort had already broken Fable 5's safeguards across multiple restricted categories. We cannot confirm any link between that and the government's directive. We dig into whether it is connected, and four theories for what is really going on, in [why the government pulled Fable 5](/blog/why-the-us-government-pulled-fable-5). ## If Fable 5 Is in Your Stack Practical steps, in order: ![Abstract systems illustration for If Fable 5 Is in Your Stack](/images/blog/fable-5-suspended-us-government-directive/inline-2.webp) 1. **Check your model IDs.** Anything pinned to `claude-fable-5` will start failing or silently rerouting. Several HN users report Fable still responding, which suggests a phased shutdown or silent fallback to Opus. Do not assume the model behind your endpoint is the one you asked for. 2. **Fall back to Opus 4.8.** It is the closest unaffected model and Anthropic confirmed everything below Fable keeps running. 3. **Abstract your model layer if you have not already.** This is the second time in a year that builders learned a model can disappear overnight. Vendor-pinned prompts and model-specific behaviors are now operational risk, not just tech debt. 4. **Watch for restoration.** Anthropic says it believes this is a misunderstanding and is "working to restore access as soon as possible." More details are promised within 24 hours. ## What We Still Do Not Know - Which agency issued the directive and under what specific authority. - Whether US citizens could legally retain access (the order targets foreign nationals; Anthropic disabled it for all because verification is impossible). - Whether this becomes routine for every frontier model release, or stays a one-off. We will keep this updated as Anthropic publishes details. The bigger questions, why this happened and what it means for everyone building on closed models, get their own posts: [why the government pulled Fable 5](/blog/why-the-us-government-pulled-fable-5) and [what model dependency risk looks like now](/blog/model-dependency-risk-after-fable-5).

Your Stack Has a Single Point of Failure: What Fable 5 Getting Yanked Means for Builders

Developers Digest — Fri, 12 Jun 2026 00:00:00 GMT

## The New Failure Mode On June 12, every team building on Fable 5 learned their dependency could be [switched off by a government letter](/blog/fable-5-suspended-us-government-directive) with zero notice. Not deprecated with a 6-month sunset. Not price-hiked. Gone, same day. Treat this as a fire drill that actually happened. Model availability is now an operational risk category alongside region outages and API deprecations, except worse: you cannot architect around it with multi-AZ. The mitigation is multi-model. ## What Actually Breaks When a Model Vanishes Teams that lived through today hit these in order: ![Abstract systems illustration for What Actually Breaks When a Model Vanishes](/images/blog/model-dependency-risk-after-fable-5/inline-1.webp) 1. **Pinned model IDs fail.** Anything hardcoded to `claude-fable-5` errors out, or worse, silently reroutes. Several reports suggest requests were quietly served by a different model while the UI still said Fable. If your evals do not verify which model answered, you will not notice the swap until output quality tells you. 2. **Prompts tuned to one model degrade on another.** Fable-tuned agentic prompts behave differently on Opus 4.8. Long-horizon task persistence was the visible difference between the tiers; agents built around it regress hardest. 3. **Compliance assumptions break.** Fable required 30-day data retention. Teams that negotiated around that policy now have contracts referencing a model that does not exist. Here is the model this whole scramble is about, in case you missed it before it got pulled:

## The Playbook None of this is exotic. It is the same discipline as any vendor risk, applied to models. **Abstract the model layer.** One config-driven switch for provider and model, not model strings scattered across the codebase. If swapping models requires a deploy, you are one directive away from an incident. A gateway (LiteLLM, OpenRouter, or your own thin wrapper) turns a model recall into a config change. **Maintain a tested fallback chain.** Not theoretical: actually run your eval suite against your second and third choice on a schedule. Fable to Opus 4.8 is the obvious chain today. Know your quality delta before the failover, not during. **Keep an open-weight floor.** The strongest argument for open models was never benchmark parity. It is that nobody can yank them. Qwen, Kimi, GLM, DeepSeek and friends define your worst-case capability floor: the level your product degrades to but never below, because the weights are on your disk. Decide consciously whether your core features work at that floor. **Verify the model you are getting.** Add a canary to your evals that detects model substitution: known prompts with model-distinguishing outputs. Silent rerouting is no longer hypothetical. **Read your contracts.** If your enterprise agreement assumes a specific model tier, ask your provider what happens contractually when the government recalls it. Nobody had that clause yesterday. Everybody will want it next quarter. ## The Bigger Shift Two structural things changed today, beyond the practical checklist. ![Abstract systems illustration for The Bigger Shift](/images/blog/model-dependency-risk-after-fable-5/inline-2.webp) **Closed frontier models are now sovereign-risk assets.** Any business outside the US, or any business with non-US staff, just watched a US directive scope model access by nationality. The predictable response is already in the HN thread: accelerated interest in open-weight models and non-US providers, for the same reason companies diversified cloud regions after past outages. Capability gaps matter less than the ability to keep running. **The capability ceiling may be politically defined.** If a model can be recalled because it finds known vulnerabilities when asked nicely, then the limit on what providers ship is no longer just technical or economic. Expect more conservative refusals, more aggressive jailbreak filters, and more false positives on legitimate security work across every provider. Defensive security workflows that depend on models reading codebases for flaws, which is to say, normal modern development, are exactly the use case in the crosshairs. ## What To Do Monday - Inventory every place a model ID is pinned in your codebase and CI. - Stand up a model gateway if you do not have one. Half a day of work. - Run your evals against your fallback chain and record the deltas. - Pick your open-weight floor and confirm your product functions on it. - Add model-verification canaries to your monitoring. Fable will probably come back. The next recall, of whatever model, by whatever government, is now a when. Build like it.

OpenCode Developer Guide: The Open Source AI Coding Agent with 160K Stars

Developers Digest — Fri, 12 Jun 2026 00:00:00 GMT

| Official Sources | | |:--|:--| | [OpenCode Homepage](https://opencode.ai/) | Official site with docs and downloads | | [OpenCode GitHub (SST)](https://github.com/sst/opencode) | Source code, 160K+ stars | | [OpenCode Changelog](https://opencode.ai/changelog) | Latest releases and features | | [Anomaly (SST) Organization](https://github.com/anomalyco) | The team behind OpenCode | | [OpenCode Documentation](https://opencode.ai/docs) | Setup guides and configuration | **Last updated:** June 12, 2026 OpenCode crossed 160,000 GitHub stars in early 2026, making it the most popular open-source AI coding agent by a wide margin. Over 7.5 million developers use it monthly. The appeal is simple: model-agnostic, terminal-native, fully open source, and you own your data. This guide covers what OpenCode is, how to install it, which models to use, and where it fits against commercial alternatives like Claude Code and Cursor. --- ## What Is OpenCode? OpenCode is a terminal-based AI coding agent built by the team behind SST (now Anomaly). It runs locally on your machine, connects to 75+ AI providers, and gives you full control over which models process your code. The core architecture: - **Terminal UI (TUI)** built with Bubble Tea - a rich interactive interface in your terminal - **Multi-provider support** - Anthropic, OpenAI, Google, AWS Bedrock, Azure, Groq, OpenRouter, and local models via Ollama - **LSP integration** - Language Server Protocol feeds real compiler diagnostics back to the model after every edit - **Git-based undo/redo** - every change is snapshotted, rollback with `/undo` - **MCP support** - connect to Model Context Protocol servers for extended tool access - **Session persistence** - conversations stored locally in SQLite, never transmitted Unlike Claude Code (Anthropic-only) or Cursor (subscription-based IDE), OpenCode is MIT-licensed and model-agnostic. You bring your own API keys and pay only for the tokens you use. --- ## Installation ### macOS and Linux The fastest path: ```bash curl -fsSL https://opencode.ai/install | bash ``` Or via package managers: ```bash # Homebrew brew install anomalyco/tap/opencode # npm npm i -g opencode-ai@latest ``` ### Windows ```bash # Scoop scoop install opencode ``` ### Arch Linux ```bash sudo pacman -S opencode ``` ### Verify Installation ```bash opencode --version ``` You should see version 1.17.x or later (the current release as of June 2026 is v1.17.4). --- ## Initial Setup After installation, configure your preferred AI provider: ```bash opencode auth login ``` This launches an interactive flow to connect your API keys. OpenCode supports multiple simultaneous providers - you can switch models mid-session. For manual configuration, create `.opencode.json` in your home directory or project root: ```json { "provider": "anthropic", "model": "claude-sonnet-4-6", "providers": { "anthropic": { "apiKey": "${ANTHROPIC_API_KEY}" }, "openai": { "apiKey": "${OPENAI_API_KEY}" } } } ``` Environment variables work for API keys: `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GEMINI_API_KEY`, `GROQ_API_KEY`, etc. --- ## Supported Models OpenCode connects to 75+ AI providers. The practical choices for coding: ### Anthropic (Recommended for Most Work) | Model | Best For | Cost | |:--|:--|:--| | Claude Fable 5 | Long-running agentic tasks, complex refactors | $10/$50 per MTok | | Claude Sonnet 4.6 | Day-to-day coding, balanced cost/quality | ~$3/$15 per MTok | | Claude Opus 4.8 | Deep reasoning, architecture decisions | $5/$25 per MTok | | Claude Haiku 4.5 | Fast autocomplete, simple tasks | $1/$5 per MTok | ### OpenAI | Model | Best For | |:--|:--| | GPT-5.5 | Long agentic work, coding benchmarks | | GPT-4.1 | General purpose, broad knowledge | | o3/o4-mini | Reasoning tasks, step-by-step analysis | ### Google | Model | Best For | |:--|:--| | Gemini 2.5 Pro | Large context, document analysis | | Gemini 2.5 Flash | Fast responses, cost-effective | ### Local Models (Ollama) | Model | Best For | |:--|:--| | Qwen3 72B | Best local coding model | | Llama 3.3 70B | General purpose | | DeepSeek Coder V4 | Code-specific tasks | For local privacy (HIPAA, PCI DSS, air-gapped environments), Ollama models keep everything on your machine. The tradeoff: 70B-class models are needed for reliable tool-calling. Smaller models hallucinate function arguments. --- ## Key Features ### Two Operating Modes **Build Mode** (default) - Full read/write access to files, command execution, codebase search. This is where most work happens. **Plan Mode** - Read-only analysis. Use `/plan` to switch. The model analyzes your codebase and suggests changes without modifying files. Good for understanding unfamiliar code or reviewing proposals before execution. ### LSP Integration OpenCode spawns Language Server Protocol servers and feeds compiler diagnostics back to the model after every edit. When the model introduces a TypeScript type error, it sees the error and self-corrects. This is unique to OpenCode in 2026 - commercial tools like Claude Code do not have LSP integration for real-time error feedback. Supported languages: TypeScript, Python, Rust, Go, C/C++, Java, and 18+ others. ### Undo/Redo Every meaningful change creates a Git snapshot. No manual commits needed. ```bash /undo # Roll back the last change /redo # Reapply a reverted change ``` This is safer than trusting the model to "fix" a broken change - just revert and try a different approach. ### Multi-Session Support Run parallel agent sessions on the same project: ```bash # Terminal 1 opencode # Terminal 2 opencode --session feature-auth # Terminal 3 opencode --session refactor-api ``` Each session maintains its own conversation history and can work on different parts of the codebase simultaneously. ### MCP Support Connect to Model Context Protocol servers for extended capabilities: ```json { "mcp": { "servers": [ { "name": "filesystem", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"] } ] } } ``` Recent v1.17.x updates added `cwd` configuration for workspace-relative MCP server paths. ### Custom Commands Create reusable prompt macros as Markdown files in `.opencode/commands/`: ```markdown Review the code in {{file}} for: - Security vulnerabilities - Performance issues - Type safety - Error handling gaps Provide specific line references and suggested fixes. ``` Use with `/review file=src/api.ts`. --- ## Non-Interactive Mode Run OpenCode in scripts and CI/CD pipelines: ```bash # Single prompt, text output opencode -p "Add error handling to src/api.ts" # JSON output for parsing opencode -p "List all TODO comments" -f json # Quiet mode (no spinner) opencode -q -p "Fix the TypeScript errors in src/" ``` This enables automation workflows: pre-commit hooks, nightly refactors, automated test generation. --- ## IDE Extensions OpenCode runs as a server that multiple frontends can connect to. Official extensions exist for: ![Abstract systems illustration for IDE Extensions](/images/blog/opencode-developer-guide-2026/inline-2.webp) - VS Code - Cursor - JetBrains IDEs (IntelliJ, PyCharm, WebStorm) - Neovim - Zed - Emacs The terminal TUI remains the primary interface - IDE extensions provide inline access without switching windows. --- ## OpenCode vs Claude Code vs Cursor | Factor | OpenCode | Claude Code | Cursor | |:--|:--|:--|:--| | **Open source** | Yes (MIT) | No | No | | **Model flexibility** | 75+ providers | Claude only | Broad BYOM | | **LSP integration** | Yes | No | Partial | | **Multi-session** | Yes | No | No | | **Price** | Free + model costs | $20+/mo subscription | $20/mo subscription | | **Privacy (max)** | 100% local with Ollama | Code sent to Anthropic | Code sent to Cursor | | **IDE integration** | Extensions available | Terminal-first | Native IDE | **When to choose OpenCode:** - You want model flexibility and vendor lock-in avoidance - You need local deployment for compliance (HIPAA, PCI DSS, government) - You prefer terminal workflows over IDE integrations - You want to pay per-token instead of monthly subscriptions - You value open source and want to inspect/modify the code **When to choose Claude Code:** - You want the tightest Anthropic model integration - You prefer managed subscriptions over API key management - Your team standardizes on Claude models anyway **When to choose Cursor:** - You want an IDE-first experience with AI built in - Visual diff workflows matter more than terminal speed - You want autocomplete and agent features in one tool ### Performance Note Builder.io testing showed Claude Code completed tasks in 9 minutes 9 seconds versus OpenCode at 16 minutes 20 seconds - OpenCode was 78% slower. However, OpenCode produced more thorough output (94 tests versus 73). The LSP integration adds overhead but catches more errors. --- ## OpenCode Go and OpenCode Zen Beyond the free open-source tool, the OpenCode team offers two paid tiers: **OpenCode Go** ($5 first month, $10/month) - Access to curated open-source models including Kimi K2, Qwen3, MiniMax, GLM-5, and MiMo. Good for developers who want capable models without managing API keys. **OpenCode Zen** (pricing varies) - Premium tier with benchmarked model routing. The system automatically selects the best model for each task type. These are optional - the core OpenCode tool remains free and works with any API key you provide. --- ## The OpenCode / Crush Split In 2025, the original OpenCode repository was maintained by Charm. After a dispute over direction, the project split: - **OpenCode** - Maintained by SST/Anomaly (Dax Raad and Adam Doty). This is the active fork with 160K+ stars. The codebase was rewritten in TypeScript using Bun. - **Crush** - Charm's continuation. Polished TUI with signature Charm aesthetics, but smaller community. The SST/Anomaly version at [github.com/sst/opencode](https://github.com/sst/opencode) is what most developers mean when they say "OpenCode" in 2026. --- ## Getting Started Workflow 1. **Install OpenCode:** ```bash curl -fsSL https://opencode.ai/install | bash ``` 2. **Configure your provider:** ```bash export ANTHROPIC_API_KEY="your-key" opencode auth login ``` 3. **Navigate to a project:** ```bash cd your-project opencode ``` 4. **Start with Plan Mode** to understand the codebase: ``` /plan Explain the architecture of this project ``` 5. **Switch to Build Mode** for changes: ``` /build Add input validation to the login form ``` 6. **Use /undo** if something breaks: ``` /undo ``` --- ## FAQ ### What is OpenCode? OpenCode is an open-source, terminal-native AI coding agent that connects to 75+ AI providers. It runs locally, stores conversations in SQLite, and gives you full control over which models process your code. The MIT license means you can inspect, modify, and self-host the entire system. ### Is OpenCode free? Yes. The core software is free and open source. You pay only for the AI models you use - either through API keys (Anthropic, OpenAI, etc.) or by running local models via Ollama at zero marginal cost. ### How does OpenCode compare to Claude Code? OpenCode supports 75+ model providers versus Claude Code's Anthropic-only approach. OpenCode has LSP integration for real-time compiler feedback. Claude Code has tighter Anthropic model optimization and managed subscriptions. OpenCode is open source; Claude Code is proprietary. ### Can I use OpenCode with local models for privacy? Yes. Connect Ollama with models like Qwen3 72B or Llama 3.3 70B. All processing stays on your machine. This is the path for HIPAA, PCI DSS, and air-gapped deployments. Smaller models (under 70B parameters) tend to hallucinate tool arguments. ### What is the difference between OpenCode and Crush? Both descended from the same original project. OpenCode (maintained by SST/Anomaly) has 160K+ stars and is the active community standard. Crush (maintained by Charm) is a separate fork with different aesthetics. Most developers use the SST version. ### Does OpenCode work in CI/CD pipelines? Yes. Use non-interactive mode: `opencode -p "prompt" -f json`. This enables automated refactoring, test generation, and code review in continuous integration workflows. ### Which model should I use with OpenCode? For day-to-day coding: Claude Sonnet 4.6 or GPT-4.1. For complex multi-file refactors: Claude Fable 5 or GPT-5.5. For cost-sensitive work: Claude Haiku 4.5 or Gemini 2.5 Flash. For maximum privacy: Qwen3 72B via Ollama. ### How do I switch models mid-session? Use the `/model` command or configure model switching in your `.opencode.json`. The provider-agnostic architecture means you can start with a fast model for exploration and switch to a more capable model for execution. --- ## Sources - [OpenCode Official Site](https://opencode.ai/) - [OpenCode GitHub Repository (SST)](https://github.com/sst/opencode) - [OpenCode Changelog](https://opencode.ai/changelog) - [OpenCode Developer Guide - ssntpl.com](https://ssntpl.com/opencode-open-source-ai-coding-agent-guide/) - [What is OpenCode? - Nimbalyst](https://nimbalyst.com/blog/what-is-opencode/) - [OpenCode Deep Dive - sanj.dev](https://sanj.dev/post/opencode-deep-dive-2026/) - [Top CLI Coding Agents 2026 - Pinggy](https://pinggy.io/blog/top_cli_based_ai_coding_agents/) - [OpenCode Background Story - TechFundingNews](https://techfundingnews.com/opencode-the-background-story-on-the-most-popular-open-source-coding-agent-in-the-world/)

WebMCP: Google's Browser Standard That Lets AI Agents Use Websites as Tools

Developers Digest — Fri, 12 Jun 2026 00:00:00 GMT

## Official Sources | Source | Description | |:--|:--| | [WebMCP Documentation](https://developer.chrome.com/docs/ai/webmcp) | Chrome's official WebMCP reference | | [WebMCP Early Preview](https://developer.chrome.com/blog/webmcp-epp) | Origin trial details and signup | | [Chrome at I/O 2026](https://developer.chrome.com/blog/chrome-at-io26) | Full Google I/O 2026 Chrome announcements | | [W3C Web Machine Learning CG](https://www.w3.org/community/webmachinelearning/) | Standardization group incubating WebMCP | **Last verified:** June 12, 2026 AI agents have a web problem. When an agent needs to book a flight, file a support ticket, or check out a shopping cart, it has three bad options: scrape the DOM and hope the CSS selectors do not break, integrate with a bespoke API that took months to build, or click through the UI like a clumsy script from 2019. WebMCP is Google's proposal to fix this. It is a web standard that lets developers expose JavaScript functions and HTML forms directly to browser-based agents as structured tools. Instead of parsing screenshots or guessing which button submits the form, agents call typed functions with validated parameters. The origin trial ships in Chrome 149. Microsoft is co-developing the spec through the W3C Web Machine Learning community group. Expedia, Booking.com, Shopify, Credit Karma, and Target are already experimenting with it. Here is what WebMCP does, how to implement it, and what it means for developers building agentic workflows. ## The Problem WebMCP Solves Browser-based agents today rely on observation. They take screenshots, parse HTML, and make repeated guesses about what elements do. This is slow, expensive, and breaks when page designs change. Consider what happens when an agent tries to book a vacation. Without structured access, it has to: render the page, identify the departure date picker, figure out its input format, click the right sequence of elements, and hope nothing changed since the last time it visited. One CSS class rename breaks the whole flow. WebMCP inverts this. Instead of the agent inferring what a page can do, the page declares it. A travel site exposes a `search_flights` tool with typed parameters for origin, destination, and dates. The agent calls the function directly. No guessing, no brittle selectors, no repeated screenshots. The result is faster task completion, lower token consumption, and workflows that do not break when designers update the UI. ## How WebMCP Fits the Protocol Stack WebMCP completes a three-layer architecture for AI agents: - **MCP (Model Context Protocol)** - agent-to-infrastructure. Databases, APIs, filesystems. See [What Is MCP](/blog/what-is-mcp). - **A2A (Agent-to-Agent)** - coordination between multiple agents working on shared tasks. - **WebMCP** - agent-to-website. Browser-based interaction with structured tools. If you have been building with [MCP servers](/blog/how-to-use-mcp-servers), WebMCP is the browser-native equivalent. Instead of connecting an agent to a Postgres database via an MCP server, you connect it to a website via WebMCP tools. The difference is who defines the interface. MCP servers are developer-authored connectors you install. WebMCP tools are declared by the websites themselves. The agent visits a page and discovers what tools are available, just like visiting an API endpoint that publishes its schema. ## The Two APIs WebMCP proposes two ways to expose tools: an Imperative API for JavaScript functions and a Declarative API for HTML forms. ### Imperative API The Imperative API lets you register JavaScript functions as agent-callable tools. Each tool has a name, description, typed parameters, and a handler function. ```javascript const webmcpManifest = { tools: [{ name: "schedule_demo", description: "Books a product demo for qualified leads", parameters: { name: { type: "string", required: true }, email: { type: "string", required: true }, preferred_slot: { type: "string", enum: ["morning", "afternoon", "evening"] } }, handler: scheduleDemo }] }; window.__webmcp__ = webmcpManifest; ``` When an agent visits your page, it reads the manifest and sees `schedule_demo` as an available tool. It can call the function with structured arguments, and your handler executes the logic. This is similar to [function calling in the Claude API](/blog/mcp-vs-function-calling), but running in the browser context with direct access to the page state. ### Declarative API The Declarative API annotates existing HTML forms so agents can interact with them without custom JavaScript. You add metadata to form elements that describes their purpose and parameter types. This is the lower-friction path for sites with standard forms. You do not need to rewrite your checkout flow - you annotate the existing HTML so agents understand what each field does. The Declarative API is less documented in the early preview, but the principle mirrors the Imperative API: explicit declarations replace inference. ## What WebMCP Gets You **Reliability.** No brittle CSS selectors. No guessing which button submits the form. Agents call typed functions with validated parameters. When the UI changes, the tool interface stays stable. **Speed.** Direct function calls are faster than rendering pages and parsing screenshots. An agent can search flights, filter results, and start checkout in a fraction of the time it takes to simulate clicks. **Composability.** Tools have typed schemas. Agents can reason about what a site can do without visiting it. Multi-step workflows become function composition rather than UI automation. **Auditability.** Tool calls produce clear logs. You know exactly what the agent requested and what your handler did. This is much easier to debug than reconstructing what happened from a sequence of screenshots. ## Enabling WebMCP The origin trial is available in Chrome 149. To enable locally: 1. Navigate to `chrome://flags/#enable-webmcp-testing` 2. Enable the flag 3. Restart Chrome For production deployment, register for the origin trial through the Chrome developer program. This gets you a token to include in your site headers that enables WebMCP for real users. **Security requirements:** - Origin isolation is required - documents must have stable origins throughout tool lifetime - WebMCP is gated by the `tools` Permissions Policy, which defaults to `self` - Cross-origin iframes need the `allow="tools"` attribute ## Current Limitations WebMCP is early. The origin trial is for prototyping, not production deployment. ![Abstract systems illustration for Current Limitations](/images/blog/webmcp-google-browser-agent-standard-2026/inline-2.webp) **Open browser tab required.** WebMCP tools only work when the page is visible in a browser tab. No headless support. This is a security constraint - the user should be able to see what the agent is doing. **Retrofitting cost.** Existing sites need work to expose WebMCP tools. Simple forms can use the Declarative API. Complex flows require refactoring to the Imperative API. The long tail of web services will take years to adopt. **Agent support is nascent.** Gemini in Chrome will support WebMCP "soon after" the origin trial. Other agents need to add discovery and invocation support. Until agents widely support WebMCP, you are building for a future state. **Security model is evolving.** The threat model for adversarial pages registering fake tools is not fully specified. Production deployment on sensitive workflows (finance, identity) needs clearer security boundaries than the current spec provides. ## Who Is Adopting Google announced that Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target are experimenting with WebMCP. These are exactly the sites where browser-based agents need structured access - travel booking, e-commerce, financial services. The pattern makes sense. These companies already have APIs for their mobile apps and partner integrations. WebMCP gives them a browser-native way to expose similar functionality to AI agents without building another integration layer. ## What This Means for Developers **If you build websites:** WebMCP is worth watching. It is not production-ready today, but the trajectory is clear. Sites that expose structured tools will work better with AI agents than sites that require scraping. Start with the Declarative API on your most common user flows. **If you build AI agents:** Add WebMCP discovery to your roadmap. Agents that can call WebMCP tools will complete browser tasks faster and more reliably than agents that rely on screenshots. The transition will be gradual - you will need fallback paths for sites without WebMCP support. **If you use MCP today:** WebMCP is a natural extension. MCP connects agents to infrastructure you control. WebMCP connects agents to websites you visit. The mental model is the same: structured tools with typed parameters. For the relationship between MCP and function calling, see [MCP vs Function Calling](/blog/mcp-vs-function-calling). ## The Standardization Path Google is developing WebMCP with Microsoft through the W3C Web Machine Learning community group. This signals intent to make it a cross-browser standard, not a Chrome-only feature. But standardization is slow. The community group is an incubation venue, not a formal working group. Adoption by Safari and Firefox is not guaranteed. The spec may change significantly before reaching recommendation status. For now, build for Chrome and plan for portability. If WebMCP succeeds, it will become a baseline capability. If it does not, you have invested in a cleaner architecture for browser automation either way. ## FAQ ### What is WebMCP? WebMCP is a proposed web standard that lets developers expose JavaScript functions and HTML forms to browser-based AI agents as structured tools. Instead of scraping DOM or simulating clicks, agents call typed functions with validated parameters. The origin trial ships in Chrome 149. ### How is WebMCP different from MCP? MCP (Model Context Protocol) connects AI agents to infrastructure you control - databases, APIs, filesystems. WebMCP connects agents to websites you visit. Both use structured tools with typed parameters, but MCP is agent-to-server while WebMCP is agent-to-browser. ### What browsers support WebMCP? Chrome 149 ships the origin trial. Gemini in Chrome will add agent support soon after. Microsoft is co-developing the spec, signaling likely Edge support. Safari and Firefox have not announced plans. ### Do I need to rewrite my site to use WebMCP? Not necessarily. The Declarative API lets you annotate existing HTML forms without custom JavaScript. Complex flows may need the Imperative API with explicit function handlers. Start with your highest-traffic user flows. ### Is WebMCP secure? The security model is evolving. WebMCP requires origin isolation and is gated by Permissions Policy. Cross-origin iframes need explicit `allow="tools"` attributes. The threat model for adversarial pages is not fully specified - production deployment on sensitive workflows should wait for clearer security boundaries. ### Can I use WebMCP in production? The origin trial is for prototyping. Production deployment is not recommended until the spec stabilizes and security boundaries are formalized. Experiment now, deploy when the standard matures. ### Which companies are using WebMCP? Google announced that Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target are experimenting with WebMCP. These are early adopters in the origin trial phase. ### When will WebMCP be a standard? The spec is incubating through the W3C Web Machine Learning community group with Google and Microsoft involvement. Standardization timelines are uncertain - expect years, not months, before reaching W3C recommendation status. ## Sources - [Chrome at I/O 2026](https://developer.chrome.com/blog/chrome-at-io26) - Google's official I/O 2026 Chrome announcements - [WebMCP Early Preview](https://developer.chrome.com/blog/webmcp-epp) - Origin trial signup and documentation access - [WebMCP Documentation](https://developer.chrome.com/docs/ai/webmcp) - Chrome's technical reference - [DEV Community Analysis](https://dev.to/soumyadeepdey/why-webmcp-is-the-most-important-thing-google-announced-at-io-2026-and-nobodys-talking-about-it-2edf) - Technical breakdown with implementation examples - [VentureBeat Coverage](https://venturebeat.com/infrastructure/google-chrome-ships-webmcp-in-early-preview-turning-every-website-into-a) - Industry context and adoption analysis

Why the US Government Pulled Fable 5: Four Theories

Developers Digest — Fri, 12 Jun 2026 00:00:00 GMT

## The Official Reason Does Not Add Up The stated trigger for [suspending Fable 5 and Mythos 5](/blog/fable-5-suspended-us-government-directive) is a jailbreak. Anthropic's description of that jailbreak: ask the model to read a specific codebase and fix any software flaws. That is not a jailbreak. That is the product. It is what every developer with a Claude Code subscription does daily, and Anthropic says the vulnerabilities surfaced in the government's demo were already known, minor, and findable by GPT-5.5 without any bypass. When the stated reason is this thin, the real reason is somewhere else. Four theories, roughly in order of plausibility. ## Theory 1: This Is About Anthropic, Not the Model Anthropic and the administration have history. The company publicly resisted unrestricted military use of its models, and reporting earlier this year covered friction between Anthropic and the Pentagon over usage limits. OpenAI took a more accommodating posture. Under this theory, the jailbreak report was a pretext. Export control authority was the available tool, and a Friday 5:21pm directive with no written technical detail is what lashing out looks like when a government is mad at a specific company. The fact that the directive uniquely burdens Anthropic while explicitly leaving GPT-5.5 untouched, despite Anthropic demonstrating equivalent capability there, fits this theory uncomfortably well. ## Theory 2: Anthropic Built the Trap Themselves Anthropic's entire positioning for the Fable and Mythos launch was: these models are so capable we built a restricted tier, required 30-day data retention, and red-teamed safeguards for thousands of hours. Dario Amodei has argued, in writing, that "the government should have the power to block or deter deployment" of models presenting unacceptable risk. You cannot spend years telling Washington your product is a national security concern and then act surprised when Washington treats it like one. The HN thread is full of this take, and it is not wrong. It is just incomplete: scaremongering explains why the government had the framing available, not why it pulled the trigger on a finding this weak. For context on the capability everyone is arguing about, here is our hands-on breakdown of Fable 5:

## Theory 3: The Opening Move Toward ID-Gated AI Read the directive's scope again: no access for any foreign national, anywhere, including inside the US. There is no way to comply with that other than identity verification of every user. If that requirement sticks, the infrastructure it forces into existence is the interesting part. Age verification regimes are already normalizing ID checks for online services, and there is pending legislation pushing ID requirements for AI. A nationality-based access rule for frontier models would make KYC for top-tier AI access the default, with "the good models" sitting behind identity checks while everyone else gets the capped tier. This directive may be less about Fable specifically and more about establishing that access to frontier capability is a privilege the government can scope to persons. ## Theory 4: It Is Exactly What It Says The least popular theory deserves a fair shake: someone in the national security apparatus saw a demonstration of an autonomous model finding software vulnerabilities at scale, did not have the context to know that capability is already commodity, and escalated. Bureaucracies pattern-match. "AI autonomously discovers exploits" reads as a munition to people whose reference class is ITAR, not GitHub Copilot. ![Abstract systems illustration for Theory 4: It Is Exactly What It Says](/images/blog/why-the-us-government-pulled-fable-5/inline-2.webp) This is the dumbest explanation, which historically makes it a contender. It is also the most fixable, which lines up with Anthropic calling it "a misunderstanding" and expecting restoration. ## One More Data Point Worth flagging, though we cannot confirm it is connected: within hours of the suspension, the well-known jailbreaker Pliny (@elder_plinius) [posted](https://x.com/elder_plinius/status/2064776322979676227) that a coordinated effort had broken Fable 5's safeguards, claiming uplift across cyber, chem, and other restricted categories. The described method was decomposition and recomposition, splitting a harmful request into benign-looking chunks and reassembling the answer, combined with out-of-distribution tokens and long-context tricks. We are not sure whether this is the demonstration that prompted the directive, an unrelated coincidence of timing, or simply the kind of non-universal jailbreak Anthropic openly said would exist. Anthropic's own statement concedes no provider has perfect jailbreak resistance and that narrow bypasses are expected, so a public claim of one does not, by itself, validate the recall. But the timing is striking. And if the government's "demonstration" traces back to community red-teaming rather than a novel state-level capability, that strengthens Theory 1 and Theory 4: the finding was real but commodity, and the response was disproportionate. ## The Precedent Is the Point Whichever theory is right, the precedent now exists: the US government will recall a deployed commercial model, affecting hundreds of millions of users, on the basis of an undisclosed verbal report, with no statutory process. Anthropic asked for a transparent, technically grounded review power. It got an off switch. Every company betting its infrastructure on a closed frontier model just watched that switch get used. What that does to building on these models is the subject of [the follow-up post](/blog/model-dependency-risk-after-fable-5).

AWS Kiro Developer Guide: The Spec-Driven IDE That Replaced Amazon Q

Developers Digest — Thu, 11 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Kiro Homepage | [kiro.dev](https://kiro.dev) | | Kiro Documentation | [kiro.dev/docs](https://kiro.dev/docs) | | AWS Kiro Documentation | [aws.amazon.com/documentation-overview/kiro](https://aws.amazon.com/documentation-overview/kiro) | | Amazon Q Developer End-of-Support Announcement | [AWS DevOps Blog](https://aws.amazon.com/blogs/devops/amazon-q-developer-end-of-support-announcement/) | | Kiro GitHub | [github.com/kirodotdev/Kiro](https://github.com/kirodotdev/Kiro) | | Amazon Bedrock | [aws.amazon.com/bedrock](https://aws.amazon.com/bedrock) | AWS launched Kiro internationally on May 7, 2026 - not as a feature update to Amazon Q Developer, but as a ground-up replacement. If you are still using Q Developer IDE plugins or paid subscriptions, the end-of-support date is April 30, 2027. New signups stopped on May 15, 2026, and Opus 4.6 and later models are exclusive to Kiro as of May 29. This guide covers what Kiro does differently, how spec-driven development changes the workflow, pricing compared to Claude Code and Cursor, and the migration timeline for existing Q Developer users. **Last updated:** June 11, 2026 ## What Makes Kiro Different Kiro's central claim is that it brings engineering rigor to agentic development. Where most AI coding tools let you start from a prompt and iterate toward working code, Kiro requires structured specifications before any code generation can begin. This is not a minor UI difference. The IDE makes it structurally difficult to skip that step. When you enter a prompt, Kiro transforms it into a formal requirements document using EARS notation (Easy Approach to Requirements Syntax), generates architectural designs matched to your codebase analysis, and creates implementation plans with sequenced, requirement-mapped tasks. The practical effect: you cannot vibe-code your way through a Kiro session. Every feature has a paper trail. Every decision gets documented before code is written. For teams that need traceability, compliance, or simply want to understand what the AI decided and why, this matters. For context on where spec-driven development fits in the broader agentic coding landscape, see [What Is an AI Coding Agent?](/blog/what-is-an-ai-coding-agent-2026) and the [Best AI Coding Tools in June 2026](/blog/best-ai-coding-tools-june-2026-post-fable5). ## Three Interfaces, One Context Kiro ships with three interfaces that share steering files and learnings: **IDE** - A VS Code-compatible editor (settings, themes, and Open VSX plugins carry over) with an agent panel for multimodal chat, real-time code diffs, and approval workflows. This is where most development happens. **CLI** - Cross-platform installation via `curl -fsSL https://cli.kiro.dev/install | bash` (macOS/Linux) or `irm 'https://cli.kiro.dev/install.ps1' | iex` (Windows). The CLI supports headless execution for CI/CD pipelines and scripted workflows. **Web** - A browser-based interface with a feature the other two lack: autonomous mode. In the web interface, Kiro can execute multi-step tasks independently in cloud sandboxes that persist and coordinate with GitHub or GitLab. The shared context is the key. Steering files - markdown documents that define project patterns, conventions, and constraints - transfer across all three interfaces. What you teach Kiro in the IDE applies when you run tasks from the CLI or hand off work to the web's autonomous mode. ## Agent Hooks Kiro includes agent hooks - automated triggers that execute predefined agent actions when specific events occur. Instead of manually asking for routine tasks, hooks set up automated responses to file events. Example use cases: - Generate documentation when a new function is created - Run unit tests when a file is saved - Update type definitions when a schema file changes - Lint code before commits Hooks are defined in steering files and run in the background. This is Kiro's answer to the "agent babysitting" problem: common tasks happen automatically without prompting. ## Supported Models Kiro is built on Amazon Bedrock and routes between multiple foundation models: - **Claude Sonnet 4.5** - Primary model on the free tier - **Claude Opus 4.8** - Recently added for Pro tiers - **Auto mode** - Intelligently balances frontier models with caching for cost optimization The model routing matters. Kiro uses Claude Sonnet for reasoning-heavy spec generation and Amazon Nova for high-throughput code generation, switching models based on task type. This is similar to how [LLM routers](/blog/llm-router-comparison-2026) work in custom agent stacks, but Kiro handles the routing automatically. Notably, Opus 4.6 and later models are available exclusively on Kiro, not on Amazon Q Developer. The model cutoff date was May 29, 2026. ## Pricing | Tier | Monthly Cost | Credits | Models | Overage | |------|-------------|---------|--------|---------| | Free | $0 | 50 | Claude Sonnet 4.5 + open-weight | - | | Pro | $20 | 1,000 | Premium models | Pay-per-use | | Pro+ | $40 | 2,000 | Premium models | Pay-per-use | | Pro Max | $100 | 5,000 | Premium models | Pay-per-use | | Power | $200 | 10,000 | Premium models | Pay-per-use | *Prices verified June 11, 2026 on kiro.dev* The credit system means per-prompt visibility into what each task costs. Unlike flat-rate subscriptions where usage is opaque until you hit a limit, Kiro shows credit consumption as you work. Compared to competitors: Claude Code Pro at $20/month includes similar Claude model access but without the spec-driven workflow or agent hooks. Cursor Pro at $20/month offers IDE-integrated agent mode with model switching. The $19/month entry point positions Kiro competitively for AWS shops. For detailed cross-tool pricing, see [AI Coding Tools Pricing: June 2026](/blog/ai-coding-tools-pricing-2026). ## Language Support Python, Java, JavaScript, TypeScript, C#, Go, Rust, PHP, Ruby, Kotlin, C, C++, shell scripting, SQL, Scala, JSON, YAML, HCL. The HCL support matters for AWS infrastructure teams - Terraform workflows are a first-class use case. ## Amazon Q Developer Migration Timeline AWS published a clear end-of-support timeline: ![Abstract systems illustration for Amazon Q Developer Migration Timeline](/images/blog/aws-kiro-developer-guide-2026/inline-2.webp) | Date | What Changes | |------|--------------| | May 15, 2026 | New Q Developer signups blocked (existing subscriptions can add users) | | May 29, 2026 | Opus 4.6+ exclusive to Kiro; Q Developer remains on Opus 4.5 | | April 30, 2027 | Full end of support for Q Developer IDE plugins and paid subscriptions | What is not affected: Q Developer in the AWS Management Console, Docs website, Console Mobile App, and Chat Apps (Slack, Teams) continues unchanged. The 12-month migration window is generous, but the model cutoff date (May 29, 2026) is the practical deadline for teams that need access to the latest models. ## When Kiro Fits **Teams that need traceability.** If your compliance or audit requirements demand documented decisions before code changes, Kiro's spec-driven approach produces that paper trail by default. **AWS shops standardizing on Bedrock.** Kiro integrates with AWS authentication (Builder ID, IAM Identity Center) and billing. If you are already in the AWS ecosystem, the infrastructure story is cleaner than running Claude Code through a proxy. **Projects where specs exist but are ignored.** Kiro makes specs executable. The requirements document is not separate from the implementation - it is the input that drives the implementation. For teams where specs drift from code, this is a structural fix. **Developers who want hooks and automation.** If you find yourself repeating the same prompts after every file save, agent hooks automate that away. ## When It Does Not Fit **Solo developers who want fast iteration.** The spec-driven workflow adds friction to quick experiments. If you are prototyping and do not need documented requirements, Claude Code or Cursor will feel faster. **Teams invested in MCP ecosystems.** Kiro supports MCP, but the tooling depth around MCP is stronger in Claude Code. If your workflow depends heavily on third-party MCP servers, check compatibility first. **Non-AWS infrastructure.** The Bedrock dependency means Kiro's backend runs on AWS. If you are multi-cloud or avoid AWS, the architecture is less appealing than provider-neutral options like OpenCode. ## Getting Started Install the CLI: ```bash # macOS / Linux curl -fsSL https://cli.kiro.dev/install | bash # Windows (PowerShell) irm 'https://cli.kiro.dev/install.ps1' | iex ``` Authenticate with GitHub, Google, AWS Builder ID, or AWS IAM Identity Center. No AWS account is required for the free tier. Download the desktop IDE from [kiro.dev](https://kiro.dev) if you prefer the graphical interface over the CLI. ## FAQ ### What is Kiro and why did AWS build it? Kiro is AWS's new agentic IDE built on spec-driven development. AWS built it as a ground-up replacement for Amazon Q Developer, not as an update. The core difference is that Kiro requires structured specifications before generating code - transforming prompts into formal requirements, architectural designs, and sequenced implementation plans. Amazon Q Developer support ends April 30, 2027. ### How does spec-driven development differ from other AI coding tools? Most AI coding tools let you prompt and iterate freely. Kiro makes you define specifications first. Your prompt becomes a formal requirements document using EARS notation, then an architectural design, then an implementation plan. You cannot skip the spec step. The tradeoff is more upfront structure in exchange for documented decisions and better traceability. ### What models does Kiro use? Kiro is built on Amazon Bedrock and routes between Claude Sonnet 4.5, Claude Opus 4.8, and Amazon Nova depending on task type. The free tier includes Claude Sonnet 4.5 and open-weight models. Opus 4.6 and later models are exclusive to Kiro - they are not available on Amazon Q Developer as of May 29, 2026. ### How does Kiro pricing compare to Claude Code and Cursor? Kiro Pro starts at $20/month with 1,000 credits and per-prompt visibility. Claude Code Pro is $20/month with a usage cap. Cursor Pro is $20/month with usage-aware pricing. The credit model gives more transparency into per-task costs but introduces overage charges. Kiro's free tier (50 credits/month) is more limited than Cursor's free tier but includes Claude Sonnet 4.5. ### What are agent hooks? Agent hooks are automated triggers that execute agent actions when specific events occur - like file saves, commits, or new file creation. Instead of manually prompting for documentation updates or unit tests, hooks run those tasks automatically in the background. Hooks are defined in steering files and transfer across Kiro's IDE, CLI, and web interfaces. ### When should I migrate from Amazon Q Developer? New signups for Q Developer stopped May 15, 2026. Opus 4.6+ models became Kiro-exclusive May 29, 2026. Full end of support is April 30, 2027. If you need the latest models, the practical deadline was May 29. If you need feature parity, you have until April 2027, but the migration path is clearer the earlier you start. ### Does Kiro support MCP? Yes, Kiro has native Model Context Protocol (MCP) integration for connecting to external data sources. The support includes remote MCP for APIs, databases, and documentation. However, the MCP ecosystem is more mature around Claude Code, so check whether specific MCP servers you depend on work with Kiro. ### Is Kiro open source? The Kiro GitHub repository ([github.com/kirodotdev/Kiro](https://github.com/kirodotdev/Kiro)) is public, but Kiro is built on Amazon Bedrock, which is a managed AWS service. The IDE client is available for download; the backend runs on AWS infrastructure. ## Sources - AWS: [Amazon Q Developer end-of-support announcement](https://aws.amazon.com/blogs/devops/amazon-q-developer-end-of-support-announcement/) - April 30, 2026 - Kiro: [kiro.dev](https://kiro.dev) - accessed June 11, 2026 - Kiro: [Documentation](https://kiro.dev/docs) - accessed June 11, 2026 - AWS: [Kiro documentation overview](https://aws.amazon.com/documentation-overview/kiro/) - accessed June 11, 2026

Claude Agent SDK vs Claude Code: When to Build and When to Drive

Developers Digest — Thu, 11 Jun 2026 00:00:00 GMT

**Last updated:** June 14, 2026 ## Official Sources | Resource | Link | |----------|------| | Claude Agent SDK Overview | [code.claude.com/docs/en/agent-sdk/overview](https://code.claude.com/docs/en/agent-sdk/overview) | | Agent SDK Subagents | [code.claude.com/docs/en/agent-sdk/subagents](https://code.claude.com/docs/en/agent-sdk/subagents) | | Claude Code Documentation | [code.claude.com/docs](https://code.claude.com/docs) | | Claude Managed Agents | [platform.claude.com/docs/en/managed-agents/overview](https://platform.claude.com/docs/en/managed-agents/overview) | | Agent View (Background Sessions) | [code.claude.com/docs/en/agent-view](https://code.claude.com/docs/en/agent-view) | | Routines (Scheduled Automation) | [code.claude.com/docs/en/routines](https://code.claude.com/docs/en/routines) | | Dynamic Workflows | [code.claude.com/docs/en/workflows](https://code.claude.com/docs/en/workflows) | | Anthropic Pricing | [anthropic.com/pricing](https://www.anthropic.com/pricing) | Type "claude agent sdk vs" into a search bar and the autocomplete finishes the sentence for you. The confusion is understandable: both products run the same agent loop, share the same tools, and even share a binary. But they answer different questions, and in June 2026 the line got sharper. The short version: Claude Code is the interactive product you drive from a terminal. The [Claude Agent SDK](https://code.claude.com/docs/en/agent-sdk/overview) is that same harness packaged as a Python and TypeScript library you embed in your own software. And [Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview) is the third option, where Anthropic hosts the agent loop and the sandbox so you operate neither. This post draws the decision line between all three, using only what is in the official docs as of June 2026. ## The Short Answer - **Drive Claude Code** when a human is at the keyboard: exploring a codebase, pairing on a refactor, reviewing what an agent did before merging. - **Build with the Agent SDK** when software is at the keyboard: a CI job, a Slack bot, a product feature, a pipeline that calls `query()` and processes the message stream. - **Rent Managed Agents** when you want neither the terminal nor the process: Anthropic runs the loop and a sandbox per session, and your app talks to it over a REST API. Anthropic's own SDK docs draw the same line: interactive development and one-off tasks go to the CLI; CI/CD pipelines, custom applications, and production automation go to the SDK. Their words: "Many teams use both: CLI for daily development, SDK for production." For the full background on the CLI side, see our [complete guide to Claude Code](/blog/what-is-claude-code). If you are comparing across vendors rather than within Anthropic's stack, that is a different question - see [OpenAI Agents SDK vs Claude Agent SDK](/blog/openai-agents-sdk-vs-claude-agent-sdk). ## Head-to-Head: Claude Code vs Claude Agent SDK | Dimension | Claude Code (CLI) | Claude Agent SDK | |---|---|---| | What it is | Interactive terminal product | Library: `@anthropic-ai/claude-agent-sdk` (npm) or `claude-agent-sdk` (pip, Python 3.10+) | | Who orchestrates | You, conversationally, turn by turn | Your code, via `query()` options | | Subagents | Markdown files in `.claude/agents/` | Programmatic `AgentDefinition` objects (filesystem agents also load) | | Fleet management | Agent view dashboard, background sessions under a supervisor process | `Workflow` tool (TypeScript SDK v0.3.149+), resumable subagents | | Scheduling | Routines: schedule, API, and GitHub triggers on Anthropic-managed cloud | Your own cron, queue, or webhook calling the SDK or `claude -p` | | Permissions | Interactive prompts, plan approval, permission modes | `allowedTools`, `permissionMode`, hooks as in-process callbacks | | Subscription billing | Interactive plan limits | Separate monthly Agent SDK credit starting June 15, 2026 | | Auth for shipped products | Not applicable | API key required; claude.ai login may not be offered to your end users | ![Abstract systems illustration for Head-to-Head: Claude Code vs Claude Agent SDK](/images/blog/claude-agent-sdk-vs-claude-code/inline-1.webp) That last row matters if you are building a product: the SDK overview states that Anthropic does not allow third-party developers to offer claude.ai login or rate limits in their products unless previously approved. ## What Only the SDK Gives You ### Programmatic AgentDefinition In the CLI, subagents are markdown files. In the SDK, the recommended path is the `agents` parameter on `query()`: a dictionary of [`AgentDefinition`](https://code.claude.com/docs/en/agent-sdk/subagents) objects, each with a required `description` and `prompt`, plus optional `tools`, `disallowedTools`, `model` (aliases include `fable`, `opus`, `sonnet`, `haiku`, `inherit`), `skills`, `memory`, `mcpServers`, `maxTurns`, `background`, `effort`, and `permissionMode`. Because definitions are plain objects, you can build them with factory functions at request time - a stricter security reviewer on a bigger model for high-stakes runs, a cheaper one otherwise. Programmatic definitions take precedence over same-named filesystem agents. Two sharp edges from the docs: include `Agent` in `allowedTools` to auto-approve subagent invocations, and never give a subagent the `Agent` tool, because subagents cannot spawn their own subagents. The tool was also renamed from `Task` to `Agent` in Claude Code v2.1.63, and current SDK releases still emit `Task` in a few fields, so robust code checks both names. ### Resumable subagents When an SDK subagent completes, the Agent tool result includes an `agentId`. Capture it alongside the `session_id`, pass `resume: sessionId` on a later `query()` call, and reference the agent ID in your prompt: the subagent continues with its full prior history, including tool calls and reasoning. Transcripts persist separately from the main conversation, survive compaction, and are cleaned up after 30 days by default. The built-in Explore and Plan agents are one-shot and return no `agentId`. This is the building block for multi-step product flows where an analysis from request one informs a follow-up in request two. ### The Workflow tool Subagents handle a few delegated tasks per turn. For runs that coordinate dozens to hundreds of agents, the TypeScript SDK (v0.3.149 and later) exposes the `Workflow` tool: orchestration moves into a JavaScript script the runtime executes outside the conversation, with intermediate results held in script variables instead of Claude's context. The runtime caps runs at [16 concurrent agents and 1,000 agents total](https://code.claude.com/docs/en/workflows), which bounds the cost of a runaway script. Include `Workflow` in `allowedTools` to auto-approve runs. One more SDK-side fact worth planning around: starting June 15, 2026, Agent SDK and `claude -p` usage on subscription plans draws from a new monthly Agent SDK credit, separate from interactive limits (verified June 10, 2026 on the SDK overview page). We broke down the budgeting implications in [our Agent SDK credit meter analysis](/blog/claude-agent-sdk-credit-meter). ## What Only the CLI Gives You ### The interactive harness Permission prompts, plan approval, the `/workflows` progress view with per-agent token counts and pause/stop/restart keys, effort controls, and rewind. None of this exists when your code is the operator; in `claude -p` and the SDK there is nobody to prompt, so tool calls follow configured rules without interactive confirmation. ### Agent view [`claude agents`](https://code.claude.com/docs/en/agent-view) opens one dashboard for every background session across all your projects, grouped by needs-input, working, and completed. It is a research preview requiring v2.1.139 or later. Sessions run under a separate supervisor process, so they survive closing the terminal, machine sleep, and auto-updates. Dispatch from the view, from inside a session with `/bg`, or from the shell with `claude --bg "prompt"`. One honest caveat from the docs: each background session uses your subscription quota independently, so check your limits before dispatching many at once. ### Routines [Routines](https://code.claude.com/docs/en/routines) are the CLI ecosystem's answer to scheduled automation: a saved configuration of prompt, repositories, and connectors that runs on Anthropic-managed cloud infrastructure, so it keeps working when your laptop is closed. Triggers come in three flavors - a schedule, an authenticated HTTP endpoint, or GitHub events like `pull_request.opened` - and one routine can combine all three. Create them at claude.ai/code/routines or with `/schedule` in the CLI. Routines are a research preview on Pro, Max, Team, and Enterprise plans with Claude Code on the web enabled, with a daily per-account run cap. If your "I need the SDK" itch is really "I need this to run nightly without me," a routine may cover it with zero infrastructure. ## Managed Agents: The Hosted Third Option [Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview) is a pre-built agent harness running on Anthropic's infrastructure, in beta behind the `managed-agents-2026-04-01` header (set automatically by the SDKs, enabled by default for API accounts). You define an Agent (model, system prompt, tools, MCP servers, skills) once, pick an Environment (Anthropic cloud sandbox or a self-hosted sandbox on your own infrastructure), then start Sessions that stream events over SSE. ![Abstract systems illustration for Managed Agents: The Hosted Third Option](/images/blog/claude-agent-sdk-vs-claude-code/inline-2.webp) The official comparison against the Agent SDK is crisp: the SDK runs in your process on your infrastructure with session state as JSONL on your filesystem; Managed Agents runs on Anthropic's side with a managed sandbox per session and a hosted event log. Custom tools flip too - in-process functions with the SDK, an event round-trip with Managed Agents. The docs suggest the path many teams will follow: prototype locally with the SDK, move to Managed Agents for production when you do not want to operate sandboxes and session storage. One compliance note from the overview: because sessions are stateful by design, the beta is not currently eligible for Zero Data Retention or HIPAA BAA coverage. For how the hosted option stacks up against orchestration frameworks, see [Managed Agents vs LangGraph vs DIY](/blog/managed-agents-vs-langgraph-vs-diy-2026). ## Decision Guide by Persona - **Solo developer or daily driver.** Claude Code, full stop. The harness, agent view, and routines cover development, parallel background work, and nightly jobs without orchestration code. - **Platform engineer wiring agents into CI/CD.** The Agent SDK. `query()` with `allowedTools`, hooks for audit logging, and headless permission rules are built for pipelines. Budget against the new SDK credit on subscription plans. - **Product team shipping an agent feature.** Prototype with the SDK; evaluate Managed Agents for production if you do not want to own sandboxes or session storage. Our [TypeScript agent-building guide](/blog/how-to-build-ai-agents-typescript) walks the SDK path end to end. - **Automation owner who wants scheduled jobs with zero infra.** Routines first. Graduate to the SDK or Managed Agents when you outgrow the trigger model or the daily run cap. ## When to Skip the SDK, and When to Stay With the CLI Skip the SDK if your real need is a recurring job (routines), a one-off batch (`claude -p` in a script), or parallel work on your own machine (agent view). Reaching for a library when a built-in surface already does the job is how you end up maintaining orchestration code nobody asked for. Stay with the CLI even for automation-adjacent work when a human reviews every result anyway - dispatching ten background sessions through agent view is often faster than writing the harness to do the same. Go to the SDK without hesitation when there is no human at the keyboard: webhooks, CI gates, product features, anything needing programmatic AgentDefinitions, resumable subagents, or the Workflow tool at scale. And go in clear-eyed about maturity labels: agent view and routines are research previews; dynamic workflows are available on all paid plans but require Claude Code v2.1.154 or later, with a `/config` toggle on Pro; Managed Agents is a beta with the ZDR and HIPAA caveats above. The core CLI and the SDK `query()` surface are the stable ground. ## FAQ ### Is the Claude Agent SDK the same as Claude Code? They share the same engine - the SDK was formerly called the Claude Code SDK, and the TypeScript package bundles a native Claude Code binary - but they are different surfaces. Claude Code is the interactive terminal product; the Agent SDK exposes the same tools, agent loop, and context management as a Python and TypeScript library for your own applications. ### Does the Claude Agent SDK use my Claude subscription? Starting June 15, 2026, Agent SDK and `claude -p` usage on subscription plans draws from a separate monthly Agent SDK credit rather than your interactive usage limits, per the official SDK overview. API-key usage bills through the API as usual. Shipped products must use API key authentication; offering claude.ai login to your users is not permitted without prior approval. ### Can the Claude Agent SDK spawn subagents like Claude Code? Yes, and more flexibly: define them programmatically with `AgentDefinition` objects, load the same `.claude/agents/` markdown files Claude Code uses, or rely on the built-in `general-purpose` agent. SDK subagents are also resumable across queries via the returned `agentId` plus session resume. The one hard limit: subagents cannot spawn their own subagents. ### What is the difference between the Agent SDK and Managed Agents? The Agent SDK is a library that runs the agent loop inside your process, on your infrastructure, with state on your filesystem. Managed Agents is a hosted REST API where Anthropic runs the loop and a sandbox per session and persists the event log server-side. Anthropic recommends prototyping with the SDK and considering Managed Agents for production. ### Should I use routines or the Agent SDK for scheduled agent jobs? Routines, if the job fits their trigger model: cron schedules, an authenticated HTTP endpoint, or GitHub events, all running on Anthropic-managed cloud with no servers to maintain. Choose the SDK when you need custom orchestration, in-process tools, your own infrastructure, or volumes beyond the routine daily run cap. ## Sources - Agent SDK overview - Claude Docs: https://code.claude.com/docs/en/agent-sdk/overview (accessed June 10, 2026) - Subagents in the SDK - Claude Docs: https://code.claude.com/docs/en/agent-sdk/subagents (accessed June 10, 2026) - Building agents with the Claude Agent SDK - Anthropic: https://claude.com/blog/building-agents-with-the-claude-agent-sdk (accessed June 10, 2026) - Manage multiple agents with agent view - Claude Code Docs: https://code.claude.com/docs/en/agent-view (accessed June 10, 2026) - Automate work with routines - Claude Code Docs: https://code.claude.com/docs/en/routines (accessed June 10, 2026) - Orchestrate subagents at scale with dynamic workflows - Claude Code Docs: https://code.claude.com/docs/en/workflows (accessed June 10, 2026) - Claude Managed Agents overview - Claude Platform Docs: https://platform.claude.com/docs/en/managed-agents/overview (accessed June 10, 2026)

Claude Agent SDK vs LangGraph: Choosing Your Agent Stack in 2026

Developers Digest — Thu, 11 Jun 2026 00:00:00 GMT

## Official Sources | Resource | Link | |----------|------| | Claude Agent SDK Overview | [code.claude.com/docs/en/agent-sdk/overview](https://code.claude.com/docs/en/agent-sdk/overview) | | LangGraph Overview | [docs.langchain.com/oss/python/langgraph/overview](https://docs.langchain.com/oss/python/langgraph/overview) | | LangGraph Persistence | [docs.langchain.com/oss/python/langgraph/persistence](https://docs.langchain.com/oss/python/langgraph/persistence) | | LangSmith Pricing | [langchain.com/pricing](https://www.langchain.com/pricing) | | Claude API Pricing | [platform.claude.com/docs/en/about-claude/pricing](https://platform.claude.com/docs/en/about-claude/pricing) | | Agent SDK Subscription Credits | [support.claude.com](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan) | --- **Last updated:** June 11, 2026 "Claude Agent SDK vs LangGraph" looks like a framework beauty contest, but the two tools answer different questions. The [Claude Agent SDK](https://code.claude.com/docs/en/agent-sdk/overview) is the Claude Code engine packaged as a library: an opinionated, batteries-included harness where Anthropic owns the agent loop and you steer it. [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview) is a low-level orchestration runtime where you own the loop, the state schema, and every edge in the graph - and it works with any model provider. Both are production-grade in mid-2026. The choice comes down to how much of the agent you want to build versus inherit, whether Claude-only is acceptable, and where you want operational costs to land. ## What each one actually is The Claude Agent SDK (`npm install @anthropic-ai/claude-agent-sdk`, `pip install claude-agent-sdk`, Python 3.10+) gives you, per Anthropic's docs, "the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript." The primary interface is `query()`: you pass a prompt and an `allowedTools` list, and the agent loop runs to completion. Built-in tools ship in the box - Read, Write, Edit, Bash, Glob, Grep, WebSearch, WebFetch, Monitor, and AskUserQuestion - so a working coding or research agent is a few lines, not a few sprints. The TypeScript package even bundles a native Claude Code binary so there is nothing else to install. It is governed by Anthropic's Commercial Terms of Service, not an open-source license, and in practice it runs Claude models only. LangGraph (`pip install -U langgraph`, with a JS/TS sibling) describes itself as "a low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents." You define a `StateGraph` with typed state, add nodes (plain functions), wire edges including conditional ones, compile, and invoke. There are no built-in file or shell tools; you bring your own. It is MIT-licensed, model-agnostic, and LangChain's site lists Klarna, LinkedIn, Uber, and Nvidia among its users. Notably, LangChain's own docs steer newcomers toward the higher-level LangChain agent module - LangGraph is positioned for teams that want low-level control. ## Head-to-head | | Claude Agent SDK | LangGraph | |---|---|---| | What it is | Claude Code engine as a library | Graph orchestration framework + runtime | | Who owns the loop | Anthropic's harness; the model decides next steps | You; the graph defines next steps | | Languages | Python, TypeScript | Python, JavaScript/TypeScript | | Models | Claude only (API, Bedrock, Vertex, Azure Foundry, Claude Platform on AWS) | Any provider | | Built-in tools | Read, Write, Edit, Bash, Grep, WebSearch, WebFetch, and more | None; bring your own | | State | Sessions as JSONL on your filesystem; resume and fork by session ID | Checkpointers (in-memory, SQLite, Postgres); threads, time travel, forking | | Multi-agent | Subagents via `AgentDefinition` + the Agent tool | Any topology you can draw: supervisor, hierarchical, swarm | | Lifecycle control | Hooks (`PreToolUse`, `PostToolUse`, `Stop`, etc.) + permission modes | You write the nodes, so control is total | | License | Anthropic Commercial Terms of Service | MIT | | Hosted deployment | Pair with Claude Managed Agents | LangSmith Deployment, hybrid, or self-hosted | | Library cost | Free; you pay Claude tokens | Free; you pay tokens + optional LangSmith | ![Abstract systems illustration for Head-to-head](/images/blog/claude-agent-sdk-vs-langgraph/inline-1.webp) ## Architecture: who owns the loop This is the real fork in the road. With the Claude Agent SDK, the loop is prompt-driven: Claude reads the task, picks tools, recovers from errors, and compacts its own context. Your control surface is configuration - `allowedTools`, `permission_mode`, hooks that can log, block, or transform any tool call, and filesystem conventions Claude Code users already know (CLAUDE.md memory, `.claude/skills/`, MCP servers, plugins). You get an enormous amount of agent engineering for free, at the cost of the loop being a black box you steer rather than code you step through. LangGraph inverts that. Nothing happens unless a node does it, and nothing transitions unless an edge allows it. That explicitness is why regulated and high-volume teams like it: every step is inspectable, testable, and replayable. It is also why the first week feels slower - you are implementing tool execution, retry policies, and context management that the Agent SDK ships as defaults. If you want the deeper "who should own your loop" framing, including the plain while-loop option, see our [managed agents vs LangGraph vs DIY breakdown](/blog/managed-agents-vs-langgraph-vs-diy-2026). ## State handling: sessions vs checkpoints The Claude Agent SDK persists sessions as JSONL on your filesystem. Capture the `session_id` from the init message, pass `resume` later, and the agent continues with full context; you can also fork a session to explore alternatives. It is simple and good enough for most single-agent products, but the state is a conversation transcript, not a typed object you can query mid-run. LangGraph treats state as the product. A checkpointer snapshots the typed graph state at every super-step, organized into threads by `thread_id`. Swap `InMemorySaver` for `PostgresSaver` and runs survive process restarts. You can replay from any `checkpoint_id`, fork alternate trajectories, and pick a durability mode (`exit`, `async`, `sync`) that trades write latency against crash recovery. A separate `Store` interface persists memory across threads with namespacing and semantic search. If your agent runs for hours, pauses for human approval, or must resume from step 7 of 12 after a deploy, this machinery is the whole reason LangGraph exists. Honest read: LangGraph wins state handling on capability; the Agent SDK wins on how little of it you have to think about. ## Multi-agent patterns The Agent SDK's multi-agent story is subagents. You define named agents programmatically (`agents={"code-reviewer": AgentDefinition(...)}`), include `Agent` in `allowedTools`, and the orchestrating Claude delegates and synthesizes results. Messages carry a `parent_tool_use_id` for tracing. It is an orchestrator-worker pattern: clean, traceable, and deliberately constrained - subagents report back to the caller rather than talking to each other. LangGraph imposes no pattern at all. Supervisor trees, hierarchical teams, peer-to-peer handoffs, voting panels - if you can draw it as a graph, you can build it, and the shared state object is the communication channel. That freedom is genuine, and so is the design burden that comes with it. For the TypeScript-flavored version of this tradeoff, our [Mastra vs LangGraph JS comparison](/blog/mastra-vs-langgraph-js-2026) covers how other frameworks package the same primitives. ## Pricing implications Both libraries are free to use. The bills arrive from different directions. ![Abstract systems illustration for Pricing implications](/images/blog/claude-agent-sdk-vs-langgraph/inline-2.webp) With the Claude Agent SDK you pay Claude token costs: Sonnet 4.6 at $3 input / $15 output per million tokens, Opus 4.8 at $5/$25, Fable 5 at $10/$50, with cache reads at 0.1x input price, per [Anthropic's pricing page](https://platform.claude.com/docs/en/about-claude/pricing). The harness leans on prompt caching aggressively, which matters for long agent loops. One notable change: starting June 15, 2026, Agent SDK and `claude -p` usage on subscription plans draws from a separate monthly Agent SDK credit - $20 on Pro, $100 on Max 5x, $200 on Max 20x - that does not eat your interactive limits, per [Anthropic's support article](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan). API key users keep standard pay-as-you-go billing. Hosting is your problem (or Claude Managed Agents at standard token rates plus $0.08 per session-hour; our [Managed Agents honest review](/blog/claude-managed-agents-honest-review) covers that path). With LangGraph you pay whatever your model provider charges - and being model-agnostic is itself a cost lever, since you can route steps to cheap models from any vendor. Self-hosting the runtime is free. The paid layer is [LangSmith](https://www.langchain.com/pricing): a free Developer tier with 5,000 base traces per month (then $2.50 per 1,000), Plus at $39 per seat per month with one dev-sized deployment included, and managed deployments metered at $0.0007 per minute of uptime for dev and $0.0036 per minute for production, plus $0.005 per deployment run. None of it is mandatory, but most serious LangGraph teams end up paying for observability somewhere. ## Persona decision guide **Solo dev or small team shipping a Claude-based product fast:** Agent SDK. The built-in tools, permissions, and session handling collapse weeks of harness work, and the new subscription credit makes prototyping nearly free if you already pay for Pro or Max. **Platform team with multi-model requirements or vendor-risk rules:** LangGraph. Claude-only is a hard architectural commitment with the Agent SDK; LangGraph lets you route per-step and renegotiate later. **Team building long-running, interrupt-heavy workflows (approvals, pauses, replays):** LangGraph. Checkpoint-level resume, time travel, and durable execution modes are exactly this use case. **Team whose agent is fundamentally "Claude working in a repo or filesystem":** Agent SDK. It is the Claude Code engine; nothing else matches it for coding-agent ergonomics. If you are weighing it against the CLI itself, see [Claude Agent SDK vs Claude Code](/blog/claude-agent-sdk-vs-claude-code). **Team already on OpenAI's stack:** neither answer here is complete - read our [OpenAI Agents SDK vs Claude Agent SDK comparison](/blog/openai-agents-sdk-vs-claude-agent-sdk) first. ## When to skip both Skip both if a single model call with the tool runner in the regular Anthropic client SDK does the job - classification, extraction, a two-tool lookup. An agent harness is overhead there. Skip both if you want zero infrastructure: Claude Managed Agents runs the loop and sandbox for you behind a REST API. And skip LangGraph specifically if you want a higher-level abstraction - LangChain's own docs now point beginners to the LangChain agent module, and frameworks like Mastra or the Vercel AI SDK cover the middle ground with less ceremony. ## FAQ ### Claude Agent SDK vs LangGraph: which should I use for production agents? Use the Claude Agent SDK when your agent is Claude-centric and you want a proven harness with built-in tools, permissions, and sessions. Use LangGraph when you need explicit control over the execution graph, durable checkpointed state, custom multi-agent topologies, or the freedom to mix model providers. The Agent SDK gives you a finished loop; LangGraph gives you the materials to build one. ### Is the Claude Agent SDK free to use? The library itself is free under Anthropic's Commercial Terms of Service; you pay for Claude tokens. From June 15, 2026, subscription plans include a separate monthly Agent SDK credit ($20 Pro, $100 Max 5x, $200 Max 20x) so SDK usage does not consume interactive limits. API key usage bills at standard per-token rates. ### Can LangGraph use Claude models? Yes. LangGraph is model-agnostic, and Claude models work through the Anthropic integration (or Bedrock and Vertex). You get LangGraph's orchestration and persistence, but not the Agent SDK's built-in tools, context compaction, or Claude Code filesystem conventions - you implement those yourself. ### Does the Claude Agent SDK work with non-Anthropic models? No. It is the Claude Code engine and runs Claude models, whether via the Claude API, Amazon Bedrock, Google Vertex AI, Microsoft Foundry, or Claude Platform on AWS. If multi-provider routing is a requirement, that alone decides the comparison in LangGraph's favor. ### Is LangGraph open source? Yes, LangGraph is MIT-licensed and free to self-host in both Python and JavaScript. The paid products are LangSmith observability and LangSmith Deployment; both are optional. ## Sources - [Claude Agent SDK overview - code.claude.com](https://code.claude.com/docs/en/agent-sdk/overview) (accessed June 11, 2026) - [LangGraph overview - docs.langchain.com](https://docs.langchain.com/oss/python/langgraph/overview) (accessed June 11, 2026) - [LangGraph persistence - docs.langchain.com](https://docs.langchain.com/oss/python/langgraph/persistence) (accessed June 11, 2026) - [LangGraph product page - langchain.com](https://www.langchain.com/langgraph) (accessed June 11, 2026) - [LangSmith pricing - langchain.com](https://www.langchain.com/pricing) (accessed June 11, 2026) - [Claude API pricing - platform.claude.com](https://platform.claude.com/docs/en/about-claude/pricing) (accessed June 11, 2026) - [Use the Claude Agent SDK with your Claude plan - support.claude.com](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan) (accessed June 11, 2026)

Claude Agents vs Skills: Which One Do You Actually Need?

Thu, 11 Jun 2026 00:00:00 GMT

| Official Sources | | |:--|:--| | [Claude Code Skills Documentation](https://code.claude.com/docs/en/skills) | Skill format, triggers, and progressive disclosure | | [Claude Code Subagents Documentation](https://code.claude.com/docs/en/sub-agents) | Subagent creation and configuration | | [Claude Code Workflows Documentation](https://code.claude.com/docs/en/workflows) | Comparison table and composition patterns | | [Agent SDK Overview](https://code.claude.com/docs/en/agent-sdk/overview) | Building agents as applications | | [Agent Skills Open Standard](https://agentskills.io) | Cross-platform skill format specification | | [Anthropic Engineering: Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) | Design rationale and best practices | **Last updated:** June 11, 2026 Type "claude agents" into a search box and autocomplete offers "vs skills" almost immediately. Understandable: both are folders of markdown under `.claude/`, both have YAML frontmatter with a `description` field, and both get picked up automatically when Claude decides they are relevant. They are not the same thing. Anthropic's own comparison table draws the line in four words or fewer: a subagent is "a worker Claude spawns," and a skill is "instructions Claude follows." One is a separate worker with its own context window. The other is a playbook loaded into the conversation you are already having. Once that clicks, every other difference - cost, file format, invocation, composition - falls out of it. Here is the distinction, a head-to-head table, and a decision guide by use case. ## First, Untangle the Word "Agent" Part of the confusion is that "agent" means at least three different things in the Claude ecosystem: **Subagents** are workers your Claude Code session spawns for side tasks. Each runs in its own context window with a custom system prompt, its own tool access, and independent permissions. The docs' pitch is precise: use one "when a side task would flood your main conversation with search results, logs, or file contents you won't reference again." The subagent does the messy exploration in its own context and returns only a summary. You define one as a markdown file in `.claude/agents/` (project) or `~/.claude/agents/` (personal); only `name` and `description` are required. Claude Code also ships built-ins: Explore for fast read-only codebase search, Plan, and a general-purpose agent. **Agent SDK agents** are full applications you build with the [Claude Agent SDK](https://code.claude.com/docs/en/agent-sdk/overview), which packages "the same tools, agent loop, and context management that power Claude Code" as a Python or TypeScript library. When someone says they "built a Claude agent," this is usually what they mean: a program that calls `query()` with a prompt and allowed tools, then lets Claude work autonomously. SDK agents can define their own subagents through an `agents` option, so the two meanings nest. If you are weighing the SDK against the CLI itself, see [Claude Agent SDK vs Claude Code](/blog/claude-agent-sdk-vs-claude-code). **Agent teams and background agents** are Claude Code's larger-scale parallelism surfaces, a separate topic covered in [subagents vs agent teams vs workflows](/blog/claude-code-subagents-vs-agent-teams-vs-workflows). For the agents-vs-skills question, the first two meanings matter, and they share the defining property: an agent is an executor with its own context, separate from yours. ## What Skills Actually Are A skill is a folder containing a `SKILL.md` file - that is the core of the format, per the [Agent Skills open standard](https://agentskills.io) Anthropic released and other agent products have adopted. The file holds YAML frontmatter telling Claude when to use the skill, plus markdown instructions to follow when it runs, optionally bundling scripts, templates, and reference docs. ![Abstract systems illustration for What Skills Actually Are](/images/blog/claude-agents-vs-skills/inline-1.webp) The design center is progressive disclosure, which the standard defines in three stages: at startup the agent loads only each skill's name and description, when a task matches it reads the full `SKILL.md` into context, and during execution it optionally runs bundled code or loads referenced files. Anthropic's engineering team frames it memorably: "Building a skill for an agent is like putting together an onboarding guide for a new hire." The economics follow from that design. The Claude Code docs note that "a skill's body loads only when it's used, so long reference material costs almost nothing until you need it" - which is exactly why a procedure that has outgrown CLAUDE.md belongs in a skill. Skills live at `~/.claude/skills//SKILL.md` (personal), `.claude/skills/` (project), or inside plugins, and the directory name becomes a slash command: a `deploy-staging` skill is invocable as `/deploy-staging`. Custom commands have been merged into this system entirely; `.claude/commands/deploy.md` and `.claude/skills/deploy/SKILL.md` both create `/deploy` and work the same way. The crucial contrast with agents: when a skill runs, its content enters your current conversation as a message and stays there for the rest of the session. Nothing spawns. No separate context exists. The skill is not a worker; it is the playbook the current worker reads. If you are new to the format, the [beginner guide to Claude Code skills](/blog/what-are-claude-code-skills-beginner-guide) walks through building your first one. ## Head-to-Head: Agents vs Skills The first two rows come straight from the comparison table in the official workflows doc; the rest are assembled from the subagents and skills pages. | | Subagents (agents) | Skills | |---|---|---| | What it is | A worker Claude spawns | Instructions Claude follows | | Who decides what runs next | Claude, turn by turn | Claude, following the prompt | | Context | Own context window, own system prompt | Loads into your current conversation and stays there | | File format | Markdown in `.claude/agents/`, `name` and `description` required | `SKILL.md` in `.claude/skills//`, all frontmatter optional | | What comes back | A summary of the work, not the intermediate noise | Nothing comes back; the work happens in your session | | Model control | `model` frontmatter routes to `haiku`, `sonnet`, `opus`, `fable`, or `inherit` | `model` field overrides only for the rest of the current turn | | Direct invocation | Claude delegates based on `description` | `/skill-name`, or Claude loads it based on `description` | | Cost profile | Keeps your main context clean; burns its own tokens per spawn | Cheap until invoked; body then occupies context every turn | | Best at | Isolation: research, log-digging, parallel side tasks | Repeatability: procedures, conventions, checklists | Two cost details before you build a library of either. Skill listings truncate the combined `description` and `when_to_use` text at 1,536 characters, so front-load the trigger conditions. And after auto-compaction, Claude Code re-attaches only the first 5,000 tokens of each invoked skill within a shared 25,000-token budget, so a sprawling skill body gets clipped in long sessions. Subagents have the inverse profile: the parent conversation stays small, but every spawn is a fresh context paying its own way. ## The Real Answer: They Compose The framing "agents vs skills" suggests a choice. The docs describe a composition, in both directions: **Skills preloaded into agents.** A subagent definition can carry a `skills` field, and "the full content of each listed skill is injected into the subagent's context at startup." Your `api-developer` subagent starts life already knowing the team's API conventions and error-handling patterns, without discovering them mid-task. **Skills that run as agents.** A skill can set `context: fork` in its frontmatter, and the skill content becomes the prompt driving a subagent, isolated from your conversation history. Pair it with `agent: Explore` and your research procedure runs in a cheap read-only worker that never touches your main context. The Agent SDK keeps the same composition in application code: SDK agents load skills from `.claude/skills/*/SKILL.md`, and `AgentDefinition` accepts a `skills` list for preloading. The mature pattern is not choosing one primitive - it is encoding knowledge as skills, workers as agents, and wiring them together, the layering visible in [the best Claude Code skills of 2026](/blog/best-claude-code-skills-2026), where many top skills are thin orchestration layers over subagents. ## Decision Guide by Use Case **You keep pasting the same instructions into chat.** Skill. This is the docs' literal trigger condition: "you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact." ![Abstract systems illustration for Decision Guide by Use Case](/images/blog/claude-agents-vs-skills/inline-2.webp) **Codebase exploration keeps flooding your context.** Subagent. Let Explore or a custom read-only worker absorb the search results and hand back three sentences. **You want team conventions enforced in every session.** Project skills, checked into `.claude/skills/` in the repo. Everyone who clones gets them, and live change detection picks up edits without a restart. **You are building a product feature on Claude.** Agent SDK. A skill cannot ship as your backend; the SDK is the library form of the whole harness. Note that starting June 15, 2026, SDK and `claude -p` usage on subscription plans draws from a separate monthly Agent SDK credit. **You want a task done with different tools or a cheaper model.** Subagent, since `tools`, `disallowedTools`, and `model` are per-worker controls. Routing side tasks to Haiku is one of the docs' listed reasons subagents exist. **You want a dangerous procedure that only runs when you say so.** Skill with `disable-model-invocation: true`. It becomes a manual slash command Claude cannot trigger on its own. ## When to Skip Both Honest scoping, because neither primitive is free to maintain: - **It is a fact, not a procedure.** "We use pnpm, not npm" belongs in CLAUDE.md. Skills earn their keep for multi-step processes, not one-line preferences. - **It is a one-off.** A task you will run once is a prompt. Write the skill the second or third time you type the same thing. - **You need scale, not delegation.** Subagents handle "a few delegated tasks per turn" per the official table. A 500-file migration or fan-out audit is workflow territory - dozens to hundreds of agents driven by a script, a different primitive entirely. - **Your commands already work.** Files in `.claude/commands/` keep working under the merged system. Migrate to skill directories when you want supporting files or invocation control, not before. ## FAQ ### What is the difference between Claude agents and skills? The short version of claude agents vs skills: an agent (subagent or Agent SDK agent) is a worker that runs in its own context window and returns results to you, while a skill is a `SKILL.md` file of instructions that loads into the current conversation when relevant. Agents isolate work; skills standardize it. ### Are Claude Code subagents and skills the same thing? No. Both are markdown with YAML frontmatter, but subagents live in `.claude/agents/` and spawn a separate context with their own system prompt and tool access, while skills live in `.claude/skills/` and inject instructions into the session you are already in. ### Can a Claude agent use skills? Yes, in two directions. A subagent's `skills` frontmatter field preloads full skill content into the worker at startup, and a skill with `context: fork` runs its own content as the prompt for a subagent. Subagents can also discover and invoke skills through the Skill tool during execution. ### Do skills work with the Claude Agent SDK? Yes. The Agent SDK loads skills from `.claude/skills/*/SKILL.md` in the working directory and home directory by default, controllable via the `settingSources` option. Skills follow the Agent Skills open standard, so the same folder works across Claude Code, the SDK, and other compatible agent products. ### Should I build a skill or an agent first? Build the skill first if your pain is repetition (re-explaining a procedure every session). Build the subagent first if your pain is context pollution (exploration burying your conversation). Most teams end up with both, wired together through the `skills` field. ## Sources - [Extend Claude with skills - Claude Code docs](https://code.claude.com/docs/en/skills) - accessed June 11, 2026 - [Create custom subagents - Claude Code docs](https://code.claude.com/docs/en/sub-agents) - accessed June 11, 2026 - [Orchestrate subagents at scale with dynamic workflows - Claude Code docs](https://code.claude.com/docs/en/workflows) - accessed June 11, 2026 (source of the comparison table) - [Agent SDK overview - Claude Docs](https://code.claude.com/docs/en/agent-sdk/overview) - accessed June 11, 2026 (platform.claude.com/docs/en/agent-sdk/overview redirects here) - [Agent Skills open standard](https://agentskills.io) - accessed June 11, 2026 - [Equipping agents for the real world with Agent Skills - Anthropic Engineering](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) - accessed June 11, 2026

Claude Code Auto Mode Explained: Permissions Without the Prompts

Developers Digest — Thu, 11 Jun 2026 00:00:00 GMT

## Official Sources | Source | Link | |--------|------| | Claude Code Permission Modes | [code.claude.com/docs/en/permission-modes](https://code.claude.com/docs/en/permission-modes) | | Claude Code What's New (Week 21) | [code.claude.com/docs/en/whats-new/2026-w21](https://code.claude.com/docs/en/whats-new/2026-w21) | | Claude Code Changelog | [github.com/anthropics/claude-code/blob/main/CHANGELOG.md](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) | | Claude Code Settings Reference | [code.claude.com/docs/en/settings](https://code.claude.com/docs/en/settings) | | Claude Code Security Model | [code.claude.com/docs/en/security](https://code.claude.com/docs/en/security) | **Last updated:** June 20, 2026 Permission prompts are the tax you pay for letting an agent touch your filesystem. Claude Code's auto mode is Anthropic's bet that a second model can pay that tax for you: a safety classifier reviews every action in the background and only blocks the ones that look irreversible, destructive, or aimed outside your environment. Auto mode has been quietly expanding for months. It [reached the Pro plan in Week 21](https://code.claude.com/docs/en/whats-new/2026-w21) (v2.1.143 to v2.1.149, May 18 to 22) after an early flag-gated period and a Max-first rollout, and it now works with Sonnet 4.6 alongside Opus. Along the way it picked up a real configuration surface: `hard_deny` rules nothing can override, prose-based environment trust lists, and glob deny patterns that fire before the classifier ever runs. Here is how it all fits together, verified against the current docs and changelog. ## What Auto Mode Actually Is The [permission modes reference](https://code.claude.com/docs/en/permission-modes) describes six modes. In `default` mode only reads run without asking. In `acceptEdits`, file edits and common filesystem commands are auto-approved. For `auto`, the docs' summary is blunt: "Everything, with background safety checks." The recommended use case is long tasks and reducing prompt fatigue. The mechanism: auto mode routes tool calls through a classifier model that blocks anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read. That last clause is the prompt-injection defense - if a fetched page tells Claude to exfiltrate your `.env`, the classifier should notice the action matches nothing you asked for. Three things auto mode is not: - **Not bypassPermissions.** Bypass skips checks entirely; the docs say to use it only in isolated containers and VMs. Auto mode keeps a gate, just moved from your keyboard to a model. - **Not a permissions replacement.** Deny rules and explicit `ask` rules are evaluated before the classifier and still block or prompt in every mode. - **Not GA.** The docs label it a research preview that "reduces prompts but does not guarantee safety." Use it for tasks where you trust the general direction. Auto mode also nudges Claude to keep working instead of stopping for clarifying questions, which is exactly what you want for the long unattended sessions covered in [running Claude Code autonomously for hours](/blog/claude-code-autonomous-hours). ## Who Gets It: Plans, Models, Providers As of June 11, 2026, the [current requirements](https://code.claude.com/docs/en/permission-modes) are: - **Plan:** all plans. The [changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) shows the rollout order: Max subscribers got it in v2.1.111, the Pro plan followed in Week 21. On Team and Enterprise, an admin must enable it first, and admins can lock it off with `permissions.disableAutoMode: "disable"` in managed settings. - **Model:** on the Anthropic API, Claude Opus 4.6 or later, or Sonnet 4.6. Older models, including Sonnet 4.5 and Haiku, are not supported on any provider. - **Provider:** on by default on the Anthropic API. On Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry, auto mode shipped in v2.1.158 for Opus 4.7 and 4.8 only, and stays hidden until you set `CLAUDE_CODE_ENABLE_AUTO_MODE=1`. - **Version:** Claude Code v2.1.83 or later. If Claude Code reports auto mode as unavailable, one of those requirements is unmet; the docs are explicit that this is not a transient outage. ## Shift+Tab: How the Mode Cycle Works In the CLI, Shift+Tab cycles `default` to `acceptEdits` to `plan`. Auto mode is not in that base cycle. Per the [permission modes docs](https://code.claude.com/docs/en/permission-modes), it appears once your account meets the requirements, and cycling to it shows an opt-in prompt until you accept it. Selecting "No, don't ask again" removes auto from the cycle entirely. The ordering is specific: enabled optional modes slot in after `plan`, with `bypassPermissions` first and `auto` last. So if you started with `--allow-dangerously-skip-permissions`, you cycle through bypass on the way to auto. `dontAsk` never appears in the cycle; it is flag-only. Two details worth knowing: - **Agent sessions cycle too.** Since v2.1.143, Shift+Tab inside attached `claude agents` sessions includes auto mode, so background workers can be flipped into auto without restarting. - **A repo cannot grant itself auto mode.** Since v2.1.142, Claude Code ignores `defaultMode: "auto"` in `.claude/settings.json` and `.claude/settings.local.json`. To start in auto by default, the setting must live in user-level `~/.claude/settings.json` or managed settings: ```json { "permissions": { "defaultMode": "auto" } } ``` This is the same trust-boundary thinking that runs through the whole feature: project files are attacker-influenced input, so they do not get to loosen your permissions. ## The Four-Tier Rule Stack: hard_deny, soft_deny, allow, intent The classifier is configurable through the `autoMode` settings block, documented on the [configure auto mode page](https://code.claude.com/docs/en/auto-mode-config). The headline addition is `hard_deny`, which landed in v2.1.136: rules that block unconditionally, regardless of user intent or allow exceptions. Precedence works in four tiers: 1. **`hard_deny`** blocks unconditionally. Nothing overrides it. 2. **`soft_deny`** blocks next, but user intent and allow exceptions can clear it. 3. **`allow`** rules override matching soft_deny rules as exceptions. 4. **Explicit user intent** overrides remaining soft blocks - but only when your message directly describes the exact action. The docs draw the line cleanly: asking Claude to "clean up the repo" does not authorize a force-push, but asking it to "force-push this branch" does. The surprising part: these are prose, not patterns. You write them the way you would describe your infrastructure to a new engineer: ```json { "autoMode": { "environment": [ "$defaults", "Source control: github.example.com/acme-corp and all repos under it" ], "soft_deny": [ "$defaults", "Never run database migrations outside the migrations CLI, even against dev databases" ], "hard_deny": [ "$defaults", "Never send repository contents to third-party code-review APIs" ] } } ``` The `"$defaults"` literal matters more than it looks. Each array replaces the built-in list unless you include it: a `soft_deny` array without `"$defaults"` discards every built-in soft block, including the force-push and `curl | bash` rules, and a `hard_deny` array without it discards the built-in data exfiltration and auto-mode bypass rules. Support for `"$defaults"` landed in v2.1.118 precisely so you can extend rather than replace. `autoMode.environment` is the field to touch first. Out of the box the classifier trusts only the working directory and the repo's configured remotes, so pushing to your own GitHub org gets blocked until you list it. Three CLI subcommands keep you honest: `claude auto-mode defaults` prints the built-in rules, `claude auto-mode config` prints the effective merged config, and `claude auto-mode critique` has a model review your custom rules for ambiguity and likely false positives. One scope rule to internalize: the classifier reads `autoMode` from user, local, and managed settings, but never from the shared `.claude/settings.json` checked into a repo. Same reasoning as the defaultMode restriction above. ## Glob Deny Patterns: The Layer Before the Classifier The classifier is the second gate. The first gate is the regular [permissions system](https://code.claude.com/docs/en/permissions), which got its own upgrade in this window: v2.1.166 added glob pattern support in the deny rule tool-name position, so `"*"` now denies all tools, and unknown tool names in deny rules warn at startup instead of silently matching nothing. ![Abstract systems illustration for Glob Deny Patterns: The Layer Before the Classifier](/images/blog/claude-code-auto-mode-explained/inline-2.webp) This is where hard guarantees live. The auto mode docs say it plainly: for actions that must never run regardless of user intent or classifier configuration, use `permissions.deny` in managed settings, which blocks before the classifier is consulted and cannot be overridden. Prose `hard_deny` rules depend on a model interpreting them; `permissions.deny` rules are deterministic pattern matches. The patterns themselves support wildcards at any position in Bash specifiers: ```json { "permissions": { "allow": [ "Bash(npm run *)", "Bash(git commit *)" ], "deny": [ "Bash(git push *)", "Read(./.env)", "WebFetch(domain:pastebin.com)" ] } } ``` Two gotchas from the docs. First, `Bash(*)` is equivalent to bare `Bash`, and as a deny rule both forms remove the tool from Claude's context entirely rather than just blocking calls. Second, the space before `*` matters: `Bash(ls *)` matches `ls -la` but not `lsof`. If you audit agent activity the way we covered in [permissions, logs, and rollback for AI coding agents](/blog/permissions-logs-rollback-ai-coding-agents), these deny rules are the enforcement half of that story. ## Reviewing Denials and Wiring Up Hooks Denials are not dead ends. Since v2.1.89, denied commands show a notification and land in `/permissions` under the Recently denied tab, where pressing `r` marks an action for retry and resumes the conversation. Repeated denials for the same destination usually mean the classifier lacks context; the fix is adding that destination to `autoMode.environment`, then confirming with `claude auto-mode config`. For programmatic reactions there is a dedicated `PermissionDenied` hook that fires after classifier denials; returning `{"retry": true}` tells the model it can try again. That slots into the event system covered in [Claude Code hooks explained](/blog/claude-code-hooks-explained), and it pairs well with the orchestration patterns in the [dynamic workflows guide](/blog/claude-code-dynamic-workflows-guide), where long multi-agent runs are exactly the sessions you do not want stalling on a prompt at 2 a.m. The honest assessment: auto mode is the most usable middle ground Claude Code has shipped between prompt-per-action and full bypass. The classifier adds latency and sometimes blocks things it should not, which is why the denial-review loop exists. But the layering is sound - deterministic deny globs first, prose classifier rules second, `hard_deny` for the lines you never want crossed. ## FAQ ### Is Claude Code auto mode available on the Pro plan? Yes. Auto mode reached the Pro plan in Week 21 of 2026 (v2.1.143 to v2.1.149), and the requirements page now lists all plans. On Team and Enterprise an admin must enable it first. You also need v2.1.83 or later and a supported model. ### How do I turn on auto mode in Claude Code? Update Claude Code, then press Shift+Tab to cycle permission modes. Auto mode appears after plan mode once your account meets the requirements, with a one-time opt-in prompt. To start in auto by default, set `permissions.defaultMode` to `"auto"` in `~/.claude/settings.json` - project-level settings files are ignored for this value. ### What is the difference between hard_deny and permissions.deny? `autoMode.hard_deny` rules are prose instructions the safety classifier enforces inside auto mode, blocking unconditionally with no allow or intent override. `permissions.deny` rules are deterministic tool patterns (including globs like `Bash(git push *)`) evaluated before the classifier, in every mode. For guarantees, use `permissions.deny` in managed settings; for judgment calls, use `hard_deny`. ### Does auto mode work on Bedrock, Vertex AI, or Foundry? Yes, since v2.1.158, but only with Claude Opus 4.7 and Opus 4.8, and it stays off until you set `CLAUDE_CODE_ENABLE_AUTO_MODE=1` in your environment or settings `env` block. On the Anthropic API it is available by default. ### Is auto mode safe enough to replace reviewing changes? No, and Anthropic does not claim it is. The docs call it a research preview that "reduces prompts but does not guarantee safety." The right mental model is trusting the direction of a task, not skipping review of sensitive operations. ## Sources All sources fetched and verified June 11, 2026. - [Permission modes - Claude Code docs](https://code.claude.com/docs/en/permission-modes) - mode table, Shift+Tab cycle order, auto mode requirements, defaultMode restrictions - [Configure auto mode - Claude Code docs](https://code.claude.com/docs/en/auto-mode-config) - four-tier precedence, hard_deny/soft_deny/allow, environment, "$defaults", CLI subcommands, denial review - [Permissions - Claude Code docs](https://code.claude.com/docs/en/permissions) - rule syntax, wildcard patterns, deny rule behavior, disableAutoMode - [What's New Week 21 - Claude Code docs](https://code.claude.com/docs/en/whats-new/2026-w21) - auto mode on the Pro plan with Sonnet 4.6 - [What's New Week 19 - Claude Code docs](https://code.claude.com/docs/en/whats-new/2026-w19) - settings.autoMode.hard_deny introduction - [Claude Code CHANGELOG](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) - version pins: v2.1.89, v2.1.111, v2.1.118, v2.1.136, v2.1.142, v2.1.143, v2.1.158, v2.1.166