> 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/scoping-requests-to-reduce-token-waste.md). # Scoping requests to reduce token waste Every token Cursor spends reading files it did not need, rebuilding something that already existed, or exploring the wrong part of the codebase is a token it is not spending on your actual task. Scoping your requests tightly — asking the right question at the right time, in the right part of the project — is one of the most practical ways to keep sessions fast, accurate, and long-lasting. ## The Core Explanation ### Ask before you build The single highest-leverage habit in AI-assisted Sandbox Studio development is asking whether something already exists before asking for it to be built. This takes one message. Building something that turns out to duplicate existing engine functionality, or an existing project file, can take ten. Before asking Cursor to implement a feature, ask it to check first. "Does Sandbox Studio already have a way to handle player damage? Check the engine source before answering." If the answer is yes, your next prompt is "use that" rather than "build this from scratch." You have saved the tokens that would have gone into implementing, reviewing, and potentially debugging a duplicate system. This applies to the project as well. "Is there already a node in this project that manages pickup behaviour? Check before we build a new one." Cursor can search the codebase in seconds. The cost of asking is negligible. The cost of not asking is a second implementation of something that was already there. ### Check the engine before building anything custom Sandbox Studio ships with a significant amount of built-in functionality. The UI kit covers HUDs, health bars, minimaps, crosshairs, counters, inventory displays, and more. The multiplayer system handles replication, RPCs, and server authority. The property serialisation system manages save/load and editor exposure. SceneNodes give you a complete scene hierarchy. Before building any of these things yourself, verify whether the engine already provides them. "Check the engine source in `.engine` — does Sandbox Studio have a built-in way to display a health bar?" costs almost nothing. Building a custom health bar UI when `BaseUIComponent` already covers it wastes tokens on implementation, risks diverging from engine conventions, and adds code to the project that will need maintaining. {% hint style="info" %} *NOTE: The Sandbox Studio UI kit is the first place to check for any in-game HUD element. The widget catalog at `.agents/skills/genesys/genesys-ui-kit/references/catalog.md` lists every shipped widget. Asking Cursor to check there before building custom UI is a reliable token-saving habit.* {% endhint %} ### Scope the search, not just the task When you ask Cursor to look for something, give it a specific place to look. "Check the src folder" is faster and cheaper than "check the whole project." "Look at how `HealthPickup.ts` handles events" is cheaper than "look at all the node files for how events work." Cursor reading twenty files to answer a question that was in one file is token waste. The more specific you are about where the answer is likely to live, the less Cursor has to search, and the more of its context window stays available for the actual work. When you do not know where to look, ask Cursor to identify the most likely location first — one message — then read that location. Two short messages is almost always cheaper than one broad one. ### Extend rather than replace When something similar to what you need already exists in the project, extending it is almost always the right move — cheaper in tokens, better for architecture, and consistent with the patterns already established. Ask Cursor to identify the closest existing implementation and assess whether it can be extended before it starts building anything new. "Is there an existing node in this project that already handles collision detection? If so, can we extend it for this feature rather than building a new one?" This one question can redirect Cursor from a multi-file implementation to a targeted addition to an existing file. The same principle applies to prefabs. If your project has a prefab that is close to what you need, extending or duplicating it is far more efficient than building from scratch. Cursor can check the `assets/prefabs` folder to see what exists. ### Ask for the minimum, then expand Scope the initial implementation to the core behaviour only. Get that working, verify it, then add complexity in a second scoped request. Asking for a complete feature with all edge cases, animations, UI feedback, sound triggers, and multiplayer support in a single prompt produces a long, expensive response that is harder to verify and harder to correct if something is wrong. "Build the basic damage application logic for the health component first — no effects, no events, just the core value change" is a better first prompt than "build the complete health system with damage effects, death events, UI feedback, and network replication." You can add each of those in a subsequent focused session, once the foundation is verified. This also means that when something goes wrong, you know exactly where it went wrong. A small, scoped implementation has fewer places for an error to hide. ### Verify against the engine before writing new code When Cursor is about to implement something, a brief verification step before it writes code costs almost nothing and prevents a common category of waste: implementing something in a way that conflicts with how the engine already handles it. "Before writing this, confirm that the engine does not already provide this functionality and that your approach aligns with how the engine handles similar systems" adds one step and removes a significant failure mode. ## Practical Guidance * Before asking Cursor to build anything, ask if it already exists — in the engine, in the project, or in the `assets/prefabs` folder. * Check the Sandbox Studio UI kit before building any HUD element. The engine ships with widgets for the most common in-game UI needs. * Give Cursor a specific directory or file to search rather than asking it to explore broadly. * When something similar exists in the project, ask if it can be extended rather than replaced. * Scope the first implementation to core behaviour only — verify it works, then add the rest in separate focused sessions. * Ask Cursor to verify its approach against the engine source before it starts writing — one instruction, saves a correction cycle. * Use the prefabs in `assets/prefabs` as a starting point where applicable — Cursor can check what is there before building from scratch. {% hint style="info" %} *TIP: The most efficient prompt pattern for a new feature is three steps: (1) "Does this exist already?" (2) "Here is what I need — plan how you would build it." (3) "Build it." The cost of steps one and two is small. The saving when they catch a wrong direction is large.* {% endhint %} ## Common Mistakes | Mistake | What to do instead | | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Asking Cursor to build something without checking if the engine already provides it | Always ask "does Sandbox Studio already have this?" before starting implementation | | Asking Cursor to search the whole project when you know roughly where the answer lives | Point it to the relevant folder or file — specific is cheaper | | Building custom UI when the Sandbox Studio UI kit already covers the use case | Check the UI kit catalog first; use the engine widget and customise if needed | | Requesting a fully-featured implementation in a single prompt | Scope to core behaviour first; add complexity in subsequent focused sessions | | Building a new system when an existing one could be extended | Ask Cursor to find the closest existing implementation and assess whether extension is possible | | Skipping the "does this exist" check to save time | It costs one message; finding out you duplicated something costs far more | The cheapest code to write is code that already exists. Before Cursor builds anything, give it thirty seconds to confirm that you actually need to build it — and if you do, that it is building the minimum required to get started. --- # 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/scoping-requests-to-reduce-token-waste.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.