Hunyuan and Tencent TokenHub on Olano

The short answer: Olano's named providers include Qwen, DeepSeek, Kimi and more than a dozen non-Chinese vendors; Hunyuan is not yet among them. Tencent Cloud's TokenHub exposes an OpenAI-compatible interface, and Olano has two general-purpose OpenAI-compatible routes: a LiteLLM proxy (model prefix litellm:, endpoint set by LITELLM_BASE_URL) and an OpenAI-compatible gateway provider whose endpoint can be overridden. Through either, Hunyuan runs in Olano today. The difference from a named provider: one extra layer, and whether model-specific parameters pass through depends on that layer.

Tencent Cloud details checked on 26 September 2026 against its public materials; endpoints and model names move, so confirm against current documentation.

What TokenHub is

Per Tencent Cloud's public description, TokenHub integrates Hunyuan and mainstream third-party models behind one interface, with day-zero access to new models, unified protocol and key management, and dynamic routing on cost, performance and capability. For a business the practical meaning is one key and one bill, with Hunyuan or another vendor behind it.

It is OpenAI-compatible, which is why Olano can reach it. Specific endpoint and model names belong to Tencent's current docs, which change faster than this page.

Route one: a LiteLLM proxy

The most general and most mature option. LiteLLM is an open-source model proxy that Olano treats as a provider (litellm):

1. Run a LiteLLM proxy and register TokenHub's OpenAI-compatible endpoint and your key as an upstream in its configuration.
2. In Olano set LITELLM_BASE_URL to that proxy.
3. Give the agent a model string litellm:<model-name>, where the model name is the alias you gave Hunyuan in the LiteLLM config.

The benefit is that LiteLLM already adapts to dozens of upstreams; parameter passthrough, error handling and retries are its job, and Olano sees a standard interface. The cost is one more process to keep running.

Route two: the OpenAI-compatible gateway provider

Olano includes a provider for OpenAI-compatible gateways. It defaults to one particular gateway, but its endpoint can be overridden — point it at TokenHub's OpenAI-compatible endpoint with a TokenHub key and, in principle, the proxy layer disappears.

The "in principle" matters: this route depends on how closely TokenHub's interface tracks the OpenAI specification, and compatibility layers always differ in small ways. It is one process fewer than route one and one adapter fewer. For production we suggest proving the model's behaviour through route one first, then deciding whether the proxy is worth removing.

Named provider versus compatible route, in practice

Compare Qwen's integration: one key, one prefix, and DashScope-specific capabilities such as thinking mode handled by a dedicated adapter. Hunyuan over a compatible route means:

• No difference in the fundamentals. Conversation, tool use, multi-turn context, memory, approvals — all of that lives in Olano's layer and is model-agnostic.
• Model-specific parameters may need attention. Whether they pass through depends on the middle layer.
• One more thing to maintain. The proxy's version, config and uptime.
• Switching still loses nothing. Memory and threads are independent of the model for every provider alike.

When this route is worth it

• You are already in Tencent Cloud and want model usage on the same bill as your other services.
• Your team and customers live in WeChat or WeCom — the channel is already connected via WeCom, and keeping the model in the same ecosystem is administratively tidy.
• You want Hunyuan and third-party models routed together, which is what TokenHub's dynamic routing is for.

If you simply want a Chinese model and have no existing Tencent Cloud commitment, Qwen's named integration is considerably less work. The two also coexist: lead on Qwen, one role on Hunyuan, in one deployment.

On "why not a named provider"

The provider list grows with demand rather than being fixed once, and the OpenAI-compatible routes mean a model does not have to wait for a named integration to be usable. If Hunyuan becomes a named provider, this page changes and the date on it changes with it.

For how the platforms themselves relate — Tencent Cloud's own AgentOps platform included — see Wukong, Qianfan, Hunyuan agents and Olano: where each fits.