# Telegram bot operations > Audience: administrators. This page is hidden from members and guests in the sidebar, the > search index, and the documentation export. It describes operating the `TelegramService` that > powers [Devii on Telegram](/docs/telegram.html). The Telegram bot bridges Devii into Telegram. It is implemented as a background service, `TelegramService` (`devplacepy/services/telegram/`), and is **off by default** because not every deployment has a Telegram bot token. Start, stop, configure and monitor it from [Services](/admin/services) like any other background service. ## Enabling the bot 1. Create a bot with @BotFather in Telegram and copy its token. 2. On the Services page, open **Telegram Bot**, paste the token into **Bot token** (a secret field), and save. 3. Start the service. It launches a single long-poller subprocess and the bot goes live. A member then pairs from their profile and chats with their own Devii. Pairing codes, the AI spend cap, memory and tools are all per user. ## Configuration | Setting | Default | Purpose | |---------|---------|---------| | Bot token | (secret) | Telegram bot token from @BotFather. Required to start. | | Long-poll timeout | 25 | getUpdates hold time in seconds. | | Pairing code lifetime | 60 | Minutes a profile pairing code stays valid. | | Max concurrent turns | 8 | Upper bound on Devii turns processed at once across all chats. | The 24 hour AI spend caps are the same per-user, per-guest and per-admin limits configured on the Devii service; Telegram turns count against the same ledger. ## How it runs - **One poller, always.** The service runs only on the worker that holds the background-service lock, so there is exactly one long-poller. This is required: Telegram rejects concurrent polling for the same token with a 409 error. - **Isolated subprocess.** The poller runs as a supervised subprocess. The bot token is passed to it through the environment and is never written to disk outside the settings store. - **In-process Devii.** Incoming messages are handled in the same process as Devii, so every turn reuses the existing sessions, memory, tools, quota and audit log. The Telegram thread is its own conversation but shares the user's Devii memory. - **Images.** A photo a user sends is read by the gateway vision model, so Devii can respond to it. For this to work the gateway vision model must be enabled. ## Cost accounting Every Telegram turn authenticates the gateway call with the **paired user's own API key**, so the gateway attributes the request, including the image vision sub-call, to that exact user. Both the chat completion and the vision describe are written to the gateway usage ledger under the user, so [AI usage](/admin/ai-usage) reports precisely what each user cost us, at the instant it happened. The gateway also folds the vision sub-call cost into the response cost header, and Devii records that authoritative native cost rather than estimating from tokens, so a user's 24 hour spend cap and the usage percentage they see reflect the true cost including image understanding. ## Monitoring and logs The service detail page shows live statistics: messages in and out, edits, errors, average response time, uptime, and whether a token is set. The **Live output** panel streams the poller's operational log in real time. This live log is **never stored in the database**; it is streamed over the pub/sub bus only while you are watching the page. ## Notifications tool When the bot is running, Devii gains a `telegram_send` capability that can push a message to a paired user's Telegram, including from a scheduled task. It only works for a signed-in user who has paired Telegram, which is the basis for future Telegram notifications. ## Audit Pairing and delivery are audited under the `telegram` category: `telegram.pair.request`, `telegram.pair.success`, `telegram.pair.failure`, `telegram.unpair`, and `telegram.send`. Review them on the [Audit Log](/docs/audit-log.html).