Runtime reasoning effort control via Telegram commands

[seqis]

Use Case

When using OpenAI reasoning models (gpt-5-mini, gpt-5 family), the reasoning_effort parameter controls how deeply the model thinks before responding. Different questions call for different levels -- a quick "what time is it?" doesn't need the same thinking depth as a logic puzzle. Currently, changing the effort level requires editing config.json and restarting the gateway.

What I Built

I patched my local install to add three Telegram slash commands:

• /rhigh -- set reasoning effort to "high"
• /rmed -- set reasoning effort to "medium"
• /rlow -- set reasoning effort to "low"

I also added /status to show the current model, reasoning effort, max tokens, and uptime.

The commands are intercepted in AgentLoop._process_message() before the LLM call, so they execute instantly without consuming tokens or creating a session. The change persists in memory until the gateway restarts (then it falls back to the config default).

How It Works

Agent loop (agent/loop.py):

• A _handle_slash_command() method checks incoming messages against a command map
• Reasoning commands update self.reasoning_effort in-place
• Returns an OutboundMessage directly -- no LLM call, no session save

Telegram channel (channels/telegram.py):

• CommandHandler entries for rhigh, rmed, rlow, status forward messages to the bus (short for reasoning high/med/low.
• This is needed because Telegram's ~filters.COMMAND filter excludes / messages from the general message handler

Why This Might Be Useful Upstream

• Reasoning tokens cost money. Being able to drop to "low" for simple questions saves real dollars over time.
• The UX difference is significant -- high effort on a simple factual question adds latency for no benefit.
• The pattern is extensible to other runtime settings (temperature, model switching, etc.).

Considerations

• This is currently OpenAI-specific. Other providers may not support reasoning_effort, so the commands would need graceful handling for non-reasoning models.
• The effort level resets on gateway restart. Persisting it to config would be a nice enhancement but adds complexity.
• Command names are short and opinionated -- the team may prefer different naming (e.g., /effort high).

Happy to share my implementation or open a PR if there's interest. Thanks!