Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: Business Premium seat plan self_serve_business_prolite is counted at baseline capacity weight 1 instead of 5

Open Beginner friendly
  • Is something wrong?
#7,440 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Ingwannu is already working on this.

Since Oct 20, 2026.

  • #7444 by @Ingwannu — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
api, backend

Research direction

Start with src/providers/codex-capacity.ts, especially CODEX_CONFIGURED_CAPACITY_WEIGHTS and configuredWeight, then read src/codex/plan.ts to understand how plan strings are normalized. Add coverage for self_serve_business_prolite alongside the existing capacity weight tests. Done when the plan is counted at weight 5, is no longer reported as unknown, and the relevant tests pass.

Written by the indexing model from the issue text.

Description

account-pool bug
Client or integration

OpenCodex dashboard

Area

Authentication and account pool

Summary

ChatGPT Business Premium seats report the plan string self_serve_business_prolite, which is not in CODEX_CONFIGURED_CAPACITY_WEIGHTS (src/providers/codex-capacity.ts:3-9: plus 1, team 1, business 1, prolite 5, pro 20). codexPlanKey (src/codex/plan.ts:10-12) only trims and lowercases, so the exact-key lookup in configuredWeight (src/providers/codex-capacity.ts:125-130) misses and the seat falls back to CODEX_DEFAULT_CAPACITY_WEIGHT = 1. The Codex pool capacity estimate therefore counts a Premium seat as one Standard seat, and the account stays in unknownPlanAccounts permanently.

This is the calibration follow-up that #3155 / #3198 explicitly left open. #3198 made uncalibrated plans count at the baseline instead of being dropped and said a real weight would be calibrated once the plan string was known; the reporter then supplied the exact string self_serve_business_prolite in #3155, but the issue was already closed and no weight was added. Current dev still has the same five-entry map.

OpenAI now documents the multiplier, so this no longer requires a guess:

Standard Business is already calibrated at business: 1, so the documented Premium value is 5, the same weight as prolite. Observed behaviour is consistent: both Premium accounts in our pool report only the weekly window from WHAM (no five-hour window), while the Team account reports both.

Expected: self_serve_business_prolite is calibrated at weight 5 (for example as an explicit map entry, or an alias to prolite), so it leaves unknownPlanAccounts and the estimate reflects the real seat. Impact is display-only: aggregateCodexPoolCapacity is documented as never participating in selection or routing (src/providers/codex-capacity.ts:203), so this changes the dashboard / GET /api/provider-quotas estimate and nothing else. Not asking to reopen the allowlist debate from #3198; only to calibrate this one now-documented plan.

Reproduction
  1. Add two ChatGPT Business Premium seat accounts and one Team account to the Codex pool (codexAccountMode: "pool").
  2. Open the dashboard Providers → OpenAI rate limits panel, or call GET /api/provider-quotas.
  3. The OpenAI report shows aggregation.kind = "capacity-weighted-v1", includedAccounts: 3, unknownPlanAccounts: 2, and the notice that accounts on an uncalibrated plan are counted at the baseline seat weight.
  4. GET /api/codex-auth/accounts shows "plan": "self_serve_business_prolite" for both Premium seats and "plan": "team" for the Team seat.
  5. The total capacity weight is 3 (1 + 1 + 1) instead of 11 (5 + 5 + 1).
Version

2.88.0 (deployed); the same map is present on current dev and in v2.89.0

Operating system

Linux (Debian 12 host, OpenCodex in a k3s pod)

Provider and model

openai (Codex pool), any GPT model

Logs or error output
GET /api/provider-quotas  (OpenAI entry, values only)
"aggregation": {"kind": "capacity-weighted-v1", "scope": "routable-known",
  "includedAccounts": 3, "excludedAccounts": 0, "unknownPlanAccounts": 2,
  "missingQuotaAccounts": 0, "pausedAccounts": 0, "reauthAccounts": 0, "staleQuotaAccounts": 0}

GET /api/codex-auth/accounts  (plan field only, other fields removed)
{"plan": "self_serve_business_prolite"}
{"plan": "self_serve_business_prolite"}
{"plan": "team"}
Screenshots and supporting files

Not attached: the report is fully reproducible from the two API responses above and the cited OpenAI help-center pages.

Redacted configuration
{
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "codexAccountMode": "pool",
      "authMode": "forward"
    }
  }
}
Checks
  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
7h 50m
Merged PRs (30d)
645

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.