Claude Code just got measurably lighter on your machine. On August 18, 2026, Anthropic's @ClaudeDevs account posted a performance callout that had already shipped six days earlier: the Claude Code CLI now uses 2x less CPU at p99 — down from 24% to 10% — after a fix to how Bun's garbage collector gets triggered.
The tweet, at 195.5K views at time of writing, put it plainly:
"Perf win of the day: Claude Code CLI now uses 2x less CPU at p99. Bun's garbage collector was running on a fixed timer, so it would kick in mid-turn and steal CPU right when Claude Code was busiest. Now it waits until the process is idle."
If you run Claude Code on a laptop while doing other work, in CI, or as one of several parallel agent sessions, this is the kind of fix you feel without reading a changelog — less CPU contention means less fan noise, fewer stalls in whatever else is competing for cycles, and more predictable behavior under load. The mechanism behind it is also a genuinely reusable lesson for anyone building their own agent harness on Node.js or Bun.
TL;DR
| Question | Answer |
|---|---|
| What changed? | p99 CPU share dropped from 24% to 10%; p50 dropped from ~5.8% to ~2.5% |
| What caused the high usage? | Bun's garbage collector ran on a fixed timer, colliding with active turns |
| What's the fix? | GC now triggers when the process is idle, not on a schedule |
| Which release shipped it? | v2.1.229, on August 12, 2026 |
| When was it announced? | August 18, 2026 — six days after it shipped |
| Is the number independently verified? | No — self-reported by Anthropic via @ClaudeDevs |
| Does this apply beyond Claude Code? | Yes — it's a general pattern for GC scheduling in any Bun/Node harness |
What the chart actually shows
The chart Anthropic attached to the tweet, titled "Claude Code now uses 2x less CPU at p99," plots one data point per release from March through August 2026 — spanning versions v2.1.228 through v2.1.232 — with two lines: a thick line for p99 CPU share and a thin line for p50 (median) CPU share.
Before the fix, the pattern was noisy rather than trending in a clear direction: p99 CPU share fluctuated between roughly 16% and 32% release over release, while p50 held fairly steady around 5.8%. That gap between p50 and p99 is the tell — most turns were cheap, but a meaningful tail of turns were spiking CPU usage well above typical, which is exactly the signature of a periodic background process (like a GC timer) occasionally colliding with active work.
A vertical marker on the chart is labeled "v2.1.229 / Aug 12" — the release where the fix shipped. After that point, both lines drop and flatten: p99 settles at 10%, p50 at 2.5%. The chart's own caption frames the measurement window precisely: "Every release, Mar → Aug 2026 · one point per release · p99 (thick) and p50 (thin) CPU share · v2.1.228 → v2.1.232."
Worth being precise about the timeline here, since it's easy to blur: the fix shipped on August 12, 2026 in v2.1.229. The tweet describing it was posted six days later, on August 18, 2026. This was a retrospective callout of an already-live fix, not a same-day launch announcement.
Why a fixed-timer GC hurts p99 specifically
The root cause is a scheduling mismatch, not a memory-management bug. A garbage collector that runs on a fixed timer doesn't know anything about what the host process is doing — it fires every N seconds (or after N allocations, depending on implementation) regardless of whether the process is mid-computation or sitting idle.
For most of Claude Code's runtime, that's harmless: if the CLI is idle waiting on user input or a model response, a GC pause landing in that window costs nothing observable. But Claude Code's busiest moments — parsing a large tool result, streaming a long response, running multiple tool calls in sequence — are also when CPU is already under contention. A fixed-timer GC has no way to avoid those windows; it will eventually collide with one, and when it does, that turn's CPU usage spikes. Averaged across a session, that shows up as a low, stable p50 with a wide, noisy p99 tail — precisely the "before" shape on Anthropic's chart.
Switching from timer-based to idle-triggered GC removes the collision by construction: the collector waits for a window where the process genuinely has nothing else to do, rather than gambling on a fixed schedule. That's why both lines on the chart compress after v2.1.229 — not just the tail (p99), but also the median (p50), because even the "normal" case previously absorbed some timer-driven GC overhead that idle-triggered GC now avoids entirely.
The harness-engineering lesson (not just internals trivia)
This is a small fix on Anthropic's side, but the underlying idea generalizes cleanly, and it's worth pulling out separately from the Claude Code specifics. Ziang Gao (@ZetsubosenseiG), replying to the original thread, made exactly this point:
"That's a good improvement and also a useful tip for harness design: run GC when it is least disruptive, such as while the process is idle or waiting for the model response, rather than simply every N seconds."
If you're building your own agent harness — a long-running Node.js or Bun process that alternates between bursty, CPU-heavy work (tool execution, parsing, streaming) and idle stretches (waiting on a model API call, waiting on user input) — the same failure mode is available to you by default, and the same fix applies:
- Identify your process's natural idle windows. For an agent harness, that's typically the time spent blocked on an outbound model request — CPU-free time you're already paying for in wall-clock latency.
- Prefer idle- or event-triggered background work over fixed timers for anything non-urgent: garbage collection, cache eviction, telemetry flushes, log rotation. A fixed timer optimizes for simplicity, not for avoiding your busiest moments.
- Measure p99, not just p50, when you tune this. A background process that only occasionally collides with peak load won't move your average CPU usage much — it will show up almost entirely in the tail, which is exactly why Anthropic's chart plots both lines rather than one.
This is the same class of lesson threaded through explainx.ai's broader harness engineering coverage: benchmark and resource-usage gains increasingly come from scaffolding decisions like this one, not from the underlying model.
Why this matters if you run Claude Code today
Most Claude Code users don't inspect their CPU graphs turn by turn, so the practical takeaway is simpler than the mechanism: if you've noticed Claude Code occasionally spiking your fan or competing with other processes mid-session, that's the exact symptom this fix targets, and it should be less common on current releases.
It matters most in a few concrete setups:
- Laptops running on battery, where CPU spikes translate directly into heat and drained battery, especially during long agentic sessions.
- CI pipelines that bake Claude Code into build or review steps, where CPU contention with other CI jobs on a shared runner has a real cost — see explainx.ai's Claude Code VPS production workflow coverage for the broader "running Claude Code unattended" context.
- Multi-session and parallel-agent setups, where several Claude Code processes run concurrently — the kind of workflow covered in explainx.ai's guide to Claude Code's cross-session messaging — and where each process's p99 tail compounds against the others on shared hardware.
None of this requires you to do anything: it's a CLI-level fix, not a setting. Update to v2.1.229 or later (check with claude --version) and the idle-triggered GC behavior applies automatically. It sits alongside Claude Code's broader Bun runtime work — the CLI has been running on Bun's Rust-ported runtime since mid-2026, and this GC scheduling fix is a continuation of that same performance track, not a separate rewrite.
What this doesn't tell you
Worth stating plainly: this is Anthropic's own reported number, published via a corporate social account with a chart, not an independently reproduced benchmark. There's no public methodology note on sample size, session mix, or hardware profile behind the "measured at the 99th percentile across all sessions" subtitle — it's aggregate telemetry from Anthropic's own fleet, not something a third party has verified. The mechanism it describes — timer-based GC contending with foreground work — is well-understood and easy to reason about independently, which is a reasonable basis for trusting the direction of the claim, even without an outside audit of the exact percentages.
Related reading
- What is an agent harness? The scaffolding layer that makes AI agents reliable
- Agent harness engineering: Terminal-Bench, LangChain, and where gains actually come from
- Claude Code ships Bun 1.4 Rust runtime: how to verify what changed
- Context, prompt, loop: the harness engineering stack
- Claude Code pricing guide 2026
- Claude Code commands: complete slash command reference
- Claude Code cross-session messaging and listing agents
- Claude Code VPS production workflow
Primary source: @ClaudeDevs on X, August 18, 2026 — chart: "Claude Code now uses 2x less CPU at p99," v2.1.228 → v2.1.232.
Version numbers, release dates, and the reported CPU figures reflect the @ClaudeDevs announcement as published on August 18, 2026, describing a fix that shipped in v2.1.229 on August 12, 2026. Claude Code's release cadence moves quickly — check claude --version for your current build before assuming this behavior applies.