# Building a Telegram AI assistant with a multi-LLM fallback chain > Source: > Published: 2026-08-18 09:30:23+00:00 I'm not a professional developer — my background is in banking, food production, and now construction — but I've spent the last few weeks building Jimi, a personal AI assistant that lives inside Telegram. Wanted to share some of the architecture decisions, since a few things surprised me along the way. Telegram is just the client. All the actual logic — intent parsing, memory, tool calls, voice — lives in a FastAPI backend, completely decoupled from the messaging layer. The idea was to avoid locking myself into Telegram forever; if I ever want a web client or a different messaging platform, the core doesn't need to change. Jimi's primary brain is OpenAI (gpt-4o-mini for cost reasons), but I built a fallback chain to Gemini and DeepSeek in case of rate limits or outages. This turned out to be more important than I expected — even a short outage on one provider used to mean the whole assistant went silent. Now it just quietly falls back. I assumed text tokens would be my main cost driver. They're not even close. Once I actually modeled the unit economics, voice (transcription + TTS) turned out to be roughly 20-25x more expensive per interaction than text — mostly because of TTS on every response, not the transcription itself. That completely changed my monetization plan: text stays free, voice becomes the premium feature. Working on persistent memory (so Jimi actually remembers preferences, not just events) and eventually expanding beyond chat into things like calendar and email actions. Curious if others here have dealt with similar cost surprises when adding voice/audio to an LLM-based product — would love to hear how you approached it.