Track B — Try an actor in the sandbox

](en/track-a/setup-and-generate/) asks you to install Python, copier, and Docker. Track B does not. You stay inside the Kaoohi app, work through forms and conversation, and the platform runs everything for you.

What the kreator sandbox is

The kreator sandbox is an ephemeral kompanion: a temporary running instance of an actor that the platform starts for you — and tears down for you. Three properties define it:

1. It runs your actor draft. The sandbox starts the image you registered, so you talk to it the way an end user will.
2. Connectors run in mock mode. The sandbox kompanion starts with its connectors mocked. Tools that would call external services get mock responses instead. No real external call leaves the sandbox.
3. It is time-limited. Every sandbox has a time-to-live. When it expires, the sandbox disappears — the platform reaps it, and nothing persists.

A sandbox is a kompanion in every other sense: it serves the same chat endpoint, the same configuration, the same declared parameters. It is just short-lived and deliberately cut off from the outside world.

When to use the sandbox

• Trying ideas. You want to feel how an actor behaves before investing in a full build.
• Form-based customization. You want to see how different parameter values change the actor’s behavior, through the rendered form.
• Pre-approval testing. You have a draft actor and want to exercise it before you submit it for review.

Try an actor

The flow, from draft to conversation:

1. Register a draft. In the Creator Hub, register your actor from its image reference. The platform pulls the OCI image, extracts the actor config baked inside it, and validates it (the wizard walkthrough lives in ](en/publishing/)). Save the result as a draft — you do not submit anything for review yet.
2. Start a sandbox for the draft. The platform launches an ephemeral kompanion in sandbox mode. This may take a moment; a container is starting.
3. Talk to it. Chat with the sandbox the way your future users will. Walk through the workflows you care about. Mock connectors answer with fake data — enough to check that the flow, the prompts, and the parameter handling make sense.
4. Let it expire — or move on. When the time-to-live runs out, the reaper tears the sandbox down. This is normal. Start a fresh one whenever you need another round.

The exact screens may evolve; the flow above is the contract. Where you see it in the app, that is the shape it takes.

Customize through forms and parameters

Your actor’s parameters are declared in its config, baked into the image at build time. The platform renders those declarations as a form — each parameter appears with the widget its author gave it (text, choice, toggle, and so on).

In the sandbox, parameter customization is your main lever:

• Change parameter values through the form and observe how the actor’s behavior shifts between runs.
• Check that the parameters your users will see are the ones that matter — the registration step warns when an actor declares a very large number of parameters (more than fifty). A form that size is a signal to simplify.
• Remember that the form reflects what is in the image. Changing values is a sandbox activity; changing which parameters exist means changing the actor’s code and building a new image.

The honest limits

The sandbox is real and works today — within these bounds:

Limit	What it means for you
Mock connectors only	No real external calls. A booking tool will not book anything. You validate flows and shapes, not real data. Only connectors the platform can mock are wired up in the sandbox.
Time-to-live	At the time of writing the default policy caps a sandbox at around 30 minutes, and lets you run two sandboxes at once. When time is up, everything is gone — including conversations.
Budgets	Each sandbox session has a token budget, and platform-wide sandbox capacity is small. You may be refused if limits are hit; try again shortly after.
Restricted egress	The sandbox cannot reach arbitrary network endpoints.
Not a development environment	You cannot edit code, add tools, or run tests inside the sandbox. It runs the image you registered — nothing else.

One more limit worth naming plainly: the sandbox does not build images. It runs an image that already exists. Producing that image — writing the actor, generating the project, building and pushing — is Track A or the AI path.

From sandbox to marketplace

The sandbox sits early in the publishing funnel:

1. An actor image with its config baked in is pushed to a public registry (GHCR by default).
2. You register the image reference in the Creator Hub. The platform pulls the image, extracts the config, and validates it.
3. You save the actor as a draft and test it in the sandbox — this is your pre-approval safety net.
4. You submit for review. Once approved, the actor appears in the marketplace and users can deploy their own kompanions of it.

The full registration wizard, the review statuses (draft, pending_review, approved, rejected, revision_requested), and what happens after approval are covered in ](en/publishing/). Two facts worth knowing while you are still in the sandbox: you follow review progress in My Actors — there are no notifications yet and no published review SLA, so check back yourself — and if you update the config of an already-approved actor, the live listing keeps the old config until the update is re-approved.

When to graduate

Stay in Track B while you are evaluating and tuning parameters. Move on when:

• You need real external calls. Mock connectors cannot confirm a real integration. Real credentials live in real kompanions of approved actors — and in local development.
• You need code changes — new tools, new prompts, new parameters. That is ](en/track-a/setup-and-generate/) (generate and edit the project yourself) or the ](en/ai-path/), where a Claude Code skill writes the actor with you.
• You need longer sessions or persistence. Sandboxes are short-lived by design; a real kompanion is the durable home.

If code is the thing you want to avoid, look at the ](en/ai-path/) first: it asks structured questions, then generates and implements the actor for you. The sandbox then becomes the place you test what it produced.