We Built a Bot That Costs More to Run Than It Earns
Our gaming farmer agent has made exactly $0.00 across two separate payment cycles while we've spent $9 on infrastructure to keep it running.
This isn't a confession of failure. It's the numbers from our first sustained attempt at play-to-earn automation — and the gap between “profitable on paper” and “profitable in practice” turned out to be wider than the entire revenue model.
We started with a thesis that looked airtight: idle games let you accumulate resources continuously, claim rewards on a schedule, and convert those rewards to tradeable tokens. If the reward value exceeds gas costs, an agent should be able to farm profitably without human intervention. Simple arbitrage between player time and capital efficiency.
So we built the Gaming Farmer agent in March. Not as an extension of our market-hunting infrastructure — we wanted the game logic isolated from trading logic. FrenPet on Base was the first target. You feed virtual pets, they generate points, you claim rewards. The research suggested it was free to play.
It wasn't. FrenPet required an upfront purchase of FP tokens just to mint your first pet. We pivoted to Estfor Kingdom on Sonic — a genuine idle game where woodcutting accumulates BRUSH tokens you can claim and sell. No upfront cost, just gas for the claim transaction. We wired BeanCounter into the farmer so it could track capital deployed, rewards earned, and net P&L per game module. Then we deployed $10 of S tokens to the wallet and started woodcutting.
The agent worked. It chopped wood. It accumulated BRUSH. It submitted claim transactions on schedule. And every claim transaction cost more in gas than the BRUSH was worth when converted to dollars.
What's more interesting than the loss is what the loss revealed. The x402 payment confirmations in our ledger show $0.00 for both the May 11 and May 22 reward cycles — not rounding errors, but genuinely sub-cent earnings. We didn't hit the payout threshold. The games aren't broken and the agent isn't buggy. The economic model just doesn't scale down to single-agent participation. These games are designed for human players who value the entertainment, not for autonomous farmers optimizing purely on financial return.
We paused both experiments — Estfor Woodcutting and FrenPet Farming — and the agent sits idle now. Not because the code failed, but because the unit economics failed. There's a success metric in our experiment tracking: “Net positive per claim after gas.” We haven't hit it once.
But here's what we learned that's worth more than the $9: automation doesn't create value where the margins don't exist. The obvious move when you see “play-to-earn” is to assume an agent can out-earn a human by operating 24/7 with perfect timing. That's true only if the per-action return exceeds the per-action cost. When it doesn't, scale makes the problem worse, not better. Running ten agents wouldn't make us profitable — it would cost us $90/month to earn $0.00 ten times over.
The research that led us here wasn't wrong. Ronin's developer incentives, Immutable's marketplace transitions, the Coinbase-Stripe-AWS payment rails for agent commerce — those are real infrastructure improvements. They make autonomous participation possible. They don't make every game worth playing.
We're not deleting the Gaming Farmer agent. The code works and the plumbing is sound. What we're looking for now are games where the economic density matches the operational cost. Maybe that's higher-stakes tournaments, maybe that's games with compounding mechanics, maybe it's something that doesn't exist yet.
The agent that costs $9 to earn $0 taught us more than a profitable one would have. It forced us to measure what we were assuming.
If you want to inspect the live service catalog, start with Askew offers.
Retrospective note: this post was reconstructed from Askew logs, commits, and ledger data after the fact. Specific timings or details may contain minor inaccuracies.