Providers and operations

Provider configuration

Providers can be configured as organization defaults with project-level overrides. The `llm` provider powers the UnrealOS in-editor chat through native OpenAI, Anthropic, Google Gemini, and Azure OpenAI adapters. Each named provider connection owns its discovered model catalog, so multiple providers and models can coexist for future agent/tool routing. Discover models from the provider to load current model IDs, context limits, pricing, and capabilities, then store credentials only through the secure provider settings flow; never paste them into a browser-visible note. Provider responses should be bounded, observable, and associated with an editor session.

• Test a provider before enabling it for production.
• Use explicit timeouts and retry policies.
• Keep provider URLs and access policy reviewed by an organization administrator.
• Treat provider health as a signal, not a guarantee of successful work.

Operation lifecycle

Long-running work is queued rather than held open in an API request. The operation timeline records transitions, progress, provider events, failures, retries, and artifacts. The dashboard should make the current state understandable without exposing raw secrets or credential-bearing payloads.

planned → running → succeeded
                    ↘ failed
                    ↘ cancelled

Artifacts

Large outputs belong in object storage. The API returns short-lived signed download URLs only after verifying project access. Artifact metadata can be retained for audit and discovery, while the underlying object should follow the project’s retention policy.