Confused by detected vs unmapped providers

[balaji-dutt]

Hi,

I am currently using OpenCode with OpenAI & GitHub Copilot auth, plus some API keys via environment variables:

❯ opencode auth list

┌  Credentials ~/.local/share/opencode/auth.json
│
●  OpenAI oauth
│
●  GitHub Copilot oauth
│
└  2 credentials

┌  Environment
│
●  Perplexity Agent PERPLEXITY_API_KEY
│
●  Perplexity PERPLEXITY_API_KEY
│
●  OpenRouter OPENROUTER_API_KEY
│
●  Moonshot AI (China) MOONSHOT_API_KEY
│
●  Google GEMINI_API_KEY
│
●  Moonshot AI MOONSHOT_API_KEY
│
●  Anthropic ANTHROPIC_API_KEY
│
└  7 environment variables

When I go into the openusage settings modal, I see that it is detecting several providers and API keys:

However, despite this when I go into the main Dashboard view it only seems to detect Claude Code (which I do not actively use) and the other providers have an "Unmapped" warning against them:

Can you help me understand what I need to do differently here?

I should also note I did install the OpenCode plugin as well, but that does not seem to change anything:

[janekbaraniewski]

hey @balaji-dutt ! I agree, this definitely needs some improvement. You should be able to map those in your settings.json file but it's currently not really documented and clearly confusing.

Where the different names come from

openusage tracks two separate things and they don't share a vocabulary:

1. Configured providers — accounts openusage knows about. We give them internal IDs like claude_code, copilot, gemini_api, gemini_cli, cursor, openrouter, openai. These show up as tiles on the dashboard.
2. Telemetry sources — events flowing in from integrations (Claude Code hooks, Codex notify, the OpenCode plugin you installed). Each event is tagged with whatever provider name the source tool uses internally. For OpenCode that's its own model-registry IDs: anthropic, google, github-copilot, openrouter, openai, moonshot, etc.

When the dashboard hydrates, it tries to attribute each telemetry event to a configured provider so the spend lands on the right tile. Today that lookup is just "exact ID match" plus one hardcoded link (anthropic → claude_code). Anything that doesn't match either lands in "Unmapped".

So in your screenshot:

• google is OpenCode's name for the Gemini API; openusage calls it gemini_api → name mismatch.
• github-copilot is OpenCode's name; openusage calls it copilot → name mismatch.
• openai, openrouter, moonshot — different problem entirely (see below).

The one-line workaround today (for the name mismatches)

Add to ~/.config/openusage/settings.json:

{
  "telemetry": {
    "provider_links": {
      "google": "gemini_api",
      "github-copilot": "copilot"
    }
  }
}

That makes google spend land on the Gemini tile and github-copilot spend land on the Copilot tile. The daemon picks up the change on its next poll cycle (no restart needed).

About openai / openrouter / moonshot — this one's bigger

The dashboard tile for a provider only exists once openusage has a configured account for it. There are four ways an account gets created today:

1. CLI / IDE auto-detection — openusage scans for installed tools on startup. If it finds Claude Code's local files, the gh CLI with Copilot, the gemini CLI with credentials, Cursor's app data, Ollama, Codex, etc., it auto-creates an account using whatever the tool itself stores locally (config files, OAuth credentials, SQLite DBs). No API key needed from you. This is how claude-code ended up on your dashboard — Claude Code is installed on your machine even if you're not actively using it right now.
2. Env-var auto-detection — at startup openusage reads a fixed list of env vars (ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, …) and creates an API-key account for each one it finds.
3. Settings → 5 KEYS tab — you paste an API key into the TUI, openusage stores the credential and creates the account.
4. Manual entry — you hand-add an entry to the accounts array in settings.json.

Once an account exists, openusage uses its credentials to query that provider's API for quota, balance, and rate-limit information — that's what fills the tile. Separately, telemetry events tagged with a matching provider id get attributed to that tile too, contributing the spend / token / request numbers from your local sessions.

That's where your case breaks for openai / openrouter / moonshot:

• OpenAI — you authed it via OAuth inside OpenCode. Path 1 doesn't apply (there's no OpenAI CLI/IDE for openusage to detect). OPENAI_API_KEY isn't set in the environment your daemon was launched in, so path 2 doesn't fire. Result: no openai account → no tile → OpenCode's provider_id=openai events have nowhere to land.
• OpenRouter — you have OPENROUTER_API_KEY in your shell, but if the daemon was started by something that doesn't inherit your shell environment (launchd on macOS, a systemd unit, a different terminal session), the env var won't be visible. Easiest fixes: export the key in ~/.zshenv (loaded by all zsh sessions including non-interactive), or paste the key into Settings → 5 KEYS — that bakes it into openusage's credentials store directly so it doesn't depend on the runtime environment.
• Moonshot — openusage doesn't support it yet at all but we'll add it soon.

In all three cases, even if we fixed the mapping perfectly, openusage would only be able to display telemetry-derived numbers — the cost, tokens, requests, and per-model breakdowns we get from your OpenCode hooks. The tile would not show remaining quota or billing balance, because those come from authenticated API calls to each provider's quota endpoint, which we can't make without credentials. Telemetry shows you what you've already spent; quota endpoints show you what's left. They're different signals from different sources.

What we're going to ship first

1. google → gemini_api and github-copilot → copilot as built-in defaults so neither shows "Unmapped" out of the box.
2. Categorize the warning so it tells you why something is unmapped — "no account configured" vs "name mismatch we can fix" vs "account exists but unreachable" — instead of one undifferentiated count.
3. Add an interactive remap inside Settings → 6 TELEM so you can pick a target account from a list, no JSON editing.
4. Tighten the header copy so it's actionable rather than vague.

Moonshot + Perplexity support is next — I'll get to it once I have test accounts to wire up the quota fetching against.

After that, the next thing we want to look at is letting you register a provider purely for telemetry attribution without requiring an API key — so OAuth-only / unsupported providers can still get a tile that displays the data we already have from OpenCode. That solves the OpenAI-via-OpenCode case end-to-end short of upstream quota numbers.

Thanks for the detailed write-up and screenshots, this was a really helpful report!
I'll keep you updated.

[janekbaraniewski]

@balaji-dutt I just released v0.9.6 with initial implementation of mapping management improvements. Give it a try and LMK what you think!

[balaji-dutt]

Hi @janekbaraniewski

Thank you for the quick turnaround on this. I've just installed v0.9.6 and I have to admit - I'm still really confused. Apologies in advance for my confusion but would much appreciate some additional clarifications.

Since I opened the issue, I've signed up for a Claude Code Pro plan as well as an OpenCode Go plan. As such here are my updated Claude / OpenCode settings:

❯ claude auth status
{
  "loggedIn": true,
  "authMethod": "claude.ai",
  "apiProvider": "firstParty",
  "email": "xxxxxxxxxxxxxx",
  "orgId": "70a2ae21-3a33-47b1-8945-9fff9b89475b",
  "orgName": "xxxxxxxxxx's Organization",
  "subscriptionType": "pro"
}

❯ opencode auth list

┌  Credentials ~/.local/share/opencode/auth.json
│
●  OpenAI oauth
│
●  GitHub Copilot oauth
│
●  Anthropic oauth
│
└  3 credentials

┌  Environment
│
●  Perplexity Agent PERPLEXITY_API_KEY
│
●  Perplexity PERPLEXITY_API_KEY
│
●  OpenRouter OPENROUTER_API_KEY
│
●  OpenCode Go OPENCODE_API_KEY
│
●  OpenCode Zen OPENCODE_API_KEY
│
●  Moonshot AI (China) MOONSHOT_API_KEY
│
●  Google GEMINI_API_KEY
│
●  Moonshot AI MOONSHOT_API_KEY
│
└  8 environment variables

When I run openusage, there are still some inconsistencies:

• Note that although no ANTHROPIC_API_KEY is present, openusage still thinks Claude Code is using Credits rather than a plan, even though the header shows an account logged in:

• Although the environment variables includes an OPENCODE_API_KEY (which as per README should be recognized as an OpenCode account), the list of providers is still limited to Claude Code:

• TELEM now shows the mapping of github-copilot & google to the internal ID's but I can only tie them to Claude Code and not OpenCode:

Can you please help me understand what I'm doing wrong that is resulting in openusage not being able to detect OpenCode?

[janekbaraniewski]

hey @balaji-dutt, sorry for the lag here — picking the thread back up.

on the claude code "credits vs plan" confusion: this is fixed in v0.11.0. when ~/.claude.json shows an active Pro or Max subscription openusage now hides the dollar values by default and keeps token totals, the 5h block, and the projection visible. the previous behavior wasn't lying exactly — it was showing what your usage would cost on the API at published per-million rates — but since openusage has no access to Anthropic's actual subscription billing the number was misleading on a flat-rate plan. you can override the auto-hide per-account or globally via dashboard.hide_costs, or press c on the focused tile to cycle auto → hide → show → auto. full writeup here: https://openusage.sh/docs/providers/claude-code/#why-is-the-dollar-number-bigger-than-what-my-claude-subscription-charged

on opencode not showing up: there are currently two paths that register an opencode account, and your setup hits neither cleanly. either OPENCODE_API_KEY has to be visible to the openusage process (env-var auto-detect), or ~/.local/share/opencode/auth.json needs an entry with "type": "api". we currently skip "type": "oauth" entries on purpose because those tokens don't authenticate against the usage endpoints we probe — but skipping silently is a real UX gap. this is being actively tracked in #90 and #149 (#90 covers the oauth-skip behavior, #149 covers a windows path-probe bug that also blocks detection). once detection lands properly the tile will appear automatically.

on telemetry tile mapping: routing works by matching each event's source_system (the provider id the source tool uses internally — OpenCode uses anthropic, google, github-copilot, openai, openrouter, moonshot, etc.) against your configured accounts, with telemetry.provider_links as the override map. the catch is that telemetry needs an existing tile to route to — if no opencode account is detected, OpenCode's events have nowhere to land regardless of how the mapping is set up. so this one is downstream of the opencode detection issue above. once that's fixed, the routing will start working on its own; if it doesn't, the manual mapping path in Settings → 6 TELEM still works.

thanks again for the patience and reports.