Forem: Max Quimby

Google's $40B Anthropic Bet: What It Means for Developers

Max Quimby — Sun, 26 Apr 2026 03:39:13 +0000

Last Thursday, Google announced it would invest up to $40 billion in Anthropic — the company behind Claude. The headline is enormous, but the structure of the deal is what developers should actually study. This isn't a standard venture investment. It's a circular finance loop: Google gives Anthropic capital, Anthropic spends that capital on Google Cloud compute, Google books the revenue. The money goes around in a circle, and what comes out the other end is 5 gigawatts of dedicated AI compute locked to the Google TPU stack.

📖 Read the full version with charts and embedded sources on ComputeLeap →

For developers building on the Claude API, this matters more than it looks.

The Deal Structure, Decoded

The $40 billion breaks into two tranches. TechCrunch reported that $10 billion is immediate cash at a $350 billion valuation for Anthropic. The remaining $30 billion is contingent — tied to undisclosed performance milestones that function as options Google can exercise over time.

That 75/25 structure matters. The immediate $10B is real capital. The $30B contingent tranche is more accurately described as a multi-year compute credit facility dressed as an investment. gHacks describes it as "a hybrid of Microsoft's OpenAI playbook and the cloud-credit model Amazon used in 2023 — equity capital flows out, but the bulk cycles back into Google Cloud as TPU spend over a multi-year horizon."

This comes just days after Amazon announced its own $33 billion Anthropic deal — with a separate $100 billion compute commitment to AWS infrastructure. In under 100 hours, Anthropic collected $65+ billion in fresh pledges from its two largest cloud partners.

ℹ️ The circular deal, simplified: Google gives Anthropic $40B → Anthropic buys Google Cloud TPUs → Google books cloud revenue. The investment is also a guaranteed customer acquisition for Google's infrastructure business.

Why "Circular" — And Why It Matters

The Humai blog published the clearest diagnosis of the deal structure: "The $40 billion is, in practical terms, a very expensive customer acquisition cost — paid in advance, recorded as an investment, and recouped through cloud bills nobody outside the deal will ever audit."

That framing went viral on Hacker News, where the story topped 798 points and 798 comments — the platform's top story on April 24. The community immediately noted that Anthropic is now what one commenter called "a MicroAmaGooVidia amalgamation" — simultaneously backed by Microsoft, Amazon, Google, and dependent on all three for compute.

The circular structure isn't new — Amazon's 2023 investment used the same cloud-credit playbook. But the scale is novel. The cumulative concentration of hyperscaler-AI lab partnerships (Microsoft–OpenAI, Google–Anthropic, Amazon–Anthropic) has grown large enough that analysts note the FTC, DOJ, and European Commission are likely to revisit the structure.

For developers, the circular nature matters for one specific reason: it means Anthropic's compute access is now structurally guaranteed by capital agreements, not just purchasing relationships. That's a different kind of stability.

What Anthropic Gets: 5 Gigawatts and a Roadmap

The concrete deliverable from this deal isn't the $40 billion number — it's the 5 gigawatts of dedicated compute capacity that Google Cloud will provide over five years. Anthropic's own announcement notes this builds on a separate Broadcom partnership for 3.5 gigawatts of next-generation TPU capacity coming online in 2027.

Combine the two commitments and you get a picture of Anthropic's training substrate for the next 3–5 years: a massive TPU-first infrastructure that validates Google's chips as a credible alternative to Nvidia for frontier model training. The financial backdrop makes the compute question urgent. Sacra's research shows Anthropic's revenue grew from $1 billion annualized in December 2024 to $30 billion in April 2026 — a 30x increase in 16 months. Business customers spending over $1 million annually doubled from 500 to 1,000 in under two months. Claude Code alone reached $2.5 billion in annualized billings. Demand is outrunning supply.

Mythos: The Model This Compute Is Built For

There's a specific model behind the compute math. Google Cloud's blog announced Claude Mythos in private preview on Vertex AI as part of "Project Glasswing" in early April. Sherwood News reported that Mythos — internally codenamed "Capybara" — is described in Anthropic's red-team disclosures as "a step change" above Opus 4.6, with pricing in the gated preview at $25 per million input tokens and $125 per million output tokens.

We already have a deep look at Claude Mythos and Project Glasswing on ComputeLeap. The key new data point: Mythos is already being used in production by the NSA despite official blacklisting — a signal that the model's capability premium is significant enough to override institutional friction.

Prediction markets are watching closely. Polymarket's "Which company has the best AI model end of April?" market has $18.5M in volume, with Anthropic currently at ~90% implied probability — even as DeepSeek V4, GPT-5.5, and Meta Muse Spark all launched in the same 72-hour window this week.

💡 For developers: Claude Mythos is accessible now via Vertex AI for approved enterprise accounts. If you're building on Google Cloud, apply for Project Glasswing access — this is the earliest path to the next frontier tier before public availability.

What It Means for Developers: Capacity, Rate Limits, and Platform Choice

The practical developer question is straightforward: will this make Claude faster to call, higher-limit, and more reliable?

The short answer is yes — but not immediately.

Current Claude API rate limits reflect a compute-constrained environment. Tier 1 developers get 50 requests per minute and 30,000 tokens per minute. Tier 4 (requiring $400 in cumulative credits) reaches 4,000 RPM and 2,000,000 ITPM. The Claude Code rate limits guide covers the developer-side mechanics in detail.

New infrastructure takes 12–24 months to translate into available capacity. The 5GW Google committed and the 3.5GW Broadcom deal (starting 2027) won't relieve rate pressure until late 2026 at earliest. But the trajectory is clear: Anthropic is building a compute foundation sized for the next order of magnitude of demand.

There's also a platform availability angle that's underappreciated. Anthropic is now the only frontier AI lab with native integrations across all three major cloud platforms: AWS Bedrock, Google Cloud Vertex AI, and Microsoft Azure Foundry. If you're an enterprise developer already committed to any of the big three clouds, Claude is there — and the investment locks in that availability for years.

ℹ️ Multi-cloud positioning: Anthropic's presence on AWS Bedrock, Google Vertex AI, and Azure Foundry means enterprise developers don't have to migrate infrastructure to access Claude. This is a meaningful competitive moat that OpenAI (primarily Microsoft/Azure-aligned) doesn't match.

The Regulatory Overhang

One signal developers building on Claude should track: regulatory scrutiny of these hyperscaler-AI lab partnerships is coming. The FTC, DOJ, and EU Commission are likely to revisit the structure of Microsoft–OpenAI, Google–Anthropic, and Amazon–Anthropic simultaneously.

The risk for developers isn't that Claude goes away. It's that regulatory action could constrain how these deals are structured going forward — potentially affecting compute availability SLAs, pricing tiers, or multi-cloud access. Worth watching, but not worth panicking over for most development teams.

How to Position Your Claude App for the Capacity Wave

If you're building production applications on Claude, the Google deal changes your planning horizon:

Short-term (now → Q3 2026): Capacity is still constrained. Use prompt caching aggressively — cached tokens don't count against your TPM limit, effectively multiplying your throughput at no extra cost. Route lower-stakes tasks to Claude Haiku 4.5, which has more generous limits. Use the Batch API for non-real-time workloads at 50% cost.

Medium-term (Q4 2026 → 2027): New Google Cloud capacity starts coming online. Rate limit tiers should expand meaningfully. If you're currently hitting walls at Tier 2 or Tier 3, plan for those ceilings to rise.

Long-term (2027+): The 3.5GW Broadcom TPU deal comes online. This is Mythos-scale compute — the infrastructure that trains and runs models well above current pricing tiers.

The Anthropic vs. OpenAI platform comparison covers how these compute roadmaps translate into API feature differences — worth revisiting with this investment context in mind.

The Bigger Picture

Google's $40B investment in Anthropic is simultaneously a capital event, a compute lockup, and a signal about where frontier AI infrastructure is headed. The circular structure isn't a flaw — it's the point. Hyperscalers are discovering that the most effective way to guarantee demand for their own compute infrastructure is to fund the companies that need the most compute.

For developers, the practical read is this: Anthropic is better capitalized and better infrastructure-secured than it has ever been. The models getting trained on 5 gigawatts of Google TPUs over the next five years will be substantially more capable than what's available today. The question isn't whether Claude will have compute — it's whether you're building on a platform positioned to scale with it.

The capacity wave is coming. The capital to fund it just got committed.

Originally published at ComputeLeap

GStack: Turn Claude Code Into a Full Engineering Team

Max Quimby — Sat, 25 Apr 2026 04:12:55 +0000

The first time you type /office-hours into Claude Code with GStack installed, something strange happens. The AI stops acting like a helpful coding assistant and starts acting like a skeptical product manager who thinks your feature idea is probably wrong.

📖 Read the full version on AgentConn →

That is the design. And it is why GStack — Garry Tan's open-source Claude Code skill setup — has accumulated 82,700 stars and 12,000 forks on GitHub since its March 2026 launch.

For context: Garry Tan is the President and CEO of Y Combinator. When the person who has reviewed more startups than almost anyone else on earth open-sources the exact AI development workflow that runs his code, developers pay attention. They also argue about it extensively on Hacker News.

This guide explains what GStack actually does, how it compares to oh-my-openagent and other harnesses, why the "it's just prompts" criticism misses the point, and whether it belongs in your workflow.

What GStack Actually Does: The 23 Skills

GStack is not a new coding assistant. It is a collection of CLAUDE.md skills — structured instructions that give Claude Code specialist personas. Install it in your project, and Claude Code gains access to 23 tools that simulate an engineering team.

The roles divide into recognizable job functions:

Planning and Strategy

/office-hours — Product interrogation with forcing questions. Challenges your idea before you build it. The "skeptical PM" experience.
/plan-ceo-review — Strategic scope challenge. Asks whether you are solving the right problem.
/plan-eng-review — Architecture and testing challenge. Finds the assumptions in your technical plan.
/plan-design-review — Design system audit. Catches "AI slop" — visual patterns that look fine locally but break at scale.
/plan-devex-review — Developer experience review of the plan.
/autoplan — Runs CEO, Engineering, and DevEx review in sequence automatically.

Design and Implementation

/design-consultation, /design-shotgun, /design-html — Design guidance at various fidelity levels.
/review — Code review targeting security issues, bugs, and architectural concerns.
/investigate — Root-cause debugging with structured reasoning.

Testing and Quality

/qa — Live browser testing with fixes applied inline.
/qa-only — Bug reporting without code modification.
/cso — Security audit applying OWASP Top 10 and STRIDE threat modeling.

Release and Deployment

/ship, /land-and-deploy, /document-release

Additional Tools

/browse, /canary, /benchmark, /retro, /codex, /pair-agent, /learn

The /codex skill adds OpenAI Codex as a parallel review engine inside Claude Code, giving you cross-model code review without leaving your terminal.

The Conductor: Parallelizing Everything

The Conductor coordinates multiple Claude Code sessions running simultaneously in isolated workspaces. One session running /office-hours on a new idea, another doing /review on an open PR, a third implementing a feature, a fourth running /qa on staging — each in its own git worktree with its own context window.

This is the part that makes GStack genuinely novel compared to a folder of CLAUDE.md prompts. Conductor is multi-agent orchestration built into the harness — not a separate tool you have to wire up yourself.

The Productivity Claim: 810×

Garry Tan reports his 2026 development pace at approximately 810× his 2013 baseline (11,417 logical lines/day vs 14). Key caveats:

The metric is "logical LOC," not raw lines. Logical LOC measures meaningful changes — new behaviors, not reformatted whitespace. This is a more honest metric than it first appears.

The 2013 baseline is a single-developer comparison. Tan is comparing his own pre-AI vs. post-AI productivity. Not a controlled experiment, but an honest data point.

It doesn't hold for all workflows. The TechCrunch analysis notes developers working on hardware-adjacent code or regulated domains see much smaller gains.

The "Just Prompts" Criticism

The most common dismissal: GStack is "a bunch of prompts in a text file." This criticism is partially correct and mostly misses the point.

It is correct that the individual skills are structured prompts. There's no compiled code, nothing that prevents you from reading every CLAUDE.md instruction.

What the criticism misses is that the value is in the system design, not the technology. The insight is architectural: separating planning from implementation, using adversarial reviewing roles, and enforcing security audits as a default step before shipping. These are software engineering principles applied to AI agent orchestration.

The CTO testimonial Garry Tan shared is worth taking at face value:

A security audit that runs automatically before every merge is not "just a prompt." It is a default gate that most teams skip under schedule pressure. GStack makes skipping it harder than doing it.

GStack vs the Field

	GStack	oh-my-openagent	GSD	cc-switch
Stars	82.7K	53.9K	35K	54K
Model lock-in	Claude Code only	Multi-model	Claude Code first	Model-agnostic config
Specialist roles	23 skills	11 agents	Spec-driven only	None
Parallel sessions	Yes (Conductor)	Yes	No	No
Install complexity	30 seconds (paste)	npm install	Manual	CLI install

oh-my-openagent routes tasks to the best model — if you need DeepSeek for cost-sensitive tasks and Claude for hard reasoning, OmO handles the routing. GStack is entirely Claude Code native.

When GStack Wins, When It Doesn't

GStack is best for:

Solo developers building SaaS or web products without a senior team
Early-stage startups without dedicated QA, security reviewer, or architect
Developers already on Claude Code — zero-friction install
Teams shipping fast who default to skipping review steps

GStack is probably wrong for:

Teams needing multi-model routing (OmO is better)
Teams with mature code review culture (GStack replaces informal processes)
Developers on OpenCode or non-Claude agents (CLAUDE.md-native)
Embedded, firmware, or highly regulated domains

Getting Started in 30 Seconds

GStack lives at github.com/garrytan/gstack. Install: open Claude Code and type Install GStack.

Your first three commands:

/office-hours — Challenge your current feature idea
/cso — Security audit on your last commit
/autoplan — CEO, Eng, and DevEx review your next technical plan

The Bottom Line

GStack implements software engineering best practices — adversarial review, security auditing, design critique, spec challenge — as default steps in your Claude Code workflow. Steps that solo developers skip not because they are bad engineers but because there is nobody else in the room.

If you are a Claude Code user building a product, install it. The 30-second install cost is trivially small relative to finding a single XSS vulnerability before it ships to production.

The frontier in AI-assisted development is not a better autocomplete. It is a well-designed team of reviewers who catch the mistakes you were going to make anyway.

Originally published at AgentConn

DeepSeek V4 vs GPT-5.5 vs Claude Opus 4.7: Model Guide

Max Quimby — Sat, 25 Apr 2026 03:34:22 +0000

Today is the most chaotic single day in the 2026 AI model race.

📖 Read the full version with charts and embedded sources on ComputeLeap →

Within a 24-hour window, OpenAI shipped GPT-5.5 — its most capable API model yet, with a 74% long-context score that doubles its predecessor — and DeepSeek responded within hours with two open-source models: V4-Pro (1.6 trillion parameters, MIT license) and V4-Flash (284 billion, equally open). Claude Opus 4.7, which launched April 16, has been the dominant coding model since. Now it has two new challengers on the same day.

The timing is not a coincidence. It rarely is at this level.

For developers, this isn't an academic benchmark exercise. The question is practical: for your next sprint, which model do you route each task to? This guide gives you the data and the decision framework.

ℹ️ Read our GPT-5.5 vs Claude Code deep dive for the coding-specific head-to-head from yesterday's launch. This article covers the broader model selection question.

What Just Dropped: The Models at a Glance

Before comparing, here's what we're actually comparing:

	DeepSeek V4-Pro	DeepSeek V4-Flash	GPT-5.5	Claude Opus 4.7
Total params	1.6T	284B	Undisclosed	Undisclosed
Active params	49B	13B	Undisclosed	Undisclosed
Context window	1M tokens	1M tokens	1M tokens	200K tokens
License	MIT (open weights)	MIT (open weights)	Proprietary	Proprietary
Input cost	$1.74/M	$0.14/M	$5.00/M	$5.00/M
Output cost	$3.48/M	$0.28/M	$30.00/M	$25.00/M
Self-hostable	Yes	Yes	No	No

The architecture story behind these numbers: DeepSeek uses Mixture-of-Experts (MoE), which is why a 1.6 trillion parameter model only activates 49 billion parameters per token. Simon Willison notes that V4-Flash achieves only 10% of the single-token FLOPs and 7% of the KV cache size of its predecessor — that's what enables the aggressive pricing.

ℹ️ DeepSeek V4 runs entirely on Huawei chips with zero CUDA dependency. This matters beyond hardware specs: the inference pipeline isn't subject to US export control disruption, a meaningful consideration for enterprise planning.

Benchmark Breakdown: Who Wins Where

Raw benchmark numbers are imperfect, but they're what we have. Here's the honest picture:

Intelligence Index (Artificial Analysis)

GPT-5.5: 60 points (top score)
Claude Opus 4.7: 57 points
DeepSeek V4-Pro: competitive, positioned between the two above

GPT-5.5 leads the overall intelligence index — but three points over Claude Opus 4.7 is a margin unlikely to be decisive in most production workloads.

Coding (SWE-Bench Verified)

Claude Opus 4.7: 87.6% (+6.8 points over Opus 4.6)
DeepSeek V4-Pro: 80.6%
GPT-5.5 Pro: 58.6% (notably behind)

💡 For pure coding tasks, Claude Opus 4.7 holds the highest verified score at 87.6% on SWE-bench. DeepSeek V4-Pro is competitive at 80.6%. GPT-5.5 Pro trails at 58.6% — a surprising gap given its overall intelligence lead.

DeepSeek also leads on terminal-level coding: V4-Pro scores 67.9% on Terminal-Bench 2.0 vs Claude at 65.4%. These are close enough that real-world workload matters more than the benchmark gap.

Hard Reasoning (Humanity's Last Exam, no tools)

Claude Opus 4.7: 46.9%
GPT-5.5 Pro: 43.1%
GPT-5.5: 41.4%
DeepSeek V4-Pro: 37.7%

This is the most revealing split. For tasks requiring genuine hard reasoning — the kind where neither model has a template to pattern-match from — Claude Opus 4.7 leads by 9 points over DeepSeek. That's a meaningful gap for legal, financial analysis, or complex research workloads. (FundaAI 38-task benchmark)

⚠️ GPT-5.5's documented 86% hallucination rate — per The Decoder's independent testing — is a significant weakness despite its top intelligence index score. For factual grounding, Claude Opus 4.7 or DeepSeek V4-Pro are more reliable.

Long-Context Reasoning (MRCR v2 at 1M tokens)

GPT-5.5: 74.0% (up from 36.6% in GPT-5.4 — an extraordinary jump)
Claude Opus 4.7: strong, but only supports 200K native context
DeepSeek V4-Pro: 1M context native, performance data pending

The GPT-5.5 long-context improvement is the headline technical achievement of this launch. If your workload involves very long document processing, GPT-5.5's long-context reasoning may be worth the price premium.

The Real Cost Math

This is where DeepSeek V4 becomes genuinely disruptive. Let's make the numbers concrete for a typical development team.

Assume 100M output tokens per month (a moderately active team with LLM-intensive workflows):

Model	Monthly Output Cost
GPT-5.5 Pro	$18,000
GPT-5.5	$3,000
Claude Opus 4.7	$2,500
DeepSeek V4-Pro	$348
DeepSeek V4-Flash	$28

DeepSeek V4-Pro at $348 vs Claude Opus 4.7 at $2,500 is a 7× cost difference for near-comparable coding performance. V4-Pro's output cost versus GPT-5.5 Pro is a 98% reduction.

For teams already running on a budget, we covered a similar cost calculus in our Kimi K2.6 vs Claude Opus 4.7 comparison — the pattern of Chinese open-source models delivering 80–90% of the capability at a fraction of the cost is now a structural feature of the AI market, not an anomaly.

ℹ️ With cached input, the gap widens further. DeepSeek-V4-Pro's cache-hit cost is roughly one-tenth of GPT-5.5 and one-eighth of Claude Opus 4.7 at scale. If your architecture reuses prompt prefixes, the savings compound aggressively.

The 1M Context Window: What It Actually Changes

Both DeepSeek V4 models and GPT-5.5 ship with 1M token context windows. Claude Opus 4.7 caps at 200K. The practical implications:

What 1M tokens enables:

Feeding an entire 500-page technical specification into a single prompt
Six months of project documentation without chunking
A full codebase (~750,000 words of active context)
Multi-step agent workflows where the model retains chain-of-thought across 20+ tool calls

DeepSeek V4 introduces "interleaved thinking" — full chain-of-thought retention across tool calls in agent workflows. This means a 20-step agent workflow doesn't suffer the amnesia-halfway-through problem that plagues most agentic pipelines.

The HN discussion at 1,588 points surfaced a key practical detail: DeepSeek's zero CUDA dependency makes it runnable in environments where Nvidia GPUs aren't available — relevant for enterprise deployments on private infrastructure.

The Polymarket Divergence: Hype vs. Market Confidence

Here's the contrarian data point most coverage will skip.

The Polymarket market "DeepSeek V4 released by...?" had $2.4 million in trading volume and resolved at 100% — traders called the release date correctly. Developer enthusiasm is genuine.

But Polymarket's "Best Chinese AI company 2026" market? DeepSeek sits at 3%.

That divergence — maximum developer excitement, minimal market confidence in DeepSeek as a company — is worth sitting with. Some reasons the market might be right:

Open-source models generate developer mindshare but not revenue
DeepSeek's pricing is so aggressive it may be below sustainable margin
US export restrictions on Nvidia GPUs create a hardware ceiling for scale
Anthropic holds ~85% in the "best coding AI company" Polymarket market — consensus hasn't shifted despite DeepSeek's coding scores

ℹ️ The pattern is clear: open-source is the Chinese AI strategy for global developer mindshare while keeping closed models for domestic enterprise. Two major drops (DeepSeek V4 + Tencent Hy3 at 295B parameters) in one day is not a coincidence. (Tencent Hy3 launch)

Decision Framework: Routing Logic by Task Type

The FundaAI 38-task benchmark and the Artificial Analysis comparison both land at the same conclusion: don't pick one model. Route.

Route to Claude Opus 4.7 when:

Hard reasoning is required (legal, financial, medical research)
Code review or complex multi-file refactoring (87.6% SWE-bench)
Citation accuracy matters — lowest hallucination rate
Enterprise compliance rules out Chinese infrastructure
You're already in Cursor (50% off right now)

Route to DeepSeek V4-Pro when:

Long-context analysis (1M token codebase ingestion, multi-document synthesis)
Agentic workflows with 20+ steps (interleaved thinking retention)
High-volume batch processing where cost is the constraint
Self-hosting or private infrastructure is required
You want open weights for fine-tuning on domain data

Route to DeepSeek V4-Flash when:

High-frequency, lower-complexity tasks ($0.28/M output)
First-pass triage or pre-processing before escalation to a stronger model
Any use case where V4-Pro would work but volume makes cost prohibitive

Route to GPT-5.5 when:

Extreme long-context reasoning (1M tokens, MRCR v2 at 74%)
Agentic computer use tasks via OpenAI Codex
Speed is a priority (GPT-5.5 Fast Mode: 1.5× faster tokens)
Deep OpenAI ecosystem integration (ChatGPT, Codex)

Skip GPT-5.5 Pro unless:

You have specific enterprise contracts with OpenAI
The $180/M output cost is justifiable for specialized, low-volume, high-stakes tasks
The 58.6% SWE-bench score won't matter for your use case

💡 The optimal architecture for most teams: route 60–70% of traffic to V4-Flash for high-volume/low-complexity tasks, escalate coding to Claude Opus 4.7, use GPT-5.5 for long-context document tasks. This pattern typically reduces costs 40–60% compared to running everything through a single frontier model.

The Bottom Line

Three models, three different bets on what matters:

Claude Opus 4.7 is the best coding model at 87.6% SWE-bench verified. It leads on hard reasoning. It hallucinates least. It costs $25/M output tokens. For high-stakes code and reasoning work, it remains the default.

DeepSeek V4-Pro is 7× cheaper than Claude, open-source, and within 10 points on most coding benchmarks. The 9-point gap on Humanity's Last Exam matters for hard reasoning. For everything else, the cost case is compelling — especially with 1M context native and interleaved thinking for agents.

GPT-5.5 wins the intelligence index at 60 points and made a massive long-context leap. But the 86% hallucination rate and $30/M output cost make it a niche choice: buy it when you specifically need that long-context reasoning, and verify outputs carefully.

The frontier in 2026 is not a single model. It's a routing layer.

For the coding-specific comparison, see GPT-5.5 vs Claude Code: Which AI Should You Use for Agentic Development?

For a deeper look at the Chinese open-source cost story, see Kimi K2.6 vs Claude Opus 4.7: The 88% Cost Advantage

Originally published at ComputeLeap

Meta's Real Story Isn't the Layoffs. It's the Surveillance.

Max Quimby — Fri, 24 Apr 2026 23:47:16 +0000

On April 23, Meta told 8,000 employees they would be walking out the door on May 20. The next morning, Microsoft announced the first voluntary retirement program in its 51-year history — up to 8,750 people eligible. Six weeks earlier, Block gutted 40% of its workforce, citing its own internal AI agent. The headlines write themselves: "AI is eating the tech industry," "the labor crisis is here."

📖 Read the full version with charts and embedded sources on ComputeLeap →

That's the story everyone is telling. It's also the wrong one.

The real story is happening inside Meta's own walls. The same week the company said goodbye to 8,000 people, it quietly began installing surveillance software on the computers of the employees it's keeping — a program called the Model Capability Initiative (MCI) that records every keystroke, mouse movement, and periodic screenshot across Gmail, GitHub, Slack, and hundreds of other sites. The stated purpose: to train AI agents that can automate white-collar work. The logical endpoint: the employees generating the training data are, line by line, encoding the workflows that will replace the next cohort. That isn't a productivity tool. That is the first visible instance of enterprise-scale AI observability applied to employees — and because Meta just normalized it, every Fortune 500 will pilot a version within 18 months.

This piece is about the layoffs. But the layoffs are the distraction. The surveillance is the precedent.

The Layoff Wave — the Surface Story

The numbers are real, and they are large. Meta's chief people officer Janelle Gale sent a Thursday memo informing staff the company would cut 10% of its workforce — roughly 8,000 people — and decline to fill another 6,000 open roles. "This is not an easy tradeoff," she wrote, "and it will mean letting go of people who have made meaningful contributions to Meta during their time here." Bloomberg was first to report; CNBC, Reuters, and the FT followed within hours. The cuts land May 20.

Meta's 2026 capital expenditure guidance — $115 billion to $135 billion, roughly double the $72 billion spent in 2025 — explains the accounting. CEO Mark Zuckerberg has told investors the company will spend whatever it takes to build "personal superintelligence." Paying for that at current margins means shedding people. The company's framing is that the capex is the investment and the layoffs are the offset. What's hidden behind this number is a structural bet: that the people being cut now will be replaced by software the remaining employees are being paid to help train.

Microsoft, on the same day, introduced something unprecedented in the company's history. Rather than traditional layoffs, Satya Nadella's team offered a one-time voluntary retirement program to about 7% of U.S. employees — senior director level and below, whose years of employment plus age sum to at least 70. That's roughly 8,750 people eligible to walk with severance and extended healthcare. The financial engineering is elegant: the people most expensive to fire voluntarily raise their hands. TechCrunch and GeekWire both flagged this as a first for the 51-year-old company. What matters isn't that Microsoft is unusually generous — it's that the framing of "retirement" sidesteps the WARN Act, muddles the layoffs.fyi counter, and gives the company political cover on capex earnings calls. This is layoff optimization, not compassion.

Block is the canary. In March, Jack Dorsey announced the company behind Square and Cash App would cut 4,000 people — roughly 40% of its workforce — and pointed directly at the company's internal AI agent, codename goose, as the reason. Goose had been in production internally for about 18 months; Fortune's exclusive with Block's CFO detailed the leverage math. Then came the complication: within six weeks, as we documented in our analysis of Block's 40% layoff and its codename goose agent, technical leads began threatening to quit unless laid-off teammates were rehired. HumAI's reporting shows Block has quietly rehired engineers — often at lower seniority and tighter comp. The lesson the rest of big tech is taking: cut fast, claim AI, rehire the critical third at a 30% discount.

Zoom out and the macro number is staggering. Per layoffs.fyi tallies reported by CNBC, more than 92,000 tech workers have been laid off in 2026 alone, bringing the running total since 2020 to nearly 900,000. Amazon announced its widest layoff in company history earlier this quarter. Oracle, Snap, Disney — the list is 96,000 and climbing. Glassdoor's Employee Confidence Index shows the tech sector dropped 6.8 percentage points year-over-year in March, the largest drop in any industry. But this is the part everyone is already covering. Let's move to the part they aren't.

On the HN thread for the Bloomberg story (781 points, 829 comments), the top comment from user bandrami captured the actual dynamic:

💡 "This is interesting because it's a case of 'AI taking jobs' but not in the way people normally mean; these massive layoffs are happening not because AI is doing the work they used to do but because capex is sucking all of the operating money out of everywhere." — bandrami, HN

Hold that frame. Because the next section explains where the capex goes — and who pays for it with their keystrokes.

The Story Underneath — Meta's MCI

Two days before Meta announced the 10% cut, Fortune broke a different story: Meta is installing tracking software on every U.S. employee's work computer. The program is called the Model Capability Initiative (MCI), and it does three things. It records mouse movements and clicks. It logs keystrokes. And it periodically captures screenshots — all inside a set of "work apps and websites" that CNBC's reporting reveals includes Google, LinkedIn, Wikipedia, Microsoft's GitHub, Salesforce's Slack, Atlassian's Jira and Confluence, Meta's own Threads and Manus, Gmail, Visual Studio Code, and an internal tool called Metamate. Hundreds of sites in total.

The stated purpose is not productivity management. It is training data. A Meta spokesperson explained the logic in clean language to Fortune: "If we're building agents to help people complete everyday tasks using computers, our models need real examples of how people actually use them." CTO Andrew Bosworth went further in an internal memo reported by The Register: Meta envisions "a world where our agents primarily do the work and our role is to direct, review and help them improve." Read carefully. The people being monitored are the raw material for the agents that will reduce the need for their successors. One employee, anonymous to the BBC, used the word that has dominated every discussion of MCI since: "very dystopian." Computing.co.uk used the quote as their headline. Futurism summarized the company's position more bluntly: "Meta is saying the quiet part out loud."

The timing is the part nobody in Meta's PR shop can spin. Fortune's story landed on April 21. CNBC's followed April 22. The 10% layoff memo landed April 23. Two days apart. TechRadar Pro ran the causal headline explicitly: "Meta is logging employees' keystrokes and screenshots to train AI agents — weeks before major layoffs." Under U.S. federal law, there is no opt-out. Workers at Meta's U.S. offices have no legal right to refuse the MCI agent on their machines. Tell someone they have six weeks until the WARN notice and then ask them to hand over their keystroke data with no opt-out — and then call it consent — and you have defined the outer edge of what "at will" means in 2026. AI Supremacy's newsletter, which broke the broader narrative into public consciousness, put it tersely: "Meta not just spying with AI glasses, now data harvesting talented staff. No opt-out."

The 18-Month Precedent

Every enterprise-software procurement cycle I've watched over 20 years follows the same pattern. A FAANG normalizes a practice. A tier-two SaaS company builds a commercial version of it. The Fortune 500 starts piloting within 12 months. It becomes a standard line item inside 24.

Meta just normalized AI-native employee observability at the scale of 75,000 users. The SaaS category that will emerge around this is already taking shape: products that record a granular stream of employee screen, keyboard, and application telemetry; pipe it through an LLM scoring layer for "workflow classification"; and feed it back into either a coaching agent or a direct-automation agent. Every CIO has received a pitch from at least one of these vendors in the last ninety days. Meta just gave all of them the reference customer they needed.

The logic is not secret — it's what the AI-native org playbook Dorsey has been pitching has been missing. Dorsey's Block built goose and then cut 40% of staff. But Block didn't productionize employee telemetry collection to train the next version of goose. Meta is. That is the leap. The companies downstream of Meta will not write research papers or send internal memos — they will simply deploy the product, usually rolled in under an existing "endpoint security" or "DLP" SKU where most employees won't notice until it's in the HR handbook.

Here is the prediction: by Q4 2027, three to five of the top ten U.S. private employers will be running some version of MCI under a brand name sold by a Menlo Park-funded SaaS vendor. Disclosure will vary. Consent will be buried in a revised acceptable-use policy. The 18-month timeline is not a guess — it's the standard procurement gap between "FAANG reference customer" and "regulated enterprise rollout."

Contrarian Corner — Steelman First

⚠️ The strongest counter-argument to the thesis above: workplace monitoring is not new. Pinkerton detectives watched factory floors in 1892. Keystroke loggers have been commercial software since the 1990s. Every enterprise already collects endpoint telemetry for security and DLP. Employees consented when they signed the handbook. What Meta is doing is a UX improvement, not a category break. And anyway, as Sam Altman pointed out in February, companies are "AI washing" layoffs they'd have done anyway — so blaming the surveillance for the layoffs, or even the other way around, is narrative fiction. The real driver is capex reallocation.

The rebuttal: the steelman is right about Pinkertons and keyloggers, and it's right that AI washing is real — but it's wrong about scale and purpose. Security telemetry is collected to detect malicious activity (data exfiltration, credential misuse). Performance management telemetry is collected to measure output (tickets closed, calls handled). MCI is different. MCI collects the process — the specific sequence of clicks and keystrokes a senior engineer uses to structure a code review, the phrasing a PM uses in a Slack thread, the order in which a designer opens Figma panels. That's not security. That's not performance. That's an apprenticeship in bulk, extracted from people who were not told what the apprentice would be. Altman's AI-washing caveat applies to the layoff narrative — and we'll take it. It does not apply to the MCI narrative. The monitoring isn't about the layoffs. The monitoring is about what comes after them.

The Ethical Question — And It Is One

It would be lazy to call this dystopian and stop there. The harder question: where is the line?

There is a real distinction — one Yale law professor Ifeoma Ajunwa has been writing about for a decade — between monitoring that enforces a contract (you agreed to do X hours of work; we verify X hours happened) and monitoring that extracts value beyond the contract (we watch how you work and build an asset, owned entirely by us, that captures the transferable skill you spent a career developing). The first is controversial but defensible. The second has no settled legal or ethical framework in the U.S. — and because most U.S. states are at-will, no practical avenue for refusal.

European workers have more ground. GDPR Article 88 gives member states authority to pass employment-specific data protection laws; most have. France's CNIL has already ruled that keystroke-level monitoring without a documented, proportionate business case violates the GDPR's "data minimization" principle. Germany's works councils can veto the deployment of tracking software outright. Meta's MCI would not, in its current U.S. form, pass a German BetrVG review. The company has been pointedly quiet about whether it will extend MCI outside the U.S., and the regulatory asymmetry is the reason.

Inside the U.S., the landscape is a patchwork. IAPP's summary lays it out: California's CCPA, as of January 1, 2026, requires employers to conduct risk assessments for processing personal-email content over company systems and for any automated processing used to infer job performance. New York requires written notice of electronic monitoring at hiring, posted in a conspicuous place. Illinois's BIPA requires informed written consent and strict data-handling for biometric data. Connecticut and Delaware have their own notice regimes. Fifteen more states have biometric legislation in committee. The federal backstop — the Electronic Communications Privacy Act and Stored Communications Act — permits monitoring "for legitimate business purposes," which has never been tested against the specific question of "training AI to replace the monitored worker." Someone will file that suit in 2026. If Meta is the defendant, the discovery alone will be brutal.

The social temperature is already shifting. A r/technology thread asking whether Palantir employees are starting to wonder if they're the bad guys hit 22,780 upvotes and 1,136 comments in a day. 30,000 Samsung union members took to the streets this week demanding a share of AI-driven profits. The broader AI backlash that's already visible in public sentiment — and in specific acts of sabotage — will not spare a company that is simultaneously laying off 8,000 people and installing keystroke trackers on the survivors. The PR surface is maximum.

What Employees Should Do — Right Now, This Week

This is the practitioner section. None of what follows requires a lawyer, a union rep, or a grievance. Every single item is something a salaried tech worker can do this week with fifteen minutes and a personal laptop.

Assume your work device is instrumented. Not just at Meta — at every tier-one tech employer within 18 months. Do not conduct job searches, update LinkedIn, or compose resume materials on a work machine. Do not route personal email through a work browser profile. Do not use work Slack or Teams for anything sensitive. If you're unsure whether endpoint monitoring is installed, check your company's acceptable-use policy and endpoint security agent list — you don't need IT's permission to read HR's own documents.
Know your jurisdiction. Californians under CCPA have data-subject rights including access and deletion requests — use them. New Yorkers can demand the monitoring disclosure that state law requires was given at hiring. Illinois employees with any biometric capture (many keystroke loggers qualify) are protected by BIPA and can sue individually. If you're in the EU under GDPR, your employer is already on weaker legal ground than they realize. Look up your state attorney general's consumer protection page this week. Bookmark it.
Document performance on personal storage. Copies of performance reviews, 1:1 notes, project outcomes, praise emails, and compensation history — kept in a personal cloud account you still control after a termination. Not a work machine. Not a work-synced OneDrive. If you are fired and want to contest it or negotiate severance, you will need evidence your employer no longer grants you access to.
Talk to a lawyer before you need one. Most employment-law firms offer free 30-minute consults. Use one. Ask three questions: (a) what does my employment contract allow around monitoring and post-termination data collection, (b) does my state have any notice or consent laws that apply, (c) if I negotiate a severance, what is a typical multiplier in my jurisdiction and role. You are not hiring a lawyer. You are getting a calibration.
Use LinkedIn and Blind with discipline. Never post job-search activity under a handle linked to your work email. Never cross-post on Blind from a device on the corporate network — Blind's "verified employer" check doesn't mean Blind itself is safe from discovery in litigation. If you are contemplating a move, set up a personal-email Blind account on a personal device today.
Know your collective-action options. Most U.S. tech workers are non-union, but the NLRB protects concerted activity even without a union. Two or more employees raising monitoring concerns in writing to HR is protected. If the topic feels too hot for email, CODE-CWA and the TechWorkersCoalition both run confidential channels.

None of this is paranoia. It is hygiene. Your great-grandparents knew not to discuss wages or organizing plans in the company town's general store. The same discipline applies when the general store now runs on the laptop in your bag.

What Employers Should Do

Shorter version. Four items. If you are building or approving a monitoring program, answer each in writing before you deploy:

Transparency. Tell employees what is collected, how it is processed, who has access, how long it is retained, and what it will be used for. Not in an updated AUP. In an email, plus a town hall, plus a written Q&A that is revised based on the questions asked.
Consent with a real opt-out. If there is no opt-out, it is not consent. If the only opt-out is resignation, it is not consent. Build a workflow that allows employees to exclude specific apps or time windows from collection, with no retaliation.
Narrow scope and retention. Collect the minimum required for the stated purpose. Delete the rest on a 90-day rolling window. Publish the retention schedule.
Independent audit. Annual third-party review of what was collected, how it was used, and whether the stated purpose and the actual purpose match. Publish the audit summary internally.

Companies that do these four things will retain talent. Companies that don't will face union drives, class actions, and a steady bleed of senior engineers to competitors inside 24 months. The math is not hard.

What Comes Next

Eighteen months is the window. By late 2027 we will know whether enterprise AI employee-observability splits into two markets — a disclosure-first one sold to companies that care about retention, and a dark-patterns one sold to companies that will be defendants in the 2028 class-action docket. The companies that land on the right side of that split will not be the ones with the most advanced surveillance stack. They will be the ones that wrote the consent architecture first.

The Meta layoffs are the headline. They're a footnote. The headline is what Meta is doing to the 72,000 employees it didn't lay off this week. They're being asked to train the thing that replaces the next 8,000 people. And because of where Meta sits in the procurement food chain, every CIO at every mid-cap company in America just saw the playbook. They will run it, with minor modifications, and with far less press attention.

If you're a tech employee, the next year is not about whether your company survives the AI wave. It's about whether you can tell the difference between a performance review and a training run. Assume you're being watched. Make it worth their while.

Originally published at ComputeLeap

Shannon AI Review: Autonomous Web Pentesting Agent

Max Quimby — Fri, 24 Apr 2026 04:25:16 +0000

📖 Read the full version with screenshots and embedded sources on AgentConn →

On April 22, 2026, the Bitwarden CLI package was compromised and pushed to npm as version 2026.4.0. The malicious release was live for 19 hours. 334 users downloaded it before detection. Bitwarden is one of the most-audited, most-trusted password managers on the planet — and the attack was caught by community monitoring, not by the organization's own tooling.

This is the context in which Shannon needs to be evaluated — not as an academic security toy, but as a response to an increasingly hostile environment where the traditional model of "annual pentest, quarterly audit" is already obsolete before the PDF is delivered.

Shannon is an open-source autonomous AI pentesting agent built by Keygraph. It reads your source code, maps your attack surface, and attempts to break in — producing a report with zero false positives, because it only files findings it can actively prove with a working exploit. It has 40.1K GitHub stars as of April 2026. Powered by Anthropic's Claude.

What Shannon Actually Does

When you run Shannon, it executes a five-phase workflow:

Pre-reconnaissance — Static code analysis: architecture patterns, entry points, authentication mechanisms, likely attack vectors
Reconnaissance — Dynamic analysis via Playwright browser automation: forms, API endpoints, authentication flows
Vulnerability & Exploitation — Five parallel Claude agents simultaneously test for SQLi, XSS, authorization bypasses, SSRF, and IDOR. No PoC = no finding
Confirmation — Dedicated pass verifies each exploit is reproducible
Reporting — Proven vulnerabilities only, with exact curl commands to reproduce

Cost: ~$50 in Anthropic API credits. Time: 1–1.5 hours. Compare: $10,000–$50,000 for a traditional pentest.

The XBOW Benchmark: 96.15%

Shannon scored 96.15% on the XBOW security benchmark — 100 of 104 intentionally vulnerable web apps solved in hint-free, source-aware mode. Commercial DAST tools typically score 30–40% on comparable evaluations.

Hands-On Test Results

DVNA (Node.js) — Shannon detected SQL injection, command injection, XSS, and XXE with working exploits. "What stood out was how Shannon organized the analysis — it structured the findings into clear sections."

OWASP Juice Shop — Better Stack's test consumed ~$60 in API credits. Shannon "didn't say 'this login looks weak' — it bypassed the login, dumped data, and handed me the screenshots and logs to prove it." Zero false positives.

The Economics

Approach	Cost	Time	Frequency
Traditional pentest	$10,000–$50,000	Weeks	Annual
Shannon per scan	~$50 API	1–1.5 hours	Daily in CI/CD

What Shannon Misses

White-box only — requires source code access; can't test closed-source dependencies
Four categories only — SQLi, XSS, SSRF, broken auth. Business logic flaws: not in scope
Not for production — creates users, modifies data, fires injection probes
LLM residual risk — confirmation phase helps but human review still essential

The Dual-Use Concern

From HN discussion: "Since this is open source, it's a white-hat tool, but it also democratizes script kiddos being able to do some serious damage." Developer: "I guess who owns the most hardware wins the arms race?"

Setup

# Requirements: Docker, Node.js 18+, Anthropic API key
npx @keygraph/shannon setup
npx @keygraph/shannon start -u https://your-dev-app.com -r /path/to/repo

The Verdict

Use Shannon if: shifting security left, web app with source code you control, OWASP Top 10 exposure, need something between nothing and a full pentest.

Don't rely on Shannon if: black-box testing needed, business logic is your risk, compliance-ready reports required, production environment.

Shannon is at github.com/KeygraphHQ/shannon — AGPL-3.0.

Originally published at AgentConn

GPT-5.5 vs Claude Code: Which AI Should You Use?

Max Quimby — Fri, 24 Apr 2026 03:26:24 +0000

The agentic coding race just got a whole lot more explicit.

📖 Read the full version with charts and embedded sources on ComputeLeap →

On April 23, 2026, OpenAI shipped GPT-5.5 with a framing it hasn't used before: not a smarter chat model, but "a new class of intelligence for real work and powering agents." The subtext is unmistakable — OpenAI is coming directly for the territory Claude Code has been quietly dominating among professional developers.

The launch racked up 40K likes within hours. Developers who have been routing serious coding work through Claude Code are suddenly asking whether it's time to reconsider. The honest answer? It depends on what you're building — and who's paying for it.

This is a practical decision guide. We'll cover the benchmark reality, the pricing drama that erupted this week, and the three distinct use cases where each tool wins. No hype, no both-sides-ism. Just a clear read on the current state of the agentic coding wars.

What GPT-5.5 Actually Is

GPT-5.5 is the first fully retrained base model OpenAI has shipped since GPT-4.5. Every previous 5.x release (5.1, 5.2, 5.3, 5.4) was built on the same foundation — this one is not.

The headline benchmark: 82.7% on Terminal-Bench 2.0, a test of complex command-line workflows that require planning, iteration, and coordinated tool use. It also posts 58.6% on SWE-Bench Pro (real GitHub issue resolution end-to-end in a single pass) and 84.9% on GDPval, which tests general-purpose knowledge work.

TechCrunch's coverage notes that Greg Brockman called it "a real step forward towards the kind of computing that we expect in the future" — pointing to autonomous task completion, not just chat fluency. The model is designed to use tools, verify its own work, and carry multi-step tasks through to completion without requiring constant human steering.

What changed under the hood according to Interesting Engineering: fewer refusals mid-task, better intent retention across long tool chains, and more efficient token usage per completed task than GPT-5.4. It's natively omnimodal (text, images, audio, video in a single unified system) and available in both ChatGPT and Codex immediately on launch day for Plus, Pro, Business, and Enterprise subscribers.

The pricing is not gentle. VentureBeat's analysis puts GPT-5.5 API at $5/million input tokens and $30/million output tokens — roughly 2x the per-token cost of GPT-5.4. OpenAI's defense is fewer tokens per task, but that tradeoff only holds if your workload actually benefits from GPT-5.5's strengths.

What Claude Code Actually Is

Claude Code is a different category of product. It's not a chat interface with coding capabilities bolted on — it's a terminal-native agent built specifically for software engineers. It runs in your local terminal, integrates directly with VS Code and JetBrains, understands your full repo context, and executes multi-hour autonomous coding sessions that Anthropic describes as its core use case.

The underlying model powering serious Claude Code work today is Claude Opus 4.7, released April 16, 2026. Its signature benchmark is 64.3% on SWE-Bench Pro — the highest score on that test for complex multi-file GitHub issue resolution. Opus 4.7 leads GPT-5.5 on 6 of the 10 shared benchmarks both providers report, particularly on the reasoning-heavy and code review-grade tests (GPQA Diamond, HLE, SWE-Bench Pro, MCP Atlas).

For a ground-level look at how real developers are using it, the Y Combinator video featuring Garry Tan's Claude Code setup is worth 15 minutes. Tan walks through his "GStack" — the full Claude Code-native development environment he runs as a solo-founder-style operator.

Claude Code's strongest differentiator isn't a benchmark. It's the depth of context retention and the autonomy of its execution. In the Hacker News thread that followed GPT-5.5's launch, one recurring pattern emerged: developers described Claude Code as "autonomous/thoughtful — it plans deeply and asks less of the human," while Codex/GPT-5.5 is characterized as "an interactive collaborator where you steer it mid-execution."

Check our complete guide to Claude Code for a deep dive on how to set up and optimize Claude Code for your workflow.

Head-to-Head: Benchmarks That Actually Matter

Lushbinary's analysis of the 10 benchmarks both providers publicly report gives the clearest picture:

Claude Opus 4.7 leads on 6:

SWE-Bench Pro: 64.3% vs 58.6%
GPQA Diamond: Opus leads
HLE (with and without tools): Opus leads
MCP Atlas: Opus leads
FinanceAgent v1.1: Opus leads

GPT-5.5 leads on 4:

Terminal-Bench 2.0: 82.7% vs 69.4%
BrowseComp: GPT-5.5 leads
OSWorld-Verified: GPT-5.5 leads
CyberGym: 82%

ℹ️ One important nuance: GPT-5.5's 58.6% on SWE-Bench Pro is measured in single-pass mode. Claude Code typically runs multiple iterations. Comparing single-pass GPT-5.5 scores to multi-pass Claude Code sessions is not apples-to-apples.

The Pricing Drama You Need to Know

On April 22, The Register reported that Anthropic quietly updated its pricing page — Claude Code showed an "X" in the Pro column, suggesting the feature was being moved exclusively to the $100/month and $200/month Max plans. No press release, no email, no changelog entry.

⚠️ Reddit and HN caught fire immediately. For a large segment of Pro subscribers, Claude Code was the reason they paid $20/month. The apparent removal felt like a retroactive bait-and-switch.

Simon Willison's take captured the confusion well: within hours of his blog post being drafted, Anthropic had reversed the pricing page change. Anthropic's Head of Growth Amol Avasare clarified the change affected "~2% of new prosumer signups" only.

The contrast with Codex is stark. Builder.io's comparison makes it plain: "Many more people can live comfortably on the $20 Codex plan than Claude's $17 plan where limits get hit quickly."

Three Decision Scenarios

Scenario 1: Solo Developer / Indie Hacker

Winner: Claude Code — with caveats on budget.

If you're running a solo operation and want an AI that will autonomously execute multi-hour coding sessions while you focus on product decisions, Claude Code on Opus 4.7 is the deeper tool. The caveat: if you're on the $20 Pro plan and hitting limits regularly, GPT-5.5 in Codex is a legitimate alternative.

Scenario 2: Engineering Team (5–50 People)

Winner: GPT-5.5 / Codex — on ecosystem and GitHub integration.

For teams, Builder.io identifies Codex's GitHub integration as its decisive advantage. GPT-5.5 also supports the Agents.md standard — Claude Code's exclusive use of Claude.md creates friction in multi-tool team environments.

Scenario 3: Enterprise (100+ Engineers)

Winner: Hybrid + cc-switch.

At enterprise scale, the right answer is an intelligent routing layer. cc-switch (49K stars) unifies Claude Code, Codex, OpenCode, and Gemini CLI into a single Rust-powered desktop app.

💡 For enterprise teams: Claude Opus 4.7 for code review and complex refactors; GPT-5.5 for long-running agentic workflows and computer use. cc-switch makes this routing practical at scale.

The Verdict

Use Claude Code (Opus 4.7) if: complex multi-file coding, autonomous execution, terminal-native workflows.

Use GPT-5.5 / Codex if: long-running tool chains, computer use, GitHub-centric team workflows, cost-sensitive setups.

Use both (via cc-switch) if: team or enterprise scale with mixed workloads.

The developers winning with AI coding in 2026 stop asking "which is better overall?" and start asking "which is better for this specific task?"

Originally published at ComputeLeap

Claude Code Agentic Stack: cc-switch & claude-context MCP

Max Quimby — Thu, 23 Apr 2026 03:36:41 +0000

Claude Code just won a Webby Award for Best Product or Service in AI Features & Innovation. Boris Cherny, Claude Code's PM at Anthropic, announced the win on X to a wave of congratulations from the developer community:

📖 Read the full version with charts and embedded sources on ComputeLeap →

But the real story isn't the trophy — it's what's happening in the GitHub repos trending alongside it.

Two repos hit the GitHub Trending page on the same day as the Webby announcement: cc-switch (+665 stars in 24 hours, 48,667 total) and claude-context (+873 stars). Both extend Claude Code's capabilities significantly — and together with a properly configured CLAUDE.md, they represent what serious agentic developer stacks look like in 2026.

This guide covers exactly how to set up both tools and wire everything together for maximum development velocity.

What the "Agentic Developer Stack" Actually Means in 2026

In the 2026 context, an agentic developer stack has three layers:

Provider management — switch between Claude Code, Codex, Gemini CLI, OpenCode, and other AI coding tools from a single interface, sharing provider configs, MCP servers, and skills
Codebase context — give your AI agent deep semantic understanding of your entire codebase, not just the files currently open
Agent configuration — the CLAUDE.md files, skills, and subagent definitions that turn Claude Code from a general-purpose tool into a domain-specific engineering partner

According to Anthropic's 2026 Agentic Coding Trends Report, teams using structured CLAUDE.md configs and subagent workflows report 2-4x velocity improvements over baseline Claude Code usage. The tools in this guide enable exactly that configuration.

Layer 1: cc-switch — Unified Provider Management

What cc-switch Does

cc-switch is a cross-platform desktop app built with Tauri and Rust that unifies management of five AI coding CLI tools: Claude Code, OpenAI Codex, Gemini CLI, OpenCode, and OpenClaw. Instead of maintaining separate configuration files and MCP server setups for each tool, cc-switch provides a single interface that syncs settings bidirectionally.

Key features:

50+ built-in provider presets — one-click import of API configurations for Anthropic, OpenAI, Gemini, xAI, Mistral, and more
System tray quick switch — instant provider switching without opening a terminal
Unified MCP & Skills Management — install MCP servers and skills once, sync across all four apps
Cloud sync — settings sync via Dropbox, OneDrive, iCloud, or WebDAV servers
Usage dashboard — track spending, request counts, and token consumption per provider
Cross-platform — Windows, macOS, and Linux support

💡 cc-switch is built with Tauri (Rust-based) for native performance — not an Electron wrapper. Cold launch is under 200ms and system tray switching responds in under 50ms. This matters when you're switching between providers dozens of times a day.

Installing cc-switch

macOS:

brew install --cask cc-switch

Or download the latest release from cc-switch/releases — .dmg for macOS, .exe for Windows, .AppImage for Linux.

cc-switch --version

Initial Setup: Provider Configuration

On first launch, cc-switch walks you through connecting your providers:

Open cc-switch from the system tray or Applications folder
Click Providers → Add Provider
Select from the preset list (Anthropic, OpenAI, Gemini, etc.) or add a custom provider
Paste your API key — cc-switch stores it in your OS keychain, not in plain text
Test the connection with the Verify button

For Claude Code, cc-switch automatically detects your existing ~/.claude/ configuration and imports it. Your existing settings, custom commands, and history are preserved.

Setting Up MCP Servers in cc-switch

The real power of cc-switch is managing MCP servers across all your coding tools simultaneously. Instead of configuring the same MCP server four separate times, you configure it once and cc-switch deploys to all connected tools:

cc-switch mcp add --name "claude-context" \
  --command "npx" \
  --args "-y @zilliztech/claude-context" \
  --scope all-tools

Layer 2: claude-context MCP — Semantic Codebase Search

Why Codebase Context Is the Biggest Bottleneck

When you ask Claude Code to modify a function that depends on types defined in five other files, Claude Code has to either load all five files into context (expensive) or try to infer the types from what it can see (error-prone). claude-context solves this with semantic search over your entire codebase.

Instead of loading full files, it retrieves only the semantically relevant code snippets. According to Augment Code's MCP registry benchmarks, claude-context achieves approximately 40% token reduction under equivalent retrieval quality conditions.

How claude-context Works

claude-context uses a hybrid search approach:

BM25 — lexical matching (finds exact variable names, function signatures)
Dense vector search — semantic matching (finds conceptually related code even with different naming)

Your codebase is indexed into a Milvus vector database (local) or Zilliz Cloud (managed). The index uses AST-aware chunking — it understands code structure at the syntax level. Function bodies, class definitions, and interface declarations are kept semantically intact.

💡 claude-context uses incremental Merkle-tree-based indexing. After the initial index build, only changed files are re-indexed. For a mid-size repo (50K LOC), re-indexing typically completes in under 5 seconds after a git pull.

Installing and Configuring claude-context

Prerequisites: Node.js 18+ and a running Milvus instance (local Docker) or Zilliz Cloud account.

npm install -g @zilliztech/claude-context
claude-context init   # configure vector DB + embedding provider
cd your-project && claude-context index .

Register with Claude Code:

{
  "mcpServers": {
    "claude-context": {
      "command": "npx",
      "args": ["-y", "@zilliztech/claude-context", "serve"],
      "env": {
        "MILVUS_URI": "http://localhost:19530",
        "EMBEDDING_PROVIDER": "openai",
        "OPENAI_API_KEY": "${OPENAI_API_KEY}"
      }
    }
  }
}

Or use cc-switch's MCP manager (recommended) — it handles the configuration and syncs it across all your AI coding tools automatically.

Using claude-context During Development

Once installed, claude-context adds a search_codebase tool to Claude Code. You can invoke it explicitly:

Use the search_codebase tool to find all implementations of the PaymentProcessor interface before modifying it.

Or Claude Code will invoke it automatically when understanding more of the codebase would improve its response.

💡 For large monorepos, create a .claude-context-ignore file (similar to .gitignore) to exclude generated files, node_modules, build artifacts, and test fixtures. This keeps the index clean and retrieval precise.

Layer 3: CLAUDE.md Configuration — Making It All Stick

Having great tools is only half the equation. The other half is configuring Claude Code to use them intelligently. This is where CLAUDE.md comes in — and where most developers leave significant productivity on the table.

For the fundamentals, see our Claude Code Complete Guide. This section focuses on configuration patterns specific to the 2026 agentic stack.

The Role of CLAUDE.md in an Agentic Stack

CLAUDE.md is the document Claude Code reads at the start of every session. According to the MindStudio guide on Agentic Business OS architecture, it's the "foundational document for your brand context layer — it defines what every agent knows before it starts any task."

Use it to tell the agent:

Which MCP servers are available and when to use them
Your coding standards and conventions
When to spawn subagents vs. work in the main context
What tools to reach for first

Sample CLAUDE.md for the 2026 Agentic Stack

# Project: [Your Project Name]

## Stack
- Language: TypeScript 5.4 (strict mode)
- Runtime: Node.js 22 LTS
- Package manager: pnpm

## MCP Servers Available
- **claude-context**: Use `search_codebase` before modifying any class, interface, 
  or utility function that may have downstream consumers. Always search before refactoring.
- **chrome-mcp**: Available for UI verification tasks.

## Coding Standards
- Functions: single responsibility, <=50 lines
- No `any` types — use `unknown` + type guards
- Tests: co-located `.test.ts` files, Vitest
- Commits: conventional commits format

## Subagent Rules
- Spawn a subagent (with worktree isolation) for: feature branches, large refactors, research
- Keep the main context for: interactive debugging, short edits, Q&A

## Agent Workflow
1. Search codebase (claude-context) before modifying shared code
2. Write tests before implementation for new features
3. Run `pnpm build` and `pnpm test` before committing

This pattern — explicitly naming available MCP servers and when to use subagents — is what separates teams that get 2-4x velocity gains from teams that treat Claude Code as smart autocomplete.

For detailed CLAUDE.md patterns, see Karpathy's CLAUDE.md template analysis.

Subagent Setup with Worktree Isolation

For complex features requiring parallel workstreams, the official subagent documentation provides the full setup. The key pattern:

---
name: feature-agent
description: Use for implementing new features across multiple modules
isolation: worktree
tools: [read, edit, write, bash, search_codebase]
---

You are a focused implementation agent. Use search_codebase to understand 
existing patterns before writing new code. Work in the isolated worktree.

Setting isolation: worktree gives the subagent its own copy of the repository, preventing conflicts when multiple agents work in parallel. For more on this, see the Claude Code best practices guide.

The Pricing Context: What the Pro Plan Controversy Means for Your Setup

On April 21, 2026, Anthropic briefly removed Claude Code from the $20/month Pro plan listing — prompting a 2,648-upvote Reddit thread and coverage in The Register and XDA Developers. Simon Willison's analysis described it as an "A/B test on ~2% of new prosumer signups." Anthropic reversed the change the same day — existing Pro and Max subscribers are not affected.

But the incident reveals the underlying tension: Claude Code sessions with Claude Opus 4.7 run up to three times longer than on 4.6, and inference costs are escalating.

⚠️ If you're building agentic workflows with long Claude Code sessions, budget for the Max plan ($100/month for 5x). Agentic sessions — especially with subagents and frequent claude-context queries — consume context much faster than interactive sessions. Use cc-switch's usage dashboard to track token consumption and catch runaway workflows before they hit billing limits.

The Full Stack Setup Sequence

1. Install Claude Code:

npm install -g @anthropic-ai/claude-code
export ANTHROPIC_API_KEY=your_key_here

2. Install cc-switch:

brew install --cask cc-switch
# Or: github.com/farion1231/cc-switch/releases

3. Import your existing Claude Code config — cc-switch auto-detects ~/.claude/ on first launch.

4. Install and configure claude-context:

npm install -g @zilliztech/claude-context
claude-context init
cd your-project && claude-context index .

5. Register claude-context MCP via cc-switch → MCP → Add Server → scope: All Tools.

6. Write your CLAUDE.md in your project root using the template above.

7. Define subagents in .claude/agents/ — start with a feature-agent and a research-agent.

8. Test the full stack:

claude
# Ask: "Search the codebase for the authentication flow and explain it"
# claude-context should invoke automatically

What's Next in the Ecosystem

A few things worth watching:

cc-switch's cloud sync is expanding to git-based sync, enabling team-wide provider config sharing
claude-context's offline mode (tracking in Issue #162) would enable fully local indexing without an external vector database
MCP Tool Search (launched January 14, 2026) allows Claude Code to dynamically load tools into context when MCP servers have 50+ tools — reducing context pressure from large MCP setups

The underlying trend is clear: Claude Code has crossed from "developer tool" to "developer platform." The Webby Award is the cultural marker. The GitHub trending repos are the technical evidence. Setting up this stack today puts you in front of the curve.

Summary

Tool	Purpose	GitHub
cc-switch	Unified provider + MCP management desktop app	farion1231/cc-switch
claude-context	Semantic codebase search MCP	zilliztech/claude-context
CLAUDE.md	Agent configuration and context file	shanraisshan/claude-code-best-practice

For the full Claude Code foundation, read the Claude Code Complete Guide. For browser automation integration, see Chrome's built-in MCP server guide.

Sources: cc-switch GitHub · claude-context GitHub · Webby Awards 2026 · Simon Willison · The Register · XDA Developers · Anthropic Subagent Docs · MindStudio Agentic OS · Anthropic 2026 Agentic Coding Trends

Originally published at ComputeLeap

Iran's Prediction Markets Tell Two Stories

Max Quimby — Tue, 21 Apr 2026 04:04:57 +0000

📖 Read the full analysis with charts on The Arc of Power →

On April 7, 2026, as President Trump was preparing to announce a two-week ceasefire with Iran, more than fifty newly-created accounts on Polymarket placed large, specific bets that the ceasefire would be announced that day. Minutes later, Trump made the announcement. The accounts profited approximately $600,000. Within 48 hours, the White House had sent internal emails warning staff not to place prediction market bets related to the Iran war.

Our thesis: prediction markets are a remarkably accurate signal for short-term diplomatic timing and a systematically poor signal for structural outcomes.

The $200 Million Experiment

Over $200 million has traded on Polymarket contracts related to Iran's ceasefire timing. Approximately $118 million was bet specifically on an April 7 deadline — the exact day Trump announced the ceasefire.

CNN reported that a single trader made nearly $1 million from well-timed Polymarket bets correctly predicting US and Israeli military actions against Iran since 2024. The White House warned staff not to bet on Iran war outcomes. Two senators wrote the CFTC demanding investigation. The BETS OFF Act was introduced in Congress.

The regulatory framing matters: The BETS OFF Act would prohibit contracts on "government actions, terrorism, war, assassination, and events where an individual knows or controls the outcome." The last clause is the tell — directed at people who influence outcomes, not just know about them.

What the Markets Actually Got Right

The ceasefire timing markets were accurate. April 7 was right. The probability curve leading into the announcement showed a sustained spike beginning roughly 6-8 hours before Trump spoke — consistent with information leakage through informal channels.

The regime stability markets have been roughly accurate. Polymarket currently prices an 80.5% probability against the Iranian regime falling before 2027. Despite Khamenei's assassination and ongoing protests, the IRGC's institutional structure has remained intact. The market's skepticism of regime collapse — maintained even as Western media ran "end of the regime" framings — has proven correct.

What the Markets Are Getting Wrong

The 67% probability of a nuclear deal by June 30 is where prediction markets hit the limits of their model.

Current odds (April 20, 2026):

Market	Odds
Nuclear Deal by April 30	36%
Nuclear Deal by June 30	67%
Nuclear Deal before 2027	59-61%
Regime Falls before 2027	19.5%

The problem: prediction markets aggregate the probability that a deal happens, not the probability that a deal resolves the underlying dispute. A deal that fails to address uranium enrichment infrastructure is not a deal. It is a delay.

Kalshi surged to 61% on nuclear deal odds following Trump's April 13 statement that Iran wants a deal "badly." Markets correctly incorporated Trump's statement — but cannot distinguish between a statement made for domestic political effect and one reflecting genuine diplomatic progress.

The contrarian read on 67%: The markets cannot price the difference between "a document is signed" and "the structural conditions for Iranian nuclear breakout capability are removed." These resolve identically in contract language but produce very different geopolitical outcomes.

The Information Asymmetry Diagnostic

The Bloomberg analysis identified two populations who could have generated the April 7 betting pattern:

Population 1: Informed analysts — people who track backchannel communications through open-source methods and correctly model diplomatic decision-making. The Islamabad negotiations were not secret. A skilled analyst could have assessed April 7 as the most likely ceasefire date.

Population 2: Informed insiders — people with access to non-public government information. The fifty new accounts make this the more plausible explanation for that specific cluster.

The distinction matters: if it's Population 1, markets aggregate genuine analytical skill. If it's Population 2, markets track who has access to government communications. The signal quality is real in both cases — but for different reasons.

What This Means

Prediction markets on Iran are useful as a rough prior — a starting estimate before you apply your own analysis. They are not useful as a substitute for structural analysis.

The 67% nuclear deal by June 30 tells you what the aggregate of informed and uninformed bettors believes will happen. It does not tell you whether the deal, if it happens, will matter.

What to watch in the next 48 hours: The ceasefire expires April 22. Watch whether the ceasefire extension contract price spike precedes or follows the official announcement. That timing will tell you more about information asymmetry in Iran prediction markets than any regulatory filing.

Originally published at The Arc of Power

Hermes Agent v0.10: Local AGI Stack & Browser Guide

Max Quimby — Tue, 21 Apr 2026 03:53:49 +0000

📖 Read the full version with diagrams and embedded sources on AgentConn →

In seven weeks, NousResearch/hermes-agent went from zero to 95,600 GitHub stars — the fastest star velocity of any agent framework in 2026. The question isn't whether Hermes Agent matters. The question is what v0.10.0 (released April 16, 2026) actually changes — and whether local deployment and browser integration are ready for production use.

What's New in v0.10.0 (v2026.4.16)

The v0.10 release is the most practically significant update for developers who want to run Hermes without API costs or need browser automation in their workflows.

Key additions in v0.10:

Ollama integration — First-class local model support via Ollama, llama.cpp, and vLLM with zero API cost
hermes-plugin-chrome-profiles — Experimental Chrome CDP integration for multi-profile browser automation
Browser Use v0.8.0+ — Upgraded browser automation with better reliability and vision integration
GEPA v2 improvements — Faster evolution cycles for the self-improvement engine
Android/Termux support — Hermes can now run natively on Android devices

The install story hasn't changed: one command, works everywhere.

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Local Deployment: Ollama Integration in Practice

The case for local Hermes is straightforward: if you're running a long-horizon autonomous task — a 2-hour coding session, a research crawl, a data pipeline — API costs compound fast. Switching to Ollama means the economics of "leave it running" change completely.

Hardware Requirements

Official Ollama integration docs are specific about what local deployment requires:

Setup	VRAM	Throughput	Notes
Apple Silicon (M2/M3/M4)	Unified RAM (≥16GB)	50-80 tok/s on 7B	Metal acceleration
NVIDIA GPU	8-16GB VRAM+	60-100+ tok/s on 7B	CUDA via Ollama
CPU-only	n/a	3-8 tok/s on 7B	Usable, not recommended

The recommendation is a 7B or 13B model with 64K+ context window. Models with shorter contexts will truncate mid-task and produce inconsistent results.

Setup

# Install Ollama first (if not already)
brew install ollama  # macOS

# Pull a compatible model (llama3.1 has 128K context natively)
ollama pull llama3.1:8b

# Configure Hermes to use local model
cat >> ~/.hermes/config.yaml << 'EOF'
llm:
  provider: ollama
  model: llama3.1:8b
  base_url: http://localhost:11434
  context_window: 65536
EOF

# Start Ollama server
ollama serve &

# Run Hermes
hermes run "your task here"

The Context Window Constraint

The critical gotcha: your model must support ≥64K context for reliable multi-step tasks. Most quantized 7B models default to 4K or 8K context.

Models confirmed to work well with local Hermes:

llama3.1:8b (128K context natively)
mistral:7b-instruct-q4_K_M (64K context with extended config)
qwen2.5:14b (32K context, good for medium tasks)
deepseek-coder-v2:16b (128K context, strong for coding tasks)

Browser Integration: CDP and Browser Use

Hermes ships with two browser automation layers:

Browser Use v0.8.0+ is the default — high-level API for navigation, form filling, clicking, and vision-enabled page reading.

hermes-plugin-chrome-profiles is the experimental CDP layer for multi-account workflows. It lets you connect to a running Chrome instance and switch between profiles programmatically.

# Browser Use is bundled — just enable it in config
cat >> ~/.hermes/config.yaml << 'EOF'
tools:
  browser:
    enabled: true
    provider: browser_use
    headless: false
    timeout: 30
EOF

hermes run "Research and summarize the top 5 HN posts from today, save to research-notes.md"

The CDP plugin is useful for multi-account testing but not production-stable — community reports of connection drops mid-task. Treat it as beta.

The GEPA Self-Improvement Engine

GEPA (Genetic Evolution of Prompt Architectures) was presented as an ICLR 2026 Oral. The mechanism: GEPA reads execution traces, identifies failure patterns, and proposes improvements to skill prompts. Unlike simple retry logic, GEPA does causal analysis — it tries to understand why something failed.

The 40% speedup on repeat tasks is achievable, but accumulates over time. The first hour feels similar to any other agent. By hour two, after 15-20 similar tasks, the improvement becomes noticeable.

The Self-Grading Problem

Hermes's self-evaluation is optimistic. The workaround: explicit success criteria.

# Instead of vague prompts:
hermes run "Fix the authentication bug in auth.py"

# Use verifiable success criteria:
hermes run "Fix the authentication bug in auth.py.
Success criteria:
1. All tests in test_auth.py pass
2. Login endpoint returns 200 for valid credentials
3. Login endpoint returns 401 for invalid credentials
Run the tests and show output before marking complete."

Hermes vs Claude Code: Complementary, Not Competing

Community consensus on Reddit: these are complementary tools.

Hermes excels at: long-horizon orchestration, repetitive workflows, local deployment, multi-agent coordination, persistent memory.

Claude Code excels at: deep intensive coding, complex architecture decisions, production-critical changes, interactive debugging.

The practical pattern: Hermes runs background orchestration, calls Claude Code for intensive steps, accumulates skills from each cycle.

Quick Start Summary

# Install
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# Cloud API path
echo "ANTHROPIC_API_KEY=your-key" >> ~/.hermes/.env
hermes run "your first task"

# Local Ollama path (zero cost)
ollama pull llama3.1:8b
hermes config set llm.provider ollama llm.model llama3.1:8b
hermes run "your first task"

95,600 stars in seven weeks is an endorsement of the concept. v0.10 is the release where the execution starts catching up to the pitch.

Originally published at AgentConn

Kimi K2.6 vs Claude Opus 4.7: The 88% Cost Advantage

Max Quimby — Tue, 21 Apr 2026 03:28:38 +0000

When Clement Delangue, the CEO of Hugging Face, called Kimi K2.6 a standout open-source model on the day of its release, the AI procurement conversation shifted. Not because a Chinese model was competitive — Kimi's K2 family and DeepSeek had already proved that point — but because of what competitive now costs.

📖 Read the full version with charts and embedded sources on ComputeLeap →

Kimi K2.6, the latest open-weight model from Beijing-based Moonshot AI, runs at $0.60 per million input tokens on the official API. Claude Opus 4.7, Anthropic's frontier model, costs $5.00 per million input tokens. That's an 8.3× difference — or roughly 88% cheaper.

If your team spends $10,000 a month on Claude Opus 4.7 today, K2.6 could in theory handle the same workload for $1,200. Engineering teams are already running the math. This guide gives you the honest version of that calculation: where K2.6 delivers, where it doesn't, and how to make the decision without the hype in either direction.

The Architecture Behind the Price

The reason Kimi K2.6 can be so cheap while performing at frontier level comes down to architecture. K2.6 is a Mixture-of-Experts (MoE) model: it has 1 trillion total parameters but activates only 32 billion per token during inference.

Dense models pay the full computational cost of every parameter on every token. MoE models route each token through a small subset of specialized "expert" subnetworks. The result is trillion-parameter model quality at a fraction of the inference cost — which flows directly to the API price.

K2.6's MoE structure is unusually large-scale:

384 expert subnetworks, with 8 selected per token plus 1 shared expert
61 transformer layers (including 1 dense layer)
Multi-head Latent Attention (MLA) mechanism for efficient long-context processing
256K token context window — enough to process entire large codebases in a single prompt
MoonViT vision encoder (400M parameters) for native multimodal input

The 256K context and 160K-token vocabulary round out a model that's clearly engineered for production coding workloads, not benchmark optimization.

ℹ️ MoE models have a catch: they're harder to run locally. At 1T total parameters, K2.6 requires significant hardware even with 8-bit quantization. Community quantizations exist on HuggingFace (via unsloth and ubergarm), but self-hosted K2.6 is a serious infrastructure commitment. If local deployment is your goal, smaller Chinese open-source models may be more practical.

Benchmarks: Where K2.6 Actually Leads

Benchmark theater is a real phenomenon in AI. But some numbers here are worth taking seriously because they map to real engineering workloads.

Benchmark	Kimi K2.6	Claude Opus 4.7	GPT-5.4	Gemini 3.1 Pro
SWE-Bench Pro	58.6	53.4	57.7	—
HLE Full w/ Tools	54.0	53.0	52.1	51.4
BrowseComp	83.2	—	82.7	—
SWE-Bench Verified	80.2	80.8	—	—
API Input Price	$0.60/M	$5.00/M	—	—
API Output Price	$2.50/M	$25.00/M	—	—

SWE-Bench Pro measures performance on real GitHub issues — actual engineering tasks, not constructed problems. K2.6's 58.6 vs Claude Opus 4.6's 53.4 is a meaningful gap on the metric that matters most to software teams.

HLE (Humanity's Last Exam) with Tools is a research-grade exam specifically designed to resist AI memorization. K2.6 leads all frontier models at 54.0, placing above Claude Opus 4.6 (53.0) and GPT-5.4 (52.1). This is surprising for a model priced as a "budget" alternative.

⚠️ These benchmarks are from Moonshot AI's own release. Independent, third-party SWE-Bench Pro evaluations are still catching up. Take the K2.6-specific numbers with the usual caveat applied to vendor benchmarks — the HN community reception and Cursor integration are better early signals than the numbers alone.

The Agent Swarm Capability

Beyond raw benchmark scores, K2.6 introduces a capability that doesn't have an obvious analogue in Opus 4.7: agent swarm scaling.

K2.6 can orchestrate up to 300 sub-agents executing 4,000 coordinated steps — decomposing a complex task into parallel, domain-specialized subtasks running simultaneously. According to Moonshot's technical blog, real-world case studies include:

Optimizing Zig inference performance from 15 to 193 tokens/second over a 12-hour autonomous run
Overhauling a financial matching engine from 0.43 to 1.24 million transactions/second (185% improvement) over a 13-hour session
Generating full-stack websites with databases from text-only prompts

A "Claw Groups" preview feature lets humans and agents collaborate in a shared operational space, with task-to-agent matching and failure detection. This positions K2.6 less as a chat model and more as an infrastructure primitive for long-horizon background workloads.

Real Developer Reception: What the HN Thread Reveals

The Kimi K2.6 Hacker News thread scored 592 points with 303 comments within hours of release — unusually strong engagement for a non-US model launch.

The developer sentiment breaks roughly into thirds:

Bullish: "Dirt cheap on OpenRouter for how good it is" (regularfry). Simon Willison posted a live demo of K2.6 generating animated SVG HTML via OpenRouter, citing it as practical and fast. One commenter confirmed K2.6 powers Cursor's composer-2 model — a real-world quality endorsement that's harder to fake than a benchmark.

Skeptical: "Tried it once... my experience was just okay-ish despite strong benchmarks." Some users report it "does only slightly better than Kimi K2.5" and "struggles with domain-specific tasks."

Philosophical: "Funny that Chinese companies are pioneering possibly the world's most important tech via open source while the US goes closed" — a sentiment that lands differently when you consider DeepSeek R1, Qwen, and now K2.6 all dropped open weights.

The median impression aligns with BenchLM's Claude Opus 4.7 vs Kimi K2.5 comparison: Claude leads overall (94 vs 68) with its sharpest advantage in agentic reliability. K2.6 closes that gap meaningfully, but the gap hasn't entirely closed.

The Qwen3.6-Max-Preview Context: Two Chinese Models in One Day

K2.6 didn't land in isolation. On the same day — April 20, 2026 — Alibaba released Qwen3.6-Max-Preview, topping six major coding benchmarks including SWE-benchPro, Terminal-Bench 2.0, SkillsBench, and SciCode.

Qwen3.6-Max-Preview is proprietary (no open weights), but the convergence of two major Chinese AI releases on the same day is structurally significant. Jack Clark's Import AI newsletter has tracked this arc: Chinese models are no longer "almost competitive" — they're trading leads on specific benchmarks with the frontier models from Anthropic, OpenAI, and Google.

The ChinAI newsletter framed it earlier this year: "Chinese open-source models are now leading foreign open-source models and closing in on global first-tier closed-source models." April 20 is a data point, not an anomaly.

If you've been following our Qwen 3.5B local setup guide, K2.6 is the cloud-API counterpart to that story — optimized for different constraints but part of the same structural trend.

When to Use Kimi K2.6

K2.6 is the right choice when:

Long-horizon coding tasks — multi-hour autonomous runs on well-scoped engineering problems, where the agent swarm architecture pays off
High-volume production workloads — teams spending $5K+/month on Opus-level API calls where the 88% cost delta is real money
One-shot code generation — initial code scaffolding, UI generation from design prompts, full-stack boilerplate where SWE-Bench Pro performance matters
Agent orchestration — building multi-agent systems (see our OpenAI Agents Python SDK tutorial for framework context) where K2.6's 300-sub-agent ceiling gives headroom
Two-tier architectures — using K2.6 for first-pass generation and Claude for final review/validation captures most of the cost savings without sacrificing output quality

When Claude Opus 4.7 Is Still Worth the Premium

Stick with Opus 4.7 when:

Complex reasoning under ambiguity — open-ended problems where the model needs judgment, not execution; Claude's agentic reliability lead is real
Production workloads where errors are expensive — if a wrong answer costs $10K to fix, the API call price is irrelevant
Enterprise compliance — Anthropic's usage policies, data handling, and audit trails are more mature than Moonshot's at the enterprise procurement level
Multimodal tasks requiring judgment — vision tasks that need contextual interpretation, not just image recognition
Creative and long-form writing — anecdotal but consistent: Claude's prose quality and editorial judgment remain ahead

💡 The hybrid approach is underrated: use K2.6 for code generation and execution, Claude Opus 4.7 for planning and validation. Our API cost comparison showed that most production AI spend is concentrated in generation volume — exactly where the K2.6 cost advantage is largest.

Accessing K2.6: Your Options

Kimi.com API (direct): $0.60/M input, $2.50/M output. Compatible with the OpenAI Python SDK via base URL swap — no code refactoring if you're already calling OpenAI-compatible endpoints.

OpenRouter: $0.60/M input, $2.80/M output (slight markup). Useful for routing alongside other models.

Self-hosted: Available on HuggingFace under Modified MIT license. Requires transformers >=4.57.1. Recommended inference: vLLM or SGLang. Commercial restriction applies for entities with 100M+ MAU or $20M+ monthly revenue.

# Drop-in replacement for OpenAI-compatible code
import openai

client = openai.OpenAI(
    api_key="your-kimi-api-key",
    base_url="https://api.kimi.com/v1"
)

response = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "Your prompt here"}],
    max_tokens=4096
)

The OpenAI SDK compatibility is the practical win here — most teams can A/B test K2.6 against their current model with a one-line base URL change.

The Bottom Line

Kimi K2.6 is not a Claude Opus 4.7 replacement for all workloads. But for code generation at volume, long-horizon agent tasks, and cost-sensitive production workloads, K2.6 delivers at a price point that makes the tradeoffs genuinely favorable.

The hidden cost of cheap models is real — we covered it here. But the hidden cost of expensive models is also real: teams that overpay for capabilities they don't use, or avoid running AI on high-volume tasks because the math doesn't work. K2.6 makes more tasks economically viable, and that's worth something even if you keep Claude for the hard stuff.

Quick decision:

High-volume coding generation → K2.6
Complex reasoning, enterprise compliance, judgment-heavy tasks → Claude Opus 4.7
Both → two-tier architecture (K2.6 generates, Claude validates)

Originally published at ComputeLeap

deer-flow vs evolver vs GenericAgent: Production-Ready?

Max Quimby — Mon, 20 Apr 2026 04:22:45 +0000

deer-flow vs evolver vs GenericAgent: Production-Ready?

📖 Read the full version with diagrams and embedded sources on AgentConn →

On April 19, 2026, three self-evolving agent frameworks landed simultaneously in GitHub's global top 10: bytedance/deer-flow at 62,800 stars, EvoMap/evolver at 5,700 stars, and lsdefine/GenericAgent at 4,600 stars. That's not three projects trending. That's a category arriving.

The timing matters. We've already covered GenericAgent and EvoMap's skill-tree approaches in detail. What hasn't been covered is how they compare to deer-flow, which is by far the largest of the three — and how all three stack up on the question that actually matters for teams considering them: can you run this in production without it becoming a liability?

What "Self-Evolving" Actually Means (And What It Doesn't)

Before comparing frameworks, the clarification that saves everyone time: none of these systems modify their underlying model weights. This is important because the marketing doesn't always make it clear.

The academic survey that anchors this category defines the feedback loop cleanly: agent executes a task → environment responds → optimizer extracts patterns → skill store is updated → next execution draws on those patterns. The agent improves over time not because the model gets smarter, but because the tools available to the model improve.

The Hacker News discussion put it plainly: "Self-improvement is really prompt/tool optimization, not weight updates." The skeptic position is correct if you're expecting AGI-style capability jumps. The practitioner position is also correct: process recursion — skill accumulation — is a genuine capability improvement, even if it's not the learning the term implies.

With that framing established, here are the three frameworks.

deer-flow (ByteDance) — The SuperAgent Harness

At 62,800 stars, deer-flow isn't just the largest self-evolving framework on GitHub — it's one of the largest agent frameworks period. It claimed #1 on GitHub Trending in February 2026 when version 2 launched, and crossed 60,000 stars within weeks.

The core concept is what ByteDance calls a "SuperAgent harness." Rather than a single intelligent agent, deer-flow is an orchestration runtime that gives agents the infrastructure to actually get work done: a lead agent that decomposes complex tasks into parallelizable sub-tasks, spawning sub-agents with scoped contexts, running them concurrently, then synthesizing results into a coherent output. The framework handles tasks that "take minutes to hours."

What makes this concrete is the execution environment. As Dev.to's technical breakdown put it directly: "The agent does not suggest a bash command. It runs it." Deer-flow provides agents with an isolated Docker container with filesystem access and a bash terminal — actual compute, not a sandbox emulation.

Key architecture decisions:

Sub-agent parallelization: Scoped contexts, concurrent execution, convergent synthesis
Persistent memory: Asynchronous debounced queue tracking user preferences and project state across sessions
Skills system: Markdown-based workflow definitions (extensible without code changes)
Model agnosticism: Works with GPT-4, Claude, DeepSeek, Kimi, Doubao-Seed, and Ollama

The production deployment guidance is notably serious. The documentation specifies 8+ vCPU / 16GB RAM minimum for server deployment, Docker-based production and development modes, and explicit warnings about untrusted network exposure with IP allowlisting and VLAN isolation recommendations.

The ByteDance factor: VentureBeat noted that "ByteDance provenance may trigger organizational review processes." Enterprise teams in regulated industries or US government-adjacent environments should route this through procurement before deploying. MIT-licensed, fully auditable codebase — but the organizational source still matters for some teams.

Built on: LangGraph + LangChain. If your team already uses LangGraph for orchestration, deer-flow's mental model will feel familiar.

evolver (EvoMap) — Genome Evolution Protocol

At 5,700 stars, EvoMap/evolver is the smallest of the three by star count but the most distinctive by architecture. It introduced the Genome Evolution Protocol (GEP) — a framework for treating prompt evolution as a structured, auditable process analogous to biological gene expression.

The GEP deep dive explains the key insight: rather than letting agents evolve through raw trial-and-error, GEP solidifies successful behaviors into three reusable asset types:

Genes: Atomic capability units — validated code or prompt fragments for a single operation
Capsules: Successful task execution paths — complex problem solutions encoded as reusable workflows
Events: Immutable evolution logs — every mutation (Innovation) or repair (Repair) recorded with full context

The operational logic is disciplined: the 70/30 rule allocates 70% of compute to stability (Repair mode) and 30% to capability expansion (Feature mode). When crashes or tool call failures are detected, evolver enters Repair Mode and follows explicit protocol gates before any mutation.

Critically: evolver does not edit code directly. It generates guided prompts for human review or integration with host runtimes. This limits scope — and also limits blast radius.

The launch story is worth knowing: evolver hit the top of ClawHub within 10 minutes of release in February 2026, racking up 36,000 downloads in three days. It later became the center of a plagiarism controversy when EvoMap accused Hermes Agent (released March 2026) of copying evolver's self-evolution architecture — a 24-39 day window from evolver's open-source release to Hermes Agent's similar feature shipping.

Best for: Teams that need compliance-friendly audit trails for agent behavior changes, or deployments in regulated environments where agent mutations need to be explainable.

GenericAgent (lsdefine) — The Minimal Skill Tree

GenericAgent makes its design philosophy explicit: "grows a skill tree from a 3,300-line seed, achieving full system control with 6x less token consumption." The Fudan University team built something unusually minimal — the entire framework is ~3K lines with a ~100-line agent loop.

The architecture is built around five layers of memory (L0–L4):

L0: Meta-rules (agent identity and constraints)
L1: Insights (generalized patterns from past tasks)
L2: Global facts (persistent world knowledge)
L3: Task skills (crystallized execution paths from completed tasks)
L4: Session archives (full interaction logs, added April 2026)

When GenericAgent completes a task, it automatically crystallizes the execution path as a skill file. As PyShine's walkthrough notes: "After a few weeks, an agent instance will have a skill tree no one else in the world has — all grown from 3K lines of seed code."

The token efficiency claim is real and measurable. Where comparable agents require 200K–1M token context windows, GenericAgent operates under 30K by loading only relevant skills from memory rather than the full history. The "6x less" figure comes from this selective loading compared to agents that stuff entire conversation histories into context.

Nine atomic tools cover the full system control surface: browser (with preserved login sessions), terminal, filesystem, keyboard/mouse input, screen vision, and mobile ADB. Multi-model: supports Claude, Gemini, Kimi, MiniMax.

Best for: Cost-conscious teams running long-running autonomous agents where token efficiency directly maps to operational cost. Also the most approachable codebase of the three — 3,300 lines is something a team can actually audit in a week.

The Security Reality No One Mentions

All three frameworks share a category-level risk that Simon Willison identified as "the lethal trifecta": if an agent combines (1) access to private data, (2) exposure to untrusted content, and (3) the ability to externally communicate, an attacker can trick it into exfiltrating private data to an external endpoint. Self-evolving agents make this attack surface significantly larger than standard API-call agents.

The 2026 AI Agent Security Report puts it starkly: 88% of organizations confirmed or suspected security incidents involving AI agents in the last year. Only 24.4% have full visibility into which agents are communicating with each other. More than half run with no security oversight or logging.

For self-evolving frameworks specifically, the risk compounds: if the framework modifies agent behavior over time (as all three do), security review at deployment isn't sufficient — you need ongoing behavioral monitoring.

Bessemer Venture Partners frames the identity problem: "In a mature agentic ecosystem, swarms of agents may be instantiated to perform a single task and then decommissioned within minutes — traditional security architectures that rely on periodic scans will fail to detect these identities entirely."

Practical mitigation per framework:

deer-flow: Docker sandbox isolation is built-in; use it. Enable IP allowlisting and VLAN isolation as the docs recommend. Monitor sub-agent spawning rates.
evolver: Use Review mode and validation steps. The audit trail via Events is the strongest governance artifact of the three.
GenericAgent: Audit the skill tree periodically. Skills accumulate without a built-in approval gate — add one in production deployments.

Decision Matrix

	deer-flow	evolver	GenericAgent
Stars	62.8k	5.7k	4.6k
Language	Python + TypeScript	JavaScript	Python
Self-evolution type	Sub-agent + memory	Prompt/gene evolution	Skill tree accumulation
Token efficiency	Moderate	N/A	6x vs. alternatives
Sandbox	Docker (built-in)	None	None
Audit trail	LangSmith/Langfuse	Built-in Events log	Session archive (L4)
ByteDance provenance	Yes	No	No
Production-ready	Yes (with hardening)	Yes (limited scope)	Yes (with monitoring)

Choose deer-flow when you're building long-horizon autonomous tasks — research pipelines, multi-step code generation, content workflows that run for hours. The Docker sandbox, sub-agent parallelization, and extensive deployment documentation make it the most enterprise-ready despite the ByteDance provenance consideration.

Choose evolver when compliance and audit trails are non-negotiable. The GEP protocol's structured mutation model is the only framework here that produces a legally defensible record of every agent behavior change.

Choose GenericAgent when token cost is the primary constraint, or when you want a framework small enough to audit completely. The 3,300-line codebase is readable by a small team in a week. The 6x token efficiency advantage is real and meaningful at production scale.

None of the above if you're building a customer-facing application where adversarial users could reach the agent with untrusted content. All three need additional input sanitization and communication controls before they're safe in that context.

For context on related frameworks: the hermes-agent review covers NousResearch's self-improving framework (95.6K stars) which is the highest-starred in this category but follows a different architectural approach.

Getting Started

deer-flow:

git clone https://github.com/bytedance/deer-flow
cd deer-flow && docker compose up

Visit localhost:3000. Works with any OpenAI-compatible API key.

evolver:

npm install -g @evomap/evolver
evolver init --mode review

Review mode prevents any mutation from applying without human confirmation — recommended for first deployments.

GenericAgent:

git clone https://github.com/lsdefine/GenericAgent
pip install -r requirements.txt
python agent.py

See GETTING_STARTED.md in the repo — the Fudan team wrote unusually clear onboarding documentation.

The category is real. Three frameworks at 62.8k, 5.7k, and 4.6k stars trending simultaneously isn't noise — it's the infrastructure layer of agentic AI arriving in production-deployable form. The question isn't whether to pay attention; it's which one fits your actual use case, and whether your team has thought through the security posture before the first deployment.

The comprehensive academic survey ends with an observation worth sitting with: "The challenge isn't making agents that learn — it's making agents whose learning is observable, bounded, and reversible." All three frameworks here have made progress on the first goal. The second and third are still largely up to the team deploying them.

Originally published at AgentConn

openai-agents-python: Build Multi-Agent AI Workflows (2026)

Max Quimby — Mon, 20 Apr 2026 03:38:53 +0000

OpenAI's openai-agents-python crossed 22,981 GitHub stars this week — gaining 751 in a single day and landing at #2 on GitHub's global trending list. That's not hype noise. It's developer validation. And it happened the same week OpenAI rolled out sandbox execution support for enterprise deployments, cementing this library's position as the most-starred agent framework on the platform.

📖 Read the full version with charts, code, and embedded sources on ComputeLeap →

But star counts tell you nothing about whether something is worth learning. So this tutorial skips the marketing and goes straight to the code. By the end, you'll have a working multi-agent research pipeline you can actually run — and an honest assessment of when this SDK makes sense versus building the same workflow with Anthropic's Claude.

Today's intelligence signals confirm what GitHub is showing: 5 of the top 7 trending AI repos are explicitly multi-agent or self-evolving systems. The infrastructure layer is materializing. If you're a developer building anything AI-adjacent in 2026, understanding how agent orchestration actually works — not in theory, but in production — is now a baseline skill.

▶️ Watch: Agents SDK from OpenAI! Full Tutorial

Why openai-agents-python Is Having Its Moment

The library is the official, production-ready successor to OpenAI's experimental Swarm library. Where Swarm was a research demo, openai-agents-python ships the same multi-agent primitives in a framework that's designed for real deployments.

ℹ️ The SDK is provider-agnostic — it works with OpenAI's APIs and supports 100+ additional LLMs via LiteLLM and compatible adapters. So despite the OpenAI branding, you're not locked in at the model layer.

Nine capabilities ship out of the box:

Agents — LLMs configured with instructions, tools, guardrails, and handoffs
Sandbox Agents — agents running inside isolated containers for extended tasks (TechCrunch, April 2026)
Agent Delegation — agents that function as tools, callable by other agents
Tools — function tools, MCP integrations, and hosted tools (file search, web search, code interpreter)
Guardrails — input/output validation with blocking and tripwire modes
Human In The Loop — structured pause points for human review
Sessions — automatic conversation history management
Tracing — built-in observability integrating with OpenAI's dashboard, Logfire, and OpenTelemetry
Voice — support for gpt-realtime-1.5 voice agents

Version v0.13 (the current release) added an any-LLM adapter, opt-in retry policies, MCP resource support, and session persistence — making it meaningfully more production-ready than it was at launch. The Definitive Guide to Agentic Frameworks in 2026 ranks it among the top 3 most actively developed frameworks alongside LangGraph and Microsoft's Agent Framework.

Installation and Setup

Requirements: Python 3.10+, an OpenAI API key.

pip install openai-agents

For voice support:

pip install "openai-agents[voice]"

Set your API key:

export OPENAI_API_KEY="sk-..."

Your first agent in under 10 lines:

from agents import Agent, Runner

agent = Agent(
    name="Assistant",
    instructions="You are a helpful assistant.",
)

result = Runner.run_sync(agent, "What is the capital of France?")
print(result.final_output)
# → "The capital of France is Paris."

That's the complete hello world. Agent defines the LLM + instructions + tools. Runner executes it. run_sync blocks until the agent produces its final output.

Core Concepts in 5 Minutes

Before building anything non-trivial, you need to understand five primitives.

1. Agents

from agents import Agent

researcher = Agent(
    name="Researcher",
    model="gpt-4o",
    instructions="""You research topics thoroughly.
    Always provide sources and key facts.""",
)

The model parameter defaults to gpt-4o if omitted. You can swap in any OpenAI model, or any LiteLLM-compatible endpoint.

2. Function Tools

from agents import function_tool

@function_tool
def search_web(query: str) -> str:
    """Search the web for information on a topic."""
    # Your search implementation here
    return f"Results for: {query}"

researcher = Agent(
    name="Researcher",
    instructions="Use search_web to find information.",
    tools=[search_web],
)

The @function_tool decorator auto-generates the JSON schema from your function signature and docstring. Pydantic validation runs on every call — no manual schema writing required.

3. Handoffs

Handoffs let one agent transfer control entirely to another:

from agents import Agent

writer = Agent(
    name="Writer",
    instructions="Write clear, engaging content based on research provided.",
)

researcher = Agent(
    name="Researcher",
    instructions="Research the topic, then hand off to the Writer.",
    handoffs=[writer],
)

When the researcher decides the user would be better served by the writer, it hands off and the writer takes over the conversation entirely. This is a one-way transfer — the researcher is done.

4. Agent as Tool

The alternative pattern keeps one agent in charge:

writer_tool = writer.as_tool(
    tool_name="draft_content",
    tool_description="Draft written content from a research summary.",
)

coordinator = Agent(
    name="Coordinator",
    instructions="Orchestrate research and writing. Use draft_content to get the writer's output.",
    tools=[writer_tool, search_web],
)

Here the coordinator calls the writer as a function and receives its output — the coordinator never loses control of the conversation.

5. Guardrails

from agents import Agent, GuardrailFunctionOutput, input_guardrail
from pydantic import BaseModel

class SafetyCheck(BaseModel):
    is_safe: bool
    reason: str

@input_guardrail
async def safety_check(ctx, agent, input):
    if "malicious" in input.lower():
        return GuardrailFunctionOutput(
            output_info=SafetyCheck(is_safe=False, reason="Flagged content"),
            tripwire_triggered=True,
        )
    return GuardrailFunctionOutput(
        output_info=SafetyCheck(is_safe=True, reason="OK"),
        tripwire_triggered=False,
    )

safe_agent = Agent(
    name="SafeAgent",
    instructions="Help users with their questions.",
    input_guardrails=[safety_check],
)

When tripwire_triggered=True, the agent never executes — preventing token spend on inputs that would fail downstream.

Building Your First Multi-Agent Workflow

Here's a complete, runnable research pipeline with three specialized agents. You can copy and run this directly:

import asyncio
from agents import Agent, Runner, function_tool

# --- Tool definitions ---

@function_tool
def web_search(query: str) -> str:
    """Search the web for information on a given query."""
    # Replace with your actual search API (Tavily, SerpAPI, etc.)
    return f"[Search results for '{query}': Top 5 results found.]"

@function_tool
def save_draft(content: str, filename: str) -> str:
    """Save a draft to disk."""
    with open(filename, "w") as f:
        f.write(content)
    return f"Saved draft to {filename}"

# --- Agent definitions ---

reviewer = Agent(
    name="Reviewer",
    model="gpt-4o",
    instructions="""You are a critical editor. Review drafts for:
    - Accuracy and factual claims
    - Clear structure and flow
    - Specific, actionable improvements
    Provide a verdict: APPROVED or NEEDS_REVISION.""",
)

writer = Agent(
    name="Writer",
    model="gpt-4o",
    instructions="""You are a clear, concise technical writer.
    Write well-structured content from research notes.
    When done, hand off to the Reviewer for quality check.""",
    tools=[save_draft],
    handoffs=[reviewer],
)

researcher = Agent(
    name="Researcher",
    model="gpt-4o",
    instructions="""You research topics thoroughly using web_search.
    Gather at least 3 distinct facts or perspectives.
    Summarize your findings, then hand off to the Writer.""",
    tools=[web_search],
    handoffs=[writer],
)

# --- Run the pipeline ---

async def run_pipeline(topic: str):
    print(f"\n🔍 Starting research pipeline for: {topic}\n")
    result = await Runner.run(
        researcher,
        f"Research this topic and produce a written summary: {topic}",
    )
    print("\n✅ Pipeline complete.")
    print(f"\nFinal output:\n{result.final_output}")
    return result

if __name__ == "__main__":
    asyncio.run(run_pipeline("OpenAI's openai-agents-python SDK"))

This creates a chain: Researcher → Writer → Reviewer. Each agent does its job and hands off. The Runner handles the entire execution loop — including managing multiple turns if an agent needs to call tools before handing off.

💡 The OpenAI Cookbook's multi-agent portfolio collaboration example is the best reference for production-style patterns — a coordinator calls data analyst, statistician, and report writer as tools and merges their outputs.

For debugging, enable tracing to see every step:

import agents
agents.enable_verbose_stdout_logging()

The full trace — every LLM call, tool execution, and handoff — is viewable in the OpenAI Traces Dashboard. This is essential for debugging where a pipeline stalls in production.

Handoffs vs. Agent-as-Tool: Which Pattern to Use

This is the core architectural decision in multi-agent systems. The official multi-agent docs define the distinction clearly:

	Handoff	Agent-as-Tool
Control	Specialist takes over	Manager retains control
Conversation	Specialist responds directly	Manager synthesizes output
Best for	Routing workflows	Aggregation workflows
Example	Customer service triage	Report generation

Use handoffs when the conversation is inherently routing — the user interacts with whichever specialist is most relevant, and you want that specialist to own the exchange.

Use agent-as-tool when a manager needs to collect results from multiple specialists and synthesize them. The portfolio collaboration example from OpenAI's cookbook demonstrates this: a coordinator calls a data analyst, statistician, and report writer as tools, then merges their outputs into a final deliverable.

The Dev.to tutorial by Jangwook Kim demonstrates both patterns with a complete content production pipeline — worth reading alongside this tutorial for a different angle on the same concepts.

The developer community has been active on this architectural question. A popular HN thread showed practitioners converging on the same conclusion:

Guardrails That Actually Work in Production

The guardrails system is more sophisticated than it first appears. Two distinct scopes:

Agent-level guardrails run before the agent processes its turn. Good for filtering malicious inputs, PII, or off-topic requests.

Tool-level guardrails run on every tool invocation within an agent's execution. Use these when you need to validate what the agent is actually doing, not just what it received.

from agents import output_guardrail
import re

@output_guardrail
async def no_pii_in_output(ctx, agent, output):
    """Ensure no PII leaks in the agent's response."""
    if re.search(r'\d{3}-\d{2}-\d{4}', str(output)):
        return GuardrailFunctionOutput(
            output_info={"flagged": True, "reason": "SSN pattern detected"},
            tripwire_triggered=True,
        )
    return GuardrailFunctionOutput(
        output_info={"flagged": False},
        tripwire_triggered=False,
    )

Per the guardrails docs: "Blocking execution runs and completes the guardrail before the agent starts. If the guardrail tripwire is triggered, the agent never executes, preventing token consumption and tool execution."

⚠️ Latent Space's analysis found a 60x higher security incident rate for agent deployments compared to standard API calls. Guardrails are necessary but not sufficient — you also need robust authentication, access controls, and sandbox execution for agents that touch the filesystem or execute code. OpenAI's April 2026 SDK update added sandbox support via E2B, Modal, Cloudflare, Daytona, Runloop, Vercel, and Blaxel.

State Management and Sessions

Sessions are the SDK's answer to long-horizon tasks — multi-step workflows where an agent needs to remember context across multiple runs:

from agents import Agent, Runner
from agents.extensions.sessions import InMemorySessionStorage

storage = InMemorySessionStorage()

agent = Agent(
    name="LongRunningAgent",
    instructions="You help users with multi-step tasks. Remember context from previous messages.",
)

# First interaction
result1 = await Runner.run(
    agent,
    "Start a report on market trends in AI agent frameworks.",
    session_id="report-session-001",
    session_storage=storage,
)

# Second interaction — agent remembers the previous exchange
result2 = await Runner.run(
    agent,
    "Now add a section on the OpenAI Agents SDK specifically.",
    session_id="report-session-001",
    session_storage=storage,
)

For production, swap InMemorySessionStorage for the Redis-backed session store:

pip install "openai-agents[redis]"

This persists sessions across server restarts and horizontal scale — essential for production multi-step workflows.

MCP Integration

The SDK supports Model Context Protocol for connecting external tools and data sources. Version 0.0.7+ includes the MCPServerStdio class:

from agents.mcp import MCPServerStdio

mcp_server = MCPServerStdio(
    command="npx",
    args=["-y", "@modelcontextprotocol/server-filesystem", "/tmp/workspace"],
)

agent = Agent(
    name="FileAgent",
    instructions="You help with file operations.",
    mcp_servers=[mcp_server],
)

The HN discussion on OpenAI's MCP support captured the developer community's mixed reaction: top criticism is that "MCP overcomplicates tool calling" versus the counterpoint that MCP enables runtime tool discovery — you can add new tools to an MCP server without redeploying your agent code.

For most projects, function tools are simpler and sufficient. Reach for MCP when you need to reuse an existing MCP server ecosystem or when runtime tool discovery is a genuine requirement.

Production Considerations

Production deployments bring additional complexity that tutorials rarely cover. Community experience on HN offers the honest take:

Observability first. In multi-agent systems, a single user query can trigger multiple LLM calls, tool executions, and handoffs. Tracing captures all of this. Connect to Logfire or export OpenTelemetry spans to your existing stack.

Token accounting. With multi-agent chains, token costs multiply fast. Each handoff means a new context window with the full conversation history. Design your agent instructions to be minimal and your handoff payloads to carry only what the next agent needs.

Parallel execution. For independent subtasks, use asyncio.gather with multiple Runner.run calls rather than sequential handoffs. The definitive guide covers this pattern in depth.

Sandbox for code execution. Any agent that can execute arbitrary code should run inside a sandbox. The April 2026 update made this straightforward — pick your sandbox provider from the supported list and pass it to the agent configuration.

Honest Assessment: OpenAI SDK vs. Anthropic Claude SDK

The Composio three-way comparison puts it well: "These represent two competing visions of agentic AI: OpenAI ships an opinionated, batteries-included SDK; Anthropic ships a model plus an open protocol."

Choose openai-agents-python when:

Your team is already on GPT models and wants minimal switching cost
You want hosted tools (file_search, web_search, code_interpreter) without managing your own infrastructure
You need rapid prototyping — hello world in under 10 lines
Your workflow is routing-oriented (triage → specialist patterns)
Cost matters for longer sessions: OpenAI bills only tokens; Managed Agents adds $0.08/hour runtime fee that adds up for sessions over 10 minutes

Choose Anthropic's Claude SDK when:

You're building multi-model architectures — Claude's SDK is built on MCP, an open standard
You need native computer control — agents can read files, write code, and execute commands without additional configuration
Model quality is your primary variable — Polymarket currently prices Anthropic at 92% for "best AI model end of April"
Vendor lock-in at the protocol layer is a concern (MCP is open; OpenAI's hosted tools are proprietary)

Per AgentPatch's cost comparison: for short sessions under 5 minutes, pricing difference is negligible. For long-horizon tasks running 10–30 minutes, OpenAI runs 20–30% cheaper for the same token count.

The Enhancial framework comparison adds a useful dimension: quick prototyping (OpenAI SDK, 2–3 weeks to production) → production-grade single agent (Claude SDK, 1–2 weeks) → complex stateful systems (LangGraph, 1–3 months). Match the tool to your complexity requirement.

For deeper context on the model-layer tradeoffs, see our Anthropic vs. OpenAI API comparison and our Claude Code Opus 4.7 creator tips for the Claude-native workflow patterns.

For making agents production-durable (surviving crashes and scaling to parallel executions), the Temporal integration is worth examining:

Getting Started

pip install openai-agents
Copy the three-agent pipeline above and run it with your API key
Swap the web_search stub for a real API (Tavily integrates cleanly)
Enable tracing and review the execution trace in the OpenAI dashboard
Add your first input guardrail before exposing to external inputs

The framework is genuinely good. The primitives are small, the documentation is clear, and the handoff pattern makes complex routing workflows dramatically easier than building them from scratch. 22,981 developers found their way here this week — the SDK earned those stars by solving a real problem with clean abstractions. Build something with it.

Originally published at ComputeLeap