Discussion: What's New in v0.3

[Loongphy]

🚀 v0.3 Preview — New Live Mode, API Key Support & Simplified Auto-Switch

Status: Preview available · Current build: v0.3.0-alpha.7

npx @loongphy/codex-auth@next --version

---

What's new in v0.3

Feature	Description
--live flag	Foreground live mode with real-time TUI refresh
Auto-switch logic	Simplified — switches only when quota hits 0
API Key support	First-class OPENAI_API_KEY account management

---

1. Live Mode (--live)

A new foreground auto-refresh flow that keeps the process running and continuously updates while the command is active.

Try it now:

codex-auth live --live
codex-auth switch --live
codex-auth remove --live

Supported refresh modes:

Mode	Flag	Notes
API mode	--api (default)	✅ Recommended — provides accurate usage data
Local-only mode	--skip-api	⚠️ May return inaccurate usage data

---

2. Auto-Switch Logic

The switching logic has been intentionally simplified.

Switching is triggered when:

• The 5-hour quota reaches 0, or
• The weekly quota reaches 0

After either condition is met, it switches to the next available account.

[!NOTE] Why the change?
When quota is nearly exhausted, Codex tries to finish whatever task is currently running. This means the last 1–2% of quota can sustain execution for a surprisingly long time — draining quota fully before switching maximizes utilization rather than cutting over prematurely on a percentage threshold.

---

3. API Key Support

OPENAI_API_KEY auth is now a first-class managed account type, alongside ChatGPT OAuth accounts.

What it does:

• Imports and syncs API-key auth.json files — no more MissingEmail rejections
• Resolves account identity via GET https://api.openai.com/v1/me
• Stores the account email for list display and grouping
• Uses API_KEY in the PLAN column to distinguish from ChatGPT accounts
• Skips ChatGPT usage refresh for API-key accounts (shows - for usage since Codex usage APIs don't apply)
• Multiple API keys sharing the same email are grouped under a parent row with masked key labels

list examples:

Single API key account:

     ACCOUNT           PLAN      5H USAGE  WEEKLY USAGE  LAST ACTIVITY
---------------------------------------------------------------------
user@example.com      API_KEY        -           -            -

Multiple API keys for the same email:

     ACCOUNT           PLAN      5H USAGE  WEEKLY USAGE  LAST ACTIVITY
---------------------------------------------------------------------
user@example.com
  sk-7f3c1***42ce     API_KEY        -           -            -

Note

The raw API key is stored only in the managed auth snapshot — it is never written to registry.json, snapshot filenames, or display labels. The local unique key uses apikey::<me.id>::<sha256(OPENAI_API_KEY)>.

---

4. Deprecation Notice

Warning

The current background auto-switch service is planned for deprecation.

It will be replaced by a foreground command-based flow, which is easier to observe, debug, and verify during actual use.

---

5. Open Questions

Feedback is welcome on the following before v0.3 is finalized:

• Is foreground-only auto-switching the right direction for v0.3?
• Is "switch only when quota reaches zero" the best strategy, or should thresholds be configurable?
• Should API-key accounts participate in the auto-switch rotation, or should they remain manual-only?

Testing results and comments are appreciated — please share your experience below. 🙏

[rollingmoai]

3. API Key Support

OPENAI_API_KEY auth is now a first-class managed account type, alongside ChatGPT OAuth accounts.

What it does:

• Imports and syncs API-key auth.json files — no more MissingEmail rejections
• Resolves account identity via GET https://api.openai.com/v1/me
• Stores the account email for list display and grouping
• Uses API_KEY in the PLAN column to distinguish from ChatGPT accounts
• Skips ChatGPT usage refresh for API-key accounts (shows - for usage since Codex usage APIs don't apply)
• Multiple API keys sharing the same email are grouped under a parent row with masked key labels

Please have the ability to support an API key using a 3rd-party endpoint (example: LiteLLM)