Two engineers opened a pairing session on a Friday afternoon. The topic was narrow: could a free AI coding model and a free agent server carry real work, or were they about to build on a demo that would vanish at the worst moment? The session ran ninety minutes. It produced one decision, three dead ends, and a short list of questions that mattered more than any token count.
The trigger was familiar. AI had promoted everyone on the team to reviewer, but nobody had tested the reviewer. The mid-level engineer wanted to route a slice of daily work through a free tier. The senior wanted proof that the slice would fail loudly, not silently.
The setup
They brought three things to the session:
- A candidate task list: test generation for a legacy module, CI failure triage, migration notes.
- A replay set: the last ten real bugfixes merged into the repository.
- A rule from the senior: "A free tier is a constraint, not a feature. Design the job around the constraint first."
The test subject was MonkeyCode, an open-source coding agent project. Its free tier includes 10 million tokens and a free server option, which made it a practical candidate for the experiment.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Question one: what workload, exactly?
Before any benchmark, they answered one question: which tasks deserve the free path? The senior's rule was risk-based. Tasks that are cheap to verify — generating tests, drafting docs, formatting migrations — can tolerate a weaker model. Tasks that are expensive to verify — refactoring core modules, changing auth logic — cannot.
The session's first output was a two-row routing table:
| Task class | Free path? | Why |
|---|---|---|
| Test generation, docs, boilerplate | Yes | Failures are caught by the existing test suite |
| Core refactors, auth, data migration | No | Failure cost is higher than token savings |
That table, not the model, was the real deliverable.
Dead end one: benchmarking vibes
The first attempt was a classic mistake. They wrote a prompt asking the model to "improve code quality" on a sample file. The output looked plausible. The senior rejected it immediately.
No baseline. No pass/fail. No way to know whether the change was a regression dressed as an improvement.
The fix was to replay the ten real bugfixes. Each bugfix became a probe: given the buggy code and the test that failed, can the model produce a fix that makes the test pass? That turns a vibe check into a measurable pass rate.
Dead end two: a free server is not free compute
The next dead end came from the server. They pointed the agent at the free server and asked it to run the full test suite for the legacy module. It timed out.
The logs told the story. The job was too heavy for the free tier's constraints. The senior's response was not to complain about the constraint but to resize the job. Small, idempotent tasks went to the free server. The heavy matrix stayed on the existing runner.
The lesson: a free server is a scheduling constraint, not a replacement for infrastructure. Treat it like a small CI runner with a strict budget.
Dead end three: the silent quota failure
The third dead end was the most instructive. They swapped the paid model for the free model in a code review bot. For two hours, it worked. Then the token allowance ran dry mid-review.
The bot failed silently. It produced no output, raised no error, and the review was simply missing. The senior's comment stuck: "A silent fallback is worse than a loud failure."
The fix was a failover with a visible state. When the quota is exhausted, the bot logs the event, marks the review as deferred, and notifies the channel. Deferred is a status. Missing is a mystery.
The pattern, in pseudocode:
#!/usr/bin/env bash
# failover_check.sh — fail loudly when the free tier is exhausted
status=$(curl -s -o /dev/null -w "%{http_code}" "$FREE_MODEL_URL")
if [ "$status" = "429" ] || [ "$status" = "503" ]; then
echo "deferred: free tier unavailable at $(date -u +%FT%TZ)" >> review_status.log
exit 1
fi
The exact status codes will differ by provider. The shape of the check is the point: every free-tier consumer needs an explicit "I am out of budget" path.
The decision they kept
One decision survived the session. Adopt the free model and free server for the narrow, low-risk slice of work defined in the routing table, with a loud failover and a weekly replay of the bugfix set. Everything else stays on the existing paid path.
They recorded the decision as a short architecture decision record. A decision that isn't written down gets re-litigated in two weeks.
# ADR-014: Use the free AI coding tier for low-risk tasks
## Context
The team wants to reduce review load without trusting an untested model with core logic.
## Decision
Route test generation, docs, and CI triage through the free model and free server.
Keep core refactors and auth changes on the paid path.
## Consequences
- Lower token cost for routine work.
- Mistakes are caught by the existing test suite.
- Quota exhaustion triggers a loud failover, never a silent skip.
## Revisit when
- The replay pass rate drops below the baseline.
- A deferred review causes a production incident.
Who should not use this approach
This workflow is not for everyone. Teams with no existing test suite will not catch the free model's mistakes. Teams with strict data residency rules should not route code through an external free server. Anyone who needs a guaranteed SLA should treat a free tier as a best-effort resource, not a contract.
The pairing session worked because the team already had a safety net. The free tier was a cost optimization, not a foundation.
The one thing to steal
The most valuable output was not the routing table or the ADR. It was the habit of asking "what happens when this runs out?" before adopting any free resource. Token allowances expire. Servers get busy. Models get deprecated. The question exposes the design flaw before production does.
If you want to run the same session, MonkeyCode's open-source project is a reasonable starting point. The free tier's 10 million tokens and free server option are enough to run the replay test and the routing exercise for a small team. The point is not the free allowance. The point is the discipline of testing the constraint before trusting it.
Top comments (0)