Doubao: surface Coding Plan usage (session/weekly/monthly) via GetCodingPlanUsage instead of "Limits not available"

[LeoLin990405]

Summary

After #1382 / #1454, Doubao correctly stops showing a false "100% used" and instead shows "Limits not available" — because the Volcano Ark bearer key exposes no usage at all. But the data does exist: the Ark Coding Plan usage is available via a Volcengine OpenAPI whose shape maps 1:1 onto CodexBar's existing session/weekly/monthly windows. This issue proposes surfacing it.

Why "Limits not available" happens (confirmed)

Probing POST ark.cn-beijing.volces.com/api/coding/v3/chat/completions (and the standard /api/v3) with the ARK_API_KEY returns HTTP 200 but no x-ratelimit-* headers (only x-request-id). So requestLimitsReliable is always false → "Limits not available". There is no bearer-key endpoint that returns Ark request limits.

The data does exist — GetCodingPlanUsage

The console's 开通管理 → subscribe tab calls the Ark Top OpenAPI GetCodingPlanUsage (Service=ark, Version=2024-01-01). Response shape (values neutralised):

{
  "Status": "Running",
  "UpdateTimestamp": 0,
  "QuotaUsage": [
    { "Level": "session", "Percent": 0.0, "ResetTimestamp": 0 },
    { "Level": "weekly",  "Percent": 0.0, "ResetTimestamp": 0 },
    { "Level": "monthly", "Percent": 0.0, "ResetTimestamp": 0 }
  ]
}

That is exactly CodexBar's model: each Level → a RateWindow(usedPercent:, resetsAt:), the same way Claude/Codex coding plans render session/weekly/monthly. (Subscription presence is confirmable via ListSubscribeTrade → ResourceType: "CodingPlan".)

Proposal

For Doubao Coding Plan keys, fetch GetCodingPlanUsage and map session → primary, weekly → secondary, monthly → tertiary, replacing "Limits not available" with real usage bars.

Caveat (raising as an issue first, not a PR)

GetCodingPlanUsage is a Volcengine OpenAPI requiring AK/SK V4 request signing — distinct from the existing ARK_API_KEY bearer credential. So this needs a new credential type (Volcengine AccessKey/SecretKey) + the Volc V4 signature, which is a product decision. If you're open to adding an AK/SK credential for Doubao, I'm happy to implement (provider fetcher + signing + settings UI + tests).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 23, 2026, 12:29 PM ET / 16:29 UTC.

Summary
Keep this issue open: current main still only supports the Doubao Ark bearer-key probe and intentionally renders unavailable limits when request-limit headers are missing, while an open draft PR already owns the requested signed Coding Plan implementation.

Reproducibility: no. high-confidence live reproduction was run. Source inspection confirms the current fallback path: valid Doubao snapshots without reliable request-limit headers omit rate windows and render unavailable limits.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
No separate ClawSweeper fix PR should be queued because the issue already has an open draft implementation PR linked with closing syntax.

Review details

Best possible solution:

Keep this issue open while maintainers review the linked draft PR and either land it with the needed provider-auth sign-off or close that PR and document the chosen Doubao limitation.

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

No high-confidence live reproduction was run. Source inspection confirms the current fallback path: valid Doubao snapshots without reliable request-limit headers omit rate windows and render unavailable limits.

Is this the best way to solve the issue?

Unclear until the linked draft PR is reviewed. The requested data source matches the missing behavior, but adding AK/SK credentials and V4 signing is a product/auth decision rather than a strict bug fix.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The remaining work adds Volcengine AK/SK credentials and request signing, so maintainers still need to decide whether that provider auth/storage surface belongs in CodexBar.
• The GetCodingPlanUsage endpoint behavior is reporter-provided and represented by the linked PR; I did not run a live Volcengine probe because repository policy avoids live provider checks unless explicitly requested.

Codex review notes: model internal, reasoning high; reviewed against 929d55aaf1d7.

Label changes

Label changes:

• add P2: This is a concrete provider usage improvement with limited blast radius but real user-visible value for Doubao Coding Plan users.
• add impact:other: The issue affects provider quota display accuracy for Doubao, which is maintainer-visible but outside the more specific owned impact labels.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a concrete provider usage improvement with limited blast radius but real user-visible value for Doubao Coding Plan users.
• impact:other: The issue affects provider quota display accuracy for Doubao, which is maintainer-visible but outside the more specific owned impact labels.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was present and read fully; its guidance affected the review by steering away from live provider probes and toward source/test inspection for provider behavior. (AGENTS.md:1, 929d55aaf1d7)
• Current Doubao snapshot omits unknown limits: Current main only creates a primary RateWindow when limitRequests > 0 and requestLimitsReliable; a valid key with unreliable headers leaves primary nil and the snapshot has no secondary or tertiary windows. (Sources/CodexBarCore/Providers/Doubao/DoubaoUsageFetcher.swift:32, 929d55aaf1d7)
• Current fetch path is Ark bearer-key header probing: The current fetcher posts to the Ark chat-completions endpoint with Authorization: Bearer and parses only x-ratelimit-* request headers; there is no signed GetCodingPlanUsage path in this file. (Sources/CodexBarCore/Providers/Doubao/DoubaoUsageFetcher.swift:91, 929d55aaf1d7)
• Current descriptor uses a single API-token strategy: Doubao’s provider descriptor resolves one API token and calls DoubaoUsageFetcher.fetchUsage(apiKey:), so current main does not expose a Volcengine AK/SK credential strategy. (Sources/CodexBarCore/Providers/Doubao/DoubaoProviderDescriptor.swift:33, 929d55aaf1d7)
• Settings UI stores only the Ark API key: The app-side Doubao settings field is a single secure API key binding, matching the issue’s caveat that a new credential type would be needed. (Sources/CodexBar/Providers/Doubao/DoubaoProviderImplementation.swift:16, 929d55aaf1d7)
• Current tests assert the unavailable-limits presentation: The Doubao menu-card test expects unreliable request-limit headers to produce no metrics and the Limits not available placeholder. (Tests/CodexBarTests/DoubaoMenuCardModelTests.swift:40, 929d55aaf1d7)

Likely related people:

• LeoLin990405: Authored the original Doubao provider work and the merged false-100% Doubao fix, and opened the linked draft implementation PR for this request. (role: introduced behavior and current feature proposer; confidence: high; commits: 6eb3699ec977, a31709838797, eee464d01e5c; files: Sources/CodexBarCore/Providers/Doubao/DoubaoUsageFetcher.swift, Sources/CodexBarCore/Providers/Doubao/DoubaoProviderDescriptor.swift, Sources/CodexBar/Providers/Doubao/DoubaoProviderImplementation.swift)
• steipete: Merged the original Doubao provider PR, carried recent Doubao follow-up fixes, and authored the unavailable-limits behavior that this feature would supersede for Coding Plan users. (role: recent area contributor and merger; confidence: high; commits: 6eb3699ec977, a31709838797, 4a6fa81c3e1f; files: Sources/CodexBarCore/Providers/Doubao/DoubaoUsageFetcher.swift, Tests/CodexBarTests/DoubaoUsageFetcherTests.swift, Tests/CodexBarTests/DoubaoMenuCardModelTests.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.

[foobra]

@LeoLin990405 If user install ark-cli (https://console.volcengine.com/ark/region:cn-beijing/arkcli)

you can query usage stats via cli :