Moonshot published the Kimi K3 weights. The model is 2.8 trillion parameters with a 1 million token context window, shipped in MXFP4 at roughly 594GB. Within a day it was being served by Baseten, Fireworks, Together, OpenRouter and SiliconFlow, with vLLM and SGLang ready for anyone self-hosting.
That speed created a small practical problem. When a model is proprietary there is one endpoint and one name. When the weights are open, every host picks its own identifier for the same file. K3 is currently spelled six different ways depending on where you send the request, and copying an id from one provider’s docs into another provider’s config gets you a 404.
SuperQode 0.2.56 carries the correct id for each route, so you pick a provider and the model resolves. This post covers the setup.
Setting up with Baseten
Baseten was a day zero host and exposes an OpenAI compatible endpoint, so it is the shortest path if you are starting from scratch.
Export your key and start SuperQode:
export BASETEN_API_KEY=your-key-here
superqode
Then connect:
:connect byok baseten moonshot-ai/Kimi-K3
Note the publisher spelling. Baseten uses moonshot-ai with a hyphen. Every other host uses moonshotai without one. It is an easy detail to lose when copying an id between providers, and the resulting error looks like the model is unavailable rather than misspelled. If you want to confirm the key is being read before connecting:
superqode connect setup baseten
That prints the environment variables SuperQode is looking for, whether they are set, the resolved base URL, and the exact connect command. It does not send anything anywhere. The same flow works headless:
superqode connect byok baseten moonshot-ai/Kimi-K3
The other routes
Pick whichever provider you already have a key for:
| Provider | Model id |
|---|---|
| Moonshot first party | kimi-k3 |
| Baseten | moonshot-ai/Kimi-K3 |
| Fireworks | accounts/fireworks/models/kimi-k3 |
| Together | moonshotai/Kimi-K3 |
| OpenRouter | moonshotai/kimi-k3 |
| SiliconFlow | moonshotai/Kimi-K3 |
| vLLM or SGLang | moonshotai/Kimi-K3-MXFP4 |
Pricing sits around $3 per million input and $15 per million output on the hosts that publish it. Fireworks additionally prices cached input at $0.30, which is worth paying attention to if you are running long agent sessions where most of the context is stable between turns.
The Moonshot first party API behaves differently from the rest in one respect: it fixes sampling parameters server side. SuperQode strips temperature, top_p and the penalty parameters on that route and leaves them alone everywhere else, because a host running the open weights will generally honour them.
Behaviour is consistent across providers
SuperQode matches K3 to its kimi model pack regardless of which host serves it. That pack sets maximum reasoning effort, enables parallel tool calls, and extends session history to 40 turns for cache friendliness. Switching from Baseten to Fireworks changes your latency and your bill. It does not change how the agent reasons or how it calls tools.
This matters more than it sounds when you are comparing providers. If the harness config drifted between routes you would be benchmarking two different agents rather than two different hosts.
Models Dev: One rough edge worth knowing
SuperQode reads its model catalogue from models.dev, which lets new models appear without anyone updating a hardcoded list. The tradeoff is that models.dev lags a launch by a few days, and it fills in host by host rather than all at once. At the time of writing, K3 shows up under Fireworks and Moonshot in the catalogue but not yet under Baseten. So if you open the Baseten model picker looking for K3, you may not see it listed.
Connecting by name works regardless:
:connect byok baseten moonshot-ai/Kimi-K3
To check whether your catalogue has caught up:
superqode models --provider baseten --refresh
Or skip models.dev entirely and ask the provider directly:
superqode models --provider baseten --live
The --live flag queries the provider’s own /v1/models endpoint, which is the freshest source available. If K3 appears there but not in the picker, that is the catalogue lag and nothing more. It resolves on its own.
We deliberately did not work around this by hardcoding K3 into the model list. Doing so would mean maintaining a parallel catalogue by hand and keeping its pricing accurate, which is the exact problem models.dev exists to solve.
Watch It Action
Self-hosting
vLLM and SGLang both had day zero support, and the Kimi team contributed a KDA prefix caching implementation upstream to vLLM ahead of the release, so long context serving is efficient from the start. Be realistic about the hardware. The MXFP4 weights are roughly 594GB before you account for KV cache and runtime overhead, and Moonshot recommends supernode deployments of 64 accelerators or more. This is a datacenter exercise. Anyone suggesting you can run K3 on a workstation is describing a different model. If you are serving it yourself, point SuperQode at your endpoint the same way you would any OpenAI compatible server:
export VLLM_BASE_URL=http://your-host:8000/v1
:connect byok vllm moonshotai/Kimi-K3-MXFP4
Getting it
uv tool update superqode
Or if you are starting fresh:
curl -fsSL https://super-agentic.ai/superqode.sh | sh
Version 0.2.56 or later has the routing and a fix for connecting to models whose ids contain a slash, which covers most open weight models rather than just this one.