> ## Content Index > Fetch the complete content index at: https://www.dataleadsfuture.com/llms.txt > Use this file to discover other available public pages before exploring further. # How I Cut Kimi K3 Costs in OpenCode - URL: https://www.dataleadsfuture.com/how-i-cut-kimi-k3-costs-in-opencode/ - Published: 2026-07-31T08:04:03.000Z - Updated: 2026-09-09T03:07:56.000Z - Description: Better code quality, but spend less money - Author: Peng Qian - Tags: Harness Engineering, Generative AI, Career Growth ## 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. Besides the official Coding Plan, if you'd rather pay per use or call a third-party API, you can just use open platforms that support Kimi K3, like [**Novita.ai**](https://fas.st/t/cBJ7iuNS) (which offers ultra-low-latency endpoints and generous free credits for new users) and OpenRouter. The setup and how it works are the same. 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`. ![A comparison of model capabilities provided on the official website.](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/2026/07/image-13.png) A comparison of model capabilities provided on the official website. Screenshot from [Kimi](https://www.kimi.com/code/docs/en/kimi-code/models.html) 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), 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), 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. ![The biggest token consumers are user messages and tool call results.](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/2026/07/image-14.png) The biggest token consumers are user messages and tool call results. Image by Author 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`: ```json { "$schema": "https://opencode.ai/config.json", "agent": { "explore": { "model": "novita-ai/deepseek/deepseek-v4-flash" } } } ``` **Quick setup tip:** If you don't have a Novita account yet, grab your API Key from [**Novita AI**](https://fas.st/t/cBJ7iuNS), then paste it into the API KEY field under the Novita provider. ![Move the retrieval cost from the main session to a sub-session running on the DeepSeek Flash model.](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/2026/07/image-15.png) Move the retrieval cost from the main session to a sub-session running on the DeepSeek Flash model. Image by Author 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: ```Markdown 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: ```Markdown 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`. ```Markdown --- 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. ![Ask OpenCode to run a self-check to see if the executor is working properly.](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/2026/07/image-16.png) Ask OpenCode to run a self-check to see if the `executor` is working properly. Image by Author 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: ```Markdown 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: ```Markdown 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`: ```Markdown --- 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: ```Markdown 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: ![](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/2026/07/image-17.png) Run a self-check on the availability of the `architect` agent. Image by Author ### 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`: ```json { "$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), 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. ## Follow Data Leads Future One practical story every month, sharing my hard-learned experiences in the enterprise AI space. Subscribe Email sent! Check your inbox to complete your signup. No spam, No ads, you can unsubscribe anytime. --- ## Further Reading How I built a coding workflow in OpenCode, Oh-My-OpenCode-Slim, and OpenSpec that rivals Claude Code: [How I Use OpenCode, Oh-My-OpenCode-Slim, and OpenSpec to Build My Own AI Coding EnvironmentRide the wave of AI coding, don’t get swept away by it![](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/icon/color_192_192-e5c5bb35-cbaa-434b-baea-547f937998e0.png)Data Leads FuturePeng Qian![](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/thumbnail/opencode_cover_3-1-59d35e77-6277-4b4b-8e8f-23f411b077fb.webp)](https://www.dataleadsfuture.com/how-i-use-opencode-oh-my-opencode-slim-and-openspec-to-build-my-own-ai-coding-environment/) By adding a reflective agent to the OpenSpec workflow, I managed to get DeepSeek-V4-Pro to perform at the level of Opus: [Reflection SDD: Use a Reflection Harness to Level Up Your OpenSpec WorkflowStop letting bad spec files tank your code quality![](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/icon/color_192_192-5a85b02b-2380-40c1-8b28-50ee54deefbb.png)Data Leads FuturePeng Qian![](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/thumbnail/9f04a900-aa9a-4fd2-bd70-6f3fe3783129-f9ad9e37-a235-4e82-b193-90540c1d7319.webp)](https://www.dataleadsfuture.com/reflection-sdd-use-a-reflection-harness-to-level-up-your-openspec-workflow/) 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: [No Plugins Needed, I Built a Fully Automated Coding Loop in OpenCodeUsing DeepSeek-V4 for low-cost Loop Engineering![](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/icon/color_192_192-abc0b774-ec22-4b1b-8119-0037d9dcc229.png)Data Leads FuturePeng Qian![](https://storage.ghost.io/c/33/67/33678c00-2c15-4961-93e9-497b427e2006/content/images/thumbnail/cover-3-comprass-b8cec65e-5414-414c-80bf-e2b49730c256.webp)](https://www.dataleadsfuture.com/no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode/) --- ## Source Code Here's the ****source code for this article**. Sign up now to get it for free. [Grab the Source Code ](#/portal/signup)