Fix the agent that's billing you in the dark.
You are running Claude Code, Codex, or a custom agent stack in production, and somewhere in the last few months a subagent fan-out, a recursive spawn, or a quota rollover put a number on your bill you were not expecting. I trace the loop, find the exposure, and build the enforcement that stops it happening again.
If a subagent loop already put a number on your bill you did not expect
- A subagent fan-out, a recursive spawn, or a quota rollover already put a number on your bill you were not expecting: a $600 session, an $1,800 overnight run, a Max plan that silently switched to pay-per-token and kept going
- It has not happened yet, but you have looked at your orchestration code and know there is no depth cap on the subagent spawner
- You have no ceiling on what a single loop can spend before something stops it
- You are an engineer or founder, not a buyer of "AI strategy," and you do not want a slide deck
- You want someone who has actually built the enforcement layer to look at your stack and tell you where the exposure is
Four tiers, same problem, different depth.
These stack. Most engagements start with the Diagnostic, and the Diagnostic's findings set the scope for the Sprint if there is real work to do. You do not have to commit past step one to get value from step one.
We trace every agent and subagent loop in your stack and map where spend can run away from you, then hand you a written, ranked report.
- Every agent and subagent loop traced against a known list of failure modes: no depth cap, no per-session or per-loop budget ceiling, silent quota-to-paid rollover, retry storms with no backoff limit
- Your actual usage and billing data for the last 30 to 60 days, matched to the code paths that caused each spike
- A written report: every exposure found, ranked by dollar risk, with the specific file or call site responsible
- Small fixes handed to you directly in the report instead of upsold into the Sprint
We build the fix the Diagnostic scoped: working, deployed enforcement, not a recommendation to build it yourselves.
- A hard budget ceiling per session and per loop that kills execution when it is hit, not just logs it
- A depth cap on subagent spawning enforced in code, not a suggestion in a config file someone can skip
- Alerting that fires before you are $500 over, not after you check your bill
- RelayPlane, or an equivalent proxy layer if your stack has a reason to avoid it, in front of your calls so enforcement lives in one place instead of being reimplemented per agent
- Enforcement tested against the exact failure modes the Diagnostic found
We run the enforcement layer for you as your system changes.
- New agents, new subagent patterns, new providers, covered by the budget and depth controls as your team adds them
- Monthly review of what actually got spent and where, with the same failure-mode ranking as the original Diagnostic
- Drift caught before it becomes a repeat of the incident that got you here
The lightweight version: ceilings and alerting stay live, we watch and flag, we are not actively building.
- Budget ceilings and alerting kept live
- Watching for the same failure signatures: fan-out spikes, quota-to-paid rollovers, spend velocity outside your normal range
- The right fit once your system is stable and you want a floor under it, not active engineering
What the Diagnostic week looks like
Trace (day 1-2)
Read access to your orchestration code, your usage and billing exports, whatever logs you have. No production write access, no credentials I do not need.
Map (day 3-4)
Every agent and subagent loop checked against a known list of failure modes: unbounded depth, no per-loop ceiling, silent quota-to-paid conversion, retry storms. Spend spikes matched to the code paths that caused them.
Report (day 5)
A written report: every exposure found, ranked by dollar risk, with the specific file or call site responsible. If a fix is small enough to hand you directly, it goes in the report instead of getting upsold into the Sprint.
Straight answers.
The person who built the enforcement layer, not a slide deck about one.
RelayPlane is a proxy I built and run myself, open source, MIT licensed, specifically to put budget enforcement and routing control in front of LLM calls. It is not a pitch-deck product I am about to build once someone signs. It already handles real production traffic for other teams, including infra PRs from engineers running it themselves in production: a Postgres telemetry backend, a Docker and CI setup, budget-cap enforcement that has already caught real usage in the wild.
I have spent fifteen-plus years on production codebases before any of this, so when I look at your agent loop I am reading it the way I would read any other system with a spend and reliability problem, not treating "it's AI" as an excuse for the code underneath it to be unaccountable.
If the Diagnostic shows two small fixes you can make yourselves, I will tell you that too. The point is an honest read of your actual exposure, not a funnel into the next tier.
Find out what your agent loop is actually exposed to.
Either way, you'll know within a week if this is the right fit.
Matt
