AI for your applications

ALYT lets you configure AI per application, either off, through ALYT local OSS120B for approved development use, or through your own provider key. AI starts disabled on every app. The dashboard page for the application links to AI settings and today’s usage, and the same page also lets you request local development access, create AI credentials, and review the daily token budget.

Configure AI for an application

Open AI settings and usage from the application dashboard. Create the connector app and finish its listing and specification first. Then choose one of three development modes: Disabled, ALYT local OSS120B — approval required, or My own provider.

Local AI use needs separate staff approval with a reason and a daily allowance. The page lets you submit that request, but signup and connector publication do not grant hardware use. Until approval is recorded, local development stays unavailable.

If you use your own provider, save these settings:

• a public HTTPS base URL
• the provider model ID
• your provider API key

The portal does not retrieve a saved key. It shows whether one is configured. Leave the key blank to keep the existing key. If you change the provider URL or the API format, you must replace or clear the saved key. Private addresses and redirects are refused.

The supported API formats are OpenAI-compatible Chat Completions and Anthropic Messages. For OpenAI-compatible APIs, max_completion_tokens is the default output-limit parameter; APIs that require max_tokens can select it. Anthropic uses its Messages output limit.

Saving your own provider for development records your consent to send sandbox requests to that provider. That consent applies only to the sandbox. You can also turn on Also allow my provider in production to let the same developer-owned provider serve production, but only after the separate publication, installation, and tenant consent checks are met. That switch never enables ALYT local AI in production. You may keep local development selected and still save a provider only for production.

AI credentials and inference requests

After saving settings, create a dedicated AI credential on the same page. Choose DEV for the development sandbox or LIVE for production installations. The app secret appears once. Exchange the App ID and that secret at POST /developers/oauth/token as described in the application credentials guide.

The resulting token has only ai:chat. Use a separate ordinary app credential for devices and connector management. Browser sessions and ordinary app credentials cannot perform inference. Rotate or revoke either credential from the Credentials page.

Send inference requests to POST /ai/chat with the AI token, an explicit tenantId, text messages, and optionally maxTokens. If you omit model, ALYT uses the saved settings. If you supply model, it must match the configured model. ALYT local requests always use OSS120B. A request cannot choose a runner URL or opt a tenant into cloud processing. Responses include model, privacy tier, latency, and usage.

The request limit is 64 messages and 64 KiB of JSON text. Include a user message. Valid roles are system, developer, user, and assistant. Maximum output is 4,096 tokens, with 1,024 by default. The platform allows one bounded provider attempt, with a 60-second deadline and no automatic retry or fallback to another provider or account.

Production use and tenant consent

LIVE AI requires all of the following:

1. developer production enablement
2. a published connector version declaring own_cloud
3. that version installed in the requested tenant
4. recorded tenant consent to cloud inference

An installed deprecated version continues to honor its own declaration. New LIVE credentials require an approved or currently published cloud-AI version. An approved credential cannot perform production inference until the published version is installed and customer consent is recorded. If a key, local approval, account access, production enablement, or tenant consent is revoked, subsequent requests fail even when the access token has not expired.

The consent setting applies to a whole tenant, not just one home. A tenant ADMIN or ALYT staff can record the decision through PATCH /tenants/:tenantId/inference-consent, supplying enabled and reason. Developer identities and app credentials cannot set it. Staff have a consent control on the portal review page and must identify the decision maker and consent record. No real tenant is opted in automatically by deployment.

Usage, budgeting, and limits

All AI calls routed through ALYT are measured per developer, app, environment, source, and UTC day. The usage view shows accepted attempts, failures, in-flight calls, input and output tokens, charged allowance, estimated calls, and total latency. Gateway request traces also record refusals. Prompts, replies, and provider keys are excluded from usage records. Calls your connector makes directly to a provider, outside ALYT, cannot appear here.

Before contacting a provider, ALYT reserves a conservative token amount and checks the remaining allowance in a database transaction. The reservation includes text bytes, message framing, and the output cap. Provider-reported input and output counts replace it after completion. Anthropic cached input is included. Missing token counts, failed calls, and interrupted workers keep their reservation and are labeled estimated, because the provider may have consumed tokens. Usage is accounting, not a provider invoice or a currency conversion.

The app budget defaults to 200,000 tokens per UTC day. Own-provider budgets apply separately to DEV and LIVE. ALYT local usage shares its staff-approved daily ceiling across the developer’s apps, so extra apps cannot multiply an allowance. Local access allows one developer request at a time across the platform, sharing the slot with connector review. Staff can set 1–30 requests per minute per developer, default six, and 1–4096 output tokens per call, default 4096. An omitted output limit is clamped to the grant; explicit values above it are refused. Own-provider access allows two concurrent requests and 60 requests per minute per developer. A rejected allowance or capacity check returns 429.

These are admission limits, not a preemptive household scheduler. An already running local developer request is not interrupted when a household voice turn arrives. Grant small allowances while the model is shared with household use.

Access boundaries and what the page shows

DEV credentials act in the developer sandbox. LIVE credentials work only for their own installed connector and require the production checks above. Household permissions are narrower than staff, so production consent and review actions can require staff where the portal says so.

On the page, you see the current AI mode, whether a provider key is configured, the production-allow switch, the daily token budget, the local approval state, the one-time AI secret, and today’s usage table. You can save settings, request local AI access, create an AI credential, rotate or revoke credentials elsewhere, and refresh usage.

Useful workflow

1. Create and publish the connector application.
2. Open AI settings and usage.
3. Choose Disabled, ALYT local OSS120B — approval required, or My own provider.
4. If needed, request local AI access and wait for approval.
5. If using your own provider, save the HTTPS base URL, model ID, and provider key.
6. If needed, enable production use and complete the publication, installation, and tenant-consent checks.
7. Save settings.
8. Create a DEV or LIVE AI credential.
9. Exchange the App ID and secret for a token.
10. Call POST /ai/chat with tenantId, messages, and optional maxTokens.

Usage page

The separate Usage page shows this month’s ceilings and use per unit, plus per-key totals. For AI, it links back to daily budgets and usage by app. Every API response also carries the IETF RateLimit and RateLimit-Policy fields, so your code can see the same numbers before it reaches the limit.