Kiro Context Window: Specs, Steering, and Session State

The Kiro context window is the limited amount of information the selected model can consider for its next response. Project specifications and steering files can persist outside that window, but the conversation still needs the right material for the action it is taking now.

That separates two jobs: keeping the project record and supplying useful working context. fenbs can keep approved decisions and progress beyond a coding session; use its web app or a supported connected assistant to maintain that record, then bring a concise brief into Kiro yourself.

What is included in Kiro working context?

Think in terms of inputs to the next action: your request, relevant conversation, project instructions, attached material, and evidence gathered while working. These inputs compete for attention and space. Having a file in the project is different from establishing that its contents informed a particular answer.

Tokens are the pieces of text and other encoded input a model processes. They are the unit behind context capacity, rather than a count of repository files. The AI context window guide explains that distinction; the Kiro overview introduces the broader coding workflow.

For a concrete example, imagine changing password reset behavior. The active task needs the approved user experience, the relevant account code, and a check for the intended result. It probably does not need an earlier discussion about the marketing site or every resolved installation error.

How do specs differ from steering files?

Kiro describes specs↗ (opens in a new tab) as structured artifacts for turning feature and bug-fix ideas into implementation plans. They can capture requirements, design, and tracked tasks. Use them to make the expected behavior and planned work inspectable outside a stream of chat messages.

Its steering documentation↗ (opens in a new tab) describes persistent project guidance in Markdown files. Steering can explain conventions, libraries, and standards that should influence work repeatedly. Inclusion behavior depends on the configured mode and interface, so consult that documentation before assuming every instruction is always active.

Avoid putting the entire story in every layer. If the password reset feature changes scope, revise its current requirements and record the approval. A temporary debugging observation should not become a standing project instruction merely because it was useful once.

For decisions that people and other assistants need outside the repository, fenbs Decisions and rules provide a separate shared work record. Keep the source requirement clear so a later session does not choose between conflicting copies.

How should you check the actual session limit?

Check the model and the interface you are using before borrowing a capacity figure from another setup. A CLI example is not proof of an IDE control, and an older product screenshot is not a measurement of your session. Record the model identity when comparing results.

Kiro's compaction documentation↗ (opens in a new tab) describes a context usage meter and automatic summarization as conversations approach their model limit. It also distinguishes interface controls: the documented manual compact command applies to the CLI, while the IDE uses automatic compaction.

Use the visible meter as an observation, not as a quality score. A small request can omit the one exception that matters. A large request can still be coherent if its evidence is relevant and its requirements are consistent. Capacity tells you about room; review tells you whether the room contains the right information.

What changes when a conversation is compacted?

Compaction means replacing older conversation material with a shorter summary. Kiro describes preserving key goals, decisions, progress, and next steps while compressing intermediate details. That supports continuity, but it is still sensible to verify the details that determine your next change.

After a long investigation, ask the assistant to restate the current requirement, the files it changed, the checks it ran, and what remains unresolved. Compare that account with the repository and results. A missing error message or a misunderstood exception is a reason to supply the original evidence again.

Preserve exact details when exactness matters. A function name, a failing assertion, or a compatibility requirement may be more valuable than a polished paragraph about general progress. Summarize the exploratory discussion, but retain a path to the evidence behind the next decision.

When a session fits but repeatedly misses important instructions, investigate AI context rot. The broader cleanup process belongs in context window management; here the key is checking what survived into the next Kiro action.

What should survive the end of a coding session?

A useful stopping point describes the work rather than the conversation. Someone should be able to read it tomorrow and find the current requirement, the evidence, and the next safe action. Write it while the results are still available to check.

• The approved outcome and any behavior that must stay unchanged.
• The relevant spec or requirement and the files changed so far.
• Checks actually performed, their results, and checks still missing.
• Open decisions that require a person before implementation continues.
• The next action, including any environment or branch state it depends on.

For the password reset example, a checkpoint might say the new confirmation screen is implemented, its unit checks passed, and email delivery still needs verification. That is more useful than saying the feature is almost done. It directs the next session toward the remaining evidence.

How to do this with fenbs

1. Create a free account. Add a project and the task you are implementing in Kiro.
2. Write the task problem and current plan. Record a person's approved decisions separately from questions that remain open.
3. Use the web app or a supported assistant listed in Integrations to review the project context. Bring the concise requirements and checkpoint into the Kiro session.
4. After reviewing the changes, update task progress and Where we left off. Include the tests performed and the first thing the next session should verify.

fenbs does not increase Kiro's capacity or automatically collect its chat history. If your work is one local task with complete repository guidance, its specs and steering may be enough. A separate record helps when decisions and progress must reach teammates or another AI app.

On resuming, compare the handoff with the current code before acting; another person may have changed the files. Our AI handoff guide covers that transition, and the context engineering topic connects it to selecting better task inputs.