Swarmby Myrik

Pipeline options

On the New Run page:

Batch API (default ON)
Uses the Batch API for parse + review phases — ~50% cheaper, adds 1–5 min latency on review. Turn off for fast iteration.
Skip per-task tests (default ON)
Skips the per-task test agent. Integration validation still runs at the end. Saves 10–20% of tokens.
Skip all tests
Disables per-task tests AND integration validation. Not recommended unless debugging.
Skip review
No review pass and no fix loop. Tasks go straight from execute to PR.
Skip PR creation
Leaves branches in your worktrees; you open PRs yourself.
Review retries
Max cycles of review → fix → re-review. Default 2.
Cost budget
Run is cancelled if spend exceeds this cap. A server-side ceiling of MAX_RUN_COST_USD=50 applies regardless.
Concurrent runs
Each org runs up to MAX_CONCURRENT_RUNS_PER_ORG=3 at a time. Beyond that returns HTTP 429; Jira webhooks past the cap are logged and skipped (no retry storm).
Keep in mind — the cost-optimized defaults (Batch API on, per-task tests off) are deliberate — integration validation and review still run, so correctness is covered while token spend stays low. Only turn tests fully off to debug.
Keep in mind — model routing defaults to a mid-tier model for every complexity; a task opts into a stronger model via the planner or an operator override — high complexity does not auto-promote (too coarse, 5× the cost).

Cost controls

Two layers of protection:

  • Per-run cap (maxCostUSD): set when starting a run. Cancels the run when exceeded.
  • Server ceiling (MAX_RUN_COST_USD, currently $50): an absolute limit every run is capped at, even if a user sets a higher budget.

View aggregate spend at /costs.

Keep in mind — there's also a per-task ceiling (MAX_TASK_COST_USD); a task that trips it fails fast rather than burning the whole run budget. Owners can raise the run cap and resume from the run page.

Mid-run instructions & re-plan

On any run's detail page you can add requirements without starting over. Two modes:

Append (default)
Free text added to run.runtimeInstructions. Every later agent turn (execute / review / fix / retry / PR) reads them as extra spec. A mid-stream task finishes its current turn before seeing the new line. Capped at 20 instructions of 4 KB each.
Trigger re-plan (checkbox)
Aborts in-flight tasks (WIP force-committed + pushed), re-invokes the planner with the new requirement plus the current task list, appends new tasks, and resumes. Existing done tasks are preserved.
From Jira
Any non-bot comment on a Jira issue linked to an active run becomes a runtime instruction. Re-plan is dashboard-only.
Keep in mind — re-plan costs a planner turn and interrupts in-flight tasks — prefer plain Append for small additions; reserve re-plan for genuinely new scope.

Continuing a completed run

The instruction box stays on completed, failed, and cancelled runs as "Continue this run". Type a requirement, hit Continue run, confirm. The planner appends new tasks; the run resumes on the same branch. An open PR picks up the new commits; if it was merged and the branch deleted, a fresh PR is created.

Refused on creating-prs runs — wait for the PR phase to finish, or start fresh.

Org-wide pipeline defaults

/settings → Pipeline defaults exposes every per-run knob at the org level. Per-run flags take precedence; server-side env caps are the ceiling.

  • Cost & concurrency: max concurrent runs, max cost per run, per-task cost cap, review retries.
  • Behavior toggles: per-task worktrees, phase pipelining, skip-low-complexity-review, skip per-task tests / review / tests / PR.
  • Integration validation: skip below N changed lines (default 50).
  • Model timeouts & advanced: per-tier timeout multipliers, per-phase timeout/turn budgets, 429-retry cap, auto-resume cap.
  • Default custom instructions: free text appended to every prompt across all runs.

Worktrees & auto-cleanup

Each run creates a git worktree under .claude/worktrees/<shortId>/ and clones the repo into .claude/repos/<runId>/. These accumulate and eat into the task's storage budget.

The Auto-cleanup worktrees toggle in /settings removes them when a run reaches a terminal state. Off by default — turn it on if disk pressure matters more than post-mortem access to failed runs.

Keep in mind — the container filesystem is ephemeral and replaced on every deploy/restart. Done-task commits are force-pushed to origin at each checkpoint, so code survives a restart even though the local worktree doesn't.