I built a Telegram-native AI agent on free-tier infra — here's the stack and what broke

Basavaraj Patil — Thu, 09 Jul 2026 20:30:00 +0000

I'm Basavaraj Patil (Basavaraj_nick), a self-taught dev and CS diploma student, and I built a Telegram-native multi-agent AI system entirely on free-tier infrastructure — no server bills, no paid APIs. Here's how it works, and what broke along the way.

What it does

It's not a chatbot. It's a full agent system that lives inside Telegram — 14+ commands, 8 autonomous sub-agents running on schedules, image generation, web research, and memory that persists across conversations. All of it running on free tiers.

The stack

Cloudflare Workers — two workers (github-backend + image-api) handle routing and image requests
GitHub Actions — 8 sub-agents run on cron schedules throughout the day (IST)
Telegram Bot API — the entire interface; no web dashboard needed
Cloudflare D1 — logs commands and stats to a dashboard
Cloudflare KV — a 5-minute rolling memory window so the agent has short-term conversational context
LLM chain: Mistral → Cerebras → Groq → OpenRouter → Gemini, falling back in that order so a single provider's rate limit never takes the whole thing down
Image gen: FLUX 1 Schnell as primary, Pollinations AI as fallback
Image editing: Stable Diffusion v1.5 img2img for the /edit command
Web research: Tavily + Jina for live search grounding

Why Telegram, not a web app

Every other agent framework I looked at assumed you'd build a dashboard. I didn't want to maintain a frontend, an auth flow, and a backend just to send myself a daily briefing. Telegram already solved auth, mobile notifications, and UI. The bot is the UI.

What actually broke

A few patterns that cost real debugging time, in case they save you some:

Return-type mismatches across agents — when 8 sub-agents pass data between each other, one agent returning a slightly different shape than the next one expects fails silently until something downstream breaks.
GitHub Actions permissions on workflow files — Actions can't modify other workflow files by default; needed explicit permissions.
KV memory misconfiguration — early versions stored memory in a public repo memory.json, which is a bad idea for anything with even mildly sensitive context. Moved it to private Cloudflare KV.
RLS conflicts — wherever a database enforces row-level security, make sure your service role key is actually bypassing it where intended, or reads silently return empty sets.

Where it stands now

The repo is public and secrets-clean — full README with the architecture, a competitor comparison, and the env var table if you want to run your own version.

Repo: github.com/basavarajpatil660/Ultimate-Ai
More of what I'm building: basavaraj.dev
Project page: basavaraj.dev/projects/ultimate-ai-agent

If you're building something similar or want to talk architecture, find me at @basavaraj_nick or drop a comment below.

How I built a production AI agent system on zero budget (and what free tiers actually break first)

Basavaraj Patil — Wed, 08 Jul 2026 23:04:17 +0000

I'm a CS diploma student, and a few months back I set myself a constraint: build a real, always-on AI system, and don't spend a single rupee on infrastructure. No paid APIs, no paid hosting, nothing.
What came out of it is Ultimate AI Agent — a multi-agent system that runs entirely through Telegram. No web dashboard needed day to day, you just chat with it.
Here's what it does, and more importantly, what I learned about where free tiers actually break.
The setup
Everything lives on Cloudflare Workers, with GitHub Actions handling anything that needs to run on a schedule. The bot has 14+ commands and actually remembers recent conversation context — most toy Telegram bots don't bother with that part, but it's what makes it feel like an assistant instead of a command parser.

It can generate images (FLUX as the primary model, with a fallback so it doesn't just die when FLUX is rate-limited), pull in live web research through Tavily and Jina, and runs 8 sub-agents on autopilot — a daily AI/tech news briefing, a YouTube trend report, that kind of thing.

The thing nobody warns you about: rate limits, not compute
Going in, I assumed compute or request limits would be the wall I'd hit. They weren't.

The real bottleneck on free tiers is almost always LLM API rate limits — you get maybe a few hundred requests a day per provider before you're throttled, and that adds up fast if the bot is chatty.
The fix that actually worked: chain multiple providers instead of relying on one.
Cerebras → Groq → Mistral → OpenRouter → Gemini
If the first provider is rate-limited or errors out, the request just falls through to the next one. It's a simple try/catch chain, nothing fancy, but it's the single biggest reason this thing stays up 24/7 without me babysitting it.

Cloudflare KV + D1 cover more than you'd think
I expected to need a "real" database pretty quickly. Turns out Cloudflare KV (for fast key-value memory, like recent conversation context) plus D1 (for structured stuff — commands, logs, automation runs) covers almost everything a small-to-medium bot needs, as long as you're deliberate about what goes where. KV for anything read-heavy and short-lived, D1 for anything you actually want to query later.

GitHub Actions as a free cron service
This one felt like cheating a little. Instead of paying for a server to run scheduled jobs, GitHub Actions cron triggers handle all 8 sub-agents — news briefings, trend reports, whatever needs to run daily. It's not built for this, but it works, and it's free.

What I'd tell someone trying this
Design for provider failure from day one. Don't build around one LLM API and add fallback later — build the chain first.
Separate your memory into "needs to be fast" (KV) vs "needs to be queryable" (D1) early, or you'll end up refactoring.
Free tiers are genuinely enough for a real, working product — the constraint pushes you toward better architecture, not worse.

If you want to see the code, it's open: github.com/basavarajpatil660/Ultimate-Ai
More of what I'm building: basavaraj.dev