Summary
The Nous Portal provider's live model discovery rejects a valid authenticated /v1/models response because the provider-specific response cap is too small.
Observed behavior
With OpenCodex 2.46.0, the Nous endpoint returned:
- HTTP status:
200
- Content type:
application/json
- Body size:
566,054 bytes
- Model rows:
390
OpenCodex then logged:
Provider model discovery for "nous" exceeded the 262144-byte response limit
The registry currently sets providers.nous.modelDiscovery.maxResponseBytes to 262_144, while the process-wide model-discovery ceiling is already 4 MiB.
Impact
The provider falls back to the configured seed instead of publishing the live catalog, and repeated catalog refreshes can repeatedly trigger OAuth/model-discovery work. The failure is especially visible for the Free combo, which includes nous/stepfun/step-3.7-flash:free.
This is separate from PR #1603, which bounds Nous OAuth response bodies; this report concerns the provider model-catalog endpoint.
Reproduction
- Configure and authenticate the
nous provider.
- Keep
liveModels: true.
- Run the provider/catalog sync against the Nous Portal account.
- Observe the valid
/v1/models response being rejected at 256 KiB.
A deterministic regression fixture can use an OpenAI-shaped { "data": [...] } payload larger than 256 KiB but smaller than 1 MiB.
Expected behavior
A valid Nous catalog within the process-wide safety limit should be accepted, parsed, and filtered according to the provider's configured model limits. A provider-specific cap should leave enough room for the current mixed paid/free catalog.
Suggested fix
Raise the Nous provider-specific cap to 1_048_576 bytes (1 MiB), keeping the existing process-wide 4 MiB ceiling and the existing raw-row limit. Add a regression test for an observed Nous-sized catalog.
I verified this minimal change locally on macOS: the catalog discovery no longer reports the 256 KiB error, the service writes the live Nous catalog, and the focused provider-discovery tests, typecheck, and privacy scan pass.
Environment
- OpenCodex:
2.46.0
- Platform: macOS arm64
- Provider: Nous Portal OAuth
- Endpoint:
https://inference-api.nousresearch.com/v1/models
Summary
The Nous Portal provider's live model discovery rejects a valid authenticated
/v1/modelsresponse because the provider-specific response cap is too small.Observed behavior
With OpenCodex
2.46.0, the Nous endpoint returned:200application/json566,054bytes390OpenCodex then logged:
The registry currently sets
providers.nous.modelDiscovery.maxResponseBytesto262_144, while the process-wide model-discovery ceiling is already 4 MiB.Impact
The provider falls back to the configured seed instead of publishing the live catalog, and repeated catalog refreshes can repeatedly trigger OAuth/model-discovery work. The failure is especially visible for the
Freecombo, which includesnous/stepfun/step-3.7-flash:free.This is separate from PR #1603, which bounds Nous OAuth response bodies; this report concerns the provider model-catalog endpoint.
Reproduction
nousprovider.liveModels: true./v1/modelsresponse being rejected at 256 KiB.A deterministic regression fixture can use an OpenAI-shaped
{ "data": [...] }payload larger than 256 KiB but smaller than 1 MiB.Expected behavior
A valid Nous catalog within the process-wide safety limit should be accepted, parsed, and filtered according to the provider's configured model limits. A provider-specific cap should leave enough room for the current mixed paid/free catalog.
Suggested fix
Raise the Nous provider-specific cap to
1_048_576bytes (1 MiB), keeping the existing process-wide 4 MiB ceiling and the existing raw-row limit. Add a regression test for an observed Nous-sized catalog.I verified this minimal change locally on macOS: the catalog discovery no longer reports the 256 KiB error, the service writes the live Nous catalog, and the focused provider-discovery tests, typecheck, and privacy scan pass.
Environment
2.46.0https://inference-api.nousresearch.com/v1/models