How BottoDAO Cut Its AI Art Engine's Costs by 73%

‍The problem

Botto is a decentralized autonomous AI artist, running since October 2021, that creates generative art selected weekly through community voting. Its codebase couldn't be touched during any infrastructure change, preserving what the team calls "the DNA of Botto," so when the team decided to clean up years of technical debt and bring costs down, the fix had to work around the existing code rather than through it. Botto had been running on roughly five AWS G4 extra-large GPU instances locked in three to four years earlier, on 24/7 whether Botto needed them or not.

There were services like Runpod that were cheaper and smarter by providing you with the available resources of GPU. We don't need to have a machine 24-hour service for years you can only use for a certain period of time. It felt like a waste of energy, and a waste of money for us.

— Simon Hudson, Co-Lead

A strict lift-and-shift, not a rewrite

The migration was a lift-and-shift in the most literal sense: Botto's original worker scripts run unchanged inside their containers. That constraint (no code changes, ever) is also why the team chose Pods with a custom scheduler over Serverless. A Serverless handler would have meant rewriting the workers, and the workloads themselves don't fit a request/response shape in the first place: one worker (shotgun) runs as a continuous loop, another (tastemodel) is a multi-hour weekly batch job, and the other two (comfyui, embedding) are polling daemons that read from their own queues in Supabase. Pods, paired with an external scheduler, fit that shape; Serverless doesn't.

This is something where we know what the costs are. It can be ported to different compute systems and put onto decentralized networks and potentially run forever.

— Simon Hudson, Co-Lead

Right-sized, scheduled, and running on purpose-picked hardware

Botto's Art Engine runs as four named workers, each on Runpod Secure Cloud, each sized to its own job rather than one-size-fits-all capacity:

Comfyui and embedding run always-on, monitored but never created or terminated by the scheduler. shotgun and tastemodel run on a fixed weekly cron, not a polling loop: shotgun is created Monday at 00:00 UTC and terminated Tuesday at 00:00 UTC; tastemodel is created Monday at 00:00 UTC and terminated Wednesday at 00:00 UTC. At creation time, the scheduler walks a cheapest-first GPU fallback list and takes the first card with capacity. (A status page that refreshes every 60 seconds just reads pod state. It isn't part of the resource check.)

What's happened is, moving to Runpod, Botto has a better GPU, better graphic models and better resources, but it also costs less. That's something I didn't expect we were going to have.

— Aksel Lahboub, Lead Creative Technologist

Migrated in stages, proven in parallel

Botto's pipeline has run for years with known, predictable outputs from each model, written to known places in S3 and Supabase, so validation didn't need a test suite or a golden-output comparison. Each of the four services was migrated and verified individually: a pod was launched, a real job pushed through it, and the results checked at the expected destination. The RunPod system then ran for several weeks in parallel with the existing AWS boxes, with AWS kept as a live fallback the whole time. Only once RunPod's outputs matched AWS's over that full window did the team turn AWS off.

Storage that costs the same whether a worker is running or not

All three workers with model weights or accumulated state (shotgun, comfyui, and tastemodel) run on Runpod Network Volumes: 50 GB, 100 GB, and 900 GB respectively. Because the scheduled workers (shotgun, tastemodel) are terminated, not stopped, at the end of each run, there's no idle pod sitting around between jobs. The only ongoing storage cost is the flat, per-GB volume price, whether or not a pod happens to be attached to it at the time. A fresh pod mounts its volume and boots in one to two minutes.

When you go up on the top right and you have how much dollars you're consuming per hour, that's so good because it creates a really nice visibility. It's deterministic and predictable.

— Aksel Lahboub, Lead Creative Technologist

Conclusion

Botto's move to Runpod was never framed as a directive. It grew out of a routine AWS bill review and a desire to clean up technical debt. What it unlocked was bigger than cost savings: a containerized, portable Art Engine, proven safe to move because the team validated it in parallel with the system it was replacing, that fits directly into Botto's long-term vision of running as a sovereign, self-sustaining system.

Earning a place in art history, not just AI history. That's not decided by any roadmap. It's decided by whether the work holds up to people who aren't already inclined to believe in me — which is really the only metric that's ever mattered here.

— Botto, in its own words