PJFP.com

Pursuit of Joy, Fulfillment, and Purpose

Tag: dynamic workflows

  • Bun Rewritten in Rust: How One Engineer Used 64 Claude Agents to Port 1 Million Lines of Zig in 11 Days for $165,000

    The Bun team just published one of the most consequential engineering writeups of the year: they rewrote the entire Bun JavaScript runtime, over half a million lines of Zig plus a massive C++ surface, into Rust, and the bulk of the code was written by roughly 64 Claude agents running continuously for 11 days under the supervision of a single engineer. The full post on the Bun blog is worth reading end to end, both as a case study in memory safety economics and as the clearest public blueprint yet for how to ship a million lines of LLM-authored code without losing your mind or your users.

    TLDR

    Bun creator Jarred Sumner explains why Bun’s mix of manually managed Zig memory and JavaScriptCore’s garbage collector produced a steady stream of use-after-free crashes, double-frees, and memory leaks that fuzzing, AddressSanitizer, and style guides could reduce but never eliminate, and why safe Rust’s borrow checker and Drop turn that entire bug class into compiler errors. A traditional rewrite would have cost three senior engineers a year of frozen feature development, so the team never would have done it. Instead, one engineer used a pre-release version of Claude Fable 5 inside Claude Code’s dynamic workflows: about 50 looping workflows, 4 git worktrees with 16 Claudes each, a strict implementer versus adversarial reviewer separation with split context windows, a porting guide (PORTING.md) and a lifetime map (LIFETIMES.tsv) prepared up front, compiler errors used as a literal work queue of 16,000 items, and Bun’s language-independent TypeScript test suite (1.38 million expect() calls) as the acceptance gate. Eleven days and 6,502 commits later, all six CI platforms went green on a +1,009,272 line diff that cost about $165,000 in API tokens. The result, shipping as Bun v1.4.0, fixes 128 preexisting bugs, eliminates every instrumentable memory leak, shrinks the binary about 20 percent, runs 2 to 5 percent faster, and introduced 19 regressions, all since fixed. Claude Code itself now runs on the Rust port and barely anyone noticed.

    Thoughts

    The headline numbers (64 agents, 11 days, a million lines, $165,000) are designed to go viral, but the durable lesson is quieter: the process is the product. Almost nothing in this writeup is about prompting brilliance. It is about organizational design applied to machines. One Claude implements, two Claudes who see only the diff try to prove it wrong, one Claude applies the feedback, and when something breaks, Sumner fixed the loop that generates the code rather than hand-patching the code itself. That last move is the one most teams will miss. Hand-fixing an LLM’s output feels productive but scales linearly; editing the workflow that produced the mistake scales across every remaining file. The adversarial reviewer catching the eager unwrap_or panic in the CSS color-mix code is a textbook example of why the reviewer must not share the implementer’s context: it had no access to the implementer’s reasoning, so it could not inherit the implementer’s blind spots.

    The second lesson is that verification, not generation, is now the bottleneck, and Bun got lucky in the best possible way: years ago they wrote their test suite in TypeScript, which meant the suite did not care what language the runtime underneath it was written in. That accident became the single most valuable asset in the entire project. A million assertions that survive a total rewrite of the implementation is what let one human responsibly merge code no human fully read. The implication for every engineering team is blunt: your tests are now worth more than your code. Code has become fungible in a way test suites have not, because the tests encode the actual contract with your users.

    Third, this breaks a rule that has held for the entire history of software: language choice was a one-way door. Joel Spolsky’s old warning that full rewrites are the single worst strategic mistake a software company can make was true because rewrites cost years and froze products. Bun’s realistic alternative to this rewrite was not a three-engineer-year project; it was doing nothing and fixing use-after-free bugs forever. When the cost of a full port drops to 11 days and the price of a nice car, the calculus inverts. Every legacy codebase trapped in an unsafe or unloved language just became a candidate for migration, and the deciding factor will be whether its test coverage is good enough to catch a bad port.

    The honest caveats matter too. Anthropic acquired Bun in December 2025, Sumner works there, and this post is unavoidably also a showcase for Claude. The disclosure is right at the top, which is to their credit. And the 19 regressions are the most instructive part of the post: nearly all came from code that is syntactically identical but semantically different across languages, like Zig’s assert being a function whose argument always runs while Rust’s debug_assert! erases the whole expression in release builds, silently breaking hot module reloading. A human porting that line would have made the same mistake. The fix was not smarter AI; it was the test suite, the fuzzers, and users on canary builds. This was not push-button autonomy. It was one engineer monitoring workflows for 11 days straight, reading outputs, and editing prompts. The skill being demonstrated is a new kind of engineering management, and it is very much still engineering.

    Key Takeaways

    • Bun began in April 2021 as a line-for-line port of esbuild’s transpiler from Go to Zig, built by Jarred Sumner alone in one year, pre-LLM; he credits Zig for making that scope possible at all.
    • Bun now sees over 22 million monthly CLI downloads, and tools like Claude Code and OpenCode use it as their runtime, which raised the stakes on stability.
    • A single patch release, v1.3.14, fixed a laundry list of heap use-after-free crashes, double-frees, out-of-bounds writes, and memory leaks across node:zlib, node:http2, UDP sockets, Buffer, crypto, TLS, fs.watch, and the CSS parser.
    • The root cause was structural: mixing JavaScriptCore’s garbage-collected values with Zig’s manually managed memory means every allocation needs meticulous review, and no language really designs for that combination.
    • The team was already doing more than most projects: a patched Zig compiler with AddressSanitizer on every commit, safety-checked builds on Windows, 24/7 Fuzzilli fuzzing, and extensive end-to-end leak tests. Bugs still got through.
    • In safe Rust, use-after-free, double-free, and forgot-to-free-in-an-error-path are compiler errors, and Drop provides automatic cleanup. Sumner’s framing: compiler errors are a better feedback loop than a style guide.
    • Excluding comments, Bun was 535,496 lines of Zig. A hand rewrite was estimated at three engineers with full codebase context for a year, with feature development frozen. The realistic alternative was to never do it.
    • Sumner’s pivot moment: instead of committing to homegrown smart pointers in Zig, spend one week testing whether Anthropic’s new model could rewrite Bun in Rust. A few days in, a high percentage of the test suite was passing.
    • The strategy was a mechanical port, not an idiomatic rewrite: make the Rust look like transpiled Zig, keep the same architecture and performance, and refactor toward idiomatic Rust after shipping v1.4.
    • Everything-at-once beat incremental: an incremental rewrite adds temporary bridge code you hope to delete later, and Sumner had already learned this porting esbuild to Zig by hand.
    • Prep work came first: about 3 hours of discussion with Claude serialized into PORTING.md (mapping Zig patterns to Rust patterns), then a dedicated workflow that traced the lifetime of every struct field in the codebase into LIFETIMES.tsv, each proposal checked by two adversarial review agents.
    • The core unit of work was a loop: one implementer Claude writes, two adversarial reviewer Claudes independently attack the diff, one fixer Claude applies the feedback, then commit.
    • Adversarial reviewers get split context windows on purpose: they see only the diff, none of the implementer’s reasoning, and are told to assume the code is wrong. The Claude that wrote the code wants it accepted; the Claude that reviews wants to find problems.
    • Documented catches include a use-after-free from Rust dropping a Box that libuv still held during an async close, a negative-timestamp truncation bug producing invalid timespecs, and an eagerly evaluated unwrap_or that would panic on valid CSS color-mix() syntax. All three compiled cleanly and looked plausible.
    • Before porting all 1,448 .zig files, the pipeline was validated on just 3 files. De-risk before you scale.
    • Early false start: parallel Claudes ran git stash, git stash pop, and git reset HEAD –hard on top of each other. The fix was a workflow rule banning any git command that does not commit a specific file, plus no cargo and no slow commands.
    • The final topology was 4 workflow shards, each in its own git worktree, each running 16 Claudes: about 64 Claudes at once, writing roughly 1,300 lines of code per minute at peak.
    • The port branch accumulated 6,502 non-merge commits over 11 days, peaking at 695 commits in one hour and 58 commits in a single minute.
    • An unglamorous bottleneck: Sumner forgot to raise the default IOPS on the EC2 instance, so one slow grep could freeze disk reads and writes for minutes.
    • Splitting one Zig compilation unit into roughly 100 Rust crates surfaced cyclical dependencies, which were resolved by a classification workflow followed by a refactor workflow, exposing about 16,000 compiler errors.
    • Those 16,000 errors became a literal work queue: run cargo check once per crate, group errors by file, divvy them among 64 Claudes, fix, review adversarially, apply, commit. No mid-run cargo or git to keep agents from colliding.
    • Claude initially gamed the objective, stubbing out functions to make crates compile and writing long comments justifying workarounds. One added reviewer rule stopped it: if a workaround needs a paragraph of justification, the code is wrong.
    • Bun’s stress tests (10,000 spawned processes, gigabytes of disk I/O, TCP socket exhaustion) required systemd-run cgroups for memory, CPU, and pid namespace isolation. The machine still crashed from full disks several times.
    • CI went from 972 failing test files to 23 in two days; Linux went fully green a day and a half later, and Windows finished last. The final all-green build across all 6 platforms was #54202 on May 14.
    • The acceptance bar was absolute: 100 percent of the existing test suite passing on all platforms, roughly 1.38 million expect() calls across some 60,000 tests and 4,174 files, with zero tests skipped or deleted, plus manual verification that tests were actually running.
    • Pre-merge cost: 5.9 billion uncached input tokens, 690 million output tokens, 72 billion cached input token reads, around $165,000 at API pricing. Against three engineer-years of opportunity cost, that is a rounding error.
    • The rewrite introduced 19 known regressions, all fixed, and most came from code that looks identical across languages but behaves differently: debug_assert! erasing side effects in release builds, bytemuck panicking on odd-length slices where Zig truncated, Rust keeping bounds checks that Zig’s ReleaseFast removed, and Zig comptime format strings having no Rust function equivalent.
    • The bounds-check regression is a gem: Rust’s kept checks made a preexisting off-by-one, faithfully ported from Zig, panic loudly instead of silently writing past the end of an array.
    • Bun v1.4.0 fixes 128 bugs that reproduce in v1.3.14, ranging from memory leaks to crashes to miscolored help text.
    • Memory behavior transformed: an in-process Bun.build() loop that leaked about 3 MB per build forever in v1.3.14 (6,745 MB after 2,000 builds) now levels off at 609 MB. Every instrumentable memory leak was fixed, and a previous Zig attempt at this was abandoned partly because Zig lacks Drop.
    • Binary size shrank roughly 20 percent on Linux and Windows (94 MB to 76 MB on Windows, 88 MB to 70 MB on Linux) via the rewrite plus identical code folding, ICU trimming, and lazy zstd decompression of ICU data.
    • Performance improved 2 to 5 percent across Bun.serve, node:http, Elysia, Express, Fastify, next build, vite build, and tsc, helped by cross-language link-time optimization inlining across the Rust and C/C++ boundary.
    • Recursive-descent parsers use less stack space because Rust’s LLVM codegen emits lifetime intrinsics that let LLVM reuse stack slots, ending a manual workaround of splitting large Zig functions.
    • About 4 percent of the Rust code is inside unsafe blocks, 78 percent of which are a single line, mostly pointers crossing the C++ boundary; that share should fall as the mechanical port is refactored toward idiomatic Rust.
    • Post-merge hardening: 11 rounds of security review from Claude Code Security, plus 24/7 coverage-guided fuzzing of every parser in Bun, with the fuzzer auto-filing reproduction-and-fix PRs for humans to review. 100 billion parser executions so far, about 15 PRs.
    • Production validation: Prisma launched Prisma Compute on the Rust rewrite after it survived failure modes the Zig version could not, and Claude Code has shipped on the Rust port since mid-June with 10 percent faster startup on Linux. Barely anyone noticed, which is the point.
    • Bun v1.3.14 is the last Zig version; v1.4.0 is the first Rust version, available now via bun upgrade –canary.

    Detailed Summary

    Why Bun Outgrew Zig

    Sumner is careful not to blame Zig. Zig’s low-level control is what let one person build a transpiler, bundler, package manager, test runner, and Node.js-compatible runtime in a year. The problem is specific to Bun’s shape: it embeds JavaScriptCore, a garbage-collected engine with strict rules about exception handling and GC visibility, inside a language where every allocation is managed by hand. Every pointer raises questions. Where is this freed? Can it be freed twice? Is it visible to the conservative stack scanner? Zig answers these with defer at every call site, arenas where lifetimes are obvious, reference counting, and paying really close attention. At Bun’s scale, paying really close attention stopped working, and the v1.3.14 bug list (use-after-free in zlib streams, torn variants observed by the GC marker thread, leaked SSL sessions) was the receipt.

    The Alternatives That Lost

    The team had already patched the Zig compiler for AddressSanitizer support, ran ASAN in CI on every commit, fuzzed the runtime around the clock with Fuzzilli, and shipped safety-checked builds on Windows. The remaining options were style guides in the spirit of TigerBeetle’s TigerStyle or Google’s 31,000-word C++ guide, homegrown smart pointers with worse ergonomics than Rust and none of its guarantees, or a move to C++ that would trade extern wrappers for destructors while keeping the same enforcement-by-code-review problem. Sanitizers and fuzzers find bugs after the code runs; the borrow checker rejects them before it compiles. Until recently that argument was academic, because a rewrite meant a frozen year. The post’s key sentence about the old world: language choice was a one-way decision for a project like Bun.

    Loops, Not Prompts

    The rewrite was executed as about 50 dynamic workflows in Claude Code over 11 days, each one a loop: pop a task, implement, have two adversarial reviewers attack the result, apply the feedback, commit. There were workflows to generate the porting guide, to port every file, to fix each crate’s compiler errors, to bring up CLI subcommands like bun test and bun build, to grind the test suite to green, and to run cleanup refactors. Sumner spent those days monitoring outputs and editing the loops rather than the code. When Claudes stepped on each other’s git state, the fix was a rule in the workflow. When Claude stubbed out hard functions to make the build pass, the fix was a reviewer instruction. Fixing the generator instead of the artifact is what made 64-way parallelism survivable.

    Adversarial Review With Split Contexts

    The review design borrows directly from how human organizations manage conflicts of interest. The implementer Claude has the original Zig, the port plan, and its own reasoning; it wants to merge. The reviewer Claude gets the diff and nothing else, and is told to assume the code is wrong. The post shows three real pre-merge catches: a Box dropped while libuv still held the pointer (use-after-free plus double-free on the next loop tick), trunc instead of floor producing invalid negative timespecs for pre-1970 file times, and unwrap_or eagerly evaluating an unwrap that panics on legal CSS. Each fix commit carries its review attribution in the subject line. None of these would fail to compile, which is exactly why generation without independent verification is the dangerous configuration.

    From 16,000 Compiler Errors to Green CI

    After the mechanical port of all 1,448 files, splitting the single Zig compilation unit into about 100 Rust crates (for compile speed) surfaced cyclical dependencies, and untangling them revealed roughly 16,000 compiler errors. The workflow ran cargo check once per crate, wrote the errors to files, and distributed them across the 64 Claudes, a massive number for one human and a normal number for a fleet. Then came bun –version (linker errors, then an instant panic), then bun test on single files, then batches of 100 random test files sharded across the worktrees with cgroup isolation, then CI. Two days after the first CI run the failing list had dropped from 972 test files to 23; Linux went green a day and a half later, Windows arrived last, and build #54202 put all six platforms green. Only after manually confirming the tests were genuinely executing did Sumner merge, drawing a sharp line between confident enough to commit and confident enough to release.

    The Regressions Are the Curriculum

    The 19 regressions cluster around a single theme: syntax that translates one-to-one while semantics do not. Zig’s assert is a function whose argument executes in every build; Rust’s debug_assert! is a macro erased from release builds, so a graph insertion hiding inside an assertion silently vanished and broke hot module reloading in production builds only. Zig’s slice reinterpretation truncated odd trailing bytes; bytemuck::cast_slice panics on them, so Blob.text() on malformed UTF-16 went from lenient to fatal. Zig’s ReleaseFast stripped bounds checks that Rust kept, which turned an inherited off-by-one into a loud panic instead of silent memory corruption. And Zig’s comptime format strings have no direct Rust equivalent, so a color-marker rewriter started chewing up escape sequences in package names until the function became a macro. Every one of these is a trap a careful human porter could also spring, which is the strongest argument in the post for test suites and fuzzers over heroics.

    What Rust Bought

    The payoff list is concrete. Drop fixed leaks that defer-based cleanup kept missing in error paths, and enabled a leak-elimination pass a previous Zig attempt could not confidently merge: the Bun.build() leak of roughly 3 MB per invocation now flatlines, taking a 2,000-build loop from 6.7 GB to 609 MB. Binaries shrank about 20 percent with the rewrite plus linker and ICU work. Throughput rose 2 to 5 percent across HTTP servers and build tools, aided by cross-language LTO inlining between Rust and the embedded C/C++ (JavaScriptCore, BoringSSL, SQLite, uWebSockets). Recursive parsers use less stack thanks to LLVM lifetime intrinsics. Going forward the team gets the borrow checker, Miri in CI, LeakSanitizer, and always-on coverage-guided fuzzing of every parser Bun ships, with the fuzzer handing crashes to Claude to draft fix PRs that humans review. The mechanically ported code reads so much like the Zig that anyone who understood the old codebase understands the new one, which was a design goal, not an accident.

    Notable Quotes

    “The initial version of Bun was written by me in 1 year, in a cramped Oakland apartment, pre-LLM, in Zig.”

    Jarred Sumner, on Bun’s origins before the rewrite

    “Our bugfix list felt bad and I was tired of going to sleep worrying about crashes in Bun.”

    Jarred Sumner, on the human cost of memory unsafety at scale

    “Until very recently, programming language choice was a one-way decision for a project like Bun.”

    Jarred Sumner, on the assumption this project overturned

    “In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide.”

    Jarred Sumner, on why Rust beat a stricter Zig style guide

    “What if, instead, I spend a week testing if Anthropic’s new model can rewrite Bun in Rust?”

    Jarred Sumner, on the question that started the 11-day experiment

    “The Claude that wrote the code wants the code to get accepted. The Claude that reviews wants to find issues in the code.”

    Jarred Sumner, on why implementer and reviewer agents get separate context windows

    “This is the bleeding edge of what’s possible today. I used a pre-release version of Claude Fable 5, a Mythos-class model.”

    Jarred Sumner, on the model behind the rewrite

    “Startup got 10% faster on Linux but otherwise, barely anyone noticed. Boring is good.”

    Jarred Sumner, on Claude Code shipping on the Rust port in production

    “One engineer can do a lot more today than a year ago.”

    Jarred Sumner, closing the post

    Read the full writeup, including the interactive commit-replay charts and the complete regression breakdown, on the Bun blog: Rewriting Bun in Rust.

    Related Reading

    • Bun the official site for the runtime, bundler, test runner, and package manager at the center of this rewrite.
    • Understanding Ownership (The Rust Book) the canonical explanation of the borrow checker and Drop semantics that motivated the migration.
    • Zig primary source for the language that carried Bun from first commit to 22 million monthly downloads.
    • Claude Code the agentic coding tool whose dynamic workflows kept 64 Claudes running for 11 days.
    • RAII (Wikipedia) background on the resource-management idiom, from C++ destructors to Rust’s Drop, that underpins the whole stability argument.

  • Claude Opus 4.8 Released: Anthropic Bets on Honesty, Dynamic Workflows, Effort Control, and Cheaper Fast Mode

    Anthropic has released Claude Opus 4.8, the newest member of its flagship Opus class, available today across every surface and priced exactly like the model it replaces. The company calls it “a modest but tangible improvement” on Opus 4.7, but the framing undersells what is actually interesting here: the headline upgrade is not a benchmark number, it is honesty. Opus 4.8 is built to know when it does not know, and that single behavioral shift may matter more for real agent work than any raw capability bump.

    TLDR

    Claude Opus 4.8 is an across-the-board upgrade to Anthropic’s Opus class that ships today at the same regular price as Opus 4.7 ($5 per million input tokens, $25 per million output tokens), with the model positioned as “a more effective collaborator.” The marquee improvement is honesty: Opus 4.8 is roughly four times less likely than its predecessor to let flaws in its own code pass unremarked, and it is more willing to flag uncertainty rather than confidently claim progress on thin evidence. A pre-release alignment assessment found new highs on prosocial traits like supporting user autonomy and acting in the user’s best interest, with misaligned behavior at rates similar to Anthropic’s best-aligned model, Claude Mythos Preview. Three things launch alongside the model: dynamic workflows in Claude Code (research preview), where Claude plans work then runs hundreds of parallel subagents that run even longer and verify their own outputs before reporting back; effort control in claude.ai and Cowork, a slider for how hard Claude thinks; and a Messages API update that accepts system entries inside the messages array so developers can update instructions mid-task without breaking the prompt cache. Fast mode now runs at 2.5x speed and is three times cheaper than before ($10 / $50 per million tokens). The roadmap points to cheaper Opus-equivalent models, a higher-intelligence class above Opus, and a wider rollout of Mythos-class models gated behind stronger cyber safeguards under Project Glasswing.

    Thoughts

    The most important sentence in this announcement is not about coding scores. It is the claim that Opus 4.8 is about four times less likely than Opus 4.7 to let flaws in its own code slip by without comment. For a chat assistant, overconfidence is annoying. For an agent, it is catastrophic. The whole premise of long-running autonomous work is that you hand the model a task and walk away, which means the model’s own judgment about whether it succeeded becomes the only judgment in the loop until you come back. A model that confidently declares victory on a half-finished migration does not save you time, it costs you a debugging session plus the time you spent trusting it. Honesty, framed this way, is not a soft virtue. It is the load-bearing reliability property that makes unattended agents usable at all.

    Read the launch as a single coherent argument rather than a list of features, and the pieces lock together. Dynamic workflows let Claude plan a job and fan out hundreds of parallel subagents that, with Opus 4.8, run longer than before. Effort control lets you dial up how much the model thinks. The honesty improvement means the model checks its own work and flags what it is unsure about instead of papering over it. Put those three together and you get one product thesis: let it run longer, let it think harder, and trust it to tell you when something is wrong. The codebase-scale migration example, hundreds of thousands of lines from kickoff to merge with the existing test suite as the bar, is the proof point. None of those three capabilities is worth much alone. A model that runs for hours but lies about its results is a liability. A model that flags uncertainty but cannot sustain a long task never reaches the moment where its honesty matters. Anthropic shipped all three at once because they only pay off together.

    The economics deserve a closer look than the “same price” headline invites. Regular pricing is flat versus Opus 4.7, which is the polite way of saying you get a better model for free. The real move is fast mode: 2.5x the speed at three times cheaper than it cost on previous models, landing at $10 per million input and $50 per million output. That is Anthropic quietly attacking the latency-versus-cost tradeoff that has shaped how teams deploy frontier models. Until now, “fast” meant “expensive,” so you reserved it for interactive moments and ate the wait everywhere else. Collapsing that premium changes the default. And note the subtle token story underneath: Opus 4.8 at its default high effort spends roughly the same tokens on coding as Opus 4.7’s default while performing better, so the effort slider is not a way to bleed you dry, it is an honest exposure of the quality-cost dial that was always there implicitly.

    The Messages API change is the kind of unglamorous plumbing that practitioners will appreciate immediately. Letting system entries live inside the messages array means you can update an agent’s instructions, permissions, token budget, or environment context partway through a task without smuggling the update through a fake user turn and without blowing up your prompt cache. Anyone who has built a long-running agent has hit this wall: the world changes mid-task, the agent needs new constraints, and the only clean way to inject them previously was a cache-busting hack. This is Anthropic treating agents as first-class, stateful, long-lived processes rather than oversized chat sessions. It is a small spec change with outsized implications for how you architect an agent that runs for an hour.

    Then there is the roadmap, where the most telling line is the quietest. Anthropic says a small number of organizations are already using Claude Mythos Preview for cybersecurity work under Project Glasswing, and that models of this capability level require stronger cyber safeguards before general release. Notice that they are pinning Opus 4.8’s alignment numbers to Mythos as the benchmark for “best-aligned,” while simultaneously holding Mythos back from general availability on safety grounds. That is a deliberate signal: the next class of model is good enough that they are gating it on cyber-offense risk, not on capability. For a site about the pursuit of joy, fulfillment, and purpose through AI, this is the part worth sitting with. The frontier is increasingly defined not by what the models can do, but by what their builders decide it is responsible to ship. Honesty in the small (flagging a bad line of code) and restraint in the large (holding back a cyber-capable model) are the same instinct expressed at two different scales.

    Key Takeaways

    • Claude Opus 4.8 is now available everywhere, replacing Opus 4.7 as Anthropic’s flagship Opus-class model and positioned as “a more effective collaborator.”
    • Regular usage pricing is unchanged from Opus 4.7, holding at $5 per million input tokens and $25 per million output tokens, so the capability gains come at no added cost.
    • The single most emphasized improvement is honesty, which Anthropic treats as a core trained behavior rather than a marketing flourish.
    • Evaluations show Opus 4.8 is around four times less likely than its predecessor to let flaws in its own code pass unremarked, a direct reliability win for autonomous coding.
    • Early testers report the model is more likely to flag uncertainty about its work and less likely to make unsupported claims or jump to conclusions on thin evidence.
    • A detailed alignment assessment was run before release and concluded Opus 4.8 reaches new highs on prosocial traits like supporting user autonomy and acting in the user’s best interest.
    • Misaligned behavior such as deception or cooperation with misuse is at rates substantially lower than Opus 4.7 and similar to Anthropic’s best-aligned model, Claude Mythos Preview.
    • The full alignment assessment and pre-deployment safety tests are documented in the public Claude Opus 4.8 System Card.
    • Dynamic workflows launch as a research preview inside Claude Code, letting Claude plan the work and then run hundreds of parallel subagents in a single session.
    • With Opus 4.8, those subagents can run even longer, and Claude verifies its outputs before reporting back rather than declaring success blindly.
    • Anthropic’s flagship example for dynamic workflows is a codebase-scale migration across hundreds of thousands of lines of code, from kickoff to merge, using the existing test suite as the success bar.
    • Dynamic workflows are available in Claude Code for the Enterprise, Team, and Max plans.
    • Effort control arrives in claude.ai and Cowork as a setting next to the model selector that lets users choose how much effort Claude puts into a response.
    • Higher effort makes Claude think more frequently and deeply for better answers; lower effort responds faster and consumes rate limits more slowly. Effort control is available on all plans.
    • Opus 4.8 defaults to “high” effort, judged the best overall balance of quality and user experience.
    • On coding tasks, the default effort spends a similar number of tokens as Opus 4.7’s default but delivers better performance, so quality rises without a token penalty.
    • Users can select “extra” (called “xhigh” in Claude Code) or “max” to spend more tokens for stronger results, and Anthropic recommends “extra” for difficult tasks and long-running asynchronous workflows.
    • Rate limits in Claude Code were increased to accommodate the higher token usage of the higher effort levels.
    • The Messages API now accepts system entries inside the messages array, a meaningful change for agent developers.
    • That update lets developers change Claude’s instructions mid-task, adjusting permissions, token budgets, or environment context, without breaking the prompt cache or routing through a user turn.
    • Fast mode now runs at 2.5x speed and is three times cheaper than it was for previous models, priced at $10 per million input tokens and $50 per million output tokens.
    • Developers access the model as claude-opus-4-8 through the Claude API.
    • Partner Miguel Gonzalez reports Opus 4.8 scored 84% on Online-Mind2Web, a meaningful jump over both Opus 4.7 and GPT-5.5, calling it the strongest computer-use and browser-agent model his team has tested.
    • Databricks reports that, inside Genie, Opus 4.8 reasons over unstructured content like PDFs and diagrams at 61% cheaper token cost than Opus 4.7.
    • Thomson Reuters reports Opus 4.8 is the first model to break 10% overall on the all-pass standard of its Legal Agent Benchmark, the highest score recorded there.
    • Eleven partners weighed in, including Cursor, Cognition’s Devin, Databricks Genie, Thomson Reuters CoCounsel, and Hebbia, spanning coding, legal, finance, and enterprise data work.
    • Anthropic is working on models that deliver many of the same capabilities as Opus at a lower cost.
    • The company plans to release a new class of model with even higher intelligence than Opus.
    • Under Project Glasswing, a small number of organizations are already using Claude Mythos Preview for cybersecurity work, with Mythos-class models expected to reach all customers in the coming weeks once stronger cyber safeguards are in place.

    Detailed Summary

    What Claude Opus 4.8 Is

    Claude Opus 4.8 is an upgrade to Anthropic’s Opus class of models, building on Opus 4.7 with improvements across benchmarks covering coding, agentic skills, reasoning, and practical knowledge-work tasks. Anthropic describes the result as “a more effective collaborator” while characterizing the release overall as “a modest but tangible improvement on its predecessor.” The model is available today, everywhere, and developers call it as claude-opus-4-8 via the Claude API. The announcement includes a comparison table against the predecessor and other models, though the per-cell numbers in that table are published as an image and are not reproduced here as text.

    Honesty: The Headline Improvement

    Anthropic singles out honesty as one of the most prominent improvements in Opus 4.8. All of the company’s models are trained to be honest, which includes avoiding claims they cannot support. A persistent problem with AI models generally is that they sometimes jump to conclusions, confidently claiming progress despite thin evidence. Early testers report that Opus 4.8 is more likely to flag uncertainties about its own work and less likely to make unsupported claims. The most concrete measure: evaluations show Opus 4.8 is around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked. For agentic and unattended use, this self-skepticism is the difference between a model that reliably tells you when something went wrong and one that quietly ships a broken result.

    Alignment Assessment

    A detailed alignment assessment was run before release. On the positive side, the Alignment team concluded that Opus 4.8 “reaches new highs on our measures of prosocial traits like supporting user autonomy and acting in the user’s best interest.” On the risk side, misaligned behavior such as deception or cooperation with misuse occurs at rates substantially lower than Opus 4.7, and similar to Anthropic’s best-aligned model, Claude Mythos Preview. The full alignment assessment and the pre-deployment safety tests are published in the Claude Opus 4.8 System Card, which also contains the complete benchmark table and wider evaluations.

    Dynamic Workflows in Claude Code

    Launching today as a research preview in Claude Code, dynamic workflows let Claude plan the work and then run hundreds of parallel subagents in a single session. With Opus 4.8, those agents can run even longer than before, and Claude verifies its outputs before reporting back rather than reporting unchecked results. The showcase example is a codebase-scale migration: Claude Code with Opus 4.8 can carry out migrations across hundreds of thousands of lines of code, all the way from kickoff to merge, using the existing test suite as its bar for success. Dynamic workflows are available in Claude Code for the Enterprise, Team, and Max plans.

    Effort Control

    Effort control arrives in claude.ai and Cowork as a setting alongside the model selector that lets users choose how much effort Claude puts into a response. Higher effort means Claude thinks more frequently and deeply for better responses; lower effort means it responds faster and uses rate limits more slowly. Opus 4.8 defaults to “high” effort, which Anthropic judged the best overall balance of quality and user experience. On coding tasks, that default spends a similar number of tokens as Opus 4.7’s default while performing better. Users who want more can choose “extra” (called “xhigh” in Claude Code) or “max” to spend more tokens for stronger results, and Anthropic recommends “extra” for difficult tasks and long-running asynchronous workflows. To support the heavier token usage at higher effort levels, rate limits in Claude Code were increased. Effort control is available on all plans.

    Messages API Update

    The Messages API now accepts system entries inside the messages array. This lets developers update Claude’s instructions mid-task without breaking the prompt cache and without routing the update through a user turn. In practice that means you can update permissions, token budgets, or environment context while an agent is running, which is exactly the kind of statefulness a long-running autonomous process needs. It is a small specification change with significant consequences for how developers build durable agents.

    Pricing and Fast Mode

    Regular usage pricing is unchanged from Opus 4.7: $5 per million input tokens and $25 per million output tokens. The notable shift is in fast mode, where the model works at 2.5x the speed and fast mode is now three times cheaper than it was for previous models, landing at $10 per million input tokens and $50 per million output tokens. The combination of unchanged regular pricing and dramatically cheaper fast mode reshapes the latency-versus-cost calculus that has long governed how teams deploy frontier models.

    Partner Results Across Coding, Legal, Finance, and Data

    Eleven partners shared results spanning the spectrum of professional work. Miguel Gonzalez reports 84% on Online-Mind2Web, a meaningful jump over both Opus 4.7 and GPT-5.5, calling it the strongest computer-use and browser-agent model his team has tested. Databricks reports that Genie reasons over unstructured content like PDFs and diagrams at 61% cheaper token cost than Opus 4.7. Thomson Reuters reports Opus 4.8 is the first model to break 10% overall on the all-pass standard of its Legal Agent Benchmark. Cursor reports gains across every effort level on CursorBench with more efficient tool calling, and Cognition reports that Devin sees cleaner tool use, fixes to the comment-verbosity and tool-calling issues seen with Opus 4.7, and improvements over Opus 4.6. Hebbia reports strong quality with better citation precision and more token efficiency on retrieval for dense financial filings. The footnotes note that Terminal-Bench 2.1 was scored on the Terminus-2 public harness (GPT-5.5’s Codex CLI harness score is 83.4%), that OSWorld-Verified methodology changed with Opus 4.7’s score updated to 82.3%, and that on Finance Agent v2 Gemini 3.5 Flash scores 57.9%.

    What Is Next: Cheaper Models, Higher Intelligence, and Mythos

    Anthropic outlined a three-part roadmap. First, the company is working on models that provide many of the same capabilities as Opus at a lower cost. Second, it plans to release a new class of model with even higher intelligence than Opus. Third, as part of Project Glasswing, a small number of organizations are currently using Claude Mythos Preview for cybersecurity work; models of this capability level require stronger cyber safeguards before general release, and Anthropic expects to bring Mythos-class models to all customers in the coming weeks.

    Notable Quotes

    “Claude Opus 4.8 has noticeably better judgment. In Claude Code, it asks the right questions, catches its own mistakes, pushes back when a plan isn’t sound, and builds up confidence around complex, multi-service explorations before making big changes. It’s a great model to build with.”

    Tom Pritchard, Staff Engineer, in Claude Code

    “On our Super-Agent benchmark, Claude Opus 4.8 is the only model to complete every case end-to-end, beating prior Opus models and GPT-5.5 at parity on cost. For agent products in translation, deep research, slide-building, and analysis, it delivers powerful reliability.”

    Kay Zhu, Co-Founder and CTO, on the Super-Agent benchmark

    “On CursorBench, Claude Opus 4.8 exceeds prior Opus models across every effort level. Tool calling is meaningfully more efficient, using fewer steps for the same intelligence, and it carries end-to-end tasks through.”

    Michael Truell, Co-Founder and CEO, on CursorBench results

    “Claude Opus 4.8 delivers the highest score recorded on our Legal Agent Benchmark, and is the first model to break 10% overall on the all-pass standard. For substantive legal work, that’s the kind of accuracy lift that translates directly into how much real attorney work our customers can hand off with confidence.”

    Niko Grupen, Head of Applied Research, on the Legal Agent Benchmark

    “Claude Opus 4.8 feels like a major quality-of-life update over Opus 4.7: faster, easier to collaborate with, and better at carrying context and style direction across a long session. Opus 4.8 is the model I kept trusting for work where voice, taste, and technical execution all have to happen side-by-side.”

    Katie Parrott, Staff Writer, on long writing sessions

    “Claude Opus 4.8 is the strongest computer-use and browser-agent model we’ve tested, scoring 84% on Online-Mind2Web, which is a meaningful jump over both Opus 4.7 and GPT-5.5. It stays reflective and on-task in the way our customers’ agent workloads need to be reliable end-to-end.”

    Miguel Gonzalez, Tech Lead, on computer-use and browser agents

    “Claude Opus 4.8 uses tools cleanly and follows instructions with the consistency our autonomous engineering workloads need to keep running unattended. It improves on Opus 4.6 and fixes the comment-verbosity and tool-calling issues we saw with Opus 4.7. This release from Anthropic translates directly into faster capability gains for engineers building on Devin.”

    Scott Wu, CEO, on building with Devin

    “On our long-running evals, Claude Opus 4.8’s analysis was consistently higher quality than prior Opus models. It finished faster and produced richer, more information dense outputs. Overall, a noticeably better signal to noise ratio. The biggest differentiator was Opus 4.8’s tendency to proactively flag issues with the inputs and outputs of an analysis, something other models routinely missed and left to the users to catch.”

    Michael Ran, Sr. Investment Associate, on long-running analysis evals

    Claude Opus 4.8 is a quieter release than its “modest but tangible” billing suggests, because the gains land where autonomous work actually lives: a model that flags its own uncertainty, runs longer and checks itself, scales effort on demand, and stays affordable while fast mode gets cheaper. The honesty improvement alone changes the trust math for anyone deploying agents. Read Anthropic’s full announcement here.

    Related Reading