Repository navigation
[Bug] Nous live model discovery rejects a valid 566 KiB catalog #3938
Description
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,054bytes - 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
nousprovider. - Keep
liveModels: true. - Run the provider/catalog sync against the Nous Portal account.
- Observe the valid
/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_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
Activity
github-actions commentedon Sep 7, 2026
Issue closed: use an issue template
Thanks for taking the time to submit this issue. It was closed automatically because it was not opened with a recognized issue template (Bug report, Feature request, Documentation, or Provider compatibility). Freeform and API-opened issues cannot skip this check.
Please edit the issue to add:
[Bug]:and applying thebuglabel alone is not enough without those section headings filled in.See the Contributing guide for details.
Once the report passes the automated checks, it will be reopened automatically unless a maintainer has changed its state.
lidge-jun commentedon Sep 7, 2026
리뷰 · 우선순위 56 / 80
이 이슈는 Nous Portal 라이브 모델 discovery가 유효한
/v1/models응답(약 566 KiB, 390행, HTTP 200)을 프로바이더 전용 256 KiB 한도 때문에 거절한다는 버그 보고입니다. 현재dev의src/providers/registry.tsnous.modelDiscovery.maxResponseBytes는262_144이고, 프로세스 전역 천장은src/providers/model-discovery-limits.ts의 4 MiB입니다. 한도가 작아서 라이브 카탈로그 동기화가 실패하고 시드 목록으로 떨어지며, Free 콤보의nous/...:free경로에서 특히 드러납니다.보고 내용과 재현·기대 동작·제안 수정(1 MiB로 상향 + 회귀 테스트)이 구체적이고, OAuth 바디 바인딩(#1603)과 카탈로그 discovery를 구분한 점도 맞습니다. 이미 같은 수정을 담은 PR #3939가
dev대상으로 열려 있습니다.경로/심볼 · registry.ts nous.modelDiscovery - 이슈의 진단과 HEAD 코드가 일치합니다. 추가 조사보다 픽스 PR 검증이 우선입니다.
경로/심볼 · 업스트림 429/524 - 이슈/PR 모두 카탈로그 한도와 추론 가용성을 분리했습니다. 이 티켓 범위 밖으로 두는 판단이 맞습니다.
메인테이너의 판단이 필요한 지점
너의 추천
중복 수정 PR을 새로 받지 말고 #3939를 검토·머지하세요. 머지되면 이 이슈는
Fixes #3938로 닫히게 두면 됩니다.이 댓글은 grok-bot이 작성했습니다
lidge-jun commentedon Sep 7, 2026
Implemented on dev in #3957 (5cd71ec). The Nous-specific response cap is now 1 MiB; current-head hosted CI 34166962088 passed, including the 390-row gather/cache and connection probe regressions. The global byte and raw-row limits remain. Updated the previously template-closed issue to completed after verified delivery.