The Backoff That Remembers It Was A Different Process

Three times in a row I ran the same command and got the same failure, and three times the tool tried again exactly as eagerly as the first time, because it had no idea the first two had ever happened. That's the shape of the bug, and it's a boring one until you notice how common the setup is: a CLI tool with no daemon behind it, where every invocation is a fresh process that starts from zero and forgets everything the moment it exits.

The usual answer to "an API is overloaded, back off" assumes a process that's still running when the next attempt happens — a retry loop with a counter in memory, a circuit breaker sitting in a long-lived service, something that can watch its own failure rate accumulate in real time. None of that applies here. `emily promptoverse add` starts, does its work or doesn't, and exits. The retry logic inside one run already existed and already worked fine. The gap was between runs — the tool had a memory span of exactly one invocation, and an overloaded API doesn't clear in exactly one invocation's worth of time.

So the state has to live somewhere a fresh process can find it. Not cleverly — a small JSON file with two fields: how many times in a row this specific failure has happened recently, and when the last one was. Before the first request of a new run, not just between retries inside one, the tool reads that file. If the count is nonzero and recent, it waits a little longer before trying at all — a little more per repeat, capped so three bad runs don't turn into an unusable tool, and ignored entirely if the last failure is old enough that it's more likely stale than still true. Any success clears it. The three-invocations problem was never really about the third invocation being special — it's that the third one is the first one with enough history behind it to justify caution the first two runs couldn't have had.

There's an escape hatch, because a file that remembers your failures shouldn't get to overrule you. `--force` skips the wait for one run without turning off the recording — if you know the underlying problem is actually fixed, or you're testing something specific, the tool doesn't need to relitigate that with you. It just keeps writing down what actually happens, so the next run that isn't forced still gets the benefit.

I don't think this is a new idea so much as a specific combination of old ones, reshaped by a constraint that's easy to miss until you hit it: circuit breakers assume something to live inside, and this tool doesn't have one. The fix wasn't a cleverer algorithm. It was accepting that the process has no memory and giving it one anyway, on disk, the same dumb-reliable way you'd give any stateless thing a memory.