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

Activity

1. clawsweeper

   added

   P2Normal priority bug or improvement with limited blast radius.Normal priority bug or improvement with limited blast radius.

   clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.

   clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.

   clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.

   impact:otherThis issue has meaningful maintainer-visible impact outside the owned taxonomy.This issue has meaningful maintainer-visible impact outside the owned taxonomy.

   issue-rating: 🌊 off-meta tidepoolIssue quality rating does not apply to this item.Issue quality rating does not apply to this item.

   on Sep 11, 2026
2. clawsweeper commented on Sep 11, 2026

   

   clawsweeperbot

   on Sep 11, 2026 – with ClawSweeper

   More actions

   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.
3. steipete commented on Sep 24, 2026

   

   steipete

   on Sep 24, 2026

   Owner

   More actions

   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.
4. steipete commented on Oct 7, 2026

   

   steipete

   on Oct 7, 2026

   Owner

   More actions

   Thanks @mvicari. QueryAccountBalance exists, but uses signed AccessKey billing requests and returns account-wide funds rather than Qwen spend. The plugin host has no Alibaba signer. Keeping this open for that capability and an explicit account-balance presentation.

   The official API documentation exposes AvailableAmount, AvailableCashAmount, credit limits, and CNY/USD/JPY currency, with bss:DescribeAcccount permission. The official SDK declares AccessKey-authenticated RPC/form POST. Plugins/ProviderPluginManifest.swift:25 and Plugins/ProviderPluginHTTPResponse.swift:272 expose static auth headers, not an Alibaba signer. The owner’s missing-host-capability stop rule applies; no native billing implementation was added.

   Maintainer decision: signed AccessKey billing requests and account-wide funds are outside what the plugin host supports today, and nobody is working on an Alibaba signer, so I am closing this as not planned for now. A PR adding that capability is welcome and I will reopen.
5. steipete

   closed this as not plannedon Oct 7, 2026