the reality of economics

What does it actually cost to run this?

Numbers a builder cares about: the monthly bill to clear captchas, whether the free Gemini key is enough, and the machine you'd need to pull 3,000 products a day over Tor. Cost figures are live from the leaderboard (real bench tokens × real OpenRouter prices).

1 · The captcha bill is rounding error

The solver only runs when a captcha appears, and captchas are rare (measured ~0.8% of exits). So the monthly cost = $/1k-solves × captcha-rate × scrapes. We show a band: 0.8% measured16.5% worst-case (the early small-sample pilot, kept as a pessimistic bound).

model / combosolved$/1k solves $/mo @ 0.8%$/mo @ 16.5%
loading…

Assumes 3,000 scrapes/day, every day (×30). $/mo = $/1k-solves × rate × 90  (90 = 3k/day ÷ 1k × 30 days). A ~ on a price means the unit price is an estimate, not a model we run in production.

2 · "Isn't the free Gemini key enough?"

Short answer: not on its own. Two separate things get called "Gemini":

Free Gemini key FREE

Google's free tier — what GEMINI_API_KEY uses. Serves only gemini-2.5-flash (~500/day) and 2.5-flash-lite (~1,000/day).

Problem 1: those models are weak on this puzzle — 32% / 30% solved vs 90%+ for the paid Gemini-3 tier.

Problem 2: the daily quota (~500–1,500 solves) sits right at our captcha volume, so a busy day exhausts it and the scraper stalls.

Paid via OpenRouter $$

The strong models — gemini-3-flash, 3.1-flash-lite, qwen3-vl-32b — only exist on the paid tier, billed through OpenRouter. That's what every combo on the board uses.

But "paid" here is cents/month (section 1). So the honest setup is: free key as a first try, paid OpenRouter as the fallback when the puzzle is hard or the quota's gone — which is exactly what production runs.

We did not ship two separate builds — one solver picks the provider per call. The free key is tried first where it's viable; OpenRouter catches the rest for a few cents.

3 · The machine, and time, to do 3k/day over Tor

Throughput is measured at ~600 product fetches/hour per arm (555–731 across the study + shootout). An "arm" = one headed Chrome + its own Tor exit. You scale by adding arms — mostly for exit diversity (more distinct IPs in rotation), not because Tor is slow.

parallel armsthroughputtime for 3,000RAM (Chrome+Tor)CPU
1~600/hr~5 h~0.45 GB~1 core
3~1,800/hr~1.7 h~1.3 GB~2–3 cores
6~3,600/hr~50 min~2.6 GB~4–6 cores
9~5,400/hr~33 min~3.9 GB~6–9 cores
Double-check these for your setup. RAM/throughput were measured on an Apple-Silicon Mac with patchright + a 1.5–4.5 s/fetch human pace; headed-Chrome memory and Tor exit availability vary by machine, OS, and the day. Prices are OpenRouter list (Jun 2026) and move. Treat the tables as order-of-magnitude, not a quote — re-measure on your target hardware before committing capacity.

4 · Things we tried and dropped