> For the complete documentation index, see [llms.txt](https://studio-docs.sandbox.game/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://studio-docs.sandbox.game/working-efficiently-with-ai/when-to-start-a-new-chat.md). # When to start a new chat ## **The Problem** Most creators run one long chat session and wonder why the AI starts making mistakes or going in circles. The problem is the session, not the AI. Knowing when to start a fresh chat is one of the most practical habits in AI-assisted development. ## **Why Sessions Degrade** Every new chat gives the AI a completely clear context window. No accumulated history, no files loaded from three tasks ago, no earlier decisions quietly contradicting what you are asking for now. A long-running session drifts. Each exchange adds weight. After enough back-and-forth, the AI is reasoning under the influence of every prior message, including the ones where it misunderstood something, went down a wrong path, or produced code you rejected. That noise stays in the window and affects every subsequent response. Starting a new chat is not starting over. With a handover summary, it is a clean transfer of the right information into a fresh working environment. {% hint style="info" %} *TIP: Ask the AI to write the handover summary. Give it the structure: what was built, what decisions were made, what files changed, what comes next. It will produce it in under a minute. Copy it, open a new chat, paste it as your first message.* {% endhint %} ## **When to Start a New Chat** ### **The context window is degrading** If the AI is repeating itself, contradicting earlier work, forgetting instructions, or producing code that ignores something it knew twenty messages ago, the window is full. Stop the session and do a handover. The longer you push past this point, the worse the outputs get. ### **You are starting a new feature** Every distinct feature deserves its own session. The AI does not need to carry the implementation details of your inventory system into a session about enemy spawning logic. Give the new feature a clean start and reference only the files that are relevant. ### **You are debugging** Debugging is a contained task with a specific input and a specific output. A dedicated session lets you describe the problem clearly, reference the relevant file, and get a precise response without the AI weighing it against everything else built this session. ### **You are doing a review or optimisation pass** Bug-finding, performance work, and code quality passes all benefit from fresh eyes. A session that already wrote the code is less reliable at critically reviewing it. Start fresh, share the relevant files, and let the AI read what exists rather than what it remembers building. {% hint style="info" %} Each Sandbox Studio system has its own skill file. When switching between systems, starting a new session means the AI loads only what is relevant to the current task. {% endhint %} ### **You are switching Sandbox Studio systems** Sandbox Studio is modular. If you have spent a session on player movement logic and now want to work on the UI kit, start a new chat. The AI will load the right context for the job rather than carrying skill data that no longer applies. ### **The session has gone off track** If you have spent several exchanges correcting a mistake and the AI keeps returning to the same wrong approach, reset. A new session with a clear prompt and only the relevant files will get further in two messages than another ten in a degraded one. ## **Practical Guidance** * One session per task. A new feature, a debug pass, a review, and an optimisation pass are four separate sessions. * Before closing any session that produced meaningful work, write a handover summary: what was built, what decisions were made, what files changed, what comes next. * Open every new session with a single-sentence intent. "I am debugging the enemy spawner in EnemySpawner.ts, enemies are not respawning after the first wave." Not "let's continue where we left off." * Reference only the files that matter to the current task. Let the AI ask for what it needs. * Treat a reset as a tool, not a failure. Ending a degraded session is the right move, not a last resort. ## **Common Mistakes** | Mistake | What to do instead | | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Continuing a session after the AI starts contradicting itself or forgetting instructions | Treat this as the signal to write a handover and start fresh | | Asking the AI to build, debug, and optimise all in one session | Split each into its own focused chat | | Starting a new chat with no context and re-explaining everything from memory | Write a handover summary at the end of every productive session and paste it at the start of the next | | Asking the AI to review code it wrote in the same session | Open a fresh session for review passes; the AI has no attachment to code it has not seen before | | Thinking a new chat means losing progress | Nothing is lost. Your code is in the files; the handover summary carries the plan | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://studio-docs.sandbox.game/working-efficiently-with-ai/when-to-start-a-new-chat.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.