Feature: configurable failover reasons

[a-bali]

As per the docs, failover currently only happens in case of 5xx and 429 errors. OpenCode seems to return 400 in case of temporary upstream issues (see request & log below); would it be possible to extend failover reasons or make them configurable?

{"time":"2026-07-28T06:06:38.074537266Z","level":"WARN","msg":"request failed","type":"invalid_request_error","status":400,"message":"Error from provider (Console Go): Upstream request failed","provider":"open
code_go","code":"invalid_request_error","method":"POST","path":"/v1/chat/completions","request_id":"c97141be-c4ed-4f2b-aa69-c17ffe6a62f4"}
{"time":"2026-07-28T06:06:38.075040719Z","level":"INFO","msg":"REQUEST","method":"POST","uri":"/v1/chat/completions","status":400,"latency":"553.201393ms","host":"ai","bytes_in":"1485","bytes_out":157,"
user_agent":"OpenAI/Python 2.24.0","remote_ip":"10.244.0.37","request_id":"c97141be-c4ed-4f2b-aa69-c17ffe6a62f4"}
{"time":"2026-07-28T06:06:38.669617633Z","level":"WARN","msg":"request failed","type":"invalid_request_error","status":400,"message":"Error from provider (Console Go): Upstream request failed","provider":"open
code_go","code":"invalid_request_error","method":"POST","path":"/v1/chat/completions","request_id":"eb834987-9e89-419d-bf04-da47a6d7044b"}
{"time":"2026-07-28T06:06:38.670858768Z","level":"INFO","msg":"REQUEST","method":"POST","uri":"/v1/chat/completions","status":400,"latency":"578.032008ms","host":"ai","bytes_in":"1240","bytes_out":157,"
user_agent":"OpenAI/Python 2.24.0","remote_ip":"10.244.0.37","request_id":"eb834987-9e89-419d-bf04-da47a6d7044b"}

Note that the actual model targeted by the virtual model does have failover targets set:

[SantiagoDePolonia]

@a-bali Thank you for reporting.

This should be fixed and released - v0.1.63 . Let me know how it works for you.

You are almost right that "... failover currently only happens in case of 5xx and 429 errors". There is also a couple of conditions not related to the status code (as visible on the screenshot). I've added a new one to fix your case.

Those exceptions exists because - as you have noticed with opencode go - the providers APIs are not perfect (sometimes return inappropriate HTTP status codes). With this fix we can somehow make it working for them :)

[a-bali]

Following up on this, it works for the original case, but is there a reason for not allowing extension of failover reasons? For example, opencode now came up with 403 to notify about an opt-in necessity. Honestly, I would prefer GoModel to just fail over in any case.

[SantiagoDePolonia]

I've reopened it and will think about it soon.

[a-bali]

Thank you. I would extend this idea even further: would be very nice if the failover and circuit breaker could trigger not only on errors but also on some sustained measurement of latency.

Use case: deepseek has been misbehaving via opencode (probably some kind of API problem), therefore the usual latency went up to minutes and sometimes failure. I decreased HTTP_TIMEOUT to avoid waiting for 10 minutes (the default) which helps but doesn't seem to trigger failover.

What would be great that if a model provides an average/p90/etc latency above a threshold over a certain period of time or number of requests, that would trigger the circuit breaker.

[SantiagoDePolonia]

AI generated summary:

All three requests from this thread are now in main:

1. Failover on more than 5xx/429 — fixed in v0.1.63.
2. Configurable failover reasons (the 403 opt-in case) — feat(failover): make retry statuses, error phrases, and max attempts configurable #798. failover.retry_on_statuses takes exact codes or whole classes, so [4xx, 5xx] fails over on any upstream error; failover.retry_on_errors matches a phrase in the error message regardless of status, if you'd rather target that specific 403. Docs: https://docs.gomodel.ai/features/failover
3. Failover on sustained latency — feat(resilience): open the circuit breaker on sustained latency #1063. Set resilience.circuit_breaker.slow_call_threshold (e.g. 60s, ideally with scope: model); calls answered slower than that count as breaker failures, and after failure_threshold consecutive slow or failed calls the circuit opens and traffic fails over immediately. It's off by default because healthy latency varies a lot by workload. Docs: https://docs.gomodel.ai/advanced/resilience#fail-over-from-a-slow-provider

Note that (3) uses a consecutive count rather than a p90/average over a window — a single fast answer resets it. That covers the DeepSeek case (every call slow) but would trip slowly on a provider that is slow only part of the time. If you hit that pattern, please open a new issue and we'll look at a sliding-window rate.

Closing; feel free to reopen if something above doesn't work for you on the next release. (0.1.94)