Free Tokens Are a Claim. Publish a Claim-to-Test Ledger Before You Standardize

A message like this lands in an engineering lead's inbox about once a quarter:

"MonkeyCode is open source. Free model access, and a free server option. Give it a try."

Two sentences. No workload, no data class, no expiry date. And still enough to start a standardization debate, because the alternative — self-hosting, or a paid seat — has an actual line item attached. Free is the only option in the room with a zero on the invoice.

So I ask a different question: what would have to be false for your team to walk away? If nobody can answer that, you don't have an evaluation. You have a mood.

The scenario below is a composite, and every number in it is illustrative. Vendor terms are dated and change. Re-verify them before you spend money or reputation on a decision.

Why "free tokens" is the wrong unit of analysis

Free capacity is real value. It's also a terrible unit for a standardization decision, for three structural reasons.

1. Tokens are an input; work is an outcome. A lane that burns 2M tokens and closes 18 of 20 smoke tasks beats a lane that burns 800K tokens and closes 11. Token counts don't tell you which one you have.
2. A grant is a stock; your workload is a flow. 10 million tokens sounds enormous until you know your team's monthly burn. A stock figure without a burn rate is a number with no denominator.
3. The claim expires; the standard doesn't. Free tiers change. If four engineers have already written their rules files and prompt libraries around a lane, the price of reversal isn't the invoice — it's the rewrite.

That third point is where most teams quietly lose two weeks.

Why this specific lane makes a useful test case

MonkeyCode's operator describes it as an open-source project with free model access and a free server option, and states a free grant of 10 million tokens as of 2026-10-16. Those are operator-supplied claims, not verified benchmarks: no public burn rate, no hardware spec, no permanence guarantee. That isn't a defect of the product — it's the normal state of a zero-price offer. And it's exactly why the offer is a good exercise. When the price is zero, the only variables left to test are the ones that actually decide your outcome.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The artifact: a claim-to-test ledger

Stop writing evaluation docs. Write falsification docs. Every vendor sentence becomes one row with a test, an owner, and an expiry date.

Column	What goes in it
Claim (verbatim)	Quote it. Never paraphrase a promise.
Falsifying test	The cheapest thing that could prove it false this sprint.
Instrument	Dashboard, CI job, task log, or a stopwatch.
Minutes	Real estimated cost of the test.
Pass if	A threshold you commit to before you see the result.
Reverse signal	What failure would change your decision, not just your mood.
Owner	One human, by name.
Expiry	The date the claim must be re-checked.

Define the variables first

• T — number of claims under test
• h — average minutes per falsification test
• F = T × h / 60 — falsification hours
• p — your honest probability of reversing the decision within one quarter
• R — rework hours to undo the decision (rules files, prompt library, eval sets, CI wiring, docs)
• W — loaded hourly cost

Run the ledger when p × R > F. The break-even threshold is p* = F / R.

W cancels out of both sides. That's the useful part: you never have to defend your loaded hourly rate to anyone.

Worked example (illustrative)

A platform team of six evaluates the lane with nine claims. F = 9 × 40 / 60 = 6 hours. They measure R = 60 hours of context rewrites with the shell snippet below rather than guessing. Then p* = 6 / 60 = 0.10.

Translation: if you believe there's more than a 1-in-10 chance you'd reverse this decision inside a quarter, the ledger pays for itself. That is a much easier argument to win than "let's do a proper evaluation."

The ledger, filled in

#	Claim (abbreviated)	Falsifying test	Min	Reverse signal
C1	free grant, operator-stated	run the 20-task smoke set twice; log tokens and tasks closed	45	grant covers < 5 working days at observed burn
C2	free server option	run the smoke set during a real PR window; record wall-clock queueing	45	queueing longer than your review window
C3	open source	clone it, build it, run the smoke set against your own copy	60	build path requires access you don't have
C4	context export	export rules files and prompt library; diff against your repo	30	export is lossy or manual
C5	CI latency	wire one nightly job; compare p95 wall clock to baseline	45	p95 blows the nightly budget
C6	review latency	count human review minutes on 20 lane-authored PRs	30	review minutes exceed authoring savings
C7	data class	ask policy whether your code class may be processed externally	15	policy answer is an absolute no
C8	offboarding	remove one engineer mid-week; confirm access and cost state	30	access or billing state becomes murky
C9	version pinning	pin a known-good configuration; re-run C1 after a restart	30	behavior drifts with no changelog

Note that C7 costs fifteen minutes and can end the entire evaluation. Cheap tests first. Always.

Sensitivity: when the ledger is not worth running

Scenario	T	h	F	p	R	p×R	Verdict
Beachhead: 2 engineers, 1 repo	4	30	2.0	0.15	12	1.8	Skip the ledger — just pilot
Scale-up: 6 engineers, 3 repos	9	40	6.0	0.30	60	18.0	Run it this sprint
Regulated: 40 engineers, 2 BUs	14	60	14.0	0.40	240	96.0	Run it, then gate on C7 alone

Look at row one. p × R = 1.8 beats F = 2.0 — barely. If your blast radius is one repo and two people, the correct decision is to skip the ceremony and use the lane for a week. Ledgers are for decisions that are expensive to reverse, not for curiosity.

Break-even moves fast: at R = 12 hours, p* = 17%. At R = 60, p* = 10%. At R = 240, p* = 6%. The more context you have to rewrite, the lower the bar for testing.

Measure R instead of estimating it

Rework hours are the one number teams routinely invent. Count your context assets first:

# context assets a reversal would force you to rewrite — count, don't guess
rg --files -g 'AGENTS.md' -g '*.mdc' -g 'prompts/**' -g 'evals/**' \
  | xargs -r wc -l | tail -1

Then keep the ledger in a file so it survives the meeting where everyone agrees verbally:

# ledger.yaml — one row per claim you are willing to falsify
# Scaffold only; the operator's stated terms are dated 2026-10-16 and must be re-checked.
decision: standardize-free-lane
owner: platform-lead              # a person, not a team
review_date: 2026-11-13           # claims expire; so does the decision
loaded_hourly_cost: 85
reverse_rework_hours: 60          # measured above, not estimated
claims:
  - id: C1
    claim: "free grant stated by operator (2026-10-16)"
    test: "run the 20-task smoke set twice; log tokens and completed tasks"
    pass_if: ">=18/20 tasks complete, twice"
    reverse_signal: "grant covers < 5 working days at observed burn"
    owner: platform-lead
    expiry: 2026-11-13
  - id: C7
    claim: "we may process this code class externally"
    test: "ask policy; get the answer in writing"
    pass_if: "written yes, with a scope"
    reverse_signal: "any conditional or verbal answer"
    owner: em
    expiry: 2026-11-13

# ledger.py — scaffold I wrote for this article; no tests, only PyYAML required
import sys, yaml, datetime as dt

doc = yaml.safe_load(open(sys.argv[1]))
claims = doc["claims"]
h = sum(c["minutes"] for c in claims) / len(claims)
F = len(claims) * h / 60
p_star = F / doc["reverse_rework_hours"]

print(f"T={len(claims)} h={h:.0f}min F={F:.1f}h break-even p*={p_star:.0%}")
print("run the ledger only if your reversal probability beats that number")

today = dt.date.today()
for c in claims:
    if dt.date.fromisoformat(str(c["expiry"])) < today:
        print(f"EXPIRED {c['id']} — owner {c['owner']}: re-check or drop the standard")

Run that on your own file before your next architecture sync, not after.

Free lane, self-host, or paid seat: fit criteria, not vibes

Criterion	Free hosted lane	Self-host	Paid alternative
Cash price	zero (operator-stated)	infra + ops hours	per seat
Whose machine processes the work	vendor — test C7	yours	vendor
Reversal cost R	context rewrites	near zero if the repo is yours	seat migration + retraining
Ops hours you own	lowest	highest	middle
Failure mode	terms change under you	nobody maintains it	renewal becomes the default

Fit rules I'd actually apply:

• Take the free hosted lane when F < 8 hours, one team, two repos or fewer, and someone owns a recurring re-check. Free buys you falsification time; it doesn't buy you a standard.
• Self-host when the code class can't leave, you already run the ops capacity, and the workload is steady enough to justify it. If self-hosting is a weekend project for one person, you've just created a bus factor.
• Pay per seat when administration, procurement, and offboarding consistency matter more than unit price. That's a governance purchase, not an engineering one.

Hard gates, owner, expiry, exit

• Gate 1 — owner. No named owner for the C1–C3 re-check, no standardization. The ledger decays the moment nobody owns it.
• Gate 2 — spend. No paid commitment before C1, C2, and C7 have a recorded pass or fail.
• Gate 3 — data class. If C7 comes back as an absolute no, this was never a ledger question. It's a stop.
• Exit criteria. At expiry: standardize if 7 or more of 9 claims pass. Extend one cycle if 5–6 pass with a named owner. Stop if fewer than 5 pass, or if C7 fails.

Limitations, and who should skip this

• Every number above is illustrative. A ledger is a conversation tool, not objective truth, and it will not settle a disagreement between people who want different answers.
• Operator-stated terms — free model access, the free server option, the stated free grant, the open-source description — are dated 2026-10-16 and may change. The ledger's value is that it forces you to re-test rather than re-cite.
• It does not price the human cost of a bad lane: review fatigue, morale, the senior engineer who quietly stops reviewing.
• It assumes you can name R with some honesty. If your context assets live in one person's head, measure that problem first.

Skip this approach entirely if you're a solo developer with no shared context to rewrite (just use the thing for a week), if your data policy is already an absolute no, or if you want a benchmark verdict rather than a decision framework. Benchmarks tell you what a lane can do. Ledgers tell you what it would cost to leave.

If you want a lane that's cheap enough to falsify, MonkeyCode's repository is a reasonable place to run C1 and C2 against your own smoke set — the whole exercise costs about forty minutes, and that is the point of a zero-price offer.

One last question, and it's the only one that matters: which single claim in your ledger would flip your decision if it failed — and who is re-checking it on 2026-11-13?