Don't Collect Another API Key: Reusing the AI Logins Already on a Mac

2026-11-14来源 dev.toEnglish

The remaining allowance on a coding agent is not a secret. It already lives behind a login you completed in that vendor's own app or CLI. Claude Code has /usage. Codex has /status. Cursor, Gemini, and GitHub Copilot each have a usage page of their own. If a menu bar meter asked you to paste a fresh API key for every one of those tools, it would be asking you to open a second billing path and to store a second secret, just to read a number you can already see.

We build TokenBar, a macOS 14+ menu bar app at Aura Technologies that shows usage and reset times for Claude, Codex, Cursor, Gemini, and Copilot. It is built on CodexBar, Peter Steinberger's MIT-licensed project, and it can connect to a local install of Pixel Agents, a separate MIT-licensed project. TokenBar does not add any quota. This post is about a design choice we kept in front of us while wiring those providers up: reuse the login that is already on the Mac, instead of collecting a new API key as the normal path.

An API key is often the wrong kind of credential

For many of these tools, the subscription you already pay for and an API key are not the same thing.

Claude Code usage on a Pro, Max, or Ultra plan is the plan allowance, shared with Claude on the web and on the desktop, and you read it with /usage or in Settings, under Usage. Anthropic documents that in its help center and in the costs guide. An Anthropic Console API key is a different billing path.

OpenAI's Codex pricing page tells you to check remaining limits in the Codex usage dashboard, or with /status during a CLI session. Local sessions and cloud chats share the plan allowance. A usage-based API key is listed as a separate column. If a tracker required that key, it would be tempting to assume it was reading the same pool you care about. It might not be.

Cursor is explicit about the same split. Its usage documentation says that on individual plans, requests made with your own API key do not count toward included usage. Your provider bills you directly. A meter that only knew how to call an API with a key you pasted would miss the weekly or monthly pool you were trying to watch.

So "just paste your API key" is not a shortcut. It is often a request for the wrong credential, plus a new secret sitting in someone else's app. The better starting point is: you already signed in to the vendor. Use that.

What reuse looks like in the menu bar

When TokenBar is connected, the menu can name the source it is using. On a Mac where Codex is signed in, that line has read "Live process detected (Codex app) - Source: OAuth," next to the session and weekly bars and the time until reset. The useful part of that sentence is the source. The app is not asking you to type a key into a form. It is using a login that Codex already has.

The same idea applies to the other advertised providers, with a per-provider source you can choose when more than one is available:

  • Claude can follow a Claude Code login, or a signed-in claude.ai session, or the claude CLI.
  • Codex can follow the Codex CLI or app login, or a signed-in ChatGPT session.
  • Cursor can follow the Cursor app or a signed-in browser session.
  • Gemini can follow a Gemini CLI login.
  • Copilot can follow a GitHub login. GitHub's own apps often use device authorization for that kind of sign-in, so you approve it on GitHub rather than pasting a token by hand.

The point is not that every provider speaks one protocol. They do not. CodexBar's own provider list, which is much longer than TokenBar's advertised set, is a reminder of how many ways a usage number can be fetched: official APIs, OAuth, device flow, a browser session, CLI output, local files. The point is that the default should be "use the session you already created," and that the menu should say which source is in play.

We do not treat unadvertised providers as part of this product story. The advertised set is Claude, Codex, Cursor, Gemini, and Copilot. If you need a longer list, CodexBar is the open-source baseline, it is free, and it is very good.

The tradeoffs you actually hit

Reusing a login is cleaner on paper than it is in a menu bar that should stay quiet.

Expiry belongs to the vendor. If an OAuth token has expired, the honest fix is to let the vendor's own app or CLI refresh it, then read again. Inventing a parallel login just so a meter can keep working is how you end up with a second, half-documented session and a confusing sign-out story. When something is stale, the message should tell you to sign in to the tool you already use, not to invent a TokenBar account for that provider. TokenBar does not need a separate Claude, Codex, or Cursor account of its own.

Keychain prompts can become noise. Credentials on a Mac often live in the Keychain. A status item that wakes, reads a token, and puts a Keychain dialog in your face every few minutes is worse than no meter. TokenBar has a setting to avoid those prompts, and it backs off for a while after a prompt is denied, so one "Deny" does not turn into a loop. That is a real tradeoff: less nagging, and a stretch of time where a denied or locked Keychain means the meter cannot refresh. Asking someone to unlock the login Keychain is the right error when that is actually the problem. It is the wrong thing to ask every time the menu opens.

A browser session is a fallback, not a tutorial in moving cookies around. Some providers can be read from a session you already have in a browser. That can unblock someone who uses the web app more than the CLI. It is also easy to document badly. We would rather tell you to choose a source in the app than publish a recipe for copying cookie headers.

Reading usage does not change usage. This should go without saying, and it still needs saying. A meter is a view. Official plan limits, reset times, and what happens when you hit them still come from the vendor. TokenBar gives you no extra quota, and it does not replace Settings, /usage, or /status.

The app is not a claim that nothing ever leaves the Mac. License checks, checkout, and similar account traffic go to TokenBar's own service. Reusing a vendor login is a decision about how we read that vendor, not a promise that the utility has no network of its own.

What I would tell anyone building a sidecar for a tool people already pay for

  1. Prefer the login the user already completed. If the number you want is on a subscription plan, an API key is often a different number.

  2. Show the source. "OAuth," "CLI," or "web session" in the UI saves a lot of guesswork when the number looks wrong.

  3. Let the vendor refresh its own tokens. Your job is to notice that the session is stale and send the user back to the official sign-in.

  4. Treat Keychain as a scarce attention budget. Prompt when you must, back off when the user says no, and do not poll in a way that makes the system ask again.

  5. Say what you do not do. No extra quota. No second provider account if you can help it. No implication that watching the meter is a privacy guarantee.

Where TokenBar fits

TokenBar runs on macOS 14 or later. Basic is $5 a month. Pro is $15 once, a lifetime license. You choose the plan in the app. It shows usage and reset times for the advertised providers, and it does not increase any of their allowances. If you want the open-source menu bar meter on its own, start with CodexBar. If you want to look at TokenBar, it is at tokenbar.site.

When you connect a third-party utility to a provider you already pay for, do you want it to reuse the existing login, even if that means a Keychain prompt, or would you rather paste a dedicated key so the access is obvious and easy to revoke?

Sources

原文：https://www.a8q9.cn/en/article/don-t-collect-another-api-key-reusing-the-ai-logins-already-on-a-mac-4ecae3.html

相关文章