Provider picker: "needs-auth / auth:missing" is inaccurate for API-key providers (and reads as a readiness regression)

[Hmbown]

Summary

The provider picker labels nearly every API-key provider as needs-auth | auth:missing | cost: unknown. This is both inaccurate wording and, in its current form, reads as a regression in how provider readiness/auth state is surfaced.

> Anthropic        needs-auth | auth:missing  | cost: unknown        | anthropic | b...
  Arcee AI         ready      | auth:configured| cost: $0.22/$0.85 mtok | chat
  AtlasCloud       needs-auth | auth:missing  | cost: unknown        | chat | base...
  Baidu Qianfan    needs-auth | auth:missing  | cost: unknown        | chat | ba...
  DeepSeek         needs-auth | auth:missing  | cost: unknown        | chat | base:ap...
  ...
  Ollama           local-ready| auth:local    | cost: local          | chat | base:localh...
  OpenAI Codex     ready      | auth:oauth-ready | usage: Codex OAu...

Problem 1 — "auth" is the wrong word for API keys

For API-key providers (DeepSeek, Anthropic, Fireworks, OpenRouter, MiniMax, etc.), the credential is an API key, not an authentication/login session. Calling an unset key needs-auth / auth:missing is misleading:

• "auth" implies an OAuth/login flow (which is what OpenAI Codex genuinely uses → auth:oauth-ready). Conflating the two makes the OAuth providers and the key-based providers look like the same mechanism.
• A new user reads "needs-auth / auth:missing" and reasonably thinks something is broken or that they must "log in," when all they need to do is paste an API key.

The labels live in:

• ProviderReadiness::label() → needs-auth — crates/tui/src/tui/provider_picker.rs:658
• ProviderAuthStatus::label() → missing (rendered auth:missing) — crates/tui/src/tui/provider_picker.rs:644

Ask: make the status terminology kind-aware:

• API-key providers with no key → something like no-key / key:not-set / add API key (actionable, accurate)
• OAuth providers → keep needs-login / auth:oauth-missing
• Local providers → local (already good)
• Don't show auth: framing for things that are just keys.

Problem 2 — looks like a readiness/catalog regression

Every key-based provider shows cost: unknown while only the catalog-backed ones (Arcee, MiniMax) show real pricing. Combined with the blanket needs-auth, the picker gives almost no useful signal and is a step back from prior versions. Worth confirming:

1. Are providers that do have a key configured (env / keyring / config) being detected and shown as ready, or are they incorrectly stuck on needs-auth? (Several reporters in the mode-desync thread are power users who very likely have keys set.)
2. Why is cost: unknown the default for so many providers — is the bundled Models.dev catalog (crates/tui/src/tui/provider_picker.rs:994) not being consulted for these provider rows?

Suggested direction

Make the readiness/auth column smart and accurate:

• Distinguish provider kind (api-key vs oauth vs local) and word the missing-credential state per kind.
• Use an actionable phrase ("press Enter to add API key") rather than a diagnostic-sounding auth:missing.
• Ensure configured keys are reliably detected so configured providers don't show needs-auth.
• Backfill cost: from the bundled catalog where available instead of defaulting everything to unknown.

Environment

• codewhale version: 0.8.65 (observed)
• Surface: TUI provider picker