Bug
klaatai whoami (both --json and plain output) always reports plan: null / omits the Plan line, even when signed in and online. Confirmed on a real signed-in session:
$ klaatcode-test whoami --json
{
"signedIn": true,
"email": "user@example.com",
"plan": null,
"backend": "online"
}
Root cause
Credentials.plan (src/auth/credentials.ts:25) is never written by anything:
- The OAuth browser-login callback (
src/auth/browser.ts:166-172) only reads access_token, refresh_token, expires_in, user_id, email off the redirect URL — there's no plan query param, so it's never captured at login time.
runWhoami (src/auth/login.ts) calls client.ping(), which hits GET /health (src/api/client.ts:407-420) — a plain health-check endpoint, not per-user, so it can't return plan info either.
- The only place the CLI does learn the live plan is
X-KlaatAI-Quota-Plan on chat-completion responses (parseQuotaHeaders, src/api/client.ts:644-656), parsed per-request for the interactive session — but that value is never written back to credentials.json.
So plan is dead on arrival: nothing populates it for any user, ever. This isn't a one-off — every signed-in user gets plan: null from whoami.
Suggested fix
Either:
- Have the web OAuth callback page also pass
plan as a redirect query param (server + website change), captured alongside email/user_id in browser.ts, and re-saved on token refresh (refresh.ts) since plan can change (upgrade/downgrade) — the stored value would still go stale between refreshes; or
- Have
whoami hit an authenticated per-user endpoint that returns plan directly (e.g. extend /v1/me/usage or add a lightweight /v1/me profile route) instead of the generic /health ping, so it's always fresh rather than relying on a cached field.
The second option avoids the staleness problem of persisting a plan string that can change server-side without the CLI knowing.
Repro
klaatai whoami --json # plan is always null, regardless of actual subscription
Bug
klaatai whoami(both--jsonand plain output) always reportsplan: null/ omits the Plan line, even when signed in and online. Confirmed on a real signed-in session:Root cause
Credentials.plan(src/auth/credentials.ts:25) is never written by anything:src/auth/browser.ts:166-172) only readsaccess_token,refresh_token,expires_in,user_id,emailoff the redirect URL — there's noplanquery param, so it's never captured at login time.runWhoami(src/auth/login.ts) callsclient.ping(), which hitsGET /health(src/api/client.ts:407-420) — a plain health-check endpoint, not per-user, so it can't return plan info either.X-KlaatAI-Quota-Planon chat-completion responses (parseQuotaHeaders,src/api/client.ts:644-656), parsed per-request for the interactive session — but that value is never written back tocredentials.json.So
planis dead on arrival: nothing populates it for any user, ever. This isn't a one-off — every signed-in user getsplan: nullfromwhoami.Suggested fix
Either:
planas a redirect query param (server + website change), captured alongsideemail/user_idinbrowser.ts, and re-saved on token refresh (refresh.ts) since plan can change (upgrade/downgrade) — the stored value would still go stale between refreshes; orwhoamihit an authenticated per-user endpoint that returns plan directly (e.g. extend/v1/me/usageor add a lightweight/v1/meprofile route) instead of the generic/healthping, so it's always fresh rather than relying on a cached field.The second option avoids the staleness problem of persisting a plan string that can change server-side without the CLI knowing.
Repro
klaatai whoami --json # plan is always null, regardless of actual subscription