Show HN: Frugal Tokens Shows Agent Costs

Frugal Tokens is a Show HN project from its maintainer for exploring usage and estimated cost across coding-agent sessions. Which sessions, models, cache misses, and long-running habits are actually driving spend? Cost visibility is most valuable at the session level, before you start arguing about budgets or blaming one tool.

Frugal Tokens is a local usage explorer for coding-agent work, with views for overall usage, estimated working time, overlapping sessions, model spend, and cache misses. That makes it relevant to Codex users, Cursor users, and anyone comparing agentic coding workflows across a real repo instead of a demo.

Start with the session, not the monthly bill

The interesting part of Frugal Tokens is not that it estimates spend. Plenty of tools can show a total.

The interesting part is that it lets you look at sessions. That is where coding-agent cost becomes explainable.

A monthly number tells you that something happened. A session view tells you what kind of work produced it: a refactor that kept rebuilding the world, a debugging loop that lost cache context, or three overlapping agents all reading the same large files.

One Hacker News reaction called the per-session explorer the best part, and that tracks with how developers actually debug systems. You do not tune a database by staring at the cloud invoice. You inspect the slow query.

For a Codex workflow, the equivalent might be a session that touches packages/api, runs tests five times, then re-reads a large generated file after every failure. If you only see total spend, the lesson is “use less AI.” If you inspect the session, the lesson might be “exclude generated files and give the agent a smaller verification loop.”

Don't treat token cost like a moral score. Expensive sessions are not automatically bad. A session that burns more tokens but lands a clean migration with tests may be cheap compared with a human afternoon. The question is whether the spend came from useful reasoning or avoidable churn.

Cache misses are a workflow smell

Frugal Tokens started from the maintainer’s curiosity about session cost and cache misses. That is a good instinct.

A cache miss is a moment where previously reusable model context is not reused, so the system has to pay more again for input that might have been avoidable. In coding-agent work, cache misses can show up when sessions go stale, context changes shape, prompts balloon, or the agent repeatedly reopens the same large surface area.

One developer in the discussion said the tool helped them notice cache misses after stepping away for an hour or more. That is the sort of tiny behavior that rarely appears in a policy doc but absolutely changes the cost profile of daily agentic coding.

Here is a concrete version.

You ask OpenAI’s Codex CLI to inspect a flaky test. It reads AGENTS.md, opens the test, checks the fixture, runs npm test -- --runInBand, and proposes a fix. Then you leave for lunch. When you return, you ask it to continue, but the session has lost enough reusable context that the next turn re-sends a lot of material.

The fix may not be “never pause.” That would be silly. The fix might be a better handoff note before you step away:

Handoff: flaky checkout test
- Current failing command: npm test -- checkout.spec.ts --runInBand
- Relevant files: src/checkout/applyDiscount.ts, tests/checkout.spec.ts
- Do not inspect dist/ or coverage/
- Next step: patch rounding branch, then rerun the single test file

That small receipt gives the next turn a tighter runway. It also makes the session easier to audit later in a tool like Frugal Tokens.

Watch for over-optimizing cache behavior before you understand the work. A cache miss during a genuine architecture shift may be fine. Repeated misses while the agent loops through node_modules, snapshots, or build artifacts are the smells worth chasing.

The project hit a real nerve

The Hacker News thread had the expected mix: curiosity, comparisons, and “my current tool only shows spend.” That last objection matters.

Spend-only reporting is useful, but it is shallow. It answers “how much?” without answering “why?”

Frugal Tokens appears to sit in the more useful middle. It is not trying to be a full observability platform. It is a developer-facing explorer that helps you notice patterns in local coding-agent usage: heavy sessions, overlapping work, model mix, and cache behavior.

That makes it part of a broader agentic coding shift. Developers are no longer only asking whether agents can write code. They are asking whether the work is inspectable enough to trust, review, and tune. That is the same reason memory tools are adding provenance signals, as in Heimdall Adds Trust Verdicts to Agent Memory, and why MCP boundaries are becoming a normal part of production agent setups.

For Codex users, this lands near AI coding governance, but the story is more concrete than that phrase sounds. You are trying to make the invisible loop visible: prompt, context, model, tool calls, tests, cache, cost, result.

Don't turn every insight into a rule. If the first reaction to a cost explorer is a long approval process, developers will route around it. Start with the debugging posture: what pattern surprised us, and what small repo habit would reduce the waste?

Add one repo rule before adding another dashboard

The practical use of Frugal Tokens is to inspect a few heavy sessions, then change one local habit. Not ten. One.

A good first habit is an AGENTS.md boundary for expensive context. Keep it boring and specific:

# Agent instructions

## Context boundaries
- Do not read generated files in dist/, build/, coverage/, or .next/ unless explicitly asked.
- Prefer the smallest relevant test command before running the full suite.
- When a task pauses for more than 30 minutes, write a 4-bullet handoff before continuing.

## Verification loop
- First run the targeted test for the touched package.
- Then run lint for the changed files.
- Only run the full suite when the targeted check passes or the change crosses package boundaries.

This is not about penny-pinching. It is about making agent behavior legible.

If Frugal Tokens shows that your expensive sessions cluster around build output, the boundary is obvious. If it shows overlapping sessions against the same task, your problem may be coordination. If it shows model spend concentrated in a few high-value refactors, maybe nothing is wrong.

MCP adds another boundary worth naming. The Model Context Protocol is a standard way for agents to connect to external systems such as repositories, issue trackers, document stores, and internal tools. If an MCP server exposes a huge document corpus, cost explorers can help you notice when a task keeps dragging that corpus into context for no good reason.

Don't measure cost without checking output quality. A cheap agent session that ships a brittle patch is not efficient. Pair cost inspection with code review guardrails: changed files, tests run, commands used, and any external context touched.

Try it safely

Use Frugal Tokens when you want to understand a few real sessions, not when you want to police every developer keystroke.

A small experiment is enough:

• Pick three heavy sessions from the last week.
• For each one, write down the task, model, rough outcome, and surprising cost driver.
• Check whether generated files, broad searches, stale sessions, or overlapping work contributed.
• Add one AGENTS.md instruction or handoff habit.
• Recheck the next three comparable sessions before changing anything else.

That last step matters. Without a before-and-after comparison, it is easy to confuse normal variation with improvement.

Common questions

What is the biggest limitation?

The biggest limitation is that estimated spend and usage traces are only as useful as the data available to the explorer. Treat the numbers as debugging evidence, not financial truth, and avoid comparing tools unless the inputs, models, and task shapes are similar.

Further reading

• Frugal Tokens
• Codex on GitHub
• Cursor Agent docs
• MCP specification

Next step

Open one expensive session and explain it like you would explain a slow test. If the explanation is “the agent kept reading things it did not need,” write one repo rule and measure again.