Smart LLM Supervisor Gateway¶
The Smart LLM Supervisor Gateway is a small, hardened HTTP service that sits between your coding client (Aider, Cline, Roo-Code, your own scripts) and the OpenRouter API. It does one thing well: it decides which model should answer a request so that trivial edits are cheap, risky or repeated work is escalated to a stronger model, and private content never leaks to a free public endpoint.
What problem does it solve?¶
When you write software with an LLM agent, three forces pull in different directions at once:
- Cost. A frontier-grade senior solver is overkill for renaming a variable.
- Reliability. A cheap worker may silently mis-implement a security fix, which is more expensive than the savings.
- Privacy. A "free" public model is rarely an acceptable place to paste your private code.
The Supervisor is the small, deterministic policy engine that balances those forces per request. It does not invent answers, and it does not let a model choose itself. The model is chosen by a fixed rule chain that always prefers the safer or cheaper option, unless an explicit "this one is hard" signal is present.
Where does it sit?¶
flowchart LR
Client["Coding client<br/>(Aider, Cline, Roo-Code,<br/>custom script)"] -->|HTTPS| Gateway["Smart Supervisor Gateway<br/>https://smart-openrounter.bee1x.one"]
Gateway -->|chat completions| OpenRouter["OpenRouter"]
OpenRouter --> Flash["DeepSeek V4 Flash<br/>(default worker)"]
OpenRouter --> Pro["DeepSeek V4 Pro<br/>(senior solver)"]
OpenRouter --> Scout["Nemotron 3 Ultra<br/>(scout, non-sensitive only)"]
OpenRouter --> GLM["GLM-5.2<br/>(emergency fallback)"]
The gateway is a single FastAPI process. It does not own a database visible to clients, does not store prompts, and does not perform any agent-style tool execution. The coding client remains the agent; the gateway only routes the request and proxies the response.
Who should use it?¶
- Individual developers running coding agents against OpenRouter who want predictable cost and privacy behavior without hand-tuning every model.
- Small teams that want a single stable OpenAI-compatible endpoint shared by multiple clients, with policy enforced server-side.
- Anyone replacing a self-hosted LLM in an IDE workflow who already uses OpenRouter and needs a drop-in base URL.
Endpoint users call¶
| Purpose | URL |
|---|---|
| Chat completions (the only client-facing LLM endpoint) | https://smart-openrounter.bee1x.one/v1/chat/completions |
| Routing decision preview (dry-run, no inference) | https://smart-openrounter.bee1x.one/v1/route/decision |
| Health probe | https://smart-openrounter.bee1x.one/healthz |
| Prometheus metrics | https://smart-openrounter.bee1x.one/metrics |
The base URL is the same as any OpenAI-compatible endpoint. Swap
api.openai.com for smart-openrounter.bee1x.one and pass a
SMART_GATEWAY_API_KEY in the Authorization: Bearer … header.
Main routing aliases¶
The model field is treated as an alias that the gateway translates into a real OpenRouter model.
| Alias | Behavior |
|---|---|
smart-router |
Default. The gateway picks Flash, Pro, or Scout based on the request and policy. |
smart-router-flash |
Force the cheap, default worker (DeepSeek V4 Flash). |
smart-router-pro |
Force the senior solver (DeepSeek V4 Pro). |
smart-router-free |
Force the free Scout (Nemotron 3 Ultra). Rejected with HTTP 403 if the request is marked sensitive. |
Five-minute quickstart¶
Set two environment variables and make one request:
export SMART_GATEWAY_API_KEY="<your-gateway-key>"
export SMART_GATEWAY_BASE_URL="https://smart-openrounter.bee1x.one"
curl -sS "$SMART_GATEWAY_BASE_URL/v1/chat/completions" \
-H "Authorization: Bearer $SMART_GATEWAY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "smart-router",
"messages": [{"role": "user", "content": "Reply with the single word PONG and nothing else."}],
"max_tokens": 8
}'
A working response looks like:
{
"id": "gen-…",
"object": "chat.completion",
"model": "deepseek/deepseek-v4-flash-0731",
"choices": [
{
"index": 0,
"message": {"role": "assistant", "content": "PONG"},
"finish_reason": "stop"
}
]
}
The full quickstart, including Python and Aider configuration, is in Getting started → Quickstart.
How to read this documentation¶
- New user? Start with Getting started → Overview and then Quickstart.
- Integrating a client? Jump to Integrations.
- Need exact request/response shapes? Use the API reference.
- Curious about the model choice? Read Architecture → Routing pipeline and User guide → Routing behavior.
- Operating the production deployment? This public site stops at
the user-facing surface. The internal operator handoff, backup/restore,
rollback, and incident playbooks live in the repository under
docs-internal/(see Operations for how to get access).