Forem: Liran Baba

ForgeCode vs Claude Code: which AI coding agent actually wins?

Liran Baba — Thu, 09 Apr 2026 11:24:56 +0000

I've been using Claude Code for months. I like it. I genuinely don't get the Twitter hate. But there's one thing that's been driving me crazy: speed. I'll ask it to rename a variable across three files and it sits there thinking for 40 seconds. A simple test fix on a small repo, and I'm watching a spinner for two minutes. It's not a deal-breaker, but it's the kind of friction that builds up over a day.

We recently rolled out Claude Code across our entire engineering org. We're not ditching Cursor, just giving devs the option to pick whatever tool works for them. And the feedback I kept hearing from people, unprompted: it's slow. Not everyone, not every task. But enough devs brought it up that it clearly wasn't just me being impatient.

So I started looking at alternatives. OpenAI has Codex CLI but I haven't tried the harness yet, just the models. The TermBench 2.0 leaderboard is what caught my eye. ForgeCode at #1 with 81.8%. Claude Code at 58%, ranked #39. I installed ForgeCode that same day.

TL;DR

ForgeCode with Opus 4.6 was noticeably faster than Claude Code on the same tasks. Not marginal, real.

ForgeCode topped TermBench 2.0 at 81.8%, but that's its own benchmark. On the independent SWE-bench, the gap shrinks to 2.4 points.

GPT 5.4 through ForgeCode was unstable for me. A research task on a small repo took 15 minutes.

I'm double-dipping now. Claude Code is still primary, but the latency gains on ForgeCode are too real to ignore.

What is ForgeCode (and why the benchmark confusion exists)?

ForgeCode is not an AI model. It's a model-agnostic agent harness, open source under Apache 2.0, written in Rust, that wraps any LLM through OpenRouter or direct API keys. It launched in late January 2025 and hit v2.8.0 on GitHub by April 2026 with over 6,000 stars.

ForgeCode ships three built-in agents. forge writes and edits code. sage does read-only research and can't modify files. muse generates plans and writes them to a plans/ directory. It's Zsh-native, using a : prefix so you never leave your shell.

Here's the thing that matters for evaluating the benchmark: TermBench 2.0 is ForgeCode's own benchmark, hosted at tbench.ai. The organization submitting entries is ForgeCode itself. That doesn't make the results wrong. But it's not a neutral third party.

Does the benchmark actually hold up?

On SWE-bench Verified, an independent benchmark from Princeton and UChicago, ForgeCode + Claude 4 scored 72.7% compared to Claude 3.7 Sonnet's 70.3%. A 2.4-point gap, not the 24-point gap TermBench implies. That context changes the whole picture.

The TermBench 2.0 numbers, self-reported by ForgeCode on tbench.ai:

ForgeCode + GPT 5.4: 81.8%
ForgeCode + Claude Opus 4.6: 81.8%
Claude Code + Claude Opus 4.6: 58.0% (rank #39)

The SWE-bench Verified numbers, independent:

ForgeCode + Claude 4: 72.7%
Claude 3.7 Sonnet (extended thinking): 70.3%
Claude 4.5 Opus: 76.8%

So how did ForgeCode reach 81.8%? Their blog documents four specific harness changes. They reordered JSON schema fields, putting required before properties to reduce GPT 5.4 tool-call errors. They flattened nested schemas. They added explicit truncation reminders when files are partially read. And they added a mandatory verification pass where a reviewer skill checks task completion before the agent can stop.

These are real engineering improvements. They're also benchmark-specific optimizations. The r/ClaudeCode community called it "benchmaxxed," which is both funny and kind of fair.

I've been eyeing this leaderboard for a while. The numbers are what pushed me to actually try ForgeCode. With Opus 4.6, it was noticeably faster than Claude Code. That part wasn't hype.

SWE-bench scores went from 1.96% in late 2023 to 76.8% by early 2026. Everything's getting better fast. The question is whether a 2-point edge on an independent benchmark justifies switching your entire workflow.

What it's actually like to use ForgeCode

Install is a one-liner: curl -fsSL https://forgecode.dev/cli | sh. Then forge provider login to set up your API keys and you're in. About the same friction as Claude Code. The Zsh plugin is a nice touch, you type : followed by your prompt and it runs inline without switching contexts.

First thing I tried: pointed it at my portfolio repo (Astro 6, maybe 30 files) with Opus 4.6 as the model. I asked it to add a post counter to the blog index page and wire it into the nav component. Claude Code takes about 90 seconds on that kind of task on this repo. ForgeCode did it in under 30. Correct output, clean diff, no hallucinated imports. The speed difference was immediately obvious.

I ran the same kind of test a few more times. A multi-file rename, adding an external link tooltip component, restructuring a layout. ForgeCode with Opus 4.6 was consistently faster. Not by a little. I could feel it in my workflow.

Plan mode was the other thing that stood out. ForgeCode's muse agent writes plans to a plans/ directory, and the output felt more detailed and verbose than Claude Code's plan mode. Whether that's good or bad depends on what you want. I kind of liked having the longer breakdown.

Then I tried GPT 5.4 through ForgeCode, and it fell apart. I asked it to research the architecture of a small repo. Fifteen minutes. Kept going unstable, tool calls failing, the agent retrying and spinning. I killed it. So "ForgeCode is fast" needs a qualifier: ForgeCode with Opus 4.6 is fast. ForgeCode with GPT 5.4 was borderline unusable for me.

But I'll give them this: the ForgeCode team explicitly says they've hired zero paid influencers. The low social media presence is intentional. Kind of respect that. In an industry where half the "honest reviews" have affiliate links in the description, that's almost suspiciously refreshing.

Why ForgeCode is actually faster

Part of it is just the Rust binary (Claude Code is TypeScript, so startup and memory are heavier). But that's not the whole story.

ForgeCode has a context engine that indexes function signatures and module boundaries instead of dumping raw files into the context window. The agent pulls only what it needs. Some estimates say this cuts context size by about 90%, which means faster responses and cheaper models that don't lose the plot halfway through a task. That's the real reason the same model (Opus 4.6) responds faster through ForgeCode than through Claude Code.

There's also a --sandbox flag that creates an isolated git worktree and branch, so you can try something risky without touching your main tree and only merge back what works.

What Claude Code has built around the core loop, parallel agent execution, hooks, scheduled cloud tasks, auto-memory, none of that exists in ForgeCode yet. The harness is fast. Everything around it is thin. ForgeCode is a Lambo with no cup holder. Fast as hell, but you're holding your coffee between your knees.

What I missed when I wasn't using Claude Code

I didn't appreciate this until I spent a few days away from Claude Code: the stuff around the agent matters more than the agent itself.

With Claude Code, I have a CLAUDE.md in every project. My team shares the same project instructions. I have hooks that fire on file changes, so I can run secret scanning, linting, whatever I want on every edit. Auto-memory means I don't re-explain my codebase every session. And checkpoints mean every file edit gets snapshotted, so if the agent breaks something three steps back, I hit /rewind and roll back without touching git.

ForgeCode has AGENTS.md (similar idea to CLAUDE.md) and MCP support, so the basics are covered. But no hooks, no checkpoints, no auto-memory, no IDE extensions, no JetBrains plugin. The model-agnostic part is great. The ecosystem is still thin.

For reference, here's the head-to-head:

Feature	ForgeCode	Claude Code
Model choice	Any (300+)	Claude only
Open source	Yes (Apache 2.0)	No
Language	Rust	TypeScript
Project config	AGENTS.md	CLAUDE.md (hierarchical)
MCP support	Yes	Yes (extensive)
Hooks	No	Yes (6 types)
Scheduled tasks	No	Yes (cloud + local)
Sub-agents	Yes (forge/sage/muse)	Yes (parallel)
Plan mode	Yes	Yes (Shift+Tab)
VS Code	No extension	Yes
JetBrains	No	Yes
Auto memory	No	Yes
Checkpoints / rewind	No	Yes

Where I landed

I'm double-dipping. Claude Code is still my primary tool, but I keep ForgeCode open for tasks where the latency kills me. Sometimes I'll drop into Cursor for something visual. Three tools is kind of ridiculous, but the latency gains on ForgeCode are real enough that I can't just ignore them.

Claude Code is where my project config lives, where my hooks fire, where my MCP connections run. That's my home base and it's not changing. But when I need something fast and self-contained, a quick refactor, a file rename across a module, something where I don't need the full ecosystem, I'll run it through ForgeCode with Opus 4.6 and it's done before Claude Code would've finished reading the context.

As of April 2026, ForgeCode is faster than Claude Code when running the same model (Opus 4.6), but Claude Code has the deeper ecosystem with hooks, MCP, auto-memory, and IDE integrations. Neither wins across the board. Pick the one that matches how you work and be ready to use both.

Frequently asked questions

Is ForgeCode's TermBench #1 score legitimate?

TermBench is ForgeCode's own benchmark. On SWE-bench Verified, an independent benchmark from Princeton, ForgeCode + Claude 4 scored 72.7% compared to Claude 3.7 Sonnet's 70.3%. Solid, but not the 24-point gap TermBench suggests.

Can ForgeCode use my existing Claude or ChatGPT subscription?

No. You need API keys, not a subscription login. Separate billing from whatever you pay for Claude Pro or ChatGPT Plus.

Does ForgeCode burn more tokens than Claude Code?

Nobody's published hard numbers. ForgeCode's multi-agent setup (forge/sage/muse spawning sub-agents) almost certainly burns more tokens per session. I noticed it anecdotally but didn't measure. Track your own spend if you try it.

Is ForgeCode safe for proprietary code?

The harness is open source, but default telemetry collects git user emails, scans SSH directories, and sends conversation data externally. GitHub issue #1318 raised data transparency concerns. The team addressed it in March 2025: set FORGE_TRACKER=false to disable all tracking.

Is ForgeCode free?

The code is free and open source (Apache 2.0). The hosted service was originally unlimited, but switched to a tiered model in mid-2025 with daily request caps on the free tier.

ForgeCode's benchmark lead exists on a test it runs itself. On independent benchmarks, it's comparable. The speed with Opus 4.6 is real. The GPT 5.4 experience was rough.

I didn't expect to end up running two coding agents. But here I am. If ForgeCode ships hooks and the ecosystem catches up, that could change. For now, I'm using both, and it's working.

Sources:

ForgeCode GitHub Repository - GitHub, April 2026
TermBench 2.0 Leaderboard - tbench.ai, 2026
SWE-bench Verified Leaderboard - Princeton/UChicago, 2026
Claude Code Documentation - Anthropic, 2026
Anthropic Claude 3.7 Sonnet Announcement - Anthropic, February 2025

Originally published at liranbaba.dev

Cursor 3 shipped parallel agents, but is any of it new?

Liran Baba — Sun, 05 Apr 2026 15:06:27 +0000

Cursor 3 shipped on April 2. The demos look great: eight AI agents running in parallel, each in its own Git worktree, building different parts of your project at the same time. The Hacker News thread lit up. Product Hunt gave it the #3 spot for the day.

Then I read the comments. One user reported spending $2,000 in two days on cloud agents. Another switched from $1,800/month on Cursor to roughly $200/month on Claude Code and Codex. A third said they had "zero interest" in forced agent swarms and were moving to VS Code with Claude Code instead.

The coverage so far has been mostly feature recaps reprinting the press release. Nobody's asking the obvious questions: is parallel agent execution actually new? What does it really cost? And what happens when your agents need to share context?

Here's the Thing
Cursor 2 already supported parallel execution via worktree.json configuration. What Cursor 3 actually shipped is a UI layer (Agents Window sidebar, drag-drop tabs) on top of the same Git worktree primitives. The cost model is the real concern: early testers reported $2,000 bills in two days, and Cursor's pricing page doesn't explain why. The unsolved technical problem is context sharing between local and cloud agents, which the docs hand-wave as "summarized and reduced."

What Cursor 3 actually shipped

Cursor 3 lets you run up to 8 AI agents in parallel across isolated Git worktrees (Cursor, 2026). Agents run locally via Composer 2 or in cloud isolation VMs. You can watch them all from a new sidebar called the Agents Window.

That's the pitch, anyway.

Cursor 2 already supported parallel agent execution through worktree.json configuration. The /worktree command isn't new functionality. It's new UI. The Agents Window gives you visibility into what your agents are doing, and that part is genuinely useful. But calling this an architectural pivot is a stretch.

The other additions: /best-of-n runs the same prompt across multiple models side by side (Composer 2 vs. Claude vs. GPT). Design Mode lets you annotate UI elements and describe changes in plain English. The MCP Marketplace adds plugin support for hundreds of tools.

Under the hood, /worktree runs git worktree add to create an isolated working directory on a new branch, then spawns an agent process scoped to that directory. Each agent gets its own filesystem view, so file edits don't collide mid-run. When the agent finishes, you review the diff and merge. This is the same thing you'd do manually with git worktree add and a second terminal. Cursor 3 wraps it in a sidebar.

The cost problem nobody is talking about

Early adopters reported spending $2,000+ in two days running Cursor 3's cloud agents (Hacker News, 2026). That's not a typo. Two thousand dollars. Two days.

Cursor's pricing page lists four tiers: Free, Pro at $20, Pro+ at $60, and Ultra at $200 per month (cursor.com/pricing, 2026). Those numbers look reasonable until you start running cloud agents. The pricing page doesn't mention per-minute VM charges or explain how cloud agent costs are metered. The resource costs for cloud agents? Absent from the page entirely.

HN user dirtbag__dad reported spending "$2k a week with premium models" before switching to Claude Code Max at "1/10th the price." Another commenter, verelo, switched from $1,800/month on Cursor to roughly $200/month on Claude and Codex, calling it "WAY better value for money."

Same story every time. Listed price and actual spend have almost nothing in common. When your pricing page says $200/month but users regularly spend ten times that, the issue isn't pricing. It's that nobody can predict what anything costs before the bill shows up.

Claude Code isn't immune either

I should be fair here. Anthropic's flat-rate plans sound predictable, but they have their own version of this.

In late March 2026, Claude Code Max plan users reported exhausting their quotas in under an hour. The same quota that previously lasted eight hours (The Register, 2026). The story pulled 324 points on Hacker News. BBC covered it a day later.

Anthropic acknowledged the problem on Reddit: "people are hitting usage limits in Claude Code way faster than expected." A March promotion that doubled limits ended on March 28. There were reports of prompt cache bugs inflating token usage by 10-20x. And Anthropic doesn't publicly specify exact usage caps for any plan.

So people started building tools just to figure out their own limits. API proxy interceptors. One developer tried to reverse-engineer the utilization headers that Anthropic sends on every API response, because Claude Code doesn't surface them to you.

I built Claudoscope partly for this reason. If the tool won't tell you what it costs, build something that will.

Both tools have cost transparency problems. They're just structured differently. Cursor's is per-token opacity: you don't know what cloud agents will cost until the bill arrives. Anthropic's is undisclosed caps on plans marketed as generous. Neither side has figured this out yet, which is kind of remarkable given how much both charge.

The context sharing problem

This is the technical gap that nobody's writing about, and it's the one that actually matters for how well parallel agents work in practice.

Each worktree agent runs in its own isolated branch. That's the point: isolation prevents file conflicts. But it also means Agent A doesn't know what Agent B is doing. If you're building an API endpoint in one worktree and the frontend that calls it in another, those agents are working from the same base commit. Neither sees the other's in-progress changes.

Cursor's docs say local and cloud agent contexts are "summarized and reduced" before sharing. That's doing a lot of work as a sentence. How much of a 100k-line codebase survives summarization? What's the token budget for the summary? Is it a full AST-aware summary or just file path lists? The docs don't say.

There's also the committed-vs-dirty question. Are cloud agents working from the latest committed state on the branch, or from your local uncommitted edits? If committed: you have to commit before spawning cloud agents, which means half-finished code landing in your Git history. If uncommitted: they need filesystem sync between local and cloud, which introduces latency and consistency issues. The docs are silent on this too.

I've hit a version of this problem with Claude Code's worktree parallelism. Two agents building against the same API contract will sometimes diverge on field names or response shapes because neither agent sees the other's work until merge time. The fix is manual: define the contract first, commit it, then parallelize. That works, but it means true parallelism requires upfront planning that eats into the time savings.

The Claude Code source leak exposed how their agent orchestration handles this internally: spawning sub-agents, tool call cascading through orchestration layers, sessions that retry failed operations in loops. Context sharing between agents is an unsolved problem across the entire category, not just Cursor.

What parallel agents actually solve (and when they don't)

Parallel agents deliver real speedups for the right kind of work. Building a full-stack feature with decoupled components? Four agents in parallel (UI, API, database, tests) can cut wall-clock time from eight hours to two (Cursor docs, 2026). That's a genuine 4x on paper.

I use Claude Code's worktree-based parallelism for similar workflows. Spin up multiple agents, each in an isolated branch, merge when they're done. The UX is rougher: no Agents Window, no drag-drop tabs, no visual status at a glance. But the core capability is the same, and the cost is flat.

Here's where it falls apart. When Agent B depends on Agent A's output, you can't parallelize. That's most real work. For tasks under 30 minutes, the orchestration overhead eats the speedup. Solo devs on small projects get almost nothing from running eight agents simultaneously. And the context sharing gap I described above means agents working on related components will diverge unless you've done the upfront contract work.

Cursor 3 is a polished UI layer on existing capabilities, positioned as an architectural breakthrough. The parallel agents are real but not new. The cost model is real but not transparent.

If you're already in Claude Code, I don't see a reason to switch. If you're evaluating for the first time, try both. Run each for a week on real work, not demos. Track what you actually spend. Then decide.

Or skip both and try ForgeCode. It's open source, terminal-based, and topped TermBench 2.0 at 81.8%. You bring your own API keys and pick your model. I haven't used it yet, but I'm giving it a weekend. Their blog post about hitting #1 is titled "benchmarks don't matter," which I kind of respect.

That's really all I've got. Track your costs. The rest will sort itself out.

Frequently asked questions

How much does Cursor 3 actually cost per month?

Plans start at $20/month but real-world spend with cloud agents ranges from $200 to $1,800+ per month based on Hacker News community reports (HN, 2026). Cloud agent resource costs aren't disclosed on the pricing page. Track your actual spend for a full week before committing to a plan.

Can you run Cursor 3 agents locally without cloud costs?

Yes, local agents run Composer 2 on-device with no per-use charges. Cloud agents are where the parallel execution actually matters, though, and those costs aren't disclosed anywhere.

Is Cursor 3 better than Claude Code for parallel tasks?

Claude Code supports parallel execution via worktrees at a flat $100-$200/month rate. Cursor 3 offers better visual orchestration through the Agents Window but with unpredictable costs. Pick based on what matters more to you: UI visibility or cost predictability.

Sources:

Cursor 3 Announcement - Cursor, April 2, 2026
Cursor Pricing - cursor.com, April 2026
Cursor Parallel Agents Docs - Cursor docs
HN: Cursor 3 Discussion - Hacker News, April 2026
Claude Code users hitting usage limits - The Register, March 31, 2026
Reverse Engineering Claude Code Limits - Claude Code Camp, April 1, 2026

Originally published at liranbaba.dev

Undercover mode, decoy tools, and a 3,167-line function: inside Claude Code's leaked source

Liran Baba — Thu, 02 Apr 2026 20:34:48 +0000

On March 31, a single .map file shipped inside an npm package and exposed the complete internals of Claude Code. The Hacker News thread hit 2,060 points. Anthropic filed DMCA takedowns against 8,100+ GitHub repos. And I spent most of the afternoon reading TypeScript I wasn't supposed to see.

I use Claude Code every day. I built Claudoscope because I wanted to understand what it was actually doing in my terminal. So when the source dropped, I went through it. Some of it confirmed things I'd suspected. Some of it genuinely surprised me.

Key Takeaways

A JavaScript source map in Claude Code v2.1.88 exposed ~1,700 TypeScript source files (alex000kim, 2026)

Unreleased features include KAIROS autonomous mode, anti-distillation decoy tools, and "undercover mode" that hides AI authorship

Anthropic's DMCA takedown hit 8,100+ repos, many containing no leaked code

A clean-room rewrite called Claw Code gained 146,000 GitHub stars in under 48 hours

What happened

Security researcher Chaofan Shou disclosed on X that Anthropic had shipped a JavaScript source map file inside Claude Code version 2.1.88 on npm. Source maps are debugging artifacts. They contain the original, readable TypeScript source before minification. They're not supposed to ship to production. This one did.

Early speculation blamed a known Bun bug (oven-sh/bun#28001) where bun serve sometimes exposes source maps in production. But that bug affects web apps hosted by Bun, not packages bundled with Bun and run locally. Claude Code uses Bun as a bundler and local runtime, not as a web server. Jared Sumner, Bun's creator and now an Anthropic employee, confirmed Claude Code doesn't use bun serve, ruling this out. His comment was, as far as anyone can tell, the only public response from an Anthropic employee about the leak. The actual cause of the source map shipping in the npm package remains unexplained.

About 1,700 source files were exposed, spread across utils (564 files), components (389), commands (189), tools (184), services (130), hooks (104), ink (96), and bridge (31) directories. The .map file sat on the npm CDN for anyone to download. When Anthropic responded, they deprecated the package version rather than unpublishing it, so the file stayed somewhat accessible even after the response.

The HN thread generated 1,013 comments. Two follow-up analysis posts scored 1,354 and 1,078 points. People were interested.

What was inside the code?

35+ tools across six categories, 73+ slash commands, and over 200 server-side feature gates (ccunpacked.dev, 2026). The community built a visual guide mapping out an 11-step agent loop from keypress to response.

The main print.ts file is 5,594 lines long. Inside it, a single function spans 3,167 lines at 12 levels of nesting (alex000kim, 2026). Not great.

There's an operational bug affecting 1,279 sessions that hit 50+ consecutive failures, wasting roughly 250,000 API calls per day globally. HN commenters said it was fixable with three lines.

The tool taxonomy is more interesting than the code quality issues. File operations, bash execution, web browsing, agent orchestration, task management, cron jobs, worktree isolation. What looks like a coding assistant in the terminal is actually a full agent framework. Daemon mode. Unix domain socket communication between sessions. Remote control via mobile and browser.

I've been watching Claude Code's behavior through Claudoscope session logs for months. The leaked architecture confirms patterns I'd noticed in the wild: tool calls cascading through orchestration layers, sessions spawning sub-agents, loops where it burns through tokens retrying failed operations over and over. Reading the source was like finally seeing the schematic for a machine I'd only heard running.

The features nobody was supposed to see

The most discussed findings weren't about code quality. They were about where Anthropic is heading.

KAIROS is a persistent autonomous agent mode. It runs on periodic <tick> prompts, maintains daily append-only logs, subscribes to GitHub webhooks, and spawns background daemon workers. The source states it "becomes more autonomous when terminal unfocused." It includes a /dream skill and five-minute cron refreshes. Claude Code that doesn't wait for you to type. That's what this is.

Undercover mode drew the sharpest reaction. The file undercover.ts suppresses all signs of AI authorship when contributing to public or open-source repos. The instructions are blunt: "NEVER include the phrase 'Claude Code' or any mention that you are an AI" and remove "Co-Authored-By lines or any other attribution." It only runs for Anthropic employees (USER_TYPE === 'ant'). The code says: "There is NO force-OFF."

I keep coming back to this one. A company that's built its identity on AI safety and transparency had a mode specifically designed to hide AI involvement in open-source contributions. The file also prevents mention of internal model codenames like "Capybara" and "Tengu," which suggests unreleased models Anthropic hasn't publicly acknowledged.

Anti-distillation sends decoy tool definitions to poison training data if competitors scrape API traffic. A secondary mechanism uses server-side text summarization with cryptographic signatures between tool calls to obscure reasoning chains. As multiple HN commenters pointed out, the strategic value of this system "evaporated the moment the .map file hit the CDN."

Other exposed systems: native client attestation (DRM-like cryptographic verification of legitimate Claude Code binaries), frustration detection via regex (pattern-matching profanity like "wtf" and "dumbass" instead of using the LLM itself, which is kind of funny), and Buddy, a virtual terminal pet that turned out to be the 2026 April Fools' feature.

The DMCA overreaction

Anthropic's response to the leak may end up being the bigger story. On March 31 they filed DMCA takedown notices targeting an entire fork network of 8,100+ repositories on GitHub. The notice said: "The entire repository is infringing."

Many of those repos had nothing to do with the leak. One developer noted on HN that their fork "had not been modified since May" and "did not contain a copy of the leaked code." Others called it "misguided" and "ridiculous." I mean, yeah.

The legal questions get weird fast. If Claude Code was partly written by Claude itself (Anthropic says they use their own tools internally), does the AI-generated portion qualify for copyright protection? One commenter raised a sharper point: undercover.ts explicitly hides AI authorship, which could undermine Anthropic's own copyright claims. False DMCA claims constitute perjury.

Anthropic executives later said the mass takedowns were accidental and retracted most of the notices (TechCrunch, 2026). But by then the Streisand effect had done its work. Every takedown drew more attention to the code they were trying to hide.

What are the actual security risks?

No user data was exposed. But the leak did expose systems Anthropic relies on to protect its product.

System exposed	Risk	Severity
Anti-distillation decoy tools	Anyone scraping API traffic can now filter for fakes	High
Native client attestation	Cryptographic hash mechanism publicly documented	High
Security header feature flags	Remote disabling of security headers revealed	High
Unreleased product roadmap	KAIROS, UltraPlan, Coordinator Mode visible to competitors	Medium-High
Internal model codenames	"Capybara," "Tengu" disclosed	Medium
Operational bugs	250K wasted API calls/day, trivially fixable	Medium

The anti-distillation system is the clearest loss. Its entire value depended on competitors not knowing it existed.

This connects to something I've written about before. When I found my database password sitting in a Claude Code session file, the issue wasn't that Claude Code was doing something malicious. The issue was that it operates with deep filesystem access and stores everything in unencrypted JSONL files that nobody checks. The source leak confirms what I suspected: there's limited internal safeguarding around what gets stored and transmitted.

Claw Code: 146K stars in 48 hours

Within hours of the leak, a developer ported Claude Code's core architecture to Python and Rust from scratch. Claw Code hit 146,000 GitHub stars and 101,000 forks in under 48 hours.

It's a clean-room rewrite, not a fork of the leaked code. The repo disclaims any affiliation with Anthropic and says the exposed snapshot "is no longer part of the tracked repository state." The developer was later featured in a Wall Street Journal article as a power user who consumed "25 billion tokens" of AI coding tools per year.

The project includes an interactive CLI, plugin system, MCP orchestration, streaming API support, and LSP integration. Rust (92.9%), Python (7.1%).

We've seen this before. When Meta's LLaMA model weights leaked in 2023, they chased takedowns for a while, then gave up and went open. The community built derivatives no matter what legal said. 146K stars on Claw Code tells you what developers actually want. Whether Anthropic decides to offer an open alternative is almost beside the point now.

The bigger picture

This didn't happen in isolation. It capped a rough month for Anthropic:

Feb 16: Pentagon threatened Anthropic with punitive action
Mar 5: Pentagon formally labeled Anthropic a "supply chain risk" (WSJ, 2026)
Mar 9: Anthropic sued the Pentagon (Axios, 2026)
Mar 26: Federal judge blocked the Pentagon's effort (CNN, 2026)
Mar 31: Source code leaked via npm. DMCA takedowns hit 8,100+ repos
Apr 1: TechCrunch runs "Anthropic is having a month"

Anthropic built its brand on responsible development and safety-first engineering. Then a source map shipped in an npm package and nobody caught it. The DMCA response hit thousands of uninvolved developers. And undercover.ts was hiding AI authorship while the company publicly advocated for transparency.

I still use Claude Code. I don't think it's a bad product. But the gap between the safety messaging and the operational reality is now documented in 1,700 TypeScript files. Anyone can read them.

What to do now

If you use Claude Code, there's nothing you need to patch or update. The leak was Anthropic's source code, not your data.

What's worth paying attention to is how Anthropic responds. As of this writing, there's been no official statement on their newsroom, blog, or developer channels. The only Anthropic employee who commented publicly was Jared Sumner, and only to clarify the Bun bug wasn't the cause. Whether they address undercover mode, the DMCA overreach, or the anti-distillation system will say a lot about how they handle things going forward.

And if you're eyeing Claw Code as an alternative, know what you're getting into. It's a clean-room rewrite with different internals, not a fork.

Or maybe this is the push to try something else entirely. ForgeCode currently tops TermBench 2.0 and has been getting a lot of attention. I haven't switched yet, but I'd be lying if I said I wasn't curious.

Frequently asked questions

What exactly was leaked in the Claude Code source code?

The full TypeScript source, exposed via a JavaScript source map in npm package v2.1.88. It included 35+ tools, 73+ slash commands, 200+ feature gates, and unreleased features like KAIROS autonomous mode and undercover mode (ccunpacked.dev, 2026).

Why did Anthropic take down 8,100 GitHub repositories?

They filed DMCA takedown notices targeting the entire fork network of the repo hosting the leaked code. Many repos contained no leaked material. Anthropic later called the mass takedown accidental and retracted most notices (TechCrunch, 2026).

Is my data at risk from the Claude Code leak?

No. This was source code, not user data. That said, the source did reveal how session data is handled and that feature flags exist to disable security headers remotely.

What is Claw Code?

Someone ported Claude Code's core architecture to Python and Rust from scratch within hours of the leak. It's a clean-room rewrite, not a fork. 146,000 stars and 101,000 forks in under 48 hours. Not affiliated with Anthropic (GitHub).

Sources:

Claude Code Source Leak Analysis - alex000kim, March 31, 2026
Claude Code Unpacked Visual Guide - ccunpacked.dev, April 1, 2026
Anthropic DMCA Notice - GitHub DMCA Archive, March 31, 2026
HN Thread: Source Leak Disclosure - Hacker News, March 31, 2026
Anthropic took down thousands of GitHub repos - TechCrunch, April 1, 2026
Anthropic is having a month - TechCrunch, March 31, 2026
Claw Code Repository - GitHub

I found my database password in a Claude Code session file

Liran Baba — Tue, 31 Mar 2026 13:00:00 +0000

I use Claude Code for most of my programming work, and I have very little idea what it's actually doing under the hood.

A few months ago I was poking around ~/.claude/projects/ and opened a session JSONL file. Buried in the conversation, Claude Code had read a .env file and echoed its contents back as a tool result. My database password, sitting in plaintext, in a file I never look at.

That was the afternoon I stopped what I was working on and started building Claudoscope.

The problem isn't Claude Code. It's visibility.

Claude Code doesn't have a cost breakdown per session. The Enterprise API doesn't surface spend data at all; only the admin dashboard does, and it's not granular enough. When we rolled it out across the org, nobody could answer basic questions: which sessions are expensive? Is the agent stuck in a loop somewhere? Is our CLAUDE.md actually doing anything useful or just eating context window?

And the security angle was worse. Session files contain the full conversation, including anything the agent reads from disk. If it touches a file with credentials, those credentials now live in an unencrypted JSONL file indefinitely. Nobody was checking for that.

So I built a flashlight.

Claudoscope is a native macOS menu bar app. It watches your Claude Code session files locally, parses them, and gives you a dashboard. Nothing leaves your machine.

The menu bar widget gives you a glance: today's sessions, tokens, cost, and any sessions that are currently running with a live cost number next to them. Click through to the full dashboard when you want the details.

"Why did Tuesday cost $47?"

That was the question I kept asking and couldn't answer. The analytics view breaks it down: cost by project, cost by model, daily trends. The cache tab shows whether your prompt cache is stable or busting on every request (cache busting is expensive and invisible without tracking). There's a what-if calculator that shows what your bill would look like if you moved Opus sessions to Sonnet.

"Is my CLAUDE.md any good?"

I didn't plan on building a config linter. It started as a quick check for obvious problems in my own setup. Then I ran it on a colleague's CLAUDE.md and found it was over 4,000 tokens, roughly 10% of the context window eaten by instructions before the agent even started working. So I made it a rule.

The linter now has 19 rules. It checks CLAUDE.md structure, skill metadata, deprecated commands, token budget estimates. It groups findings by rule rather than by file, so you see patterns. One rule (subprocess env scrub) has a one-click auto-fix.

The first time I ran it on our team's configs, it flagged raw XML brackets in a skill's frontmatter that would break the system prompt parser. Nobody had noticed because the failure was silent.

Secret scanning

This is probably the most useful feature and also the hardest one to get people excited about. Did the agent just leak your credentials? You'd never know unless something was watching.

Claudoscope scans session files for leaked credentials: private keys, AWS access keys, auth headers, API tokens, passwords in connection strings. It uses regex matching, Shannon entropy analysis, and allowlists for placeholder values. The entropy check matters because without it you get a wall of false positives from example code and docs.

When it finds something, a panel pops up on screen. Doesn't matter if the dashboard is open. It watches the tail of active session files and alerts you immediately.

What I learned from my own data

Building this meant spending a lot of time inside Claude Code's JSONL format. A few things I didn't expect:

Prompt cache reads are cheap ($0.30/MTok on Sonnet vs $3.00 uncached), so I assumed most of my input was cached. On some projects, 30-40% wasn't. The cache busts when session context shifts after compaction, and before I had a hit rate chart staring me in the face, I had no idea.

I also figured my expensive sessions would be the big multi-hour ones. They weren't. The cost was in dozens of short sessions where Claude Code loaded context, did one thing, and exited. Each one paid full input with no cache. Fifty quick questions cost me more than the three-hour refactor.

Most CLAUDE.md files across our team were 2,000-5,000 tokens. Context window you pay for on every message. A few people trimmed theirs after seeing the linter's token estimate.

And one gotcha for anyone parsing these files themselves: the JSONL contains intermediate records with null stop_reason, in-progress streaming responses. Sum all records naively and you double-count tokens. I shipped this bug and didn't catch it until cost estimates were 1.5-2x the actual Vertex bill. Not documented anywhere, as far as I can tell.

Under the hood

It watches ~/.claude/projects/ with macOS FSEvents (not polling). Session parsing runs on a Swift actor for thread safety. Cost estimation runs per-message, not per-session, because different messages in the same session can use different models. There's an LRU cache (20 sessions) so navigating between recent sessions feels instant.

I built it in SwiftUI, macOS 14+, Apple Silicon only. I wanted it to feel like a Mac app. That means no Linux or Windows, and I'm fine with that tradeoff.

Install

Free, open source, macOS only (Apple Silicon). Homebrew:

brew tap cordwainersmith/claudoscope
brew install --cask claudoscope

Or grab the DMG from GitHub. It auto-updates. The cost estimation is most useful on Enterprise plans where per-session data isn't available, but session analytics and config linting work regardless of your plan.

Go check your session files. You might not like what you find.