The sandbox and AI inside it
The developer sandbox is a real ALYT tenant with the same isolation and request shape as production, but with smaller visibility and a hard ceiling from day one. It is free for now, yet it still has to protect the house that runs it: the household’s own voice turns keep priority, the cloud can go down without stopping the house, and a DEV key stays in the sandbox while a LIVE key only works for its own connector. AI in the sandbox reaches developer code in three ways: ALYT’s local AI through POST /ai/chat, the developer’s own cloud AI key, or the developer’s own local AI endpoint.
What the sandbox is
Section titled “What the sandbox is”A sandbox is not a toy environment. It is a real tenant with the same isolation boundaries and broker ACLs as production, and the same query narrowing developers rely on in the platform. It is seeded with a property and rooms so the first request has something meaningful to address. It also includes virtual devices, so a developer without ALYT hardware can still watch telemetry arrive and a command take effect.
That realism matters because a sandbox that behaves differently from production teaches the wrong lesson. The limits are enforced the same way in both places, even though the sandbox is free.
Free does not mean unbounded
Section titled “Free does not mean unbounded”The sandbox is free because the portal is still new, not because it costs nothing to run. It runs on hardware in the house, not on someone else’s cloud, so free access still needs a ceiling.
That ceiling exists to protect the house first. A developer’s request may queue or be shed if needed, but the household’s own voice traffic may not lose priority. The platform keeps working when the cloud is down, so routing to the cloud is never the default path for the house itself.
For a developer sandbox, cloud routing is the right default only when it protects local hardware. The sandbox is exactly the place where the platform can prefer a metered cloud provider over local GPU use if needed. The key point is that free means no charge, not no limit.
AI reaches a developer in three ways
Section titled “AI reaches a developer in three ways”| # | Path | Costs ALYT | Gate |
|---|---|---|---|
| 1 | ALYT’s local AI through POST /ai/chat | yes — GPU or the Mac | a dedicated per-developer key, minted only after explicit approval |
| 2 | The developer’s own cloud key | nothing | none beyond the sandbox itself |
| 3 | The developer’s own local AI endpoint | nothing | none |
ALYT’s local AI
Section titled “ALYT’s local AI”This path uses ALYT’s own local inference capacity, so it is the one that consumes the house’s hardware. It is routed through POST /ai/chat and it needs a dedicated per-developer key. That key is minted only after explicit approval.
This is the narrowest path because it is the only one that spends ALYT’s resources. It is also the path that benefits most from a queue or quota, because a free sandbox still needs to meter use.
The developer’s own cloud AI key
Section titled “The developer’s own cloud AI key”A developer can bring a cloud model provider they already use and supply their own key. In that case ALYT does not pay for inference. The key is handled as write-only platform data: stored, never returned, and never logged.
The sandbox’s cloud setting remains a tenant-level decision, not a request parameter. That keeps one request from changing inference routing for another tenant. If a developer wants their sandbox to use cloud inference, that decision belongs to the sandbox configuration.
The developer’s own local AI endpoint
Section titled “The developer’s own local AI endpoint”A developer can also point the sandbox at a model running on their own machine. That path also costs ALYT nothing. It follows the same integration-credential rule: the value is stored and not exposed back through the API.
What developers need to know about the boundary
Section titled “What developers need to know about the boundary”A connector that uses a cloud model must declare that in its descriptor before installation. The portal needs to show that clearly, because a household using ALYT to keep audio and inference in the house has to see the cloud dependency before they approve it.
That is a product boundary as much as a technical one. ALYT’s promise is local-first behavior, so a connector that silently routes household data to a third-party model conflicts with the platform’s purpose.
Practical rules for sandbox AI
Section titled “Practical rules for sandbox AI”- The sandbox has a ceiling even when it is free.
- House traffic wins over developer inference.
POST /ai/chatis the local ALYT AI path.- A dedicated per-developer key is required for ALYT’s local AI and is minted only after explicit approval.
- Developers can bring their own cloud key or their own local AI endpoint.
- Cloud inference is a tenant decision, not a request parameter.
- A published connector that calls a cloud model must declare that in its descriptor.
- The sandbox remains a real tenant, so it follows the same isolation and limit behavior as production.