# How Do You Prevent Long Coding Sessions from Losing Context? > Prevent context loss by moving durable facts out of chat and into a compact task ledger, decision log, test record, and repository checkpoints. Refresh the agent from those artifacts before compression or model changes instead of replaying an unbounded transcript. Long sessions usually fail through drift rather than sudden amnesia. The agent remembers the broad goal but loses a small constraint, trusts an obsolete test result, repeats an investigation, or edits from a plan that no longer matches the repository. The remedy is a durable external state that is shorter and more reliable than the transcript. Treat conversation as working memory and the repository as the source of truth. At each meaningful checkpoint, write down what changed, what is verified, what remains uncertain, and what should happen next. ## Track four kinds of context Separate facts by function so a summary does not become an undifferentiated story. | Context type | Examples | Durable location | |---|---|---| | Goal | User outcome and acceptance criteria | Task ledger | | Constraints | Compatibility, safety, style, scope | Task ledger | | Repository state | Files changed and current branch | Version control | | Evidence | Tests, logs, screenshots, benchmarks | Verification record | Add assumptions as a fifth category only when clearly labeled. An assumption should include the cheapest action that can confirm or reject it. ## Maintain a compact task ledger A useful ledger fits on one screen. Update it after milestones, not after every message. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Keep exact paths, commands, and failure names. Avoid a diary of how the discussion unfolded. ## Checkpoint around verified state A checkpoint should follow a result the next session can reproduce. Good boundaries include a passing test group, a small committed change, a confirmed API response, or a design decision backed by a fixture. Record dirty files before switching models or compressing context. Do not claim a feature works because code was written. Link the claim to a test, build, or observable artifact. | Claim | Evidence needed | |---|---| | Parser supports two calls | Fixture with two correlated call IDs | | Retry is safe | Idempotency test under disconnect | | Refactor preserves behavior | Existing and new test suites pass | | UI is correct | Rendered inspection at target sizes | ## Retrieve source instead of replaying chat When a detail matters, reopen the current file, schema, or official document. Old transcript excerpts can describe code that has since changed. Give the agent paths and search terms so it can inspect the latest state. Retrieval should be narrow. Load the interface, its implementation, the failing test, and the relevant log before loading an entire repository. This leaves room for reasoning and reduces distractions. ## Compress by preserving decisions and evidence A good compression removes conversational repetition while retaining constraints, irreversible decisions, rejected alternatives, and verification. It should distinguish `verified`, `observed`, `assumed`, and `pending`. Do not summarize a failed experiment as if it were the final design. Keep the reason an option was rejected when the same tempting approach could reappear later. ## Bound tool output before it enters context Long logs and generated files consume attention quickly. Ask tools for relevant ranges, counts, or matched lines. Store full output as an artifact and return a short digest with a path. Apply the same rule to test failures: keep the first useful stack trace, the failing assertion, and environment details. Avoid sending hundreds of repeated frames back into the model. ## Resume with a deterministic ritual After a pause, context compression, or model switch: * Read the objective and constraints. * Inspect version-control status and recent changes. * Open files named in the current-state section. * Rerun the last relevant check. * Confirm the recorded next action is still valid. This routine catches stale summaries before they cause new edits. ## Choose models without relying on transcript memory A gateway makes model switching easier, but state remains your responsibility. Atlas Cloud offers multiple LLM protocols from one base URL; check the [protocol matrix](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) and the current [model catalog](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) before moving a live agent. Give the replacement model the task ledger, relevant source files, and a fresh verification result. Avoid depending on provider-specific state handles unless the same protocol and behavior are confirmed. ## The bottom line Long coding sessions keep context when durable state is concise, evidence-backed, and easy to reload. Maintain a one-screen ledger, checkpoint around verified changes, retrieve current source instead of replaying chat, bound tool output, and use a deterministic resume routine. A larger context window helps, but disciplined external state is what makes the work recoverable. ## FAQ ### Is a larger context window enough for a long coding session? No. More space delays pressure but does not guarantee that old constraints remain salient or that stale observations are corrected. ### What belongs in a coding-session ledger? Record the objective, constraints, current plan, changed files, key decisions, verification results, unresolved risks, and the exact next action. ### How often should the agent create a checkpoint? Checkpoint after a meaningful state change such as a passing test, completed migration step, design decision, or discovery that changes the plan. ### Should I paste the whole transcript into a new model? Usually not. Provide a curated checkpoint plus the relevant source files and logs, then let the new model inspect current repository state. ### How do I prevent summaries from preserving an old mistake? Separate verified facts from assumptions, attach evidence such as commands or file locations, and retire claims when new tests contradict them. ### What is the safest way to resume after interruption? Reload the task ledger, inspect version-control status, rerun the last relevant verification, and start from the recorded next action.