Maxxwell by Rindler
Writing

Running Claude Code, Codex and Cursor together

2026-09-11

Most of us are past the "one prompt, one answer" phase. The problem now is coordinating multiple long-running coding agents without turning yourself into a.

Most of us are past the "one prompt, one answer" phase. The problem now is coordinating multiple long-running coding agents without turning yourself into a full-time air-traffic controller.

This piece compares three ways to run multi-agent coding in practice:

  1. Directly stitching Claude/Codex/Cursor via APIs and scripts
  2. Using their built-in multi-agent features
  3. Putting Maxxwell on top as the orchestrator for all of them

It's about reliability, ergonomics, and how rich your workflow semantics can get before you drown.

What actually changes when you go multi-agent

Anthropic, OpenAI, and Cursor all say the same thing in different words: the work has shifted from "answer this question" to "own this task for hours".

A few numbers to calibrate:

So you run more agents in parallel to get more done, and then you:

That's the real problem: not "can the model code?" but "who owns the loop, and how do you stay in control when there are 6+ loops running?"

Option 1: DIY orchestration with raw APIs and scripts

The purest approach is:

This is effectively what OpenAI calls "owning the loop" with the Responses API.

When DIY works well

DIY is good when:

Example sketch of a minimal orchestrator:

# naive parallel run
for task in "refactor-api" "write-tests" "update-docs"; do
  ./run_agent.sh "$task" &
done
wait

And run_agent.sh might:

#!/usr/bin/env bash
TASK="$1"
python agent.py "${TASK}" logs/"${TASK}".log > runs/"${TASK}".json

You own everything:

Where DIY hurts

The cost is not "it's code," the cost is ongoing orchestration tax.

You eventually end up rebuilding:

And because you wrote it, you get:

You can absolutely solve all of this. The slope is just steeper than most side projects deserve.

For more on why this is happening at all, see the pillar piece on agent-native development: a working definition - this article is the comparison layer on top of that.

Option 2: Native multi-agent features in Claude Code, Codex and Cursor

The big tools now ship their own harnesses. You talk to one product; it spins up multiple agents, runs tools, and gives you PRs, diffs, and logs.

Claude Code

Claude Code is Anthropic's coding workspace. From their own study (~400k sessions, ~235k users):

Mechanically, Claude Code:

You get good ergonomics if you're happy to live inside that environment and its defaults. You don't see a dozen separate terminals; you see one managed session with richer semantics.

OpenAI Codex / Agents SDK

OpenAI has split things cleanly:

The Agents SDK gives you:

It's a nice balance for:

You still write code, but you're writing a workflow around a managed agent, not a bare event loop.

Cursor

Cursor is on the IDE side: heavy focus on multi-agent coding and parallel worktrees. From their public numbers:

Cursor's multi-agent features include:

Their blog explicitly says the interface is agent-centered, not file-centered. The idea: you think "Spin up an agent to fix onboarding flow," not "Open OnboardingForm.tsx."

Limits of vendor-native harnesses

These tools are strong, but they share some constraints:

If you mainly live inside one ecosystem, this is fine. The cracks show when you:

Option 3: Maxxwell as the agent-of-agents

Maxxwell is not another coding agent. It's a workspace that manages your existing agents, Claude Code, Codex harnesses, Cursor agents, or your own CLI tools.

Mechanically:

On top of that sits the orchestrator seat:

So instead of 12 terminals, you have:

Drafts rather than acts

One important property: Maxxwell never acts on your fleet unilaterally.

No silent mutations, no background automation that reconfigures sessions while you're at lunch. This matters if you care about tests, review, and what lands on main.

Reliability semantics instead of vibes

Maxxwell is opinionated about state:

That last part is deliberate. The conducting is real; the autopilot is not.

Persistence without drama

Sessions outlive the app:

That sounds small until you've lost a long-running Cursor agent because of one bad window close.

Local, bring-your-own model

Maxxwell runs locally:

If you're already invested in Claude Code, Codex, or Cursor, Maxxwell is a control plane over them, not a replacement.

Reliability: who drops the ball when sessions pile up

Let's map failure modes.

DIY harness

You own:

If a long-running job stops responding, nothing tells you unless you've built it.

Vendor-native (Claude Code, Codex Agents SDK, Cursor)

You get:

But:

Maxxwell

Maxxwell sits above any of these:

It does not auto-resume, re-aim, or recycle context. It gives you visibility and precise knobs; you remain the pilot.

Ergonomics: how painful is it to keep 8 agents in your head

Ergonomics is where the approaches feel different day-to-day.

DIY

Pros:

Cons:

Claude Code / Codex / Cursor

Pros:

Cons:

Maxxwell

Ergonomic differences:

You still jump into a specific worker when you want deep control, but you don't have to babysit them all individually.

Workflow semantics: from "run this" to "own this loop"

Modern agent tools ship richer semantics out of the box:

OpenAI's Agents SDK has handoffs and agents-as-tools. Anthropic has checkpoints and hooks. Cursor has autonomous cloud agents, remote desktop control, and artifacts.

These are all within one product's world.

Maxxwell's semantics are about coordination across worlds:

It doesn't auto-harden or re-aim a drifted agent for you. It makes cross-agent, cross-tool coordination something you can express in one place without shell gymnastics.

Tradeoff summary: DIY vs vendor harness vs Maxxwell

Here's the short version, with the main axis being who owns orchestration.

If you're running one agent at a time, adding Maxxwell is overhead. Once you're answering questions from 6+ sessions and can't tell what's stuck, that's when a manager agent starts to pay for itself.

Recommendation by use case

"I'm building a custom internal platform"

You're wiring agents into CI, internal dashboards, proprietary tools.

"I live inside one IDE and mostly ship app features"

You're a product engineer; your world is one editor.

"I already have Claude, Codex and Cursor running at once"

You're the target audience of this blog.

That keeps attention as the scarce resource and uses agents to solve that, instead of creating more tabs for you to babysit.

FAQ

How does Maxxwell differ from just spinning up more agents in Cursor or Claude Code?

Cursor and Claude Code run multiple agents inside their own environments. They're great if you mostly live in one tool.

Maxxwell runs above those tools. Each worker session is a real terminal running Cursor, Claude, Codex, or your own agents. You get a fleet view and an orchestrator seat that manages them all without replacing them.

Does Maxxwell automatically fix or re-aim agents that drift off task?

No. Maxxwell does not auto-correct drift, auto-compact context, or restart stalled work.

It:

You stay the one making the call.

Why would I use Maxxwell if I already have a DIY tmux + scripts setup?

If your tmux layout works and you're running a couple of sessions, you're fine.

Maxxwell becomes useful when:

It's basically "tmux + statuses + manager agent," without taking away your existing tools.

Is Maxxwell safe for production repos?

Yes, with the same baseline caveats as any agent in your stack. It runs locally and it doesn't act on your fleet on your behalf.

Anything that would affect your fleet is drafted as a message; you review and send it. Your underlying workers (Claude, Codex, Cursor, etc.) respect whatever permissions and environments you give them.

How does this fit into "agent-native development" as a practice?

Agent-native development treats agents as first-class actors in your system, not just autocomplete. The questions become:

Claude Code, Codex, and Cursor give you agent-native behavior inside their worlds. Maxxwell gives you an agent-native control plane across worlds.

For a deeper dive on the philosophy and patterns, see the main article: Agent-native development: a working definition.