Token Budgets Are Not Task Budgets: A Free-Tier Accounting FAQ

A developer opens a free coding console on a Monday, asks the agent to rename one config key across forty files, and finds the session closed before the last file is touched. Nothing crashed, no model refused, and the tool reported success each turn; the allowance had simply been spent re-reading the same repository over and over. That small scene explains most of the confusion around free tiers, because the quantity being metered is not the work you asked for.

Four claims circulate in issue threads and conference hallways, and each one survives because it is almost true. Below, every claim gets a counter-measurement, a corrected mental model, and a probe you can run against your own tasks. All arithmetic here is labeled arithmetic rather than measurement, and none of it is a vendor benchmark.

Myth 1: "A token quota is a task quota"

This claim treats the allowance like a fuel tank, where one liter of driving consumes one liter whether you idle or accelerate. Agent sessions do not work that way, because the conversation history and any retrieved repository context are typically re-sent with every turn. The multiplier is turns, not tasks, and a task that needs nine corrections can cost an order of magnitude more than the task it was cloned from.

A rough planning formula keeps the shape honest even when the constants are wrong. Expected input is roughly the sum of system prompt, injected context, and task text, multiplied by the number of turns, plus the growing transcript from earlier turns.

expected_input ≈ (system + context + task) × turns + transcript_growth

If your system prompt and pinned context total 6,000 tokens and a mundane rename takes six turns, you have already spent about 36,000 input tokens before writing a single line of code. Sixty tasks of that shape consume well over two million, which is the arithmetic that surprises people who divided a large allowance by an imagined per-task price.

The probe: measure tasks per 100k tokens

Guessing from character counts is unreliable, because tokenizers differ from the ones you test with and providers report usage differently. The honest approach is to record what the tool actually reports and divide by outcomes rather than attempts. The script below wraps any CLI agent invocation that can emit a usage file, then computes successes per 100k tokens so that a chatty run cannot flatter itself with volume.

#!/usr/bin/env python3
"""budget_probe.py: tasks-per-token accounting for any CLI coding agent.

Usage file contract: the wrapped command must write JSON like
{"input_tokens": 61234, "output_tokens": 812}
If it cannot, the run is recorded with zero tokens and marked unusable.
"""
import json, subprocess, time
from dataclasses import dataclass

@dataclass
class Attempt:
    task_id: str
    ok: bool
    seconds: float
    tokens_in: int
    tokens_out: int
    metered: bool


def run_one(task, cmd, usage_path):
    start = time.monotonic()
    proc = subprocess.run(cmd, shell=True, capture_output=True, text=True)
    elapsed = round(time.monotonic() - start, 2)
    usage = {}
    try:
        with open(usage_path) as f:
            usage = json.load(f)
    except FileNotFoundError:
        pass
    # exit code alone is not correctness; task["verify"] is the judge
    verify = subprocess.run(task["verify"], shell=True, capture_output=True)
    return Attempt(
        task_id=task["id"],
        ok=verify.returncode == 0,
        seconds=elapsed,
        tokens_in=int(usage.get("input_tokens", 0)),
        tokens_out=int(usage.get("output_tokens", 0)),
        metered=bool(usage),
    )


def summarize(attempts):
    metered = [a for a in attempts if a.metered]
    total = sum(a.tokens_in + a.tokens_out for a in metered)
    wins = sum(1 for a in metered if a.ok)
    if not total:
        return {"note": "no usage data; fix the usage file before trusting anything"}
    return {
        "tasks": len(metered),
        "successes": wins,
        "tokens_total": total,
        "successes_per_100k": round(wins / total * 100_000, 2),
        "tokens_per_success": round(total / wins, 0) if wins else None,
    }

Run ten to fifteen small tasks from your own repository, each with a machine-checkable verify command, and store the JSON beside the commit hash. The number that matters is successes_per_100k, because it folds correctness, verbosity, and retry cost into one comparable figure. A cheap model that succeeds after four retries is often more expensive than a slower one that succeeds immediately.

Myth 2: "The free server is a free CI runner"

A session box is built for interactive agent loops: you land in it, run a command, inspect the diff, and continue. A CI runner is built for queued, parallel, hermetic jobs that must terminate on their own with artifacts attached. Confusing the two produces the classic complaint that a free environment is useless because it cannot run a forty-job matrix overnight, which is like complaining that a workshop cannot serve as a warehouse.

The operator-provided free server option is genuinely useful for the first role and generally wrong for the second. Use the decision table below as a starting filter, and treat every row as a hypothesis rather than a rule.

Task shape	Where to run	Why
Single-file edit with a fast test	Local shell	Feedback loop measured in seconds
Multi-file refactor needing repo context	Server session	Keeps the laptop cool and the context stable
Nightly matrix across runtimes	Real CI	Queueing, parallelism, and artifact retention
Reproducing a user bug in a clean image	Server session	Disposable environment, pinned toolchain
Publishing signed release artifacts	Real CI with secrets	Audit trail and credential isolation

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode exposes free model access and a free server option, and the allowance advertised at the time of writing is ten million tokens; treat any figure you read here, including that one, as expiring, and confirm the live quota in the console before planning around it.

Myth 3: "A bigger context window produces better patches"

Larger windows raise the ceiling on what can be attended to, not the floor on what gets attended. Past a certain size, unrelated files compete with the one function under repair, and the model's effective attention spreads thinner across a longer field. The practical symptom is a patch that is locally reasonable and globally wrong, such as renaming a symbol consistently in code and inconsistently in tests.

Measure context as a variable rather than a virtue. Run the same task set twice, once with a curated three-file context and once with the whole directory tree pasted in, and compare successes_per_100k from the probe above. If the larger context does not pay for itself, the smaller one is not a compromise but an optimization, and the accounting finally says so out loud.

Myth 4: "Free means disposable, so state does not matter"

Ephemeral environments tempt people into skipping pins, and then the same task passes on Tuesday and fails on Thursday for reasons nobody records. The environment is a variable in the experiment, so pin the toolchain explicitly and print it into the run log alongside your results. Three lines of setup cost less than an afternoon of arguing about a flaky failure.

node --version >> run.log 2>&1
python3 --version >> run.log 2>&1
git rev-parse HEAD >> run.log 2>&1

When a run regresses, you can now ask whether the task changed or the ground moved beneath it. Without that line in the log, every disagreement becomes a matter of memory, and memory loses.

Limitations and who should skip this

The probe is only as good as its verify commands, and exit codes are optimistic witnesses that will happily certify a broken build. Token counts also come from two different counting regimes, so compare runs made on the same tool rather than across vendors. Small samples are noisy, cached dependencies skew timings, and quotas move faster than articles do.

Skip this approach if you need contractual guarantees, if your repository context cannot leave your network, or if your workload is a scheduled batch job that belongs in CI. Skip it too if you cannot write a verify command for your task, because without one you are measuring enthusiasm rather than outcomes.

If you want to try the probe somewhere the meter is already free, the MonkeyCode free model access and free server option make a low-stakes starting point, and fifteen tasks are enough to learn something you can defend in a review.