The sandbox and AI inside it
A developer sandbox is a real tenant with its own property, rooms, and virtual devices. It uses the same tenant isolation, broker permissions, and query narrowing as production, so the sandbox behaves like a normal home from the API point of view, but only within your sandbox tenant. You activate it by verifying your email, and then the page shows the tenant and property identifiers you use in calls. DEV app credentials work only in the sandbox. LIVE credentials work only for their own installed connector in customer tenants.
What the sandbox shows
Section titled “What the sandbox shows”After activation, the sandbox page displays the home name, tenant id, property id, rooms, and the devices in those rooms. If the sandbox is not provisioned yet, the page tells you that it appears when your email is verified. For each room, you see the room id and any devices assigned to it. For each device, you see its name, kind or capabilities, status, and last seen time. Device status appears as online, offline, or a warning state.
Use the ids shown on the page in your API calls. The sandbox is a PLATFORM-hosted property, and the same routes a household console calls are narrowed to this tenant. The simulator supplies virtual lights, climate devices, and sensor devices. You can observe telemetry, change state, and exercise connector lifecycle flows without owning hardware.
Start with virtual devices
Section titled “Start with virtual devices”Create your app, its connector listing, and its specification before issuing credentials. Then use the simulator-backed sandbox to test against the real broker and device APIs. Real sandbox devices register through the public TLS broker. Internal services use the internal broker route and must not loop back through the public address; the simulator handles that automatically.
A successful synthetic test does not prove physical device behavior. The sandbox is useful for development and API validation, but it does not replace testing with real hardware when device-specific behavior matters.
AI is an app setting
Section titled “AI is an app setting”AI starts disabled. Open the AI settings and usage view on an application tile to choose the development source and create a dedicated AI credential. Normal connector credentials and browser sessions do not authorize inference.
Three development sources are available:
| Source | Development | Production | Whose provider account |
|---|---|---|---|
ALYT local OSS120B | Explicit staff approval and a daily allowance | Unavailable | No external account |
| Developer-owned provider through ALYT | Developer supplies URL, model, and key | Separate production switch, publication, installation, and tenant consent | The developer’s |
| Direct calls from the connector to its own model | Controlled by the developer | Must be accurately declared and reviewed | The developer’s |
ALYT never provides external AI accounts to developers. There is no automatic cloud fallback. You may use ALYT local OSS120B during development and your own provider in production, or use your own provider only during development.
Provider keys saved through ALYT are encrypted and write-only. The portal shows whether a key exists and offers replacement or removal, never retrieval. When you choose a developer-owned cloud provider for the sandbox, consent is recorded only for that sandbox. Customer production requires separately recorded tenant consent and a published connector declaring cloud AI.
Metering and privacy
Section titled “Metering and privacy”Use POST /ai/chat with the dedicated AI credential to include requests in ALYT’s accounting. The app usage page separates DEV from LIVE and local from own-provider calls. It shows tokens, calls, failures, latency, and conservative estimates when a provider cannot report usage. Prompts and replies are not stored in usage records.
Direct connector-to-provider calls outside ALYT cannot be measured by ALYT. Hosted BYO provider endpoints must be public HTTPS addresses; ALYT does not connect to a developer’s private LAN endpoint. The connector can call its own private local model directly outside this route.
Access limits and availability
Section titled “Access limits and availability”ALYT local access is capped across all a developer’s applications. Only one local developer request is admitted at a time across the platform, and there is no unbounded queue. This protects capacity, but it does not preempt a running model request for a household voice turn. Shared hardware is finite, so explicit approval and small allowances remain required even when access is free for now.
Local functions can keep working during a cloud outage. Cloud-dependent connectors require the provider and network, and cloud AI paths are unavailable when that path is unavailable. Household permissions are narrower than staff permissions. DEV credentials act in the developer sandbox, and LIVE credentials only for their own installed connector.