Skip to content

docs: state whether each provider login consumes a subscription allowance or bills per token #4215

Closed

Description

@lidge-jun

Documentation problem type

Missing documentation

Documentation location

https://opencodex.me/guides/providers/ (repository source docs-site/src/content/docs/guides/providers.md)

What is wrong or missing?

The documentation does not answer the first question subscribers ask before they connect an account: when a provider is used through OpenCodex, does the traffic draw on the subscription allowance that login already pays for, or does it bill separately per token?

Asked on X by @iGotYourBackMr on 2026-09-09: "if I use Claude through OpenCodex in the Codex app, does it use my included Claude Max allowance, or incur separate pay-per-use Anthropic API charges?" (https://x.com/iGotYourBackMr/status/2097703858159894675). The question recurs for every provider that has both a subscription login and an API key, and answering it once on X does not scale.

What should the documentation explain instead?

State the rule per authentication mode, not per vendor marketing tier: an OAuth or subscription login consumes that subscription's allowance and its quota windows, an API key bills that key's account per token, and OpenCodex does not convert one into the other. Then give the same one-line statement for each provider that supports both modes, so a reader can check their own setup without inference.

Suggested wording or example

For each provider entry, one explicit line, for example:

Anthropic (Claude subscription login): requests consume the subscription allowance attached to that login, subject to its own quota windows.
Anthropic (API key): requests bill the API account that owns the key, per token. No subscription allowance is consumed.

Plus a short note that the account card in the dashboard shows which mode an account is using, so the reader can verify rather than assume.

Additional context or attachments

Related closed issue #3777 (expose the Anthropic account subscription tier) shows the same subscription-versus-API confusion arriving through the product surface rather than the docs.

Checks

  • I searched existing documentation issues.
  • No secrets or personal information are included.

Activity

  1. lidge-jun commented on Sep 10, 2026

    @lidge-jun
    OwnerAuthor

    리뷰 · 우선순위 48 / 80

    이 이슈는 문서만의 문제다. 사용자가 프로바이더를 OpenCodex에 연결하기 전에 가장 먼저 묻는 질문 — “이 로그인은 구독 한도를 쓰나, 아니면 API 키처럼 토큰당 과금인가?” — 가 docs-site/src/content/docs/guides/providers.md(공개 URL https://opencodex.me/guides/providers/)에 없다. X @iGotYourBackMr가 Claude Max 구독으로 Codex 앱에서 Claude를 쓰면 Max 한도인지 Anthropic API 과금인지 물은 것과 같은 종류다. 구독 로그인과 API 키를 둘 다 받는 프로바이더마다 같은 질문이 반복되므로, X 답변으로는 스케일이 안 된다.

    현재 dev HEAD 6101140ff(2.51.0)에서 해당 가이드 파일은 존재한다. 이슈가 원하는 규칙은 벤더 마케팅 티어가 아니라 인증 모드 기준이다. OAuth/구독 로그인이면 그 구독 한도와 쿼터 창을 쓰고, API 키면 그 키 계정에 토큰당 청구되며, OpenCodex가 하나를 다른 하나로 바꾸지 않는다는 한 줄. 프로바이더마다 같은 한 줄을 붙이고, 대시보드 계정 카드에서 지금 모드를 확인하라는 짧은 안내면 충분하다. 닫힌 #3777(Anthropic 구독 티어 노출)도 같은 혼동이 제품 표면으로 온 사례라, 문서와 제품이 같은 말을 쓰면 좋다.

    제품 레인(L3/L5 등)과 코드 충돌은 거의 없다. docs-only라 types/config 쪼개기에도 안 걸린다. 우선순위는 제품 버그·통합보다 낮으니, 제품 레인 직후 작은 docs PR로 잡거나, 문서만 따로 빠르게 넣어도 된다. feasibility에서 말한 “schedule after product lane or small docs PR”과 같다.

    경로/심볼 - docs-site/src/content/docs/guides/providers.md: 구독 vs API 과금 한 줄이 없음
    경로/심볼 - 인증 모드 규칙: OAuth/구독 = 구독 한도, API 키 = 토큰당 (변환 없음)
    이슈 - #3777 (닫힘): 같은 혼동이 제품 쪽에서도 온 선행 사례

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

    너의 추천
    docs-only로 providers.md에 인증 모드별 한 줄 규칙을 추가하라. 코드 변경 없이 작은 PR이면 제품 레인과 병렬로도 괜찮고, 여력이 없으면 제품 레인 직후로 스케줄하라. 닫지 말고 열어 두되, types/config 캠페인과는 무관하니 기다릴 필요 없다.

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

  2. lidge-jun commented on Sep 11, 2026

    @lidge-jun
    OwnerAuthor

    Fixed on dev via #4239 at 271a0ab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions