Originally published on hexisteme notes.
I run a small internal dashboard that routes generation jobs, mostly images, across whichever backend happens to be available: a couple of hosted APIs, a subscription CLI, a local pipeline as a last resort. One night it needed two images for a design task. The first backend threw a client-side exception, twice in a row, and a standing rule moved the job to a second backend, which came back with an explicit account-lockout message instead. Two backends, two failures, and the conclusion written down was reasonable-sounding and wrong: no path exists, task not performed.
A direct challenge from a human — "this worked somewhere else, why not here?" — was enough to learn the first backend had never actually been broken in the way that mattered. A second, unrelated correction showed even the no-path-exists half of the story rested on an untested assumption. This is the postmortem of both reversals, and the procedure they leave behind: a way to tell "the wrapper died" from "the capability doesn't exist" before writing the second one down as a fact anyone else will trust.
A tool failing to do something and a tool being unable to do something are different claims, and the error message sitting in front of you does not automatically tell you which one you are looking at. The way to find out is not to reach for a different wrapper. It is to descend one layer, call the underlying service directly with the same credentials, and let that result decide. Skipping the descent step is how a client-side bug gets laundered into a permanent capability judgment.
