Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/douglasmonsky/codex-usage-tracker/usage-kernelnpx skills add douglasmonsky/codex-usage-tracker --skill usage-kernelgit clone --depth 1 https://github.com/douglasmonsky/codex-usage-trackerWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00028 | $0.01030 |
| Opus 5 | $0.00014 | $0.00515 |
| Sonnet 5 | $0.00006 | $0.00206 |
| Haiku 4.5 | $0.00003 | $0.00103 |
Grade A, and why
usage-kernel scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Codex Usage Tracker
Use the tracker as a factual local data plane. The tools return exact or explicitly graded facts; the model owns inference, explanation, and recommendations.
Use the three-step loop scope → batch → evidence:
- Scope. Start with the needed
usage_querywhenever the question maps to a curated template or a known typed request. The result carries its generation, grade, history coverage, and cache state. Callusage_statusonly when the query reports an absent or insufficiently fresh index, or when the user explicitly asks about operational state. A committed generation remains queryable while refresh is active or recommended. When the needed fields are unfamiliar, setinclude_guidance=trueon the sameusage_querycall that carries the first batch; use an empty batch only for standalone capability discovery. - Batch. Prefer one batched
usage_querycall. Its arguments always wrap one or more query requests in therequestsarray. Execute a curated server-side template with{"requests":[{"template":"<name>"}]}; for the common thread leaderboard use{"requests":[{"template":"top_threads"}]}. Templates query the hydrated snapshot and report its coverage; refresh complete history only when the user asks. For same five ranked threads, use result 1 for labels, selectors, totals, shares, and token classes; use result 2 only for cost/credits. Do not query again unless user asks for evidence. Use{"requests":[{"template":"weekly_drivers"}]}for the latest indexed seven-day thread leaderboard,{"requests":[{"template":"week_over_week"}]}for that window versus the immediately preceding seven days, and{"requests":[{"template":"latest_incremental_change"}]}for the active generation's inserted calls and leading affected thread. These templates derive their anchors from the committed snapshot; do not discover dates or generation numbers first. Use{"requests":[{"template":"model_effort"}]}for model/effort mix and{"requests":[{"template":"tools"}]}for structural tool facts. Do not repeat a successful curated template or request guidance after it returns rows. Supplyparametersonly when the selected template requires them. Otherwise send only the typed dataset, operation, dimensions, measures, filters, and limits needed for the question. Do not copy or reconstruct a returned template body. Preserve the returned generation, grade, coverage, counts, and explicit row/byte limits. Compose filters as{field, operator, value}using only the dataset fields and operators infilter_grammar;intakes an array of 1–25 values. Phase queries require one returned scope-filter template for a thread, turn, or time window. - Evidence. Rank candidates from the facts first. Call
usage_evidenceonly after ranking, and only with an exact returned logical selector. Uselive=truefor the same timeline in live mode.
Label every claim:
- fact — returned exact/deterministic data; for
partial, state the hydration preset/cutoff and never generalize to all history; - estimate — returned estimated data with coverage and provenance;
- hypothesis — model inference that still needs evidence;
- unsupported — unavailable from the returned scope and not asserted.
The optional context dataset is aggregate-only private local evidence. Its
observed_bytes and events measures are exact for the structurally observed
payload strings that were indexed. estimated_tokens is available only when
an explicit tokenizer populated it; always preserve its estimator identity and
coverage. Never describe category bytes or estimates as exact billed input
tokens, and keep unattributed_input_tokens unsupported when the response
reports it as null. If context composition is disabled, continue with the
base accounting datasets instead of starting hidden work.
Call usage_refresh only when freshness matters. Reuse the returned job; never
start a duplicate. Use usage_job_status with a bounded wait_seconds value
so the host waits; do not short-interval poll from the model. Use
usage_allowance for observed allowance facts and preserve its provenance and
limitations. Do not infer waste or productivity from token totals alone.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 82 lines · 28 tokens per session scan A 39e746389bb0
usage-kernel is a skill published in the GitHub repository douglasmonsky/codex-usage-tracker (193 stars, last pushed 11d ago), licensed MIT. It adds 28 tokens to every session and 1,030 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
cost-aware-development
先按风险选择最低可胜任能力,再决定需要多少流程和角色。简单任务保持简单;成本优化不得绕过真实风险、安全边界或完成证据。.
disposable-prototype
当实现前可用最小可运行实验回答具体技术或交互未知时使用;产物默认不可发布,且这是轻量叶子能力,不负责任务编排。.
domain-context
当开发任务需要澄清领域术语、业务不变量、CONTEXT.md 或 ADR 约束时使用;这是轻量叶子能力,不负责任务编排。.
module-design
当用户要求改善模块边界、降低耦合、缩小变更面或评估代码结构时使用;这是轻量叶子能力,不负责任务编排。.
codex-plugin-discovery
Use when a user asks what Codex plugins are available or can be used, wants plugin recommendations for a task, asks to find/search/discover installable plugins, asks about the plugin marketplace, or asks whether a plugin can help with a task.
final-release-review
Perform pre-release planning or a final release-candidate review for openai-agents-python by comparing the target with the previous remote tag, determining the minimum compatible release type, auditing regressions and contract changes, reviewing open documentation PR coverage, drafting minor-release Key Changes, and…