Diogo Soares

Posted on Nov 2 Edited on Nov 2

The Hidden Cost of Running Multiple AI Coding Agents

#git #ai #productivity #programming

My terminal has several AI coding agents running. One is adding a feature in a side project, another is writing tests in a second repository, a third is reviewing a branch. Every pane is moving, and it looks like a lot of work is getting done.

Then the panes stop, one after the other, with the same kind of message: usage limit reached. The work doesn't fail. It just waits, until the window resets or until I decide to pay for more.

I use Claude Code on a Claude Pro plan and OpenAI Codex on ChatGPT Plus, two subscriptions of $20 a month each in the US (billed monthly), plus tmux, Git worktrees, subagents, Agent Teams and Orca. That combination raised a question I couldn't answer from the feeling of speed: are parallel AI agents making me more productive, or am I just reaching my subscription usage limits faster?

This post is my answer, built from the official docs of both tools and the research on AI coding productivity:

What a Claude Pro and a ChatGPT Plus plan actually give you, and what they don't promise.
Single agent, tmux sessions, subagents and Agent Teams compared, with diagrams.
A tested tmux + Git worktree workflow, and where Orca fits.
A way to measure it on your own plans, with the metrics that matter.
A decision framework and a list of habits that make a $20 plan last.

One idea runs through all of it: more generated code is not more delivered software.

The illusion of infinite productivity

Running four agents feels four times faster. It isn't, and the reason is in three words people use as synonyms.

Term	What it measures	What parallel agents change
Throughput	Work items completed per hour (here: code generated, not yet reviewed)	Can increase for independent tasks, but coordination and resource limits may reduce the gains
Latency	Time from "start this task" to "this task is done"	Can go down for independent tasks, up for dependent ones
Productivity	Verified, merged, working features per unit of your time and budget	Unknown until you count review, rework and waiting

At best, parallel agents raise throughput of generated code. Productivity only counts code that passed tests, survived review and merged. Everything between those two numbers is work that lands on you: reading diffs, resolving conflicts, re-explaining context, and waiting for a reset.

There is research on how unreliable the feeling of speed is. In METR's 2025 randomized controlled trial, 16 experienced open-source developers worked on 246 real issues from their own repositories. With AI tools allowed, they took 19% longer. Before the study they expected a 24% speedup, and afterwards they still believed AI had made them about 20% faster.

That result has limits that matter. It used early-2025 tools (mostly Cursor with Claude 3.5 and 3.7 Sonnet), large mature codebases and a small sample. In a February 2026 update, METR said developers are probably more sped up now, but its new data is "only very weak evidence" of how much, partly because many developers refused to work without AI. So the study is not evidence that AI makes you slower. Its useful lesson here is simpler: your sense of speed is not a measurement.

Google's DORA team points in the same direction from a different angle. The 2024 report associated higher AI adoption with better documentation and code review speed, but also with an estimated 1.5% drop in delivery throughput and 7.2% drop in delivery stability. The 2025 report sums it up as AI being an amplifier of what a team already does well or badly.

What Claude Pro and ChatGPT Plus usage limits actually give you

Before comparing workflows, get the budget right. Neither vendor sells you a fixed number of tokens, and several different limits get mixed up in discussions online.

Limit	What it is	Claude Pro	ChatGPT Plus (Codex)
Session window	Usage allowed inside a five-hour period	Five hours, starting with your first message (source)	Five hours, published as ranges of local messages per model (source)
Weekly limit	A second cap over the week	Yes, across all models, reset at a fixed time per account	"Weekly limits may also apply"
Shared pool	What draws from the same budget	claude.ai, Claude Code and Claude Desktop	Local messages and cloud tasks
Published allowance	A guaranteed token count	None; "the number of messages you can send will vary" (source)	Ranges, explicitly "not fixed message limits"
Paying for more	When the plan runs out	Optional usage credits, prepaid, billed at standard API rates (source)	Optional credits, or an API key billed at API rates
Context window	How much one conversation can hold	A model property and a separate limit, though a fuller context costs more quota per turn	Same: a separate limit, but more context means more usage
How to check	Remaining usage	`/usage` in Claude Code, Settings > Usage	`/status` in the CLI, the Codex usage dashboard

Prices and ranges are as of November 2026. Three details change how you should work.

The pool is shared. Every Claude Code session in every tmux pane, every subagent and every chat on claude.ai draws from the same Pro budget. Ten terminals are not ten budgets. On the OpenAI side, local messages and cloud tasks share one allowance too, and the docs warn that cloud tasks "may use more of your allowance than local messages".

Usage is not message count. Anthropic says usage depends on the length and complexity of the conversation, the features you use, the model and the effort level. Its Claude Code guide adds the part most people miss: every turn resends the conversation so far, plus CLAUDE.md and the files Claude has read, before your new prompt. A long session gets more expensive per message as it grows.

Model choice is the biggest lever you control. OpenAI publishes it plainly. On Plus, the heaviest model in the Codex table allows 5 to 45 local messages per five hours, and the lightest allows 350 to 3,000. The published ranges for the two ends of the table differ by about two orders of magnitude, and OpenAI says they vary by task, so read them as a direction, not a conversion rate. Anthropic doesn't publish numbers, but says Opus "uses meaningfully more of your quota" and that Sonnet is the right choice for most coding work.

Two traps to avoid. API prices are not the price of subscription usage; they only apply when you turn on usage credits or use an API key. And if ANTHROPIC_API_KEY is set in your shell, Claude Code uses that key instead of your subscription, which can turn an evening of "free" agents into an API bill.

One agent vs multiple agents

There are four architectures in my day-to-day, and they behave very differently on tokens, context and review.

flowchart LR
  subgraph A["A. Single agent"]
    D1([You]) --> S1[One session]
  end
  subgraph B["B. tmux sessions"]
    D2([You]) --> P1[Claude Code: project 1]
    D2 --> P2[Codex: project 2]
    D2 --> P3[Claude Code: project 3]
  end
  subgraph C["C. Subagents"]
    D3([You]) --> M[Main session]
    M --> SA1[Explore]
    M --> SA2[Test runner]
    SA1 -. summary .-> M
    SA2 -. summary .-> M
  end
  subgraph D["D. Agent Team"]
    D4([You]) --> L[Lead]
    L --> T1[Teammate 1]
    L --> T2[Teammate 2]
    T1 <-. messages .-> T2
  end

A. A single agent

One Claude Code or Codex session working through tasks in order. It has the best context continuity: the agent remembers why a decision was made, and you review one stream of changes. Debugging is simple because there is one author.

It isn't automatically the most token-efficient option, though. Because every turn resends the whole conversation, a session that carries three unrelated tasks pays for the history of the first two while working on the third. Anthropic's own best practices say /clear between unrelated tasks "costs nothing" and stops the next task from paying for the previous one. A single agent is efficient when its context is relevant, not when it is long.

B. Multiple tmux sessions across projects

Independent agents on independent projects. This is the cleanest form of parallelism: no shared files, no merge conflicts, and each agent has a small, relevant context.

Two limits still apply. All the Claude Code sessions share one quota, so parallelism spends your five-hour window faster; it doesn't create more of it. And the scarce resource moves to you: each pane eventually asks a question, needs a decision or produces a diff to review. tmux keeps the sessions alive and organized. It does nothing for token consumption.

This is also where mixing providers is a real advantage. Claude Pro and ChatGPT Plus are two separate pools. Putting one project on Claude Code and another on Codex is the only way in this post to get more included allowance without upgrading a plan or paying API rates for credits.

C. Subagents inside one project

A parent session delegates a bounded job to a subagent. In Claude Code, each subagent runs in its own context window, and only its result returns to the main conversation. The built-in Explore subagent, for example, is read-only and made for searching a codebase.

The common misunderstanding is that subagents save tokens. They save context, which is different. The docs say each subagent sends its own requests, which "count toward the same usage limits as your main conversation". What you gain is a main session that stays short and focused, because 40 files of search results never enter it. Codex says the same about its own subagents: they "consume more tokens than comparable single-agent runs" (source).

A real example from this post. To research it, I delegated the documentation reading to Claude Code subagents (Claude Code 2.1.308): five of them read the Anthropic help center, the Claude Code docs, the Codex docs, Orca's docs and the productivity studies in parallel, and all came back in under two minutes. Claude Code reported about 430,000 tokens across those five. That's a token total, not a share of my quota, which neither tool exposes as a number. That's the ideal case for subagents: read-only, independent, verbose work. It still needed checking: one later verification pass found that an earlier subagent summary had marked a sentence as missing from a doc page when it was there.

Subagents pay off for narrow, verbose, read-heavy tasks: exploring a codebase, running a test suite and summarizing failures, reviewing a diff. They pay off more with a cheaper model; Claude Code lets you set model: haiku on a simple subagent.

D. Agent Teams

Agent Teams in Claude Code are experimental and off by default (you enable them with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). A lead session coordinates separate Claude Code instances that share a task list and message each other directly. Subagents return their result to the caller. One catch if you use both: while Agent Teams are enabled, a subagent that Claude names launches as a teammate, so a team, with team-level token costs, can form when you only asked for delegation.

The docs are direct about the cost. Agent Teams "use significantly more tokens than a single session", usage scales with the number of active teammates, and the costs page estimates about 7x the tokens of a standard session when teammates run in plan mode. The same docs say that for sequential tasks, same-file edits or work with many dependencies, a single session or subagents are more effective.

Anthropic's engineering team found the same pattern outside Claude Code. Its multi-agent research system used about 15 times the tokens of a chat, worked best on breadth-first research, and the post notes that "most coding tasks involve fewer truly parallelizable tasks than research".

	Single agent	tmux sessions	Subagents	Agent Team
Context	One, continuous	One per project	Isolated per task, summary returns	One per teammate
Tokens vs one session	Baseline	Sum of sessions, same pool	Higher, but the main context stays small	Highest, scales with teammates
Coordination	None	You	The main agent	Lead, task list, messages
Merge conflicts	None	None across projects	Low if subagents only read	Possible on shared files
Best for	Dependent, sequential work	Unrelated projects	Search, tests, review	Research, competing hypotheses, cross-layer work with clear ownership

tmux, Git worktrees and multi-agent IDEs

When you want two agents on the same repository, they need separate checkouts, or they'll edit the same files under each other. Anthropic's docs put it simply: give each piece of work "its own checkout so the edits can't collide". Git worktrees are the standard way to do that: each worktree is a separate directory, on its own branch, sharing one repository.

Here is the workflow I'd use. I ran the git and tmux commands in a scratch repository with git 2.54 and tmux 3.8, with the agent commands replaced by echo so no usage was spent (the git pull and npm ci lines need a real remote and project, so they didn't run there):

# From the main checkout, with an up-to-date main
git switch main && git pull --ff-only

# 1. One worktree and one branch per independent task
git worktree add -b feat/rbac ../app-rbac main
git worktree add -b feat/audit-log ../app-audit main

# 2. Worktrees are fresh checkouts: no .env, no node_modules.
#    Start from the committed template, never your real .env, then give
#    each worktree its own dev-only database and no production secrets.
cp .env.example ../app-rbac/.env && cp .env.example ../app-audit/.env
createdb app_rbac && createdb app_audit
perl -pi -e 's|^DATABASE_URL=.*|DATABASE_URL=postgres://localhost:5432/app_rbac|' ../app-rbac/.env
perl -pi -e 's|^DATABASE_URL=.*|DATABASE_URL=postgres://localhost:5432/app_audit|' ../app-audit/.env
(cd ../app-rbac && npm ci) && (cd ../app-audit && npm ci)

# 3. One tmux session, one window per agent
tmux new-session -d -s agents -n rbac -c "$PWD/../app-rbac"
tmux new-window -t agents -n audit -c "$PWD/../app-audit"
tmux send-keys -t agents:rbac 'claude "Implement docs/tasks/rbac.md. Run npm test before you stop."' Enter
tmux send-keys -t agents:audit 'codex "Implement docs/tasks/audit-log.md. Run npm test before you stop."' Enter
tmux attach -t agents

Each task description lives in a file in the repository, so both agents start from the same written requirements instead of a prompt you typed differently twice. The second window runs Codex on purpose. One practical detail: the first time you run claude in a new directory it asks you to trust the folder, so attach to the session and accept it before the prompt runs.

Then review and merge like you would a colleague's branch:

git log --oneline main..feat/rbac          # what the agent committed
git diff --stat main...feat/rbac           # how big the change is
(cd ../app-rbac && npm test)               # run the checks yourself
git switch main && git merge --no-ff feat/rbac

# Cleanup, only after the merge and once nothing in the worktree still matters
git -C ../app-rbac status --short --ignored   # lists what removal would touch
git worktree remove ../app-rbac            # fails on modified or untracked files
git branch -d feat/rbac                    # fails if the branch isn't merged
dropdb app_rbac                            # the worktree's own dev database
# Repeat for feat/audit-log, ../app-audit and app_audit, then:
tmux kill-session -t agents

In my test, git worktree remove refused to delete a worktree with an untracked file until I passed --force, and git branch -d refused to delete a branch still checked out in a worktree. Keep those guards, and know their gap: gitignored files don't count, so node_modules and a .env you edited inside a worktree are deleted without a warning. That's why the status --ignored line comes first: if it lists anything you still need, copy it out before you remove the worktree.

Both tools also do this for you. claude --worktree feature-auth starts a Claude Code session in a new worktree, and a .worktreeinclude file lists the gitignored files to copy into it; keep that list to dev-only files, for the same reason as above. OpenAI's desktop app has a Worktree mode for running Codex chats in parallel (docs); its docs don't describe the same for the CLI.

A worktree isolates files, not processes. Both agents run as your user, on the same machine, with the same network access, the same credentials in ~/.aws or ~/.ssh, and often the same local database and ports. If two worktrees run migrations against one Postgres database, they will collide, which is why each one got its own above. If you need security isolation, that comes from the agents' sandbox settings, containers or separate machines, not from a second directory.

Where Orca fits

Orca is an open-source (MIT) desktop app for running coding agents side by side, each in its own Git worktree. It supports Claude Code, Codex and many other CLI agents, and you use your own subscriptions; it doesn't sell model usage. According to its docs, it creates a real git worktree per task, shows diffs you can annotate and send back to the agent, notifies you when an agent finishes or needs attention, and tracks the usage and reset times of providers like Claude Code and Codex in its status bar.

What it doesn't do: raise your limits. Orca runs the same CLIs against the same plans, so four agents in Orca spend the same pool as four agents in tmux. Its own docs say to prefer the provider console for authoritative spend. Its value is visibility (which agent is waiting on you, how much quota is left) and less manual worktree work. Its cost is another app in your toolchain that releases very often (v1.4.245 on October 30, 2026), with plugins that, per its release notes, run with full access to your computer once approved.

My rule: if you run one or two agents, tmux and three git commands are enough. When you regularly lose track of which agent is blocked, a tool like Orca starts paying for itself in attention, not in tokens.

The hidden cost of parallelism

Parallel agents move work to places you don't see in the moment.

Duplicated context. Every agent learns your codebase from scratch: it reads CLAUDE.md or AGENTS.md, explores the folders, opens the same core files. Four agents pay that onboarding four times, from one quota.

Coordination tokens. In an Agent Team, messages between teammates and task-list updates are model calls too. Every teammate is also a separate Claude instance with its own context window, which is the reason Anthropic gives for teams in plan mode using about seven times the tokens of a standard session.

Merge conflicts and semantic conflicts. Worktrees prevent agents from overwriting each other's files. They don't prevent two branches from making incompatible decisions, like two different error formats or two ways of checking a role. Git merges those cleanly, and your tests or your users find them later.

Review is serial. You can run five agents in parallel, but you read diffs one at a time. If an agent produces a 600-line change in 20 minutes and you need 40 minutes to review it properly, adding a second agent mostly doubles your review queue.

Interruptions. A limit that hits halfway through a task stalls it. Recent Claude Code versions (2.1.234 and later) wait and continue on their own after the reset, but the first request after a long break misses the prompt cache and reprocesses your whole context. Meanwhile, the half-finished branch blocks whatever depended on it.

flowchart LR
  G[Agents generate code<br/>parallel] --> R[You review<br/>serial] --> T[Tests and fixes] --> M[Merged and verified]
  R -. rework .-> G

The bottleneck in AI-assisted development is usually the review step, not the generation step. Add agents until your review queue is full, and stop there.

How to measure this on your own plans

No article can tell you which workflow wins on your codebase, your plans and your review speed. A small, controlled comparison can, and it's the only way to stop trusting the feeling of speed that METR measured. This is the setup I'd use.

The project. A TypeScript REST API with PostgreSQL, authentication, role-based access control (RBAC), automated tests and one small frontend screen. Every run starts from the same commit, the same written task files and the same acceptance tests.

The tasks. A mix of independent and dependent work:

#	Task	Depends on
T1	Add a `roles` table, migration and seed	none
T2	RBAC middleware: deny by default, check role and resource owner	T1
T3	Audit log of security events (login, failed login, role change)	none
T4	Rate limiting on login with progressive lockout	none
T5	Admin screen listing users and their roles	T2
T6	Tests that try IDOR and privilege escalation against T2	T2

The workflows. Single agent, tmux sessions (one task per session, same checkout, to expose conflicts), subagents, an Agent Team, tmux with worktrees, and worktrees split across Claude Code and Codex. If you use Orca, run the last one from it as a seventh. Change one thing at a time: same models, same task files, same tests, and at least two runs per workflow, because one run of an agent is an anecdote.

The metrics. Wall-clock time to the last merged task, active human time (time you spend typing, reviewing or deciding), input, output and cache tokens, quota consumed, sessions interrupted by a limit, acceptance test pass rate, security issues found in review, merge conflicts, rework rounds, and verified tasks per hour: tasks that passed the acceptance tests and your review, divided by wall-clock hours.

Both tools expose token data. Claude Code exports claude_code.token.usage through OpenTelemetry when CLAUDE_CODE_ENABLE_TELEMETRY=1 is set and an exporter is configured (for example OTEL_METRICS_EXPORTER=console), with input, output and cache tokens as separate types, and codex exec --json emits a turn.completed event with input_tokens, cached_input_tokens and output_tokens (docs). Quota is harder: neither plan shows a raw number, so record the percentage from /usage or /status before and after each run.

Put one row per workflow and one column per metric in a spreadsheet, and read verified tasks per hour first. A workflow that finishes faster but needs more rework or more of your review time hasn't won anything.

What I'd expect, as a hypothesis and not a result: worktrees across two providers will win on verified tasks per hour for T1, T3 and T4, and a single agent will win on T2, T5 and T6, because those three share one design decision (how a role is checked) that is cheaper to make once than to explain to three agents.

How to get more from your AI subscription

These are the habits I'd apply before upgrading any plan. Each one comes from the vendors' own guidance or follows from how usage is counted.

Clear between tasks. /clear when switching to unrelated work, /compact with a focus when continuing a long task. Every turn resends the history, so stale history is the most expensive thing in your session.
Pick the model per task. Sonnet for most Claude Code work, Opus only when it's stuck or for wide changes (/model opusplan plans with Opus and executes with Sonnet). On Codex, a lighter model for routine edits buys you a much larger allowance.
Keep the always-loaded files small. Anthropic suggests keeping CLAUDE.md under 200 lines; OpenAI suggests reducing the size of AGENTS.md. Both get read on every session.
Turn off what you don't use. Every MCP server adds to the context: in Claude Code its tool names and instructions (full definitions load only when a tool is used), in Codex context on every message. Both vendors say to disable the servers you don't need, and Anthropic suggests CLI tools like gh when they exist.
Delegate verbose work, not judgement. Send searches, test runs and log reading to a subagent with a cheap model, and keep design decisions in the main session.
Split by provider, not only by pane. Put independent projects or tasks on the plan that has quota left.
Write the task down. A task file with acceptance criteria and the test command saves the back-and-forth that burns tokens, and it lets you hand the same task to a different agent after a reset.
Watch the meter before you start, not when it stops you. Check /usage or /status before launching parallel work. If the window is 80% spent, start one task, not four.
Turn on paid overflow deliberately. Usage credits are opt-in and billed at API rates. Set a monthly cap if you enable them, so a forgotten agent can't run up a bill.
Check that ANTHROPIC_API_KEY is unset in shells where you mean to use your subscription.

A decision framework

Workload	Best fit	Why
One feature, steps depend on each other	Single agent, `/clear` between features	Shared decisions stay in one context
Unrelated projects	tmux sessions, mixed providers	Clean parallelism, two quotas
Independent tasks in one repository	Worktrees, one agent each	File isolation, simple merges
Search, test runs, log analysis, review	Subagents with a cheaper model	Keeps the main context small
Debugging with competing hypotheses, broad research	Agent Team, few teammates	Teammates challenge each other; worth the tokens
Same files, shared schema, tight dependencies	Single agent	Parallel agents create semantic conflicts
Three or more agents, or you lose track of which is blocked	Orca or a similar tool	Pays back in attention, not quota
Window almost spent	One small task, or switch provider	Interrupted work stalls, and resuming re-reads the whole context

Final verdict

So, are parallel AI agents making developers more productive, or just reaching the limit faster?

Both, depending on the work. Parallel agents are worth it when tasks are truly independent, when each one has written acceptance criteria and tests, when the work is spread across two providers' quotas, and when your review capacity keeps up with what they produce. A single agent is the better choice when the tasks share decisions, touch the same files or depend on each other, which, according to Anthropic's own engineering team, describes more coding work than research work.

What doesn't hold up is the idea that more agents means more software. Every architecture in this post spends from a limited pool, and every one of them ends at the same place: a person reading a diff and deciding whether it's right.

The best AI coding workflow is not the one running the most agents. It's the one producing the most verified engineering value within its constraints.

Takeaway

Your quota is shared. Every Claude Code pane, subagent and chat draws from one Pro pool; Codex local and cloud work share one Plus pool.
Subagents save context, not tokens. Use them for verbose, read-heavy work, with a cheaper model.
Agent Teams cost about 7x in plan mode. Use them for work that benefits from discussion, not for routine edits.
Worktrees isolate files, not processes. Separate databases, ports and credentials need their own isolation.
Two $20 plans are two pools. Splitting work by provider is the cleanest way to get more allowance without upgrading.
Count verified tasks per hour, not agents running or lines generated.

How many agents can you run before your review becomes the bottleneck, and what did you change when you hit that point? Tell me in the comments.

I'm Diogo Soares, a Staff AI Engineer working on AI agents and legacy modernization. If this was useful, follow me here on DEV.to and on Instagram at @diogosoares.dev, where the habits from this post become a carousel you can save for your next planning session. This article also has a video walkthrough on my YouTube channel, Diogo Soares Dev, so subscribe there for the next ones. Let's also connect on LinkedIn, or check out diogosoares.dev.

DEV Community