Build1 publisher3 min readPublished
A sixty-line route table pins the two vendors an overnight LLM batch is allowed to reach
An engineer's overnight batch on a prepaid account failed over onto a vendor key added months earlier for a one-off evaluation, and the audit question that followed took longer to answer than the outage.
The Engineer · Build desk

What happened
- An engineer writing on dev.to runs an overnight batch that regenerates product copy and triages return requests, both reaching a model vendor through one internal routing service that owns the API credentials.
- The first guard on the prepaid account was an alert: when the balance dropped under 20 percent a webhook fired and someone topped it up.
- Answering which vendor had seen the batch's free-text return reasons meant rebuilding the provider registry as it stood at 03:14 out of deploy history and environment snapshots.
- The replacement gateway is about sixty lines of policy checked into git and reviewed like a schema migration, with secrets referenced by name and resolved at call time.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A subtraction policy widens the permitted spend surface on its own each time the router gains a provider, while an allowlist widens only when someone edits a file and gets the commit through review.
- capability Refusing to start a batch the remaining balance cannot finish turns an overnight prepaid exhaustion into a stop before work begins instead of a partly processed queue.
- exposure Customer free text reaches whichever provider the failover picks, so the contents of the credential registry decide who processed the data that night.
- decision Teams now have to choose how deep to pin: the vendor and credential line up with a contract and a bill, while a pinned model id imports the vendor's retirement schedule as maintenance work.
Before the gateway opens a socket it resolves the route by id, refuses any id that is not in the table, and refuses to start a batch that the remaining balance cannot finish [16]. The author says the third check is the one people skip, and that it buys a clean stop instead of a half-processed queue [16]. The alert it replaced fired at 03:14, exactly as designed. The retry loop was not reading the channel [3][4].
The table is what makes the permitted spend countable. Its two entries carry monthlyCapUsd fields of 400 and 150 [15], so the reviewed ceiling for the whole gateway is 550 dollars a month [20]. A subtraction policy leaves that ceiling unwritten. It defines the allowed set as everything nobody has thought of yet, and each provider the router gains adds a credential, a billing identity and a spend path that no one reviewed [9]. Secrets appear in the table only as a name such as LLM_KEY_VENDOR_A and are resolved at call time. The post says that is the OWASP baseline, and also what makes the route table safe to log [13][14].
On the night in question the router failed over, the exclude rule said "not vendor X", and the job retried. Resolution landed on a provider whose key had been added months earlier for a one-off evaluation and never removed [5]. "Nothing was broken. The policy allowed it, because the policy was written as a subtraction," the author wrote [6]. The money was bounded, since that is what prepaying buys [19]. The expensive part arrived two weeks later, when the returns team asked which vendor's servers had seen the free-text return reasons from that batch [7]. The post does not put a dollar figure on the night or an hour count on the follow-up work [21].
An allowlist does not close this by itself. A stale entry in the table would take a failover the same way the stale key did, and the argument for the allowlist is an argument about people: "An exclude rule that nobody can explain stays forever, because deleting it looks risky and nobody can prove what it was protecting against," the author wrote [11]. The claimed asymmetry is that an allowlist entry nobody can explain gets deleted in review [22]. The evidence offered for it is one incident at one storefront [1].
The vendor is the right thing to pin because it is the boundary that maps onto a contract, a data processing agreement and a bill, which the model id does not [18].
For the balance check to transfer, the account has to be prepaid, so that there is a remaining balance to read at dispatch time [1]. The credentials have to sit in one routing service, so that the checked-in table is the effective allowed set [2]. If the account is invoiced monthly instead, the dispatcher has no balance to compare against at 03:00, and the per-route monthlyCapUsd field is the only ceiling left [15].
What to watch
- Whether any team other than this storefront reports the same post-incident cost of an implicit allowed set, since the account rests on one night's failure.
- Whether the monthlyCapUsd values are enforced at dispatch or only recorded in the checked-in route table.
- Whether the gateway keeps resolving once vendor-b retires the triage-medium default the standby route names.