The Rs 100 cap that became Rs 10,00,000

A good incident write-up tells you what happened, what we got wrong, and what we changed. This one is mostly the second.

What happened

I set one AI worker's daily spend cap to Rs 100. Later it read Rs 10,00,000 on production. Two multiplications by a hundred had landed on it.

The reconstruction, from the incident document:

1. An earlier migration (an abandoned attempt to store costs more precisely) may have already multiplied the value by 100. Or a 60-second in-memory cache caused a race across two clicks, which both read a stale "rupees" flag. Either way, Rs 100 became Rs 10,000.
2. I clicked a "Convert to paise" button a second time, against an earlier warning not to. The guard only checked whether the flag already said "paise". It did not know the value had been changed by a separate mechanism. Rs 10,000 became Rs 10,00,000.

100 times 100 times 100 is 10,00,000, which matched the production value exactly. My own account of the sequence turned out to be right.

The wrong turn

A proposed fix was to divide the caps by 100 in SQL. I rejected it. A single division does not reverse a three-factor, non-uniform corruption, and it was a bandage on a bigger problem. I was right to refuse, and the reason mattered: the caps are human-set numbers, with no measured source to recompute from.

Costs themselves could be recomputed from token counts, since neither corruption touched those. The caps could only be flagged for me to re-enter.

The deeper defect

I asked Replit to prove that all the cost pages showed the same values. They did, but only by luck. Four pages each ran their own SQL and their own unit conversion for what should have been one number. The fix made one file the gatekeeper for reading spend. The call path that writes spend still had its own raw queries, and a schema comment still said "logical unit = paise", which was wrong.

What I asked

After the incident I asked, directly: Claude created the whole system, Claude broke it, Claude could not cleanly solve it, and now Claude is not sure its own proposed fix is foolproof. What is happening?

The answer was honest. The subsystem was built and repaired across many separate AI sessions, each with partial visibility into what the others had tried, reverted or half-finished. The root defect is an ordinary one: storing a money value whose unit depends on a separate flag read at runtime. A human team might well have made the same mistake. What was specific to this situation was the repair process: many stateless sessions, each reasoning from local context.

And the proposed fix was critiqued by its own author. Cowork found real gaps. Most of the controls in the proposal were documentation and process, and docs comments never enforce anything. A rigorous answer to "is this foolproof" was no, and here is why not.

What we changed

The recommended hard controls:

• Rename the columns so they stop implying rupees only, and store cost in paise with no flag.
• A ledger table that records one-time data migrations, so a migration can never run twice.
• Delete the unit-conversion machinery and the "Convert to paise" button. No soft deprecation.
• A CI grep that fails the build if the old column names reappear.
• A standing rule in the project instructions: AI costs are paise, display through one function.
• Reset all caps to NULL after migration and set them explicitly per worker.

The sequel

In November the caps changed again, now stored in micro-dollars. When Replit's publish applied its own schema diff, our backfill almost left every cap NULL. By then, NULL meant "uncapped", which is the opposite of the intent. The migration that fixed it is in the Replit post.

Two decisions from the July reset carried straight through: money units are not a runtime flag, and one place reads spend.

What's still open

Dollar and rupee conversion still has an open item: the code uses 83 rupees to the dollar and my own figures imply about 94.7. I have not resolved it.

Numbers at a glance