Regression in v0.147.0 with LiteLLM provider — streaming requests consistently fail

The actual error comes from the service provider (Bedrock), not LiteLLM:

Invalid Value: 'tools.namespace'. User-defined namespace 'functions' collides with an existing tool namespace.

Likely related to #36957

I compared rust-v0.146.1..rust-v0.147.0 and found a concrete request-shape regression that explains the Bedrock error.

The introducing change is f21dc46388 / #37022, “Canonicalize default tools under the functions namespace.”

Before that change, Responses Lite placed ordinary function/custom tools in the additional_tools developer item as flat entries:

[
  {"type": "function", "name": "some_tool", "...": "..."}
]

Since 0.147.0, ModelClient::build_responses_request calls create_tools_json_for_responses_lite() whenever use_responses_lite and provider.capabilities().namespace_tools are both true. That serializer moves all ordinary function/custom tools into an explicitly user-defined namespace:

[
  {
    "type": "namespace",
    "name": "functions",
    "description": "",
    "tools": [
      {"type": "function", "name": "some_tool", "...": "..."}
    ]
  }
]

This also affects custom/LiteLLM providers because ConfiguredModelProvider inherits ProviderCapabilities::default(), where namespace_tools: true. There is currently no provider capability negotiation or custom-provider config switch that distinguishes:

1. support for namespaced tools in general, from
2. support for explicitly declaring the reserved/default functions namespace.

Bedrock already owns/implicitly provides the functions namespace, so the new explicit declaration is rejected with:

Invalid Value: 'tools.namespace'.
User-defined namespace 'functions' collides with an existing tool namespace.

That means the streaming retries and final “high demand” message are secondary/misleading symptoms; the underlying failure is a non-retryable provider-side request validation error.

The relevant 0.147.0 flow is:

• codex-rs/core/src/client.rs: selects create_tools_json_for_responses_lite() when namespace_tools is true.
• codex-rs/tools/src/tool_spec.rs: constructs ResponsesApiNamespace { name: "functions", ... } and moves flat function/custom tools into it.
• codex-rs/model-provider/src/provider.rs: defaults namespace_tools to true, including for ConfiguredModelProvider.

I also checked current main; the relevant serialization and custom-provider capability default are still present.

A safe immediate workaround is to pin 0.146.1. A source-level workaround is to retain the pre-0.147 flat create_tools_json_for_responses_api() representation for custom providers even inside the Responses Lite additional_tools item. Setting use_responses_lite: false through a full model-catalog override may also bypass this exact path, but it changes more transport behavior and can expose separate reserved-namespace compatibility issues.

For the durable fix, I suggest separating “supports namespace tools” from “supports an explicit default/functions namespace,” defaulting the latter to false for custom providers unless explicitly advertised. A regression test could use a configured custom provider with a Responses Lite model and assert that additional_tools contains flat function/custom entries and no {"type":"namespace","name":"functions"} wrapper.

Separately, this class of provider 4xx validation error should ideally not be retried and surfaced as “high demand,” since that obscures the actionable error.

A current workaround is:

Dump model catalog:
codex debug models --bundled > ~/.codex/models-bundled-0.147.json

Unset the usage of responses-lite for gpt-5.6 models:

jq '
(
  .models[]
  | select(
	  .slug == "gpt-5.6-sol"
	  or .slug == "gpt-5.6-terra"
	  or .slug == "gpt-5.6-luna"
	)
  | .use_responses_lite
) = false
' ~/.codex/models-bundled-0.147.json \
> ~/.codex/models-bundled-0.147-workaround.json

Reference it in your ~/.codex/config.toml file:

model_catalog_json = "~/.codex/models-bundled-0.147-workaround.json"

Hi @emerzon

Thanks a lot for your reply. Indeed, it seems that the issue stems from their new “namespace” functions. They appear to have assumed that all API providers work the same way as OpenAI

if I understand correctly, Codex sends a structure that Bedrock rejects. LiteLLM then converts or relays this error as an HTTP 500, and Codex ultimately hides the true cause behind its generic message

Thanks for your workaround, I hope they will fix the bug in next releases

I'm experiencing that this is inconsistent depending on what device I am on for reasons unclear. The Codex config is the same between the devices, the verisons are the same. One device is linux (generally seems to work) and the other is a mac; hitting either litellm or azure.