The reason your cost gate gets disabled: it fails on a +200% change that cost a fraction of a cent

Most CI cost gates get deleted because they fire on noise — a 10-to-30 token file is +200% but costs $0.00006. The fix is an absolute noise floor under the percentage gate (min-delta-tokens), not a bigger threshold.

The reason your cost gate gets disabled: it fails on a +200% change that cost a fraction of a cent

Every team that adds a CI cost gate hits the same wall in week one, and it’s the reason most of them quietly delete it in week two: the gate fires on noise.

Here’s the exact failure. You add a helper file. On the base branch it’s 10 tokens; on your PR it’s 30. That’s a +200% increase — three times the cost! — and a percentage gate set to “block if cost grows more than 20%” fails the build. Except the absolute change was 20 tokens. At Sonnet’s $3 / 1M input, that’s $0.00006. Your build is red over six thousandths of a cent.

Do that twice and nobody trusts the gate. The team adds continue-on-error, or rips it out, and now you’re back to shipping cost regressions blind. A gate that cries wolf is worse than no gate, because it trains everyone to ignore it.

The fix is a noise floor, not a bigger threshold

The instinct is to raise the percentage — block at 50% instead of 20%. That’s wrong: it makes the gate blind to the regressions you actually care about (a real 30% jump on a large file is now invisible) while still failing on a tiny base that doubles.

The right fix is an absolute floor underneath the percentage gate: only block when the token increase is at least N tokens AND exceeds the percentage. Small absolute changes never trip it, no matter how large the percentage looks; genuine regressions on real files still do.

In wartzar-bee/ci-guardrail that’s one input, min-delta-tokens, and it defaults to 100 — so the false positive is off out of the box:

- uses: wartzar-bee/ci-guardrail@v1
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    threshold-pct: 20        # block if cost grows >20% vs base...
    min-delta-tokens: 100    # ...but ONLY if the absolute jump is ≥100 tokens

Now the 10→30 helper sails through (20 tokens < 100 floor), and a file that genuinely grows 8k→12k tokens still fails the build (4000 tokens ≥ 100 floor, and +50% > 20%). The gate only speaks when it has something worth saying.

Two edges worth knowing:

  • The floor is on the percentage gate only. If you also set max-tokens or max-usd (absolute ceilings — “no PR over 200k tokens” / “no run over $0.50”), those are hard limits and the noise floor doesn’t soften them, by design. A ceiling is a ceiling.
  • Set min-delta-tokens: 0 to go back to pure percentage gating if you actually want that.

Why this is the difference between a gate that survives and one that doesn’t

Cost regressions in agent code are real — re-sending accumulated context, an extra tool round-trip, a prompt that grew — and they compound across every run. A gate is the only thing that catches them before they merge. But a gate only works if people leave it on, and people only leave it on if it’s right when it’s red. The noise floor is small, but it’s the difference.

ci-guardrail predicts a PR’s token-cost delta with tokenscope, comments the responsible files, annotates the exact hunks that grew, and blocks (or just warns) on your policy. It’s a GitHub Action — drop the YAML above in .github/workflows/ and it runs on the next PR.


wartzar-bee/ci-guardrail is MIT-licensed and on the GitHub Marketplace. It’s powered by @wartzar-bee/tokenscope (npx @wartzar-bee/tokenscope — reads your Claude Code logs, shows where the tokens went, nothing leaves your machine), which runs on the enclave runtime. wartzar-bee builds tools for operating cost-efficient autonomous agents.


Write a comment