Skip to main content
Applies to:
  • Plan -
  • Deployment -

​
Summary

Issue: A project-level AI provider is configured, but requests through the legacy AI proxy continue using organization-level provider credentials. The proxy logs may show a warning like Failed to load project secrets, continuing with org secrets only with a ZodError for unrecognized metadata keys such as auth_format or auth_type. Cause: Some legacy proxy versions validate AI provider secret metadata with a strict schema. Newer provider metadata saved by the Braintrust UI can include fields that the old proxy does not recognize. When the proxy cannot parse the project-level provider secret, it skips or fails project-secret loading and falls back to organization-level secrets. Resolution: Upgrade the data plane/proxy where possible. As a temporary workaround on legacy proxy deployments, patch the project AI provider env var to a minimal metadata object that the old proxy can parse.

​
When to use this workaround

Use this only when all of the following are true:
  • The deployment is using the legacy AI proxy on an older data plane.
  • The problem is specifically that project-level provider credentials are not being used.
  • Proxy logs show project secret loading/parsing failures, especially unrecognized_keys in provider metadata.
Do not use this as the default fix for current data plane versions or Gateway deployments. Current proxy versions accept and preserve unknown provider metadata keys, and Gateway does not use this legacy proxy Zod metadata schema.

​
How project-level provider loading fails

When a proxy request includes project context, Braintrust loads AI provider secrets for that project and filters them against the requested model. A project OpenAI provider remains eligible for default OpenAI models when:
  • secret_type is openai
  • metadata.excludeDefaultModels is not true
  • the provider secret parses successfully
If the project secret metadata contains keys the old proxy schema does not recognize, the parse fails before the project provider can be merged with organization providers. The proxy then continues with organization-level secrets, which makes it look like project-level override is not working.

​
Temporary workaround

Patch the project AI provider env var and remove metadata keys that the old proxy rejects. Keep only the fields needed for routing. First, find the project-level AI provider env var: 
curl -sS "$BRAINTRUST_API_URL/v1/env_var?object_type=project&object_id=<PROJECT_ID>&secret_category=ai_provider" \
  -H "Authorization: Bearer <braintrust-api-token>" \
  | jq '.objects[] | {id, name, secret_type, metadata}'
Then patch the affected provider. Replace <ENV_VAR_ID> and the api_base value with the endpoint you intend to use: 
curl -sS -X PATCH "$BRAINTRUST_API_URL/v1/env_var/<ENV_VAR_ID>" \
  -H "Authorization: Bearer <braintrust-api-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "secret_type": "openai",
    "metadata": {
      "excludeDefaultModels": false,
      "supportsStreaming": true,
      "api_base": "https://us.api.openai.com/v1"
    }
  }'
This removes newer metadata fields such as auth_type and auth_format while preserving the fields the old proxy needs to route default OpenAI-model requests to the project provider.

​
What each metadata field does

  • secret_type: "openai" marks the env var as an OpenAI AI provider secret.
  • api_base points the provider at the intended OpenAI-compatible endpoint.
  • excludeDefaultModels: false keeps the provider eligible for normal OpenAI model routing.
  • supportsStreaming: true marks the provider as streaming-capable.
The key part of the workaround is omitting unsupported fields from metadata. In the legacy proxy failure mode, extra metadata can cause the entire project provider secret to be rejected before it is used for routing.

​
Verify the fix

After patching the env var:
  1. Retry the same Playground or proxy request.
  2. Confirm the proxy no longer logs Failed to load project secrets, continuing with org secrets only for that project.
  3. Confirm the request uses the expected project-level provider credentials.
  4. If available, check the proxy or response headers for the used provider endpoint.

​
Long-term fix

Upgrade the data plane/proxy instead of relying on direct metadata patches. Current proxy versions changed provider-secret metadata validation to preserve unknown keys rather than rejecting the secret, which prevents newer UI metadata from breaking older routing assumptions. For new deployments and migrations, prefer Gateway over the deprecated AI proxy. Project-level provider override is name-based: when project and organization providers share the same provider name, the project provider takes precedence for that project. If providers have different names but are both eligible for the requested model, they can both remain candidates for routing.