Handing the commit button to agents does not just change how code gets written. It quietly rewrites your build cost model, and the multiplier is no longer you.
Author: James Phoenix | Date: July 2026
A $74 Invoice for a Guard That Was Meant to Save Money
I opened a Vercel invoice for $74 on a project that should have cost a few dollars a month. Nothing about the app had changed. What had changed was who was pushing commits.
The question I asked mid-debug was blunt: “Is the main problem that I was simply committing too frequently because of agents now?” The answer was yes. Once agents drive the commit button, every per-build inefficiency gets amplified five to ten times, and costs that used to be rounding errors become line items.
The Multiplier Is the Agents
A human pushes maybe 5 to 10 commits a day to a staging branch. Agents running loops, worktrees, and canary suites push 30 to 50. That is not a productivity brag, it is a cost coefficient. Any waste that scales per build is now scaling against the agent’s commit rate, not yours.
In my case a build-skip had quietly stopped working, so staging rebuilt the web app on every push. At a human’s cadence a broken skip costs about $5 a month and you never notice. At the agent’s cadence the worst case was $19 a day, and the pipeline looked healthy the whole time: green checks, successful deploys, no errors. It just ran the expensive path every time.
The lesson is not “agents are expensive.” It is that when you hand agents the commit button, you have to re-audit every per-build cost, because the thing multiplying it changed and nobody repriced the ledger.
Cost Guards That Fail Open Are Silent Leaks
The skip ran as turbo-ignore in Vercel’s ignoreCommand, and it had started crashing. A crashed ignoreCommand returns a non-zero exit code, which Vercel interprets as “run the build.”
The guard whose entire job was to prevent expensive builds, when it broke, defaulted to running them. It failed open. A broken guard and a working pipeline look identical: builds happen, deploys succeed. The only difference is the invoice, and it arrives a month late.
This generalises past Vercel. Any optimisation gate whose failure mode is “do the expensive thing” needs its own monitoring, separate from the thing it guards. A guard you cannot see failing is one you should assume is failing.
The Guard Could Never Have Worked There Anyway
The crash was structural, not a bug I could patch. Vercel’s ignoreCommand runs in a stripped sandbox with no git binary and no VERCEL_GIT_* variables; those only decrypt for the real build phase. So turbo-ignore and every hand-rolled git diff skip script are impossible there by design. They were reaching for git that was not present.
The fix was to stop asking the build host to decide. I moved deploys into GitHub Actions with a path filter and pushed with vercel deploy --prebuilt, a direct upload that bypasses ignoreCommand. Now the decision runs where the git history actually is, and the deploy is a dumb upload. Put the decision where the information lives, not where the platform happens to run your hook.
The Same Story in the Lint Bill
It does not stop at deploys. A lint layer had crawled to 114 seconds and the instinct was to rewrite the tool. Profiling said otherwise: 98% of the critical path was one type-aware rule grinding for 83 seconds on a single 43,000-line generated OpenAPI file, producing zero findings.
The tool was never slow. One pathological input was, and it existed because agents generate large files. Exempting generated files from type-aware linting halved the run. Before you rewrite an engine, profile it: the real cost is usually a pathological input, not the tool. Multiply an 83-second no-op by 30 to 50 runs a day and you have rebuilt the $74 invoice in wall-clock instead of dollars.
One Shared Runner Serialises Everything
The last flavour is latency, not money. A single self-hosted runner turns every workflow into one global queue. In one loop, rapid iteration on an unrelated docs deploy monopolised the runner and starved the integration tests for over 30 minutes. My feedback latency was hostage to whatever grabbed the runner first.
At human pace you rarely collide with yourself; at agent pace, collisions are the default. Shared-runner concurrency is an invisible dependency chain, and agents are the workload that saturates it.
The Rule I Now Follow
When you let agents drive CI, three things become non-negotiable:
- Re-audit every per-build cost. The multiplier is now 30 to 50, not 5 to 10. Costs you rationally ignored are now real.
- Monitor any gate whose failure mode is “spend money.” Fail-open guards are indistinguishable from working ones until the invoice lands. Alarm the guard, not just the build.
- Watch the leaf, not the plumbing. A green pipeline proves the pipeline ran. It does not prove the skip skipped, the cache hit, or the runner was free.
This is why agents working while you sleep and throughput-first merging are so powerful and so quietly expensive: agent velocity is the whole value proposition and the coefficient on every inefficiency you never fixed. See also Cost Protection with Multi-Layer Timeout Limits for the LLM-spend version, The Six-Layer Lint Harness for scaling lint under agent load, and CI/CD Patterns for AI Agents.
Agents did not make my CI more expensive. They repriced the mistakes I was already making, and handed me the bill.
