Open BurnBar
GitHub Download
The router · exact model failover · animated

Same model. Different account. Every time.

BurnBar's local router stretches one model across every account in your library that serves it. Your gpt-5.5 stays gpt-5.5. Your claude-opus-4-7 stays claude-opus-4-7. Default mode stays inside the selected provider family. Exact Model Failover can look wider, but only after the next route proves the same canonical model ID.

  • 127.0.0.1:8317 · local-only
  • two router modes · one daemon
  • canonical model id · fail closed
Locked-Model Relay — a model token labelled gpt-5.5 stays anchored at the top while five OpenAI-family accounts (OpenAI · personal, OpenAI · team, Codex · plus, OpenAI · agency, OpenAI · backup) cycle their availability below. The active routing pillar slides between healthy accounts every 2.4 seconds, demonstrating that failover swaps accounts without ever changing the model identity. Provider-Family Failover keeps the retry inside the selected provider family. Exact Model Failover can look outside that family only when the destination proves the same canonical model ID; every merely similar route is filtered out for a gpt-5.5 request.
  1. active route
  2. pressure
  3. rate-limited
  4. cooling · recovering
Download for macOS Read the gateway doc See today's rundown
The non-negotiable rule

Your model in. Your model out. Every path.

Three things can happen to a request in flight. Watch what each one does — or refuses to do — to the model identity you asked for.

02 · gpt-5.4 · exact

Exact mode: Factory Standard exhausted → OpenAI route, same canonical model.

model identity → unchanged swap · canonical gpt-5.4 → canonical gpt-5.4
03 · glm-4.6 · 503

No other account carries it → 503, never a swap.

model identity → unchanged swap · nothing — gate closes, IDE sees a clean 503

Implementation · ProviderRoutingPolicy.decide · BurnBarProviderRouter.scoreAndRankRoutes · fail-closed gateway responses

Two router modes · one invariant

Choose how far failover may look. The model still stays exact.

Provider-Family Failover is the conservative default: stay inside the selected provider family. Exact Model Failover is the opt-in expansion: BurnBar may cross to another provider or account, but only after it proves that route serves the same canonical model ID. Same gateway. Same accounts. A stricter proof gate before any wider retry.

01 · default · provider-family failover

Stay inside the selected provider family.

conservative capacity extension · no unrelated provider pool

Locked-Model Relay — a model token labelled gpt-5.5 stays anchored at the top while five OpenAI-family accounts (OpenAI · personal, OpenAI · team, Codex · plus, OpenAI · agency, OpenAI · backup) cycle their availability below. The active routing pillar slides between healthy accounts every 2.4 seconds, demonstrating that failover swaps accounts without ever changing the model identity. Provider-Family Failover keeps the retry inside the selected provider family. Exact Model Failover can look outside that family only when the destination proves the same canonical model ID; every merely similar route is filtered out for a gpt-5.5 request.
  1. active route
  2. pressure
  3. rate-limited
  4. cooling · recovering
  • Your selected family is the boundary. A Codex route stays with Codex accounts, a Claude route stays with Claude accounts, and a Z.ai route stays with Z.ai accounts.
  • Your active route wins while healthy. The exact selected account and model stay active until quota, rate-limit, or availability state forces a retry.
  • Account-level capacity. Add a second subscription or key in that provider family and BurnBar can hold it as the runner-up.
  • Never a generic coding bucket. Provider-family mode does not send Claude traffic to Z.ai or Codex traffic to Claude just because a different account has quota.

On by default. No client changes needed.

02 · opt-in · exact model failover

Cross providers only when the model identity matches.

canonical model proof · fail closed if proof is missing

  • The request creates a required canonical model ID. If you ask for gpt-5.4, eligible routes must prove gpt-5.4.
  • Cross-provider is allowed only after proof. BurnBar may move from Factory, OpenAI, Codex, or another account only when the destination serves that exact canonical model.
  • Similar does not count. gpt-5.4-mini, gpt-5.4-pro, gpt-5-family, and broad classes like openai:standard are rejected as substitutes.
  • Missing proof fails closed. If BurnBar cannot prove exact identity, the gateway returns a structured 503 instead of guessing.
  • The audit trail says what happened. Events record the attempted model, canonical ID, original route, destination route, reason, and whether the invariant passed.
See the exact-model test
Exact Model Failover

Cross-provider failover has to pass one simple test.

BurnBar does not ask "is this model similar?" or "is this provider good enough?" It asks a narrower question: can the destination route prove the same canonical model ID as the request? If yes, it may recover the request. If no, it stops.

  1. 01

    Start with the requested model.

    The incoming request creates a required identity. A direct request for gpt-5.4 requires canonical gpt-5.4. The router carries that value through ranking, retry, and audit.

  2. 02

    Accept only exact catalog proof.

    Explicit canonicalModelID wins. Otherwise direct catalog IDs count. Wrapper families count only when they have one unambiguous exact alias, like factory-gpt-5.4-family resolving to gpt-5.4.

  3. 03

    Reject anything that merely looks close.

    gpt-5.4-mini, gpt-5.4-pro, gpt-5-family, openai:standard, benchmark picks, and "similar" matcher hits are not exact proof. They stay advisory and never open the failover gate.

  4. 503

    No proof means no winner.

    If the primary route is exhausted and no exact canonical match remains, BurnBar returns a structured unavailable response. That is deliberate: a clean failure is safer than a quiet model change your agent did not ask for.

Model board · daily

Today's board verdict — model research, not failover permission.

Every twenty-four hours a board of language models runs research and analysis tasks against the model-landscape snapshot. The result is frozen, dated, and inspectable — the daily archive at /router/daily holds 12 of them. Below: today's top coding candidates, with source freshness and the deterministic selection score shown alongside. These rankings are advisory; they never prove that a failover destination is the exact same model.

model board running research

Today · Coding 2026-06-12

Today's pick: GPT-5.5 xhigh — stable favorite rank #1 under 2026-05-13.stable-favorites; preferred reasoning effort xhigh; led the benchmark composite at 55/100; evidence is fresh; context window of 400k clears typical large-context work; runner-up Claude Opus 4.7 is held in reserve for instant failover.

  • AA
  • TB
  • DA

A board of language models runs the daily research pass, then BurnBar reduces the findings to a deterministic selection score. Runtime pins, auth, quota, safety, availability, and exact-model failover rules still override the ranking.

  1. #1 GPT-5.5 xhigh OpenAI ctx 400k 99 selected
  2. #2 Claude Opus 4.7 Anthropic ctx 1M 96
  3. #3 GLM 5.1 Z.ai ctx 256k 93
Browse the daily archive
Shipping (per-device QA matrix)

Google Nest Hub

Google · 7-inch smart display · Cast V2

BurnBar casts a live provider dashboard to the Nest Hub on your kitchen counter. Refresh, brightness, theme, and provider filter are all controlled from the Mac app.

  • Cast V2 + Home Assistant blueprints — no third-party server
  • Provider rail, big-total, ambient, photo-blend layouts ship today
  • Acceptance probe before "healthy" — `docs/SMART_DISPLAY_DEVICE_QA.md`
Shipping (per-device QA matrix)

ULANZI TC001

Pixel clock · 32×8 LED matrix · AWTRIX HTTP

A faithful 32×8 LED matrix render — same glyph tables, same palette, same per-pixel glow blur the BurnBar daemon paints to AWTRIX firmware.

  • AWTRIX HTTP — works on stock or community firmware
  • Four layouts · provider dashboard, quota carousel, burn status, alerts
  • Ember & whimsy palette by default · five palettes ship

See every BurnBar surface →

What BurnBar will not do

Four bright lines we don't cross.

A router that's allowed to do anything is a router you can't predict. These are baked into the policy — not promises, code.

  • Will not swap your model on failover.

    Exact Model Failover drops every candidate route whose canonical model ID does not match the requested one. If no candidate survives, the gateway returns a structured 503 — your IDE sees a clean error, never a silent substitute.

  • Will not collapse accounts into a generic quota pool.

    Each account keeps its own bucket, its own cool-down clock, its own decision history. You added them separately because they cost and throttle differently — the router treats them that way.

  • Will not log secrets.

    The local decision stream records the chosen account ID, the skipped ones, and the reason each was skipped. It never records the API key, the OAuth bearer, the request body, or the response body. Keys live in the macOS Keychain, device-local.

  • Will not treat benchmarks as absolute truth.

    Benchmark snapshots feed the daily model board and inform deterministic recommendations. They never prove exact model identity. They never override a pin. They never beat live quota state. A model that benchmarks higher but is rate-limited right now still loses.

State Simulator & Playground

Interactive Account Lifecycle Playground.

The OpenBurnBar router dynamically tracks, scores, and re-ranks accounts in real time. Select a scenario below to watch how the local router executes failover paths, handles 429 rate limits, and triggers recovery, in a live-scrolling console.

SCENARIO:
SPEED: 1.0x
pressure cooling-down 5-min auto rate-limited 429 · cool unknown healthy serving exhausted limit hit disabled auth-failed expired 401 swap keys user action
BURNBAR ROUTER CONTROL SIMULATOR v1.0.4
ONLINE
Quick answers

The questions we get on every demo.

Will failover ever change my model?
No. Failover stays inside the model identity you asked for. If you sent gpt-5.4, the router must prove the destination route serves canonical model gpt-5.4. If no eligible account exists, BurnBar returns a structured 503 — never a silent substitute.
What is Provider-Family Failover?
The default mode. BurnBar extends capacity inside the provider family you selected. A Codex route stays with Codex accounts, a Claude route stays with Claude accounts, and a Z.ai route stays with Z.ai accounts. It does not treat unrelated providers as one generic coding quota pool.
What is Exact Model Failover?
The opt-in mode for wider failover. BurnBar may try another provider or account after quota, rate-limit, or availability failure — but only if that destination proves the same canonical model ID as the request. gpt-5.4 can move to another route that truly serves gpt-5.4; it cannot become gpt-5.4-mini, gpt-5.4-pro, gpt-5-family, or a generic openai:standard route.
What counts as proof of the same model?
Explicit canonicalModelID wins. Otherwise BurnBar uses the real catalog model ID for direct models. Wrapper entries only count when they have one unambiguous exact alias, such as factory-gpt-5.4-family resolving to gpt-5.4. Broad capability labels, benchmark recommendations, and matcher-only similar models do not count.
Is the daily model board a failover mode?
No. The daily model board is advisory research: it explains model-landscape recommendations, source freshness, and why certain models look strong for a task. It does not grant permission to silently swap the model on a failed request. Provider-Family Failover and Exact Model Failover are the runtime modes.
What benchmark sources does BurnBar use?
Artificial Analysis (intelligence + coding indices · pricing · TPS), Terminal-Bench via Hugging Face (verified shell-loop agents), and Design Arena (pairwise Elo). Manual cached fixtures cover gaps. Every signal carries a freshness state — fresh / stale / unavailable / error / manual — surfaced in /router/daily. Those signals are advisory; they are never proof of exact model identity.
Can I pin a model in either mode?
Yes. In Provider-Family Failover, the pinned account stays active while healthy and the runner-up is selected inside that provider family. In Exact Model Failover, the pin still wins while healthy; only recoverable failures open the door to another provider/account, and only after the canonical model ID matches.
Are routing logs safe?
Yes. The local ProviderRoutingDecisionEvent stream records the chosen account ID, the skipped account IDs, and the reason each was skipped — never API keys, OAuth bearers, request bodies, or response bodies. Logs stay in the local SQLite store.

Pick the failover boundary once. Let the daemon enforce it.

Use Provider-Family Failover for conservative same-provider recovery, or Exact Model Failover when you want BurnBar to recover across providers without ever changing the canonical model.

Download for macOS Read the gateway doc Browse the daily rundown