Claude Code workflows with Haiku 5.5: 3.7× cheaper than Opus alone on a 200-file audit, but not faster

The viral "Opus plans, Haiku swarms" tip for Claude Code mostly holds on cost. On a 200-file audit, a workflow that Opus 5.5 wrote and Haiku 5.5 ran cost about USD 0.68 per run, against USD 2.49 for Opus working alone (Claude Code's list-price estimate), roughly 3.7 times cheaper.

It was not faster, though: about 2 minutes 43 seconds against 2 minutes. And Haiku missed one of the 12 bugs we planted, in both runs.

Tested on 18 October 2026 with Claude Code 2.1.302, claude -p on a Windows 11 PC (WSL, Ubuntu 24.04), signed in with a Claude Max plan, main session on Opus 5.5. The code is 200 files from the Python 3.14 standard library with 12 bugs we added ourselves.

At a glance

Key results

• Cheapest: Opus writing a workflow that Haiku 5.5 runs: USD 0.755 and 0.603 in two runs. Opus's own share was USD 0.53 and 0.36; Haiku's was USD 0.22 and 0.25.
• Opus alone: USD 2.52 and 2.47, and it found all 12 planted bugs both times.
• Most expensive: the same kind of workflow with every agent on Opus: USD 7.48 for one run, also 12 of 12.
• Not faster: the Haiku workflow took 161 and 165 seconds wall time, against 122 and 120 seconds for Opus alone.
• One miss: both Haiku runs missed the same bug, a function that returns two values in the wrong order. Opus alone caught it every time.
• More extra flags: the Haiku runs also reported 5 and 9 functions we had not touched; Opus alone reported 0 and 1. Several of those are real stale docstrings in the standard library, not pure noise.

The tip, and what is real in it

On 16 October an X post with about 1,700 likes and 180,000 views called this "the sharpest trick for Claude Code" and credited Anthropic: let Opus 5.5 "write the plan as a script", "swarm the new Haiku 5.5 in parallel", and have Sonnet 5.5 patch the fixes. It linked Anthropic's workflows documentation.

What checks out:

• Workflows are real. Per that documentation, a dynamic workflow is "a JavaScript script that orchestrates many subagents at once", and "a workflow script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer". It is available on all paid plans.
• The split is Anthropic's idea. The Claude Haiku page says "a more intelligent model like Fable or Opus can plan the work and hand off subtasks to Haiku, making it practical to run many agents in parallel". Haiku 5.5 was announced on 7 October 2026 at USD 0.10 per million input tokens and USD 0.50 per million output tokens for prompts up to 100K tokens.
• claude --effort ultracode is a real flag. It turns on workflow planning for the whole session and sets effort to xhigh.

What does not:

• "JEV", which the post says routes "micro-forks in milliseconds", appears nowhere in the workflows documentation or the Claude Code changelog we checked.
• "340 tok/s" for Haiku 5.5 is not on Anthropic's Haiku page, which gives no tokens-per-second figure.
• In claude -p, the ultracode keyword does nothing. The documentation says the keyword only counts in a prompt you type yourself. In a script, ask in plain words ("Use a workflow for this") and allow the Workflow tool.

We tested the scanning half of the tip: Opus plans, Haiku reads. We did not test the "Sonnet patches each fix" half.

Hands-on test

Setup

• Machine: Windows 11 PC, WSL with Ubuntu 24.04 (which has Python 3.12 installed, not 3.14).
• Claude Code 2.1.302, run as claude -p --model opus --output-format stream-json in a clean environment, Claude Max plan.
• Code: 200 .py files picked at random from the Python 3.14 standard library (1.3 MB). In 12 of them we changed one line so that a function no longer does what its docstring says: bisect_left uses <=, queue.Queue.full is off by one, stat.S_ISLNK checks for a regular file, secrets.token_hex uses half the bytes, genericpath.getmtime returns the access time, shlex.join no longer quotes, PurePath.stem cuts at the first dot, sched.empty is inverted, numbers.Complex.__bool__ is inverted, poplib.top swaps its arguments, quoprimime.header_length uses the body table, and ParserBase.getpos returns (offset, lineno).
• Prompt (all setups): audit every file for functions whose code doesn't do what the docstring says, judge only from the code and docstring, don't compare with any other copy of the files, and answer with a JSON list.
• Three setups:
  1. Opus alone: no subagents or workflows allowed (2 runs).
  2. Opus + Haiku workflow: "Use a workflow… Haiku agents read the files in batches of 10 and flag suspect functions, then an independent Haiku agent verifies each flagged function" (2 runs).
  3. Opus workflow: the same workflow wording without naming a model, so every agent ran on Opus (1 run).
• What we measured: planted bugs found (out of 12), other functions reported, wall time, and cost from the final result message (modelUsage), which is Claude Code's estimate at API list prices. On Max nothing is billed per run; the runs count toward the plan's usage limits.

The results

How Opus worked alone: it wrote a short Python script that pulled every function and its docstring out of the 200 files with ast, then read that output in about 10 chunks. That's why it was fast: it never opened the files one by one.

How the Haiku workflow worked: Opus loaded the workflow-writing skill, listed the files, and wrote a script with two phases: 20 Haiku agents each reading 10 files and returning suspects as JSON, then one Haiku verifier per suspect. Opus then read only the verified list, which is the "Opus only sees the final result" part of the tip.

The bug Haiku missed was ParserBase.getpos, whose docstring says "Return current line number and offset" while the code returned (offset, lineno). Nothing looks wrong unless you notice the order.

About the extra findings: we did not change those functions, but several are real mismatches in the standard library. For example, dbm.dumb.open's docstring says other flag values "will default to the semantics of 'c'", while the code raises ValueError for anything other than r, w, c or n. So read "other functions reported" as extra review work, not as a count of false alarms.

What worked

What worked

• The cost split is real. Opus's share of the Haiku workflow runs was USD 0.36 to 0.53, a fifth or less of what Opus spent reading everything itself. Most reading happened on Haiku at a fraction of the price.
• Opus writes a usable workflow from one sentence. Both Haiku runs produced a working two-phase script with JSON schemas and a verifier step, without us writing any JavaScript.
• Opus's context stayed small. The main session saw the file list and the verified findings, not 200 files of source. (For a lighter way to split work in claude -p, see our test of fork subagents; for Haiku against Sonnet on single tasks, see Claude Haiku vs Sonnet.)

Where it fell short

What didn't work

• No speed gain. Wall time went up by about 40 seconds. Twenty Haiku readers plus a verifier per suspect took longer than one Opus session reading a compact dump. We didn't profile why; the extra verify phase and the short start delay the documentation describes for agents sharing a prompt cache are likely parts of it.
• One subtle bug got through, twice. If the bugs you care about are the subtle ones, a cheap first pass needs a stronger second look.
• More to triage. 5 to 9 extra reports per Haiku run against 0 to 1 for Opus alone, even with a verifier agent.
• An all-Opus workflow is the worst of both: about 3 times the cost of Opus alone for the same 12 of 12.
• Watch for shortcuts. In our first attempt, on a laptop with Python 3.14 installed, Opus didn't read the code at all: it diffed the files against the installed standard library and found the 12 changed files in 35 seconds. We threw those runs away, moved to a machine without 3.14 and added the "don't compare with other copies" rule. If you benchmark coding agents, check the tool calls, not just the score.

Our verdict

The tip is right about money and wrong about speed. If you run large read-only sweeps on an API budget or close to a plan's limits, ask Opus to "use a workflow" and put the scan stage on Haiku: in our test that cut the estimated cost by about 3.7 times and kept 11 of 12 planted bugs. If you need every subtle bug, or the result fast, let Opus do it alone; with a smart extraction script it was quicker and missed nothing. Skip the all-Opus workflow for this kind of job. And ignore the parts of the viral post you can't find in Anthropic's documentation.

Frequently asked questions

Does Haiku 5.5 make Claude Code cheaper for big audits?

In our 200-file test, yes: an Opus-written workflow with Haiku 5.5 doing the reading cost about USD 0.68 per run against USD 2.49 for Opus alone, at Claude Code's list-price estimate. It found 11 of 12 planted bugs instead of 12.

Is a Haiku workflow faster than Opus alone?

Not in our test. The Haiku workflow took about 2 minutes 43 seconds; Opus alone took about 2 minutes, because it extracted all functions with one script and read them in a few large chunks.

How do I run a workflow from claude -p?

Ask for it in plain words, such as "Use a workflow for this", and allow the Workflow tool (for example with --allowedTools Workflow). The ultracode keyword is ignored in prompts passed with -p.

What is JEV in Claude Code?

We could not find it. It appears in a viral post about Opus and Haiku, but not in Anthropic's workflows documentation or the Claude Code changelog we checked on 18 October 2026.