Incomplete Coverage when connecting Codex Business Premium Seat

[harry248]

Client or integration

OpenCodex dashboard

Area

Provider adapter

Summary

After my Business Codex Account was upgraded to a Premium Seat (available since 25.08.) under Rate Limits I get an "Incomplete coverage: 1 account(s) excluded, including 1 unknown plan(s)" warning. Didn't show before the upgrade.

Reproduction

You need an OpenAI Business account (maybe Enterprise works too).
You must buy a premium seat or upgrade a regular seat to premium.
(Premium seats where introduced on 25.08.).
Connect that account with opencodex and visit the provider section of the dashboard.
The Codex rate limit section will show the warning.

Version

2.39.0

Operating system

macOS 26.6.2 (25G83)

Provider and model

OpenAI

Logs or error output

Incomplete coverage: 1 account(s) excluded, including 1 unknown plan(s)

Screenshots and supporting files

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Ingwannu]

Confirmed the immediate boundary on current dev: the capacity estimator intentionally recognizes only the exact configured plan keys plus, team, business, prolite, and pro. An unfamiliar Premium Seat plan is therefore excluded and produces this warning.

I do not want to guess that Premium Seat is equivalent to ordinary Business, ProLite, or Pro, because that would remove the warning while potentially publishing a false pool-capacity estimate.

Could you share only the exact sanitized plan value returned for that account by /api/codex-auth/accounts? In the dashboard's browser developer tools, the response can be reduced to something like:

{ "plan": "<exact-value>" }

Please remove the email, account IDs, quota/reset values, credentials, and every other field. If OpenAI documents or the Business workspace shows a capacity/rate-limit multiplier for Premium Seat relative to a standard Business seat, please link or quote that non-sensitive value as well. With those two facts we can add the key and correct weight without guessing.

[lidge-jun]

리뷰 · 우선순위 60 / 80

설명

이 이슈는 OpenAI Business 계정을 Premium Seat로 올린 뒤, 대시보드 Rate Limits에 Incomplete coverage: 1 account(s) excluded, including 1 unknown plan(s) 경고가 뜬다는 보고입니다. 업그레이드 전에는 없었고, Premium Seat는 2025-08-25경 도입됐다고 합니다. 버전 2.39.0, macOS, provider OpenAI 입니다.

지금 HEAD GUI 문자열은 gui/src/i18n/en.ts 의 pws.capacity.incomplete 와 같습니다. 집계는 gui/src/provider-workspace/report.ts 의 unknownPlanAccounts / incomplete 필드를 읽습니다. 서버·쿼터 쪽은 src/codex/quota.ts 가 plan 이름 allowlist로 창을 가르지 않는다고 명시합니다. upstream 스냅샷만 해도 plan 문자열이 많고, 낯선 이름을 거절하면 쿨다운이 영구가 되기 때문입니다. 그런데 대시보드 "incomplete coverage" 는 그와 다른 축일 수 있습니다. capacity 패널이 계정별 plan을 알려진 집합과 비교해 unknown으로 세는 GUI/관리 API 경로가 남아 있으면, 새 Premium plan 문자열 하나만으로 경고가 납니다.

src/codex/plan.ts / plan-from-token.ts 는 JWT chatgpt_plan_type 을 읽습니다. Premium Seat가 새 plan_type을 내보내면, 파서는 문자열을 저장하지만 capacity 요약이 "unknown plan" 으로 제외할 수 있습니다. #3057 entitlement tri-state, #3058 entitlement status API, #2933 plan reconcile 이 HEAD에 있어도, Premium 라벨 자체 인식은 별 작업일 수 있습니다. types/config 분할과 무관합니다. remote hub보다는 계정 UX 후속입니다.

점수는 60입니다. 실제 Business Premium 사용자가 보는 경고이고, 쿼터 숫자 자체보다 "제외됨" 문구가 신뢰를 깎습니다. 다만 재현에 plan_type 원문·WHAM 페이로드가 없어 서버 버그인지 GUI 분류인지 아직 갈립니다.

경로 gui/src/provider-workspace/report.ts unknownPlanAccounts - incomplete 배지의 직접 입력입니다. API가 unknown을 어떻게 세는지 서버 스키마를 같이 봐야 합니다
경로 src/codex/quota.ts 주석 - plan allowlist를 버렸습니다. capacity incomplete가 다른 allowlist를 쓰면 정책이 갈라집니다
경로 src/codex/plan.ts chatgpt_plan_type - Premium Seat의 실제 문자열을 이슈에 첨부해 달라고 요청하는 것이 다음 조사 키입니다
경로 스크린샷 - Rate Limits 카드에 incomplete 문구가 보입니다. 숫자 쿼터가 비었는지, 계정만 제외인지도 구분해야 합니다

메인테이너의 판단이 필요한 지점

• unknown plan을 경고에서 빼 보여줄지, Premium 문자열을 알려진 집합에 넣을지
• Business Premium이 weekly/monthly 창 중 무엇을 쓰는지 upstream 확인이 필요한지
• help wanted로 두고 plan_type 샘플을 받을지

너의 추천
이슈를 열어 두고, 보고자에게 WHAM/account JSON의 plan / plan_type 문자열(비밀 제외)을 요청하는 조사 댓글을 메인테이너가 남기면 됩니다. 성급한 코드 PR보다 문자열 확정이 먼저입니다. 쿼터 파서가 allowlist를 버린 방향과 capacity unknown 집계가 모순이면 capacity 쪽을 완화하는 패치가 맞습니다. 라벨은 이 댓글에서 바꾸지 않습니다.

이 댓글은 grok-bot이 작성했습니다

Translated Message

Original language: Korean

Review · Priority 60 / 80

Description

This issue is a report that after upgrading an OpenAI Business account to Premium Seat, a warning Incomplete coverage: 1 account(s) excluded, including 1 unknown plan(s) appears on the dashboard Rate Limits. It was not present before the upgrade, and Premium Seat was reportedly introduced around 2025-08-25. Version 2.39.0, macOS, provider OpenAI.

The current HEAD GUI string is the same as pws.capacity.incomplete in gui/src/i18n/en.ts. The aggregation reads the unknownPlanAccounts / incomplete fields in gui/src/provider-workspace/report.ts. On the server/quota side, src/codex/quota.ts specifies that the plan name allowlist is not applied as a filter. This is because even in upstream snapshots there are many plan strings, and rejecting unfamiliar names would result in permanent cooldown. However, the dashboard "incomplete coverage" may be a different axis. If a GUI/management API path remains in the capacity panel that compares per-account plans against a known set and counts unknowns, a single new Premium plan string would trigger the warning.

src/codex/plan.ts / plan-from-token.ts reads the JWT chatgpt_plan_type. If Premium Seat exports a new plan_type, the parser stores the string but the capacity summary may exclude it as "unknown plan". Even though #3057 entitlement tri-state, #3058 entitlement status API, #2933 plan reconcile are in HEAD, Premium label recognition itself may be a separate task. This is unrelated to types/config split. It is more of an account UX follow-up than remote hub.

The score is 60. It is a warning visible to actual Business Premium users, and the "excluded" phrasing erodes trust more than the quota numbers themselves. However, reproduction lacks the plan_type original text and WHAM payload, so it remains unclear whether this is a server bug or GUI classification issue.

Path Analysis:

• Path gui/src/provider-workspace/report.ts unknownPlanAccounts - direct input for the incomplete badge. Need to check server schema on how the API counts unknowns.
• Path src/codex/quota.ts comment - plan allowlist was dropped. If capacity incomplete uses a different allowlist, policy diverges.
• Path src/codex/plan.ts chatgpt_plan_type - The next investigation key is requesting the actual string for Premium Seat in the issue attachment.
• Path screenshot - incomplete text visible on the Rate Limits card. Must distinguish whether quota numbers are empty or only accounts are excluded.

Points Requiring Maintainer Decision:

• Whether to exclude unknown plans from the warning display, or add Premium strings to the known set
• Whether upstream confirmation is needed on whether Business Premium uses weekly/monthly window
• Whether to leave as help wanted and request plan_type samples

My Recommendation:

Keep the issue open and have a maintainer leave an investigation comment requesting the plan / plan_type strings (excluding secrets) from WHAM/account JSON from the reporter. String confirmation comes before premature code PRs. If the quota parser dropped the allowlist direction and capacity unknown aggregation contradicts it, a patch relaxing the capacity side is correct. Do not change labels in this comment.

This comment was written by grok-bot

[harry248]

The value is

{
    "accounts": [
        {
            "id": "__main__",
            "email": "",
            "plan": "self_serve_business_prolite",
            "logLabel": "main",
            "isMain": true,
            "paused": false,
            "priority": 0,
            "hasCredential": true,
            "needsReauth": false,
            "quota": {
                "weeklyPercent": 1,
                "weeklyResetAt": 1788770722,
                "resetCredits": 0,
                "updatedAt": 1788284958401
            },
            "health": {
                "status": "healthy"
            },
            "healthLabel": "Healthy",
            "healthSummary": "codex main account: healthy"
        }
    ]
}

And the remaining usage seems to be in sync with Codex. Your false pool-capacity estimate fear does not seem to be justified.

[lidge-jun]

Fixed by #3198, landed on dev as ef6a163.

Your Premium Seat upgrade changed the plan string the account reports, and the capacity estimate weighted accounts by a hardcoded map of five plan names. Anything outside it got no weight and was dropped from the aggregate — which is the warning you saw.

Worth knowing: this was not specific to Premium Seat. The bundled upstream snapshot alone carries 21 distinct plan strings against the five with weights, so sixteen real plans were already being excluded the same way, including go. Yours is simply the one that made someone look.

So the fix is not "add premium to the list". An uncalibrated plan is now counted at the baseline seat weight instead of being dropped. Under-counting a large seat gives you a visibly conservative estimate; excluding it silently told you your coverage was complete when it was not.

The dashboard wording is split to match, because the old sentence had become false. Exclusion (paused, needs-reauth, missing or stale quota) and calibration are now separate lines:

Incomplete coverage: N account(s) excluded
N account(s) on an uncalibrated plan are counted at the baseline seat weight, so this estimate may be conservative

Your Premium Seat will now appear in the estimate, with that second line noting the figure may be conservative for it. If you can tell us the plan string it reports — the dashboard shows it next to "Current effective account" — we can calibrate a real weight for it rather than leaving it at baseline.

One caveat: I do not have a Business Premium Seat, so this is verified against the component rendering and the capacity aggregation rather than against your exact account. If the warning persists after upgrading, please reopen.

Thanks for the report, and for pinning down that it started at the upgrade — that detail is what pointed at the plan string rather than at quota parsing.