Skip to main content

​
BytePlus Coding Plus Telegram

Use this playbook when coding traffic should stay on the dedicated BytePlus Coding lane while Telegram owns the lightweight live reply-loop surface. This page keeps three boundaries explicit:
  • BytePlus general traffic and BytePlus Coding traffic are not the same lane
  • Telegram is a shipped runtime-backed bot surface
  • gateway ownership only comes after the Telegram loop already works

​
When This Is The Right Playbook

  • coding quota or pricing should stay on the dedicated coding route
  • one Telegram bot should own the reply loop
  • you still want a separate general BytePlus profile available for other work
  • the team wants explicit profile switching instead of one profile being rewritten repeatedly

​
Use A Different Playbook If

If you actually need…Go here instead
Volcengine plus Feishu or LarkVolcengine Plus Feishu Or Lark
Volcengine plus WeComWeCom Rollout
several already-healthy runtime-backed channels on one hostGateway Rollout

​
Step 1: Keep General And Coding Profiles Separate

active_provider = "coding"

[providers.byteplus_main]
kind = "byteplus"
api_key = { env = "BYTEPLUS_API_KEY" }
model = "auto"

[providers.coding]
kind = "byteplus_coding"
api_key = { env = "BYTEPLUS_API_KEY" }
model = "your-reviewed-coding-model"
Why this matters:
  • byteplus belongs to the general /api/v3 lane
  • byteplus_coding belongs to /api/coding/v3
  • keeping both profiles visible is cleaner than patching one profile back and forth with ad-hoc route overrides

​
Step 2: Confirm The Active Coding Lane

loong doctor
loong ask --message "Confirm that the active provider is the dedicated coding lane."
If you want to inspect the general profile separately later, switch active_provider deliberately instead of changing the kind on the active profile in place.

​
Step 3: Add The Telegram Bot Surface

Single-account config: 
[telegram]
enabled = true
bot_token = { env = "TELEGRAM_BOT_TOKEN" }
allowed_chat_ids = [123456789]
Smoke-test it: 
loong telegram-send --target "123456789" --text "hello from loong"
loong telegram-serve
Operational notes:
  • allowed_chat_ids is the trust boundary
  • Telegram is the smallest runtime-backed reply-loop lane in the current public docs set

​
Step 4: Move To Named Bot Accounts If Needed

If one config should hold several Telegram identities, move to named accounts before introducing gateway selectors. 
[telegram]
enabled = true
default_account = "bot_123456"

[telegram.accounts.bot_123456]
bot_token = { env = "TELEGRAM_BOT_TOKEN" }
allowed_chat_ids = [123456789]

[telegram.accounts.ops]
bot_token = { env = "TELEGRAM_OPS_BOT_TOKEN" }
allowed_chat_ids = [987654321]
Now the selector story is explicit: 
loong gateway run --channel-account telegram=bot_123456
loong gateway status --json

​
Step 5: Choose Foreground Or Persisted Ownership

Foreground loop: 
loong telegram-serve
Persisted owner contract: 
loong gateway run --channel-account telegram=bot_123456
loong gateway status --json
loong gateway stop
Use the foreground loop first during rollout. Use gateway ownership only after the bot path already behaves correctly.

​
Troubleshooting

SymptomWhat to check
the runtime behaves like the general BytePlus lane instead of the coding laneconfirm active_provider = "coding" and keep byteplus_main separate
the coding profile is pointed at a generic /api/v3 pathswitch back to byteplus_coding instead of forcing the route with ad-hoc URL overrides
telegram-send works but telegram-serve is not stablereview allowed_chat_ids and make sure the bot identity is the one you expect
gateway run --channel-account telegram=bot_123456 failsadd default_account and accounts.bot_123456 first, or run gateway run without a selector

​
Continue Reading