Responses
ChatGPT / OpenAI-compatible
USE CASE
Le failover est une liste sur le runtime, pas un rewrite UI. Même session.send, mêmes types d’événements.
Le failover est une liste sur le runtime, pas un rewrite UI. Même session.send, mêmes types d’événements.
Le failover est une liste ordonnée d’IDs catalogue. Basculez ChatGPT, Claude, une URL perso ou DeepSeek sans réécrire session.send.
Responses
ChatGPT / OpenAI-compatible
Anthropic
Claude / messages API
failover_ids
ordered list on the runtime
Swap a provider and teams rewrite the stream parser, the tool-call dialect, and the UI status. Failover becomes a second client path. The visitor sees a restart. Sveda keeps session.send and the same event types. The catalog walks an ordered list.
Responses in one module, Anthropic in another, a third for the UI. Failover means picking a different frontend.
The host catches a 5xx and calls send again. Tokens already streamed are lost. Chat state forks.
Model URLs and secrets leak into the client so the browser can “choose a backup.” The runtime should own the chain.
Primary is whichever catalog id you set. Builtin wrappers (including DeepSeek) sit beside ChatGPT, Claude, and custom Responses or Anthropic URLs. failover_ids is an ordered list. The client still calls session.send. Events do not change.
The runtime builds a stream chain from the primary plus failover_ids. Duplicates are skipped. Unknown ids are skipped.
The catalog takes custom Responses or Anthropic URLs. You are not locked to one vendor hostname.
The host does not learn a failover API. session.send is the turn. The SSE event list does not restart as a new product.
FAILOVER PATH
The default chain is whatever you put first, then failover_ids. That is not a marketing “99.9% uptime” claim, and not a rewrite of the client. If the primary cannot stream, the runtime walks the next id.
Put more ids on failover_ids when you add custom endpoints. The chain is ordered. The UI does not pick the backup.
The models page and the models docs list catalog ids and SVEDA_FAILOVER.
Client still session.send. Event names unchanged.
await session.send(text)
Accept: application/vnd.sveda.stream+json
message.start
text.delta
tool.call → tool.result
message.end
SAME WIRE
The host may pass model or provider on a turn. Failover is still the ordered list on the runtime. The JS client does not grow a backup send() or a second Accept header. Custom endpoints are catalog rows, not a new protocol for the page.
This is developer infrastructure: a catalog, a chain, a stream. Not a SaaS chatbot with a status badge and a fabricated conversion lift.
Pair with the stream protocol and stream docs. The copilot path is still session.send on the host you already have.
Product copilot
Same session.send. Failover does not change the attach path.
Code agent
Index tools stay in the catalog while the model list walks.
Host MCP
HTTP tools stay attached across the failover chain.
Models
ChatGPT, Claude, custom URLs, ordered failover_ids.
Stream protocol
Event names stay put when the provider changes.
Models docs
Catalog ids, protocols, SVEDA_FAILOVER.
Stream protocol docs
SSE framing and the closed event list.
JS client docs
session.send is still the turn after a failover.
ChatGPT, then Claude, then your failover_ids. The stream events do not get a new name.