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; default model gpt-5.5-xhigh; 5 public model ids.

Every external submission should reference the public endpoint, the request-id support flow, and the canonical model table.

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

Public artifacts already exposed

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

Provider manifest

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

OpenCode defaults

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

Model catalog

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

Health check

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, opencode.json installer merge

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 /healthz returns healthy from the public origin.

GET /v1/models returns the same canonical ids as /docs/models.

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.

buildLumaProviderManifest

Feeds /.well-known/lumacloud-provider with support, endpoint, models, defaults, and integration hints.

buildOpenCodeConfig

Feeds /.well-known/opencode and personalized opencode.json downloads.

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