# How I Cut Kimi K3 Costs in OpenCode > Source: > Published: 2026-07-31 08:04:03+00:00 [Harness Engineering](https://www.dataleadsfuture.com/tag/harness-engineering/) # How I Cut Kimi K3 Costs in OpenCode Better code quality, but spend less money *Disclaimer: This post contains affiliate links. If you click and enroll, I may earn a small commission at no extra cost to you. Thank you for your support!* ## Introduction Last week, I burned through 7 days' worth of quota in a single day while using the `Kimi K3` model on Kimi's Allegreto plan. `Kimi K3` is genuinely great. Its performance is on par with `Claude Fable 5` and `GPT 5.6 SOL` , so I ended up going full throttle with it all day long. But the cost is ridiculous. It runs way higher than `GLM-5.2` , `DeepSeek-V4` , or even `Kimi K2.7` . For someone like me who got spoiled by the cheap API of `DeepSeek-V4` , that was just not okay. So I started optimizing how I use OpenCode. The goal was to do more with the same `Kimi K3` quota while keeping quality about the same. After a few days of work, the results are pretty solid. The Allegreto plan now covers a full week of development for me. No more sitting around two days out of five waiting for the weekly `Kimi K3` quota to reset. If these methods work for me, they should work for you too. So this article is a quick write-up of what I've done, and I hope it helps you lower your `Kimi K3` costs in OpenCode. All the source code mentioned in this article is at the bottom. Feel free to grab it. ## Pick the Right Provider The most fundamental way to cut costs is picking the right provider. The official Coding Plan is the best option. Based on various reports, the third and fourth tiers of the Coding Plan offer dozens of times more value per dollar than the API at the same price. That's a great deal. But if you also need to use the model outside of coding scenarios, or the Coding Plan quota just can not keep up with heavy usage, I recommend using the K3 version hosted on [ Novita.ai](https://fas.st/t/cBJ7iuNS?ref=dataleadsfuture.com). Here's why: - Quality is guaranteed. Novita is one of OpenRouter's top providers. The K3 model there most likely uses `fp8` high-precision quantization, the same as`GLM-5.2` . That keeps the model's reasoning quality solid and output reliable. - The price is low. K3 on Novita is priced roughly the same per million tokens as MoonshotAI, so there's no extra cost. - Enterprise-grade compliance and oversight. When data security matters to you, Novita's API fits that need better. - Centralized budget management. In later sections of this article, I combine sub-agents running different models to handle different tasks. A single shared budget pool lets you use every dollar you have. You won't end up in a situation where one provider runs dry while another still has plenty left. Since I already purchased the official Allegreto plan upfront, I'll use the Coding Plan models as the primary example throughout this article. ## Pick the Right Model and Thinking Level (Variants) ### Pick the right model The Coding Plan gives you access to two models: K2.7 Code and K3. K3 requires Allegreto or above, and only the K3 model supports 1M context length. This week, Kimi also released a K3 model with 256K context, with the model ID `k3-256k` . At the same time, the official docs confirmed that the standard K3 model consumes twice the quota of `k3-256k` . That's probably why I burned through a whole week's quota right out of the gate. Without a second thought, I switched my default model to `k3-256k` . You might wonder: since I'm used to `DeepSeek-V4` 's 1M context, will 256K be enough? I don't think you need to worry too much about that. The 1M context mainly helps your cache hit rate stay high as conversations get longer. But context rot is still a real problem as the context grows. So if you've ever felt like `DeepSeek-V4` gets dumber after a long session, your instinct is right. That's context rot at work. On top of that, we normally use frameworks like OpenSpec for SDD (Spec-Driven Development). All the plans and specs worked out earlier with the model get saved as files on disk. Whether you use the `/compact` command or start a new session, the model reads context from those files. The message history doesn't need to be that long. Then there are situations where you need to scan a large codebase or pull in a lot of information from the web. For those cases, we use sub-agents running in separate sub-sessions to handle the research, then return only the key findings to the main session. That approach cuts down context usage a lot. All things considered, 256K context is plenty for now. For the `Plan` and `Build` agents, just use `k3-256k` directly. If you're using the API from [ Novita.ai](https://fas.st/t/cBJ7iuNS?ref=dataleadsfuture.com), it's even simpler. Just use `Kimi K3` straight up.### Pick the thinking level For a long time, Kimi models felt slow. That's because before K3, Kimi didn't support the `reasoning_effort` parameter. Every call defaulted to maximum thinking, so each request took forever to finish. The K3 release added support for `reasoning_effort` , with three levels: `low` , `high` , and `max` . But when the model first launched last week, only `max` was available. That meant every call generated massive thinking tokens through a long chain-of-thought process, which burned through a huge amount of token budget. Good news: starting this week, both K3 models support `low` and `high` . If you're setting up `Kimi K3` in OpenCode for the first time this week, the default thinking level is `High` . If you configured `Kimi K3` last week, make sure you change the thinking level from `Max` to `High` . If you care more about code quality than cost, or you're doing complex research and don't want lower thinking intensity to hurt your results, there's a middle ground. Use `Max` thinking in the `Plan` agent for architecture planning, then use `High` thinking in the `Build` agent for code execution. One thing to watch out for here is that, according to the [official docs](https://www.kimi.com/code/docs/en/kimi-code/models.html?ref=dataleadsfuture.com), switching the `reasoning_effort` value invalidates the context cache. Right after the switch, the model immediately refills the cache using your existing message history, which costs extra tokens. The official recommendation is to open a new session before switching `reasoning_effort` , so you avoid paying to refill old messages into the cache. There's a more elegant solution though. Set up a dedicated sub-agent with `Max` thinking, specifically for architecture decisions and hard problems. I'll cover that in the next section. ## Use Sub-Agents to Build an Efficient Team With the model and thinking level choices from earlier, you should already be saving a good chunk of tokens. If you want to cut costs even further, the best move is to use sub-agents, each with its own model and prompt, so each agent fits the task it handles. Why does this work? If you've ever led a dev team, you know that not everyone needs to be a superstar engineer, because superstars come with superstar price tags. From a cost and output perspective, the smartest call is matching the right task to the right person. A team runs best that way. So which sub-agents should you set up to get more out of `Kimi K3` per dollar? ### Explore Have you ever noticed that the bigger your codebase, the faster your token usage spikes? That comes down to how LLM caching and codebase retrieval work together. OpenCode puts tools, skills, system prompts, and other mostly static content at the top of the message list when it sends requests to the model. The model caches all of that, so subsequent prompts don't cost much extra. The real token hog is actually your most recent prompt. Before making any code changes, OpenCode uses `grep` to search through relevant code. When the codebase is large, even a few `grep` calls can pull in a massive amount of text. That's where most of your tokens go. When you need to pull information from multiple files or web sources, doing that in the main session makes things worse. A huge amount of irrelevant text gets stuffed into the main message list, blowing up both the model's context window and your quota. That's why OpenCode uses an `explore` sub-agent to handle complex research in a separate sub-session. Once the research is done, only the conclusions get returned to the main session. That keeps the main session's token usage lean. By default, `explore` has no model assigned to it, so it falls back to whatever model the primary agent uses, which is `Kimi K3` . That keeps costs high. The fix is to give the `explore` agent its own dedicated model. I strongly recommend `deepseek-v4-flash` . The `flash` model is cheap, has a long context window, and is plenty capable for text retrieval. Setup is simple. Just add a few lines to `~/.config/opencode/opencode.json` : ``` { "$schema": "https://opencode.ai/config.json", "agent": { "explore": { "model": "novita-ai/deepseek/deepseek-v4-flash" } } } ``` Give it a try. When your bill drops significantly, you'll thank me. ### Executor With the `explore` sub-agent and its dedicated model, we've already cut a big chunk of input token costs. Now let's look at how to reduce output token costs. Output token costs mainly come from actually writing code. There's a common misconception here. You might think that since `Kimi K3` is so capable, it must be the one writing the final code to make sure things work. That's not actually true. Writing code is a lot like a skilled programmer looking at a design doc and typing out what's on the screen. Most of it runs on muscle memory. If the coding task is well-planned in advance, and the model doing the actual output isn't too far behind in capability, then whether `Kimi K3` or `deepseek-v4-flash` writes the code, the quality difference is not that big. What really matters is who thinks. Good system design and knowing exactly what code will solve the problem efficiently, that's the important part. So we can keep the `Plan` primary agent for task planning and detailed spec generation (I recommend OpenSpec for SDD planning here), then hand off the actual coding to an `executor` sub-agent. This agent doesn't need to think. It just needs to write the code. OpenCode doesn't come with an `executor` sub-agent out of the box, so we build one ourselves. You don't have to agonize over the prompt. Just open OpenCode and tell `Kimi K3` what you want, like this: ``` I want to create a sub-agent called `executor`. Its main job is to complete coding and file editing tasks quickly at low cost. It doesn't do any research or information retrieval. That's the primary agent's job. Its only responsibility is to implement code fast based on the primary agent's plan. ``` OpenCode will write an `executor` agent file under `~/.config/opencode/agents/` based on what you described. Once it's done, restart OpenCode, and you're good to go. You can also give the `executor` more responsibilities. For example, you can allow it to run concurrently to speed things up: ``` This agent should support concurrent work. When the tasks to be implemented have no dependencies on each other, multiple `executor` agents (no more than 5) can be called in parallel to finish the work faster. ``` Don't forget to set the `executor` agent's model to `deepseek-v4-flash` . ``` --- description: ... mode: subagent model: novita-ai/deepseek/deepseek-v4-flash permission: webfetch: deny websearch: deny task: deny skill: deny --- ``` Restart OpenCode again. If you're not sure whether `executor` is configured correctly, ask OpenCode to run a self-check and evaluate whether the `executor` is working the way you designed it. OpenCode will generate some temporary coding tasks and hand them to `executor` to complete. It will also try to ask `executor` to do things it's not permitted to do, just to see if it follows the rules. When `executor` finishes, it returns a summary to the primary agent about whether the task was completed successfully. `Kimi K3` never has to output the actual code, so those expensive output token costs stay low. At the same time, `deepseek-v4-flash` is capable enough that your code quality won't take a noticeable hit. One important thing to keep in mind with the `executor` agent: don't let the `deepseek-v4` model write frontend code. Due to gaps in post-training, `deepseek-v4` really struggles with frontend visual design. So you should restrict the `executor` agent from handling frontend work: ``` This agent does not support frontend development. Any frontend-related work should never be assigned to this agent. ``` Or you can set the `executor` agent to still use the `Kimi K3` model, but with the variant set to `low` . If you mostly write backend code, `deepseek-v4-flash` is enough. If you write frontend code regularly, I'd go with the K3 model plus `variant=low` . That brings up a natural question: how do we make the most out of the thinking level parameter? ### Architect To keep `Kimi K3` fast and reduce token consumption during the thinking process, we set the default thinking level to `High` . I mentioned earlier that you can set the `Plan` agent to `Max` thinking during the planning phase. But what if you need K3 to hit Fable 5-level performance to crack a hard problem? You'd have to set `reasoning_effort` to `Max` . The official docs say that switching `reasoning_effort` invalidates the existing context cache, so the recommendation is to open a new session first. But that's not realistic in practice. The times when you actually need `reasoning_effort=max` are usually when you're stuck on an architecture tradeoff or a bug you can't fix after several tries. At that point, your message list is already packed with critical context. Starting a new session means K3 has to re-scan all the relevant code from scratch, and it's doing that scan at `max` thinking intensity, which burns even more tokens. And then if you want to switch back from `max` to `high` , the cache has to be refilled all over again, wasting another round of tokens. No matter how you slice it, it's not worth it. So why does a sub-agent solve this? Because we can set up a K3 sub-agent with `reasoning_effort` locked at `max` (I call this one `architect` ). When a hard problem needs solving, the primary agent first summarizes its current session into a condensed brief, then sends that brief along with the problem to the `architect` agent through a fresh sub-session. At that point, `architect` already understands the full context, so it doesn't need to re-scan all the documents the way a brand-new session would. It only needs to look up a few extra details it cares about, then focus entirely on thinking through the solution. I also turn off edit permissions for the `architect` agent. That way K3 isn't burning `max` -level thinking on actually writing code fixes. It just figures out the solution. The primary agent handles everything else. Building this sub-agent is straightforward. Just open OpenCode and ask it to write the prompt for you: ``` Design an architect sub-agent specifically for making architecture decisions, debugging hard bugs, and doing code reviews. ``` Don't forget to assign `architect` the Kimi K3 model with `variant` set to `max` : ``` --- description: ... mode: subagent model: novita-ai/moonshotai/kimi-k3 variant: max permission: edit: deny task: deny --- ``` To stop the primary agent from getting lazy and routing every problem to `architect` , add a guardrail in the sub-agent description. Require the primary agent to try at least two times on its own before delegating: ``` Hard bugs must go through at least two independent hypothesis-and-verify rounds by the primary agent with no resolution before they can be delegated here. ``` After restarting OpenCode, ask it to run a self-check to verify that `architect` applies the right thinking level when tackling hard problems: ### General Last but not least, don't overlook the `general` sub-agent. As one of OpenCode's built-in sub-agents, this one has always had a confusing identity. Looking at the source code, it's meant for complex research and retrieval work, which puts it in similar territory as `architect` , only to be called when heavy reasoning is needed. But it also supports concurrent calls to speed up research, which makes its token burn rate closer to `executor` . The role feels split in two. This agent rarely gets called during normal use. But if you ignore it, one day a complex deep research task might come up, and it'll get called concurrently to run complex web searches and research work, all using the default `Kimi K3 High` . So if you want tight control over your LLM token usage, make sure you assign this sub-agent a cheaper model. In my view, `deepseek-v4-pro` is a great fit here. It's capable enough for complex research, and the token cost isn't much higher than `deepseek-v4-flash` : ``` { "$schema": "https://opencode.ai/config.json", "agent": { "explore": { "model": "novita-ai/deepseek/deepseek-v4-flash" }, "general": { "model": "novita-ai/deepseek/deepseek-v4-pro" } } } ``` ## Conclusion That covers everything I've done to use Kimi K3 at lower cost inside OpenCode. With Kimi K3's model weights now publicly released, these methods come at the perfect time to help you experience this excellent model without breaking the bank. In my experience, after applying all these settings, even during high-intensity development work, my Allegretto plan went from "work two days, rest five" to "work five days, rest two." Even if your main models are Claude or GPT, these optimization approaches still apply. On top of that, the sub-agent setup I recommended here will noticeably speed up your development workflow and boost your overall efficiency. That's all for today. I'm [Mr. Qian](https://www.linkedin.com/in/qtalen?ref=dataleadsfuture.com), and I focus on enterprise-level AI Agent applications in practice. If you have any questions about this article, feel free to leave a comment, and I'll get back to you as soon as I can. Thank you for reading and subscribing. Feel free to share this article with your friends so more people can benefit from it. ## Recommended Enterprise AI Courses Getting the hang of some AI coding tricks is just the beginning. To learn the AI development tech stack more systematically and grow from an "AI enthusiast" to an "AI-driven software engineer," here are some courses I'd recommend to you: - Dive deeper into AI coding and agent building. Check out Vanderbilt University's on Coursera.**Generative AI Software Engineering Specialization** - To build real, production-ready enterprise AI agent apps to kickstart your AI career. The is a great fit here.**IBM RAG and Agentic AI Certificate** Both courses are included in [ Coursera Plus](https://imp.i384100.net/3kOjjB?ref=dataleadsfuture.com). If you're planning to level up in both AI engineering and architecture this year, the annual subscription is definitely the better deal. ## Further Reading How I built a coding workflow in OpenCode, Oh-My-OpenCode-Slim, and OpenSpec that rivals Claude Code: By adding a reflective agent to the OpenSpec workflow, I managed to get DeepSeek-V4-Pro to perform at the level of Opus: The concept of Loop Engineering has been getting a lot of buzz lately, so I decided to give it a shot in OpenCode. The results were surprisingly good: Get the source code for this article. **Start using it right away and save yourself a ton of trial and error time.** [Grab the Source Code](#/portal/signup)