Feature Request: Support Qwen Cloud / DashScope pay-as-you-go API balance and usage

[mvicari]

Summary

Currently, CodexBar's Qwen Cloud provider (.qwencloud) exclusively tracks the individual Token Plan (Personal/Solo) via web console session cookies from home.qwencloud.com (reporting rolling 5-hour and 7-day rate windows).

However, many users access Qwen models (such as Qwen 2.5 / Qwen 3 Coder, Qwen-Max, and Qwen-Plus) via standard pay-as-you-go API keys (DashScope / Qwen Cloud API keys) billed against an account cash balance or credit card, rather than a fixed Token Plan subscription.

I would like CodexBar to support tracking pay-as-you-go account balance and spend for Qwen Cloud / DashScope accounts, similar to existing API balance providers like DeepSeek (deepseek) and Doubao (doubao).

Current Behavior

• Enabling qwen-cloud requires web cookies from home.qwencloud.com and attempts to fetch zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/* endpoints.
• In QwenCloudProviderDescriptor.swift, supportsCredits and supportsTokenCost are hardcoded to false.
• Accounts without an active Token Plan subscription cannot view their remaining account balance or API spend.

Expected Behavior

1. Balance & Credit Display: Support displaying available account balance / prepaid credits for pay-as-you-go accounts.
2. API-First Authentication: Allow configuring an API key (or Alibaba Cloud RAM / BSS OpenAPI credentials if the inference gateway lacks a direct balance endpoint) without requiring browser cookie imports.
3. Graceful Handling: If an account has no Token Plan subscription but has a valid pay-as-you-go balance, show the balance instead of failing or reporting missing token plan data.

Relevant Context

• PR feat(providers): add Qwen Cloud individual token-plan provider #2361 added the initial Qwen Cloud Token Plan provider.
• Issue Alibaba Coding Plan: INTL accounts cannot fetch usage — no working auth path #612 investigated DashScope API endpoints and noted that inference keys on coding-intl.dashscope.aliyuncs.com return 404 for /v1/usage and /v1/quota. A billing/balance integration may need to target Alibaba Cloud BSS OpenAPI (QueryAccountBalance) or Qwen Cloud console balance endpoints.
• PR Add China API models.dev pricing lookup #2376 added China API pricing lookups for session cost attribution.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 11, 2026, 3:33 AM ET / 07:33 UTC.

Summary
Keep open: pay-as-you-go billing remains unsupported, and the related work does not supply it. This is a distinct provider feature requiring a verified billing contract and authentication decision; the repository profile also prohibits automatic closure.

Reproducibility: not applicable. this requests new billing coverage; current source and released documentation explicitly limit Qwen support to Token Plan quotas.

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
Should Qwen pay-as-you-go support accept separate Alibaba billing credentials when inference API keys cannot retrieve balances?	Conditionally support read-only billing: Approve the direction once a documented or redacted working endpoint establishes account scope and minimum read-only permissions.

Why: That choice expands authentication and account scope beyond the existing Token Plan provider, and VISION.md requires sign-off for such changes.

Next step
Confirm the acceptable billing credential scope and obtain a documented or redacted working balance response before commissioning implementation.

Review details

Best possible solution:

Use a verified, least-privilege billing API and shared provider presentation, clearly separating account currency balances from Token Plan credits while preserving existing cookie-based subscriptions.

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

Not applicable: this requests new billing coverage; current source and released documentation explicitly limit Qwen support to Token Plan quotas.

Is this the best way to solve the issue?

Unclear: API-first billing fits the product, but the endpoint and credential contract must be verified before choosing an implementation; toggling capability flags alone would not provide balances.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The report proposes billing endpoints but does not establish their account coverage, required credential permissions, currencies, or available spend fields.

Codex review notes: model internal, reasoning medium; reviewed against 4cfb60692bdd.

Label changes

Label changes:

• add P2: This is useful, bounded provider coverage without an established regression or blocked supported setup.
• add impact:other: Pay-as-you-go users lack account balance and spend visibility in CodexBar.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is useful, bounded provider coverage without an established regression or blocked supported setup.
• impact:other: Pay-as-you-go users lack account balance and spend visibility in CodexBar.

Evidence reviewed

What I checked:

• Current implementation remains subscription-only: The descriptor permits auto/web sources and returns no strategy for API mode. The fetcher calls individual Token Plan usage, subscription, and quota-config endpoints; its snapshot produces quota windows with providerCost nil. (Sources/CodexBarCore/Providers/QwenCloud/QwenCloudProviderDescriptor.swift:88, 4cfb60692bdd)
• Documented and released limitation: Current documentation explicitly excludes API-key authentication and token-cost summaries. The same limitation appears in v0.59.0; no implemented billing fix was established. (docs/qwen-cloud.md:51, dca9c5f4b7a2)
• Prior endpoint investigation informs feasibility: In Alibaba Coding Plan: INTL accounts cannot fetch usage — no working auth path #612, steipete closed the Coding Plan investigation after diagnostic cleanup, explaining that implementation needed a working authenticated quota endpoint or redacted console request. That discussion concerns subscription quota, so it neither proves nor disproves a pay-as-you-go billing API.
• Related work does not own account billing: The supplied GitHub context confirms feat(providers): add Qwen Cloud individual token-plan provider #2361 merged Token Plan support. Add China API models.dev pricing lookup #2376 remains open and concerns local session pricing, not account cash balance. REST searches for Qwen balance, DashScope, and QueryAccountBalance found no distinct canonical billing implementation.
• Vision supports coverage with authentication sign-off: VISION.md welcomes provider coverage using existing patterns, while requiring sign-off for features and changes affecting provider authentication or privacy. (VISION.md:19, 4cfb60692bdd)
• Area-history routing: Path history shows Qwen work by Umut Keltek and descriptor/credential refactors by Peter Steinberger; GitHub confirms umutkeltek authored merged fix(qwen-cloud): restore Brave browser support in cookie import #3148 and steipete authored merged refactor: unify CLI onto descriptor-owned provider capabilities #2685. Exact-line blame and content-history searches failed because required historical objects could not be retrieved; introduction attribution is therefore left unknown. (Sources/CodexBarCore/Providers/QwenCloud/QwenCloudProviderDescriptor.swift, c2701d241f97)

Likely related people:

• umutkeltek: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.

[steipete]

Current main still supports Qwen Cloud Token Plan quotas only. Alibaba documents QueryAccountBalance, but its official SDK uses signed AccessKey billing requests, not a DashScope inference bearer key. The response is an Alibaba account balance, not Qwen-specific spend. Keeping this open pending a scoped billing-auth/signing design and confirmation of the desired account/currency presentation.