When agents write 99% of your code, costs break

By Lazar Milicevic · Published September 22, 2026 · 9 min read

Your API bill last month was 4x what you projected, half your PRs came from agents, and nobody on the team can explain why the token graph spikes at 3 AM. That's not a hypothetical — that's the standard operating condition at shops like Kilo Code, Replit, and Symbotic right now. If you're a founder or lead engineer trying to figure out whether agents are burning budget or building leverage, the answer depends entirely on the guardrails you put in before you scaled.

The shift: humans review, agents write

At Kilo Code, co-founder Emilie Schario has said engineers now read or write code themselves only about 1% of the time — agents handle the rest. That number sounds absurd until you watch a modern dev loop: an engineer describes intent, an agent scaffolds files, another agent runs tests, a third writes the migration. The human's job compressed into prompt design, PR review, and incident response.

This isn't limited to AI-native startups. Replit's agent products have pushed the same pattern into general product development, and Symbotic — a warehouse automation company — reports similar leverage on internal tooling. The pattern is consistent: agents are cheap enough per call to feel free, expensive enough in aggregate to blow quarterly budgets, and reliable enough to trust with 80% of tasks but not the 20% that actually matters.

The uncomfortable truth is that most teams adopted agents before they set up the accounting. They now have three problems stacked on top of each other:

1. Cost visibility — nobody knows which agent, on which task, for which customer, spent what.
2. Reliability ownership — when an agent ships a bad migration, who owns the cleanup?
3. Multi-model sprawl — Claude for reasoning, GPT for structured output, a local model for classification, and no unified spend view.

The rest of this post is how teams that actually ship handle each one.

Why token bills explode (and it's not the model)

The default assumption is that costs scale with model choice — switch from Opus to Haiku, save money. That's true at the unit level and misleading at the system level. In practice, three patterns drive 80% of runaway spend:

Context bloat. Agents that re-read the entire codebase on every step. A 200k-token context window used greedily costs 20x what a scoped one costs. Most teams don't notice because each call still "works."

Retry loops. An agent hits a failure, retries with more context, fails again, escalates to a bigger model. One user request becomes 40 model calls. This is where "we spent $8k on one bug" stories come from.

Parallel fan-out without budgets. Subagents spawning subagents. Great pattern for research tasks, catastrophic pattern with no cost cap per parent task.

Here's a minimal cost meter you can drop into any Python agent loop:

class TaskBudget:
    def __init__(self, max_usd: float, task_id: str):
        self.max_usd = max_usd
        self.spent = 0.0
        self.task_id = task_id
        self.calls = 0

    def charge(self, input_tokens: int, output_tokens: int,
               in_rate: float, out_rate: float):
        cost = (input_tokens * in_rate + output_tokens * out_rate) / 1_000_000
        self.spent += cost
        self.calls += 1
        if self.spent > self.max_usd:
            raise BudgetExceeded(
                f"Task {self.task_id} spent ${self.spent:.2f} "
                f"over {self.max_usd:.2f} cap after {self.calls} calls"
            )
        return cost

Wire this into your agent framework's response handler. Every call charges the budget. When it trips, the task fails loud instead of quietly burning money. This is the single highest-ROI change most teams can make in an afternoon.

Which tasks are safe to hand to agents

The teams running agents at scale aren't handing over everything. They've built a mental model of what's safe and what isn't, and it's more useful than any generic "AI capability" list.

The pattern is blast radius plus observability. High-blast, low-observability tasks stay with humans. Low-blast, high-observability tasks go to agents. Everything in the middle gets an agent draft plus mandatory human review with a checklist.

Anthropic's own guidance on Claude Code puts this well: agents should operate in loops with clear success criteria and cheap ways to detect failure. Read their engineering blog on building effective agents — it's the most honest writeup on agent architecture I've found from a lab.

MCP guardrails: the layer most teams skip

Model Context Protocol (MCP) is the piece that makes the difference between "agent has access to production" and "agent has access to a scoped, audited, revocable interface to production." Most teams either give agents too much (raw shell access, full DB credentials) or too little (a prompt-only interface with no tools).

The right pattern is MCP servers that wrap capabilities with policy. Here's a minimal example of what a guarded MCP tool looks like in configuration:

mcp_servers:
  - name: production_db
    transport: stdio
    command: ./mcp-postgres-readonly
    env:
      DB_URL: ${PROD_READ_REPLICA}
    policy:
      allow_tools: [query, describe_schema]
      deny_tools: [execute, delete, drop]
      row_limit: 1000
      require_approval_for: [query_with_join_count_gt_3]
      audit_log: /var/log/mcp/prod-db.jsonl

  - name: github_writer
    command: ./mcp-github
    policy:
      allow_repos: [internal/tooling, internal/docs]
      deny_repos: [internal/billing, internal/auth]
      require_approval_for: [merge, force_push, delete_branch]

Three principles here matter more than the syntax:

1. Default deny, explicit allow. Every tool is off unless listed.
2. Approval gates on destructive actions. A human sees a diff before a merge, always.
3. Structured audit logs. Every tool call is JSON, timestamped, attributable to a task_id and user.

The audit log is what turns "agents did something weird last week" into a diffable, greppable record you can actually debug. Without it, you're guessing.

Multi-model architectures without the sprawl

Nobody serious runs one model for everything anymore. The economics are too different across models, and the capabilities cluster around task types. But most teams get to three or four models and lose the plot on routing, fallback, and cost attribution.

A workable router pattern:

ROUTING = {
    "classify_intent":    ("haiku",  {"max_tokens": 200}),
    "extract_structured": ("gpt-4o-mini", {"json_mode": True}),
    "plan_and_reason":    ("sonnet", {"max_tokens": 4000}),
    "write_code":         ("sonnet", {"max_tokens": 8000}),
    "review_code":        ("opus",   {"max_tokens": 4000}),
    "embed":              ("local-bge", {}),
}

def route(task_type: str, payload: dict, budget: TaskBudget):
    model, params = ROUTING[task_type]
    try:
        return call_model(model, payload, params, budget)
    except (RateLimitError, ProviderDown):
        fallback = FALLBACK_CHAIN[model]
        return call_model(fallback, payload, params, budget)

Rules that keep this from collapsing into chaos:

• Route by task type, not by "which model is best today." Task-to-model is stable enough to codify. Model choice per task changes quarterly.
• Every route has a fallback. Provider outages are a normal Tuesday.
• Attribute cost to task_type in your metrics. When your bill jumps, you want to know it was review_code calls that doubled, not "AI spending."
• Cache aggressively. Prompt caching alone can cut costs 40-70% on repeated system prompts — check current pricing pages for the exact discount, but the pattern applies across major providers.

The one anti-pattern to avoid: letting each engineer pick their own model per PR. You end up with a bill you can't reason about and behavior you can't reproduce.

Who cleans up when agents ship bad code

This is the question that separates teams doing agent development from teams cosplaying it. When an agent writes a migration that locks a production table for 40 minutes, or introduces a subtle race condition in payment code, someone has to own the cleanup — and "the agent did it" isn't a valid post-mortem.

The teams handling this well have converged on a few practices:

One human owner per PR, no exceptions. The agent drafts, a named engineer merges. That engineer owns the code exactly as if they'd written it. This kills the diffusion-of-responsibility problem before it starts.

Mandatory pre-merge checks that agents can't skip. Static analysis, type checks, integration tests, security scans. If the agent is fast enough to write ten PRs an hour, your CI has to be fast enough to reject nine of them.

Blast-radius aware deploys. Auto-merge for docs and internal tooling. Manual approval for anything touching customer data. Progressive rollout for backend changes. This isn't agent-specific — it's just discipline that agents make more important because volume is higher.

Post-incident tagging. Every incident gets a tag: agent-originated, human-originated, or mixed. Without this data, you'll spend a year arguing about whether agents are net positive. With it, you'll know in a quarter.

The cost/reliability tradeoff nobody talks about

There's a real tension in agent design that most vendor pitches gloss over: the cheapest agent runs are also the least reliable, and the most reliable runs cost 10-50x more per task. Reliability comes from multiple passes — plan, execute, verify, self-critique, retry — and each pass is more tokens.

A practical calibration:

• Draft/scaffolding tasks: single-pass, cheap model. ~$0.01-0.05 per task. Expect 60-70% acceptance.
• Production code changes: plan + execute + self-review + test-run loop. ~$0.30-2.00 per task. Expect 85-90% acceptance.
• High-stakes changes (auth, billing, migrations): full plan + execute + adversarial review + human gate. ~$3-15 per task. Expect 95%+ acceptance, but human still reviews.

Note these are order-of-magnitude ranges from operating agent stacks — your numbers will differ based on codebase size and model choice. The point is that reliability isn't free, and picking one budget tier for all tasks either burns money on trivial work or ships bugs on critical work.

What to instrument before you scale

If you're about to 10x your agent usage, the instrumentation you set up now determines whether the next quarter is a controlled rollout or a fire drill. Minimum viable telemetry:

{
  "task_id": "t_9f2a...",
  "parent_task_id": null,
  "user_id": "u_431",
  "task_type": "write_code",
  "model": "claude-sonnet-4-5",
  "input_tokens": 12400,
  "output_tokens": 2100,
  "cached_tokens": 8900,
  "cost_usd": 0.043,
  "latency_ms": 3200,
  "tools_called": ["read_file", "write_file", "run_tests"],
  "outcome": "merged",
  "human_approved_by": "eng_17",
  "retries": 0,
  "timestamp": "2026-09-22T14:22:11Z"
}

Ship one of these per agent task, land them in a cheap columnar store (Clickhouse, DuckDB, BigQuery), and you can answer every question that matters: cost per customer, cost per feature, retry rates by task type, which engineers are approving the most agent PRs, which tools are called most, which prompts have the worst cost-to-outcome ratio.

Without this, you'll argue in circles about whether the agent investment is paying off. With it, you'll have a dashboard that makes the answer obvious.

How BizFlowAI approaches this

We build agent stacks for small teams that need production-grade cost control and reliability without hiring an ML platform team. That usually means Claude Code as the engineering surface, MCP servers with default-deny policies wrapping every production capability, a task-typed router across models, and per-task budget caps that fail loud instead of quietly burning through your monthly cap. Every tool call is logged as structured JSON, so cost attribution and post-mortems are a query away instead of a scavenger hunt.

The clients who get real leverage from agents aren't the ones with the biggest budgets — they're the ones who set up the accounting and the guardrails before their token bill hit five figures. If you're already past that point and trying to reverse-engineer control, that's a solvable problem too. Book a discovery call and we'll walk your setup, find the top three cost leaks, and scope what a controlled rollout looks like for your team.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.