Open Frontier Models Built for Work That Takes Hours
Kimi is Moonshot AI's family of open-weight frontier models, and it is built for a specific shape of work: tasks measured in hours rather than turns. Sustained engineering sessions across large repositories, terminal orchestration, multi-step research, and document-heavy knowledge work. The flagship is the first open model in the trillion-parameter class, with native vision and a million-token context, yet it activates only a small fraction of its parameters on any given token. Unlike most frontier systems, the architecture is published rather than described. On DEVUP AI the family is reachable through the standard OpenAI-compatible endpoint, billed in Algerian Dinar.
Most models are evaluated on how well they answer. Kimi is built around how well a model keeps going. The design target is the long task — an engineering session that spans many files and many failed attempts, a research question that takes twenty tool calls to answer, a document set that has to be read whole before anything sensible can be said about it. Those workloads fail differently from short ones. The failure mode is not a wrong fact; it is losing the thread.
The architecture is unusual in how aggressively it is sparse. The flagship carries parameters in the trillions but activates well under two percent of its expert pool on any given token, routing through a small handful of hundreds of available experts. Attention is a hybrid of a delta-rule linear variant across most of the depth, with gated latent attention inserted where exact retrieval matters. That split is what makes a million-token context tractable rather than nominal. Quantization was applied during training rather than after, so the released weights are the trained ones.
The family handles a distinctive property that catches integrations out. Where most reasoning models expect their thinking trace to be discarded before the next turn, Kimi was trained the other way: the complete assistant message must be sent back, reasoning included. Discarding it does not merely waste earlier work — it removes information the model committed to and expects to still have. Any middleware that normalises assistant messages down to a role and a content string needs an exception before multi-turn behaviour is correct.
Vision is native rather than adapted, with a dedicated encoder inside the model, and it is built to be used in a loop: look at something, compute about it, look again. Where a code execution tool is available alongside the image, results improve substantially — this is a family designed to reason about what it sees, not to describe it.
Weights are published, which is worth stating in a field where most frontier systems are described rather than released. Licences are model-specific rather than uniformly permissive, so check the individual model page before building something commercial. On DEVUP AI the family is reachable through the same OpenAI-compatible endpoint as the rest of the catalogue, with billing in Algerian Dinar and local payment methods.
Available Kimi Models
Deploy and access all published models in this family with unified DZD pricing and zero foreign card requirement.
| Model | Context | DZD in / 1M tokens | DZD out / 1M tokens | Actions |
|---|---|---|---|---|
| Kimi-K3moonshotai/Kimi-K3 | 1M Tokens | 998 | 4988 | View model |
| Kimi-K2.7-Codemoonshotai/Kimi-K2.7-Code | 262K Tokens | 259 | 1225 | View model |
| Kimi-K2.6moonshotai/Kimi-K2.6 | 262K Tokens | 262.5 | 1225 | View model |
Call any Kimi model
Every model on this page uses the same API key and standard OpenAI-compatible endpoint. The example below uses the featured model moonshotai/Kimi-K3.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["DEVUP_API_KEY"],
base_url="https://api.devupai.com/v1"
)
response = client.chat.completions.create(
model="moonshotai/Kimi-K3",
messages=[
{"role": "user", "content": "Hello world!"}
],
max_tokens=1024
)
print(response.choices[0].message.content)import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.DEVUP_API_KEY,
baseURL: "https://api.devupai.com/v1",
});
async function main() {
const response = await client.chat.completions.create({
model: "moonshotai/Kimi-K3",
messages: [
{ role: "user", content: "Hello world!" },
],
max_tokens: 1024,
});
console.log(response.choices[0]?.message?.content);
}
main();curl -X POST "https://api.devupai.com/v1/chat/completions" \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "moonshotai/Kimi-K3",
"messages": [
{ "role": "user", "content": "Hello world!" }
],
"max_tokens": 1024
}'Frequently Asked Questions
Long-horizon work. Sustained engineering sessions across large repositories, terminal orchestration, multi-step research, and document parsing and extraction. Its strongest published results sit in agentic and tool-heavy categories rather than in single-turn question answering. For a short factual query almost any capable model will do; the difference appears on the twentieth tool call.
Almost certainly because the assistant message is being rebuilt rather than passed back whole. Kimi requires the complete assistant message returned by the API — including its reasoning field and any tool calls — to be appended to your messages array as-is. Reconstructing it from the content string alone removes information the model expects to still have. This fails silently: the first turn works, the second is wrong, and no error is raised.
No, never — on this family or any other. Keep the reasoning field separate in both directions. Merging it into content presents the model's private reasoning back to it as though it were the published answer, and on structured-output paths it breaks JSON parsing. Log the reasoning if it is useful for debugging; show the content.
Yes. The default reasoning effort on this family is the deepest setting, which is the reverse of most models. Every request that does not set it explicitly runs at maximum deliberation. Set it deliberately per request: the lowest level for simpler tasks, the highest for long agent runs and hard problems.
Yes. Vision is native, and document parsing and structured extraction are among the family's strongest results — including cases where pages are supplied purely as images with no machine-readable text. If your task requires computing over what was seen rather than just describing it, give the model a code execution tool: the measured improvement is large.
Weights are published, which is uncommon at this scale. Licences are model-specific rather than uniformly permissive, so review the terms on the individual model page before committing to a commercial deployment. Availability on DEVUP AI is separate from the licence — that governs what you may do with the weights, not with the API.
Input tokens grow faster here than on models that discard their reasoning, because the trace travels with the conversation on every turn. That is the trade for the consistency it buys on long tasks. Enable usage reporting on your stream so you can watch it rather than discover it afterwards, and bound every agent loop with an iteration ceiling and a scoped token with a spending limit.
