FAQ

Questions, answered.

The questions we hear most — grouped by what you're actually wondering about. Each answer points back at the architecture choice that drove it. If yours isn't here, open an issue.

Router & failover

How routing, pins, and failover behave.

What is Provider-Family Failover?

It's the default routing mode in BurnBar. The router stretches capacity inside the provider family you selected — never across unrelated providers, and never to a different model.

A Codex route stays with Codex accounts. A Claude route stays with Claude accounts. A Z.ai route stays with Z.ai accounts. Your exact selected account and model remain active while healthy; only quota, rate-limit, or availability state moves the request to a runner-up inside that family.

If no candidate survives, the gateway returns a structured 503 — your IDE sees a clean error, never a silent substitute.

What is Exact Model Failover?

It's the opt-in wider failover mode. BurnBar may try another provider or account after a quota, rate-limit, or availability failure — but only when that destination proves it serves the same canonical model ID as the request.

That means a request for gpt-5.4 can fail over to another route that truly serves canonical gpt-5.4. It cannot become gpt-5.4-mini, gpt-5.4-pro, a broad gpt-5-family wrapper, or a generic openai:standard substitute.

If the router cannot prove the exact identity, it fails closed with a structured 503. The audit event records the attempted model, canonical model, original route, destination route, reason, and whether the exact-model invariant passed.

What is the daily model board?

The daily model board is advisory research, not a failover mode. A board of language models researches the model landscape using Artificial Analysis, Terminal-Bench, Design Arena, and cached/manual fixtures, then BurnBar turns that into a deterministic public rundown at /router/daily.

Those rankings can explain which models look strong for coding, terminal, design, analysis, or agent tasks. They do not prove exact model identity and they do not authorize silent substitution. Pins, auth, quota, safety, availability, provider-family mode, and Exact Model Failover's canonical-ID gate still win at runtime.

Will BurnBar send my Codex task to Claude?

Not in Provider-Family Failover. The router refuses to cross the selected provider-family boundary. Your Codex route stays with Codex accounts. Your Claude route stays with Claude accounts. Your Z.ai route stays with Z.ai accounts.

Exact Model Failover can look wider only when the destination route proves the same canonical model ID. It still will not send a request to a merely similar model just because that provider has quota.

Can I still pin a model?

Yes. Pinning is the strongest signal in both modes.

In Provider-Family Failover, you pin an account that serves your chosen model. The pinned account wins as long as it's healthy; a runner-up inside that provider family is pre-selected for instant failover.

In Exact Model Failover, the pin still wins while healthy. Only recoverable failures open the door to another provider/account, and only after the destination proves the same canonical model ID.

What benchmark sources does BurnBar use?

A curated set of recently refreshed, well-methodologized public sources: Artificial Analysis (intelligence + coding indices, plus TPS and pricing), Terminal-Bench via Hugging Face (shell-loop agents, verified-run flag), and Design Arena (pairwise Elo + win-rate by category). Manual cached fixtures cover gaps when a source's API is unavailable.

Each score carries an age and a confidence label; older scores are weighted down, not silently dropped. The daily rundown at /router/daily shows the model-board verdict, the raw evidence score, the deterministic selection score, source logos, and freshness states.

We don't synthesize benchmarks. We cite, we don't fabricate. And no benchmark ever overrides your pin, beats live quota state, or counts as exact-model proof — they're advisory signals.

Are routing logs safe?

Yes. The local ProviderRoutingDecisionEvent stream records the chosen account ID, the skipped account IDs, the reason each one was skipped, and the final ranking signals.

It never logs the API key. Never the OAuth bearer. Never the request body. Never the response body. Keys live in the macOS Keychain with device-local accessibility.

Logs stay in the local SQLite store and never leave the device unless you explicitly enable an opt-in mirror.

Privacy & your data

What leaves your machine, and when.

Does OpenBurnBar send my data anywhere?

By default, no. Local usage tracking runs entirely on your Mac and writes to a local SQLite database. No telemetry, no analytics, no crash reports leave the device unless you explicitly enable an opt-in feature.

The opt-in features are: Firebase sync (metadata only by default), iCloud session-log mirroring (separate from Firebase, uses your Apple ID), Sentry crash diagnostics (off by default), and hosted quota sync (paid). Each one is a separate toggle, each one is described in the Privacy & Trust page.

Does OpenBurnBar read my API keys?

Not by default. Local usage tracking reads usage logs, not credentials. If you choose to enable provider routing or quota polling, you may provide an API key for that specific provider — stored in the macOS Keychain with device-local accessibility.

If you enable hosted quota refresh through BurnBar Cloud, credential material you explicitly hand over is stored in Google Cloud Secret Manager; Firestore only holds a redacted label.

Can I delete my data?

Yes — at any time, from several angles.

Local: delete the app and its support files at ~/Library/Application Support/OpenBurnBar/.

Cloud: sign out and choose Delete my data in Settings → Account.

Hosted credentials: remove the provider account from OpenBurnBar.

iCloud mirror: delete files from the iCloud.com.openburnbar.app container in your iCloud Drive.

What happens offline?

The whole product works offline. Dashboard, menu bar, log parsing, session viewing, settings, Hermes (with local backends), CLI, editor extension, controller workbench — none of them require a network.

Cloud sync simply pauses and resumes when you come back online. Disabling sync entirely does not affect local data.

Accounts, cost & accuracy

Sign-in, who it's for, and how numbers are computed.

Do I need an account?

No account is needed for the core product. OpenBurnBar reads logs your agents already drop on disk and works fully offline.

You'll only sign in (Apple or Google, via Firebase Auth) if you want optional cloud sync, multi-device chat resume, BurnBar Cloud, or BurnBar Cloud Pro.

How accurate are the costs?

Every provider row is tagged with one of three confidence labels:

Exact — the vendor's own API or local logs return token counts and we apply current public pricing.

Estimated — token counts come from an on-disk approximation (e.g. Copilot uses an 85/15 input/output heuristic).

Unavailable — the vendor doesn't expose data. We mark it instead of pretending.

Only OpenRouter returns dollar costs directly. For everyone else we compute from a pricing table — accurate for trends, not for tax audits.

Which providers are exact vs estimated?

Exact today (counted from the vendor's own API or from local logs): Claude Code, Codex, OpenAI, Cursor, Cursor Agent, Factory, MiniMax, Xiaomi MiMo, Z.ai, Warp, Ollama, Kimi, OpenRouter, Aider, Antigravity, DeepSeek, OpenCode, Hermes, and Pi Agent.

Estimated (counted, then priced from a public table): GitHub Copilot, Anthropic Console (daily lag), Forge, and xAI (Grok).

Detection-only (the vendor exposes nothing, so we show only Installed / Not installed): Gemini CLI, Cline, Roo Code, Kilo Code, Augment, Windsurf, Goose, and OpenClaw.

The full matrix is on the Providers page.

Is this for teams or solo developers?

Both — but the product is sharpest for solo developers and small teams who run multiple agents in parallel and are tired of finding out about the bill on the first of the month.

For solo: zero accounts, all local, on your Mac. For small teams: optional Firebase sync lets each developer see their own burn while a shared workspace surface stays consistent. There is no admin console or seat-billing today — that's roadmap, not present.

Plans & billing

Cloud, Cloud Pro, Cloud Ultra, allowances, and refunds.

What is BurnBar Cloud?

BurnBar Cloud is the first paid tier. It adds hosted quota refresh, encrypted conversation backup and resume, full session-log sync, cloud search, and synced agent memory to the free local product.

It costs $7.99/month or $79/year. Monthly and annual plans are available on web, App Store, and Google Play. Purchases are verified server-side before hosted features turn on.

What is BurnBar Cloud Pro?

BurnBar Cloud Pro is the second paid tier. It includes everything in BurnBar Cloud, plus Floo phone-to-Mac workflows and Agent Control under your grant.

It costs $24.99/month or $249/year. Monthly and annual plans are available on web, App Store, and Google Play. Cloud Pro unlocks the Pro feature group after server-side purchase verification.

How do Cloud Pro allowances and top-ups work?

Cloud Pro includes 500 hosted Agent Control actions and 50 relay-accounting GB each month. Extra hosted usage is prepaid before use: $4.99 buys 100 hosted actions, and $4.99 buys 50 relay-accounting GB.

Monthly caps still apply: 2,000 hosted actions and 300 relay-accounting GB. If allowance plus top-ups are exhausted, hosted Agent Control or Floo relay pauses instead of silently spending more. BYOK actions do not consume hosted action credits.

What is BurnBar Cloud Ultra?

BurnBar Cloud Ultra is the top paid tier. It includes everything in BurnBar Cloud Pro — Floo, Agent Control, and the same hosted action and relay allowance — plus 10× private agent memory.

Agent memory is the repo docs, notes, and chat-derived memories your agents recall while they work. Cloud Pro gives your agents 10 knowledge sources, 50,000 memory chunks, and 1 GB. Cloud Ultra raises that to 100 sources, 500,000 chunks, and 10 GB. The text is sealed on your device; hosted nearest-neighbor recall is opt-in and runs over cloaked vectors and opaque keyed hashes, which still reveal structural patterns such as recurrence, counts, and access timing.

It costs $59.99/month or $599/year. Monthly and annual plans are available on web, App Store, and Google Play. Cloud Ultra unlocks the higher memory limits after server-side purchase verification.

What happens to the old Hosted Quota Sync subscription?

Existing $4.99 Hosted Quota Sync subscribers are grandfathered for Group A cloud features. It is not sold as a new purchase tier, and it does not unlock Cloud Pro features such as Floo or Agent Control.

How do cancellation and refunds work?

Cancel from the platform where you purchased: Apple App Store, Google Play, or Stripe. Access remains until the paid period expires unless the platform reports a refund, chargeback, or revocation.

Apple and Google refunds follow store policy. Stripe purchases can be handled through support. Consumed top-ups are non-refundable except where store policy or law requires it.

Floo, Agent Control & editors

Phone-to-Mac, supervised agents, and the extension.

Why is Claude Code self-hosted only?

Two reasons. First, Claude Code's real data sources live in your local filesystem — the statusline hook in ~/.claude/settings.json and the per-session JSONL files in ~/.claude/projects/. A cloud function has no lawful way to read those without an agent running on your Mac.

Second, Anthropic's current Claude Code policy disallows third-party developers from offering Claude.ai login or routing Free, Pro, or Max credentials on behalf of users. We agree with that boundary. Claude Code always stays on your machine.

How does the Cursor / VS Code extension work?

The extension is an activity-bar panel that talks to OpenBurnBar's local daemon over the same UNIX socket the menu bar app uses. It shows the burn for your active workspace, the quota state for your active agent, and exposes the routed-provider gateway when you have it on.

It's source-only today — no public marketplace listing, no signed VSIX. Build from extensions/openburnbar and load unpacked. Marketplace publication is on the roadmap.

What is Floo?

Floo joins your phone and your Mac. From your iPhone or iPad you can see your Mac's screen, reach in and control it, send files either direction, start a voice or video call, share one clipboard across both, and even unlock your Mac with Face ID or Touch ID.

It only ever connects your own paired devices. Once paired E2EE is enabled and the runtime-readiness gate is complete, the screen, control, file, and clipboard contents are sealed end-to-end between your devices — the relay sees routing metadata, never those contents. Live voice and camera frames travel over the encrypted QUIC link itself, not the per-payload seal. Every connection asks first, and one tap ends it.

Floo is built and rolling out now, included with OpenBurnBar. (For the curious: Floo stands for File & Live Object Overlay — or, if you prefer, Fast Link Over Owl.)

Can an agent actually use my computer?

Only if you let it, and only as far as you allow. With Agent Control, an OpenBurnBar agent can click, type, and work your apps — drive a browser to fill a form or pull data, or use the Mac itself when you grant that reach.

You stay in charge the whole way: watch every move live, approve each step or set limits and let it move freely inside them, mark off-limits windows and sites it can never touch, and stop it instantly with a shortcut or a gesture on your phone. Every action is written to a tamper-proof record. Grants are per task and expire on their own.

It ships only in the direct download of OpenBurnBar and stays off until you turn it on. Prefer it never have this reach? The Mac App Store build ships without it entirely.