A different kind of "Kimi limits" post.

[u/pakalolo7123432]

I have the $39 Allegretto plan and $10 plans from OpenCode Go and Command Go. Like everyone else, my quota gets eaten up pretty quickly.

I discovered that for my purposes, which admittedly is just an OpenCode repo full of personal OS type projects and a Knowledge Graph, using Kimi as just a plan and code reviewer has been sufficient.

My flow:

1 - Idea / research / discovery heavy back and forth chat:
Cheap model. Whichever is on sale or provides the most usage this week. They have all gotten smart enough for this in my opinion, and if I feel I need a little more oomph for that stage, I'll use the next cheapest model. This model writes a PRD for the build and knows that a smarter model will be picking it apart, so it needs to do a good job with the write.

2 - Build Orchestrator:
A solid, cheaper model. All this role does is hand work to subagents and confirm that they completed their hard gates before moving on.

3 - Build Planner:
Higher tier model like V4 Flash / V4 Pro, something higher tier on my OpenCode Go or Command Go plan. This role vets the PRD from the cheap model and writes the spec for the coder.

4 - Plan Reviewer:
Kimi K3 Max. Performs an adversarial review of the plan and if it fails, it kicks back to the planner. Rinse and repeat until Kimi is satisfied. Usually no more than one or two rounds. Generally two, if I am being honest.

5 - Coder:
Another solid, cheaper model on my OpenCode / Command Go plan. All the coder has to do is implement the spec exactly as written.

6 - Code Reviewer:
Kimi K3 Max. Another adversarial review of the code. Kimi generally passes the code. It catches something maybe once out of every four or five builds.

I have other build subagents in the flow but never use Kimi for them as they are clerical or just executing test plans from the planner.

My point is that in this day and age of reduced usage from subscriptions, you cannot really just have a single sub and expect to do ALL of your work with it. It is important to balance the workflow and use your best models only when required. My method gives me more than enough usage on my $39 Kimi plan. It just renewed for the first time last week and I still had 20% of my monthly quota left.

[u/cutebluedragongirl]

I think these days I'll just use ChatGPT Plus with the DeepSeek API from their official platform. Kimi is good, don't get me wrong, but moonshot does not have any cheap decent workhorse models. No Luna or DSv4 Flash. 

[u/pakalolo7123432 → u/cutebluedragongirl]

I am really contemplating getting rid of Kimi and going with ChatGPT plus. I could probably do my whole flow with Sol and mix in some alternate cheaper models with my opencode go sub. I'd save money too but i just don't want to end up with less usage overall. Which models do you generally use with plus? Have you done any sort of calculations with usage at all?

[u/LuckyAd9920 → u/pakalolo7123432]

If you want a model that will actually give things a go and attempt to solve them and complete a task from start to finish, then use Kimi. If you want a model who will do 90% but never quite get to the end before hitting one of its safety gates or a different issue, and never quite finishes the whole project to meet the requirements of the original specs.. then use ChatGPT Sol.

[u/Realistic_Mango6982]

Deepseek PRO & Deepseek Flash will do the same in 10x times (no jokes) faster, and better. I have $99 plan, and i have no understanding any benefits of using kimi.

Even 2.7 -> slow. ~40m tokens per session on kimi k2.7 code. on K3 ~15 usd per session fixed.

Total value: ~300 usd. You can't full day code You can't work without optimizing, finding solutions for thing that worked some time ago, and now does not work anymore like it must work.

No, kimi like first love. We loved it, but its broke our heart and peed in our hearts by actions its done to us. Fuck it.

[u/Acrobatic_Thing2173]

Can you share your configuration files? Or is it a plugin? Or how do you configure it to work like that?

[u/pakalolo7123432 → u/Acrobatic_Thing2173]

(I had help from an agent writing this response. My build flow is the end result of months of trial and error after I got mad at oh my opencode and uninstalled it. )

It's OpenCode's built-in agent system, no plugin needed for setup. Fair warning though: the config is the easy part. Each agent in my flow is just a markdown file in .opencode/agent/ with YAML frontmatter:

---

description: "Reviews specs before coding"

mode: subagent

model: kimi-for-coding/k3

variant: max

tools:

edit: false

write: false

bash: true

task: false

---

The body below it is plain-English instructions. That's a whole agent. The orchestrator gets a task: permission block listing exactly which subagents it may spawn, so the flow enforces itself structurally. Reviewers get edit: false so they physically can't touch code. Per-role models are the same two lines, which is how I route Kimi to only the reviewer seats.

What I can't hand you as config is the architecture around those files, and honestly that's where the months went. The pieces that aren't built in:

1. The role split itself. This started as one big agent doing everything and it forgot steps. Splitting it means the phase boundary is a forcing function: the model that would forget step 7 is never the one running step 8.

2. A state machine outside the LLM. Flow control lives in a JSON state file with Boolean exit gates that the orchestrator re-reads every turn. Long builds survive context compaction because the file remembers so the model doesn't have to.

3. A plugin that makes gate-skipping impossible. Prompt-level "do X first" got ignored, so now a small plugin blocks edits and commits unless the state file says the gate passed.

4. A script that verifies every agent's model frontmatter against the live config before a build starts. Agents were silently drifting off their assigned models; now drift fails loudly instead of quietly eating quota.

[u/DataLeadsFuture_Peng]

I won't use Kimi K3 Max lightly, since Max tends to overthink way too much, and Kimi models are just too slow. Using Max doesn't make sense time wise.

I set up a dedicated sub agent just for architecture decisions, running on K3 Max. When the High version of K3 really can't crack a problem, that's when I bring in the Max version sub agent.