DEV Community: Jens Krause

Field Guide to the Token Species in Your Dev Team

Jens Krause — Wed, 29 Jul 2026 12:48:57 +0000

Every team that put AI coding agents on subscription seats created an ecosystem by accident. Subscriptions meter usage, so seats got caps, and caps produce behaviour. Watch the usage table for a week and four species emerge.

The Tuesday Extinction. Hits the weekly cap by Tuesday and honestly does not know why. Every question is a fresh session, every session inhales the whole repo, and by Tuesday lunch the meter reads zero. Not recklessness: a workflow bug, same genus as a memory leak.

The Ghost. Has never seen the limit screen and half suspects it is a myth. Asks one precise question and closes the terminal. In the usage table this row looks like an instrumentation error.

The Absentee Landlord. Wrote a cron job months ago that runs an agent nightly, then forgot it exists. It spends a slice of the cap while its owner sleeps, faithfully, indefinitely.

The Cartographer. Writes issues so complete that anyone could implement them. Also frequently broke, because a spec that good burns tokens too. The team's best specifications and its emptiest wallet share a chair.

Before you claim the Ghost: the heaviest burners are the surest of their restraint, so let a spend plugin that reads Claude Code's local session logs and reports per project and per branch assign your species.

This is not a personality quiz

I took personality tests and this is none. The field guide documents a market with no clearance mechanism: surplus on one side, starvation on the other, same team, same tool. The variance is habits and workflow, not talent or effort.

The whispered workaround, multiple subscriptions, is a terms-of-service violation, so no.

The Cartographer scopes an airtight issue and has no budget left to run it. The Ghost picks it up cold, zero context and zero further input, and spends leftover budget to implement it. Call it the Token Donor. The donor contributes compute, not knowledge: not review, not mentorship. One person supplies the thought. The other supplies the meter.

A donor needs a floor under the generosity, and a Tuesday Extinction deserves to find out before the cap decides for them. BudgetClaw, an open-source usage guard, reads the same logs and halts the run at a limit you set.

Efficiency is a skill, and nobody grades it

Token efficiency is a real engineering skill that no ladder document mentions. We promote people for what they built, never for what they declined to spend, so the Ghost's discipline reads as a quirk instead of capacity the team already paid for.

Make the first donated run a deletion. Agents produce comments that restate the line below them and tests that assert a mock returns what the mock was told to return, and nobody funds removal from their own cap. Donated surplus is the first budget subtraction has ever had.

Comments are open: which species are you, and did a dashboard or a hunch decide? Report whether your team hosts an Absentee Landlord nobody has met; the crontab knows things the standup does not. And if a colleague's meter has ever shipped your issue, or yours theirs, file a field report; documented cases are rare.

The price table most AI cost tools multiply by has one automated test: jq empty

Jens Krause — Sun, 12 Jul 2026 09:03:38 +0000

Most tools that tell you what your AI usage costs work the same way: count tokens locally, multiply by a shared price table. For most of the ecosystem that table is a single JSON file in the LiteLLM repo, and its only automated check is jq empty, which verifies the JSON parses. That is the entire quality gate: no value validation, no cross-check against provider pages, no guard against swapped input and output prices, no dates, no provenance.

This is not an obscure file. LiteLLM (BerriAI/litellm, ~51k stars, MIT) prices roughly 2,783 models. ccusage (~16.4k stars) re-pins it hourly, tokencost vendors a copy, ccost embeds it. An error in it is not one tool's bug; it is the whole ecosystem agreeing on a wrong number, with nothing left over to disagree.

Why I was in there

I maintain a spend monitor for Claude Code called BudgetClaw: it tails the local JSONL logs Claude Code already writes, computes cost in real time, and on a budget breach sends SIGTERM to the process. Zero keys, zero prompts, zero added latency. What sent me upstream was a Saturday spent grouping a month of usage by branch: about $2,770 total, one refactor branch at $543 by itself, mostly retry loops re-sending an 80K+ token context. But a tool that kills processes over dollars has to get the dollars right, and cache pricing makes that delicate: a cache read bills at 0.1x the base input rate, a 5-minute cache write at 1.25x, a 1-hour write at 2x. One wrong multiplier and the kill switch fires at the wrong moment or not at all. Quietly wrong is worse than loudly wrong. So before trusting the table, I read it.

Findings

1. Records that cite their own refutation. Four xai/grok-4.20-* rows are priced at $2 input / $6 output per million tokens. The source field on those same rows points at docs.x.ai, which says $1.25 / $2.50.

"input_cost_per_token":  2e-06,    // $2.00 per million
"output_cost_per_token": 6e-06,    // $6.00 per million
"source": "https://docs.x.ai/..."  // the cited page says $1.25 / $2.50

The wrong number and its own correction, in one record. jq empty passes; it parses flawlessly.

2. No guard against transposition. Input and output prices have been swapped before. The command-r7b fix had to bring its own test, because there was none to fail.

3. Provenance is optional. A source appears on about 31% of records. There is no last_validated, no confidence, no date field of any kind. For two thirds of the table, the reason to believe a number is that it is in the file.

4. The past is deleted. When a price changes, the old value is overwritten and gone. ccusage issue #764, closed unresolved, is users pointing out that today's prices get applied to all historical usage, so reported costs do not match what was charged. They asked for point-in-time pricing; the upstream model deletes the past, so it could not be given.

5. Merging a fix may not fix anything. The default branch is litellm_internal_staging. Public main can run about nine days behind it, serving a bug already fixed on staging, and a bulk staging sync can overwrite a community fix after it merges. A correct price can land, merge, and silently regress.

A control experiment

A static audit only goes so far, so I filed the grok fix and watched the pipeline handle it: BerriAI/litellm#30849, opened 2026-06-19. Twenty-eight lines, correcting both the root map and the bundled backup so they agree, plus the cost-calculator test that did not exist.

Weeks later it is open and unmerged, reviewed by exactly three entities: a CLA signature bot, greptile, and codecov. No human. I report this as data, not a grievance, and per finding 5, even a merge might not stick.

None of this is a scandal about people; it is what jq empty looks like at scale. That repo has fielded on the order of 1,158 pricing PRs, and no volunteer team hand-verifies that volume against provider pages. The maintainers run the most successful price table in the ecosystem exactly as well as its architecture allows. Every finding above is structural.

Diagnosis

The instinct is to call this a coverage problem and fix it with more rows. It is not. LiteLLM carries ~2,783 models, models.dev ~5,278; the set I actually need is 94. One bad price kills a cost tool, and 2,700 correct ones do not save it. A price with no source and no date is fine for an estimate and wrong for a bill.

Provenance-first is not exotic: every record carries a first-party source URL, an effective date, a last_validated date, and a confidence label. Corrections supersede old rows instead of deleting them, so priceOn(model, date) returns the rate actually in effect that day, which is what ccusage #764 wanted. A bot diffs each provider's own pricing page; a human verifies every change before it lands. I keep such an index for my 94 models, with history back to GPT-4's 2023 launch (github.com/RoninForge/ai-price-index, CC-BY).

The point

Parsing usage logs is the easy 90%; the tokens sit on your disk with model names attached. The dollar at the bottom is only as honest as the price it was multiplied by, and for most of the AI-cost stack that price lives in a JSON file whose sole certification is that it parses. jq empty answers one question: is this valid JSON. Every tool downstream is answering another: what did this cost. Right now nothing stands between the two.

The index is open. If I have a price wrong, the fix is a PR.

Nobody keeps the receipts for AI pricing, so I built the changelog

Jens Krause — Wed, 17 Jun 2026 11:04:01 +0000

I got one surprise AI bill that woke me up and I went looking for a simple answer: what did this model actually cost on the day I ran it?

Turns out that is weirdly hard. Provider pricing pages change quietly with no changelog. The Wayback Machine is patchy. And the obvious shortcut, today's price times last month's tokens, is just wrong the moment a provider shifts rates mid-period.

Whilst building a couple of small tools that calculate AI usage costs bugs popped up and traced back to one thing: I could not reliably say what a given model cost on a given date. Estimations are easy, knowing is hard.

So I built ai-price-index: an open, dated record of LLM API prices.

The idea is boring on purpose. Every price is bitemporal, it carries the date it became valid and the date I last re-checked it against the official source. So you can price historical usage point-in-time instead of extrapolating from today. Every price links its first-party source. A bot diffs the official pricing pages every day and flags drift, and I review every actual change by hand before it merges, because pricing is exactly the kind of data you do not want a scraper silently guessing on.

Where it stands:

10 providers, 86 models (Anthropic, OpenAI, Google, Mistral, xAI, DeepSeek, Cohere, Amazon Nova, AI21, Alibaba Qwen)
CC-BY-4.0, plain JSON, DOI on Zenodo (10.5281/zenodo.20730241)
Free, and staying free forever

If a price looks wrong or your provider is missing, that is the most useful thing you can tell me. Corrections and provider requests are open on GitHub.

Repo: https://github.com/RoninForge/ai-price-index
Browse it : https://roninforge.org/data/ai-price-index/
Hugging Face: https://huggingface.co/datasets/RoninForge/ai-price-index

Demo Integration :

Snap Shot: how much are all models on Jun 17th 2026?
Model Price Visualization