Kimi code 2.6 major bug, horrendous support, epic engine!

Developer Support Kimi K2
, ,
1

Alright, I need to get this off my chest because I am absolutely losing my mind over how a product this good can be shackled by a system this broken — and how a support team can be this clueless.

Let me paint you the picture. I am a solo dev. I work on multiple projects at once. I am on the Allegretto plan. I live in Kimi Code. It is, without exaggeration, the most incredible coding assistant I have ever used. The context understanding, the multi-file editing, the sheer intelligence of this engine is off the charts. I was preaching Kimi Code to everyone I knew.

Then the 2.6 update dropped.

And everything changed…

THE BUG: THE INVISIBLE WALL
Here is what my life looks like now, on a plan I am paying for:
I sit down to work. I open Kimi Code. I am flying across three different projects simultaneously because that is how I work. Heavy context switching, heavy token usage, heavy output. I am in the zone.

And then, BOOM. Throttled.

Weekly cap exhausted. Not monthly — weekly.

This has already happened twice, half way through the same billing cycle.

Both times, I hit the ceiling within the first few days of the week. Not on day six. Not on day five. In the first couple of days. Most recently, I burned through 60% of my entire weekly quota in ONE NIGHT. One night! Because I was coding across multiple projects, which is literally the job.

So now I wait. Days. I have to sit there and twiddle my thumbs while the weekly limit resets, watching my projects stall, watching my momentum die, because I “used too much too fast.”

But here is the real kicker — the thing that makes me want to scream:
I am now two weeks into my monthly cycle. My dashboard reads: 22.48% monthly usage.

Twenty-two percent! I have been throttled twice. I have lost entire days of productivity. And my “monthly” pool looks like I barely touched it.
That is because the weekly cap is now the de facto monthly cap. It is the real boss. The monthly number is a fantasy. A decorative percentage. A participation trophy. You cannot reach the monthly ceiling if a weekly wall smacks you down every few days.

If I am two weeks in, and I have been working this hard, my monthly usage should read closer to 50%. But it cannot, because the system is designed to stop me before I get there.

THE MATH THEY DO NOT WANT YOU TO DO
Let me break down the logic of what a fair system looks like, because clearly whoever designed this update did not.

Start from the monthly quota — the number they advertise, the number you think you are buying.

  • Monthly ÷ 4 weeks = Weekly quota (~25% of monthly)
  • Weekly ÷ 7 days = Daily quota (~3.6% of monthly
  • Daily ÷ 4.8 = 5-hour window quota (24 ÷ 5 = 4.8 periods)

This is proportional scaling. This is a system. Every layer feeds logically into the next.

But that is NOT what we have right now.

What we have is a mess where the weekly cap is binding at roughly ~11-12% of the monthly pool — about HALF of where it should be.

The weekly limit is suffocating the monthly limit. The monthly limit is a billboard you drive past while stuck in weekly traffic.

These quotas are not a system. They are an out-of-order mess.

THE SUPPORT EXPERIENCE: A MASTERCLASS IN NON-ANSWERS
So I do what any reasonable person does. I email support. I lay it all out. The numbers. The throttling. The math. The disconnect between 22.48% monthly and the fact that I cannot work.

I wait. Days. Nearly a week…

And then I get this gem back — a generic FAQ copy-paste that looks like it was written by a bot that skimmed the word “token” in my subject line.

They explain:
“How are credits calculated? Usage is based on tokens…”
Cool. I know how tokens work. That is not what I asked.

They explain:
“Usage examples: Generating a simple PPT: ~1-2%… Writing a piece of code: ~0.5-2%…”
Cool. I did not ask for a price list.

And then — the pièce de résistance — they drop this sentence:
“Can I use all my credits on a single feature? Absolutely. That’s the core of our ‘unified balance’ design. You are free to spend your entire credit pool on whichever feature you use most, whether it’s coding, research, or chat.”

ABSOLUTELY*.*
You are free to spend your ENTIRE CREDIT POOL on coding.

Except… I CANNOT. Because the weekly cap stops me at ~11% of the monthly pool per week. I am just about a Kimi Code-only user. I want to spend everything on coding. Your own email tells me I am “free” to do so. But the system physically prevents it.

So which is it, Kimi Support?

Is the claim “Absolutely, spend your entire pool on one feature” true? Then raise the weekly cap to ~25% of monthly so I can actually do it.

Or is the weekly cap the real limit? Then stop lying to users about spending their entire credit pool.

You cannot have both. This is a direct contradiction in your own customer-facing documentation, delivered to me as if it were a solution.

WHY THIS HURTS MORE: THE ENGINE IS GODLIKE
I need you to understand something. I am not here to trash Kimi. I am here because I love this product so much that watching it sabotage itself is genuinely painful.

Kimi Code is an epic engine. The 2.6 update brought incredible improvements to the actual coding experience. The way it understands context across files, the way it suggests refactors, the way it handles complex multi-step implementation — it is genuinely on another level compared to the competition.

I was all-in. Evangelist-level all-in.

But the token system — specifically the weekly cap post-update — has turned that love into frustration. Now I’m all in for a couple days, maybe a few days if I turn the notch down, to being all out for even longer.

The issue did not exist before the update. Before, the limits felt proportional. I could work hard all week long, feel the weight of usage, but I would not get completely locked out of my IDE assistant. Now?

Locked out twice in two weeks. Waiting for resets. Watching my subscription waste away while I wait for support that DOES NOT CARE!

I am on the Allegretto plan. I am a single worker. I should not be maxing out infrastructure designed for heavier use this fast.

THE ASK
Fix the weekly cap scaling, please.
Make it proportional to the monthly pool. Monthly ÷ 4 = weekly. Weekly ÷ 7 = daily. Daily ÷ 4.8 = 5-hour. A system, not a trap.

Stop sending FAQ templates to users doing the math for you.

And please — either honor your “Absolutely” promise that users can spend their entire pool on one feature, or retract it. Because right now, it is false advertising.

I want to go back to loving this product unconditionally. But you are making it really, really hard. :sad_but_relieved_face:

TL;DR: Kimi Code 2.6 engine = god tier. Token system post-update = broken, weekly cap throttles way too early, monthly usage is a lie, support sent a generic FAQ that literally contradicts their own policy. Fix the proportional scaling. Please.

/endrant

1 Like
2

Hi there,

First of all, thank you so much for taking the time to share such a thorough, passionate, and detailed piece of feedback.

As the team managing the Developer Platform and the underlying inference infrastructure, we are deeply flattered by your incredibly high praise for the model’s capabilities. You give us too much credit, but it means the world to hear that it is helping you tackle multiple projects. Please know that our Pre-training and RL teams are continuously striving to refine and push the limits of the models, while we on the platform side are doing everything we can to ensure they run as efficiently as possible for developers like you.

That being said, reading about your experience with the workflow interruptions and the quota design is genuinely tough. We completely understand your frustration when you are “in the zone” and suddenly hit an unexpected wall.

To help get this sorted, it is important to share a bit of context on how things are structured under the hood:

Kimi Code operates as a core part of the broader Membership ecosystem. Its product logic, code plans, and quota systems (like the weekly vs. monthly allocation you mentioned) are designed and managed independently from our Developer Platform’s pay-as-you-go API infrastructure.

We absolutely welcome and value these kinds of deep-dive discussions here on the forum! Your breakdown of the math and the product design is incredibly insightful, and it is exactly the kind of user perspective that drives better products. However, to truly influence how the membership tiers and quotas are structured moving forward, we highly encourage you to forward this exact post directly to [email protected].

Putting your feedback directly in front of the product and membership teams is the best way to advocate for a more reasonable quota system that matches the power of the engine you enjoy using.

Thank you again for pushing the model to its limits, and for caring enough to help us all build a better ecosystem. Keep the feedback coming!

1 Like
3

On a personal note, comparing k2.5 to k2.6 in my own daily use, I’ve also noticed a shift.

If you look closely at the CoT, there is a lot more “internal friction” going on. The model constantly second-guesses itself, repeatedly double-checking to ensure it hasn’t missed any edge cases, which means it ends up overthinking even the simpler problems.

It is really a bit of a seesaw from a training perspective. The current priority is to push the ceiling on final accuracy—enabling the model to solve much more complex problems that it couldn’t handle before. The trade-off, however, is that this extra “mental gymnastics” on the easier tasks consumes more tokens, which I think isn’t ideal from a usage standpoint.

Having real-world “bad cases” gives our training team the exact data they need to help calibrate this balance. I would be incredibly grateful if you could share more of these examples.

1 Like
4

Such a wholesome response back. Likely, one as perceptive as yourself could provide a truly positive expectation of support.

I will email [email protected] again, and with this thread, for a laugh :joy: I mean, it’s reciprocal at this point for already sending me the exact FAQ response I mentioned as an example of the support I received.

Kind of funny, kind of hurts.

However, for Kimi — I hold plenty of hope.

Because…

:alien_monster: Kimi has undoubtedly helped me far greater than the distress I am currently under.

:folded_hands: My prayers will resonate with systemic mathematical consistency for the future of Kimi code.

:green_heart: My hopes will encompass that the weekly quota is increased to align with the monthly quota, rather than the other way around.

Thank you.

1 Like
5

We know that there is a compensating factor at present. A deeper model that can solve more complex problems, introduces a necessary force of caution.

And in reverse, to be more cautious, more depth is required to find caution towards. Depth = data, caution = comprehension

Kimi 2.6 is at least twice as cautious as 2.5. From an experiential point of view, 2.6 has definitely been refined. Problems which 2.5 could not resolve without at least a more detailed prompt, or “hint of the culprit”, were resolved every single time by 2.6, with the same prompt or one of lesser quality.

I can confidently say that all of the struggles I faced with 2.5, completely disappeared with 2.6.

These additions:

  1. Plan mode
  2. Send additional info while Kimi is in motion

Are incredible and so intelligent!!

I do not see the issue of extra tokens being spent as a problem, because the solutions are close to twice as efficient. I think the team has done exceptionally well here.

There is one flaw which I have noticed, and once focused upon, should repair the circling issue you mentioned over certain problems/solutions, which I believe was also recently expressed here on the forum.

I would bet the keys of this solution to be memory retention and pattern recognition. These are the only flaws I have noticed which would create a longer than usual resolution to an otherwise quicker 2.5 solution, or an unnecessarily repetitive 2.6 rectification.

Referencing to human nature: a deep over thinker is commonly anxious, unless they are performing a task they memorise, or are within a place they remember.

Maybe this will provide some valuable insight without getting into tooo much detail [:infinity:]

1 Like
6

UPDATE****

I have reached out to the proposed support email, although I have received no response. Kimi support feels heavily unmanaged, and unhelpful.

I am actually about to flip. How can I be told to contact this email for support related to Kimi code, yet receive zero support when doing so.

Feels like a true stitch up.

Super displeased with Kimi support right now. It is essentially non-existent.