One task, one writing boundary
Iterel-managed writers reserve isolated worktrees. Two writers cannot claim the same mutable worktree at the same time.
Parallel coding agents
Run several coding agents without losing the project.
Give every coding task its own connected engine, context, worktree, receipt, and review boundary.
Iterel turns parallel Claude Code, Codex, Cursor, and other engine runs into visible product work—not a pile of terminal sessions the team has to reconstruct later.
The coordination problem
More terminal sessions are not a coordination system.
A second coding agent can increase throughput, but it also creates another branch, transcript, set of assumptions, and place to watch for questions. Once several tasks move at once, the missing layer is ownership: who is changing what, from which context, against which snapshot, and what is ready to review.
Iterel makes the task the unit of parallel work. The engine still executes on the maker’s machine; the project keeps the objective, dependencies, rounds, Changes, verification, and decision together.
What becomes visible
Coordinate the work around each engine run.
Dependencies before collision
Tasks can declare dependencies, while advisory territory warnings surface likely overlap between separate worktrees.
Context that survives the session
Objectives, rules, selected files, project decisions, design intent, and prior outcomes stay attached to the task and its rounds.
A live attention layer
Running, needs-input, failed, blocked, and needs-review work stays visible from the Board and Command center.
Evidence at the task boundary
Changes, counts, checks, activity, engine attribution, and the task-only Preview remain connected to the exact task worktree.
External work stays yours
Unmanaged edits are detected and preserved. Iterel does not kill, reset, stash, move, or overwrite a person’s outside changes.
Parallel workflow
From several prompts to one reviewable project record.
- 01
Define separate tasks
Give each objective its acceptance criteria, context, dependencies, and task rules before execution.
- 02
Choose the engine
Route each task to an available connected engine and use only the controls that engine actually supports.
- 03
Reserve the worktree
A managed writing round claims its isolated worktree before it becomes Running.
- 04
Watch attention, not terminals
Follow progress, approvals, needs-input, failures, dependencies, and mission health from shared project views.
- 05
Review the exact outcome
Inspect Changes and verification against the task snapshot, then Accept, Discard, or start another round.
Precisely stated safety
Isolation reduces collisions; it does not invent certainty.
Hard worktree ownership
Same-worktree writers block. In-place and full-access runs are project-exclusive.
Advisory semantic overlap
Territory warnings help people spot likely overlap, but Iterel does not claim to prove that two changes are semantically independent.
Snapshot-bound verification
Workspace drift invalidates stale evidence. Iterel waits for stability and retries a verification attempt at most once.
Questions, answered
Managing multiple coding agents in practice.
Can I run Claude Code and Codex in parallel?
Yes, when both are connected and the tasks qualify for parallel execution. Each managed writing task owns its task record and isolated worktree rather than sharing one mutable checkout.
Does Iterel prevent every merge conflict?
No. Worktree ownership prevents same-checkout writers from corrupting one another, and territory warnings make likely overlap visible. Semantic conflicts can still exist and belong in review.
What happens if the workspace changes during verification?
Verification is bound to a workspace fingerprint and change epoch. If the workspace drifts, Iterel preserves the work, invalidates the stale attempt, waits for stability, and retries at most once.
Can I see which engine changed each file?
The task keeps engine and round attribution alongside its exact Changes, activity, checks, and receipt, so review starts from the work that produced the change.
Does parallel work require Iterel Cloud models?
No. Connected engines run through the user’s own machine and vendor access. Iterel Cloud execution is a separate, explicit, credit-funded choice.
Start with one engine—or several
Give parallel work a shared product record.
Free includes unlimited machine-local projects with Build and Design and one connected engine. See the plans for multiple connected engines and cloud continuity.