Skip to main content

Ultracode & Effort Levels: Turning Claude Code Up to Eleven

Learn Claude Code's five standard effort levels (low through max) and the separate session-only ultracode mode: how to opt in, monitor workflow cost, and know when to go big.

For most of Claude Code’s history, you had one big dial: which model to use. In the Fable 5 era there’s a second one, and it might matter more day-to-day. For models that support it, /effort controls how hard the model reasons about each step. Ultracode is separate from that five-level model dial: it is a session-only Claude Code mode that combines xhigh with dynamic workflow orchestration for substantive tasks.

This guide covers the five standard effort levels, what ultracode actually changes, the official controls for monitoring and limiting workflow scale, and — just as important — when to leave all of it switched off.


What Effort Actually Controls

/effort sets the reasoning effort for your session. It doesn’t change which model answers you — that’s /model — it changes how much thinking that model spends per step before acting.

The trade is straightforward:

more effort  →  deeper reasoning per step
             →  more tokens, more latency
             →  better answers on hard problems

less effort  →  faster, cheaper turns
             →  perfectly fine for mechanical work

Both /model and /effort can be switched mid-session, but persistence has exceptions: max is session-only unless set through CLAUDE_CODE_EFFORT_LEVEL, and ultracode always resets when the session ends. Set a sensible supported default, then reach for the dial when a specific task deserves more (or less).

If you’re also deciding which model to run, read this alongside our model selection guide — model tier and effort level are two separate dials, and the interesting configurations mix them.

The Five Standard Levels

For effort-capable models, /effort offers five standard levels: low, medium, high, xhigh, and max.

There’s no official per-level spec sheet, and you don’t need one. The useful mental model comes from how effort is used inside multi-agent workflows: cheap, mechanical stages get low effort; hard verification and judgment stages get the high tiers. Apply the same logic to your sessions:

LevelReach for it when
lowMechanical work: renames, formatting, boilerplate, “read this file and tell me X”
mediumEveryday coding: routine features, straightforward fixes
highGenuinely hard problems: tricky debugging, multi-file refactors, design questions
xhighThe hardest judgment work: architecture decisions, adversarial verification, “this must be right”
maxDeepest model reasoning when the additional spend is justified; watch for diminishing returns

Claude Code 2.1.226 lists Fable 5, Opus 5, Sonnet 5, and the previous Opus 4.8 as supporting all five levels. Haiku 4.5 is not listed as effort-capable, so use it without --effort or a workflow effort option. Model visibility and entitlement can differ by provider, plan, account, and rollout; verify the models shown by /model in your environment.

The key shift: for supported models, quality-versus-cost is now a dial you hold, adjustable per session and — as you’ll see below — per individual subagent.

Ultracode: A Session-Only xhigh Plus Orchestration Mode

Ultracode is not a sixth effort level and does not sit above max: ultracode = xhigh effort + dynamic workflow orchestration as a Claude Code session mode.

That second half is what makes it different in kind, not just degree. With ultracode on, Claude Code is instructed to:

  • optimize for the most exhaustive, correct answer — not the fastest or cheapest one
  • use multi-agent Workflow orchestration on every substantive task, not just when you ask for it
  • accept that substantive tasks can use more tokens and take longer

In practice that means a task like “review this diff” stops being one agent reading files and becomes a scripted Workflow: parallel finders fanning out across the change, skeptic agents trying to refute each finding, a synthesis stage assembling what survives. Workflows can spawn dozens of agents and consume large token volumes — which is exactly why ultracode is opt-in. The harness requires you to explicitly request that scale; it will never silently burn a workflow-sized token bill on your behalf.

How to Opt In

Ultracode itself has two activation paths:

  1. The keyword. Include “ultracode” in a prompt for a one-off opt-in:

    ultracode: audit the payments module for correctness bugs

    That single turn runs at full scale. The next turn is back to normal.

  2. The session toggle. Choose ultracode via /effort for a standing opt-in — every substantive task in the session gets the treatment until you dial back down or end the session. Ultracode cannot be saved as the standing effortLevel and resets at session end.

Zoom out one level and workflow orchestration more broadly has a third door: workflows also run when you explicitly ask for one (“use a workflow to…”) or when a skill you’ve invoked instructs it. Without one of those opt-ins — ultracode, an explicit request, or a skill — Claude Code defaults to individual subagents or working solo. Orchestration at scale is always something you asked for.

Cost Controls: Visibility, Warnings, and Size Guidance

Ultracode is an opt-in to more extensive orchestration, not a promise of a fixed spend. The official controls are operational:

  • /workflows shows per-agent token use while a run is active and lets you stop it.
  • A Large workflow warning appears when a run schedules more than 25 agents or projects more than 1.5 million tokens.
  • The Dynamic workflow size setting in /config guides Claude toward fewer than 5, 15, or 50 agents.

The warning and size setting are advisory. Claude Code does not document a +500k prompt directive as a hard ceiling, and workflow scripts do not expose a public budget.total / budget.remaining() enforcement API. For a costly run, start with one directory or a narrow question, inspect the result and token use, then expand deliberately.

Per-Agent Effort: Spend Where Judgment Lives

Inside workflow scripts, reasoning effort is set per subagent: effort: 'low' | 'medium' | 'high' | 'xhigh' | 'max'. This is where the economics of big runs actually get decided. The pattern:

  • cheap mechanical stages (searching, reading, formatting) → low effort on a capable model, or Haiku without an effort override
  • hard verify/judge stages → the high tiers

Here’s a bounded discovery loop that puts both ideas together — cheap finders that stop after two dry rounds, then expensive skeptics on whatever was found. (Workflow scripts open with an export const meta = { ... } literal declaring name, description, and phases; the fragment below is the body.)

phase('Discover');

let dryRounds = 0;
const seen = [];

while (dryRounds < 2) {
  const round = await parallel([
    () => agent(
      `Hunt for correctness bugs in the payments module.
       Already seen: ${seen.join('; ') || 'none'}.
       Report only NEW findings, or the word NONE.`,
      { label: 'hunt-correctness', model: 'haiku' }
    ),
    () => agent(
      `Hunt for error-handling gaps in the payments module.
       Already seen: ${seen.join('; ') || 'none'}.
       Report only NEW findings, or the word NONE.`,
      { label: 'hunt-errors', model: 'haiku' }
    ),
  ]);

  const fresh = round.filter(Boolean).filter(r => !r.trim().startsWith('NONE'));
  if (fresh.length === 0) dryRounds += 1;
  else { dryRounds = 0; seen.push(...fresh); }
}

phase('Verify');

const verdicts = await parallel(
  seen.map(finding => () => agent(
    `Try to REFUTE this finding. Confirm only if you cannot:
     ${finding}`,
    { label: 'skeptic', effort: 'xhigh' }
  ))
);

Notice the shape of the spending: the loop that might run many rounds uses Haiku without an effort override, while xhigh is reserved for the verification stage where a wrong call actually costs you. The finders are told what’s already been seen so they don’t resell old findings, and the loop only stops after two consecutive empty rounds — the “loop-until-dry” pattern covered in depth in the effort and ultracode tutorial and its companion on quality patterns.

When NOT to Use Ultracode

The failure mode of a powerful dial is leaving it turned up. Skip ultracode for:

  • Trivial edits. A rename, a typo fix, a config tweak needs one agent and low effort. Spawning an orchestrated workflow for it is pure waste.
  • Conversational turns. “What does this function do?” or “which approach do you prefer?” are answered from context. There is nothing to fan out.
  • Single-fact lookups. If you know which file holds the answer, a direct read beats any delegation.
  • Anything where you want fast iteration. Ultracode optimizes for exhaustive and correct, which is the opposite of a quick feedback loop while you’re still sketching.

Rule of thumb: ultracode is for tasks where missing something is expensive and the search space is bigger than one agent’s context. Everything else runs better — and dramatically cheaper — at normal effort. For the broader cost picture, see the cost optimization tutorial.

Three Recipes

The audit. ultracode: audit the auth module for security issues. This is ultracode’s home turf: broad discovery where completeness matters. Start with a bounded scope, use the loop-until-dry shape from the snippet above, adversarially verify every finding, and report any coverage limits explicitly.

The migration. ultracode: migrate every deprecated API call in src/ to the new client. Agents that mutate files in parallel need isolation: 'worktree' on their agent() calls — each gets a fresh git worktree so they can’t trample each other, auto-removed if unchanged. Worktrees cost real setup time and disk per agent, which is exactly the kind of scale you’re consenting to when you type the keyword.

The research sweep. ultracode: map every place we handle currency rounding, and how. A multi-modal sweep — parallel agents each searching a different way (by file location, by content, by entity, by time) — followed by a completeness critic asking “what’s missing?” whose answers seed the next round. Haiku can sweep without an effort override, or an effort-capable economical model can use low effort; the final synthesis gets the expensive treatment.

The Takeaway

Effort levels turned answer quality into something you control per task on models that support the dial. Ultracode remains a separate session-only mode: xhigh reasoning plus standing workflow orchestration, gated behind explicit opt-in because it can spend substantially more time and tokens. Cost control comes from scope, size guidance, live visibility, and the ability to stop a run — not from an undocumented hard token ceiling.

The skill worth building isn’t “always use ultracode” — it’s knowing which of your tasks are dial-worth-turning tasks. Audits, migrations, and research sweeps, yes. The typo you’re about to fix, no.


Want to go deeper? The Effort Levels & Ultracode tutorial covers the verified cost controls, and What Is a Workflow? explains the orchestration layer ultracode is built on.