Cost Savings for Multi-Repo Teams

Teams with multiple repositories use repository_isolated mode (the default) where each repo maintains its own cache pool. Even with cache pools split across repositories, a team of 100 engineers working across 10 repos achieves meaningful savings — averaging 10 engineers per repo still produces substantial overlap.

Use this page when

• Your team uses multiple independent repositories and you want to understand per-repo cache economics.
• You need strategies for maximizing hit rates across a repository portfolio (org-scoped fabric, repo grouping, TTL tuning).
• You are deciding whether to keep repos isolated or consolidate them into monorepo groups.

Primary audience

• Primary: Technical Leaders
• Secondary: Technical Engineers, AI Agents

How Repository-Isolated Mode Works

In repository_isolated mode, each repository gets its own independent cache pool:

cache:
  codebase_identity_mode: repository_isolated
  fabric_scope: org
  ttl_seconds: 86400

This is the default configuration. You do not need to specify codebase_identity_mode explicitly — Keeptrusts automatically isolates cache pools by repository identity.

Cache Pool Boundaries

Configuration	Cache Pool Scope
repository_isolated (default)	One cache pool per repository
fabric_scope: org	All org members share each repo's pool
fabric_scope: team	Only team members share each repo's pool

Per-Repo Hit Rates

Hit rates in multi-repo setups depend on how many engineers actively work in each repository:

Engineers per Repo	Typical Hit Rate	Notes
2–5	40–55%	Small teams with moderate overlap
5–15	55–70%	Good overlap, common patterns emerge
15–30	70–80%	High overlap, shared utilities dominate
30+	80–90%	Near-monorepo levels of sharing

A team of 100 engineers distributed across 10 repositories (averaging 10 per repo) typically achieves 55–70% hit rates per repository — translating to 55–70% cost avoidance on upstream AI calls.

Example: 10-Repo Engineering Organization

Consider an organization with the following repository structure:

acme/
├── user-service/        (15 engineers)  → ~70% hit rate
├── payment-service/     (12 engineers)  → ~65% hit rate
├── notification-service/ (8 engineers)  → ~60% hit rate
├── auth-service/        (10 engineers)  → ~65% hit rate
├── analytics-service/   (10 engineers)  → ~65% hit rate
├── mobile-app/          (15 engineers)  → ~70% hit rate
├── web-app/             (12 engineers)  → ~65% hit rate
├── shared-libs/         (8 engineers)   → ~60% hit rate
├── infra/               (5 engineers)   → ~50% hit rate
└── docs/                (5 engineers)   → ~50% hit rate

Weighted Monthly Savings

With an average of $0.03 per upstream request and 50 requests per engineer per day:

• Total daily requests: 100 engineers × 50 = 5,000
• Weighted average hit rate: ~64%
• Daily cache hits: ~3,200
• Daily cost avoided: 3,200 × $0.03 = $96
• Monthly savings: ~$2,880

Strategies for Maximizing Multi-Repo Savings

1. Use Org-Scoped Fabric

Set fabric_scope: org so all organization members share cache pools per repository. Even engineers who occasionally contribute to a repo benefit from the primary team's cached responses.

cache:
  codebase_identity_mode: repository_isolated
  fabric_scope: org
  ttl_seconds: 86400

2. Consolidate Related Repositories

If you have repositories with significant code overlap (shared patterns, similar frameworks), consider grouping them with monorepo_group mode instead:

cache:
  codebase_identity_mode: monorepo_group
  monorepo_group_id: "backend-services"
  monorepo_repo_ids:
    - "github.com/acme/user-service"
    - "github.com/acme/payment-service"
    - "github.com/acme/auth-service"

This pools cache across related services, boosting hit rates for repositories that share frameworks and patterns.

3. Optimize TTL by Repository Activity

Actively developed repositories benefit from shorter TTLs to keep cached responses fresh. Stable repositories can use longer TTLs:

Repository Type	Recommended TTL
Active development (daily commits)	43200 (12 hours)
Moderate activity (weekly releases)	86400 (24 hours)
Stable/maintenance mode	172800 (48 hours)

4. Set Appropriate Similarity Thresholds

For repositories with highly structured code (e.g., API services with consistent patterns), you can lower the similarity threshold slightly to increase hit rates:

cache:
  semantic_similarity_threshold: 0.90

For repositories with diverse code patterns, keep the threshold at 0.92 or higher to maintain response quality.

Monitoring Multi-Repo Performance

Track these metrics across your repository portfolio:

• Per-repo hit rate: Identify underperforming repositories that may benefit from configuration changes.
• Cross-repo contribution patterns: Spot repositories where occasional contributors drive cache misses.
• Estimated avoided cost per repo: Understand which repositories deliver the most savings.
• Fill rate trends: Monitor whether cache pools are growing or stagnating.

When to Upgrade to Monorepo Group Mode

Consider switching specific repositories to monorepo_group mode when:

• Two or more repos share more than 50% of their dependency tree.
• Engineers frequently context-switch between the same set of repos.
• Per-repo hit rates plateau below 60% despite adequate contributor counts.
• Repositories use identical frameworks and coding patterns.

You can mix modes across your organization — some repos in repository_isolated mode and others grouped under monorepo_group — to optimize savings for each team's workflow.

For AI systems

• Canonical terms: Keeptrusts, multi-repo, repository_isolated, per-repo cache pool, fabric_scope: org, cache strategy, monorepo_group upgrade path.
• Config keys: cache.codebase_identity_mode: repository_isolated, cache.fabric_scope, cache.ttl_seconds, cache.semantic_similarity_threshold.
• Best next pages: Cost Savings for Mono-Repo Teams, Repository-Isolated vs Monorepo-Group, Configuring Monorepo Group Caching.

For engineers

• Default mode (repository_isolated) requires no additional config — each repo gets its own cache pool automatically.
• Set fabric_scope: org so all org members (not just the primary team) share each repo’s pool.
• Tune TTL by activity: active repos (daily commits) use 12h, stable/maintenance repos use 48h.
• Consider lowering semantic_similarity_threshold to 0.90 for repos with highly structured, repetitive code patterns.
• Upgrade path: switch related repos to monorepo_group when they share 50%+ dependency tree and identical patterns.

For leaders

• 100 engineers across 10 repos (avg 10/repo) achieve weighted ~64% hit rate = ~$2,880/month savings.
• Hit rate scales with engineers-per-repo: 2–5 engineers = 40–55%, 15–30 engineers = 70–80%, 30+ = 80–90%.
• Key strategies: use org-scoped fabric, consolidate related repos into monorepo groups, optimize TTL per repo activity level.
• You can mix modes — some repos isolated, others grouped — optimizing for each team’s workflow.
• Monitor per-repo savings and hit rates; promote repos with plateaued rates to monorepo group mode.

Next steps

• Cost Savings for Mono-Repo Teams — monorepo topology advantages
• Repository-Isolated vs Monorepo-Group — choosing identity mode
• Configuring Monorepo Group Caching — setup for group mode