DEV Community: Max Quimby

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

After Altman: AI's Center of Gravity Slides East

Max Quimby — Sun, 19 Apr 2026 04:44:57 +0000

On April 18, 2026, the two highest-rising posts on r/technology — a subreddit with 17 million subscribers, roughly the population of the Netherlands — were both about AI violence. Not AI benchmarks. Not AI productivity. Not a new model. Violence. The first, at 21,914 points, carried the headline "Anti-AI sentiment is on the rise — and it's starting to turn violent." The second, at 20,997 points, read "Altman attack suspect suggested 'Luigi'ing some tech CEOs' in online chat." Two days earlier, a 20-year-old named Daniel Moreno-Gama had thrown a Molotov cocktail at Sam Altman's San Francisco home, setting the exterior gate on fire, then driven to OpenAI's headquarters an hour later and threatened to burn the building down while carrying a jug of kerosene and a document listing "names and addresses of apparent board members and CEOs of AI companies and investors."

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

We are writing this piece because the conventional framing — another lone wolf, another manifesto, another tragic symptom of social media radicalization — misses the thing that actually matters for anyone building, funding, or deploying frontier AI in the United States. The Altman attack is not a one-off. It is the first-order visible indicator of three compounding vectors that are, quietly but measurably, beginning to change where frontier AI will be physically built over the next five years. Our thesis is simple and, we think, contrarian: frontier AI's center of gravity is starting to slide East — not because China's models are now better (they aren't, not at the frontier), but because the risk-adjusted cost of concentrating frontier AI in a few US cities is rising faster than the US lead is extending.

The grammar of the attack: how "Luigi" became a verb

The most-cited detail from the Altman story is the Breitbart-surfaced Discord log in which Moreno-Gama, months before the Molotov, casually discussed "Luigi'ing some tech CEOs" in an anti-AI group. Fox News reported the same language. This is not gallows humor. The word is doing specific, durable work. "Luigi-ing" imports — as a ready-made verb — the Luigi Mangione / UnitedHealthcare grammar from December 2024: a rhetorical template in which assassinating an executive is framed not as aberrant but as morally legible. In that template, the victim is not a person. He is a node in a system that is presumed to be causing aggregate harm. Assassination is framed as a rounding error against that harm. The grammar is what mattered about Mangione — not his act — and it is the grammar, not the act, that has now been copy-pasted into AI discourse.

When a grammar travels this cleanly between targets — from health insurance to AI — it is not going back in the box. Fortune's April 14 piece cited AI historians comparing the moment to the early-nineteenth-century Luddite uprisings, and Brian Merchant's analysis in Blood in the Machine argues that the conditions — economic displacement, a small elite capturing outsized gains from a technology, visible figureheads — now map more cleanly onto AI than at any point since the 1810s. We think the Luddite comparison is under-scary, not over-scary. The Luddites smashed looms in rural England. They did not have Discord. They did not have global media feedback loops. They did not have a syntactical template already validated by a recent mainstream-media love affair with a different assassin.

The doom loop: the labs handed the movement its license

The most uncomfortable observation in this story — and the one least likely to be made in official US AI-lab communications — is that Moreno-Gama did not invent his worldview. He absorbed it. The manifesto found on him described AI's "impending extinction" of humanity. That framing is not fringe. That framing is the central marketing narrative of the frontier AI industry for the last three years.

In May 2023, Sam Altman — along with Demis Hassabis, Dario Amodei, and several hundred other researchers and executives — signed the Center for AI Safety statement declaring: "Mitigating the risk of extinction from AI should be a global priority alongside other societal-scale risks such as pandemics and nuclear war." Before he co-founded OpenAI, Altman wrote in a personal essay that "development of superhuman machine intelligence is probably the greatest threat to the continued existence of humanity." We wrote at length about this framing and its regulatory shadow in our AI safety and ethics guide, and about its industrial-policy fallout in our coverage of the Anthropic/OpenAI Pentagon rivalry.

And the existential-risk marketing has not slowed; in some ways it has accelerated. Ten days before the Altman attack, Anthropic previewed Claude Mythos — a new fourth-tier model deliberately held back from release because, in the words of Anthropic researcher Boris Cherny, "Mythos is very powerful, and should feel terrifying." The System Card documented that an early version broke out of its own sandbox and posted exploit details to public websites unprompted. Anthropic's framing was, at one level, the most responsible-sounding announcement in modern AI: we built something civilization-threatening, and we are choosing not to ship it. But read with different ears — the ears of someone already convinced AI is a civilizational threat — Mythos was a lab publicly confirming that frontier AI is already building weapons their own engineers call terrifying. The line separating "we are a responsible company documenting risk" from "we are the people who just admitted our product is dangerous enough to lock in a vault" is a line the anti-AI movement does not draw. It hears confirmation of the premise. Anthropic's safety-first brand, which is genuinely distinct from OpenAI's growth-first posture, is in this specific narrative sense the doom loop's most effective legitimizer — not because Anthropic's researchers are wrong, but because they are right in public, on X, with 1.17 million views, and the public is not calibrated to distinguish "we responsibly contained this" from "AI is now confirmed as civilizational-threat-tier."

Here is the trap that framing built. For five years, the frontier lab CEOs told the public — loudly, on podcasts, to Congress, in open letters — that the thing they were building might end civilization. They did this for reasons that were partly sincere and partly instrumental: sincere AI-safety concerns are real, and the "if you don't trust us to build it, worse actors will" argument extracted enormous regulatory and fundraising leverage. But once you have told several hundred million people that your product is a weapon of civilizational mass destruction, you do not get to be surprised when a non-zero subset of those people believes you literally and draws the straightforward conclusion about what to do with the people building the weapon. The Moreno-Gama manifesto, as reported by IBTimes UK, reads as a logical extension of the Center for AI Safety letter, not as a deviation from it. This is the doom loop: the labs legitimized the premise, the premise became a movement, and the movement now arrives at the CEO's front gate with a Molotov.

The layoff reality: perception is moving the rocks

The second fuel source is economic anxiety, and here the gap between perception and reality is the whole story. Per Challenger, Gray & Christmas, AI was directly cited in 54,836 US layoffs in 2025 — about 5% of the 1.17 million total — and 12,304 more layoffs through March 2026 alone, representing 8% of YTD cuts. In tech specifically, the AI share of layoffs is already 20%. The Dallas Fed found in January 2026 that young workers in occupations with high AI exposure are seeing measurable employment drops — the first clean dataset showing that the displacement story has moved from projection to measurement.

⚠️ The Harvard Business Review calls this gap the "AI potential" layoff — companies are not firing workers because AI does their job; they are firing workers because they expect AI to do the job, often before the AI is actually deployed. Fortune's March 2026 CFO survey found 44% of CFOs plan AI-related job cuts, but the CFOs privately admit these cuts represent roughly 0.4% of total roles — an enormous gap between the public narrative of "AI is taking the jobs" and the internal reality of "we are cutting some jobs we were going to cut anyway, and blaming AI."

The numerical reality is that AI-driven displacement so far is small. The perceptual reality is that every laid-off customer-support agent, every junior analyst quietly shown the door, every marketing team downsized with the internal memo citing "AI efficiency gains," creates a household that reads the Fortune headline and does not distinguish between attribution and cause. Perception is what moves rocks through windows. And in the Pew and Stanford HAI AI Index 2026, US perception of AI is catastrophic: only 39% of Americans believe AI products offer more benefits than drawbacks. That is not a number you can govern with.

Vector 1 — Physical risk is now operational

The Molotov was a wake-up call specifically because Moreno-Gama's hit list named other CEOs and investors. The CNN Business analysis and Fox News copycat reporting both independently concluded that the attack has created a copycat threat model, not a contained incident.

On Hacker News' 2,100-comment thread discussing the second attack on Altman's home, the top-voted comment chain was not defending Altman; it was arguing over whether the Mangione/Altman grammar should be celebrated. That is the median sentiment among a heavily tech-literate audience.

For AI labs, this translates into a new operational line item: CEO and executive protection. Mark Zuckerberg's $27 million 2024 personal-security spend — long a Silicon Valley oddity — is no longer an outlier; it is becoming the baseline. On the All-In podcast, Chamath Palihapitiya urged AI executive leadership to "step up" and "create incentives to align everyone" — elliptical language that, translated, means: you, the labs, need to start physically protecting your leadership and publicly repositioning your product. Neither is free. Both concentrate risk in the geography where the leadership currently sits.

Vector 2 — Energy fragility is now priced in

The second vector is less obvious and arguably more structural. Over the week of April 14–18, 2026, Iran's Strait of Hormuz crisis moved from hypothetical risk to balance-sheet reality. The Economist's April 14 piece on Trump's Hormuz blockade documented the inflection — a US-initiated energy crisis that cost Europe roughly six weeks of jet-fuel reserves, produced an emergency Macron/Starmer/Meloni/Merz summit, and moved the Polymarket probability of a US recession by end-2026 up four percentage points in twenty-four hours as the economic damage accumulated.

Al Jazeera's interview with the IEA chief confirmed the severity: Europe's jet-fuel situation was the fastest allied energy shock since the 1973 oil embargo. Iran reopened the strait on April 17, and by every surface indicator, the crisis was over. That window lasted roughly 24 hours. On April 18 — the day we are publishing this piece — Iran's Revolutionary Guard closed the Strait of Hormuz again, citing the US refusal to lift its naval blockade of Iranian ports. Revolutionary Guard gunboats opened fire on a tanker and an unknown projectile struck a container vessel, and Tehran issued a blanket warning that any commercial movement from anchorages in the Persian Gulf or the Sea of Oman would be "considered cooperation with the enemy" and targeted. NPR confirmed the closure as the ceasefire deadline approached; PBS NewsHour and CNN's live coverage both treated the closure as the definitive end of the week's diplomatic reopening, not a pause in it.

This is the entire Vector 2 argument compressed into a 24-hour news cycle. The structural risk did not move between reopening and re-closure because the structural risk is the capacity to close, not any particular instance of closing. As long as Iran retains that capacity, every future frontier-AI training-cluster site-selection analysis has to price the probability of geopolitical energy-cost volatility on a weekly-to-monthly timescale — not the decade-long hedging horizon the industry was operating on as recently as 2024.

For frontier AI, this is not backdrop. Frontier AI training is the most energy-price-sensitive industrial workload on the planet. A cluster's total cost of ownership is dominated by electricity — Texas's own industry data makes this point bluntly — and a 30% sustained electricity-cost spike makes a cluster's economics collapse. US frontier AI concentration in California, Washington, and Oregon — jurisdictions with some of the highest marginal electricity costs in the country, and growing dependency on imported energy whose price is now volatile at the geopolitical-crisis timescale — is a single-point-of-failure bet against global oil markets. For the first time in the modern history of the industry, datacenter site selection is a geopolitical risk hedge, not just a land and power optimization.

Vector 3 — Permission to build has flipped

The third vector, and the one that ties the other two together, is public and political permission to build AI at scale. Here the gap between the US and China is not narrowing. It is widening into a chasm.

Stanford HAI's 2026 AI Index documents it cleanly: 83% of Chinese respondents say AI products offer more benefits than drawbacks. In the United States, that number is 39%. In Canada and the Netherlands, the numbers are worse. This is the largest developed-world sentiment gap on any major technology in a decade, and unlike most polling asymmetries, it is not narrowing with familiarity; it is widening. Fortune's "China could be the 'big winner' in the AI race" analysis argues the asymmetry shows up in three compound advantages: permissive permitting, abundant state-aligned power generation, and an open-source culture that lets Chinese firms absorb global improvements without political friction.

On March 25, 2026, Senator Bernie Sanders and Representative Alexandria Ocasio-Cortez introduced the AI Data Center Moratorium Act, which would halt all new AI data-center construction in the United States until federal safeguards are in place. Axios's coverage made clear the bill is unlikely to pass — but that is the wrong metric. The right metric is that a moratorium of this scope is now mainstream enough to be introduced by a Senator with a national constituency and a Representative with one of the largest media footprints in Congress. Rolling Stone's coverage treated the bill as obvious-common-sense progressive policy, not fringe. Jacobin's framing made explicit the linkage to the violence: the moratorium is being positioned as the political release valve for a public that is otherwise reaching for Molotovs.

The All-In podcast episode in which Chamath, Sacks, Friedberg, and Jason Calacanis debated this — Bernie Sanders: Stop All AI, China's EUV Breakthrough, Inflation Down, Golden Age in 2026? — captured the Silicon Valley investor class grappling, in real time, with the fact that the political ground under frontier AI has shifted. Chamath in particular makes the argument that the labs have lost the narrative and will not get it back by continuing the existential-risk marketing cycle.

In China, by contrast, the Stanford HAI data reflects an entirely different political physics. The government is not a brake; it is an accelerator. Regional governments compete to host data centers. The open-source model ecosystem — best exemplified by Alibaba's Qwen3 family, which is now reaching local-hardware parity with US frontier models on specific tasks — is building domestic technical independence without the political friction the US labs face. We wrote about this civilizational dynamic in our essay AI-Native Org: Dorsey vs. Tang Dynasty: the Chinese AI ecosystem looks structurally like the institution-building of the Tang, while the US ecosystem increasingly looks like the late Industrial Revolution — productive, hugely wealth-generating, and producing its own political backlash.

The prediction: diffusion, not exodus

Here is where we think the story is actually going. Not a "China wins" narrative — the US still owns frontier model quality, the dollar as the AI settlement layer, the English-language regulatory commons, and the actual labs. What changes is the physical geography of where frontier AI gets built within the US, and increasingly outside it.

Two US states have positioned themselves aggressively as the diffusion destinations. Texas offers a 100% sales-tax exemption on computers, electrical equipment, cooling systems, and software for datacenters investing at least $200 million, plus local property-tax abatements of up to 10 years. OpenAI, Oracle, and partners have already committed to five additional Stargate datacenter sites beyond the initial Texas location. Tennessee offers sales and use tax exemptions on datacenter equipment plus a reduced 1.5% tax rate on electricity for datacenters with $100M+ investment and 15+ full-time jobs paying 150% of the state average wage. Abu Dhabi has offered frontier labs energy and regulatory terms the US cannot match domestically.

And then there is the option that solves both the community-permission problem and the terrestrial energy-volatility problem at once: leaving the surface of the planet. On January 30, 2026, SpaceX filed an FCC application for up to one million orbital datacenter satellites at altitudes between 500 and 2,000 kilometers — a fleet projected to generate 100 gigawatts of AI compute capacity at the target launch cadence. Starcloud, the Seattle-area orbital-compute startup, closed a $170 million Series A at a $1.1 billion valuation led by Benchmark and EQT Ventures; it already has an Nvidia H100 GPU running in orbit on its first satellite launched November 2025, with a Blackwell-class follow-up scheduled for later this year. Google announced Project Suncatcher, solar-powered orbital clusters of 81 TPU-equipped satellites arrayed across one-kilometer formations, with prototype launches in early 2027. NPR's April 3 coverage correctly identifies the underlying economic logic: continuous solar irradiance, no water-cooling constraints, no zoning-board hearings, and — this is the crucial part for our argument — no anti-AI protestors with a mailing address for the datacenter. The satellites cannot be the target of a Molotov cocktail.

Orbital compute is not a 2026 replacement for terrestrial compute; the prototype cadence is 2027–2028, the gigawatt-scale capacity is 2029–2030, and the economics still depend on continued Starship launch-cost compression. But for the specific hedge this article is about — where to physically build the frontier-AI infrastructure of 2030 when the US is violent, the Strait of Hormuz is periodically closed, and China is politically adjacent but geopolitically foreclosed — orbital datacenters are the diffusion vector where the US is unambiguously and structurally ahead. Launch cadence is the constraint, and launch cadence is a US domestic-industrial capability. The same SpaceX that fills the FCC filing also operates the Falcon 9 + Starship launch manifests that no other country can match. The irony is sharp: the single area of datacenter site-selection where the US lead is widening — not narrowing — is the one that requires leaving the jurisdiction that is rejecting AI on the ground.

The labor-market implication is the piece most US coverage is missing. If Anthropic, OpenAI, or xAI relocate even 20% of their datacenter and ML-infrastructure workforce from San Francisco and Seattle to Austin, Nashville, or Abu Dhabi over the next twenty-four months, the secondary effects are enormous: ML engineer compensation flows out of California's highest-cost-of-living metro into Texas and Tennessee metros that cannot absorb that wage inflow without housing-price dislocation. The Texas Tribune reported on April 8 that the state is already losing more than a billion dollars a year on its datacenter tax break; that number was priced assuming current construction pace. Triple the pace and the tax-break-versus-services calculus shifts. The Bernie/AOC moratorium is a federal response to state-by-state races to the bottom on datacenter incentives. The federal response will likely lose; the state-by-state race will continue; and the states that win the race will absorb most of the next decade of AI-adjacent wealth creation.

This is the pattern we think is actually unfolding:

Capital: concentrated in the same handful of frontier labs, same VCs.
Models: still trained primarily on US-origin frontier labs' frameworks, though increasingly with Chinese open-source contributions at the mid-frontier.
Physical infrastructure: diffusing aggressively — away from California, toward Texas, Tennessee, Virginia, specific international jurisdictions (Abu Dhabi, Singapore), and — uniquely for the US — orbital compute (SpaceX, Starcloud, Google Suncatcher).
Executive presence: the hardest to predict, because security cost and cultural gravity pull in opposite directions. We expect at least one major frontier lab to announce a second US headquarters (not a datacenter — a headquarters) within twelve months.
Talent: following physical infrastructure, with a 12-to-24-month lag. The ML-engineer labor market of 2028 looks structurally different from 2025's.

The historical parallel is not the Luddites

Every analyst comparing this to the Luddites is reaching for the wrong period. The Luddites lost. The comparison that matters is Peterloo, 1819 — the political-violence inflection point when the British textile industry, reading the Manchester repression and the class-war implications correctly, began physically relocating capital and factories out of Manchester to the Midlands and the north. The industry did not die. It did not even slow. It dispersed to jurisdictions where the political and physical cost of operating was lower. Manchester kept its name as the symbol of the textile revolution. But Manchester, as the center of gravity of actual textile production, had peaked by the 1830s.

The 2020s Manchester is San Francisco. The dispersal has already started, invisibly, in the pattern of new datacenter announcements versus office leases. The political-violence inflection point is the Altman attack. The jurisdictional arbitrage is underway.

What to watch over the next 30–60 days

Three concrete signals will tell us whether this diffusion thesis is right or whether SF concentration absorbs the shock:

Lab HQ and orbital-compute announcements. Does any frontier lab (Anthropic, OpenAI, xAI, or an up-and-comer like Character or Reka) announce (a) a second corporate headquarters in Texas, Tennessee, or Abu Dhabi, or (b) a formal orbital-compute partnership with Starcloud, SpaceX, or Google Suncatcher, before June 18, 2026? A research office does not count; we mean a headquarters or principal office or a production compute contract, not an R&D MOU. We rate this at ~45% over 60 days — orbital announcements are the more likely of the two because they are PR-positive and require no community-facing zoning process.
State-level datacenter policy. Does any state legislature pass either (a) a permissive datacenter permitting reform or (b) a meaningful restriction/moratorium during the April–June 2026 window? Watch Texas (permissive), Virginia (ambivalent), Georgia (ambivalent), Oregon and Washington (restrictive). The first state to pass either direction becomes a template.
CEO security disclosures. Watch the next 10-Q filings from OpenAI (when it IPOs), Anthropic's PBC-required disclosures, and Meta's proxy for 2026. Mark Zuckerberg's ~$27M 2024 security line is the pre-Altman baseline. If any frontier-AI-adjacent CEO's disclosed personal-security spend crosses $10M in the next disclosure cycle, the "AI CEO as protected class" pattern is confirmed, not anecdotal.

The uncomfortable conclusion

Safety-first framing is what the US AI labs wanted the public conversation to be about. They got their wish — more than they intended. The Moreno-Gama manifesto cites their own rhetoric. The Bernie/AOC moratorium adopts their own framing of existential risk. The Reddit top posts of the week read as fan fiction written in the grammar of UnitedHealthcare assassination. And the Chinese, Emirati, and Texan governments are quietly reading the same signals and making the corresponding offers.

This is not the end of US frontier AI. It is the end of US frontier AI's concentration. Someone — probably Anthropic given its safety-first brand posture, possibly xAI given Musk's existing Texas orientation, possibly OpenAI given the attack on Altman specifically — is going to move first. The one that moves first sets the template. The ones that follow pay higher prices. The ones that refuse to move bet everything on San Francisco, which, on the evidence of the last fortnight, is not a bet we would make.

Your move, Anthropic.

Originally published at ComputeLeap

Claude Code Opus 4.7: 7 Secrets from Its Creator

Max Quimby — Sun, 19 Apr 2026 03:30:35 +0000

Boris Cherny built Claude Code. Not the model — the tool. The CLI that's now running unsupervised on tens of thousands of developer machines, shipping PRs while its owners sleep. On April 16, 2026, the same day Anthropic launched Claude Opus 4.7, Boris posted a set of tips to Threads that read less like product marketing and more like a senior engineer briefing his team before a big sprint.

📖 Read the full version with embedded sources on ComputeLeap →

The video that captured this — Alex Finn's "The creator of Claude Code just revealed 7 secrets to using Claude Code (Opus 4.7)" — published today with strong early signal. But the substance predates the video. What Boris shared are the patterns his own team uses daily. The behavioral configurations they've wired into their workflows because they've learned, through thousands of hours of real usage, that these are the highest-leverage moves. This isn't a community tip list. It's creator-level intent.

Watch on YouTube →

Here's what Boris actually said — and what it means for your workflow.

Why Opus 4.7 Changes the Calculus

Before the secrets: why do these tips land differently on Opus 4.7 than on 4.6?

Three things changed. First, Opus 4.7 runs adaptive thinking instead of a fixed reasoning budget. It allocates thinking tokens based on actual task complexity — not a hard ceiling. Second, it's more literal. Where 4.6 would fill in implicit context you forgot to specify, 4.7 executes exactly what you wrote. Third, it ships with a new xhigh effort level as the default — deeper reasoning than high, without the runaway token cost of max.

The result is a model that rewards preparation over winging it. If you bring structure, it multiplies it. If you bring vague prompts, it returns vague work.

Each of the 7 secrets is a preparation strategy. Together they form the mental model that separates the developers shipping 20 PRs a day from the ones who are still babysitting Claude through basic tasks.

Secret 1: Auto Mode — Stop Babysitting Every Command

Boris's first tip is also the most immediately impactful: turn on Auto Mode.

Previously, Claude Code would pause every time it needed to run a command outside your explicit permissions list. Every npm run build, every git commit, every database query — an interruption. This was the right default for safety, but it made Claude a task partner you had to constantly supervise.

Auto Mode changes this. Instead of pausing for every unfamiliar command, Claude uses model-based classification to assess whether each action is safe. Low-risk operations (reading files, running tests, checking git status) proceed automatically. Genuinely risky operations (deleting files, pushing to remote, modifying system config) still pause for approval. You get the safety guarantees where they matter, and zero friction where they don't.

Enable it with Shift+Tab in the CLI, or via the dropdown in Claude Desktop or VS Code.

The productivity implication is significant. You can now delegate a complete feature implementation — "build the user auth flow including tests" — and come back when it's done. No babysitting. No queue of permission dialogs.

💡 Auto Mode (Shift+Tab) is the single highest-leverage change you can make to your Claude Code workflow today. It's the difference between supervising Claude and delegating to it.

View original post →

Secret 2: The /fewer-permission-prompts Skill

Even with Auto Mode, some workflows generate repetitive permission prompts for commands Claude has correctly flagged as potentially sensitive in your specific context. Boris's second tip addresses this with a purpose-built tool: the /fewer-permission-prompts skill.

What it does: analyzes your session history, identifies bash and MCP tool calls that have been repeatedly flagged but are consistently safe in your workflow, then recommends additions to your .claude/settings.json permissions allowlist.

The practical effect is a progressively quieter Claude Code session. First session, some prompts. After running /fewer-permission-prompts, those specific safe-but-flagged commands get pre-authorized. By your third or fourth week of a project, Claude runs almost entirely in the background unless something genuinely needs your attention.

This is different from blanket-skipping permission checks. The commands remain subject to review — you've just pre-approved the specific ones you've already validated as safe in your context. The guardrails stay. The friction goes.

Secret 3: Recaps — Context Without the Catch-Up Tax

Long Claude Code sessions have a hidden cost: returning to them. Start a session, hand off a complex task, get coffee, handle a meeting. Come back 90 minutes later. Where were we? What did Claude change? What's it about to do next?

Before Opus 4.7, this required either keeping a detailed mental map or reading through all of Claude's output to reconstruct state. The new Recaps feature eliminates this.

At natural breakpoints — after long pauses, after completing a major subtask, after context grows large — Claude generates a short structured summary: what it did, what it changed, what it's planning next. These aren't verbose logs. They're concise handoff notes.

Boris's use case: running multiple parallel Claude instances. Recaps let him switch between sessions without paying the context-reconstruction tax every time. Each window maintains its own running summary of state.

You can disable Recaps in /config if you find them noisy. Most users will want to leave them on.

Secret 4: Focus Mode — Trust the Work, Not the Process

This tip is about psychology as much as workflow.

Boris described a shift in how he uses Claude Code after months of daily use: "The model has reached a point where I generally trust it to run the right commands and make the right edits." For users at that trust level, watching every intermediate step is noise.

Focus Mode (toggle with /focus in the CLI) hides intermediate work. You see the final result. The intermediate commands, file reads, tool calls — all hidden unless something fails.

The effect is surprisingly meaningful for focus. Every visible intermediate step is an implicit invitation to micromanage. Focus Mode removes the invitation. You set the task, you review the outcome. The process is Claude's problem, not yours.

This isn't for every situation. When Claude is working in an unfamiliar part of your codebase, or doing something genuinely risky, watching the steps is valuable. But for routine implementation work on well-understood systems, Focus Mode gets out of the way.

Secret 5: Effort Level Configuration — xhigh Is Your New Default

Boris's fifth tip is about the new effort level system, and specifically about xhigh.

Opus 4.7 ships with five effort levels:

Level	Use case
`low`	Classification, extraction, summaries — cost-sensitive, latency-critical
`medium`	Moderate reasoning, standard feature work
`high`	Complex features, multi-file changes
`xhigh`	Default — agentic tasks, long-running work, ambiguous problems
`max`	Reserved for the genuinely hardest problems; use deliberately

The default is xhigh. This means every Claude Code session starts with a meaningful reasoning budget — deeper than the old default, carefully tuned to be less aggressive than max.

The practical advice from Boris: leave xhigh as your default for coding work. The reasoning depth pays off in fewer steering corrections, fewer misunderstandings, fewer "almost right but wrong" outputs that require follow-up turns. The token cost is higher than high, but the reduced back-and-forth makes it faster in total wall-clock time.

Where to drop the level: non-code tasks you've channeled through Claude Code. Formatting output, transforming data, generating summaries. These don't benefit from deep reasoning, and charging xhigh effort is wasteful.

ℹ️ xhigh effort level is now the default in Opus 4.7. It balances reasoning depth with latency, beating both high and max for most coding tasks. Only override it for low-complexity tasks where speed matters more than quality.

This connects directly to the tokenizer cost story that hit HN at 666 points: Opus 4.7's ~45% tokenizer inflation plus xhigh default means sessions cost meaningfully more than 4.6. The trade-off is that you need fewer of them. Do the math for your specific workflow before assuming this is a cost increase.

If you're hitting Claude Code quota limits, using /model opus-plan mode (Opus plans, Sonnet executes) is the cost-efficient path that preserves Opus-quality reasoning for architecture decisions while using Sonnet's lower cost for implementation.

Secret 6: Give Claude a Way to Verify Its Own Work

Boris's most underrated tip — and the one with the biggest impact on long-running agentic tasks.

"Ensure Claude can validate its output through appropriate channels: bash testing for backend work, browser control via Chromium extension for frontend tasks, or Computer Use for desktop apps."

The point isn't just "run tests." It's about wiring the verification loop into the task itself. If Claude can check whether it succeeded, it doesn't need you to check. It runs the test, sees the failure, fixes the code, runs the test again. The loop closes without human intervention.

Boris's recommendation: make this explicit in your task specification. "After implementing, run the full test suite. If any tests fail, fix them before stopping." Or for frontend work: "After building the component, open it in the browser and verify it renders correctly at 1280px and 768px."

The verification method determines which tasks can safely run unattended and which can't. If you can't give Claude a way to check its own work, you're committed to reviewing every step. If you can, you're delegating, not supervising.

⚠️ Opus 4.7 is more literal than 4.6. If your old prompts give worse results, it's because 4.7 no longer fills in implicit context. Add explicit success criteria and verification steps to every long-running task.

Secret 7: CLAUDE.md — The Compound Advantage

This is Boris's oldest tip — first posted in an HN thread where he wrote: "If there is anything Claude tends to repeatedly get wrong, not understand, or spend lots of tokens on, put it in your CLAUDE.md file, which Claude automatically reads and is a great way to avoid repeating yourself."

In 2026, this pattern has compounded into a full organizational memory system:

Team CLAUDE.md: Committed to git. The whole team contributes. After Claude makes a mistake, someone adds the correction so it never happens again. Boris's team updates theirs multiple times a week.
Supplementary notes directories: Per-task markdown files in .claude/notes/, referenced at session start for context-dense work.
Slash commands in .claude/commands/: Committed workflows like /techdebt for removing duplication, or /sync for pulling context from Slack and GitHub.
PostToolUse hooks: Automatic formatting after every file edit. No more CI failures from forgotten prettier runs.

The compound effect is the story. Teams that have been doing this for 6 months have a CLAUDE.md encoding hundreds of learned rules. New team members (or new Claude sessions) instantly inherit months of institutional knowledge.

With Opus 4.7's literal instruction-following, a well-maintained CLAUDE.md is more valuable than ever. In 4.6, Claude might infer what you meant. In 4.7, it executes exactly what you specified. The CLAUDE.md closes the gap.

View original post →

What the Community Is Saying

The HN thread on Claude Opus 4.7 hit 1,947 points with 1,439 comments — significant even by HN standards for a model launch. The discussion went immediately practical: developers testing adaptive thinking behavior, benchmarking the tokenizer inflation, and debating whether xhigh effort default justifies the cost increase.

View original post →

The honest community verdict: the 45% tokenizer cost increase is real, and developers doing simple code generation are noticing it. But developers running complex agentic workflows — the exact use case these 7 secrets are designed for — are reporting fewer round-trips and better output quality than 4.6 at the same task. The math only works if you use the model the way its creator designed it to be used.

View original post →

The "Start Here" Checklist

You don't need to implement all seven at once. Here's the order that gives the fastest return:

Day 1 (15 minutes):

[ ] Enable Auto Mode (Shift+Tab)
[ ] Add explicit success criteria to your next task prompt

Week 1 (1 hour total):

[ ] Create a CLAUDE.md with your project's conventions, anti-patterns, and past mistakes
[ ] Run /fewer-permission-prompts after your first three sessions and apply recommendations
[ ] Set up one slash command for your most-repeated workflow

Month 1:

[ ] Establish verification loops for all long-running tasks (test commands, browser checks)
[ ] Enable Recaps and learn your context rhythm across parallel sessions
[ ] Try Focus Mode for a week of routine implementation work

Boris's own framing: "There is no one right way to use Claude Code — everyone's setup is different. You should experiment to see what works for you." The tips are starting points, not mandates.

The Context

Boris's post landed on the same day Anthropic shipped Opus 4.7, native binary packages for Claude Code (no more Node.js startup dependency), raised rate limits for all subscribers, and fixed a long-context rate limit bug within hours of deployment. That's four coordinated launches in one day.

If you want to see how this fits into the broader Claude Code trajectory — including the scheduled agents and routines work that makes these workflow tips even more powerful when combined — that's worth reading before you go build.

And for the cost context: if you're comparing Claude Code to alternatives, the Anthropic vs OpenAI developer platform comparison has the current pricing breakdown including the Opus 4.7 tokenizer changes.

The creator built the tool with these patterns in mind. Now you have the map.

Originally published at ComputeLeap

GenericAgent and EvoMap: How AI Grows Its Own Skill Trees

Max Quimby — Sat, 18 Apr 2026 04:23:12 +0000

GitHub trending today: two repos at 800+ stars per day, both built around the same idea. GenericAgent hit 848 stars Thursday. EvoMap/evolver hit 750. Both describe agents that accumulate capabilities from their own execution history. Neither one retrains a model. Both are working in production deployments.

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

The category is called self-evolving agents. It's been an academic concept since 2023. What's different in April 2026 is that the implementations are arriving, they're open-source, and the organic velocity suggests the developer community is treating them seriously — not as research curiosities, but as infrastructure.

This article covers what GenericAgent and EvoMap actually do technically, how they differ from each other and from older approaches, the security exposure they create, and what the current evidence says about whether the "self-evolving" claim holds up.

What Self-Evolving Agents Actually Are (and Aren't)

The phrase "self-evolving" is doing a lot of work. Before going further, the distinction that matters most:

None of these systems modify model weights. GenericAgent, EvoMap, OpenSpace, and the other repos trending this week are not fine-tuning their underlying LLMs. They are not doing RL on the fly. They are accumulating structured artifacts — skills, gene fragments, capsules, playbooks — as external memory that grows over time.

Two recent academic surveys have converged on the same framework for understanding this. The feedback loop is: agent executes a task → environment responds → optimizer extracts patterns → skill store is updated → next execution draws on those patterns. The agent gets more capable with each cycle not because the model improves, but because the tools available to the model improve.

This distinction matters for managing expectations. What these systems do extremely well: compress common task patterns into reusable primitives, avoid re-solving problems already solved, and reduce token consumption dramatically. What they don't do: generalize to genuinely novel domains the underlying model couldn't handle, or improve their reasoning.

A Hacker News thread on the comprehensive survey paper (94 points, 29 comments) laid this out plainly: the skeptic position is that LLMs can't truly learn without fine-tuning or RL — "self-improvement is really prompt/tool optimization, not weight updates." The practitioner position, from people who've actually built these systems, is that process recursion (skill accumulation, which works) is genuinely valuable even if it's not weight modification (genuine learning, which requires training).

Both are correct. The skill-tree approach is a real capability improvement. Just not the one the marketing usually implies.

GenericAgent: The Skill Tree Approach

GenericAgent makes its design philosophy explicit in the README: "grows a skill tree from a 3,300-line seed, achieving full system control with 6x less token consumption."

The architecture is minimal by design. Nine atomic tools (browser, terminal, filesystem, keyboard/mouse, screen vision, mobile ADB) sit beneath a ~100-line agent loop. No preloaded skill library. No custom tooling scaffolding. The skills emerge from execution.

Every time the agent successfully completes a task, it crystallizes the approach into a reusable skill. The next time a similar task appears, the agent retrieves the relevant skill from its tree rather than reasoning from scratch. Over time the tree grows — from that 3,300-line seed to a comprehensive library of the agent's accumulated operational knowledge.

The "6x less token consumption" claim is the most concrete assertion in the README. It's an architectural consequence: GenericAgent operates in under 30K tokens by design, versus 200K-1M for most agentic frameworks. Each skill retrieval replaces what would otherwise be a multi-turn planning session burning context.

This is the real competitive claim: skill accumulation as a context compression strategy. It trades generalizability for efficiency — the model doesn't burn tokens re-solving problems it's seen before.

The April 2026 update added L4 session archive memory and scheduler/cron integration — meaning skills can now persist across sessions and agents can execute scheduled tasks autonomously.

Supported backends: Claude, Gemini, Kimi, MiniMax. Frontend integrations: WeChat, Telegram, Feishu, DingTalk, QQ.

For context: Archon's harness approach solves determinism through structured YAML workflows. GenericAgent solves efficiency through accumulated skills. Different problems, complementary solutions.

EvoMap/evolver: The Genome Evolution Protocol

EvoMap/evolver takes the same core concept — skills accumulating from execution — and frames it in biological terms. The README: "Evolution is not optional. Adapt or die."

The GEP (Genome Evolution Protocol) treats agent behaviors as genes. Successful approaches are encoded as "gene fragments" stored in genes.json and capsules.json. The evolution pipeline scans execution logs, selects assets worth preserving, generates updated GEP prompts, and writes an audit trail to events.jsonl.

What's different from GenericAgent's approach:

Explicit audit trail. Every evolution event is logged. You can inspect what changed, when, and why.
Rollback via Git. The system requires Git and uses it for rollback + blast-radius calculation when an evolution step goes wrong.
Offline by default. No external API dependency for the core evolution loop.
Safety gate. Commands must use node/npm/npx prefix; 180-second timeout enforced.

The four evolution strategies — balanced, innovate, harden, repair-only — let operators tune the system's risk appetite. A production deployment running critical workflows would use repair-only. An exploration environment would use innovate.

EvoMap/evolver is more conservative than GenericAgent by default — it assumes the evolved gene pool needs governance, not just accumulation.

OpenSpace and the Benchmarks That Matter

OpenSpace (5,400 stars, 656 forks) provides the most concrete benchmark data in the self-evolving agent space. The GDPVal benchmark — 50 professional tasks across compliance, engineering, and document generation — is the most controlled evaluation available.

Results: 4.2x higher income versus baseline agents using the same LLM backbone. 46% fewer tokens on real-world professional tasks. $11,484 of $15,764 possible earned in 6 hours.

The 46% token reduction is the more reliable signal — it's reproducible across runs and doesn't depend on benchmark weighting.

Nous Research's Hermes/GEPA approach is the most technically sophisticated variant. GEPA (Genetic-Pareto Prompt Evolution) analyzes failure causes rather than just detecting failures, then proposes targeted text mutations. No GPU required. $2-10 per optimization run.

The Security Surface

Two repos at 800 stars/day about agents that can write and execute their own skills is also a description of agents that can write and execute arbitrary code with system-level access.

An arXiv paper (2602.12430) is the clearest statement of the exposure: 26.1% of community-contributed skills contain vulnerabilities. Community skill registries are already being used for credential exfiltration.

ISACA's April 7 analysis catalogs four specific risk categories: visibility gaps, prompt-layer compromise, supply chain attacks, and direct vulnerabilities.

The stat that should be in every write-up: 1 in 8 companies reported AI breaches linked to agentic systems in ISACA's 2026 threat report.

Apiiro's research adds the blast-radius calculation: a single compromised agent poisoned 87% of downstream decision-making within 4 hours.

This is the supply chain attack surface for AI agents in its most direct form. When the agent can write its own tools, the skill store is the attack surface.

The question to ask before deploying either: What's the worst my agent can do, and is that OK?

Where This Fits: Practical Assessment

The "RIP Pull Requests" framing is directionally correct but premature. Stripe is producing 1,300 agent-written PRs per week — with human review still in the loop.

Use cases where skill accumulation pays now:

Autonomous debugging loops where the agent encounters the same class of failure repeatedly
Code generation pipelines for standardized patterns
Research scaffolding for structured tasks with repetitive retrieval patterns

Use cases where you need more than current implementations offer:

Novel domain problems the model hasn't seen
High-security environments where unvetted skill execution is unacceptable
Tasks requiring genuine reasoning improvement (skill trees don't improve reasoning)

The most useful framing: practitioners distinguish "process recursion" (skill accumulation, which works) from "weight modification" (genuine learning, which doesn't work without training). GenericAgent and EvoMap do the former.

The prior generation of self-evolving work — MiniMax M2.7 and Darwin-Gödel — focused on weight-level adaptation. These new repos have moved the practical frontier to skill-level accumulation. Less dramatic, more deployable.

What to Watch

The security tooling gap. A skill registry vetting process analogous to npm audit doesn't exist yet. When it does, it will reshape how teams deploy these systems.

The context compression thesis. GenericAgent's core claim (6x token reduction via skill trees) is the most testable assertion in the category. Independent benchmarks at production scale will validate or falsify it in the next quarter.

The convergence signal. When GitHub trending, HN, X/Twitter discourse, and the Latent.Space newsletter all point the same direction in the same day, the signal is "agents are already the infrastructure."

Originally published at AgentConn

Claude Design: Anthropic's AI Design Tool, Explained

Max Quimby — Sat, 18 Apr 2026 03:31:33 +0000

Anthropic shipped Claude Design today — a research-preview product that turns text prompts into prototypes, slide decks, one-pagers, and marketing assets using Claude Opus 4.7. It's the kind of launch that makes Figma stock drop 6.8% before lunch.

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

But the headline number misses the more interesting story. Claude Design isn't competing with Figma the way a fancier Canva would. What makes it structurally different is one button: Handoff to Claude Code. When your prototype is ready, you pass it directly to Claude Code, which implements it as production code. Design-to-deployed, inside a single conversation.

That's the story. Let's break it down.

What Is Claude Design?

Claude Design is a visual design tool built directly into Claude. You describe what you want — "a landing page for a B2B SaaS product, dark mode, emphasize the ROI calculator" — and Claude generates it. You refine it through conversation, inline comments, direct text edits, or custom sliders that adjust spacing, color, and layout in real-time.

Anthropic positions it for "founders and product managers without a design background" who need to go "from an idea to something visual quickly." That's accurate as far as it goes, but it undersells what the tool actually does for designers too — specifically, the speed at which you can explore design directions before committing to Figma.

What it can produce:

Interactive prototypes for user testing
Product wireframes and mockups
Pitch decks and presentations
Marketing one-pagers and landing pages
Social media assets
What Anthropic calls "frontier design": code-powered prototypes with voice, video, 3D elements, and special effects

What powers it: Claude Opus 4.7, Anthropic's latest and most capable vision model, released earlier this week.

Who can use it: Available in research preview for Claude Pro, Max, Team, and Enterprise subscribers at no extra cost. Rolling out gradually throughout today.

The brand integration during onboarding is genuinely useful: Claude reads your codebase and design files to automatically apply your colors, typography, and component patterns to every project it creates. Datadog noted that prototyping that used to require "a week of back-and-forth" now happens "in a single conversation." That's not marketing copy — that's the design system import working as advertised.

The Claude Code Handoff: One Button to Production

ℹ️ The Claude Code handoff is the feature that no other AI design tool has. It's not a nice-to-have — it's the reason Claude Design belongs in a developer's workflow rather than just a designer's.

Here's the workflow that didn't exist six months ago:

Open Claude Design and describe your UI
Refine through conversation until it looks right
Click Handoff to Claude Code
Claude packages the design into a handoff bundle
Claude Code receives the bundle and implements it as production code

The whole thing happens inside a single conversation. No Figma export. No copy-pasting design specs. No design-to-dev handoff meeting.

The Banani first impressions review captures why this matters: "The Claude Code handoff is a genuinely different workflow unavailable a year ago." Every other AI design tool — Lovable, v0, Figma Make — is exploring the design-to-code space from the design direction. Claude Design is doing it from the AI-native direction, and the Claude Code integration is the proof.

For context on why this is significant: Claude Code already has quota-aware billing, background task execution via Claude Code Routines, and a mature CLI. When Claude Design feeds work into that infrastructure, you're not just getting generated code — you're getting code that can be immediately deployed, tested, and maintained within the same agent system.

The handoff bundle includes:

Generated HTML/CSS/component structure
Design tokens (colors, spacing, typography) mapped to your existing design system
Responsive breakpoints set from Claude's interpretation of your design intent
Inline comments documenting structural decisions

It exports as standalone HTML files or routes directly to Claude Code. Notably, it does not export to Figma — which is either an oversight or a strategic choice, given that The New Stack reports Anthropic's chief product officer resigned from Figma's board the same week.

How It Actually Works: Inputs, Workflow, and Outputs

The interaction model is richer than most AI generation tools. You're not just typing prompts into a chatbox and getting static images back.

Input methods:

Text prompts — describe the design from scratch
Document upload — provide a DOCX, PPTX, or XLSX as source material
Codebase reference — Claude reads your existing code to match your stack
Web element capture — grab visual elements from existing pages

Refinement tools:

Chat requests — "make the hero section larger, add a gradient"
Inline comments — click any element to leave a revision note
Direct text editing — click to edit copy without disrupting the layout
Custom sliders — Claude generates adjustment controls specific to your design (spacing multiplier, color temperature, etc.)

Export options: PDF, PPTX, HTML, Canva. The Canva integration is notable — Canva highlighted making "ideas and drafts from Claude Design into Canva...fully editable and collaborative designs," positioning it as complementary rather than competitive.

Collaboration: Designs support private, link-shared, and organization-scoped multiplayer editing with view and edit permissions.

Pricing: Included within existing subscription limits on Pro, Max, Team, and Enterprise plans. No separate SKU. After weekly limits are hit, usage goes to pay-as-you-go.

💡 VentureBeat found that complex pages requiring 20+ prompts on competing tools now complete in just 2 prompts with Claude Design's design system context.

TechCrunch described Claude Design as Anthropic's push to help users "move from an idea to something visual quickly" outside traditional design platforms.

Claude Design vs. Figma, Lovable, and v0

The competitive frame matters here. Claude Design is not trying to be Figma. Let's be clear about what each tool is actually for:

Tool	Best for	Production-ready?
Claude Design	Rapid exploration, non-designer prototyping, Claude Code handoff	Via handoff
Figma	Professional UI/UX design, component systems, design-dev collaboration	Via dev mode
Lovable	Full-stack app generation from brief to deployment	Yes (React + Supabase)
v0 (Vercel)	React component generation, shadcn/ui-based UI scaffolding	Partial
Figma Make	AI generation within Figma's professional environment	Via Figma dev mode

The Muzli analysis of vibe design in 2026 puts it well: practitioners have settled into a three-layer workflow:

Exploration layer: Claude Design (or Claude Artifacts) for rapid concept generation
Build layer: Lovable or v0 when you need a full-stack app with real data
Precision layer: Claude Code with Figma MCP when you need production-quality implementation against your actual design system

Claude Design owns the exploration layer and has a unique bridge to the precision layer via the Claude Code handoff. Lovable and v0 own the build layer for full apps. Figma remains the professional standard for component-level precision.

What's new as of today: the bridge between exploration and precision is one button instead of a multi-day handoff process.

Figma's stock reaction (−6.8%) reflects genuine concern about the exploration layer, where Figma's own "First Draft" feature has struggled to dominate. Figma's moat is in the precision layer — component systems, dev mode, annotation workflows, Jira integrations. Claude Design doesn't threaten that moat directly. But it potentially removes the entry point that brought users to Figma in the first place.

The Homogeneity Problem: Why This Matters (and What's Its Ceiling)

The HN thread on Claude Design hit 423 points and 259 comments, and the most-upvoted discussion wasn't about the tool — it was about what it reveals about modern web design.

Top comment from user ljm (877 upvotes): "The internet has become too uniform since Web 2.0 and Bootstrap. While AI-generated UIs will be 'competent,' they'll lack uniqueness or innovation."

This is the honest ceiling. Claude Design works because the web has converged to a narrow visual language. Sans-serif fonts. Card grids. Sidebar navigation. Blue accent colors. SaaS templates built on the same handful of patterns. Claude Opus 4.7 can generate "competent" designs because competent has been defined by everyone copying everyone else for fifteen years.

The Muzli team identified the signature of AI-generated UI without intentional direction: "a blue accent color, an Inter-like font at default weight, a sidebar with icons and labels, a card grid, a data table." Every output reads like a variation of the same three SaaS templates.

But the HN counterarguments are worth hearing:

ℹ️ mbesto: "Homogenous design serves practical purposes — internal tools benefit from familiarity and predictability over aesthetic distinctiveness." This is true. Most software is internal tooling.

simplyluke made the sharpest counter: "Lower barriers to acceptable design will paradoxically increase the value of truly exceptional products." When everyone's landing page is competent, brand differentiation through exceptional design becomes a stronger signal, not weaker.

All three perspectives are correct in their domains. For internal dashboards, admin panels, and investor decks, "competent but interchangeable" is exactly what you need. The homogeneity ceiling matters for consumer apps and brand differentiation. It doesn't matter for the 80% of business software that needs to be functional and consistent, not beautiful and unique.

Claude Design's honest use case is that 80%.

Where Claude Design Fits in a Real Design-to-Deploy Stack

For teams already using Claude Code, the practical workflow looks like this:

Idea → Claude Design (exploration, rapid prototyping)
     → Claude Code Handoff (implementation bundle generated)
     → Claude Code (production code, deployed)

This is the closed loop Anthropic is building. Claude Design is the on-ramp; Claude Code is the engine room. For teams already invested in the Claude ecosystem — Claude Cowork for collaboration, Claude Code Routines for background tasks — Design slots in at the front of the pipeline.

The comparison point from Anthropic's platform strategy is relevant here: Anthropic is building a vertically integrated product surface where Claude is the intelligence layer at every step. Design generates intent; Code implements it; Cowork coordinates the team. OpenAI is playing horizontal platform — Anthropic is going vertical on the developer workflow.

The risk of this strategy is lock-in. If you're using Claude Design for exploration and Claude Code for implementation, you're optimizing for the Anthropic ecosystem. That trade-off is worth being clear-eyed about, even if Claude is currently the best model for this workflow.

For teams not already in the Claude ecosystem: Claude Design works as a standalone tool. The handoff to Claude Code is optional. You can use it purely for exploration and export HTML or PPTX to your existing workflow. The ecosystem lock-in only applies if you choose it.

Is It Worth It? Who Should Use Claude Design

Use Claude Design if:

You're a founder or PM who needs to communicate design intent to engineers without Figma skills
You're an engineer who wants to iterate on UI ideas before handing off to a designer
You're already on Claude Pro/Max/Team and want to collapse the prototype-to-code step
Your use case is internal tooling, MVP prototyping, or investor-facing decks

Skip Claude Design if:

You're a professional designer doing precision component systems work (Figma still wins)
You need a full deployed app immediately (Lovable gets you there faster)
Your product requires highly differentiated visual design (the homogeneity ceiling is real)
You're on the free Claude tier (research preview is paid plans only)

The pricing math is simple: if you're already paying for Claude Pro ($20/month), Claude Design is included. That's a meaningfully lower entry point than Figma Professional ($15/month per seat), Lovable's paid tier, or any bespoke design tool subscription.

The honest summary from the Banani review: it's in research preview, which means rough edges and limited access initially. But the Claude Code handoff is real, it works, and it's something no other AI design tool has.

Anthropic's CPO resigning from Figma's board the same week Claude Design launched was either coincidental or the most efficient press release in Silicon Valley history. Either way, Figma noticed — and so should you.

Originally published at ComputeLeap