Kimi and DeepSeek on the LLM Gateway, Plus a Way to Try Them

What's new

The Enterprise LLM Gateway now supports two more providers: Kimi (Moonshot AI) and DeepSeek. Org admins can configure credentials for either the same way they already do for OpenAI, Azure OpenAI, Anthropic, and Gemini — under Enterprise → LLM Gateway on the org's admin page — and team gateway keys can be scoped to allow them like any other provider.

Alongside that, a new Compare Model action is available on any captured proxy session (a session that went through the LLM Gateway). From the session detail page, you can re-run that session's prompt against a different model — say, swap the original OpenAI call for a Kimi or DeepSeek one — and see a diff between what the original model actually said and what the new one produces. It's a fast way to answer "would a different or cheaper model have handled this the same way?" without leaving the session or reconstructing the prompt by hand somewhere else.

How it works

Kimi and DeepSeek integrate the same way every other Gateway provider does: once an admin saves credentials for one, it shows up as a normal provider option everywhere the Gateway already supports provider selection — team gateway key scoping, model-pattern restrictions, and the existing enable/disable toggle if an admin ever needs to pause a provider without deleting its credentials.

Compare Model builds directly on top of that. Open a proxy session, click "Compare Model," pick a provider and a model name, and paste in a team gateway API key for that org (the same kind you'd create under Enterprise → LLM Gateway → Team Gateway Keys for any other use). The key isn't stored — it's used once, for that single call, and then discarded.

The comparison call goes through the same authenticated path as regular Gateway traffic, so the same rules apply automatically: the provider has to be configured and enabled for the org, and the pasted key has to be allowed to use that provider and model. If a key is invalid, revoked, or not scoped for the model you picked, you get that exact error back.

One consequence worth calling out plainly: because comparison calls go through the real Gateway endpoint, they show up in ordinary Gateway traffic — they're not a separate, invisible "preview" lane. If you run a comparison, it's a real API call, billed and logged the same as any other request through that key.

What to expect right now

A few limitations we're watching:

• You need an existing team gateway key. Compare doesn't mint a one-off key for you — you paste in a real one, which means someone has to have created one already (and you need to have its raw value, which is only shown once at creation). If this friction turns out to matter in practice, a narrower-scoped, comparison-specific credential is a reasonable next step — tell us if this gets in your way.
• The diff is a plain text diff, not a semantic one. It'll show you every wording difference between the two responses, not just the ones that reflect an actual change in behavior or correctness. Read it with that in mind.
• Results aren't saved. Run a comparison, look at it, close the window — nothing persists. Re-run any time you want to check again against a different model.
• Access to Compare is governed by whoever holds a valid gateway key for the org, not by session-view permissions specifically. If that scoping feels wrong for your team's setup, we'd like to hear about it.

If you hit a case where this doesn't behave the way you'd expect — especially around gateway-key scoping, provider availability, or the diff output — we want to know. This is a first pass, and it's the kind of feature where the sharp edges only show up with real use.