Skip to content

USE CASE

If a provider drops, the stream continues.

Failover is an ordered list on the runtime, not a rewrite of the UI. The same session.send, the same event types, the next model in line.

Ordered fallback

Configure an ordered model list on the runtime. When a provider errors, sveda-server tries the next row without forcing the client to reopen the stream.

Responses

ChatGPT / OpenAI-compatible

Anthropic

Claude / messages API

failover_ids

ordered list on the runtime

The challenge of provider lock-in

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.

A parser per protocol

Responses in one module, Anthropic in another, a third for the UI. Failover means picking a different frontend.

Retry in the page

The host catches a 5xx and calls send again. Tokens already streamed are lost. Chat state forks.

Keys in the widget

Model URLs and secrets leak into the client so the browser can “choose a backup.” The runtime should own the chain.

How Sveda solves it

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.

Ordered catalog

The runtime builds a stream chain from the primary plus failover_ids. Duplicates are skipped. Unknown ids are skipped.

  • SVEDA_DEFAULT_MODEL sets the primary
  • SVEDA_FAILOVER overrides the ordered list
  • ChatGPT, Claude, or a custom URL are catalog rows
  • DeepSeek wrappers are optional builtins
  • Unknown ids are skipped

Custom endpoints

The catalog takes custom Responses or Anthropic URLs. You are not locked to one vendor hostname.

  • Protocol is Responses or Anthropic — not a third dialect
  • Custom entries speak those URLs from settings
  • Same tool-call path on the runtime
  • Swap a provider in the catalog, not in the UI
  • Keys stay on sveda-server

Same client, same events

The host does not learn a failover API. session.send is the turn. The SSE event list does not restart as a new product.

  • Client still calls session.send
  • Accept is still application/vnd.sveda.stream+json
  • message.start, text.delta, tool.call, message.end stay the names
  • Frontend tools keep the same registry
  • No second widget for the backup model

FAILOVER PATH

Primary, then the next id in line.

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.

FAILOVER PATH ordered
  • ChatGPT primary
  • Claude failover
  • Custom URL catalog

Client still session.send. Event names unchanged.

CLIENT unchanged

await session.send(text)

Accept: application/vnd.sveda.stream+json

message.start

text.delta

tool.call → tool.result

message.end

provider walk runtime

SAME WIRE

Do not rewrite the stream to change a model.

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.

Related

Change the catalog. Keep session.send.

ChatGPT, then Claude, then your failover_ids. The stream events do not get a new name.

Get started