Alibaba Token Plan: personal (Solo) subscriptions render no quota rows — ProductCode is hardcoded to the Teams plan

[LeoLin990405]

Summary

On a personal (Solo) Alibaba Token Plan subscription, the Alibaba Token Plan card authenticates fine but renders no quota rows — primary, secondary and tertiary are all null. The card shows only the provider title and Plan: Token Plan.

The subscription-summary request is hardcoded to the Teams product code, and the console returns an empty payload for a Solo subscription.

Environment

• CodexBar 0.45.0 (also reproduced on 0.41.0)
• macOS, menu-bar app + codexbar CLI
• Alibaba Model Studio / Bailian, region cn-beijing
• Subscription: Token Plan "Pro 套餐", personal (Solo), auto-renew on
• Auth: cookie (web), working

Observed

codexbar usage --provider alibabatokenplan --format json (redacted):

{
  "usage": {
    "identity": { "providerID": "alibabatokenplan", "loginMethod": "TOKEN PLAN" },
    "primary": null,
    "secondary": null,
    "tertiary": null,
    "updatedAt": "2026-07-21T09:03:25Z"
  },
  "source": "web",
  "provider": "alibabatokenplan"
}

Text output is just:

== Alibaba Token Plan (web) ==
Plan: Token Plan

Auth itself is healthy — debug log shows the sec_token being resolved and a 200 response:

info …alibaba-token-plan: bodyBytes=225 userInfoHost=bailian.console.aliyun.com  Resolved Alibaba Token Plan sec_token from user info
info …alibaba-token-plan: bodyBytes=407 contentType=application/json;charset=UTF-8 status=200  Alibaba Token Plan HTTP response

So the provider reaches the API and gets a 200 — the 407-byte body simply carries no quota fields.

Root cause (source-level)

AlibabaTokenPlanUsageFetcher builds the subscription-summary request with a product code that is hardcoded to the Teams plan:

Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanAPIRegion.swift

public var tokenPlanProductCode: String {
    switch self {
    case .international:
        "sfm_tokenplanteams_dp_intl"
    case .chinaMainland:
        "sfm_tokenplanteams_dp_cn"
    }
}

Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageFetcher.swift:284

let paramsObject = ["ProductCode": region.tokenPlanProductCode]

…which is then posted as action=GetSubscriptionSummary&product=BssOpenAPI-V3.

git grep -c "tokenplansolo\|solo_public" Sources/ → 0 matches. There is no Solo/personal code path.

Evidence that this account is a Solo subscription

Captured from the Bailian console's own calls on
#/efm/subscription/token-plan/personal (values redacted):

action=QueryAvailableInstances&product=BssOpenApi

{
  "Data": {
    "TotalCount": 1,
    "InstanceList": [
      {
        "InstanceID": "sfm_tokenplansolo_public_cn-<redacted>",
        "ProductType": "sfm_tokenplansolo_public_cn",
        "ProductCode": "sfm",
        "SubscriptionType": "Subscription",
        "Status": "Normal",
        "RenewStatus": "AutoRenewal",
        "EndTime": "2026-08-21T16:00:00Z"
      }
    ]
  },
  "Code": "Success"
}

The instance is sfm_tokenplan**solo**_public_cn, while CodexBar asks about
sfm_tokenplan**teams**_dp_cn.

Notably, the console's own summary call — with the Teams product code — also comes back empty for this account:

action=GetSeatSubscriptionSummary&product=BssOpenAPI-V3&params={"ProductCode":"sfm_tokenplanteams_dp_cn"}

{ "Data": {}, "Code": "Success", "Success": true }

Meanwhile the console page itself does render the two quota windows CodexBar models well — 5小时用量 (5-hour) and 7天用量 (7-day), both with 0/50/90/100% markers, plus "最后统计时间" (last aggregation time).

What is verified vs. not

Verified:

• Cookie auth and sec_token resolution work; the summary endpoint returns HTTP 200.
• CodexBar sends the Teams product code on a Solo subscription.
• The Teams-code summary call returns an empty Data object for this account.
• There is no Solo/personal product code anywhere in the source.
• Result: all three rate windows are nil, so the card renders no usage.

Not verified (being explicit rather than guessing):

• I have not confirmed that simply substituting the Solo product code would populate the quota fields. This subscription was created today and currently shows 0% on both the 5-hour and 7-day windows, so an empty/zero response is not yet distinguishable from a wrong-product-code response. I'd rather report the mismatch than assert a fix I can't demonstrate.

I'm happy to re-test and post a redacted before/after once this account has accumulated real usage, if that's useful.

Possible directions

Rather than hardcoding a second constant, the product code could be discovered:

1. Call QueryAvailableInstances (product=BssOpenApi) and read ProductType from the returned instance, then use it for the summary request — this covers Solo, Teams and any future SKU.
2. Or try the Teams code and fall back to the Solo code when Data comes back empty.
3. Whether the Solo quota actually lives behind GetSubscriptionSummary at all still needs confirming — the console's Solo page may source the 5-hour/7-day windows from a different call.

Happy to help verify any of these against a live Solo account.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this issue: Alibaba Token Plan: personal (Solo) subscriptions render no quota rows — ProductCode is hardcoded to the Teams plan This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[LeoLin990405]

Correction to my own analysis — the ProductCode is not the root cause. I kept digging after filing and the mismatch I reported turns out to be a red herring. Posting the corrected diagnosis rather than leaving the wrong one standing.

What I got wrong

I assumed the Teams-vs-Solo ProductCode mismatch caused an empty payload. It does not. Re-running both codes against GetSubscriptionSummary with a valid sec_token returns the same shape either way (redacted):

// ProductCode = sfm_tokenplansolo_public_cn   (410 B)
{ "Data": { "Uid": …, "TotalSurplusValue": "0", "TotalCount": 0,
            "TotalValue": "0", "ProductCode": "sfm_tokenplansolo_public_cn" },
  "Code": "Success" }

// ProductCode = sfm_tokenplanteams_dp_cn      (same shape)
{ "Data": { "Uid": …, "TotalSurplusValue": "0", "TotalCount": 0,
            "TotalValue": "0", "ProductCode": "sfm_tokenplanteams_dp_cn" },
  "Code": "Success" }

The empty "Data": {} I quoted originally came from GetSeatSubscriptionSummary (what the console page calls), not from GetSubscriptionSummary (what CodexBar calls). My mistake — those are two different actions and I conflated them.

The actual root cause

Parsing works fine. TotalValue: "0" is picked up by totalQuotaKeys, and planName resolves to TOKEN PLAN — which is exactly why the card shows the title but nothing else. The rows are dropped one layer down:

Sources/CodexBarCore/Providers/Alibaba/AlibabaTokenPlanUsageSnapshot.swift

private static func usedPercent(used: Double?, total: Double?, remaining: Double?) -> Double? {
    guard let total, total > 0 else { return nil }   // total == 0 → no window
    …

So: GetSubscriptionSummary answers 200 with TotalValue = "0", usedPercent correctly refuses to divide by zero, primary becomes nil, and the card renders with no quota row.

Why the value is zero

GetSubscriptionSummary (product=BssOpenAPI-V3) is a billing/BSS subscription summary — it reports subscription value/credits, not Token Plan consumption. For a Token Plan subscription it appears to be legitimately 0.

The quota CodexBar wants to show — the console's 5小时用量 (5-hour) and 7天用量 (7-day) windows on #/efm/subscription/token-plan/personal, with a "最后统计时间" (last aggregation) timestamp — is not carried by this endpoint at all. I captured every XHR/fetch the console page makes when that panel loads; only four actions fire (GetTokenPlanAccountDetail, GetSeatSubscriptionSummary, QueryAvailableInstances, QueryRenewPeriod) and none of them contains a usage/percent/quota field. So the 5-hour / 7-day figures come from somewhere I haven't found yet.

Where that leaves the issue

The user-visible bug stands: a Token Plan subscription shows a card with no usage rows. But the fix is not a ProductCode swap — the provider is reading an endpoint that does not carry Token Plan consumption.

Two honest open questions I could not settle:

1. Which call actually backs the 5-hour / 7-day windows. (Not in the four page requests; possibly SSR-embedded, a different host, or aggregated client-side.)
2. Whether TotalValue is ever non-zero for some Token Plan account shape — my subscription was created today, so a zero is not conclusive on its own.

Happy to keep digging, or to test any specific endpoint/param against a live personal Token Plan account if that helps narrow it down. Sorry for the noise in the original root-cause section.

[LeoLin990405]

Cross-reference: #2329 answers my open question 1 — but for the other console. This one is the China-mainland twin, not a duplicate.

@Yach0's #2329 (for #2328) found the endpoint I said I couldn't locate:

POST https://cs-data.qwencloud.com/data/api.json
  ?product=sfm_bailian&action=IntlBroadScopeAspnGateway
  &api=zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/usage
→ per5HourPercentage / per1WeekPercentage + epoch-ms reset times

That confirms the class of bug I reported: the personal plan doesn't live behind GetSubscriptionSummary at all — it's a REST path tunnelled through a generic ASPN gateway action, with rolling windows instead of a credit pool. My TotalValue: "0" finding is the same symptom seen from the other side.

Why #2329 doesn't close this

#2329 adds a third region case, .qwenCloudPersonal (home.qwencloud.com), and routes only that one to the new API:

public var usesPersonalTokenPlanAPI: Bool {
    self == .qwenCloudPersonal
}

.chinaMainland is untouched. The PR's own docs table states this explicitly:

Region	Console	Quota API
cn	bailian.console.aliyun.com	GetSubscriptionSummary (team credit pool)
qwen	home.qwencloud.com	.../tokenplan/personal/api/v2/* (rolling windows)

and its test pins the old behaviour:

#expect(AlibabaTokenPlanAPIRegion.chinaMainland.tokenPlanProductCode == "sfm_tokenplanteams_dp_cn")

My subscription is a personal (Solo) plan on bailian.console.aliyun.com/cn-beijing (sfm_tokenplansolo_public_cn) — i.e. the .chinaMainland path. After #2329 merges, the international personal plan works and this account still renders an empty card. Two consoles, same product family, one covered.

To be clear, this is not a gap in #2329 — #2328 scoped it to Qwen Cloud, and it does that job. I'm flagging the boundary so the two issues don't get collapsed into one.

What I think the mainland shape is (unverified)

#2329's request body hardcodes the console identity:

"cornerstoneParam": [
    "domain": "home.qwencloud.com",
    "consoleSite": "QWENCLOUD",
    ...
]

and the action is named IntlBroadScopeAspnGateway — the Intl prefix suggests a mainland sibling. The api path itself (zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/*) and product=sfm_bailian are likely shared, since the mainland console is Bailian.

That's a hypothesis, not a finding. I'm going back to the Bailian console to look for the mainland gateway action now that I know what shape to look for — my earlier capture missed it precisely because I was grepping responses for usage-like field names rather than looking for a tunnelled REST path. I'll report back either way; if it turns out mainland personal has no such endpoint, that's worth recording too.

Happy to defer entirely if you'd rather land #2329 first and treat mainland personal as a follow-up on top of the region plumbing it introduces — that's probably the cleaner sequencing, since a mainland variant would reuse AlibabaTokenPlanPersonalAPI rather than duplicate it.

[LeoLin990405]

Found the mainland endpoint. The delta from #2329 is a single constant — the host.

Open question 1 from my last comment is now answered for bailian.console.aliyun.com. All three personal-plan endpoints exist on the mainland console with byte-identical request and response shapes to the Qwen Cloud variant in #2329.

Why I missed it the first time

My original capture only watched bailian.console.aliyun.com. The personal-plan calls go to a different host — bailian-cs.console.aliyun.com — so they never appeared in the four actions I reported. That was the "different host" possibility I listed and then failed to actually check. Mea culpa; the four-action claim in the issue body should be read as "four actions on that one host".

The mainland endpoint

POST https://bailian-cs.console.aliyun.com/data/api.json
  ?action=BroadScopeAspnGateway
  &product=sfm_bailian
  &api=zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/{usage,subscription,quota-config}

Live responses from a personal (Solo) cn-beijing subscription, unwrapped at data.DataV2.data.data — the same envelope AlibabaTokenPlanPersonalAPI.unwrapPayload already walks:

// usage
{ "per5HourPercentage": 0.0009973083333333333, "per5HourResetTime": 1784813220000,
  "per1WeekPercentage": 0.0003014725,          "per1WeekResetTime": 1785234900000 }

// subscription
{ "instanceCode": "sfm_tokenplansolo_public_cn-<redacted>", "specCode": "pro",
  "status": "VALID", "remainingDays": 29, "autoRenewFlag": false,
  "startTime": 1784622404000, "endTime": 1787328000000 }

// quota-config
{ "lite":     { "five_hour": 700,   "weekly": 2500  },
  "standard": { "five_hour": 3000,  "weekly": 10000 },
  "pro":      { "five_hour": 12000, "weekly": 40000 } }

Cross-check that the percentages are fractions of the tier ceiling: 0.0009973 × 12000 ≈ 12.0 and 0.0003015 × 40000 ≈ 12.1. Both windows agree on ~12 credits consumed, which matches my actual usage today. So the specCode → quota-config join in #2329 carries over unchanged.

What actually differs between the two consoles

I probed the gateway with six request variants to find the real requirements rather than guessing from one capture:

Variant	Result
No cornerstoneParam	❌ Bad Request — the envelope is required
cornerstoneParam with mainland values (domain: bailian.console.aliyun.com, consoleSite: ALIYUN)	✅
cornerstoneParam with #2329's Qwen Cloud values verbatim	✅ — contents are not validated
action=IntlBroadScopeAspnGateway (the intl name) against the mainland host	✅ — the action name is not region-specific
No region query item	✅
No sec_token	✅

So cornerstoneParam must be present but its contents are ignored, and neither action, region, nor sec_token needs to change. The only mainland-specific value is the host.

Worth flagging separately: this endpoint needs no sec_token at all — cookie auth alone suffices. bailian.console.aliyun.com/tool/user/info.json doesn't even carry a sec_token field for this account, yet every call above succeeded. That's a small simplification available to a mainland code path.

Suggested sequencing

@Yach0 — if you'd rather fold this into #2329, it looks like roughly:

case .chinaMainland:
    "https://bailian-cs.console.aliyun.com"     // quotaAPIBaseURLString
...
public var usesPersonalTokenPlanAPI: Bool {
    self == .qwenCloudPersonal || self == <mainland personal>
}

The complication is that .chinaMainland currently means team edition on Bailian, so mainland personal probably needs its own case (a fourth region, or a personal/team axis orthogonal to region) rather than flipping the existing one — otherwise existing mainland team users regress. That's a design call I'd rather leave to you and @steipete than pre-empt in a competing PR.

I'm happy either way: fold it into #2329 and I'll test against my live mainland Solo account, or I'll open a follow-up on top once #2329 lands. Just say which. Not opening a PR right now precisely because it would collide with yours.

All figures above are from a live personal cn-beijing Token Plan (Pro tier) — happy to re-run any specific variant.

[mudrii]

Confirmed on macOS with an international (Singapore) personal Token Plan. Browser sign-in and CodexBar automatic cookie import succeed; CodexBar detects the TOKEN plan but renders no usage, while the Model Studio console shows current five-hour and seven-day usage. This matches the Solo-versus-Teams product-code mismatch.

[mudrii]

This remains unresolved for my international personal Token Plan. Please prioritize a fix for the Solo subscription path and merge it when ready; the current build still authenticates successfully but does not show the five-hour or weekly usage.