Currently, my-codex orchestrates LLM CLI sessions across isolated project environments without persistent tracking of operational API usage costs or token balances. This feature request proposes a structured lifecycle to track token expenditures natively per session, embed the accumulated tracking metadata directly into generated Git commit messages, and handle automated state resets upon successful commits.
Core user requirements
- Startup initialisation: the tally must be initialised to zero when starting Emacs or spinning up a new project session buffer.
- State isolation: use a buffer-local mechanism to isolate counters per project workspace, preventing metrics from bleeding across active terminal splits.
- Automated metadata insertion: append the total accumulated token count to the generated commit message text block as a standardised Git trailer.
- Commit-driven reset: wipe the active running tally back to zero automatically as soon as the background git commit process exits successfully.
- Manual inspect and reset: introduce explicit interactive options for users to manually check or clear the tally mid-session via the minibuffer.
Proposed architectural adjustments
- State orchestration (
my-codex.el)
- Introduce a new buffer-local state tracking variable named
my-codex-session-token-count.
- Update
my-codex--mark-session to cleanly instantiate this tracking state with zero assets during creation loops.
- Intercept
my-codex-backend-send to dynamically increment token weights during prompt submission sequences.
- Git interface automation (
my-codex-git.el)
- Modify my-codex--wait-for-commit-message to pull the active count from the session buffer and append it to the tail of the message block before spawning the interactive text editor.
- Update the process sentinel logic inside my-codex-git-commit-with-message to safely flush the active session's local tally variable back to zero upon process termination with code 0.
- Interactive utilities (
my-codex-prompts.el)
- Add user-facing interactive functions (my-codex-inspect-tokens and my-codex-reset-tokens) to offer manual telemetry controls.
- Expose these workflows inside the core my-codex-transient layout overlay map for quick navigation.
Technical data strategies
We can approach metrics collection using one of three methodologies:
- Dynamic estimation fallback: leverage the existing
my-codex--approx-token-count utility to mathematically extrapolate token lengths over incoming prompts and outgoing message text blocks.
- Interactive terminal scraping: intercept execution boundaries asynchronously to issue hidden
/status or /credits slash-commands into the vterm line, parsing the immediate output telemetry before cleaning up the screen buffer history.
- Session cache parsing: read directly from home directory CLI metadata logging paths to fetch absolute database balances mapped against active project root hashes.
Currently, my-codex orchestrates LLM CLI sessions across isolated project environments without persistent tracking of operational API usage costs or token balances. This feature request proposes a structured lifecycle to track token expenditures natively per session, embed the accumulated tracking metadata directly into generated Git commit messages, and handle automated state resets upon successful commits.
Core user requirements
Proposed architectural adjustments
my-codex.el)my-codex-session-token-count.my-codex--mark-sessionto cleanly instantiate this tracking state with zero assets during creation loops.my-codex-backend-sendto dynamically increment token weights during prompt submission sequences.my-codex-git.el)my-codex-prompts.el)Technical data strategies
We can approach metrics collection using one of three methodologies:
my-codex--approx-token-countutility to mathematically extrapolate token lengths over incoming prompts and outgoing message text blocks./statusor/creditsslash-commands into thevtermline, parsing the immediate output telemetry before cleaning up the screen buffer history.