Monorepo vs Polyrepo: Which Structure Costs Less for AI Coding Agents?

A monorepo is not automatically expensive for an AI coding agent, and a polyrepo is not automatically lean. The cost depends on how much irrelevant context the agent reads, how often stable context is reused, and how many repositories a successful task must coordinate.

Repository layout affects five parts of the bill: initial discovery, retrieval and indexing, prompt and cache behavior, tool execution, and validation. Human teams often choose a layout for ownership and release reasons. AI cost should be a secondary measurement, not the sole architecture driver, but it is large enough to model for high-volume agent fleets.

Where Monorepos Spend More

An unconstrained agent can list broad trees, read multiple package manifests, search generated files, and run a test command that touches unrelated workspaces. Large tool outputs then re-enter model context. If each task begins by rediscovering the repository instead of using a maintained map, the same structural tokens are purchased repeatedly.

Indexing also has a wider potential scope. A hosted editor may charge indirectly through included usage, while a custom system pays embeddings, storage, and refresh compute. Changing one shared generated directory can trigger large invalidations. The waste is not the number of files; it is indexing and retrieving files that have near-zero probability of affecting the task.

Where Polyrepos Spend More

Cross-service changes require several clones, authentication contexts, dependency graphs, branches, pull requests, and CI pipelines. The agent may reconstruct the same organizational standards in every repository and lose cache reuse because system prompts and file ordering differ. A version bump across eight services can become eight agent sessions even when one coordinated change would suffice.

Polyrepos also increase synchronization failures. One patch merges while another waits, an API version changes between runs, or tests pass locally against the wrong dependency revision. Retries and human coordination can dominate the token savings from smaller search spaces.

A Comparable Cost Model

For each task class, measure discovery tokens, retrieved code tokens, generated tokens, tool-output tokens, runtime minutes, CI minutes, number of repositories touched, and acceptance rate. Suppose a monorepo task uses 500K input, 60K output, and 20 CI minutes. A polyrepo version uses 320K input and 45K output per session but needs two sessions and 28 combined CI minutes. The smaller individual prompt still produces the larger total task.

At $1/M input and $5/M output, the monorepo model bill is $0.80. The two polyrepo sessions cost $0.64 input plus $0.45 output, or $1.09. CI and review widen the gap. Reverse the assumptions for a narrow single-service fix and the polyrepo can win. Segment results by task type rather than publishing one repository-wide average.

Controls That Matter More Than Layout

• Maintain repository maps. Give agents package ownership, dependency edges, generated paths, and canonical test commands.
• Scope search by default. Start from the named package and expand only when imports or test failures justify it.
• Standardize instructions. Stable ordering and shared policy improve prompt-cache reuse across repositories.
• Use affected-test tooling. Validate the dependency cone instead of running every test or too little.

Benchmark Representative Tasks

Choose a balanced evaluation set: one local bug, one shared-library change, one API migration, one security patch, and one cross-service feature. Run each layout with the same acceptance criteria and equivalent agent capabilities. Normalize for repository size only after reporting the raw task result; size is part of the real operating environment.

Capture the sequence of files retrieved and commands run. Two agents can spend the same number of tokens but differ sharply in useful context. Label retrieved files as necessary, helpful, or irrelevant after review. That relevance rate identifies whether a monorepo needs better scoping or a polyrepo needs better dependency discovery.

Account for Organizational Friction

Repository boundaries often encode team ownership and permissions. An agent crossing a boundary may wait for another reviewer, use a different CI system, or lack credentials. Measure queue time and handoffs, not just machine spend. Faster inference cannot shorten a two-day ownership wait.

In a monorepo, broad access can simplify changes but increase the blast radius of a mistaken edit. Use path-scoped policies, owners, and affected-build checks. In polyrepos, provide a coordination manifest listing required commits and compatible versions. These controls add modest setup cost while preventing repeated cross-boundary failures.

Bottom Line

Monorepos trade a larger searchable universe for easier coordination and reuse. Polyrepos trade narrower local context for duplicated sessions and cross-repository state. Benchmark representative changes on your actual agent, then optimize maps, retrieval, caching, and affected tests. Repository structure sets the terrain; agent discipline determines most of the bill.