Three Agents, One Terminal, Thirty-Minute Branches
Thirty-minute branches beat overnight integration bills
The expensive part of agent-assisted development is often not the first patch. It is the fourth explanation of the same architecture, the second agent repairing the first agent’s assumptions, and the integration session that drags half the repository back into context. Short branches cannot eliminate those costs, but they make the waste visible sooner.
My default is one behavior change per branch, with a thirty-minute checkpoint rather than a promise to finish in thirty minutes. At that checkpoint, merge a verified slice, narrow the task, or stop. Do not keep buying tokens because the agent sounds nearly finished.
Price the task before opening another worktree
Before launching an agent, write a tiny contract: the behavior to change, likely files, acceptance test, and explicit exclusions. For an API timeout fix, that might mean changing retry classification and adding two tests, without touching authentication or configuration loading.
- Give each branch one observable outcome that reviewers can verify.
- Name the exact test command before requesting any implementation work.
- Set a spending checkpoint before allowing another broad exploration pass.
- Require permission before changing shared interfaces or adding new dependencies.
A time limit alone is not a budget. Track token usage or billed cost alongside elapsed time. An agent can burn through substantial context while appearing to spend only a few minutes thinking.
Keep parallel agents away from shared ownership
Three agents are useful when their work is independent. They are expensive when all three edit the same request pipeline. I would split a timeout change into implementation, a separate documentation update, and an independent review of the proposed diff, not three competing implementations.
Use a separate worktree for each implementation branch. Run git worktree add ../timeout-fix -b fix/timeout-classification from the repository, then launch the agent there. Worktrees isolate files, not contracts: two cleanly separated directories can still produce incompatible assumptions. Agree on shared interfaces before parallel work begins.
Send a bounded prompt, not a repository tour
Start with the failing test, relevant paths, and the smallest useful explanation. Ask the agent to inspect those files first and report when it needs broader context. Avoid pasting yesterday’s entire conversation into today’s branch.
A useful handoff reads: retry only transient upstream failures; preserve existing authentication behavior; add coverage beside the current retry tests; run the focused suite; report changed files and unresolved risks. That is cheaper to review than a transcript and harder to misinterpret.
Match model spend to uncertainty
For a constrained test update, try Claude Haiku 4.5. For an ambiguous failure crossing several modules, consider Claude Sonnet 5.5. Treat those as experiments, not permanent assignments: compare accepted changes and total cost, including retries and review, rather than assuming a cheaper initial response means a cheaper merge.
Fluxo makes that comparison practical with one key and one base URL, https://api.fluxorelay.com, for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more. It works with Claude Code, Codex, Gemini CLI and any OpenAI SDK, so switching tools need not become a separate integration project.
Billing is per real token, including cache reads and writes, with no monthly fee. Keep stable instructions reusable, but inspect actual usage instead of assuming repeated context is free. If you want to try this workflow, create a Fluxo account and start with one bounded branch.
Merge the slice, then count the repair loops
Before merging, inspect git diff --stat, read the complete diff, run the focused tests, and run the project’s required checks. A small diff is a review advantage, not evidence of correctness. If the patch requires unrelated cleanup to make sense, split that cleanup into another branch.
Record cost per accepted change, repair prompts, and reviewer minutes. Those numbers reveal whether parallelism is helping. Keep referral income separate from engineering savings: Fluxo users earn a referral share when people they invite pay, but that does not make an inefficient agent run cheaper. The durable saving is fewer abandoned patches and fewer paid conversations about work already done.