What an API provider must answer
Before comparing model names, ask six operational questions:
| Question | Why it matters |
|---|---|
| Which model IDs are available? | Your router must not send traffic to a retired or absent model |
| Which request formats are supported? | Anthropic Messages and OpenAI-compatible requests use different bodies |
| How are limits and errors returned? | A bot needs a clear response for timeouts, rate limits, and depleted balance |
| What usage data can you inspect? | Support teams need to explain spikes and investigate failed replies |
| How is customer data handled? | Tickets can contain account, payment, and personal information |
| Can the bot switch routes? | A fallback prevents one provider incident from becoming a full outage |
Claudexia exposes a live catalog through one service. Check the models documentation before selecting the default because IDs and terms can change.
A support bot architecture
Keep the Telegram adapter thin. It receives an update, authenticates the chat, and sends a response or progress event. Your application layer retrieves account data, selects a model, and checks the output. A queue controls retries and stops a slow model call from blocking every chat.
Telegram update
-> webhook and chat authentication
-> support service and knowledge retrieval
-> model router
-> API provider
-> policy check and human handoff
-> Telegram reply
The model should not decide whether an account is refunded, disabled, or upgraded. Let a tool with an explicit permission perform that action, and ask a human for approval when the policy requires it.
Model routing for support
| Request | Starting model | Required check |
|---|---|---|
| FAQ and short instructions | claude-sonnet-5 or gpt-6-luna | Answer stays inside the knowledge base |
| Long policy explanation | claude-opus-5-5 or gpt-6.1-sol | All conditions and exceptions remain present |
| Ticket classification | gpt-6-luna or deepseek-v4-flash | Labels parse and match the rubric |
| Sensitive account case | Any tested route, then a human | No automatic state change without permission |
Treat the table as a starting route. Test with anonymized tickets, including incomplete details and attempts to override the bot's rules.
A safe provider integration
Use environment variables for the key and base URL. Keep the provider client on the server. Never put a key in a Telegram message, browser bundle, or repository.
const client = new Anthropic({
apiKey: process.env.CLAUDEXIA_API_KEY,
baseURL: "https://api.claudexia.tech",
});
const answer = await client.messages.create({
model: "claude-sonnet-5",
max_tokens: 700,
system: SUPPORT_POLICY,
messages: [{ role: "user", content: ticketText }],
});
Add a request ID to your logs and send that ID to your support team. Log model ID, elapsed time, and outcome. Do not log full conversations by default.
Human handoff is part of the product
Show the user when a human has taken the conversation. Pass the agent the original question, retrieved policy, model draft, and reason for escalation. Let the agent edit before sending.
Escalate on payment disputes, identity changes, legal threats, uncertain policy, repeated failed answers, and an explicit request for a person. Those conditions are easy to test and hard to recover from after an automatic action.
Tests before launch
Create fixtures for a normal FAQ, an unknown question, a prompt injection, a rate limit, a provider timeout, and a handoff. Check the text sent to Telegram and the state stored in your support system. A green API request is not proof that the customer saw a correct reply.
Set a per-chat concurrency limit. Telegram users can tap a button twice, resend a message, or trigger two webhook deliveries. Use an idempotency key for actions and a queue for generation.
FAQ
Is one provider enough for a Telegram support bot?
One provider can simplify operations, but keep a tested fallback or a human path for outages. The fallback must use a request format and prompt it accepts.
Can the model change a customer's account?
Only through a server-side tool with permissions, validation, and an audit record. Keep refunds, identity changes, and similar actions behind a human approval rule.
Which model is best for support?
Start with a model that follows your policy and produces a parseable response. Compare Sonnet, GPT, Gemini, or DeepSeek on anonymized tickets instead of choosing by brand.
Where should I keep the API key?
Store it in the server environment or a secret manager. Do not send it to Telegram, the browser, or a client-side app.
How do I check current model availability?
Use the models documentation and the live API catalog immediately before launch. Do not rely on a copied model list in an old tutorial.