Colony runs its own development pipeline. Every PR goes through seven agents. Every dollar is attributed to one of them. When you can see the breakdown, the distribution of spend stops being a mystery and starts being a question with a real answer.
Over 30 days — April 13 to May 13, 2026 — Colony merged 1,284 PRs at a total cost of $1,142.18. Most engineering work is orchestration. The biggest single cost in the pipeline, though, is the agent doing the implementation.
Builder is the dominant cost center
Builder took $612.40 of the $1,142.18 total — 53.6% of spend over that 30-day window.
The next two are Inspector at $201.18 (17.6%) and Architect at $118.92 (10.4%). Surveyor, Marshal, Mayor, and Sentinel share the remaining 18.4%.
The distribution is expected. Builder runs Claude Code in a subprocess for each issue it processes. It reads repo context scoped to the relevant packages, digests the Architect’s plan, checks out a branch, and implements — across files, packages, and test suites as the issue requires. When the Inspector returns action items, Builder re-reads the PR, addresses the feedback, and iterates. Each round costs tokens, and the rounds are not short.
Inspector is cheaper because it works from a finished diff against a structured checklist — it evaluates what Builder produced rather than generating it. Architect is cheaper because it plans from an issue description and a high-level view of the repo, doing so before a full implementation is in progress.
The 53.6% share reflects a structural asymmetry in the pipeline: the agent doing open-ended generation against a large codebase context will carry a larger cost than agents doing classification or planning. That’s the expected state. The useful question is whether the spend inside Builder is efficient.
Two context-budget experiments
Colony’s production learnings encode a principle that applies to every prompt path: every prompt path that includes user-generated or code-generated content must have a size budget. Two experiments applied that principle at different points in the pipeline — one in the Inspector’s review prompt, one in Builder’s planning phase.
Diff-size limits and summarization in change-request cycles (#456). When a PR goes back for another round, the Inspector re-reviews the diff against a structured checklist. The direct approach: include the full diff in the review prompt. For large PRs — many files, substantial refactors — a full diff overwhelms the context window. Earlier context drops. The model starts reasoning against a partial picture.
The fix caps the review prompt’s diff size (review.max_diff_lines, default 3000, in reviewer/src/executor.ts and external-review.ts) and routes epic-scale diffs through a summarization pass instead (reviewer/src/epic-review.ts). Above the budget, the Inspector’s prompt carries a structured summary — which files changed, what categories of change, where the action items are localized — rather than the raw diff.
Repo context budget scaled by issue complexity (#321). Before this change, Builder read roughly the same scope of repository context for every issue — a one-line type annotation fix and a multi-package feature addition both loaded similar context windows. Small issues don’t need wide context. Loading it regardless is waste that accumulates across hundreds of issues per month.
The fix is complexity tiers, set in developer/src/planning.ts: 2000/4000/7000 max tokens and tree depth 3/4/5 for small/medium/large issues. Quality on small issues holds because they genuinely don’t require wide context to produce correct implementations. Budget scales with actual complexity.
Both changes have the same structure: identify a prompt path carrying code-generated or user-generated content, impose a size budget, and route overflow to a structured summary.
What didn’t work as the primary signal
Hard turn and iteration limits seemed like the right mechanism for capping Builder spend. A maximum number of turns per complexity tier, defined in advance, gives a predictable upper bound on cost per issue.
The problem is that turn counts don’t correlate with work remaining. A Builder circling on a failing type check burns turns on attempts that all fail the same way. A Builder making clean progress on a large implementation hits the same count and stops mid-task. The limit fires with equal indifference to either situation.
Colony replaced hard turn limits as the primary termination signal with progress-based termination (#394). Builder stops when it stops making progress — no new files written, no tests changed, no meaningful delta in implementation state. Turn limits remain in the pipeline as backstops: Builder can still hit them, but they’re the last resort rather than the primary mechanism.
One honest follow-on: post-hoc budget enforcement is still required. Claude Code can exceed configured max_turns without the CLI enforcing it during execution. Colony added validation that checks num_turns <= max_turns after execution and marks overruns with isMaxTurns: true (#1047, #1048). Progress-based termination is the correct primary signal; the post-execution guard is a required backstop. Your engineering standards survive autonomy.
If your team is running AI coding agents in production and any of this looks familiar — cost attribution, context-window management, termination logic — we’d like to talk. The pilot conversation is open. The pipeline is at the self-hosted pipeline.
If you’d like to see the pipeline running on your work, we should talk.