Claude Code and OpenAI Codex have both acquired an Ultra mode. From the product label, you could reasonably assume they do roughly the same thing: turn the reasoning dial to maximum and let the coding agent work harder.

They do share that basic idea. Both modes combine a high reasoning setting with permission to delegate work proactively. But their implementations are substantially different.

Claude Code Ultracode is a programmable workflow engine. Claude writes a constrained JavaScript program that describes how agents should fan out, pipeline work, verify one another, and synthesize results. The program runs in a dedicated background runtime with structured outputs, token accounting, concurrency controls, persistence, and resume support.

Codex Ultra is a policy switch over Codex’s native multi-agent system. It maps the visible ultra effort setting to max for the inference request, then injects a developer instruction telling the main agent it may proactively call ordinary spawn_agent tools. Those agents live in Codex’s thread hierarchy, inherit context and tools, can message one another, and can recursively delegate.

One is closer to a deterministic map/reduce runtime for LLMs. The other is closer to taking the safety off an existing distributed-agent system.

This article is based on the implementations rather than launch posts or third-party descriptions. I inspected:

The snapshot matters. Both tools are moving quickly enough that an undated comparison becomes archaeology almost immediately.

The common product idea

At the highest level, the two modes agree on a useful distinction: reasoning effort and orchestration policy are separate controls.

A model can think longer without using subagents. It can also use ten subagents while reasoning shallowly about how their work fits together. Ultra modes try to combine both:

  1. Use the provider’s highest intended reasoning tier.
  2. Let the harness delegate without requiring the user to explicitly request each subagent.
  3. Preserve enough coordination state for the parent to assemble a coherent result.

That is where the similarity ends.

Claude Code UltracodeCodex Ultra
Main reasoningxhighVisible ultra, sent to the model as max
Orchestration mechanismGenerated JavaScript workflowNative agent tools called by the main model
Ultra policyRun workflows for substantive tasks by defaultUse subagents when parallelism materially improves speed or quality
Coordination shapeCentral script, pipelines, barriers, structured returnsHierarchical threads with direct agent messaging
PersistenceContent-pinned scripts, checkpoints, rerunsThread and rollout state
Best fitAudits, broad research, migrations, adversarial reviewInteractive implementation and adaptive delegation

The reasoning labels are not a benchmark. Claude’s xhigh and OpenAI’s max control different models through different APIs. There is no shared scale from which we can conclude that one “thinks harder.” The comparable fact is that each mode selects its provider’s top intended tier while changing the harness’s delegation behaviour.

What Claude Code actually enables

Claude Code’s shipped settings schema describes Ultracode directly:

Enable ultracode for the session: xhigh effort plus standing dynamic-workflow orchestration.

The /effort command similarly reports:

ultracode: xhigh + dynamic workflow orchestration (this session only)

There are two related activation paths:

The distinction matters. A keyword-triggered turn authorizes one workflow. Standing Ultracode changes the default policy for the whole session.

The Workflow tool’s embedded instructions are unusually explicit:

When a system-reminder confirms ultracode is on, that opt-in is standing: author and run a workflow for every substantive task by default.

They continue:

The goal is the most exhaustive, correct answer you can produce — token cost is not a constraint.

This is not merely permission to call Claude Code’s ordinary Agent tool a few more times. It activates a separate orchestration runtime.

Claude’s workflow runtime

A workflow is a JavaScript program authored by the main Claude model and supplied inline to the Workflow tool. Every program begins with a literal metadata declaration:

export const meta = {
  name: 'find-flaky-tests',
  description: 'Find flaky tests and propose fixes',
  phases: [
    { title: 'Scan' },
    { title: 'Fix' },
  ],
}

The runtime exposes a small purpose-built API:

Scripts run in an async context, but they are intentionally not general Node programs. They cannot use filesystem or Node APIs directly. Date.now(), Math.random(), and argument-less new Date() are prohibited because they would make checkpointed execution non-reproducible. Any file inspection or mutation is performed by agents through their normal tools.

The orchestration is deterministic; the model outputs are not. Given the same checkpoint, the runtime knows which phase, item, and script content it is resuming. The agents remain stochastic language models.

Each invocation persists its script under the session directory. Claude can edit that persisted file and rerun it by path. Scripts are content-pinned, so a changed script requires reapproval instead of silently resuming under different code.

Concurrency is also concrete. The shipped instructions state that concurrent agent() calls are capped at min(16, CPU cores - 2) per workflow, with excess calls queued. A workflow can schedule many more total items, and there is a 1,000-agent lifetime backstop intended to catch runaway loops rather than define a sensible fleet size.

That is real orchestration infrastructure, not branding painted onto a larger token budget.

Example: an adversarial code review

Here is a representative workflow Claude could generate in Ultracode. Four agents review a diff independently. Every proposed finding is then sent to another agent whose explicit job is to disprove it.

export const meta = {
  name: 'adversarial-pr-review',
  description: 'Review the current diff and independently verify every finding',
  phases: [
    { title: 'Review' },
    { title: 'Verify' },
  ],
}

const FINDINGS = {
  type: 'object',
  properties: {
    findings: {
      type: 'array',
      items: {
        type: 'object',
        properties: {
          title: { type: 'string' },
          file: { type: 'string' },
          line: { type: 'number' },
          severity: {
            type: 'string',
            enum: ['blocking', 'important', 'minor'],
          },
          explanation: { type: 'string' },
        },
        required: ['title', 'file', 'line', 'severity', 'explanation'],
      },
    },
  },
  required: ['findings'],
}

const VERDICT = {
  type: 'object',
  properties: {
    real: { type: 'boolean' },
    confidence: { type: 'number' },
    reasoning: { type: 'string' },
  },
  required: ['real', 'confidence', 'reasoning'],
}

const lenses = [
  ['correctness', 'Find concrete correctness bugs and regressions.'],
  ['concurrency', 'Find races, deadlocks, and lifecycle bugs.'],
  ['compatibility', 'Find API, packaging, and compatibility breaks.'],
  ['testing', 'Find missing coverage and tests that prove too little.'],
]

phase('Review')

const reviews = await parallel(
  lenses.map(([name, prompt]) => () =>
    agent(`Review the current git diff. ${prompt}`, {
      label: `review:${name}`,
      phase: 'Review',
      schema: FINDINGS,
      effort: 'xhigh',
    })
  )
)

const candidates = reviews
  .filter(Boolean)
  .flatMap(review => review.findings)

phase('Verify')

const verified = await parallel(
  candidates.map(finding => () =>
    agent(
      `Try to DISPROVE this alleged bug by reading the source and tests.

Finding: ${JSON.stringify(finding)}

Return real=false if it depends on speculation, misunderstands an
invariant, or cannot be demonstrated from the code.`,
      {
        label: `verify:${finding.file}:${finding.line}`,
        phase: 'Verify',
        schema: VERDICT,
        effort: 'xhigh',
      }
    ).then(verdict => ({ finding, verdict }))
  )
)

return verified
  .filter(Boolean)
  .filter(result => result.verdict.real && result.verdict.confidence >= 0.7)

The important property is not that this uses many agents. You can manually ask almost any modern coding harness to do that. The important property is that verification is encoded into the execution graph. A first-pass finding cannot survive merely because the parent model found it plausible. It must pass a hostile second inspection with a structured verdict.

Claude’s built-in guidance explicitly recommends this pattern, along with perspective-diverse judges, loop-until-dry searches, multi-modal sweeps, and completeness critics.

Example: competing architectures with blind judges

A second useful pattern separates generating designs from evaluating them. Four architects approach a problem independently. Three judges then examine each proposal through different lenses. A final agent receives both the proposals and the scorecards.

export const meta = {
  name: 'architecture-tournament',
  description: 'Generate competing designs, judge them, and synthesize a winner',
  phases: [
    { title: 'Design' },
    { title: 'Judge' },
    { title: 'Synthesize' },
  ],
}

const problem = args.problem
const constraints = args.constraints || []

const strategies = [
  'Prefer the smallest backwards-compatible change.',
  'Prefer the cleanest long-term architecture.',
  'Optimise for operational safety and rollback.',
  'Challenge the premise and seek a different design.',
]

phase('Design')

const proposals = await parallel(
  strategies.map((strategy, index) => () =>
    agent(
      `Inspect the repository and design a solution.

Problem: ${problem}
Constraints: ${JSON.stringify(constraints)}
Perspective: ${strategy}`,
      {
        label: `architect:${index + 1}`,
        phase: 'Design',
        effort: 'xhigh',
      }
    )
  )
)

phase('Judge')

const judged = await pipeline(
  proposals.filter(Boolean),
  proposal => parallel([
    () => agent(
      `Judge this design for correctness and hidden coupling:\n\n${proposal}`,
      { label: 'judge:correctness', phase: 'Judge', effort: 'xhigh' }
    ),
    () => agent(
      `Judge this design for deployment, observability, and rollback:\n\n${proposal}`,
      { label: 'judge:operations', phase: 'Judge', effort: 'high' }
    ),
    () => agent(
      `Judge this design for implementation and maintenance cost:\n\n${proposal}`,
      { label: 'judge:maintenance', phase: 'Judge', effort: 'high' }
    ),
  ]),
  (scorecards, proposal) => ({ proposal, scorecards })
)

phase('Synthesize')

return await agent(
  `Select or synthesize the best architecture. Reject any proposal with a
credible fatal flaw. Preserve disagreements instead of averaging them away.

Problem: ${problem}
Candidates and judgments: ${JSON.stringify(judged)}`,
  {
    label: 'chief-architect',
    phase: 'Synthesize',
    effort: 'xhigh',
  }
)

This is useful when the solution space is wide. Asking one model to propose an architecture and then “critique itself” tends to anchor the critique on its first answer. Independent generation followed by blind evaluation produces genuine alternatives before convergence.

The same runtime can handle migration work. A discovery agent identifies independent file sets; pipeline() gives each set to an implementation agent in an isolated worktree; a verifier starts as soon as that implementation finishes. There is no need to wait for the slowest migration unit before testing the first completed one.

What Codex Ultra actually does

Codex’s implementation is much smaller and, in a way, more revealing.

The protocol defines Ultra as a reasoning effort alongside the familiar levels:

pub enum ReasoningEffort {
    None,
    Minimal,
    Low,
    Medium,
    High,
    XHigh,
    Max,
    Ultra,
    Custom(String),
}

See openai_models.rs.

Ultra is a harness-level compound mode, not a distinct effort sent unchanged to the model. Codex tests establish that it becomes Max for the actual request:

assert_eq!(
    reasoning_effort_for_request(ReasoningEffort::Ultra),
    ReasoningEffort::Max,
);

The orchestration half is derived separately. With Multi-Agent V2 active, Codex resolves the effective mode from the selected effort:

match turn_context.effective_reasoning_effort() {
    Some(ReasoningEffort::Ultra) => MultiAgentMode::Proactive,
    _ => MultiAgentMode::ExplicitRequestOnly,
}

See multi_agents.rs.

That mode produces a developer message:

Proactive multi-agent delegation is active. Any earlier instruction requiring an explicit user request before spawning sub-agents no longer applies. Use sub-agents when parallel work would materially improve speed or quality.

The exact text lives in multi_agent_mode_instructions.rs.

Codex has tests covering the complete behaviour: an Ultra turn sends max as reasoning effort and contains the proactive delegation instruction. Leaving Ultra appends an explicit instruction revoking proactive delegation, including across a cold thread resume. See multi_agent_mode.rs.

The old API field that selected multiAgentMode directly is now deprecated and ignored. Protocol comments repeatedly tell clients to use Ultra reasoning effort instead. OpenAI has deliberately made “Ultra” the public abstraction and proactive multi-agent behaviour an implementation detail.

Codex’s native agent model

Ultra does not create a new workflow runtime. It changes how readily the main model uses the multi-agent tools already available to it.

Codex’s V2 spawn_agent tool creates a hierarchical task path. If /root/task1 spawns task_3, the child becomes /root/task1/task_3. A spawned agent:

The tool description is visible in multi_agents_spec.rs.

Codex also exposes controls for thread capacity, wait behaviour, subagent instructions, model overrides, reasoning-effort overrides, agent roles, and whether agent metadata appears in the tool schema. Agent state is part of the thread manager and rollout rather than a separate workflow artifact.

The result is a conversational distributed system. The parent can discover a problem, spawn a specialist, keep working locally, receive a message, redirect the child, and spawn a second-generation agent as the task changes. There is no need to decide the complete execution graph up front.

The cost is that complex discipline remains model-mediated. Codex can certainly ask three agents to review a finding and then count votes. But there is no Ultra-specific program enforcing that structure. The parent model must continue choosing the right calls in the right order.

Static graph versus adaptive society

The cleanest way to understand the difference is to ask where coordination lives.

In Claude Ultracode, coordination lives in code. The model decides on a graph, writes a script, and gives it to a runtime. Parallelism, barriers, schemas, token limits, retries, and verification stages are represented explicitly. The graph is relatively stable while that workflow runs, although the main session can inspect its result and launch another workflow for the next phase.

In Codex Ultra, coordination lives in the ongoing model conversation. The parent and children inhabit a task hierarchy and communicate as circumstances change. Delegation is more adaptive, but guarantees are softer because the execution plan remains implicit in model decisions.

Claude’s design is computational: agents are functions producing values inside a program.

Codex’s design is organisational: agents are workers in a hierarchy with shared tools and messaging.

Neither is universally better.

Where Claude’s approach wins

Claude’s workflow runtime is the stronger design for tasks where breadth and independent verification are the point:

Structured schemas are especially important. An agent can be forced to return a validated object rather than prose that the parent later tries to parse. Pipeline stages can begin as soon as individual items are ready. Content-pinned scripts make resume behaviour intelligible.

Claude’s implementation is not just more aggressive. It provides better machinery for proving that an expensive multi-agent run covered what it claimed to cover.

Where Codex’s approach wins

Codex Ultra is better suited to normal interactive development:

Its proactive instruction is restrained: use agents when they materially improve speed or quality. Claude’s standing instruction is substantially more forceful: use a workflow for every substantive task, lean toward adversarial verification, and do not treat token cost as a constraint.

That makes Codex Ultra easier to leave enabled. A three-line mechanical fix is less likely to acquire an architect, two implementers, a review panel, and a completeness critic. Software engineering has enough meetings already.

The cost problem

Claude’s source is refreshingly honest about the economics. The Workflow tool normally requires explicit user opt-in because workflows can spawn dozens of agents and consume large token budgets. Ultracode converts that opt-in into standing permission.

The runtime offers hard token targets through budget.remaining(), but the standing Ultracode instruction itself says token cost is not a constraint. Unless the user supplies a ceiling, exhaustive patterns can become genuinely exhaustive.

Codex Ultra can also consume much more than a normal turn, particularly when agents inherit maximum effort. But its orchestration guidance emphasises concrete, bounded subtasks and material improvement. It does not prescribe workflow use for every nontrivial job.

This difference is policy rather than capability, but policy matters. Models follow the affordances and instructions their harness gives them.

My conclusion

Claude Code Ultracode is the more novel implementation. A constrained, resumable workflow DSL with first-class pipelines, barriers, structured output, isolation, token budgets, and adversarial verification is meaningful engineering. For a hard audit or a high-value architectural investigation, it provides stronger machinery than repeatedly asking a parent agent to remember the next coordination step.

It is also too aggressive as an everyday default. “Workflow for every substantive task” and “token cost is not a constraint” are excellent instructions when the task deserves a small research organisation. Most coding tasks do not.

Codex Ultra is less spectacular but saner to leave on. Maximum model reasoning plus permission for proactive native delegation fits ordinary implementation work. Its agents communicate naturally, its decomposition can change midstream, and the parent can keep the critical path local.

The practical choice is straightforward:

The shared lesson is more interesting than the product comparison. “Reason harder” is no longer the top setting in an agent harness. The top setting now changes the structure of the computation around the model. The next generation of coding tools will compete as much on orchestration semantics as on the model sitting underneath them.