Your AI Agent Might Be Answering With the Wrong Model. Mine Was.

If you run AI agents that do real work, here is a question worth losing sleep over. When your configured model gets rejected mid-request, does your stack tell you, or does it quietly answer with something weaker and let you believe nothing changed?

Mine didn't tell me. I run OpenClaw, an open source gateway that routes my agents across model providers, and I noticed responses that felt off. Not broken, just dumber than they should have been. When I dug in, the model I had configured, one of the gpt-5.6 tiers on the ChatGPT OAuth route, was being rejected by the provider at request time. OpenClaw caught the rejection and answered with a fallback model instead. No warning. The status command still claimed the primary model was resolving fine.

Why This Is Worse Than an Outage

An outage is honest. Things stop, you notice, you fix it. A silent downgrade is a lie your infrastructure tells you. Every output still arrives, formatted the same, signed by a model you didn't choose. In our world that matters because agents draft trading research, summarize filings, and monitor systems. A quietly weaker model produces quietly worse work, and you price that error in without knowing you should.

The bug had a second layer. The model catalog itself was dishonest. OpenClaw advertised the full gpt-5.6 lineup on the OAuth route whether or not your account was actually entitled to it. The models validated at config time, then the provider rejected them at request time with a 400. So you could configure a model, watch it pass validation, and never once get an answer from it.

File the Bug, Not the Tweet

I wrote it up as two GitHub issues against the project, #105445 and #106786, with reproductions and the exact failure path. Peter Steinberger, who runs the project, engaged directly and the fixes started landing within days.

Three real changes came out of it. Rejections that are actually usage limits now get classified structurally instead of guessed at, and the gateway rotates to a sibling auth profile on the same model before it ever considers falling back to a different one (PR #108254). The duplicate model catalog is gone, replaced by live account-backed discovery, so the list you see is the list your account can use. And the discovery handshake now reports the real client version instead of a placeholder (PR #108683), which was the root of models validating and then bouncing at request time. The static fallback catalog also stopped advertising premium tiers it couldn't prove you had.

The last piece, loud surfacing when a fallback actually fires, is still open and tracked. Two and a half out of three within a week is a better response than most commercial vendors give you.

The Takeaway for Anyone Running Agents

Trust in an AI stack is not about the model being smart. It's about the plumbing being honest. Audit what your gateway does when a provider says no. If the answer is "it handles it gracefully," ask what gracefully means, because in practice it often means silently.

And when you find something like this in open source software you depend on, file the issue with a real reproduction. Maintainers like Steinberger move fast when you hand them the failure on a plate. Complaining in a group chat fixes nothing. A good bug report upgraded the reliability of every OpenClaw install on the planet, including the three machines running this firm.