Quox Telegram Pro · $29 one-time
Your agents and your approvals, already in your pocket.
A bidirectional gateway bot you create and own, with forum-topic terminal channels for live session visibility and a Telegram chat that can carry your HITL approvals. Long-polling by default, so no public URL or open port is needed to get started.
In plain words
What it is, where it lives, when to reach for it
- What is it
- A plugin for QuoxCORE that connects a Telegram bot you own to your agents and their approvals.
- Where do I use it
- In your Telegram app, talking to your own bot; managed with
quox tgfrom your terminal. - When would I use it
- When you are away from the dashboard and still need to watch sessions or approve an agent's action.
- How do I use it
- Create a bot with Telegram's BotFather, then run
quox tg statusandquox tg bind-owner <chat_id>.
QuoxCORE is the free, self-hosted platform underneath this. What is QuoxCORE
How it works
Three steps, and it is live.
01 · connectA bot you own
Create a bot through BotFather and paste its token into the onboarding wizard. Quox never asks for BotFather access itself, and the token is stored in the vault, not in a config file.
▸ botfather token · vault-stored02 · listenLong-polling by default
Quox polls Telegram for updates, so nothing needs a public URL or an open port. A webhook is available as an opt-in "Advanced" path, only worth switching to if this install already has a public HTTPS endpoint.
▸ getUpdates · webhook opt-in03 · routeBidirectional, without duplicates
Inbound updates are deduplicated, so a Telegram retry or redelivery never processes the same message twice. Outbound sends are queued and paced against Telegram’s own per-chat, per-group and per-bot rate limits.
▸ update dedup · rate-aware queue
What ships today
A gateway bot, not a toy integration.
Every card below names the actual surface behind it: a durable table, a queue, or a wizard step, not a slide.
Gateway bot, owned by you
One bot, created through BotFather, connected with a token you control. Quox relays your agent conversations through it; it is never a shared bot across customers.
Forum topic terminal channels
Forum topics in your Quox Dev group are tracked as they are created, renamed, closed and reopened, so a topic can map to a live terminal session.
Replay-safe webhooks
Every inbound update is checked against a seen-update table before it is processed, so retries and redeliveries from Telegram never double-fire a reply.
Rate-aware outbound queue
One lane per bot, chat and thread, paced against Telegram’s published limits: roughly 1 message a second per chat, 20 a minute per group, 30 a second per bot. A 429 pauses the lane and requeues rather than dropping the message.
A roster, not a single bot
Gateway, agent and notify bots each get their own row: username, webhook or polling status, and how many chats are bound. Add a bot without leaving the roster view.
A guided setup, not a manual
A four-step wizard for the gateway bot (three for agent or notify bots) walks from bot creation to a bound Quox Dev group, with the owner channel bound at the end.
Approvals that find you
The inbox reaches your phone. The decision stays governed.
Telegram Pro is not a separate approval system: it is one more way a HITL item can reach you, on top of the platform’s existing 16-connector notification router.
A chat can already receive HITL notifications
Telegram is one of 16 delivery connectors the platform’s notification router already supports, and a Telegram Pro chat can be bound as a hitl_inbox target so approval items land there.
▸ channel_bindings · target hitl_inboxDeciding still happens on the inbox, CLI or MCP
The item finds you in Telegram, but approving from inside the thread itself is not shipped yet. Today the decision is made from the HITL inbox, the quox inbox CLI, or an MCP-connected Claude, then relayed.
▸ inbox · quox inbox CLI · MCPApproving with a yes, a no, or sending work back for another pass, all lives on the HITL inbox: read the full HITL page for the escalation ladder, the audit trail, and what is proven versus still beta there.
Where it stands
What's proven, what's still beta.
- Gateway bot creation via BotFather, vault-stored token, and the 4-step owner onboarding wizard, shipped in v1.0.0
- Long-polling is the default connection path, so no public URL or open port is required; a webhook is an opt-in "Advanced" path for installs that already have a public HTTPS endpoint
- Inbound update deduplication and a rate-aware outbound queue (per-chat, per-group and per-bot pacing, 429 backoff) both run today, not as a planned upgrade
- Forum topics are tracked as they are created, renamed, closed and reopened, but the activity feed showing session traffic inside them "lands in a later phase of Telegram Pro" (the product’s own roster view says so)
- A Telegram chat can be bound as a HITL delivery target, but multi-channel HITL delivery through Telegram is marked Experimental platform-wide and has not been verified against a live send
- On instances where the full multi-bot roster backend has not shipped yet, the roster view synthesizes its rows from the older single-bot status endpoint rather than genuine per-bot detail
- Approving or rejecting an item from inside the Telegram thread itself, "reactions-as-HITL", is on the roadmap and not built
- Per-agent bot identities and a /link command to bind a Telegram user to a Quox identity are both listed as future features, not shipped
- TRIAGE-Q cannot read or act on inbox items today, only summarise from memory, so it cannot pre-triage what lands in your Telegram chat
- The Matrix bridge that would relay a governed room into a Telegram group is stopped pending a relay-mode rewrite; a human decides from the dashboard or the inbox today, not from that path on a phone
Ready when you are
Put your agents where your phone already is.
Quox Telegram Pro is a one-time $29 plugin: create a bot, connect the token, and the onboarding wizard does the rest.