Kimi K3: an open-source Fable? The long-running agent model worth testing
Kimi K3 is exactly the kind of release that makes people reach for benchmark tables. A Chinese model catches up with, or in some cases beats, Western models; markets react; social media asks whether this is another DeepSeek moment. That is interesting, but for a company adopting AI in real processes, the better question is simpler: where would this model actually belong?
The YouTube signal appeared on July 17, 2026 from two watched channels. Marek Bartos highlighted Kimi K3 as a cheaper, open, and very capable model. Zaujaloma AI included it among the main updates alongside Claude and ChatGPT. The hard facts, however, come from Kimi/Moonshot primary sources.
Moonshot AI's official blog says Kimi K3 is a 2.8-trillion-parameter model built on Kimi Delta Attention and Attention Residuals, with native vision and a 1M-token context window. Moonshot did release the full weights on July 27, 2026; they are available through the official repository and Hugging Face. That makes K3 a real candidate for self-hosting, not an automatically ready self-hosting option for every company.
Update — July 29, 2026: the weights are out; the operational reality remains
On July 27, Moonshot published the official Kimi K3 repository, technical report, and full weights on Hugging Face. The previous statement that the release was still pending is no longer true.
That changes the options for teams that want direct control of the model: they can assess the licence, inference stack, and behaviour outside a vendor API. It does not mean K3 runs "locally" on an ordinary company server. It is a 2.8T MoE model; self-hosting is a project for a team with suitable GPU capacity, serving, observability, security, and budget. For most n8n/Make workflows, an API or a provider hosting the model will remain more practical.
"Open-source Fable" is useful as a direction, not a conclusion. K3 targets the same class of long-running coding and knowledge-work agents as Claude Fable 5 and GPT‑5.6 Sol, but open weights alone do not equal output quality, cost per approved outcome, or enterprise readiness. Kimi itself says its overall performance still trails Fable 5 and Sol.
The practical next step is not a bulk migration: take one long-running but non-critical evaluation — contract extraction with JSON-schema validation, an internal research memo, or a coding task in an isolated repository — and compare quality, latency, infrastructure cost, and human-review needs against the current API model.
Requesty and OpenRouter: a practical API path, not automatic EU residency
Kimi K3 is now also available through Requesty as moonshot/kimi-k3 and OpenRouter as moonshotai/kimi-k3. Both gateways expose an OpenAI-compatible API, so for n8n, Make, or an internal agent this is a base-URL, API-key, and model-ID change rather than an integration rewrite. At the time of this update, both list $3 per 1M input and $15 per 1M output tokens; Requesty also lists $0.30 per 1M cache-read tokens and says it adds no markup. That is a sensible route for putting K3 behind an existing model router, measuring cost per approved outcome, and avoiding a self-hosted inference stack.
For European data, however, separate the gateway from the full data path. Requesty offers an EU gateway in Frankfurt with zero retention and a DPA, but its K3 model page identifies Moonshot as upstream, the provider location as China, and data retention as Yes. That alone does not make K3 an EU-resident or GDPR-ready option for personal, customer, or otherwise sensitive data. The EU endpoint can still be a useful control layer — for key management, audit, PII scrubbing, and policy — but before deploying K3, obtain written confirmation of the actual inference region, subprocessors, upstream retention, and DPA for the specific data flow.
OpenRouter is especially useful for quickly comparing providers, pricing, and routing. Its unified API does not replace a security review either: for sensitive workflows, pin the exact provider and region, disable unverified fallbacks, and log which endpoint actually handled the run. Both gateways are practical for non-critical evaluations, public data, or anonymised classification. For invoices, CRM, support history, or contracts, verify the whole data path first — not merely the gateway’s location.
What the verifiable benchmarks actually say
Only results with a stated setup are worth comparing — and even those are not clean apples-to-apples comparisons. For DeepSWE v1.1, Kimi reports 67.3% using a mini-SWE-agent harness; OpenAI's table reports 72.7% for GPT‑5.6 Sol and 69.7% for Claude Fable 5. For BrowseComp, Kimi reports 90.4% with a 1M-token context and no context management; OpenAI reports the same 90.4% for Sol and 84.3% for Fable 5.
These values are a signal, not a purchase decision. Harnesses differ: Kimi describes KimiCode or Claude Code, while Sol is often run through Codex; some Kimi comparisons ran on H20 rather than reference H100 hardware, and Kimi notes that Fable used fallbacks on 35% of tasks in one SWE Marathon run. That means the numbers do not honestly support either "Kimi beats Fable" or "Sol always wins." They do support putting K3 on the same pilot shortlist for long-horizon agent work.
In practice, treat K3 as a candidate open specialist model, not as a reason to switch the whole stack. Use the same task, repository or document set, harness, cost cap, and human review. Only that internal evaluation will show whether an open alternative to Fable makes sense for your team.
Where K3 runs and what it costs
Today, you run it as a service, not on your own GPUs. K3 is available on Kimi.com, in Kimi Work, in the terminal and IDE through Kimi Code, and through the Kimi API as kimi-k3. The API is OpenAI-compatible Chat Completions and supports JSON Schema; Kimi also offers Enterprise for team management. Moonshot plans to release full weights by July 27, 2026. Until then, "open-source Fable" does not mean self-hosting: production use means choosing a vendor API and addressing the usual region, DPA, retention, and source-data access questions.
| Model | Where to run it today | API price per 1M tokens |
|---|---|---|
| Kimi K3 | Kimi API, Kimi Code, Kimi Work/Kimi.com | $3 input, $0.30 cached input, $15 output |
| Claude Fable 5 | Claude Platform/API, Claude.ai, Claude Code, and Claude Cowork; availability is also being restored on AWS, Google Cloud, and Microsoft Foundry | $10 input, $50 output |
| GPT‑5.6 Sol | OpenAI API, ChatGPT, ChatGPT Work, and Codex | $5 input, $0.50 cached input, $30 output |
The useful lens is the cost of a real run, not one token. At 1M uncached input tokens and 1M output tokens, list pricing puts K3 at $18, Sol at $35, and Fable at $60. If K3 input actually hits cache, the same volume is roughly $15.30; Sol is $30.50. Fable's cited launch announcement gives input and output pricing, but not a comparable cached-input price, so it is intentionally not inferred here.
That does not promise that K3 is always cheapest. Longer reasoning, repeated tool calls, fallbacks, retries, and a weaker first result can easily reverse the cost. For n8n, Make, or an internal agent, measure cost per approved outcome instead: a corrected invoice, a valid CRM record, a PR ready for review, or a verified decision memo.
What matters
K3 is not presented as only a chat model. Kimi positions it for long-horizon coding, knowledge work, and agentic workflows. In practice, that gives it three layers.
The first layer is Kimi Code. The official docs list the k3 model ID, CLI and IDE usage, plan limits, and up to 1M context on higher plans. For engineering teams, that matters because the model is not only an API endpoint. It is meant to operate inside long repository work.
The second layer is Kimi Work and knowledge work. Kimi talks about documents, presentations, dashboards, research reports, and interactive visualizations. This is the same broad direction as ChatGPT Work, Claude Cowork, and other work-oriented AI layers: the model does not only answer a question, it produces an artifact.
The third layer is the API. Kimi API uses an OpenAI-compatible Chat Completions interface, the kimi-k3 model, automatic context caching, and structured outputs through JSON Schema. The official blog lists pricing at $0.30 per million cache-hit input tokens, $3 per million cache-miss input tokens, and $15 per million output tokens. That is not a cheap filter for every tiny call, but it may be an interesting worker for long tasks where cache helps and a stronger model saves human time.
Do not make it the default model
The biggest mistake would be to read the benchmark table and switch everything to Kimi K3.
Kimi itself says the user experience still trails the strongest proprietary models. The docs also list practical constraints: K3 always reasons, API reasoning effort currently defaults to max, multi-turn tool calls need the complete assistant message returned to the next request, and switching models mid-session can hurt quality and cost because cache no longer applies.
Those are the details that decide whether automation works. A model can be excellent for one long task and still be a poor default for thousands of small requests. It can be strong for agentic coding and too expensive for support classification. It can have 1M context, but if you dump entire CRM exports into it without a strategy, you mainly produce a token bill.
Where I would test it
The first candidate is a long-running coding agent. Not a quick typo fix, but a task such as: inspect a larger repository, find relationships, propose a change, write tests, run them, read failures, and iterate. That is where Kimi K3 should be compared against what the team already uses: Claude Code, Codex, Cursor, GLM-5.2, or an internal agent stack.
The second candidate is document extraction with large context. Think due diligence folders, technical documentation, public tenders, contracts, or support knowledge bases. K3 should not just summarize documents. It should produce structured output, citations, uncertainty, and a list of items a human must verify.
The third candidate is an internal research agent. Market monitoring, vendor tracking, legislation, competitors, or technical release notes are good examples. The agent can process a large source set, build a dashboard, and draft a decision memo. But there still needs to be a rule for when AI output is enough and when a primary source or human review is mandatory.
The fourth candidate is multimodal output review. Kimi mentions vision-in-the-loop for frontend, games, and CAD. For web apps, that can reduce manual checking if it is paired with Playwright, screenshots, and clear acceptance criteria.
How I would route it
I would not put Kimi K3 into a company model router as the only model. I would give it a specialist role.
The cheap layer stays responsible for classification, normalization, simple field extraction, email drafts, and triage. A cheaper and faster model often wins there because request volume is high and rules can catch many errors.
The middle layer handles structured output and everyday knowledge work: CRM enrichment, invoices, support, content pipelines, and internal reports. The choice depends on accuracy, latency, cost, and format reliability.
I would test Kimi K3 in the specialist layer: long coding agents, large document contexts, research workflows, visual review, and tasks where an agent runs for tens of minutes and must keep a plan. In those cases, a more expensive output token can still be cheaper than an hour of senior human time.
Above that, I would keep an audit layer. Every model in the router should log sources, model version, cost, output, uncertainty, human approval, and post-deployment result. Without that, a model router becomes a more complicated lottery.
What to measure
Start with three test scenarios and compare them with the current workflow.
First: agentic coding. The metrics are not only benchmark scores. Measure successful PRs, time to merge, review comments, broken tests, token cost, and how often a human had to stop the agent.
Second: document extraction. Measure field accuracy, citations, corrected conclusions, uncertainty handling, and cost per approved document. For invoices, contracts, or RFPs, audit matters more than a polished summary.
Third: research memos. Give the agent a source bundle and ask it to prepare a decision for the CTO or leadership. Measure how many claims have primary sources, how many sources were misunderstood, how quickly a human can verify the memo, and which recommendations changed a decision.
The takeaway
Kimi K3 deserves a standalone look because it combines several trends at once: a very large open model, long context, agentic coding, knowledge work, vision, and API pricing that may work in a specialist layer.
It is not a reason to throw away the current stack. Full weights are still planned rather than available, benchmarks are vendor benchmarks with different harnesses, and real cost depends on reasoning output, cache hit rate, and session length.
So the practical question is not: "Is Kimi K3 better than Claude or GPT?" A better question is: "Which three tasks are long, expensive, and auditable enough that a specialist model is worth testing?" That is where Kimi K3 belongs in evaluation.
Sources: YouTube signals from Marek Bartos Chinese AI model Kimi K3 and Zaujaloma AI Chinese AI catches up with Fable5 and GPT, Kimi/Moonshot [Kimi K3: Open Frontier Intelligence], Anthropic Redeploying Claude Fable 5, OpenAI GPT-5.6: Frontier intelligence that scales with your ambition, and Anthropic Claude Fable 5 and Claude Mythos 5(https://www.kimi.com/blog/kimi-k3), Kimi API docs Kimi K3 quickstart, Kimi Code docs Model Configuration, and Cloudflare Workers AI docs Kimi K3 model page.