Academy
6. Security, Costs, and Best Practices
Understand sandbox isolation guarantees, monitor AI-credit and execution-time costs in real time, and apply best practices for efficient, cost-aware building.
Sandbox Isolation: What It Guarantees
Every Code Builder project executes inside a fully isolated cloud sandbox. This means:
• Machine isolation – The sandbox has zero access to your local filesystem, environment variables, or running processes. Nothing you build can touch your dev machine. • User isolation – Your sandbox is walled off from every other user's sandbox. There is no shared memory, storage, or network namespace between projects of different users. • Ephemeral by design – The runtime exists only to serve your project. The live preview renders the result beside the conversation, but the execution environment itself is disposable.
For advanced developers accustomed to Docker or VM-level isolation: think of the sandbox as a comparable boundary, but fully managed — you never configure networking rules or mount points. The platform handles it.
This architecture lets you safely test AI-generated code — including code that performs file I/O, spawns processes, or opens ports — without risk to your own infrastructure.
Understanding the Two Cost Dimensions
Code Builder charges across two axes, both visible in real time as you work:
- AI credits – Consumed every time the AI generates or iterates on code. Each conversational turn ("add dark mode", "refactor the API layer") costs credits proportional to the generation work.
- Sandbox execution time – The clock runs while your project is alive in the sandbox and the live preview is active. Longer-running or compute-heavy projects accumulate more execution-time cost.
Because costs are displayed as you go, you can monitor spend mid-session and decide whether to continue iterating or download the current state and finish locally.
Keep iterations atomic to save credits. Ask for one change per message ("make the header sticky") rather than bundling five changes. Atomic requests reduce failed generations and wasted credits, because the AI can apply and verify a single, well-scoped edit more reliably.
Choose the right execution profile before you start. Profiles define the runtime and capabilities of your sandbox. Picking the wrong one (e.g., a lightweight profile for a heavy backend) can cause failures that cost credits to debug. Set profiles in builder settings and match them to your project type upfront.
Best Practices for Cost-Aware Building
• Front-load your brief. A detailed initial description — purpose, screens, key behaviors — produces a closer first version and fewer paid iterations afterward. • Review generated files before iterating. Open the workspace file view to understand what the AI wrote. Sometimes a manual tweak after download is cheaper than another AI round. • Download early, iterate locally when appropriate. The generated files are yours. If the remaining work is routine (CSS polish, config changes), export and finish in your own editor to stop the execution-time meter. • Monitor costs in-session. Because spend is visible as you go, set a personal budget per session and check it between iterations.
Open Code Builder, start a small project, and watch the cost indicators as you iterate. After two or three conversational turns, open the workspace file view to review the generated code, then download the files. This gives you a concrete feel for credit consumption and the export workflow.
Code Builder's sandbox guarantees full isolation from your machine and from other users — safe for any generated code. Costs split into AI credits (per generation/iteration) and sandbox execution time, both visible in real time. To build efficiently: write a thorough initial brief, iterate one change at a time, pick the correct execution profile, review files in the workspace before requesting more AI rounds, and download early when remaining work is routine. These habits keep quality high and spend predictable.