What to check before choosing a provider
Start with the support workflow, then compare API details. A low-friction demo can still fail when a customer repeats a message, a request times out, or an agent needs the full conversation.
| Provider question | Test to run before launch |
|---|---|
| Which model IDs are available? | Fetch the catalog and reject unknown IDs during deployment |
| Which request format is supported? | Run one fixture through your selected SDK and gateway |
| How do errors and limits look? | Simulate a timeout, rate limit, invalid key, and depleted balance |
| What usage data can you inspect? | Match a request ID to model, duration, status, and account |
| How is customer data handled? | List fields sent to the provider and remove fields you do not need |
| Can the bot switch routes? | A fallback prevents one provider incident from becoming a full outage |
The models documentation shows the IDs available through Claudexia. Recheck it when you deploy a router because model availability can change.
A model route for common support work
The live catalog checked on 2026-10-03 includes several families. The table describes a route to test, not a ranking. Use anonymized tickets and your own acceptance rubric.
| Support job | Model IDs to test | Acceptance check |
|---|---|---|
| Short FAQ and routing label | claude-sonnet-5, gpt-6-luna, deepseek-v4-flash | The answer stays inside the policy and the label parses |
| Long account or product explanation | claude-opus-5-5, gpt-6.1-sol, gemini-3.8-flash | Conditions, exceptions, and next steps remain present |
| Second route for a comparison run | claude-fable-5-1, gpt-6-sol, qwen3.8-flash | The same fixture produces a reviewable result |
| Sensitive account case | A tested route followed by a human | No refund, identity, or account change runs automatically |
Do not let the model choose a refund, password reset, or account state transition by itself. A server-side tool should validate the request, record the action, and require approval when policy says so.
Keep the Telegram layer thin
The Telegram adapter should authenticate the chat, normalize the update, and send a response. Business rules belong in a service that can also serve a web chat or agent console.
Telegram webhook
-> chat authentication and idempotency
-> support service and knowledge retrieval
-> model router
-> provider gateway
-> policy check and human handoff
-> Telegram response
Put a queue between the webhook and generation when a reply can take longer than a Telegram request window. Store the update ID and refuse a second delivery of the same event. A user can tap twice. Networks can retry.
A server-side provider call
Keep the API key in the runtime environment. The browser and Telegram message must never receive it.
const baseURL = process.env.CLAUDEXIA_BASE_URL ?? "https://api.claudexia.tech";
const apiKey = process.env.CLAUDEXIA_API_KEY;
if (!apiKey) {
throw new Error("CLAUDEXIA_API_KEY is missing");
}
const response = await fetch(`${baseURL}/v1/messages`, {
method: "POST",
headers: {
authorization: `Bearer ${apiKey}`,
"anthropic-version": "2023-06-01",
"content-type": "application/json",
"x-request-id": requestId,
},
body: JSON.stringify({
model: "claude-sonnet-5",
max_tokens: 700,
system: SUPPORT_POLICY,
messages: [{ role: "user", content: ticketText }],
}),
});
if (!response.ok) {
throw new Error(`model request failed: ${response.status}`);
}
Use the request ID in application logs and in the support console. Record the model ID, elapsed time, response status, and retry count. Avoid logging full tickets by default, especially when a ticket can contain payment or identity data.
Human handoff is part of the product
Create explicit escalation cases before launch. Route payment disputes, identity changes, legal threats, uncertain policy, repeated failed answers, and a direct request for a person to an agent. The bot should say that a person is reviewing the case and show a reference ID.
Give the agent the original message, the retrieved policy passages, the draft answer, and the reason for escalation. Let the agent edit the draft before it goes to Telegram. The model can prepare context. Your support system owns the final send.
See the guide to building a Claude support chatbot and the companion Telegram support bot provider checklist for more routing examples.
Tests before production traffic
Keep fixtures for a normal FAQ, an unknown question, an incomplete account request, a prompt injection, a rate limit, a provider timeout, and a handoff. Assert both the model request and the Telegram message.
Set per-chat concurrency limits. Add a timeout around each provider call and a bounded retry policy for transient errors. Never retry a tool that changes account state unless it carries an idempotency key.
FAQ
Can one LLM provider handle a Telegram support bot?
One provider can simplify routing. Keep a tested second route or a human path for provider errors, and make sure the fallback accepts the same policy and output format.
Which model is best for customer support?
Start with a model that follows your policy and returns data your application can parse. Compare Claude, GPT, Gemini, and DeepSeek on anonymized tickets instead of choosing by name alone.
Can the model update a customer's account?
Only through a server-side tool with permissions, validation, an audit record, and an approval rule for sensitive actions. The model output itself is not authorization.
Where should the API key live?
Use a server environment variable or secret manager. Do not put it in a Telegram message, browser bundle, mobile app, or repository.
How do I check current model availability?
Read the models documentation and the live catalog immediately before a release. Keep unknown IDs out of production configuration.