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 skills add douglasmonsky/codex-usage-tracker --skill usage-kernelgit clone --depth 1 https://github.com/douglasmonsky/codex-usage-trackerWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/douglasmonsky/codex-usage-tracker/usage-kernel)<a href="https://agentmods.dev/skills/douglasmonsky/codex-usage-tracker/usage-kernel"><img src="https://agentmods.dev/badge/skills/douglasmonsky/codex-usage-tracker/usage-kernel/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/douglasmonsky/codex-usage-tracker/usage-kernel"><img src="https://agentmods.dev/badge/skills/douglasmonsky/codex-usage-tracker/usage-kernel.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high System Prompt Leakage · line 80 Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.Fix: Remove any instructions that reveal, print, or output system prompts or internal rules. System instructions should never be exposed to end users.
What 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.1 | $0.00028 | $0.01030 |
| Opus 5.5 | $0.00011 | $0.00412 |
| Sonnet 5.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 1mo ago.
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.
- 1mo ago 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 (196 stars, last pushed yesterday), licensed MIT. It adds 28 tokens to every session and 1,030 once invoked, about $0.0001 per session on Opus 5.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
Guidance for choosing the smallest suitable development process based on a task's risk and complexity.
disposable-prototype
A small, isolated experiment used to answer a specific technical or interaction question before full implementation. Its code is temporary by default and is not treated as a publishable feature.
domain-context
A lightweight guide for finding and applying a project's domain terms, business rules, recorded decisions, and constraints. It can read files such as CONTEXT.md and architecture decision records when they exist.
module-design
A lightweight method for improving how code is divided into modules, where modules are parts of a program with defined responsibilities.
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.
playwright
Use when the task requires capturing or automating a real browser from the terminal.