Other clients

The two values any OpenAI-compatible client needs, which clients are known to work, which are unverified, and which cannot be routed.

A client with a custom OpenAI-compatible provider setting (a base URL field and an API key field) can be pointed at the gateway.

Field	Value
Base URL	`https://guardrails.vulnetix.com/<provider>/<uuid>/v1`
API key	Your Vulnetix API key
Model	The provider’s own model name: `gpt-4o-mini` on `openai`, `openai/gpt-4o-mini` on `openrouter`

Conditions:

Include /v1. Only Anthropic-shaped clients leave it off.
<provider> must serve chat. Every built-in provider except anthropic and kiro does. An OpenAI-shaped client cannot reach anthropic.
The organisation must have a stored key for <provider>, or the gateway answers 403 provider_key_missing.
The key field is often labelled “OpenAI API key”. It still takes your Vulnetix key.

Known to take this recipe

Cline, Roo Code and Zed each have a custom OpenAI-compatible provider with base URL and key fields. The CLI does not detect or write them, and status does not list them.

Unverified

OpenCode, Hermes Agent (Nous Research) and OpenClaw appear to support a custom OpenAI-compatible provider in their config files. They have not been tested against the gateway, so no configuration is published for them. The recipe above is the place to start.

Cannot be routed

Client	Why
Junie (JetBrains)	Its provider is fixed by the vendor (it reads `JUNIE_OPENROUTER_API_KEY`) and it has no base-URL override. Its traffic always goes to its vendor. Continue runs in the same IDEs and can be routed.

Verify any client

A client the CLI does not know about does not appear in vulnetix ai-firewall status, and its absence says nothing. Send a request that a guardrail blocks: a 403 with code: request_blocked and blocked_by naming the rule, shown in the client, proves that request went through. The capability inventory lists what the gateway saw, with the client name it inferred (often openai-sdk or unknown).

Error	Usually means
`404 unsupported_api`	The base URL is wrong: missing `/v1`, or a provider that does not serve `chat`
`404 unknown_provider`	The slug is not in the provider catalogue
`401 invalid_api_key`	The key field holds a provider key, or the UUID in the URL is not the one the key belongs to
`403 provider_key_missing`	No key in the vault for that provider