The swap everyone makes
You have a paid endpoint and a bill you dislike. A free endpoint appears. You change one line, and the invoice drops to zero. So why does the work feel slower two weeks later?
That is the myth I keep meeting. Free model access moves the bill. It rarely deletes it.
Free model access and a free server option are the two availability claims behind this post. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I will not quote quotas, hardware, or latency numbers I have not verified. You measure your own.
Myth 1: Free means the cost is zero
The invoice is zero. The cost moved somewhere else.
- Attempt cost. Every retry is another request.
- Wall-clock cost. A queue you wait in is still time spent.
- Human cost. Someone re-runs the job at 2am.
- Opportunity cost. You stop tuning because "it's free anyway."
Add those four lines and the endpoint stops looking free. It is cheap in dollars and expensive in attempts. Do you know your attempts per successful task today?
Myth 2: It is the same model, only cheaper
This one bites hardest. The same family name is not the same serving path.
Rate limits and timeouts can differ per deployment. So can context handling and truncation behavior. A familiar model name tells you nothing about the endpoint behind it.
Do not assume parity. Probe it. Send one fixed prompt many times. Record latency, output length, and whether the answer is usable.
If output length shrinks across a long run, that is a serving difference. It is not a bad afternoon. Corrected model: treat a free endpoint as a different deployment, not a discount on the same one.
Myth 3: It is free, so fan it out
Fan-out multiplies attempts, not just traffic. Ten parallel CI jobs become one queue.
Queues become timeouts. Timeouts become retries. Retries become duplicate work. Now the free pipeline is slower than the paid one it replaced.
My rule is blunt. Fan-out is real when attempts per success stays near one. Above that, your parallelism is fake. You are only moving load around.
Myth 4: A free server means I can skip setup scripts
No. It means setup has to be scripted, because yesterday's state may not exist.
If your runbook lives in your head, a fresh box will expose it. That is not a free-tier problem. That is a reproducibility problem you were hiding.
Corrected model: free compute rewards scripts and punishes memory.
Build a 40-line attempt ledger
Here is the artifact. It wraps any OpenAI-compatible endpoint. It logs every attempt as JSONL, so you can count real work units.
Save it as attempt-ledger.sh. Set ENDPOINT, MODEL, and TASKS before running. Three attempts per task is the retry ceiling.
#!/usr/bin/env bash
# attempt-ledger.sh - log every attempt, not just the happy path.
set -uo pipefail
ENDPOINT="${ENDPOINT:?set ENDPOINT to your base URL}"
MODEL="${MODEL:?set MODEL}"
TASKS="${TASKS:-20}"
LEDGER="${LEDGER:-attempts.jsonl}"
: > "$LEDGER"
for i in $(seq 1 "$TASKS"); do
attempt=0
ok=0
while [ "$attempt" -lt 3 ] && [ "$ok" -eq 0 ]; do
attempt=$((attempt + 1))
start=$(date +%s%3N)
code=$(curl -s -o /tmp/ledger_out.json -w '%{http_code}' \
-X POST "$ENDPOINT/chat/completions" \
-H 'Content-Type: application/json' \
-d "{\"model\":\"$MODEL\",\"messages\":[{\"role\":\"user\",\"content\":\"Reply with the single word: ok\"}]}")
end=$(date +%s%3N)
[ "$code" = "200" ] && ok=1
printf '{"task":%d,"attempt":%d,"http":%s,"ms":%d,"ok":%d}\n' \
"$i" "$attempt" "$code" "$((end - start))" "$ok" >> "$LEDGER"
done
done
echo "wrote $LEDGER"
Now summarize it. This jq program prints the numbers worth arguing about.
jq -s '
def p(q): (map(.ms) | sort) as $s | $s[((($s | length) - 1) * q) | floor];
([.[] | select(.ok == 1)] | length) as $ok |
{
logical_tasks: ([.[].task] | unique | length),
total_attempts: length,
successes: $ok,
attempts_per_success: (if $ok == 0 then null else (length / $ok) end),
p50_ms: p(0.50),
p95_ms: p(0.95)
}
' attempts.jsonl
What follows is an illustrative shape only. These are not measured numbers from any product. Your run will differ.
{"logical_tasks":20,"total_attempts":27,"successes":20,"attempts_per_success":1.35,"p50_ms":1180,"p95_ms":4300}
How to read those numbers
- attempts_per_success = 1.0? The endpoint behaves like a paid one for this workload.
- 1.0 to 1.5? Acceptable for offline batch work.
- Above 1.5? You are paying in time. Fix payload size or concurrency.
- successes = 0? Stop. That is a configuration bug, not a free-tier bug.
A decision table keeps the switch honest.
| Workload | Retry budget | Gate before switching | Verdict |
|---|---|---|---|
| Interactive chat, human waiting | 1, manual | p95 under your patience | Free access is fine |
| Offline batch, idempotent tasks | 3 | attempts/success at or under 1.5 | Free access is fine |
| CI on every push, wide fan-out | 0-1 | queue time unknown, so measure | Measure first |
| Anything paged at 3am | 0 without alerting | failure alerts exist | Do not run free-only |
| Long stateful jobs | n/a | state survives a restart? | No |
What the ledger cannot see
Honesty matters more than a clean table.
- It does not measure answer quality. Read some outputs yourself.
- It does not measure your own re-run time. Add a column if you want it.
- It does not prove persistence. A server that lived yesterday may not live tomorrow.
- It does not tell you where your data goes. Ask before sending sensitive prompts.
Who should skip this approach
- Teams with data-residency constraints they cannot verify.
- Products with hard latency budgets and no fallback path.
- Jobs that keep state in memory or on local disk between runs.
- Teams that will not read a ledger file. The number is the whole point.
The corrected mental model is simple. Free model access trades dollars for attempts, queues, and attention. Free servers trade permanence for setup discipline. Neither is a discount on a system you refused to measure. If you run this ledger against MonkeyCode's free model access, tell me your attempts-per-success. That is the only comparison worth making.
Top comments (0)