Supported providers
Nine connectors ship today. Each one carries its own honest labels describing where its credentials come from, how official its data interface is, and how likely it is to break.
The nine connectors
| id | connect | reads |
|---|---|---|
claude | Nothing to do: OpenLimiter reads what Claude Code already renders. | The Claude Code status line, automatically. An opt in poll of Anthropic's own usage endpoint, with your own token, covers the gap when Claude Code is closed. Off unless you turn it on. |
openrouter | Real OAuth, started from the hub. A key you already hold still works. | OpenRouter's documented key and usage report. |
codex | Use the login already there, or sign in from inside OpenLimiter. | The login the Codex CLI stored. May break when OpenAI changes it. |
antigravity | Read only, from the credential already there. | The credential the Antigravity CLI stored. May break when Google changes it. |
gemini_cli | Read only, from the login already there. | The login the Gemini CLI stored. May break when Google changes it. |
grok | Use the login already there. OpenLimiter cannot start Grok's own sign in yet. | The login the Grok CLI stored, without the client marker xAI's own tool sends. |
kimi | Use the login already there. OpenLimiter cannot start Kimi's own sign in yet. | The usage response the Kimi CLI defines. May break when Moonshot changes it. |
opencode | Import only: you supply the document yourself. | A usage view behind a session you already signed in to. May break without notice. |
manual | You write the numbers yourself. | Never breaks, never guesses. |
How data actually arrives
Most connectors read for themselves now. Two still do not, and this is the part worth stating plainly.
claudeis fed by the Claude Code status line the moment it renders, and by an opt in poll of Anthropic's own usage endpoint when Claude Code is closed.codex,gemini_cli,antigravity,grok,kimiandopenrouterread the login their own tool already stored, at most once every fifteen minutes, behind the desktop app's own refresher or the terminal'sopenlimiter refresh.manualis fed by a document you place in the state directory.opencodeis the one connector left with no reader of its own: it only accepts data throughopenlimiter ingest --provider opencode, because it reads an authenticated page rather than a login file.
The ingestion page documents the manual and OpenCode shapes in full.
Reading the labels
Every snapshot carries four labels, so a surface can always tell a reader how much to trust a number.
| label | values you will see |
|---|---|
credentialOrigin | official-local-tool, user-key, browser-session, user-entered |
dataInterfaceStatus | native-statusline-payload, documented-api, internal-endpoint, authenticated-scrape, manual |
automationRisk | low or high |
verification | UNVERIFIED |
What drift looks like
Unofficial interfaces change without notice. When a shape moves, parsing fails closed: the affected provider returns to unknown, the other providers are unaffected, and nothing invents a number to fill the gap.
The OpenRouter credential
OpenRouter is the one connector with a real sign in of its own: OAuth, started from the hub, and the key it hands back is what gets read from then on. A key you already hold still works, fed the same way any other connector is.
openlimiter ingest --provider openrouter --payload '{"data":{"total_credits":15,"total_usage":14.2}}'API spend keys
A key for an API spend meter is a separate thing from a subscription login. It lives in this device's operating system keyring by default. Cloud metering, an opt in Pro feature, stores that key encrypted on the server instead, so the hub and the phone can show spend with no device running.
Connectors that do not exist yet
Only the nine above are real. Anything else you might hope for is not built, is not scheduled, and should not be assumed. If a subscription has no connector, the manual path covers it today with numbers you enter yourself.