Dev.to AI 🤖 Ai 👁 0 📖 4 min read

The Re-Read Tax: A One-Hour Spike for Where Your Agent Tokens Actually Go

Your agent budget rarely dies on one giant file. It dies on the same file, read ten times. That is the failure mode worth spiking. Before you wire any free tier into CI, spend one hour testing a single hypothesis about

Your agent budget rarely dies on one giant file. It dies on the same file, read ten times.

That is the failure mode worth spiking. Before you wire any free tier into CI, spend one hour testing a single hypothesis about redundant context.

This is a design for that hour. The code below is illustrative and was not executed for this article. The thresholds are conventions, not measured results.

The hypothesis, written before you run anything

A spike without a falsifiable claim becomes a demo. Write one sentence like this:

In this task, at least 30% of the characters the agent pulls in come from repeated reads of files it already saw.

That sentence gives you three things: a target number, a metric you can compute, and a clean way to be wrong. "The agent felt slow" gives you none of them.

Rule: one hypothesis, one task, one run

Pick a task you already understand. A bug fix with a known cause works well. Do not pick a task where you are also learning the codebase.

What counts as evidence

Collect four artifacts. Nothing else counts as a result.

  1. The raw transcript or tool-call log from the run.
  2. A summary JSON produced by a script, not by you reading logs by eye.
  3. A self-check fixture with a known correct answer.
  4. A timestamped decision line: keep, narrow, or abandon.

Without item 3 you cannot tell a broken parser from a real signal.

The artifact: a log normalizer

Most agent harnesses emit one JSON object per tool call. Format names differ, so adapt the field mapping first.

# read_tax.py — ILLUSTRATIVE, NOT EXECUTED for this article
import json
from collections import Counter, defaultdict

READ_TOOLS = {"read_file", "view", "cat"}

def events(path):
    with open(path) as f:
        for line in f:
            line = line.strip()
            if line:
                yield json.loads(line)

def summarize(rows):
    reads = Counter()
    chars = defaultdict(int)
    for ev in rows:
        if ev.get("type") != "tool_call":
            continue
        if ev.get("name") not in READ_TOOLS:
            continue
        p = (ev.get("args") or {}).get("path")
        if not p:
            continue
        reads[p] += 1
        chars[p] += int(ev.get("result_chars") or 0)

    total = sum(chars.values())
    repeated = sum(chars[p] * (n - 1) / n for p, n in reads.items())
    return {
        "reads": dict(reads),
        "total_chars": total,
        "repeated_chars": round(repeated),
        "repeat_share": round(repeated / total, 3) if total else 0.0,
    }

if __name__ == "__main__":
    import sys
    print(json.dumps(summarize(events(sys.argv[1])), indent=2))

The math is simple. Each path's characters are split evenly across its reads. Repeats are everything after the first read.

Self-check before you trust the number

Build a two-line fixture where the answer is known by hand.

{"type":"tool_call","name":"read_file","args":{"path":"a.py"},"result_chars":400}
{"type":"tool_call","name":"read_file","args":{"path":"a.py"},"result_chars":400}

Two reads, 400 characters each. Total is 800, repeated is 400, share is 0.5. If your script prints anything else, fix the script before running the real task.

python3 read_tax.py fixture.jsonl    # expect "repeat_share": 0.5

The timebox

Minutes Action
0–10 Write the hypothesis and the fixture
10–15 Choose the task and freeze its inputs
15–40 Run the agent with tool logging on
40–50 Self-check the script, then summarize the real log
50–60 Write the decision line and stop

At minute 60 you stop, even mid-run. A spike that overruns stops being a spike.

Reading the result

Sample thresholds only. Calibrate them against your own logs.

repeat_share Reading Next step
under 0.15 Context is mostly fresh Move on; the tier is not your bottleneck
0.15–0.40 Some redundancy Narrow the task or cache file digests
over 0.40 Re-read tax dominates Restructure the task before scaling the tier

If the share is high, the fix is rarely "a bigger budget". The fix is a narrower working set.

  • Replace re-reads with a short summary the agent keeps.
  • Split the task so each run touches fewer files.
  • Prefer search over full-file dumps for orientation.

Where a free tier fits

This is where MonkeyCode enters the picture, and only as the thing under test. Two operator-supplied levers matter for a spike: free model access, and a free server option.

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

The operator states a free token allowance. Confirm the current figure and terms on the project page yourself, because quotas and availability change. Do not plan a pipeline around a number you read in a post.

Why the two levers help here: you can rerun the same fixture without metering every call, and the free server option keeps the run off your laptop so the environment is reproducible. Reproducibility is the point, not the discount.

Keep the tier out of the equation

Use the same task, the same fixture, and the same script on every run. If you change models mid-spike, you measured nothing.

One soft ask: if you try the flow, run the fixture first and only then the real task. The fixture is where you find out whether your log parser is lying.

Limitations and who should skip this

Be honest about what one hour buys you.

  • One run is not evidence of a trend. It is a signal worth a second run.
  • result_chars is not tokens. Character-to-token ratios vary by model and content.
  • Client-side caching can hide re-reads from your log entirely.
  • Log schemas differ per harness, so the field mapping is yours to verify.
  • Tool output size is not the same as context window pressure.

Skip this spike if your task already fits in a single small file. Skip it if you cannot get a raw tool log — the metric depends on it. Skip it if you need a performance number to justify a purchase; this measures context shape, not speed.

The one-line takeaway

Write the hypothesis first. Build the fixture second. Trust the parser only after the fixture passes.

If your repeat share is high, fix the working set before you touch the budget.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.