Alibaba Token Plan (Personal/Solo, Singapore ap-southeast-1) — quota not parsed; auth succeeds but body parser returns null

[halilertekin]

Problem

The alibaba-token-plan provider in CodexBar detects the login cookie correctly and reaches modelstudio.console.alibacloud.com over HTTPS, but the parsed usage is always primary=null, secondary=null, tertiary=null. Only loginMethod=TOKEN PLAN is exposed, so the menubar widget shows "Plan: Token Plan" without any quota/reset windows.

This is distinct from #612 (which is about alibaba-coding-plan INTL users with no auth path). This issue is about alibaba-token-plan for Singapore Personal/Solo subscriptions, where auth works but quota parsing does not.

Environment

• CodexBar: latest stable (menubar build, macOS 14+)
• Account: Alibaba Cloud International (INTL) Singapore workspace
• Plan: Token Plan — Personal/Solo edition (not Coding Plan, not Team edition)
• Region: ap-southeast-1
• Authentication: Chrome Default profile cookies on modelstudio.console.alibabacloud.com (Section "Alibaba Token Plan")
• API key (sk-sp-H.RIXR.{signature}): confirmed valid for inference endpoint https://token-plan.ap-southeast-1.maas.aliyuncs.com/apps/anthropic/v1/messages (returns 200 OK), but token-plan team endpoint (sfm_tokenplanteams_dp_cn ProductCode) rejects it.

Symptoms

codexbar usage --provider alibaba-token-plan --json returns:

[
  {
    "provider": "alibabatokenplan",
    "source": "web",
    "usage": {
      "loginMethod": "TOKEN PLAN",
      "secondary": null,
      "tertiary": null,
      "updatedAt": "2026-07-20T02:24:04Z",
      "primary": null,
      "identity": {
        "providerID": "alibabatokenplan",
        "loginMethod": "TOKEN PLAN"
      }
    }
  }
]

Verbose log (--log-level trace) confirms:

apiHost=modelstudio.console.alibacloud.com dashboardCookieNames=[…27 cookies including login_aliyunid, hsite…] hasCSRF=1 region=intl secTokenSource=resolved
bodyBytes=409 contentType=application/json;charset=UTF-8 status=200

So the request succeeds (HTTP 200, sec_token resolved, region=intl) but the 409-byte JSON body does not contain the TotalValue/TotalSurplusValue/TotalCount fields that CodexBar's parser expects.

Root cause hypothesis

CodexBar's GetSubscriptionSummary call targets the China mainland Team-edition SKU (sfm_tokenplanteams_dp_cn ProductCode + region=cn-beijing hard-coded). Singapore Personal/Solo edition returns a different subscription summary payload (different field names, different SKU, different region). The cookie auth is reached correctly — only the SKU/region/hard-coded query params and the JSON shape parser need to be Personal/Solo + ap-southeast-1 aware.

Suggested fix (medium-term)

1. Detect Singapore Personal SKU from cookie/dashboard HTML and switch the ProductCode and region=ap-southeast-1 query params.
2. Make the JSON parser tolerant of alternative field names returned by the Personal/Solo subscription summary (usedQuota, totalQuota, quota, etc. — whatever the live payload shape is).
3. Alternatively, surface a clear "Quota parse unavailable for Personal edition" label instead of silently emitting primary=null so users know the issue is on the parser side, not their account.

Reproduction

# 1. Enable Alibaba Token Plan in CodexBar Settings → Providers.
# 2. Ensure Chrome is signed in to https://modelstudio.console.alibacloud.com/ap-southeast-1/
# 3. From terminal:
codexbar usage --provider alibaba-token-plan --json
# Result: usage.primary/secondary/tertiary all null despite loginMethod=TOKEN PLAN.

Workaround

Until this is fixed, Singapore Personal Token Plan subscribers must manually track quota in the Alibaba Cloud console: https://modelstudio.console.alibacloud.com/ap-southeast-1/?tab=globalset#/efm/coding_plan

Related

• Alibaba Coding Plan: INTL accounts cannot fetch usage — no working auth path #612 — Alibaba Coding Plan INTL accounts cannot fetch usage (closed but unresolved, same root mechanism)
• Unable to detect balance for Xiaomi MiMo model #2209 — Xiaomi MiMo balance detection (unrelated)

[halilertekin]

👋 Submitted by a CodexBar user (Halil, Mac Mini, halil@ertekin.me). I do not have label-write permission on this repo, so for the maintainer's triage convenience I would suggest applying:

• `provider:alibaba` (already used on Alibaba Coding Plan: INTL accounts cannot fetch usage — no working auth path #612)
• `bug`
• `priority:high` (same as Alibaba Coding Plan: INTL accounts cannot fetch usage — no working auth path #612 — Singapore/INTL quota fetching is currently broken across providers)
• `area:auth-keychain` or `area:providers`

Personal context:

• CCS profile (`albb`) successfully talks to the inference endpoint at `https://token-plan.ap-southeast-1.maas.aliyuncs.com/apps/anthropic/v1/messages\` with the same `sk-sp-H.RIXR.{signature}` key — so the auth material is valid; the gap is purely in CodexBar's `alibaba-token-plan` parser/SKU selection.
• Happy to capture an exact 409-byte response payload if useful for the parser fix; let me know.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 24, 2026, 4:00 PM ET / 20:00 UTC.

Summary
Keep open only for the repository owner’s requested affected-account retest; current source and released builds implement the Singapore Personal/Solo route and rolling-window parser. Likely related people: steipete (high) and wait2050 (high).

Reproducibility: no. current live reproduction was run because it requires an affected Alibaba account; current source and focused fixtures show the reported Team-route/parser mismatch is replaced by the Personal/Solo path.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Has an affected ap-southeast-1 Personal/Solo account confirmed that a released build now exposes its quota window, permitting closure?	Request one affected-account retest: Keep this issue open until a redacted v0.55.0 CLI result confirms a Personal/Solo quota window.

Why: Current source and release history cover the reported implementation gap, but the owner intentionally retained this issue for account-specific confirmation and repository policy disallows automatic closure.

Next step
No repair PR is appropriate because the implementation is merged and shipped; the only remaining action is an affected-account confirmation and maintainer closure decision.

Review details

Best possible solution:

Retest v0.55.0 with International — Personal/Solo selected and close once a redacted CLI result shows the 5-hour or weekly quota window; retain the merged variant and parser design.

Do we have a high-confidence way to reproduce the issue?

No current live reproduction was run because it requires an affected Alibaba account; current source and focused fixtures show the reported Team-route/parser mismatch is replaced by the Personal/Solo path.

Is this the best way to solve the issue?

Yes for the original issue: the explicit International Personal/Solo gateway plus rolling-window parser is narrower and safer than adapting Team summary fields; the remaining question is live-account confirmation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No affected Singapore Personal/Solo account has confirmed the released behavior; the owner explicitly requested that post-release validation before closure.

Codex review notes: model internal, reasoning high; reviewed against c9e7f4df556d; fix evidence: release v0.46.0, commit d04c74a71b1a.

Label changes

Label justifications:

• P2: This is a bounded provider quota-display defect with a released implementation awaiting confirmation.
• impact:auth-provider: The reported failure is in Alibaba browser-session authentication and provider quota retrieval.

Evidence reviewed

What I checked:

• Current Personal/Solo route: The international Personal/Solo variant selects ap-southeast-1 and the dedicated Singapore quota host instead of the Team subscription-summary route. (Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanAPIRegion.swift:15, c9e7f4df556d)
• Current parser behavior: The Personal parser finds 5-hour and weekly percentage fields and produces corresponding usage windows, rather than requiring Team TotalValue fields. (Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanPersonalUsageParser.swift:34, c9e7f4df556d)
• Regression coverage: Tests assert that International Personal uses the Singapore personal usage endpoint and that the shared Personal fixture yields primary and secondary windows. (Tests/CodexBarTests/AlibabaTokenPlanProviderTests.swift:79, c9e7f4df556d)
• Feature provenance: History records the Personal variants implementation, followed by the workspace-authorization repair and current retry handling for empty Success envelopes. (Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift:337, d04c74a71b1a)
• Release provenance: The merged Personal-variants commit is contained by v0.46.0; v0.55.0 additionally shipped retry handling for transient empty Personal responses. (appcast.xml:6, 061593ca15d9)
• Owner-requested confirmation: The repository owner stated that International Personal/Solo support landed through the merged implementation and asked for an ap-southeast-1 confirmation after release. (d04c74a71b1a)

Likely related people:

• steipete: Authored the Personal/Solo implementation and merged the PR explicitly connected to this report. (role: feature author and merger; confidence: high; commits: 20d54c0094a3, d04c74a71b1a; files: Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanAPIRegion.swift, Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift)
• wait2050: Authored the merged Personal/Solo workspace-authorization repair affecting the same Singapore account path. (role: follow-up auth repair author; confidence: high; commits: 4482118b7a5f; files: Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift)
• Zhongyue Lin: Authored the current-main retry handling for empty successful Personal usage responses. (role: recent provider reliability contributor; confidence: high; commits: 961d7fd10448; files: Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift, Tests/CodexBarTests/AlibabaTokenPlanProviderTests.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[doublezz10]

(not OP but chiming in as I'm having the same problem) Here's what I see after getting the cookie from Chrome; CodexBar sees that I am subscribed to the token plan and tries to pull info, but is not able to get any usage info

[steipete]

International Model Studio Personal/Solo support landed via #2487 (explicit variant + shared Personal rolling-window parser; auth path unchanged for Team users). Thanks @halilertekin for the CLI JSON and trace metadata that defined the contract. Please confirm on the next release with your ap-southeast-1 account; keeping this open until then.

[steipete]

The Alibaba Personal/Solo authentication fix is queued for the next CodexBar release. Please verify it with your personal-account setup after that release and let us know whether usage loads correctly.