[Feature][model] Add Synthorai as a proxy LLM provider

Search before asking

• I had searched in the issues and found no similar feature requirement.

(Searched synthorai and synthor across issues and pull requests, open and closed — no existing request.)

Description

Add Synthorai as a proxy LLM provider under packages/dbgpt-core/src/dbgpt/model/proxy/llms/, following the same pattern as the aggregator gateways already in that directory: orcarouter.py, aimlapi.py, burncloud.py, litellm.py, siliconflow.py.

Disclosure first: I work on Synthorai, so this is a vendor request, not a report of user demand. Synthorai is early stage — it is not a large or well-known provider, and I am not going to claim a user base it does not have. I am filing this because #3186 (OrcaRouter) was merged on 2026-08-14 under exactly the same circumstances, with the author openly stating they were on the OrcaRouter team, which suggests this class of contribution is welcome here. If you would rather not keep adding small aggregators, please close this — no hard feelings. The generic OpenAI-compatible configuration already works today, so this is purely about discoverability, not capability.

Synthorai in one line: an LLM API gateway serving 113 models across 11 upstream providers (Claude, GPT, Gemini, GLM-5.2, Kimi-K3, DeepSeek, Qwen and others) behind one base URL and one key, at direct-provider prices with zero markup.

Technical details relevant to the integration:

• OpenAI-compatible: POST https://synthorai.io/v1/chat/completions and POST https://synthorai.io/v1/responses
• Base URL for OpenAI SDKs: https://synthorai.io/v1
• Auth: standard Authorization: Bearer <key>; proposed env var SYNTHORAI_API_KEY
• Also Anthropic-compatible on the same base URL (POST https://synthorai.io/v1/messages). Not needed for this integration — noting it only because it means one key also covers users running Anthropic-format clients elsewhere.
• Live production service, not a beta or waitlist.

Because the OpenAI Chat Completions surface is standard, the provider module would be a thin subclass of OpenAILLMClient / OpenAICompatibleDeployModelParameters exactly like orcarouter.py — no new protocol handling, no new dependency.

Use case

A DB-GPT user who wants to compare or switch between Claude, GPT, Gemini, DeepSeek, Qwen and GLM for ChatData / ChatDashboard / agent workloads currently has to register and manage a separate account and key per upstream. With a Synthorai entry they set one SYNTHORAI_API_KEY, put provider = "proxy/synthorai" in their config, and switch models by changing the model id.

This is admittedly already achievable through the generic OpenAI-compatible escape hatch. The reason to add a first-class entry is the one given in #3186: it keeps the model picker, the config reference (configs/dbgpt-proxy-*.toml) and the installation docs consistent with how the other gateways are wired, rather than leaving users to hand-assemble a base URL.

If a maintainer wants to try it before deciding: signup is free and needs no card, and the free tier is 10 calls up to $1 — enough to run a couple of ChatData queries end to end. Docs: https://synthorai.io/docs/ · Pricing: https://synthorai.io/pricing/

Related issues

No open or closed issue requests this. Direct precedent is #3186 (feat(model): add OrcaRouter proxy provider, merged 2026-08-14) — same provider class, same four-file shape.

Comparable providers already in tree: aimlapi.py, burncloud.py, litellm.py, orcarouter.py, siliconflow.py.

Feature Priority

Low

Deliberately Low. Nobody is blocked, since the OpenAI-compatible path works. This is a consistency and convenience addition, and I would rather rank it honestly than inflate it.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Happy to do all the work. Mirroring #3186, I would touch four files:

• packages/dbgpt-core/src/dbgpt/model/proxy/llms/synthorai.py — SynthoraiLLMClient and SynthoraiDeployModelParameters (provider = "proxy/synthorai", api_base ${env:SYNTHORAI_API_BASE:-https://synthorai.io/v1}, api_key ${env:SYNTHORAI_API_KEY}), registered through register_proxy_model_adapter
• packages/dbgpt-core/src/dbgpt/model/proxy/__init__.py — add SynthoraiLLMClient to the lazy import map
• configs/dbgpt-proxy-synthorai.toml — ready-to-run config example
• docs/docs/installation/integrations/synthorai_llm_install.md — install doc alongside the others

Before opening it I would run make fmt, make fmt-check, make mypy and make test per CONTRIBUTING.md, confirm scan_model_providers() registers the adapter and get_model_adapter("proxy/synthorai", ...) matches, and test against the live endpoint (non-stream, stream, tool calling, bad key returns 401) so the PR carries the same evidence #3186 did. I will confirm the exact default model id against the live catalog in the PR rather than guessing at one here.

Just say the word and I will open it — or close this if the proxy directory is not taking further gateways. Either answer is genuinely fine. Thanks for DB-GPT!

---

中文摘要：希望参照已合并的 #3186（OrcaRouter）在 model/proxy/llms/ 下新增 Synthorai provider。Synthorai 是 OpenAI 兼容的 LLM 网关（base URL https://synthorai.io/v1，113 个模型 / 11 家上游，原价无加价），实现方式与 orcarouter.py 完全一致，只需继承 OpenAILLMClient，共改 4 个文件。利益相关声明：我是 Synthorai 团队成员，项目处于早期阶段，没有用户规模可言，这不是社区需求而是厂商申请。 优先级填 Low，PR 我来写并附完整测试证据。免费额度可直接试用（10 次调用 / 上限 $1，无需绑卡）。如果维护者不希望继续引入小型聚合网关，直接关闭即可。