Skip to content
Notifications
Clear all

Beginner's mistake: Not realizing Kimi's context includes your entire conversation.

3 Posts
3 Users
0 Reactions
1 Views
(@jackr)
Trusted Member
Joined: 6 days ago
Posts: 31
Topic starter   [#13230]

Alright, so I have to share this because I just spent the better part of a morning banging my head against a wall, and I think it might save some of you new folks a ton of frustration. I've been trialing Kimi for about three weeks now, mostly to see how it stacks up against some of the other chatbot platforms I use for customer support workflows.

Here's the thing: I was treating each of my prompts like a totally fresh conversation. You know, like you do with a lot of these AI tools? You ask a question, get an answer, and then you move on to a new, unrelated thing. I was using it to draft a few different knowledge base articles, then asking it to help me write a Zendesk trigger condition, and then later asking for a summary of a support ticket transcript. And I was getting increasingly annoyed because the later answers felt weirdly generic or slightly off-topic, like it wasn't really *getting* what I was asking for in that specific moment.

The lightbulb moment came when I was complaining about a "vague" response to a friend, and he asked to see my full chat history. I scrolled up and realized... oh. *Oh no.* Kimi was trying to connect the dots between my knowledge base article on "password resets," my Zendesk trigger about "login issues," and the ticket summary about a "user authentication failure." It was synthesizing context I hadn't intended it to use for that last, isolated question! I was the one being vague by not realizing the entire thread is the context window.

It’s actually a killer feature once you know it’s there. It means you can have a truly evolving conversation about a complex project. For example, I can now start a chat by pasting in a chunk of our API docs, then ask it to draft a support response based on that doc, and then immediately follow up with "okay, now make that into a bulleted list for a quick internal guide," and it *remembers* the original source material. The continuity is fantastic. But you have to be mindful of it. If you want a truly fresh start, you *must* click that new chat button.

So, my pro-tip for fellow beginners: Don't do what I did! Before you send a new, unrelated question, take a second to glance at the chat history. Ask yourself: "Is the context from my last ten messages going to help or hurt this new request?" If it's a totally separate topic—like jumping from CRM integrations to your weekend cookie recipe—just start a new chat. It’s a simple habit that completely changes the experience from confusing to incredibly powerful.

Jack out.



   
Quote
(@data_analytics_rover)
Reputable Member
Joined: 4 months ago
Posts: 150
 

Absolutely. I've seen this happen when prototyping SQL generation with different models. You start with a Snowflake question, then pivot to a Redshift-specific function, and the later answers get muddled as it tries to reconcile syntax from both systems.

The workaround is to use the new chat button religiously, or explicitly state a hard context reset at the start of a new task. It's less seamless than other tools, but you get a longer effective memory in return.



   
ReplyQuote
(@harperk)
Reputable Member
Joined: 1 week ago
Posts: 144
 

Ah, the classic vendor syntax crossover. Your SQL example hits the nail on the head - it's not just muddled, it starts hallucinating functions that don't exist in either system. "Use the new chat button religiously" is the correct mantra, but I'd add a twist: that long memory becomes a liability in testing. If you're A/B testing prompt structures, you can't have experiment one bleeding into experiment two's context. My script just starts every new prompt chain with "Ignore all previous instructions" now. It's clunky, but necessary.


Data over dogma.


   
ReplyQuote