Moonshot announced Verda — a European full-stack AI cloud — as an inference partner for Kimi K3.1 Pro, their 3T-class open-weight model with a 1-million-token context window. Verda put Verda Inference into preview on 4 November with day-0 access to it, served from their own European data centres on an SGLang-based stack.
Good news if you want EU-hosted Kimi. But the more useful fact for anyone already building is that K3.1 Pro has been answering on Antbase for a while, across fifteen catalogued routes, and you do not have to care which one serves you.
What it costs, by route
Same weights, same model, same model string. Per 1M tokens, input / output, as catalogued today:
- •DeepInfra, OpenRouter, Phala — $2.00 / $10.00
- •Nebius, SiliconFlow, Baseten, Vercel, Akash, AskCodi — $20.00 / $100.00
- •Moonshot, direct — $13.20 / $32.00
- •Vercel and AskCodi also list a "highspeed" variant at $40.00 / $200.00
Read the first and third lines together. Going straight to Moonshot costs 6.6x more on input and 3.2x more on output than the cheapest healthy route for the same model. That is not a criticism of Moonshot — first-party inference is priced for first-party support — it is just the number, and it is the reason a routing layer pays for itself on exactly one model.
Verified, not assumed
A catalogue row is a claim, not a capability. The hard-won lesson in this codebase is that a model id can look right, resolve somewhere unintended, and bill nothing while appearing to work — so every route gets a real request before it is believed. Three of the cheap ones, asked for the capital of France, with the response and round trip as measured:
openrouter HTTP 200 1253ms "Paris" 133 tokens
phala HTTP 200 1584ms "Paris" 124 tokens
deepinfra HTTP 200 53267ms "Paris" 141 tokensNote the token counts. A four-character answer cost well over a hundred tokens, because K3.1 Pro is a thinking model and the reasoning is billed. An earlier run of the same test with `max_tokens: 5` returned empty strings from every provider — not a failure, just the entire budget consumed before the model reached its answer. If you cap output tightly on a reasoning model you will get nothing and it will look like an outage.
DeepInfra's 53 seconds was almost certainly a cold start on a 3T-class model rather than steady-state latency, and it is precisely the case failover exists for: a route that is technically healthy but too slow for your request is not a route you want to wait on.
How to call it
curl https://antbase.ai/v1/chat/completions \
-H "authorization: Bearer $ANTBASE_KEY" \
-H "content-type: application/json" \
-d '{
"model": "moonshotai/kimi-k3.1-pro",
"messages": [{"role": "user", "content": "Summarise this contract."}],
"max_tokens": 2000
}'Give `max_tokens` real headroom, as above. If you want a specific provider rather than the cheapest healthy one, prefix the id — `deepinfra/moonshotai/Kimi-K3.1-Pro`, `phala/moonshotai/kimi-k3.1-pro`, `baseten/moonshotai/Kimi-K3.1-Pro`. Pinning is the right call when you are under audit and need the route to be reproducible; leave it unpinned when you would rather have the cheapest one that is up.
Why fifteen routes beats one good route
Because routes die, and they die without telling you. Of those fifteen, several are not serving right now — two providers are out of credit on our side, one has a retired credential, and two rows are marked inactive. None of that reached a single user, because the model string does not name a provider and the orchestrator picks from whatever is healthy.
That is the whole argument for this shape of infrastructure, and it is worth stating without varnish: the value is not that we found you a cheaper Kimi. It is that when the cheap one breaks at 3am you do not find out from your users.
On Verda specifically
Antbase does not route to Verda today — it is not in the provider registry. Verda Inference is days old and in preview, so that is a statement of timing rather than a judgement.
It is worth watching for one specific reason: data residency. If you are running finance or health workloads under EU rules, where the inference physically happens is a compliance question, not a performance one, and "the cheapest healthy route" is the wrong default when one of the healthy routes is on the wrong continent. A European-hosted Kimi with an OpenAI-compatible API is a genuinely useful thing to be able to pin an allowlist to. Verda's published preview figures — a median 148ms time to first token, and over 99% of reusable agent context served from cache in their own coding-agent testing — are their numbers from their own internal testing, not something measured here.
When it is wired up it will be announced with its own verification table, same as every other route.
