tokenomy-pi
Automatic token-saving router for the Pi CLI using Pi's openai-codex provider, with visible local usage and quality evidence.
Package details
Install tokenomy-pi from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:tokenomy-pi- Package
tokenomy-pi- Version
0.2.0-beta.3- Published
- Jul 27, 2026
- Downloads
- 3,755/mo · 155/wk
- Author
- odyshev
- License
- MIT
- Types
- extension
- Size
- 351.3 KB
- Dependencies
- 2 dependencies · 2 peers
Pi manifest JSON
{
"extensions": [
".pi/extensions/tokenomy/index.ts"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
Tokenomy Pi Extension
Tokenomy is a token-economy layer for Pi users working with Codex through a ChatGPT Plus subscription. Its shipped defaults and live evaluation are focused on Plus. ChatGPT Pro has not been tested and is outside the currently supported subscription scope; the project makes no Pro compatibility claim.
This package is a Pi extension, not a native OpenAI Codex CLI extension.
It depends on Pi's extension lifecycle and uses Pi's openai-codex provider.
Tokenomy is designed to reduce total token spend during normal project work without forcing you to manually choose a model for every prompt.
The product goal is:
Spend fewer tokens while preserving the original prompt intent and the quality of the final answer.
After installation, Tokenomy runs automatically before each agent turn. It classifies the prompt, chooses the cheapest Codex model tier that should still solve the task, and upshifts when the work looks risky, broad, or release-like. It also uses local project memory, classifier prompt simplification, TokenShrink compression, safety guards, and routing telemetry to reduce repeated context cost without rewriting the final user prompt.
Tokenomy is useful when the same project contains mixed work:
- quick questions and explanations
- cheap shell commands like
ls -l - targeted reads and small edits
- debugging and test failures
- larger refactors or architecture work
- release, version, and npm/GitHub Actions flows
Instead of sending all of that to the strongest available model, Tokenomy keeps easy work cheap and reserves stronger models for prompts where a weak attempt is likely to cost more through retries, excessive tool calls, or incorrect edits.
What Tokenomy Does By Default
- Routes simple and low-risk prompts to cheaper Codex models.
- Upshifts complex, risky, debug, architecture, and release prompts.
- Detects prompt shape locally with
compromise, including question/action/mixed prompts and concrete multi-step action requests. - Preserves the user's startup model, then restores both the pre-route model and thinking level after each fully settled prompt.
- Uses a confidence threshold before trusting classifier decisions.
- Applies a per-session classifier budget and a conservative break-even check, so routing does not spend more estimated credits than it can plausibly save.
- Offers
save,balanced, andqualityeconomy modes. - Falls back conservatively when routing confidence is too low.
- Learns local project memory such as package names, test commands, important files, and release workflow hints.
- Keeps memory injection and routing-digest injection opt-in so the default system-prompt prefix stays cache-friendly.
- Simplifies and compresses large classifier prompts so routing itself stays cheap.
- Rejects compression when protected signal lines would be rewritten or dropped.
- Measures provider-reported input, cached-input, cache-write, output, reasoning, total-token, request, and cost usage after each turn.
- Builds daily, monthly, and lifetime telemetry rollups with explicit measured/unavailable coverage, configurable plan-credit estimates, completion/tool-error proxies, verified user feedback, correction signals, evaluator scores, tool-output measurements, and measured compaction savings.
- Provides
/tokenomy dashboardwith 7/30-day trends, budgets, quality evidence, per-tier spend, estimated remaining turns, mode comparisons, and quota-adapter status. - Offers project-local data inventory and selective purge commands without removing configuration.
- Supports deterministic opt-in economy-mode experiments with no-cost shadow tier decisions.
- Routes English, Ukrainian, Russian, Spanish, French, German, and Portuguese instructions locally.
- Supports provider-qualified model IDs, provider allowlists, optional live model discovery, and a validated external rate-card file.
- Shows recognized provider limit headers when available, with explicit project/process scope.
- Accepts an explicit account-quota snapshot from a user/companion adapter without inventing unavailable ChatGPT Plus totals.
- Supports manual task-preserving compaction and opt-in threshold compaction.
Tokenomy does not rewrite the final prompt sent to the selected agent model. Memory and compression are routing/context optimizations only, and the current user prompt always overrides remembered project facts.
Current Scope
Tokenomy's shipped defaults remain focused on one well-defined setup:
- Pi users authenticated with ChatGPT Plus Codex access. This is Tokenomy's primary, live-tested setup.
- ChatGPT Pro is untested and unsupported for now. It may work, but users should not infer compatibility from the Plus results.
- The
openai-codexmodel family exposed by Pi. Other providers are supported only as an experimental configuration surface through provider-qualified model IDs and an explicit allowlist; the project does not ship or test their routing tiers or rate cards. - Project-local routing through
.pi/extensions/tokenomy/index.ts. - Local-only memory, cache, telemetry, and compression. No external database or external memory API is used.
- Local routing signals for English, Ukrainian, Russian, Spanish, French, German, and Portuguese. Unknown scripts bypass routing for that turn.
Tokenomy is still beta software. It is ready for private dogfooding and early adopter use, but it is not yet a universal model router for every provider, model catalog, or coding-agent runtime. Multi-provider configuration is available, but the shipped tiers and rate card remain intentionally optimized for Codex models available to ChatGPT Plus users through Pi.
Files
.pi/extensions/tokenomy/index.ts— Pi extension implementation.pi/extensions/tokenomy/lib/— storage, config, and model-policy modules.pi/tokenomy.json— project configuration.pi/tokenomy.schema.json— editor/validation schemaINSTALL.md— install and update instructionsCONFIG.md— full configuration referenceLIMITATIONS.md— known limitations and beta caveatsEVALUATION.md— reproducible methodology and latest signed-in evidenceSECURITY.md— security and stored-data notesCONTRIBUTING.md— development and release checklist
Usage
See INSTALL.md for full setup steps. The short version is:
pi install npm:tokenomy-pi@beta
For project-local install:
pi install -l npm:tokenomy-pi@beta
Then authenticate Codex in Pi and start Pi from the target project.
Start Pi in this directory:
pi
Make sure Codex is authenticated with your ChatGPT Plus account:
/login
Then select the openai-codex provider.
Useful commands inside Pi:
/tokenomy
/tokenomy off
/tokenomy on
/tokenomy mode save
/tokenomy mode balanced
/tokenomy mode quality
/tokenomy reload
/tokenomy explain
/tokenomy history
/tokenomy dashboard
/tokenomy feedback success
/tokenomy feedback partial
/tokenomy feedback failure
/tokenomy quota
/tokenomy report
/tokenomy report 7d
/tokenomy report 30d
/tokenomy report month
/tokenomy report lifetime
/tokenomy limits
/tokenomy compact
/tokenomy memory
/tokenomy memory show
/tokenomy memory refresh
/tokenomy memory clear
/tokenomy memory on
/tokenomy memory off
/tokenomy export-history
/tokenomy export-report
/tokenomy reset-history
/tokenomy reset-stats
/tokenomy dry-run on
/tokenomy dry-run off
/tokenomy debug on
/tokenomy debug path
/tokenomy debug purge
/tokenomy debug off
/tokenomy data
/tokenomy data purge cache
/tokenomy data purge telemetry
/tokenomy data purge memory
/tokenomy data purge debug
/tokenomy data purge all
/tokenomy doctor
/tokenomy status shows the current routing state, last decision, accounting
mode, and the plan rate-card version.
/tokenomy explain shows the signals and reason for the last routing decision.
/tokenomy history shows recent prompt-safe routing telemetry.
/tokenomy dashboard shows project-local trends, quality evidence, budget
alerts, tool/compaction measurements, and per-mode comparisons.
/tokenomy feedback success|partial|failure attaches a verified user rating to
the latest completed routed turn.
/tokenomy quota reads a validated project-local account snapshot. ChatGPT
Plus does not expose a public personal quota API to Tokenomy, so missing totals
are displayed as unavailable rather than guessed.
/tokenomy report shows a 30-day local telemetry report with measured token
usage, cache-read ratio, estimated plan credits, completion/tool-error proxies,
route distribution, and fallback/guard counts.
Use /tokenomy report 7d, /tokenomy report 30d, /tokenomy report month, or /tokenomy report lifetime for specific periods.
/tokenomy limits shows the latest recognized provider limit headers when Pi
can see them; it is not an account-wide quota report.
/tokenomy compact triggers task-preserving context compaction.
/tokenomy memory shows local project memory status.
/tokenomy memory show shows stored project facts.
/tokenomy export-history shows the local routing history file path.
/tokenomy export-report shows the local telemetry rollup file path.
/tokenomy reset-stats clears local lifetime counters.
/tokenomy reset-history clears local routing history.
/tokenomy debug on starts an opt-in local JSONL trace for debugging
Tokenomy decisions. Payload fields are redacted by default; set
debug.redact to false only for a deliberate raw capture.
/tokenomy data inventories every project-local Tokenomy state file and its
size. /tokenomy data purge cache|telemetry|memory|debug|all removes only the
selected class; all asks for confirmation and preserves configuration.
/tokenomy doctor checks configuration, configured models, private storage,
the bundled schema, and rate-card freshness.
Live evaluation
Normal CI uses mocked providers and never consumes plan quota. After signing in to Pi, run the opt-in production scenarios with:
TOKENOMY_LIVE_EVAL=1 npm run test:live
The runner uses a temporary project, verifies a simple answer and two coding
tasks, and writes routing/usage evidence to
tokenomy-live-evidence.json inside that temporary directory. Set
TOKENOMY_LIVE_EVALUATOR=1 to include the independent model evaluator, or
TOKENOMY_LIVE_EVAL_OUTPUT=/path/evidence.json to choose the artifact path.
The manual Live Tokenomy Evaluation workflow runs the same suite only on a
self-hosted runner that is already signed in to Pi.
For a controlled comparison against one fixed model, run:
TOKENOMY_ECON_EVAL=1 npm run test:economic
This uses paired fresh workspaces with counterbalanced execution order,
requires an explicit quality non-inferiority gate, and reports measured token
and estimated plan-credit deltas. The smoke profile runs five cases once. Use
TOKENOMY_ECON_PROFILE=full for the 30-case corpus (three repeats by default),
TOKENOMY_ECON_ARMS=baseline,router,full to include the live classifier, and
TOKENOMY_ECON_MANIFEST=/path/scenarios.json for real-repository fixtures. It
consumes real Plus quota.
Routing decision notifications are enabled by default so you can see when
Tokenomy switches models. To disable them, set ui.notifyDecisions to false
in .pi/tokenomy.json.
You can also disable it for one run:
pi --tokenomy-off
What it optimizes
Tokenomy considers total token usage, not just model cost:
- prompt/context size
- hidden thinking level
- output verbosity
- unnecessary tool schemas
- unnecessary tool calls
- retry risk from underpowered routing
On startup, Tokenomy preserves the model already selected by the user. It selects the configured complex model only when Pi starts without any current model. Each turn records the pre-route model as its baseline without claiming that a different model would necessarily have consumed the same tokens.
For simple prompts it prefers the cheapest/fastest configured Codex model, minimal thinking, concise answers, and no tools when tools are unnecessary.
For complex/high-risk prompts it may choose a stronger model because a weak model can waste more tokens through failed attempts, excessive tool loops, or corrections.
How routing works
Tokenomy runs before each agent turn and makes a routing decision from local
signals first. That local pass does not spend model tokens. It looks at prompt
length, context size, images, and task language such as explain, review,
debug, implement, refactor, security, or performance.
The local heuristic assigns:
- a tier:
simple,medium, orcomplex - an intent such as
answer,shell_simple,read,single_edit,multi_edit,debug,architecture,local_workflow, orrelease - a risk level:
low,medium, orhigh - a tool profile:
none,read, orwrite - a prompt shape:
question,action, ormixed, plus action count and multi-step signal - a confidence score
- a list of signals that explain the decision
If the prompt is simple and the heuristic is confident enough, Tokenomy routes directly to the simple tier. If the prompt looks risky or likely to need edits, multi-step reasoning, broad code inspection, or careful design work, it routes to a stronger tier.
Short follow-up prompts such as continue, go on, or proceed inherit the
previous routing context in the current session, so Tokenomy does not downshift
in the middle of an ongoing complex task.
Broad review prompts such as please do an audit, please review, or
please refactor are treated as deep project work and route to the complex
tier. Targeted audits, such as focused config or dotfiles checks, can still
route to the medium tier when the scope is narrower.
Tokenomy also analyzes prompt shape locally without a model call. It uses the
compromise NLP library for sentence, question, and verb detection, then
applies Tokenomy's coding-agent action filters. Simple questions can stay cheap,
but explicit multi-step requests or prompts with several concrete actions route
to the complex tier because a weak first attempt is likely to cost more through
retries. Focused single edits and local workflows can still route to the medium
tier.
Trivial general prompts such as what time is it?, how time is it?,
thanks, or local info questions answerable with one read-only command stay on
the cheapest model even when the current project context is large. The trivial
path is not used when the prompt mentions project files, logs, tests, code, or
tool work.
Tokenomy currently supports English routing instructions only. If a prompt is primarily written in another language, Tokenomy bypasses routing transparently and leaves the current Pi model/tool state unchanged. English instructions may still include non-English text as payload, such as text to translate or a code comment to preserve.
For ambiguous prompts, Tokenomy can ask the cheapest configured classifier model
for a tiny JSON decision. The classifier is only accepted when its confidence is
at least classifier.minConfidence, which is 0.95 by default. Accepted
classifier decisions are cached locally by normalized prompt, context bucket,
intent, and risk so repeated routing questions do not keep spending classifier
tokens.
If classifier confidence is below that threshold, classifier output is unavailable, or the local heuristic is below the same confidence threshold, Tokenomy uses fallback. Fallback is risk-aware:
- low-risk uncertainty falls back to the cheapest configured available model
- medium-risk write/debug work falls back to the medium tier
- high-risk architecture/release work falls back to the complex tier
This policy keeps cheap fallback for basic uncertainty while avoiding expensive retries on risky prompts.
When explicitly enabled, Tokenomy can inject a compact digest for large or
repeated project contexts from .pi/tokenomy-cache/project-digest.json. The digest stores
routing metadata such as intent counts and last route, not prompt text or model
responses. Digest injection defaults to off because its changing content can
reduce exact-prefix prompt-cache reuse.
Tokenomy also keeps local per-project memory in
.pi/tokenomy-cache/project-memory.json. Memory learning is enabled, while
prompt injection defaults to off. It stores short durable project facts such as
package names, test commands, important implementation files, and release
workflow hints. Memory is
advisory: the current user prompt always overrides it. Tokenomy injects memory
only after memory.inject is enabled and the turn is likely to save repeated
discovery. It does not store raw prompts or model responses.
For large prompts that need classifier help, Tokenomy locally simplifies the classifier prompt first. It keeps head/tail context and signal lines such as errors, failed tests, file paths, and counts. The original user prompt is still sent to the selected agent model.
Tokenomy also applies local TokenShrink compression to classifier prompts. It
keeps the compressed version only when TokenShrink reports enough saved tokens,
so compression should not increase routing cost. TokenShrink compression is
enabled by default and can be disabled with
promptSimplification.compressionEnabled: false.
Tokenomy also adjusts thinking level by tier:
simple: minimal thinkingmedium: low thinkingcomplex: medium thinking
After agent_settled, Tokenomy restores the model and thinking level selected
before routing. Each value is restored only if it still matches the value
Tokenomy selected; explicit changes made during execution are preserved.
Decision notifications show the selected tier, source, model, and thinking
level. Tokenomy does not write a main Pi footer/status
entry because Pi renders plugin footers in shared terminal space and long
entries can crowd other extensions. Use /tokenomy status for the current
routing state and accounting contract. Legacy pre-v2 proxy counters remain in
.pi/tokenomy-stats.json.
Recent routing decisions are stored locally in
.pi/tokenomy-cache/routing-history.json when telemetry is enabled. Telemetry
stores prompt hashes, routing metadata, compression guard status, measured
usage, and estimated plan credits—not raw prompt text.
Longer-term telemetry is stored in
.pi/tokenomy-cache/telemetry-rollups.json as daily, monthly, and lifetime
prompt-safe aggregates. Rollups include exact provider-reported token
categories, cache-read ratio inputs, request counts, Pi-reported cost,
rate-card-based plan-credit estimates, classifier overhead, route distribution,
adaptive fallbacks, prompt shape, quality feedback, experiment cohorts,
tool-output measurements, compaction savings, and compression guard rejections. Historical
non-zero estimatedTokensSaved/cost-unit fields are labeled as pre-v2 model-rank
proxies and are never presented as tokens or credits.
Reports cover only this Pi project. They do not claim to represent total account-wide ChatGPT or Codex usage.
Configuration
Edit .pi/tokenomy.json. See CONFIG.md for every option.
Safer defaults for sharing:
tools.manageisfalseunless you opt indebug.dryRunlets you see routing without changing model/tool statedebug.traceis disabled by default; enabled traces are redacted by default, retained for seven days, and stored with private permissionspromptSimplification.enabledreduces classifier prompt size for large logspromptSimplification.compressionEnabledcontrols localtokenshrinkcompression and defaults totruememory.enableddefaults totrue;memory.injectdefaults tofalsefor prompt-cache stabilitydistillation.enableddefaults tofalsefor the same reason
Default Codex model preferences are:
- classifier:
openai-codex/gpt-5.4-mini - simple:
gpt-5.4-mini, thengpt-5.6-luna - medium:
openai-codex/gpt-5.6-terra - complex:
openai-codex/gpt-5.6-sol
The authenticated Plus catalog checked on 2026-07-27 also exposed
gpt-5.3-codex-spark. Tokenomy records it in the known catalog but does not
route to it by default because no verified plan-credit rate is bundled.
npm run test:catalog compares the current authenticated Pi catalog with these
defaults and fails when a configured model disappears or the rate card is
stale.
If you want the fallback selection to be smarter than string sorting, Tokenomy uses explicit model-family ranking rather than relying on IDs.
If your available model list differs, run:
pi --list-models openai-codex
Then update .pi/tokenomy.json.
Debug Trace
For difficult routing issues, Tokenomy can write a local session trace that is optimized for debugging routing decisions and feature interactions:
/tokenomy debug on
/tokenomy debug path
/tokenomy debug purge
/tokenomy debug off
The trace is stored as JSONL in .pi/tokenomy-cache/debug/session-*.jsonl.
Sensitive payload fields are redacted by default, files are private (0600
where supported), and traces older than debug.retentionDays are removed at
session start. Set debug.redact: false only for raw local diagnostics and
purge them afterward.
This is intentionally off by default. When enabled, Tokenomy shows a warning because the trace may include raw prompts, model/tool outputs exposed to Tokenomy, classifier prompts and responses, memory context, compression data, routing decisions, and internal errors. Normal telemetry remains prompt-safe; debug trace is the explicit opt-in path for full local visibility.
Before public sharing, review COMPATIBILITY.md, LIMITATIONS.md, and
CHANGELOG.md.
Future direction: Tokenomy may add an optional local side-LLM path, such as Ollama or another local model, for heavier prompt compression and prompt complexity determination. The current release keeps compression deterministic and local through TokenShrink.
Tests
Run the integration tests with:
npm test
The tests use Node's built-in test runner and a mocked Pi runtime. They verify startup model preservation, current Pi lifecycle events, model/thinking restoration after settle, exact usage aggregation, plan-credit conversion, explicit unavailable status, stable default system additions, model routing, classifier caching, opt-in memory/digest injection, and classifier-compression guards.