Beyond the meter: building Limitcast’s repository optimizer

Sam Stull · 8 November 2026

Limitcast already forecasts usage windows, budgets subagents and helps trim context. I wanted it to address another source of waste: the work an agent keeps doing after it has stopped making progress.

After comparing Limitcast with Microsoft’s TokenEconomizer, I added a local repository optimizer to the Limitcast source. It covers failure-loop detection, learning successful check-command alternatives, pruning unused built-in capabilities and building a small source map.

This is a development update, not a new npm release. The additions are in the source repository; npm’s released version remains 0.18.3. They are opt-in. I have not established that Limitcast saves more than TokenEconomizer or that these changes reduce real subscription usage.

A check on repeated failures

The loop detector watches repeated failures and edits to the same files within a turn. It also uses productive turn lengths once a repository has enough evidence. Passing a recognized check clears earlier failure evidence; a long turn or changing errors alone does not trigger it.

When the evidence crosses the threshold, the agent gets a short redirect to revisit its hypothesis before editing again. Continued repetition produces a notice. Limitcast does not stop the running turn, and this implementation adds no judge-model calls.

Learn a command only when the evidence repeats

Repository learning starts off. When enabled, it can learn a narrow fact such as bare pytest being unavailable while python3 -m pytest works. Three independent sessions must confirm the replacement before it is injected into a later session. A contradictory missing-command or module result retires it.

Ordinary assertion failures do not teach environment facts. Commands come from a small whitelist. Raw output and prompts are not stored as learned instructions, and Limitcast does not execute a learned command itself. This is narrower than a model synthesizing general repository knowledge, but it avoids adding an automatic paid proposer.

Trim built-in capabilities with a way back

Existing MCP trimming remains. The optimizer adds proposals for unused Codex collaboration, goals and image-viewing packages, and individual Claude tools when their declarations are available in the transcript. Core reading, editing, search and question tools are protected.

Applying a named proposal is explicit. Tracked files, symlinks, conflicting settings and insufficient evidence cause a refusal. A receipt is written before changing a configuration. Undo restores the original bytes only if the resulting file still matches; later user edits are preserved for manual reconciliation.

The native Codex check caught a useful integration bug during development: on 0.167, features list ignores -C when choosing project settings. Validation now runs from the repository’s actual working directory and checks that the requested features really turned off.

A source map with a fixed budget

The map lists tracked source files and recognizable declaration names within a 6,000-character default budget. It excludes hidden, credential-shaped, generated and vendor paths, and skips symlinks. Clean trees reuse a commit-keyed cache; dirty trees regenerate it. Injection is off until enabled for a repository.

This is a lightweight declaration map, not a full dependency graph. It adds context of its own, so it belongs in repositories where reduced searching can justify that cost.

What the checks establish

• The full suite passed 249 tests, including concurrent hook delivery, contradictory learning, privacy filtering, rollback and user-edit preservation.
• Six deterministic Promptfoo replay cases passed: repeated loops, productive work, changing failures, exploration, duplicate delivery and ambiguous status.
• An isolated native Codex 0.167 fixture disabled all three selected controls and restored them. Rendered prompt-input JSON fell from 85,121 to 84,441 characters. Those are character counts in one fixture, not measured token or subscription savings.
• The packaged CLI contains the new modules. Live optimizer-hook delivery in existing user sessions and comparative real-model task outcomes remain separate checks.

The first adapters cover Claude Code, Codex and Grok. Grok receives startup context with its first tool result. Copilot and Pi are not integrated yet. Capability pruning remains explicit, and no model-backed judge or general fact proposer is included.

That leaves a clear next test: equivalent real tasks, with and without each mechanism, counting the mechanism’s own overhead and checking whether the work still gets done. A feature list cannot answer that.