Your AI coding plan has quota caps and reset windows. TokenKick watches local Codex and Claude state, shows which windows are ready, and can anchor a fresh window after you opt in. Provider logins stay with the official CLIs on your machine.
~/projects/zoo on main % tk [->|] token kick ____ _ ___ ____ | _ \ ___ ___ ___ | ||__ \ / ___| ___ | |_) / _ \/ __|/ _ \| __|/ / | | _ / _ \ | _ < __/\__ \ __/| |_ |_| | |_| | (_) | _ |_| \_\___||___/\___| \__|(_) \____|\___/ (_) ? What would you like to do? (↑↓ to move, enter to select) ❯ Status View cached or live provider status Kick Anchor a ready window Setup Discover accounts and configure basics Auto-kick Enable or disable automatic kicks Schedule Configure smart kick windows Notifications Configure or test notifications Diagnostics Doctor, history, reset log, Codex buckets Daemon Start, stop, restart, or inspect daemon Exit ❯ Status ACCOUNT STATE RESET USED ACTION ───────────────────────────────────────────────────────────── personal ● Weekly ready w ready w 0% · s 1% Kick work ● Session ready s ready w 18% · s 0% Kick backup ● Active s 2h 14m w 18% · s 41% Use agency ● Weekly spent w 2d 06h w100% · s12% Wait → Kick-ready windows: personal, work · run tk kick --all to anchor them.
Run tk to open this interactive menu.
AI coding plans have quotas and reset windows. Estimate how much paid window time drifts unused, with your own assumptions.
of paid window time that would otherwise drift unused
No multiplier, no hidden constant. Move any control and watch every number update live.
TokenKick reads local Codex and Claude rate-limit data, shows which windows are ready, and helps you decide what to do next. If you opt in, it can send one minimal provider-client request to anchor a fresh window on your schedule.
Reads local Codex and Claude state, plus CodexBar fallbacks where available. No new auth, no token relay. Each account gets a state: Weekly ready, Session ready, stale, or unknown. Global Reset Detection needs 2+ local accounts from one provider.
Status names the next useful action. With scheduling on, the daemon defers the kick until it lands inside your deep-work block, so no window spills past the end of your day.
After approval, TokenKick sends one minimal provider-client request per account, records it in the kick log, and can notify your phone. Run it once or as a local service; ntfy and Telegram surface the result wherever you are.
First-use windows start burning when they are anchored. TokenKick can wait until the right moment, so more of the window lands inside your work block.
Set work hours per account. TokenKick can defer approved kicks until they line up with your day, and pending kicks survive daemon restarts.
Naive: 14:00 kick → 19:00 reset → 24:00 expiry (3h post-work waste)
Smart: 11:00 kick → 16:00 reset → 21:00 expiry (0h post-work waste)
$ tk schedule set --account personal --weekdays 14:00-21:00 --weekends 10:00-16:00
With multiple accounts, TokenKick can stagger approved kicks so a fresh window is available across your workday. Use recurring schedules for normal hours, or preview a one-off plan for today before anything changes.
Not "encrypted at rest." Not "securely stored." TokenKick does not transmit your provider credentials to us. It runs where the official CLIs already run: your laptop, Mac mini, home server, or VPS.
Your ~/.codex, your ~/.claude, OAuth tokens, and cookies stay where the provider CLIs already put them, on hardware you control. TokenKick reads local state, writes local logs, and runs provider-client commands locally. Optional ntfy or Telegram notifications send only the status messages you configure.
Local stays free. The current CLI, beta Mac app, and local daemon are MIT-licensed and free to use. A hosted TokenKick Cloud tier for cross-machine coordination is planned and may have separate terms; provider credentials still stay on hardware you control.
TokenKick does not increase quota, bypass rate limits, resell access, or pool accounts.
Automated kicking is opt-in and may violate provider terms.
Run tk for the interactive TUI. Use commands for scripts and agents; JSON output is available where machines need it. Full reference: tk --help.
Hand your coding agent the prompt below. TokenKick can run headless with TK_NO_INTERACTIVE=1 and return JSON via --json-output, so agents do not get stuck in the menu.
Install and configure TokenKick from tokenkick.dev: run `pipx install tokenkick`, then `TK_NO_INTERACTIVE=1 tk setup`, then show me `tk status --json-output`.
/llms.txt. For agents, see the Agent playbook. JSON is available on status, calendar, run, history, doctor, update, and reset-log.TokenKick ships a local MCP server. Your agent can read quota state, preview a plan, configure schedules, and apply approved orchestration through guarded commands. Codex and Claude Code can install it directly; other MCP-capable agents can use the same local server. See the MCP setup guide.
tk plan, and shows the proposed account timeline before anything changes.Voice can work through your agent intake. TokenKick's own Telegram listener stays read-only for lightweight checks: /status, /refresh, and /ping.
tk, and the native Mac app beta gives the same local-first model a desktop surface. The CLI is the recommended install path; Mac app beta DMGs are published through GitHub Releases when available and may show a macOS security warning if not notarized. The current CLI, Mac app beta, and local daemon are MIT-licensed and free to use. Future hosted services may have separate terms, without moving provider credentials into TokenKick's cloud.
tk history --json-output shows user-meaningful attempts, confirmations, failures, timestamps, and available token evidence.
~/.codex, your ~/.claude, OAuth tokens, and cookies stay where the official CLIs already put them, on hardware you control.
tk setup, enable the accounts you want, then start tk daemon --background. That self-hosted daemon is the always-on runner.
tk history shows user-meaningful kick attempts, confirmations, failures, timestamps, and token evidence where available. tk history --json-output is there for scripts, and the daemon log explains why TokenKick acted, skipped, deferred, or notified.
tk auto disable "<label>" to stop automation for an account, tk daemon --stop to stop the background loop, and tk notify or account notification settings to change alerts without touching provider logins.