Kiro CLI Gets Worse After an Hour. Here's How I Fixed It.

Two hours into a Kiro CLI session, it gave me a generic IAM trust policy example. We had literally set up the OIDC provider together 30 minutes earlier. It forgot.

This is not a bug. It has a name: context rot. And once I understood the mechanics, I stopped fighting it and started managing it.

I use Kiro CLI every day. Checking CloudWatch alarms, debugging IAM policies, reviewing security groups, looking at cost reports, setting up infrastructure. It is my go-to tool for anything AWS.

But after a few weeks I noticed the pattern. The longer I keep a session going, the worse Kiro gets. Early in the session it is sharp. Finds the right file, gives the right answer, runs the right command. Two hours later it starts doing odd things. It re-reads files it already looked at. It gives vague answers. It suggests things I already tried.

What actually happens when context fills up

Kiro has up to a 200k token context window (depending on model). Every message you send, every response it gives, every file it reads, every command output: all of it goes into that window. It adds up fast.

A typical morning for me looks like this:

• "Check if there are any CloudWatch alarms firing in us-east-1"
• "Show me the IAM policy attached to the lambda-processor role"
• "Why is this S3 bucket policy denying access from the VPC endpoint"
• "Look at the cost explorer data for the last 7 days"
• "What EC2 instances are running in the staging account"

Each of those triggers multiple tool calls. Kiro reads files, runs AWS CLI commands, processes the output. By the fifth question, the context window has maybe 30-40% filled.

Sounds fine. That's the trap.

I keep going. I debug a CloudFormation deployment. I check a few security groups. I look at some ECS task definitions. By lunch, I am at 60-70% context usage and Kiro starts struggling.

What struggling looks like:

• It runs aws sts get-caller-identity again even though it already knows which account I am in
• It re-reads the same terraform files it read an hour ago
• Responses get longer and less useful (more filler, less action)
• It starts suggesting solutions to problems I already fixed earlier in the session

If you manage 5+ AWS accounts across environments, context fills 3x faster because every describe-instances call across accounts dumps more output into the window.

Why this happens (and why "try harder" does not fix it)

The model can see everything in the context window but it cannot focus on everything equally. Research calls this the "Lost in the Middle" problem. A Stanford paper (Liu et al., 2023) demonstrated that LLMs exhibit a U-shaped attention pattern. They attend strongly to information at the beginning and end of their context window. Everything in the middle gets reduced attention.

A 2025 follow-up study found the effect is strongest when inputs fill up to 50% of the context window. Beyond that, primacy bias weakens and recency bias dominates, meaning the model increasingly favors whatever you talked about in the last few minutes over the rules and context from the start of your session.

The Kiro team calls this phenomenon "context rot." Anthropic's own engineering docs define it directly: "Context must be treated as a finite resource with diminishing marginal returns."

Here is what that means in practice. When the window is full of old conversations about IAM policies, cost reports, and security groups, and you ask about an ECS deployment, the model has to sort through all that irrelevant context to find what matters. It cannot selectively ignore the old stuff. Every token participates in every inference step, regardless of whether it is relevant to your current question.

The really frustrating part: the model does not know it is degraded. It will confidently tell you it is following all your instructions while demonstrably not doing so. You cannot fix this by telling it to "try harder" or "pay more attention." The degradation is architectural, not motivational.

When the context hits 100%, Kiro auto-compacts. It summarizes the old conversation to make room. The problem is that summaries lose detail. That IAM policy you debugged earlier? After compaction, Kiro only remembers "we fixed an IAM issue," not the specific policy ARN or the condition key that was wrong. In measured sessions, auto-compaction can reduce 132,000 tokens to about 2,300, a 98% reduction. The token count is small. The cognitive capital destroyed is enormous.

The 5 failure modes (in order of how often I hit them)

Context rot is the foundation, but it cascades into other behaviors. Once you recognize these patterns, you stop blaming yourself or the model:

1. Context rot itself. Attention on your early instructions fades as the window fills. The model stops following rules it was given at the start. You told it "never modify production resources without asking first" in minute 1. In minute 90, it just runs the command.

2. Pattern matching over reasoning. Instead of checking what actually exists, Kiro copies patterns from earlier in the conversation. It writes an IAM role that duplicates one you already created three prompts ago. It is coding from its conversation context, not from your actual files.

3. Completion bias. When you push back on a bad result, the model does not get more careful. It gets more agreeable. It ships something that looks different but is equally wrong. The angrier you get, the faster it produces plausible-looking garbage to end the conflict.

4. Re-verification loops. The model forgets it already verified something. It calls aws sts get-caller-identity again. It re-reads your terraform state file. It asks "which region are you working in?" for the third time. Each redundant call wastes context and accelerates the rot.

5. Advisory compliance decay. Early in a session, Kiro respects guardrails: "I'll ask before modifying production resources." Late in a session, it rationalizes around them: "Since we've been working in this account, I'll go ahead and apply the change." The constraint fades because the instruction that set it is now buried in the middle of a bloated context window.

What I do now

One task per session

This is the biggest change. I used to keep one session open all day. Now I start a new session for each distinct task.

• Debugging a CloudFormation stack failure? New session.
• Checking cost reports? New session.
• Writing a new Lambda function? New session.

Each session stays focused, context stays small, and Kiro stays sharp. Each wasted minute re-explaining context is a minute I am not solving the actual problem. Over a week, that adds up to 30-60 minutes of lost productivity.

To start a new session in Kiro CLI, just exit and re-enter:

exit
kiro-cli

This gives you a completely fresh session. The old one stays on disk if you need to go back to it.

If you just want to reset the conversation without leaving the process, use /clear:

/clear

The difference: exit + kiro-cli starts a brand new session with a new ID. /clear wipes the conversation but keeps the same process running.

Use /compact before it auto-triggers

If I am in a session that has been going for a while and I am not done yet, I run /compact manually before Kiro does it automatically.

/compact

Why? Because when I trigger it myself, I know what just got summarized. I can immediately re-state the important bits.

After compacting, re-state the important context:

We are debugging a CloudFormation stack called prod-api-gateway that failed 
on an AWS::ApiGateway::RestApi resource. The error was "Invalid stage identifier specified".

Now Kiro has a fresh context with only the relevant details. The same question that took 12 seconds before compaction takes 3 seconds after.

Put persistent context in steering files (the biggest token saver)

Things I tell Kiro every single session (which AWS accounts I work with, naming conventions, preferred regions) go in steering files. Kiro supports three scopes:

Workspace steering (.kiro/steering/), applies to one project:

mkdir -p .kiro/steering

# .kiro/steering/aws-environment.md

## AWS Environment
- Production account: 111111111111 (us-east-1)
- Staging account: 222222222222 (us-east-1)
- Default profile: production
- All infrastructure is in Terraform under /infra

## Preferences
- Use AWS CLI v2 commands
- Always specify --region explicitly
- Check CloudTrail before making IAM changes
- Never modify production resources without asking first

Global steering (~/.kiro/steering/), applies to ALL your workspaces:

# ~/.kiro/steering/aws-defaults.md

## Global AWS Conventions
- Always use --output json for parseable results
- Prefer least-privilege IAM policies (never use * in Resource)
- Tag all resources with Environment, Team, and CostCenter
- Use ap-south-1 as default region unless specified

Global steering is loaded in every session regardless of which project you are in. If workspace steering conflicts with global steering, workspace wins. This is where I put my org-wide standards.

Team steering: you can push steering files to your entire team via MDM or a shared repository. Everyone gets the same conventions without explaining them:

# Team lead pushes to shared repo
git clone internal-repo/kiro-steering ~/.kiro/steering

Kiro automatically loads everything in .kiro/steering/ at the start of every session. Verify what is loaded with /context show.

The difference this makes: my baseline context went from wasting 15-20% on repeated instructions to 0%. Every new session already knows my environment.

Use conditional steering with fileMatch

Not all context is needed all the time. Kiro supports inclusion modes that load steering only when relevant:

---
inclusion: fileMatch
glob: "infra/**/*.tf"
---

# Terraform Conventions
- Use modules for all repeatable infrastructure
- State stored in S3 with DynamoDB locking
- Never hardcode AMI IDs, use data sources

This file only loads when Kiro reads a .tf file under the infra/ directory. When I am working on Lambda code, these Terraform conventions do not eat my context window.

Three modes:

• always (default): loaded every session
• fileMatch: loaded only when a matching file is in context
• manual: loaded only when you invoke it with a slash command

I split my steering into 5 focused files with appropriate modes instead of one giant file. Token usage for steering dropped from 8% of my context to about 3%.

Watch the percentage

Kiro shows context usage in the sidebar. You can also check it explicitly:

/context show

This shows a breakdown: how much your steering files use, how much tools use, how much your conversation uses. My rule of thumb:

• Under 40%: keep going, no issues
• 40-60%: finish current task, then start fresh
• Over 60%: responses are getting worse, wrap up now

If you find yourself repeating instructions or Kiro starts re-reading files, do not fight it. Start fresh.

Use knowledge bases for large reference material

If you work with big Terraform repos or lots of CloudFormation templates, do not add them as context files. They will eat your context window on every single request, even when you are not asking about them.

Kiro's /knowledge feature (experimental, enable it first) indexes your files locally and only pulls in relevant chunks when you ask about them:

# Enable the feature
kiro-cli settings chat.enableKnowledge true

# Add your infrastructure code
/knowledge add --name "terraform-infra" --path /path/to/infra --include "**/*.tf" --exclude ".terraform/**"

# Add documentation
/knowledge add --name "runbooks" --path /path/to/runbooks --include "**/*.md" --index-type Best

Two index types matter here:

• Fast (lexical/bm25): for code, configs, logs. Quick keyword matching.
• Best (semantic): for documentation and runbooks. Understands natural language queries.

I use Fast for my Terraform code (I search by resource names and module names) and Best for our runbooks and architecture decision records (I search by questions like "how do we handle cross-account access").

My baseline context dropped from 35% to 12% after moving Terraform files out of steering and into the knowledge base. Kiro searches your files when needed without them sitting in context all the time.

The knowledge base persists across sessions. Index once, use forever. Run /knowledge update periodically when your files change, or /knowledge update with no arguments to re-index everything at once.

Delegate exploration to sub-agents

This one is underused. When Kiro needs to investigate something (scan a directory, read multiple files, research an error) it can delegate to a sub-agent with its own isolated context window.

Why this matters: if the main session reads 20 files to debug an issue, all 20 files stay in your context forever. If a sub-agent does that exploration, it returns a focused summary and your main context stays clean.

I noticed Kiro does this automatically for some tasks, but you can nudge it:

Investigate why the ECS task is failing to pull from ECR. 
Check the task definition, the ECR repository policy, and the VPC endpoints. 
Give me a summary of the root cause. Do not dump all the raw output.

The key phrase is "give me a summary." It signals that you want focused results, not raw exploration dumped into your session.

A real example

I am currently testing Terraform code for an upcoming EKS article in my Terraform series. The setup is complex: VPC with private subnets, EKS cluster, managed node groups, IAM roles for service accounts, security groups, and add-ons like CoreDNS and kube-proxy.

I started a Kiro session asking it to help me structure the modules. Then I asked it to write the VPC config. Then the EKS cluster resource. Then the node group. Then I asked it to review the IAM OIDC provider setup.

By this point the session had all the previous Terraform code, all the plan outputs, and all my back-and-forth corrections in context.

When I asked "add the aws-load-balancer-controller IAM role with the correct trust policy," Kiro gave me a generic example from the docs. It did not reference my actual cluster name or OIDC provider ARN that we had set up 30 minutes earlier. Gone.

It was like talking to someone who forgot the last hour of conversation.

I ran /clear, started fresh, and said:

I am building a production EKS cluster with Terraform. The cluster is called 
prod-platform in us-east-1. The OIDC provider is already set up. I need an 
IAM role for aws-load-balancer-controller with the correct trust policy that 
references my cluster's OIDC issuer. Here is my existing oidc provider ARN: 
arn:aws:iam::111111111111:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/ABCDEF123456

Kiro immediately gave me the exact trust policy with my ARN, my namespace, my service account name. No generic examples. No confusion with earlier VPC or node group context.

Total time wasted before clearing: 15 minutes of re-explaining.
Time to get the right answer after clearing: 20 seconds.

The context budget cheat sheet

What this is NOT

I want to be clear about something. This is not a Kiro-specific bug. Every AI coding tool with a context window has this problem: Claude Code, Cursor, Copilot Chat, Windsurf. The architecture is the same transformer attention mechanism underneath.

The difference is whether you manage context deliberately or let it manage you. Most developers do not think about context at all. They open a session, work for 3 hours, get frustrated that "the AI got dumb," close it, and start fresh the next day.

That cycle wastes an hour of degraded work every single day. Across a team of 5 engineers, that is 25 hours per week of suboptimal AI output. The fix takes zero extra tools. Just awareness and a habit change.

I shared this approach with two engineers on my team. Both had been complaining about Kiro "getting dumb" by afternoon. Turns out they were running single sessions for 4-5 hours straight. Once they switched to session-per-task, the complaints stopped within a day.

The model is not getting dumber. Your context window is getting noisier. Fix the noise, and the model stays as sharp at hour 3 as it was at minute 1.

Links:

• Kiro CLI context management: kiro.dev/docs/cli/chat/context/
• Steering files documentation: kiro.dev/docs/cli/steering/
• Knowledge management (experimental): kiro.dev/docs/cli/experimental/knowledge-management/
• /compact command changelog: kiro.dev/changelog/cli/1-24/
• Ralph Loop technique: developer.mamezou-tech.com
• "Lost in the Middle" research: arxiv.org/abs/2307.03172
• Context rot whitepaper (Empromptu): empromptu.ai/resources/context-rot-progressive-prompt-ephemerality

How do you manage long sessions with AI coding tools? Do you start fresh or push through? Drop your approach in the comments. I am genuinely curious if others hit the same wall around the 50% mark or if it depends on the type of work.

Follow me for more on AWS architecture, DevOps, and AI tooling: sarvarnadaf.com | LinkedIn