Claude Code v2.1.160 renamed the `workflow` trigger to `ultracode`. Every scripted prompt that contained it just regressed.

Claude Code v2.1.160 quietly renamed the workflow keyword to ultracode. If you've scripted prompts, your agents just changed behavior overnight.

The v2.1.160 changelog landed at 02:10 UTC on June 2. Forty-something line items. Most of them are the usual: WSL fixes, IME redraw bugs, a vim p paste fix. Buried in the middle, no version-bump fanfare, no migration note, no Anthropic blog post:

Renamed the dynamic-workflow trigger keyword from workflow to ultracode. The word "workflow" no longer triggers a run; asking for one in your own words still works. The trigger keyword is highlighted in violet in the prompt input.

If you have shipped a prompt template, a CLAUDE.md, a slash command, or a CI script in the last two months that contains the literal word workflow, your agents are not doing what they did yesterday. There is no compatibility shim. There is no deprecation period. There is one line in a patch release.

Here's what actually broke. Who's quietly running degraded for the next two weeks. And the migration you do before standup tomorrow.

What v2.1.160 actually changed

The rename is one of three things shipped together that you need to read as a single move:

1. The trigger keyword for dynamic workflows — Anthropic's preview feature that fans out hundreds of parallel subagents — switched from workflow to ultracode. The match is exact-token. If your prompt says "set up the workflow for the bootstrap script," you are no longer opted in. You get a single-agent run with no fan-out.

2. The fallback path didn't go away. The release note's second sentence — "asking for one in your own words still works" — means the classifier that decides whether to spawn subagents is still listening. If your prompt says "fan out the linter across all packages," you still get the dynamic-workflow path. The keyword was a fast-path trigger. The slow path is still alive.

3. The same release adds a /config setting called "Workflow keyword trigger" that lets you turn the word workflow back into a normal word. Anthropic added a backstop for the small fraction of users who want to keep the old behavior — but the default is the new behavior. The default is the breaking change.

And a fourth thing, two releases earlier in v2.1.158: /effort ultracode is the new way to manually request dynamic workflows from any prompt. The CLI surface and the prompt surface are converging on the same name. "workflow" is being removed from the vocabulary of the dispatch layer because it conflicts with the English word "workflow" — which a developer might just be talking about, like "our CI workflow" — and was generating false positives.

That is the actual problem the rename solves. It is not arbitrary. It also is not free for anyone who already adopted the keyword.

If you ship X, this is you

The regression class is narrow and specific. You are affected if any of the following are true:

• You have a CLAUDE.md, a slash command, or a saved prompt template that contains the literal word workflow and you relied on it to trigger fan-out
• You have a CI job that pipes a prompt to claude --bg with workflow in the text — your nightly large-codebase migration is now single-threaded
• You have a team runbook that documents "type workflow to spin up parallel subagents" — your onboarding doc is wrong as of today
• You wrote a blog post or shared a prompt on X in May that used the keyword — anyone copy-pasting it is silently degraded
• You have a billing dashboard that shows a sudden drop in tokens-per-prompt on June 2 — your team is using fewer subagents because the fast path stopped firing

The class that is not affected:

• Anyone who said "fan out N agents to do X" in plain language — the classifier still catches you
• Anyone using /effort ultracode explicitly — that was already the new name
• Anyone who has the auto mode classifier on and lets it pick — it will still spawn the workflow when the task warrants it

Practical: grep your repo for \bworkflow\b in any prompt-shaped file before EOD. If it shows up in something an agent reads, decide whether you want the old behavior or not.

The failure mode is silent. You don't get an error. You get a slower, cheaper, less parallel run. Which sounds fine — until the migration that used to finish in 18 minutes takes 4 hours because it's now sequential. And until the cost report at the end of the month shows a number that doesn't match the work you did, because half your prompts dropped to single-agent mode and the other half hit the classifier and went the expensive way.

The specific class of team that gets hurt the worst: enterprise teams who locked in a prompt template six weeks ago, shipped it to 200 engineers via a managed CLAUDE.md, and put a CI gate on top to ensure consistency. Those teams cannot just edit the template — they have to push it through review, ship a new version, and verify the rollout. The lag between v2.1.160 dropping and that template being patched is the window where the regression is real, observable, and unfixable in the moment. The smaller team that maintains its own CLAUDE.md will patch it in 20 minutes. The 200-engineer team will patch it in two weeks.

The mechanism — why the keyword existed and why it had to die

Dynamic workflows are not a model feature. They are a dispatch feature. When Claude Code reads a prompt, it runs the text through a fast classifier that decides one thing: should this run spawn the parallel-subagent harness, or should it run as a single agent? The classifier has three inputs:

1. The presence of the trigger keyword in the prompt — fast path, ~zero latency
2. The semantic intent of the prompt — slower path, model-based classification
3. The /effort setting and any explicit --ultracode flag on the CLI

The trigger keyword exists because the model-based classifier is not cheap. Running it on every single prompt — including the 90% of prompts that are "explain this file" or "fix this typo" — would add latency and cost to the dispatch layer that's hard to amortize. The keyword is a shortcut. If the prompt literally says workflow, skip the classifier and go straight to the fan-out path.

Here's what the dispatch logic looks like in pseudocode:

def dispatch(prompt: str, effort: str, flags: dict) -> AgentMode:
    if flags.get("ultracode") or effort == "ultracode":
        return AgentMode.DYNAMIC_WORKFLOW

    if has_trigger_keyword(prompt):
        return AgentMode.DYNAMIC_WORKFLOW

    intent = classify_intent(prompt)
    if intent.score > 0.85:
        return AgentMode.DYNAMIC_WORKFLOW

    return AgentMode.SINGLE_AGENT

The has_trigger_keyword step used to match workflow. As of v2.1.160 it matches ultracode. The classifier step still catches plain-English requests. So the fan-out doesn't disappear — it just costs one classifier call per ambiguous prompt instead of being free for prompts that used the keyword.

Why did the keyword have to change? Because "workflow" is one of the most overloaded words in software engineering. "Our CI workflow," "the GitHub Actions workflow," "the user onboarding workflow," "my dev workflow this week." Every time a developer typed any of those into Claude Code, the fast path fired and the dispatcher spawned subagents the user didn't ask for. That is a billing problem and a correctness problem. The fix is a keyword the developer would never accidentally type — ultracode — combined with the violet highlight in the prompt input so the user sees the trigger fired before sending.

The violet highlight matters more than it looks. In v2.1.157 and earlier, the trigger was invisible until the run started. You couldn't tell from the input whether you were about to spawn 1 agent or 200. v2.1.160 fixes that with a colored token in the input itself — the kind of UI affordance that should have shipped with the original keyword and didn't. If you're paying for the SKU, you want to see the trigger before you hit enter.

A secondary mechanism shipped in the same release that's worth flagging: the Edit tool no longer requires a separate Read after viewing a file with grep. Single-file grep/egrep/fgrep commands now satisfy the read-before-edit check. For a workflow that fans out 200 subagents to grep-then-edit across a codebase, this removes one full read roundtrip per subagent. On a 200-file migration that's 200 fewer model calls, which is real money at fan-out scale. The two changes — keyword rename and grep-satisfies-read — read as a single move to make the fan-out tier cheaper to run.

This is a good change. It is also a breaking change.

The opposing view — "this is a non-event, the classifier still works"

The pushback you'll see in the next 48 hours from people defending the rename: the classifier still catches plain-English requests, so the user experience is unchanged for anyone who wasn't being weirdly literal. From Anthropic's docs:

Dynamic workflows can be triggered three ways: the keyword in your prompt, the /effort ultracode setting, or asking for parallel work in your own words.

The argument: if you wrote "workflow X" in your prompt template, you were doing it wrong. You should have written "fan out subagents to do X" because that's what you meant. The keyword was always a power-user shortcut, not a contract.

I don't fully buy it. The keyword was documented. People built on it. The classifier path is not free — it adds 200-400ms to every prompt that doesn't use the fast path, and the false-negative rate on the classifier is real. Anthropic does not publish the classifier's recall numbers because they shift week-to-week as the model updates. If your prompt says "refactor every component to use the new auth hook" and you assume that triggers fan-out, you are betting on a classifier hitting the right threshold. That's a worse contract than the keyword.

There's a second pushback worth naming: the new keyword ultracode is itself overloaded — it's also the name of the /effort level, the CLI flag, and probably a future config namespace. Anthropic is reusing one identifier for four surfaces. That's elegant from a naming-consistency standpoint and a footgun from a debugging one. When someone asks "why did my prompt fan out?" the answer is now "because one of four things named ultracode fired" instead of "because the keyword matched."

The right read: the rename is a net positive, but the cost is paid entirely by early adopters who built on the old keyword. There is no migration tool, no warning when the old keyword appears, no telemetry to tell you when your prompt regressed. You are the migration tool.

The playbook — what to do today

Four steps. Two should be done before lunch.

1. Audit your prompt surface

Run this in every repo that talks to Claude Code:

rg -i --type-add 'prompt:*.{md,mdx,txt,prompt}' -t prompt -t yaml -t json \
  '\bworkflow\b' \
  --glob '!**/node_modules/**' \
  --glob '!**/.git/**' \
  | grep -iE '(claude|agent|prompt|skill|command)'

This catches the literal word workflow in any file shaped like a prompt template, slash command, or skill. Filter by context — most matches will be the English word, not the trigger keyword. The ones in a prompt-shaped file next to a Claude-related token are the ones you migrate.

2. Decide per-match: keep fast path, drop to classifier, or invert

For each match, you have three choices. Write down which one you picked next to the line you change:

• Keep fast path — replace workflow with ultracode. The trigger fires the same way, just under a new keyword. Use this when you want the deterministic fan-out behavior the old keyword gave you.
• Drop to classifier — delete the keyword and rewrite the prompt to ask for parallel work in plain English. Use this when you're not sure the fan-out was ever the right call and you want the classifier to decide per-run.
• Invert — turn workflow into a normal word and disable the trigger via /config. Use this when you have a prompt template that was accidentally firing the fast path and you want it to stop.

3. Pin the /config setting on your shared template

The new /config setting — "Workflow keyword trigger" — defaults to off (because the keyword is now ultracode). But if your team standardized on the old keyword and you want to give yourselves a 30-day grace period, you can turn it back on. The setting is per-install, not per-prompt, so it lives in ~/.claude/settings.json:

{
  "trigger": {
    "workflow_keyword": true
  }
}

This is a band-aid. Anthropic will not maintain this toggle indefinitely. Use it to buy two weeks of migration time, not as a permanent setting.

4. Update your runbooks and onboarding docs

Grep your internal docs — Notion, Confluence, your README, your CLAUDE.md — for the phrase "type workflow." If new hires read that doc in the next 30 days, they will type the wrong keyword and wonder why their fan-out doesn't fire. The cost of a stale onboarding doc here is hours of confused debugging per new hire. The fix is a search-and-replace and a one-line note explaining why the keyword changed.

5. Add a smoke test for the trigger you care about

The migration is reversible if you catch it early and unrecoverable if you don't. The cheapest insurance is a one-shot smoke test that runs Claude Code against a known prompt and checks whether a fan-out happened. You don't need a test framework — three lines of bash:

#!/usr/bin/env bash
set -euo pipefail
out=$(claude --print --json \
  'ultracode: list every .ts file under src and report its line count' 2>&1)
echo "$out" | jq -e '.subagent_count > 1' >/dev/null \
  || { echo "FAIL: fan-out did not trigger"; exit 1; }
echo "OK: fan-out fired with $(echo "$out" | jq .subagent_count) subagents"

Run it on every Claude Code upgrade. The cost is one extra prompt per release. The benefit is you find the next silent rename within 10 seconds of installing the new version instead of within 10 days of your monthly bill.

Practical: if you maintain a public prompt-engineering blog post that used the keyword, update it. Readers copy-pasting your snippet will silently regress.

When it breaks

The three failure modes you'll see in the next two weeks:

• Silent slowdown — your nightly CI migration job that used to fan out across 200 files now runs sequentially because the keyword stopped triggering. Symptom: the job suddenly takes 4-5x longer with no error. Detection: compare wall-clock duration of the same job pre- and post-June 2.

• Cost increase from classifier latency — every prompt that doesn't use the new keyword now pays for the classifier roundtrip. For a team running 10K prompts/day, that's 10K extra classifier calls per day. Not catastrophic, but visible on a usage dashboard. Detection: per-prompt latency p50 ticks up by 200-400ms on dispatch.

• Onboarding regression — new hire follows the team's CLAUDE.md, types workflow, gets single-agent behavior, asks the team why fan-out doesn't work, the team assumes they're using the CLI wrong. Detection: someone files a "Claude Code is broken" ticket internally and the answer is "your prompt template is stale."

• Stale benchmark numbers — anyone who ran a benchmark in May with workflow in the prompt and is comparing to a June run with the same prompt is comparing two different code paths. The old number is dynamic-workflow throughput, the new number is single-agent throughput. The comparison is meaningless. Detection: a benchmark regression that doesn't match the model release notes, with no obvious cause in your config.

• CI cost spike from classifier fallback — for teams that didn't migrate but kept their prompts, every prompt now pays for the classifier roundtrip and sometimes gets the fan-out anyway. The bill goes up because both paths are firing — keyword fallback miss plus classifier hit — and neither one was budgeted for. Detection: token spend rises 5-15% on the same workload week over week, with no change in repo size or PR count.

The second one will hit hardest at companies that put Claude Code on a shared budget. The dispatch-classifier path is real money over a quarter — for a 50-person engineering team running ~30K prompts/day, the classifier latency alone costs an extra 100-300 GPU-seconds per day, and the false-negatives on the classifier mean some fan-out runs you wanted simply don't happen. You can't audit what didn't fire.

The non-obvious takeaway

The rename is a load-bearing signal about where dynamic workflows are going. The keyword changed because Anthropic is consolidating the dispatch surface around ultracode — the /effort ultracode flag, the ultracode keyword, the --ultracode CLI flag, and a future ULTRACODE.md file are converging on one identifier.

The bet I'll write down today: by the end of 2026, ultracode will be the public name of the entire fan-out tier, with its own pricing surface separate from the per-prompt token meter. Dynamic workflows are too expensive and too unpredictable to keep on the same billing line as single-agent runs. Anthropic needs a SKU. They are building the vocabulary for that SKU right now, one keyword at a time.

Three signals support the bet. First, the /effort levels have always been an analog dial — low, medium, high, xhigh — and ultracode is the first level that doesn't fit on that dial. It's not "more reasoning," it's a different runtime. That's a SKU shape, not an effort shape. Second, the v2.1.160 patch quietly added a guard — "ultracode is no longer offered on models that do not support it" — which means the tier is becoming a capability gate, not a setting. Tiers get billed. Settings don't. Third, the violet highlight in the prompt input is the kind of UI you build when you want users to know before they hit send that they're about to spend more. You don't add that affordance for a free feature.

If I'm right, anyone who built tooling around the word workflow is going to migrate again in 90 days when the billing layer follows. The cost of moving now to ultracode is one search-and-replace. The cost of moving twice is double that plus the confusion of explaining to your team why the keyword keeps changing. And the team that already standardized on ultracode in their CLAUDE.md gets to skip the conversation entirely when the bill arrives.

If I'm wrong, the worst case is you typed a slightly weirder keyword for a quarter and Anthropic walks it back. That asymmetry is why the migration is worth doing this week instead of waiting. The cost of being early is zero. The cost of being late shows up on a billing dashboard you didn't budget for.

This week

Three concrete things to do before Friday:

1. Grep every prompt-shaped file in every repo for \bworkflow\b and decide per-match: rename to ultracode, drop to classifier, or invert via /config. Don't batch this — do it the same day you upgrade past v2.1.160.

2. Add a one-line note to your team's CLAUDE.md explaining that the trigger keyword changed in v2.1.160. Two sentences max. Future-you and every new hire will save an hour each time they hit it.

3. Diff your token-usage dashboard for June 2 vs June 1. If you see a sudden drop in tokens-per-prompt or in the count of subagent spawns, your team's prompt templates regressed and nobody told you. Find the regressed template and migrate it before the next billing cycle hides the signal in the noise.

The keyword changed. The cost of ignoring it is silent and small and adds up to a quarter of degraded fan-out runs nobody flagged. The cost of fixing it is one search-and-replace and a runbook update. Do it today.