I'm “infra-curious” but not an engineer. I can hold my own in conversations about cloud services and workflow automation, but I don't write Go, Python, or Rust.
That tension is how awesome-alt-clouds went from a tidy GitHub README to a multi-week odyssey involving batch schedulers, token budgets, GitHub Actions failures, and a humbling education in reading the documentation first. 😂
The Project
At Datum, we've been quietly curating a list of alternative cloud providers since 2024. The premise is simple: providers that meet four criteria:
- Transparent public pricing — if I can't see a price, you're out
- Self-service signup — no sales calls required
- A status page or SLA — some evidence of production readiness
- Usage-based billing — pay for what you use
As the list grew, a static README wasn't enough. It needed to be browsable, contributable, and maintainable by people who'd never opened a pull request. So we built alt-cloud.org: a GitHub Pages frontend with badge scores, a public submission form, an evaluation pipeline, and the README kept as the single source of truth. Nothing complicated, just a markdown file with 🟢🟡 circle emoji badges that everything else reads from.
Contained and reasonable. But then I added: "Can you also automatically discover new services every week?"
Choosing a Model
There was no deliberate model selection. I was already on Claude Pro, the scope kept expanding, and I'd accidentally committed to building a full automation system before I noticed.
Early work felt effortless — sketching evaluation logic, generating frontend HTML, thinking through data models. The model question only got real during the automated discovery phase. Claude's built-in web search seemed purpose-built for the job: search weekly, evaluate against criteria, update the list, repeat.
That was the theory.
When debugging got serious — real files, real JavaScript errors, real server logs — I switched to Claude Code, the CLI tool that runs inside your repository. That switch should have happened much earlier. The feedback loop is completely different when the model can run a local server, read the console, and fix the file directly. My advice now: sketch in chat, build in Claude Code.
Rate limits, e.g. “read the docs” first!
Each web search through the Anthropic API consumed 15,000–20,000 tokens. My tier's rate limit: 30,000 tokens per minute. The list had 15 categories. The math doesn't work.
Attempt 1: One weekly workflow. All 15 categories. Run every Monday. Failed on category three. Every. Single. Time. The GitHub Actions log was unambiguous:
🔍 Searching Unikernels & WebAssembly...⚠️ Rate limit hit, waiting 30 seconds...❌ Retry failed: Error code: 429 - This request would exceed the rate limit for your organization of 30,000 input tokens per minute.Attempt 2: Add 20-second delays between each category. Progress! It now failed on category six or seven, which was technically an improvement, but still not useful.
Attempt 3: Increase delays to 30 seconds. Same result, slightly later in the run.
Attempt 4: Split 15 categories into three batches of five, running Monday, Wednesday, and Friday. Three separate GitHub Actions workflows. Each with its own cron schedule. This was architecturally the most sensible thing I tried, but it was also the most effort spent on something that still didn't work.
The web search operations were consuming tokens faster than the rate limit window could reset, and there was no reliable way to predict whether a given run would complete or crash halfway. On a good day, the output looked like this:
🔍 Searching Customer, Marketing and eCommerce Clouds...✅ Found 0 candidates⏱️ Rate limiting: waiting 20 seconds...🔍 Searching Blockchain Clouds...✅ Found 0 candidates⏱️ Rate limiting: waiting 20 seconds...🔍 Searching Unikernels & WebAssembly...⚠️ Rate limit hit for Unikernels & WebAssembly, waiting 30 seconds..❌ Retry failed: Error code: 429Even on successful runs, the output was zero candidates worth adding. The system was functioning as designed; it just wasn't useful. The $5 in API credits evaporated repeatedly, and I had a well-documented set of failures to show for it.
The pivot, in retrospect, was obvious. Discovery was never the problem — people find interesting cloud services through Slack, Discord, HackerNews. The tedious part is verifying them against specific criteria. So I flipped the approach: let people submit candidates through a form, let Claude evaluate them, let a maintainer approve or reject.
What Followed
Once the form went live, the list grew organically, as did feedback from users. We responded!
- We added batch submissions so users could add up to five URLs at once
- We create an admin override for Cloudflare-blocked sites that couldn't be auto-evaluated
- We fixed small bugs, like
/approvetriggering onapprovewithout the slash - We added a “PR-to-issue” auto-close
- We added open graph images, brand guidelines, a favicon, and sorting
Each fix revealed the next thing. Vibe coding's natural rhythm?
What It Cost
Across four Claude Code sessions and dozens of subagent calls, the actual token usage broke down like this:
| Tokens | Estimated cost | |
| Input tokens | 5,706 | $0.02 |
| Output tokens | 4,539 | $0.07 |
| Cache read tokens | 40,836,921 | $12.25 |
| Cache write tokens | 2,597,609 | $9.74 |
| Claude Pro subscription | — | $20.00/mo |
| Total | ~43.4M tokens | ~$42 |
That’s 40 million tokens for roughly $42 all-in for the month. Without Claude Code's prompt caching (which re-uses context across turns instead of retransmitting the entire conversation each time) the same work would have cost an estimated $122 in API costs alone.
What I'd Do Differently
Do the math before writing code. The entire batch-splitting architecture existed to work around a constraint I could have caught in five minutes. Two searches per minute maximum, fifteen categories was never going to work. My hint: read the rate limit docs first.
Move to Claude Code sooner. Browser chat is right for architecture discussions and initial scaffolding. It's the wrong tool the moment you're debugging something that needs to run.
Validate the core assumption. We built rate-limit mitigation before confirming automated search was surfacing anything useful. It wasn't. A quick test of the premise would have saved time.
One source of truth from the start. We eventually landed on the README as canonical. We should have started there.
The project works. The frontend is live, 381 services are browsable with scores, and the submission-and-approval workflow gives maintainers final say. It's not the autonomous discovery system I originally imagined, but it is far simpler, and more useful for it.