I've been using Kiro heavily since launch. After a few weeks I noticed something: certain sessions cost dramatically more than others, and it didn't always correlate with how much actual work happened. The expensive sessions were long ones.
Here's the thing that isn't obvious until you watch your usage graph: an LLM has no memory. Every single request sends the entire conversation again.
Why Long Sessions Get Expensive
Your first message in a session is small. Your prompt, the steering files, maybe a file or two of context.
Your twentieth message sends all of that, plus every response Kiro gave, plus every file it read, plus every terminal command and its output, plus all of the agent's intermediate reasoning. The model re-reads the whole history to produce one more paragraph.
The total cost of a session grows exponentially with the number of turns, not linearly. Each request resends everything before it, so the cumulative token bill accelerates as the conversation gets longer. The same request in a fresh session versus ninety minutes into a sprawling one does not cost the same.
Hand Off to Yourself
This is the biggest lever.
When a session starts getting long, I stop and ask for a handoff document:
Write docs/handoff-current-task.md covering:
- what we've completed and why
- the current problem and what we've ruled out
- open questions I need to answer
- the next 3 concrete steps
Assume the reader has no prior context.
Then I close the session, open a new one, and start with #File docs/handoff-current-task.md — pick up from here, start with step 1.
The new session carries the conclusions instead of the transcript. A few thousand tokens of handoff replaces 60,000 tokens of back-and-forth, and every subsequent request in that session is cheap again.
Kiro does compact context automatically as you approach the limit, but that's a summary the agent chose. A handoff file is one you reviewed. You drop the dead ends, keep the decisions, and have a real artifact you can pick up days later.
Let Sub-Agents Do the Expensive Exploration
This is the automated version of the handoff pattern.
When Kiro delegates work to a sub-agent, that sub-agent starts with a fresh, minimal context. It doesn't inherit your 40-turn conversation history. From your main session's perspective, it's a tool call: a prompt goes out, a summary comes back. Your parent context grows by the size of that summary, not by the 15 file reads and 8 grep searches the sub-agent ran internally to produce it.
You can nudge this explicitly: "investigate how the auth middleware interacts with the session store, don't change anything, just report back." That exploration happens in a disposable context fork instead of polluting your main conversation. The conclusions come back; the dead ends stay behind.
Front-Load the Specifics
Clarification round trips look small and aren't. When Kiro asks "do you want this in the service layer or the controller?" and you answer with three words, that three-word reply still triggers a full resend of the conversation so far.
The same ambiguity at turn 30 costs real money. Front-load the specifics: name the file, name the pattern you want followed, say what "done" looks like.
Compare:
Fix the auth bug.
The middleware rejects valid tokens when the
issclaim uses the regional endpoint URL instead of the global one. It worked before we added the EU pool. Start insrc/middleware/verify.ts.
The second one skips an entire diagnostic conversation.
Match the Model to the Job
Different models consume credits at different rates. A prompt on a frontier model costs more than the same prompt on Auto.
- Frontier model for planning and diagnosis. Architecture decisions, designing a system, tracing a bug through code you don't understand. This is where reasoning quality changes the outcome.
- Cheaper model or Auto for execution. Once the plan is written down, you're just implementing it: wiring up boilerplate, renaming across files, writing tests to a spec. The thinking is already done.
Spec sessions pair well with this: plan and design expensively once, then execute tasks on a cheaper model. Don't pay frontier rates to add a field to a struct.
Kill the Tool Loops
The single most expensive failure mode I hit wasn't a hard problem. It was the agent running in circles.
I was working in Unreal Engine, and running automation tests from the command line was the worst offender. Kiro would launch the editor, not get a clean result, go hunting through log directories, pull log fragments into context, try a different invocation, hit a stale process, try again. Every retry resent the entire conversation plus the accumulated log output. Context ballooned, credits went with it, and I still didn't have a test result.
The fix was a shell script that wraps the build and test run to print exactly one verdict line, plus a steering file that forbids the improvisation:
# Build & Test: Execution Rules
## Building
Run synchronously with a timeout:
execute_bash: command="./scripts/build.sh", timeout=300000
- The script outputs BUILD SUCCEEDED or BUILD FAILED with error details.
- Read the output. That's it. No follow-up log parsing needed.
## What NOT to Do
- NEVER use a background process for builds or tests
- NEVER sleep/poll/wait in a loop checking if the process is still running
- NEVER go hunting for log files after running these scripts
- NEVER retry a timed-out build automatically, ask me
The scripts are trustworthy enough that the agent never needs a plan B, and the steering explicitly forbids the plan Bs it used to invent. Prohibitions matter as much as instructions. A capable agent will always find another approach to try, and each attempt is another full-context request.
Any routine task where Kiro repeatedly improvises is a candidate: builds, tests, deploys, migrations, log queries. Write the script, write the steering rule, and the loop dies permanently.
Keep Tool Output Small
Whatever a tool prints goes into context and gets resent for the rest of the session. A 5,000-line log dump doesn't cost you once. It costs you on every subsequent request until you start a new session. Same for reading an entire generated file when you needed one function, or listing a directory with thousands of entries.
Prefer targeted searches over full reads, and wrap noisy commands in scripts that emit a summary. When something does flood the context despite your best efforts, that's your signal to write a handoff file and start fresh.
Use .kiroignore for Binary-Heavy Projects
If your project has large binary files (game assets, compiled outputs, media files, ML model weights), Kiro may attempt to read them or include them when gathering context. A .kiroignore file works like .gitignore: it lists patterns for files Kiro should leave alone. One catch: Kiro doesn't pick it up automatically. You need to add the filename to the ignore list in your IDE settings for it to take effect.
I noticed credit usage spike after adding audio assets to my project. I'm not certain whether the binary content was being injected into context directly or whether the expanded file list was just causing the agent to attempt more reads. Either way, after adding a .kiroignore that excluded binary asset directories, the per-session cost dropped back to expected levels.
# .kiroignore - keep binary assets out of context
*.uasset
*.umap
*.mp3
*.wav
*.ogg
*.png
*.jpg
*.fbx
Content/
Binaries/
Intermediate/
DerivedDataCache/
There's no real downside. Kiro doesn't need to read your textures or compiled binaries to write your code.
For non-game projects, the same applies to node_modules/, dist/, .next/, large data fixtures, vendored dependencies, or anything else that's large and irrelevant to the code being written.
Know When to Abandon a Thread
If the same approach has failed twice, the conversation is actively working against you. Every wrong hypothesis stays in context, gets resent, and nudges the model back toward the thinking that already didn't work. The context becomes a graveyard of bad ideas that the model keeps tripping over.
Starting over with a clean session and a precise description of what you've already ruled out is usually both cheaper and faster than grinding through a third attempt.
The Short Version
Every request resends the full conversation. That's the whole problem. Handoff files reset the meter. Precision up front avoids expensive clarification loops. Use a frontier model to think, a cheap one to type. Script anything the agent keeps improvising. And .kiroignore your binaries. Kiro doesn't need to read your textures to write your code.
I'm not using Kiro less. I'm just not paying to resend the same 60,000 tokens forty times to get the same work done.
