Are tokens the new unit of effort?

Token Efficient Builders is a Chrome extension and toolkit that tracks what Claude and OpenAI usage costs in tokens and teaches what drives that cost. This is a devlog about its newest piece, Token Guard, and about a thought I keep having while building it: with AI in the loop, we are starting to count human effort in tokens. I think that is half true, and the other half matters more.

What is Token Guard, and why build it?

The repo started as a Chrome MV3 extension that logs token spend for Claude and OpenAI, estimates what that spend would cost, and keeps a record of Cursor usage. Around it grew a set of standalone HTML calculators (a token counter, a cost estimator and a burn-rate calculator) and a playbook of 7 guides on what makes a prompt expensive.

Token Guard is the part that sits closest to the work. It is a small Python MCP server that talks over stdio and logs usage into SQLite, so an agent session can write down what it spent while it is spending it. My reasoning: you cannot plan around a number you never see. Plainsight does something similar by telling you which of its own features the research supports. Show the evidence, then let people decide.

Why does effort feel like tokens on a Max plan?

I do not pay per token. I use Claude on a Max 5x subscription, which the Max plan help article (read 15 September 2026) lists at $100 a month for five times the per-session usage of Pro. So a token never arrives as a line on an invoice. It arrives as a progress bar.

Anthropic’s usage limit best practices page describes those bars under Settings, Usage: one for the five-hour session limit and one for weekly limits. Its usage and length limits article says usage depends on conversation length and complexity, the features used, the model and the effort level, and that claude.ai, Claude Code and Claude Desktop all draw from the same limit.

This is where it stops being about money. After a long refactor I do not ask what it cost. I ask how much of my window it ate, and whether I still have enough left to finish the evening. Effort, for me, has quietly become a fraction of a five-hour bar.

What changed in version 0.3.0?

Version 0.3.0 of the extension landed on 15 September 2026, the same day I wrote the token count was never the metric. That post covered what the tracker is for. This one covers what broke and what got fixed. Most of it was remediation, the kind of fix that only shows up once you use your own tool every day.

• Re-keying could lose your API key. A bug in the re-key path could leave a stored key unrecoverable. It now trial-decrypts with the old key before it re-encrypts anything.
• A race lost usage records. Two writes doing read, modify, write at once could drop an entry. Writes now run through a per-key promise chain.
• The day started at the wrong time. Days were UTC, so in US Central the dashboard read 0 every evening. There is now a local day window with a “my day starts at” setting.
• New tools: session labels, per-entry edit and delete, a Count tab that puts an exact count_tokens result next to a heuristic estimate, an opt-in Claude status and release-notes tab, and an effort layer.

One small discovery: there is no Anthropic news RSS feed. The address I tried returned 404 again today, so the release-notes tab reads the Claude Platform release notes page instead. The status tab reads status.claude.com, which said All Systems Operational when I checked tonight.

The testing grew too: 48 browser tests in real Chromium, including a WCAG contrast audit, a mutation campaign of 26 mutants, and an 8-step first-run walkthrough. The same habit of checking my own assumptions came out of the memory file was the bug, where a stale note cost a whole rebuild.

How do you count Claude tokens before you send a prompt?

Anthropic’s token counting docs describe an endpoint that accepts the same structured input as a real message (system prompt, tools, images, PDFs) and returns the number of input tokens. As of 15 September 2026 the page says it is free to use, with its own requests-per-minute limit that is separate from message creation. It also says plainly that the count is an estimate and the real number can differ by a small amount.

That is why the Count tab shows two numbers side by side. The heuristic is instant and works offline. The exact count needs an API key and a network call. Seeing both teaches you how far a rule of thumb drifts on your own prompts.

There is a catch worth knowing. The same docs say Claude 4.7 and later models use a newer tokenizer that produces roughly 30 percent more tokens for the same text, and tell you to recount against the model you plan to use rather than reuse old counts. A token is not a fixed unit even inside one company.

What makes a Claude request use more tokens?

Short version: more text in, more text out, and more thinking in between. The docs I read today name a few levers.

• Effort. The effort parameter controls how many tokens Claude spends on a response. The API default is high, and the page calls effort a behavioral signal, not a strict token budget.
• Context. The context windows page lists a 1M-token window for current models and warns that accuracy and recall degrade as the count grows, which it calls context rot. Bigger is not free.
• Caching. Prompt caching charges 1.25 times base input for a 5-minute cache write and 0.1 times for a cache read on most models. Prompts under the model’s minimum length are simply not cached, with no error.
• Model choice. The pricing page lists Claude Opus 5 at $5 per million input tokens and $25 per million output tokens, and Claude Haiku 4.5 at $1 and $5.

Those are API prices, dated 15 September 2026. On a subscription they turn back into bar movement, but the shape is the same: output costs more than input, and a repeated prefix is cheaper the second time.

Can tokens measure human effort?

Here is the thesis. When most of my building runs through a model, the work leaves a trail measured in tokens. Anthropic’s own Economic Index maps Claude conversations to occupational tasks and found in its first report (2025) that use leaned toward augmentation (57 percent) over automation (43 percent). If AI is part of how the work gets done, the tokens look like a record of the work.

Now the counterargument, which I find stronger.

• Tokens measure the model, not me. They count what was read and generated. They do not count the walk I took before I knew what to ask.
• Short can be expensive. A 40-token question can hold a week of thinking. A 40,000-token log dump can hold none.
• Counts are not comparable. Tokenizers differ between vendors and, per the token counting docs, between Claude generations. The same sentence has different sizes.
• Targets bend measures. This is Goodhart’s law. Manheim and Garrabrant’s paper Categorizing Variants of Goodhart’s Law describes how optimizing a metric past a point becomes ineffective or harmful, and notes the risk grows with the optimization power AI brings. Grade people on tokens and you get padding.

What is still not done in Token Guard?

• Every insert still re-serializes the whole stored array. That is write amplification, and the real fix is a tiered index.
• The live count_tokens request has not been run for real yet, and neither has the Python Token Guard test suite.
• The extension is not submitted to the Chrome Web Store.
• There is no project page yet. When there is, it will join the others on the projects page.

Until then, progress notes land on the devlog, and every past post is in the full history.

So what is a token count good for?

My position: a token count is a receipt, not a measure of worth. A receipt is useful. It tells me a big refactor eats a third of a session, so I start it in the morning. It tells me a cached system prompt is cheaper the second time. It also shaped how I split up the work on CaptureTools and the comparison in one extension, or six?

What it cannot do is tell me whether the work was good, or how hard it was to think of. Token Guard will keep counting. I will keep deciding what the counting means. Questions are welcome at dhseadev@gmail.com, and there is more about me on the about page.