Kimi K3 runs through OpenCode with paid Kimi Code API key

• Kimi K3 has a practical OpenCode path today, with levelsio's setup using a paid Kimi account, a Kimi Code API key, /connect, and BUILD mode.
• The router path was shaky on launch day, since levelsio's OpenCode report hit “rate limited upstream” through OpenRouter and LLMJunky's OpenRouter test hit limits every 2 to 3 tool calls.
• The paid Kimi Code plan still had hard ceilings: LLMJunky's quota post hit a 5-hour quota before finishing one browser-game prompt, while LLMJunky's terminal screenshot showed a 403 at 101K tokens in a 256K context.
• The creator demos are strongest in UI and spatial code, from levelsio's macOS-in-browser demo to stevibe's iPhone canvas test, but LLMJunky's Rocket League test found weaker physics and playability.
• K3 benchmarks looked near-frontier rather than cleanly dominant, with LLMJunky's benchmark read putting it second or first on several coding charts while warning that “better than Fable” was overhype.

Moonshot's Kimi K3 docs call it a 2.8T-parameter model with a 1M-token context window, native vision, always-on max thinking, and open weights promised by July 27. The official Kimi OpenCode guide now walks through selecting kimi-k3 in OpenCode 1.18.3, while OpenRouter's Kimi K3 page warns that upstream capacity is limited and the model may return frequent 429s. The weird creator hook is that the same model powering leaderboard arguments also got dropped into a Windows XP messenger-emulator project.

levelsio's repeatable path had four steps:

1. Ask Codex or Claude Code to install OpenCode.
2. Create a Kimi account, pay for a $19/mo membership, and get an API key.
3. Run OpenCode, use /connect, choose Kimi Code, and paste the key.
4. Switch to BUILD mode with Shift+Tab, with bypass permissions configured in /settings.

OpenCode's provider docs describe /connect as the general path for adding provider API keys, storing credentials in ~/.local/share/opencode/auth.json. Moonshot's own OpenCode guide uses opencode auth login for Moonshot AI, then /models to select Kimi K3 and /variants to select max, noting that kimi-k3 currently supports only max thinking effort.

Kimi's pricing page lists K3 at $0.30 per 1M cached input tokens, $3 per 1M uncached input tokens, and $15 per 1M output tokens. Its rate-limit docs tie API limits to cumulative recharge amount and warn that cluster load can trigger temporary limit adjustments.

levelsio's starting problem was a retro-computing build, not a normal SaaS app. He said Fable and Opus were blocking him while he tried to install Yahoo! Messenger from 2003 inside a Windows XP browser emulator.

He had already applied to Anthropic's Cyber Verification Program after Opus 4.8 flagged the work as a cybersecurity topic. The screenshot says the program unlocks “fewer refusals and improved responses” for the approved use case inside an organization.

The Kimi run was working inside OpenCode 1.18.3 against a “Multi-messenger AI bot auto-login system.” The screenshot shows K3 using grep and logs around msn_ns.py, xpmsn-server.js, local Escargot routing, and an always-allow permission prompt for /opt/escargot/*.

The todo list had already checked off lobby sharding, AIM/Yahoo guest-wrapper tooling, and MSN auto-login. The remaining work included ICQ TCP OSCAR replacement, UOL Messenger server routing, an NSFW block across MSN/AIM/ICQ/Yahoo/UOL, and rate-limit tuning for 10K parallel users.

LLMJunky said Kimi K3 on OpenRouter was getting rate-limited every 2 to 3 tool calls. levelsio hit the same class of failure before going direct to Kimi, saying OpenRouter immediately returned “rate limited upstream” in his OpenCode report.

OpenRouter's own Kimi K3 page says the model is hosted by one provider, Moonshot AI, so OpenRouter forwards every request directly rather than routing around capacity. The same page lists $3 input, $15 output, $0.30 cache read, 7.92s latency, and 20 tokens per second for the Moonshot route.

LLMJunky hit the 5-hour quota on the $19 plan about 85% of the way through one browser-game build. The console screenshot attached to the post shows weekly usage at 20%, rate-limit details at 100%, “Moderato Member,” and K3 as the flagship model.

The terminal screenshot adds the sharper number: 101K tokens, 40% of a 256K context window, and a 403 usage-limit error. In a follow-up, LLMJunky put it as 100K tokens consuming 20% of the weekly allotment.

The product banner in the Kimi console says K3 supports up to 1M context tokens and is optimized for coding, 3D gaming, and complex knowledge tasks. That did not make the $19 coding workflow feel unmetered.

levelsio showed “MacOS 27 in the browser” built by Kimi K3. The attached video shows a browser-hosted desktop with resizable windows and app launching.

stevibe tested K3 against GPT-5.6 Sol with a single-file HTML canvas prompt: a rotating iPhone disassembling into an exploded view, pausing, and reassembling with Apple-style 3D perspective. He said neither output was perfect, but K3 had the cleaner exploded view.

minchoi collected a broader K3 build reel:

1. A Game Boy Advance emulator, from minchoi's first example.
2. Creative visuals and functions, from minchoi's second example.
3. A textured, lit 3D scene, from minchoi's third example.
4. A CS:GO x Portal clone in three shots with 600K tokens, from minchoi's fourth example.
5. A BridgeBench Horror House comparison against Fable 5, from minchoi's fifth example.
6. An Animal Crossing clone, from minchoi's sixth example.
7. A macOS-style UI in 15 minutes from one prompt, from minchoi's seventh example.
8. Kernel-stack rewriting and optimization, from minchoi's eighth example.
9. A wuxia-style RPG, from minchoi's ninth example.
10. A cyberpunk web-swinging game, from minchoi's tenth example.

The caveat came from the same thread: “many game examples, not so much anything else,” minchoi's reply said.

Moonshot's Kimi K3 docs position K3 for long-horizon coding, knowledge work, reasoning, game development, frontend engineering, CAD, and screenshot-driven workflows. The coding chart in LLMJunky's post gives the useful spread:

• DeepSWE: Kimi K3 67.5, behind GPT-5.6 Sol at 73.0 and Fable 5 at 70.0.
• Terminal Bench 2.1: Kimi K3 88.3, just behind GPT-5.6 Sol at 88.8.
• FrontierSWE: Kimi K3 81.2, behind Fable 5 at 86.6 and ahead of GPT-5.6 Sol at 71.3.
• Program Bench: Kimi K3 77.8, narrowly ahead of GPT-5.6 Sol at 77.6 and Fable 5 at 76.8.
• Kimi Code Bench 2.0: Kimi K3 72.9, behind Fable 5 at 76.9.
• SWE Marathon: Kimi K3 42.0, ahead of Opus 4.8 at 40.0 and GPT-5.6 Sol at 39.0.

LLMJunky's conclusion was near-parity, not a clean closed-model wipeout. In a later reply, he said model choice still shows up most clearly on long-horizon tasks and long context.

Open weights also did not mean desktop-local access on day one. stevibe's taxonomy split models into local, open, and closed; LLMJunky's hardware reply said even “only” 1.7TB of VRAM would mean several hundred thousand dollars.

The cost story got less flattering when illscience measured full tasks instead of token stickers. His eval asked 10 frontier models to judge 40 claims against a roughly 3,000-claim knowledge base, then measured per-task cost and seconds per claim.

Kimi K3 landed at $440 per 1,000 claims and 204.2 seconds per claim. In the same table, Fable 5 was $453 and 54.7 seconds, while GPT-5.6 Terra Medium was $72 and 12.1 seconds.

The claim was not that K3 was bad. illscience's follow-up called it “a fabulous model with an incremental cost advantage,” but said per-token pricing misrepresented per-task cost.

fabianstelzer had the same open question before testing Hermes on K3: his post asked whether the pricing advantage would get eaten by greedy reasoning and latency.