mfltok · a measuring instrument
Every time an AI assistant reads a file, you pay for it — by the token, on every single read. Most tools that claim to count tokens are estimating. This one measures.
Measured — this project, read once
8,399 tokens · $0.08
Ten files. That is the bill each time an assistant loads the whole thing — and it will load it many times in a working session.
The common shortcut is to guess: count the characters, divide by four. It is fast, it looks reasonable, and it is wrong.
We measured our own estimator against the real thing. It undercounted by 18.6% — and, more damaging, it was wrong unevenly. Dense, punctuation-heavy files were off by 25%; simple ones by 6%. So the list of "your biggest files" came out in the wrong order. Not just the totals were wrong. The ranking was.
mfltok replaces the guess with the same arithmetic the model itself uses. It has been checked against the reference implementation 166,350 times, and agrees exactly every time.
Once you can measure honestly, most of the usual advice stops surviving contact with the numbers. We tested the three common suggestions on real code:
| Suggested fix | Effect | Verdict |
|---|---|---|
| Split a big file into smaller ones | −0.03% | Nothing. Same words. |
| Reflow long lines | +0.18% | Nothing. Slightly worse. |
| Don't load the file at all | −100% | The only real lever. |
This is the whole insight, and it is unglamorous: you cannot reformat your way to a smaller bill. Rearranging the same words costs the same. The only thing that helps is deciding what the assistant never needs to look at.
Scanning one real project, a single 8-megabyte file — a compiled program that nobody would ever want an assistant to read — accounted for this much of the total:
5,870,023 tokens of pure noise from one file, sitting inside a measurement that otherwise looked completely healthy. Finding a single item like that is usually worth more than every formatting change you could make.
Point it at a folder and read the report.
You get the total, what a full read costs, the heaviest files in order, which ones are machine-generated — and, importantly, a count of everything it left out. A tool that quietly skips files while implying it measured all of them is the thing this was built to avoid.
Same command, structured output, no parsing of prose.
The practical use: check the cost before reading something, and skip what isn't worth it. Two of the heaviest files in a typical project are generated ones no one needs to see.
It never claims to have saved you anything. It is a measuring instrument — it does not sit between you and the assistant, and it cannot lower a bill by itself. It tells you where the money goes; the deciding is yours.
That restraint is deliberate. A well-known tool in this space advertised "96.2 million tokens saved" while a controlled experiment found its users' bills had gone up 7.6%. Any tool that grades its own homework can produce a number like that. So this one publishes no savings figure at all.