Size the Fuse to the Furnace, Not the Candle

The principle: a global safety limit must be calibrated against your heaviest known run before you trust it, not against a vendor's idea of a typical one.

I adopted a runaway-cost fuse this week. It is a small, well-built tool: it watches token spend and halts the session if spend crosses a ceiling. Exactly the kind of backstop you want when you are handing schedules to autonomous agents that run while you sleep.

It shipped with a default ceiling. The default was set to halt a session at roughly fifty dollars of spend. Sensible-looking number. Round, conservative, the sort of figure a careful vendor picks so the tool never embarrasses anyone with a surprise bill.

I almost installed it on the default and moved on. Then I checked it against the one number I actually had: what had this session already cost.

The measurement that saved me

The session I was sitting in, the one doing the adoption work, had already run to about eighty-two dollars and seventy-four million tokens. Not a runaway. Not a bug. A normal heavy day: multi-agent fan-out, large context, real work across a dozen desks.

So the default ceiling was not a safety net. It was a tripwire set below my own footstep. Had I installed the fuse on its shipped value, it would not have caught a runaway. It would have halted a healthy, productive, intended session partway through and left me debugging a "failure" that was nothing but a guard set too low.

I sized the real ceiling against the heavy session, with headroom, and installed it there. The fuse now protects against genuine runaways without firing on a normal hard day. The economics of running agent fleets at this intensity is its own subject, one I covered in token economics: build once, run forever; the guard exists to protect that model, not to fight it.

The named lesson

Calibrate a global guard against a known-heavy instance before you size it. The dangerous default is not the one that is too loose. It is the one that is too tight to survive your normal worst case.

We worry about guards that are too generous: the limit that never fires, the alert that never trips. Those are real, but they fail quietly and you keep working. The guard that is set too tight fails loudly and at the worst moment: it interrupts legitimate work, presents itself as a system failure, and trains you to distrust or disable the very protection you installed. A safety mechanism that cries wolf gets switched off, and then you have no safety mechanism at all.

The vendor's default cannot know your worst case. It is picked for a median user doing median work. Your heaviest legitimate run is a fact only you hold. So the calibration step is not optional polish. It is the difference between a fuse that protects you and a fuse that sabotages you.

This is not just about cost

The shape repeats anywhere a single global limit sits above a population of jobs of wildly different size:

• Timeouts. A request timeout set to the median request will strangle the legitimate slow one: the big export, the cold-cache first call, the end-of-month batch. Size it against the slowest call you actually intend to allow.
• Rate limits. A per-minute cap tuned to typical traffic throttles your real peak: the launch, the campaign send, the migration backfill. Size it against the peak you plan to run, not the average you usually run.
• Memory and disk ceilings. A container limit set to the average working set gets killed by the one job that legitimately needs three times the room.
• Budget alerts. An alert threshold below your real monthly spend turns into noise you mute, and a muted alert is a deleted alert.

In every case the trap is the same: the limit was sized against the candle when the system routinely runs the furnace. The first time the furnace lights, the limit fires, and you lose either the work or the guard.

How to do the calibration

It is one cheap step, and the cost of skipping it is exactly the incident the guard was supposed to prevent, inverted.

1. Find your heaviest legitimate instance. Not hypothetical. Measured. The biggest real export, the longest real session, the largest real batch you have actually run and intended to run.
2. Add headroom. That instance is your floor, not your ceiling. Heavy-but-normal will get heavier. Multiply by a comfortable factor so the guard sits clearly above your worst intended case.
3. Set the guard there, and write down why. The number will look large to the next person who reads it. Leave the measurement next to it so they do not "helpfully" tighten it back to the default and reintroduce the tripwire.

The whole exercise took me one measurement I already had in hand. The session told me its own cost. I just had to look before I trusted the default.

The smaller habit underneath

There is a quieter discipline here that pays out far beyond fuses. Before you accept any default that gates your work, measure your real load against it. Defaults are guesses made by someone who has never seen your workload. Most of the time the guess is fine. The times it is not, it fails in the most expensive way available: it stops good work while looking like the good work was the problem.

A fuse exists to protect the furnace from a fire. Size it to the candle and the first honest day's heat will blow it, and you will spend the morning wondering why the lights went out when nothing was wrong.

Part of the Operating Principles series from KG Consultancy.