Gateway versus legacy providers
Both appear under AI Gateway → AI Providers. Add a normal Gateway provider with Add provider; legacy providers are in the separate Legacy Providers section.
Legacy does not mean the upstream model is old. It describes how OpenWork distributes credentials and routes requests. OpenWork Models is a separate managed subscription, not another name for either provider type.
Supported Gateway providers
The table describes supported integration paths, not a guarantee that every model or API offered by an upstream is available. Models, regions, account permissions and API capabilities must also match your configuration. Organization credential means an admin saves a shared upstream credential. Per-person credential means Gateway uses the requesting person’s own sign-in or key; it never falls back to an organization credential when theirs is missing.
All supported chat integrations support streaming on their streaming operation. Tool calling, reasoning, structured output, attachments and context limits depend on the selected model and upstream API, not just the provider row. Gateway is not a universal API translator: an OpenAI request cannot be sent to an Anthropic-only model merely by changing its model ID.
What “compatible catalog provider” means
The Gateway does not support every provider simply because it appears in models.dev or advertises an OpenAI-compatible endpoint. Creation checks the catalog’s SDK, and model selection checks each model’s configuration. Supported SDK families are:
A model that switches to a different SDK or contains unresolved configuration templates is excluded. Selecting it explicitly is rejected. All models means all compatible catalog models, not every model enabled in your upstream account. A new catalog model is not automatically granted to existing model groups.
For an arbitrary endpoint or model definition outside this contract, use a custom legacy provider. For LiteLLM, prefer the dedicated Gateway integration rather than the legacy custom-provider route.
Usage and API boundaries
- Usage parsing: Gateway parses Chat Completions, Responses, Anthropic Messages, Google Generate Content and Bedrock Converse responses. Additional allowed operations may have no usage parser; allowing an API path does not guarantee token counts, prices or spend enforcement. See Counting usage and Token costs.
- LiteLLM budgeting: With one organization key, OpenWork estimates cost and applies OpenWork limits. With personal or OpenWork-created keys, OpenWork records tokens only; LiteLLM enforces user, team and key budgets.
- Not a full provider API proxy: Model requests must select an authorized model. Arbitrary account management, batch/deferred jobs, multipart uploads, provider-hosted tools and stored-resource references are not supported. Do not assume image/audio API paths imply file-upload support, or that HTTP streaming implies WebSocket/realtime support.
- Network access: Upstreams use public HTTPS by default. Private/local endpoints or HTTP require the operator to approve the exact origin on both Den and Gateway. A provider setting cannot grant private network access. See Self-hosted Gateway.
Moving an existing legacy provider
Move to gateway is available only for eligible shared-key catalog providers with compatible models and configuration. Custom providers and legacyper_member providers cannot be moved automatically. Azure, Vertex and Bedrock providers that require explicit destination or authentication settings must be configured as new Gateway providers.
When automatic migration is unavailable, add the Gateway provider separately, set its credentials and access, and test a model request before removing the legacy provider. Do not treat removal from OpenWork as revocation of an upstream key that was previously synced to a device; rotate or revoke that key with the upstream provider when needed.
For setup, start with AI Gateway. For the legacy workflows, see Managed providers, Custom providers and Per-member credential bindings.