Tokenmax 0.1.9

What’s new

A zero-Keychain-prompt monitoring option

Tokenmax can now monitor Claude through its documented status-line data without reading Claude Code’s Keychain item. Choose Settings → Data Source → Status line only for zero Tokenmax credential prompts.

Status-line readings update while Claude Code is active. Per-model weeklies, the plan name and usage-credit flag are unavailable, and unattended automation pauses because this source cannot safely verify spending. Manual task runs still work.

Fewer prompts in Keychain mode

• A Deny is remembered until you explicitly click Refresh; background timers and automatic verification cannot reopen the question.
• Simultaneous credential callers now share one in-flight read instead of potentially stacking duplicate dialogs.
• Allow covers one read. Always Allow records a grant for the current credential item.

Diagnosing Keychain prompts

Tokenmax now records every Keychain read so an unexpected prompt can be investigated instead of guessed at. Run:

make logs

Or open:

~/Library/Application Support/Tokenmax/logs/tokenmax.log

Each Keychain entry records:

• why the read occurred, such as nothing cached yet or cached token expired;
• the result and elapsed time;
• whether it was silent or likely waited on a consent dialog;
• when Claude Code last modified the credential item;
• the Tokenmax binary’s code hash at launch, so prompts caused by a new build can be identified.

Timing is evidence rather than proof—macOS does not directly tell Tokenmax that it displayed the dialog. When reporting an unexpected prompt, include the surrounding keychain: and launch: cdhash lines.

Install or upgrade

brew install --cask danieldrinhausen/tap/tokenmax

Tokenmax is signed but not notarized, so first launch still requires System Settings → Privacy & Security → Open Anyway. Keychain monitoring also asks once for the new binary; choose Always Allow if you want macOS to record the grant.