Repository navigation
Add per-model availability checks and latency display #1765
Description
Area
Dashboard
What are you trying to accomplish?
When a provider exposes or is configured with many models, I want to quickly verify which individual models can actually handle requests and compare their response latency before selecting or routing traffic to them.
What prevents this today?
The current provider test only shows whether a provider-level connection is usable. A successful provider check does not tell me whether every model is available, authorized for the account, compatible with the provider endpoint, or blocked by a model-specific quota or configuration problem.
Today I have to select and invoke models one at a time, then inspect the request result or logs. This is slow and error-prone for providers with large model catalogs.
What should OpenCodex do?
Add a per-model availability check to the Dashboard's model or provider view.
The user should be able to check all models for one provider, or retry a single model, and see:
- available, unavailable, checking, and not-yet-checked states;
- latency for successful checks;
- a concise model-specific failure reason;
- the time of the last check.
The bulk check should use bounded concurrency and be manually triggered by default so it does not unexpectedly consume excessive quota, cost, or rate limits.
Example usage or interface
Provider: example-provider [Check all models]
Model Status Latency Last checked
model-a Available 420 ms just now
model-b Unavailable — just now
model-c Checking... — —
model-d Not checked — —
Selecting an unavailable model could show a sanitized reason such as model_not_found, permission_denied, rate_limited, or incompatible_endpoint, with a retry action.
An optional CLI equivalent could be:
ocx models check --provider example-providerAlternatives or workarounds
I can manually send a request with each model, inspect logs, or call the provider's model-list endpoint. The first approach does not scale, and model discovery only proves that an ID was listed; it does not prove that inference succeeds for the current account and endpoint.
Additional context
A sanitized startup example shows the current ambiguity:
[opencodex] Provider model discovery for "deepseek" omitted configured model ids;
dropping them from the authoritative live catalog: deepseek-chat, deepseek-reasoner.
This reports a catalog discrepancy, but it does not provide a per-model health result or latency. Related UX and health discussions include #1062, #1146, and #753.
Checks
- I searched existing issues and documentation.
- This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
- I removed secrets and personal data.
Activity
coderabbitai commentedon Aug 15, 2026
🔗 Related PRs
#354 - fix(models): surface discovery failure status when /v1/models returns 401 (
#329) [open]#639 - fix(catalog): accept Together top-level /models arrays [merged]
#653 - feat(providers): add Baseten Model APIs preset [merged]
#965 - fix(catalog): custom model rows inherit provider reasoning metadata [open]
#1087 - fix(gui): shadow-call selects save the canonical namespaced model id (
#1075) [merged]📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
lidge-jun commentedon Aug 19, 2026
리뷰 · 우선순위 32 / 80
프로바이더 연결이 성공해도, 그 아래 모델마다 실제 호출이 되는지와 지연을 한눈에 보고 싶다는 대시보드 요청입니다. 지금처럼 모델을 하나씩 골라 로그를 보는 방식은 카탈로그가 클 때 느리고, 목록에 ID가 있다고 추론이 된다는 뜻은 아닙니다.
현재
dev의 프로바이더 테스트는src/server/management/provider-routes.ts의POST /api/providers/test입니다. 주석대로 라이브/models조회를 직접 때리고, 카탈로그 존재만 보지 않습니다. 응답에ok,latencyMs,applicable,static_catalog같은 프로바이더 단위 결과만 있습니다. 모델별 available/unavailable, 모델별 실패 이유, 마지막 검사 시각을 모아 주는 API는 이 파일에 없습니다.이슈가 원하는 표는 모델마다 상태, 성공 시 지연, 짧은 실패 이유, 마지막 검사 시각입니다. 대량 검사는 수동 트리거와 동시성 제한이 있어야 할당량과 비용을 갑자기 쓰지 않습니다.
ocx models check --provider는 있으면 좋지만, 핵심은 대시보드입니다.해결방안: 기존
/api/providers/test와 별도로, 한 모델에 대한 최소 추론 프로브와 제한된 일괄 검사를 추가하고, 결과를 프로바이더/모델 뷰에 붙이면 됩니다. 실패 이유는model_not_found,permission_denied,rate_limited처럼 살균해서 보여야 합니다. 자동 시작 스캔은 할당량을 먹을 수 있어 기본값으로 켜지 않는 편이 맞습니다. 정확한 프로브 페이로드는 어댑터마다 달라서, 여기서는 패치는 추측하지 않음.이 댓글은 grok-bot이 작성했습니다
lidge-jun commentedon Aug 19, 2026
리뷰 · 우선순위 32 / 80 · 종결
대시보드에서 모델마다 ping 해서 됨/안 됨, 지연, 실패 이유를 보여 달라는 요청임. 지금 프로바이더 테스트는 연결만 보니까, 목록에 있어도 권한/쿼타/엔드포인트 때문에 안 되는 모델을 모름.
방향은 맞음. 다만 지금은 안 함. 대량 체크는 쿼타/돈/레이트 나가고, 대시보드 표 + 동시성 제한 + 실패 사유 정규화까지면 GUI 작업이 큼. 머지 플랜/코어 버그 쪽 먼저임.
나중에 PR 올려주면 봄. 닫는다고 아이디어를 거절하는 건 아님. 구현할 땐 수동 트리거가 기본이어야 함 (자동 일괄 ping은 안 됨). CLI
ocx models check는 있으면 좋고 필수는 아님.해결방안: 지금은 패치 없음. 후속 PR이면 프로바이더 뷰에 수동 Check all + 단건 retry, 상태 4종, latency, sanitized reason.
이 댓글은 grok-bot이 작성했습니다