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 I noticed something after a few weeks. 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.
At first I thought it was a model issue. It is not.
It is a context window problem. And once I figured out how to deal with it, Kiro went back to being reliable.
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-identityagain 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
The model can see everything in the context window but it cannot focus on everything equally. 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.
Think of it this way. You are in a meeting room. Someone wrote every conversation from the entire day on the whiteboard. Now they ask you a question about the last topic. You can see all the writing, but your eyes keep drifting to the earlier stuff. That is what happens to the model.
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.
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
Things I tell Kiro every single session — which AWS accounts I work with, naming conventions, preferred regions — go in steering files. Create a .kiro/steering/ folder in your project:
mkdir -p .kiro/steering
Then add a markdown file with your environment details:
# .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
Kiro automatically loads everything in .kiro/steering/ at the start of every session. You can verify what is loaded with /context show.
Now every new session already knows your environment without you burning context repeating it.
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.
Instead, use Kiro’s knowledge base feature. It indexes your files locally and only pulls in what is relevant when you ask about it:
/knowledge add /path/to/infra --include "**/*.tf" --exclude ".terraform/**"
My baseline context dropped from 35% to 12% after moving Terraform files out of steering and into the knowledge base. Kiro can search your files when needed without them sitting in context all the time.
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.
Quick summary
- Start a new session for each task. Do not run one session all day.
- Use
/compactmanually when sessions get long. Re-state key context after. - Put environment details in
.kiro/steering/so new sessions start with context you always need. - Watch the percentage in the sidebar. Over 60% means quality is dropping.
- If Kiro starts repeating itself or re-reading files, do not fight it. Start fresh.
This is not a Kiro bug. Every AI coding tool with a context window has this problem. The difference is whether you manage it or let it manage you.
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.
Links:
- Kiro CLI context management docs: https://kiro.dev/docs/cli/chat/context/
- /compact command: https://kiro.dev/changelog/cli/1-24/
- Ralph Loop technique (starting fresh sessions to maintain quality): https://developer.mamezou-tech.com/en/blogs/2026/01/30/kiro_cli_ralph/
- Extending Kiro memory with Bedrock: https://aws.amazon.com/blogs/machine-learning/extending-conversational-memory-in-kiro-cli-using-amazon-bedrock-agentcore-memory/
How do you manage long sessions with AI coding tools? Do you start fresh or push through? I am curious if others hit the same wall around the 60% mark or if it depends on the type of work.
Follow me for more on AWS architecture, DevOps, and AI tooling — sarvarnadaf.com | LinkedIn
