How I Cut Kimi K3 Costs in OpenCode

#vibecoding #ai #programming #coding

Better code quality, but spend less money

Introduction

Last week, I burned through 7 days' worth of quota in a single day while using the Kimi K3 model on Kimi's Allegretto 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 was spoiled by the cheap API of DeepSeek-V4, that was not acceptable.

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 (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 Allegretto 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, 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, 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.

What's next?

How to configure the built-in explore and general agents in OpenCode to significantly cut down on input costs.
How to save on output costs by setting up the executor and architect agents.
A quick walkthrough on cache configuration for the coding agent.

If you're interested, feel free to click on Data Leads Future to read the full article.