How to Connect an LLM API to a Telegram Bot on a VPS
Not long ago, a Telegram bot could only reply with scripted answers: tap a button, get one of ten pre-written responses. That's changed. Hook a bot up to an LLM API and it starts holding real conversations, tracking context, and phrasing replies that were never written into any script. Here's a step-by-step look at how to connect an LLM API to a Telegram bot on a VPS — from registering the bot to running a service that can handle real traffic.
Why a VPS instead of a home computer or a free hosting plan? Telegram expects the bot's server to be reachable around the clock. Home internet drops, IP addresses change, and free platforms tend to go idle after a few minutes of inactivity. A virtual server solves all three problems at once — a fixed address, uninterrupted uptime, and enough resources to handle LLM requests without noticeable lag.
This kind of setup has become a common building block for small teams and solo developers who want an AI-powered assistant without building a standalone app. A Telegram bot already has a distribution channel, a familiar interface, and push notifications built in — all that's missing is the intelligence layer, and that's exactly what an LLM API provides.
What Is an LLM API and Why Does a Telegram Bot Need One
An LLM API is a programming interface an application uses to send text to a language model and get a generated reply back. That's how OpenAI, Anthropic Claude, Google Gemini, and dozens of other services work: the bot builds a JSON request, sends it over HTTPS, and receives a ready-made response. The model itself has no idea it's talking through Telegram — it just processes text, while the bot's code handles delivery.
The Telegram Bot API works in a similar way: the bot gets a token that lets it receive incoming messages and send replies. In practice, a bot running on a VPS acts as a go-between for two APIs — it pulls the user's message from Telegram, forwards it to the LLM, waits for a response, and sends the result back. A small script doing three things: listening, thinking, and answering.
The VPS is where that script lives around the clock. It keeps the connection to Telegram open and calls the LLM API whenever a new message arrives. It's worth noting that the model itself isn't hosted on your server — you're paying the LLM provider for compute, while the VPS only handles the bot's logic and, if needed, stores conversation history.
How It Works: Architecture and Step-by-Step Setup
The flow is straightforward: a user messages the bot → Telegram forwards it to the server → the script builds a request to the LLM API → the model returns text → the bot sends it back to the user. Each step has a few details worth getting right from the start.
Registering a Bot on Telegram and Getting a Token
A bot is created through the official @BotFather: the /newbot command, a name, a username — and in return you get a token that looks like 123456:ABC-DEF. The token is an access key, and it should never be published in a public repository or hardcoded into your source. Keep it in environment variables or a separate config file that's excluded from version control.
Getting Access to an LLM API
Next you need an API key from your chosen model provider. Sign up, add a payment method, generate a key from the dashboard. Most providers offer a free trial quota, which is usually enough to test the bot-and-model pairing before going to production. Pricing is usually quoted per million tokens, and it's worth checking both the input and output rates before committing to a provider — output tokens are typically priced higher and add up faster in a chat-style bot. Here's a comparison of the popular options.
| Provider | Popular Models | Strengths | Best For |
|---|---|---|---|
| OpenAI | GPT-4o, GPT-4o mini | Large ecosystem, clear docs, function calling | General-purpose chat bots and assistants |
| Anthropic | Claude Sonnet, Claude Haiku | Long context window, careful instruction-following | Bots with complex logic and long dialogues |
| Gemini 2.0, Gemini Flash | Fast, low-cost models in the Flash line | Bots with high request volume | |
| Mistral | Mistral Large, Mistral Small | Open weights for some models, flexible pricing | Budget-conscious projects |
| Ollama (self-hosted) | Llama 3, Mistral, Qwen | Model runs directly on the server, no external API | Projects with strict privacy requirements |
Preparing the VPS and Environment
A modest server is enough to run the bot — 1–2 vCPUs and 1–2 GB of RAM will do for the start, as long as the model is called over an API rather than run locally. A Serverspace VPS running Ubuntu is a solid fit here — it spins up in minutes, and you can scale resources later as your user base grows. The server will need Python and a handful of libraries:
sudo apt update && sudo apt install python3-pip python3-venv -yNext, create a virtual environment and install the dependencies — a library for the Telegram Bot API and the SDK for your chosen LLM provider:
python3 -m venv botenv && source botenv/bin/activatepip install aiogram openai python-dotenvWriting the Bot Code and Integrating the LLM
A minimal bot's logic fits into three blocks: receive the message, call the LLM API, send the reply. Keys live in a .env file loaded through python-dotenv rather than hardcoded into the source. The model call itself looks roughly like this:
response = client.chat.completions.create(model="gpt-4o-mini", messages=[{"role": "user", "content": user_text}])The model's reply comes back as text, which then just needs to be passed to the Telegram send-message method. This is also the point to add error handling — network hiccups and rate limits happen even with reliable providers, and the bot shouldn't just go silent when they do.
Running the Bot as a Service
A script running in a terminal window stops the moment the SSH session closes. To keep the bot running continuously, set it up as a systemd service with automatic restarts on failure:
sudo systemctl enable telegram-bot.service && sudo systemctl start telegram-bot.serviceFrom then on, the bot survives server reboots and process crashes without manual intervention — systemd brings it back up according to the unit file.
Webhook or Long Polling: How the Bot Receives Messages
There are two ways for the bot to get messages from Telegram. Long polling has the script ask Telegram's server once a second whether there's anything new; it's simpler to set up and doesn't need a domain with HTTPS, which makes it convenient for getting started. A webhook works the other way around: Telegram pushes each message straight to the bot's address as soon as it arrives. That option is lighter on resources and reacts faster, but it needs an SSL certificate and an open port — on a VPS that's a quick nginx-and-certbot setup.
Long polling is fine for a small bot. Once traffic grows into the hundreds of messages a minute, switching to a webhook makes sense — it cuts out redundant calls to the Telegram API and noticeably shortens the gap between a user's message and the bot's first response.
Testing and Monitoring
Before going live, it's worth running the bot through a few scenarios: short questions, long messages, nonsense input, repeated requests in a row. Keeping a log of LLM API calls pays off — it's the fastest way to trace what went wrong if the model starts giving odd answers or requests suddenly start taking much longer.
It's also worth setting up a basic uptime check — a script or an external service that pings the bot with a test message every few minutes. If the process crashes and systemd somehow fails to restart it, that check will flag the problem before users start complaining. Keeping an eye on token usage from the start is just as important — a sudden spike often points to a bug or abuse long before it shows up on the monthly invoice.
Pros and Cons of Connecting an LLM to a Telegram Bot via VPS
At first glance it looks like you just copy the code from the docs and it all works. In practice, this setup has real strengths alongside trade-offs worth weighing before you start the project.
| Pros | Cons |
|---|---|
| Full control over the server and the bot's code | Requires basic Linux administration skills |
| A fixed IP and 24/7 uptime | Costs for both the server and LLM API usage |
| Flexible choice of LLM provider and models | Security has to be configured yourself |
| You can store conversation history and logs | You're responsible for backing up that data |
| Easy to scale as load grows | Response time depends on LLM API speed |
Limitations and Risks
The main risk is cost: LLM APIs bill by token, and without limits in place a bot can quietly burn through a budget — especially if someone starts feeding it large chunks of text back to back. It's worth capping request length and per-user request frequency from day one.
The second risk is around securing the bot's token and the API key. If either one ends up in a public repository, someone else can send requests under your account and run up your bill. Both secrets are worth keeping out of the codebase entirely, with regular checks of your commit history for accidental leaks.
There's a technical limitation too — response latency. LLMs don't generate text instantly, and longer replies can mean a wait of several seconds. That's not a dealbreaker on Telegram, but it's worth adding a "typing…" indicator so users know the bot is working, not stuck.
User data is worth thinking about as well. Conversations with a bot often carry personal details — names, order numbers, work-related questions. Before sending any of that to an external LLM API, it's worth checking the provider's data-handling terms and deciding how much conversation history to keep on the server, and for how long. For projects with strict privacy needs, that's an extra argument for running a local model through Ollama instead — the user's text never leaves the VPS.
- Token and per-minute rate limits imposed by most providers
- Runaway costs if bot usage isn't kept in check
- Risk of an API key leaking through careless storage
- Response delay when the model generates longer replies
- Need for response moderation on public-facing bots
Practical Use Cases
Pairing a Telegram bot with an LLM API isn't just for novelty chat bots. Here are a few use cases that come up in practice.
Customer support bot. The model handles routine product or service questions and hands off anything complex to a human agent. It takes load off the support team and never clocks out.
Personal assistant. The bot helps plan the day, sends reminders, and answers quick questions on the fly — effectively replacing several separate apps with one chat window.
Content generator. Given a short brief, the model drafts posts, captions, or headline variations — handy for small editorial teams and social media managers.
Learning assistant. The bot explains terms, checks homework, and offers coding hints — essentially a tutor available at any hour.
Translator and editor. A user sends over a piece of text, and the model translates it or tightens up the wording — a scenario that's especially useful for teams working across languages.
Common Mistakes When Connecting an LLM to a Telegram Bot
Even a simple integration tends to trip up on the same handful of issues. Here are the most common ones.
- The bot token and API key are hardcoded instead of stored as environment variables
- No error handling for when the LLM API is unavailable
- No token limits set, so replies end up unnecessarily long and expensive
- The bot runs in a plain terminal session and dies when SSH disconnects
- No logging, so it's unclear where things broke when something goes wrong
One easy-to-overlook mistake is skipping the system prompt. Without clear instructions, the model can drift into the wrong tone or wander off topic. A couple of sentences describing the bot's role and boundaries go a long way toward making its responses predictable.
Conclusion
Connecting an LLM API to a Telegram bot on a VPS can be done in an evening: register the bot, grab an API key from a model provider, write a bit of Python, and wrap it in a systemd service for reliability. From there, the real work is in the details — limits, logging, a well-written system prompt — and those details decide whether you end up with a rough prototype or a service people actually keep using. For more on setting up servers for projects like this, check the Serverspace blog.
FAQ
Which LLM API should I pick for a Telegram bot — OpenAI, Claude, or something else?
It depends on the task. OpenAI works well for a general-purpose chat bot, Anthropic's models suit complex dialogues with long context, and Mistral or Gemini Flash are worth a look for budget-conscious projects.
How much does connecting an LLM API to a Telegram bot cost per month?
The cost has two parts: the VPS itself (typically $5–15 a month for an entry-level plan) and LLM API token usage, which depends on request volume and length — anywhere from a few dollars to tens of dollars for an actively used bot.
Do I need a powerful VPS for this kind of bot?
No, not if the model is called through an external API. The bot's own logic is lightweight, so 1–2 vCPUs and 1–2 GB of RAM are enough to start, with room to upgrade as your audience grows.
Can I use a local model instead of a cloud API?
Yes, through tools like Ollama. That removes the dependency on an external provider and suits projects with strict privacy requirements, though it calls for a more powerful server with enough memory to run the model itself.
How do I keep the API key from leaking?
Store it in environment variables or a .env file excluded from version control, restrict file permissions on the server, and rotate the key periodically through the provider's dashboard.
What should I do if the bot responds slowly?
Check the model's own speed first — lighter versions like GPT-4o mini or Gemini Flash respond faster. Trimming the system prompt and capping the reply length on the request side also helps.
Can one bot use more than one LLM model?
Yes, that's a common setup: a fast, cheap model handles simple questions, and a more capable one kicks in only for harder requests. Switching between them can be based on keywords, a user command, or message length — the logic stays entirely in the bot's own code.
Do I need a separate domain for the bot on my VPS?
Not for long polling — the script just needs outbound internet access. A domain only becomes necessary if you switch to a webhook, since Telegram sends messages to a specific HTTPS address and won't deliver them without a valid SSL certificate.
