Why and how I switched from Claude to Kimi: field report of a hybrid setup

Here is my situation, with my real invoices: three months, two providers, and a switch. The question was never "is Kimi better than Claude", but: is it reasonable to bet everything on a single provider — and to fund caps that cut work off mid-run?

The real argument is not the price — even if €385.96 over two months at Anthropic versus a single €204 subscription does count. The real argument is the recurring work interruptions: the Claude caps cut my runs mid-work, and every API top-up bought the end of the month, not the end of the run. What I did: cancel the Claude subscription, move Kimi to Ultra, and build a hybrid stack that no longer depends on any single provider. The direction is deliberate: one readable subscription + local — and move the local agentic layer to Kimi as soon as it is technically possible, for the swarm's coherence: same language, same mechanics everywhere. Here is the honest assessment, including what I lost.

1. Why: the reasons, in the order they actually matter

1.1 Hybrid philosophy and sovereignty

This is my real reason number one, so I say it first. Anthropic sells access; Kimi sells an exit door. Kimi K3.1 Pro is the only frontier model on the market to announce the release of its open weights (expected around 4 November 2026), to expose an endpoint compatible with the Anthropic API (§1.3), and to show a readable price. Concretely: an SMB will never be able to host Claude on its own machines — that is structural, not a budget question. With Kimi the door stays open: the day the weights ship, self-hosting becomes possible, and in the meantime local (§2) takes over whenever a task does not need the frontier. For someone whose position is "a sovereign agent swarm, at home", a provider that leaves an exit door matters more than one more benchmark.

1.2 Price — without exaggerating

K3.1 Pro is not cheaper than Sonnet: it is the same price. What is true: announced Opus-level performance at Sonnet's price, with a 1M-token context native in the API. And on the subscription side, my invoices in the opening table speak for themselves. The official prices are published on the Moonshot platform pricing page; my figures above are my observations of the day, not a source.

1.3 Compatibility: the Anthropic endpoint

Kimi exposes an endpoint compatible with the Anthropic API: https://api.kimi.com/coding/ for the Kimi Code subscription (the key is created in the Kimi Code Console), and https://api.moonshot.ai/anthropic for the pay-as-you-go platform, per token. Concrete consequence: my existing tools (Claude Code first) switch without changing the chain. The migration costs an hour, not a month.

1.4 The heart's choice, and the grail I cannot test

Full transparency: my heart's choice was Qwen. DeepSeek, I am not a user of it. Kimi won because it had already proven itself on my machines with K2.7 Coder — and because no other frontier opens the same door. One honest impossibility remains: the real grail would be all-Kimi hybrid agentics — the K3.1 weights at home, the cloud as backup. Not on my rig: the weights need roughly 1.4 TB of aggregate GPU memory; mine has 32 GB. The exit door exists; it is simply too heavy for me today. Every situation is a hell of trade-offs — the only question is choosing the ones you can live with.

2. The hybrid stack: one subscription, everything else metered

Golden rule: one subscription (Kimi). Everything else is pay-per-token or local. If Kimi ever falls short on a task, I will pay for that task per token elsewhere — not a second subscription. That is precisely the "promise → cap → disappointment" pattern I am leaving.

Routing matrix

⚠️ OpenRouter pitfalls: tight rate limits on the free models, models that change without notice, and your data transiting through a third intermediary. Never for client code or anything sensitive.

The hardware that runs the local side

My rig: Ryzen 7 7800X3D, 64 GB DDR5, RTX 5080 16 GB (PCIe x16) + RTX 4070 Ti SUPER 16 GB as an eGPU (x4 link, so ~32 GB of VRAM in total).

Rule number one of heterogeneous multi-GPU: one model = one GPU. The eGPU's x4 link saturates under tensor-split between the two cards, so each model is assigned whole to one card, with no inter-GPU traffic. I do not enforce this by hand: turnstile, my deterministic GPU allocator, enforces it — a clean queue, and live checks that the model answering is the one that was allocated. In an architecture where a software router picks the backend, that last guarantee is not a detail.

These measurements are taken in real production conditions — the CPU serves two other models during the measurements — not in an empty lab. That is deliberate: a lab figure tells you nothing about what you will get at home.

Mind the KV cache: a long context eats VRAM quickly when running locally. That is a feature of the architecture: anything beyond ~16–32k of context is routed to Kimi (1M native) — not to a more aggressive quant.

Power supply note: 5080 (~360 W) + 4070 Ti SUPER (~285 W) + 7800X3D → plan for a 1000 W PSU (the eGPU has its own power brick).

Minimum viable config for you: a single 16 GB GPU is enough for a 9B at a high quant or a 27B at IQ3; 8 GB → 7–8B. Whatever is missing locally is routed to the API.

The laptop as control plane: "light brain, heavy muscles"

Third element of the architecture: a Ryzen 7 laptop with 64 GB of RAM that pilots everything — and it may be the most useful part, because it reverses the usual "everything on all the time" logic. A rig with a 5080 + 4070 Ti SUPER draws ~100–150 W at idle (about €10–15/month doing nothing, plus noise and wear); a laptop draws 15–35 W. So the laptop stays on permanently and the rig only powers up for compute.

Principle: the laptop receives the requests, applies the routing matrix from §2, and calls the right backend — itself (light tasks), the rig (woken by Wake-on-LAN if needed), or the remote APIs. Concretely: n8n on the laptop → HTTP node → http://rig:8080/v1/chat/completions.

Documented pitfalls:

• Token streaming hates WiFi (jitter) — cable whatever can be cabled; remotely, Tailscale/WireGuard, never expose llama.cpp ports directly on the Internet.
• Wake-on-LAN must be configured in the BIOS + the rig's network card, otherwise "piloting" becomes "getting up to press the button".
• Single point of failure: there used to be one — the laptop. The answer is called mindhub: a small low-power node, always on, holding the swarm's minimal control plane (the rule: whatever can be driven from the laptop must also be drivable from mindhub). The laptop can die, the rig can sleep: the swarm stays reachable and steerable from the pocket, without waking the power. The daily n8n export stays in place — restoring a node must remain a matter of minutes.

3. How: the concrete migration

3.1 Switching Claude Code to Kimi

The official procedure is the one in the Kimi Code documentation for third-party agents. Three steps, in order.

Step 1 — the key. In the Kimi Code Console (the subscription, not the per-token platform): "Create API Key", name it, copy it — it is no longer readable once the dialog closes. The pay-as-you-go platform key (platform.moonshot.ai, endpoint https://api.moonshot.ai/anthropic) remains a per-token fallback option, outside the subscription.

Step 2 — the official script, before the first launch. After installing Claude Code, do not start it right away: this script enables third-party model support in ~/.claude.json (penguinModeOrgEnabled + hasCompletedOnboarding) and removes the old model variables from any env block in ~/.claude/settings.json — a stale configuration there would override the new one:

node --eval "
const fs = require('fs');
const os = require('os');
const path = require('path');

// enable third party model support and fast mode
const claudeJsonFilePath = path.join(os.homedir(), '.claude.json');
if (fs.existsSync(claudeJsonFilePath)) {
    const content = JSON.parse(fs.readFileSync(claudeJsonFilePath, 'utf-8'));
    fs.writeFileSync(claudeJsonFilePath, JSON.stringify({ ...content, penguinModeOrgEnabled: true, hasCompletedOnboarding: true }, null, 2), 'utf-8');
} else {
    fs.writeFileSync(claudeJsonFilePath, JSON.stringify({ penguinModeOrgEnabled: true, hasCompletedOnboarding: true }), 'utf-8');
}

// delete old model id
const claudeSettingsJsonFilePath = path.join(os.homedir(), '.claude', 'settings.json');
if (fs.existsSync(claudeSettingsJsonFilePath)) {
    const content = JSON.parse(fs.readFileSync(claudeSettingsJsonFilePath, 'utf-8'));
    if (typeof content === 'object' && typeof content.env === 'object') {
        for (const element of [
            'ANTHROPIC_MODEL',
            'ANTHROPIC_SMALL_FAST_MODEL',
            'CLAUDE_CODE_SUBAGENT_MODEL',
            'ANTHROPIC_DEFAULT_FABLE_MODEL',
            'ANTHROPIC_DEFAULT_FABLE_MODEL_NAME',
            'ANTHROPIC_DEFAULT_OPUS_MODEL',
            'ANTHROPIC_DEFAULT_OPUS_MODEL_NAME',
            'ANTHROPIC_DEFAULT_SONNET_MODEL',
            'ANTHROPIC_DEFAULT_SONNET_MODEL_NAME',
            'ANTHROPIC_DEFAULT_HAIKU_MODEL',
            'ANTHROPIC_DEFAULT_HAIKU_MODEL_NAME',
        ]) {
            delete content.env[element];
        }
        fs.writeFileSync(claudeSettingsJsonFilePath, JSON.stringify(content, null, 2), 'utf-8');
    }
}
"

Step 3 — the official configuration: exported environment variables, not an env block in settings.json. Depending on your plan, the available models and context window change:

The "K3 with 1M context" configuration (Allegretto and above):

export ANTHROPIC_BASE_URL=https://api.kimi.com/coding/
export ANTHROPIC_API_KEY=YourApiKey

export ANTHROPIC_MODEL="k3[1m]"
export ANTHROPIC_DEFAULT_FABLE_MODEL=$ANTHROPIC_MODEL
export ANTHROPIC_DEFAULT_OPUS_MODEL=$ANTHROPIC_MODEL
export ANTHROPIC_DEFAULT_SONNET_MODEL=$ANTHROPIC_MODEL
export ANTHROPIC_DEFAULT_HAIKU_MODEL=$ANTHROPIC_MODEL
export CLAUDE_CODE_SUBAGENT_MODEL=$ANTHROPIC_MODEL
export CLAUDE_CODE_EFFORT_LEVEL=high
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=1048576
export CLAUDE_CODE_MAX_CONTEXT_TOKENS=1048576

claude

The "k3[1m]" form exists only there: as a Claude Code environment variable value, quoted, to unlock the 1M-token window. Everywhere else — API requests, the "Model ID" field of other tools — the identifier is k3. If your plan only gives K3 at 256k, use ANTHROPIC_MODEL=k3 and set CLAUDE_CODE_AUTO_COMPACT_WINDOW and CLAUDE_CODE_MAX_CONTEXT_TOKENS to 262144.

3.2 The pitfalls (what cost me time, so it does not cost you yours)

1. A single authentication variable: the official documentation only uses ANTHROPIC_API_KEY. Do not mix it with older variables (ANTHROPIC_AUTH_TOKEN, leftovers of an env block) — that is what the step 2 script is for.
2. Turning "thinking" off reroutes K3 to K2.6: keep reasoning enabled to stay on K3 / K2.7. Effort is set in-session with /effort, without an environment variable. Level mapping: low → low, medium and high → high, xhigh and max → max (unset: high).
3. Every unconfigured tier variable = a silent failure of the matching scenario (subagents, summary, etc.). Everything must be mapped.
4. Test before launching: a curl against the endpoint validates the key in 10 seconds; then /status in Claude Code must show Base URL https://api.kimi.com/coding/. The /model menu and /status may keep showing Claude model names: that is normal, the calls do go to the Kimi Code API.
5. If a 400 persists: add ENABLE_TOOL_SEARCH=false.
6. EU vs China keys: platform.kimi.ai (international) and platform.kimi.com (China) are two silos — a key from one returns 401 on the other.

3.3 The swarm: n8n as conductor

Above Claude Code, the swarm runs on n8n, on the laptop: each workflow reads the routing matrix from §2, delegates to the right backend — Kimi, a local model on the rig, or LFM3 — and logs cost and latency per task. That log is what keeps the matrix honest: a route that costs too much or fails too often shows up, and it changes. The workflow details belong to the "your agent stack" series; here, the only thing to remember is that the router is a deterministic tool, not an agent deciding on a hunch.

4. What I measure — and what I refuse to publish

I will not publish an A/B Claude vs Kimi table with quality scores: I did not run that benchmark, and an invented table would be worth less than any blogger's benchmark. What I actually measure:

• Work continuity. In September and October, the Claude caps cut runs mid-work, repeatedly — the €108.76 then €145.20 of top-ups are there to prove it. In November, a single interruption on the Kimi side (see §5). That is my criterion: the number of times work stops without me deciding it.
• The real cost, invoice by invoice: the opening table.
• Local throughput, measured in production: the table in §2.
• Local model quality, produced by fh-bench — programmatically judged tasks, a capability map — not by a user's impression.

5. What I lost (as important as the rest)

• The cap exists at Kimi too. On Ultra, the cycle's monthly limit was reached mid-session — a blunt 429, lived on 3 November 2026. The difference is not "cap vs no cap", it is frequency and readability: a single tier to watch instead of a subscription plus top-ups.
• Briefing is less forgiving. Poorly briefed, K3 drifts into verbosity; it takes strict system prompts (the Disler method: explicit communication contracts, positive and negative patterns) where Claude holds the style more naturally. The framing work does not disappear, it moves into the prompts.
• The third-party ecosystem is poorer. Less ready-made tooling, and the Anthropic-compatible endpoint had to be wired by hand into every tool in the chain — the procedure in §3 exists because it was written nowhere for my case.

6. Who it is for (and who it is not for)

• Light Claude subscriber, occasional use → do not move. The migration only makes sense past a certain volume — my €385.96 over two months is not your reference.
• Heavy API use, long-context needs, a hybrid local/frontier project → the test is worth it. Start with one month in parallel, publish your measurements.

Sources

• Kimi Code, third-party agent configuration (Claude Code) — official documentation
• Moonshot AI, official API pricing
• freedzhost.cloud, the Kimi Code tutorial
• freedzhost.cloud, turnstile, the GPU allocator

Prices observed on 2 November 2026 — prices move fast on both sides. Transparency: no relationship with Moonshot AI; this article is not sponsored; real figures from my invoices. Article under CC BY-SA 4.0, like the rest of freedzhost.cloud.

Found this useful? Tell us what to measure next.