Provider adoption

Make Luma Cloud show up as a native provider, one client at a time.

Manual OpenAI-compatible setup works today. Native listings should ship only after conformance, support, pricing, and legal gates are clean.

API setup

Provider contract

Luma Cloud

Provider id luma-cloud; candidate default family gpt-5.5; at most 25 candidate ids.

Every external submission should reference the public endpoint, request-id support flow, and authenticated dynamic model catalog.

The candidate table is documentation, not an availability promise; each credential receives only its fresh verified subset.

Do not submit internal bridge topology, local OmniRoute routes, hidden account pool details, or raw API keys.

Public artifacts already exposed

These URLs are the source material for native-provider submissions and partner review.

Provider discovery

https://api.lumaos.cloud/.well-known/lumacloud-provider

OpenCode discovery

https://api.lumaos.cloud/.well-known/opencode

Authenticated model catalog

https://api.lumaos.cloud/v1/models

Deployment readiness

https://api.lumaos.cloud/readyz

Process liveness

https://api.lumaos.cloud/healthz

Support docs

/docs/support

Error docs

/docs/errors

Targets

Submission lanes

Treat each native listing as a small PR with evidence, not as marketing copy.

First native-listing target

OpenCode / Models.dev

Submit Luma Cloud provider metadata, model metadata, support links, and an OpenAI-compatible config example after public v1 conformance passes.

Required artifacts

provider.toml, model TOML files, logo asset, docs links, streaming smoke evidence

Already hosted

OpenCode remote defaults

Keep /.well-known/opencode aligned with provider-registry output so custom-provider builds can import the same provider shape.

Required artifacts

/.well-known/opencode, /api/downloads/opencode/config, secret-free provider skeleton

Config example first

Continue / VS Code

Publish a copy-safe OpenAI-compatible model block and then pursue a Hub/example listing if the current Continue registry path supports third-party providers.

Required artifacts

config.yaml block, env secret naming, chat/edit smoke evidence

Manual provider ready

Cline and Roo Code

Use OpenAI Compatible provider screens first. Submit docs/preset PRs only after streaming and tool-call behavior are verified in current client builds.

Required artifacts

base URL, model id, key field, stream=true smoke, tool-call smoke

Manual custom API path

Cursor

Document custom OpenAI-compatible base URL setup. Native provider submission remains gated on Cursor's available extension/provider marketplace path.

Required artifacts

base URL, model id, API key, editor-agent smoke, fallback note

Settings template ready

Zed

Maintain a settings example with api_url and available model ids. Submit docs/example PR only after current Zed assistant behavior is smoke-tested.

Required artifacts

settings JSON, available_models list, streaming smoke evidence

Gate list

Do not submit until these are true.

This prevents external clients from listing a provider whose setup, support path, or product promise is not ready.

Submission checklist

Run these before opening or approving any external provider PR.

GET /readyz confirms both Postgres and fresh signed exact-model capacity.

GET /healthz remains a liveness check only; it is not sufficient for release.

Authenticated GET /v1/models returns a subset of the documented candidate ids for the test credential.

Every advertised native family contains its base id and default medium effort; omitted efforts remain omitted.

POST /v1/diagnostics/echo validates auth without burning quota.

Streaming chat completion succeeds with the fast smoke model.

x-lumacloud-request-id or error.request_id is visible in failure cases.

Support contact is info@lumaos.cloud across manifest, docs, and submissions.

Legal pages are reachable before any external marketplace/provider submission.

No submitted example contains bridge, shard, VPS, localhost OmniRoute, or raw API key material.

PR packet shape

Every target gets the same evidence bundle.

Product copy

Keep API copy split between Builder subscription quota and standalone metered API usage.

Provider registry

All metadata must come from @lumacloud/usage provider-registry helpers.

Client smoke

Each target needs a current-version smoke before a PR claims native support.

Release gate

External PRs are not production deploys, but they still need owner approval because they publish product promises.

Implementation source

Generate provider files from the registry, not by hand.

The @lumacloud/usage provider-registry helpers already generate the OpenCode config, provider manifest, and Models.dev-style TOML metadata.

buildLumaProviderDiscoveryManifest

Feeds metadata-only /.well-known/lumacloud-provider and points consumers to authenticated /v1/models without claiming routability.

buildOpenCodeDiscoveryConfig

Feeds metadata-only /.well-known/opencode and the authenticated download. It carries no raw secret and makes no static model-availability claim.

buildModelsDevProviderToml

Produces the provider TOML starting point for a native OpenCode/Models.dev submission.

Current public state: manual setup works, native listings are gated.

Keep visual/product copy in docs, and keep submission mechanics in the durable repo handoff.

Installation matrix