Grok build usage

[salavatkhafizov]

Please check Grok build usage limits calculation - looks like they just shifted to weekly limits (used to be monthly limit)

[clawsweeper]

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

Summary
Keep open: current main has prior Grok Weekly/Monthly label work, but the reported calculation concern is not proven fixed because the CLI path still decodes monthlyLimit and the web path only has percent/reset metadata.

Reproducibility: no. not with high confidence. Source inspection shows monthly-specific Grok calculation code, but AGENTS.md discourages live provider probes without explicit request and the issue does not include a current Grok payload or screenshot.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
A maintainer or reporter should provide a redacted current Grok billing payload or live-provider confirmation before a repair worker guesses at the upstream weekly-limit contract.

Review details

Best possible solution:

Update the Grok billing parser from an actual current CLI or web billing sample, keep the UI label tied to true period metadata where available, and cover weekly-limit payloads with focused parser tests.

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

No, not with high confidence. Source inspection shows monthly-specific Grok calculation code, but AGENTS.md discourages live provider probes without explicit request and the issue does not include a current Grok payload or screenshot.

Is this the best way to solve the issue?

Unclear. The maintainable path is to update the existing Grok parser and tests from a real current provider response rather than infer weekly behavior only from reset distance.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The issue has no attached Grok CLI JSON-RPC payload or grok.com protobuf sample, so a code change would risk guessing at xAI's new field names or denominator semantics.
• The web billing fallback currently parses percent and reset timestamp but not an explicit period length, so it may still be unable to distinguish true weekly limits from monthly limits late in the cycle.

Codex review notes: model internal, reasoning high; reviewed against 6b3f265c7512.

Label changes

Label changes:

• add P2: This is a focused user-facing provider usage-limit calculation issue with limited blast radius to Grok.
• add impact:other: The concrete impact is incorrect Grok usage-limit display, which is maintainer-visible but outside the owned auth/message/session/security categories.
• 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:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: This is a focused user-facing provider usage-limit calculation issue with limited blast radius to Grok.
• impact:other: The concrete impact is incorrect Grok usage-limit display, which is maintainer-visible but outside the owned auth/message/session/security categories.

Evidence reviewed

Acceptance criteria:

• swift test --filter GrokBillingResponseTests
• swift test --filter GrokWebBillingFetcherTests
• make check

What I checked:

• Issue report: The issue body reports that Grok Build usage limits appear to have shifted from monthly to weekly and asks maintainers to check the calculation.
• Current CLI billing model is monthly-specific: Current main still models the Grok CLI billing response with a monthlyLimit field. (Sources/CodexBarCore/Providers/Grok/GrokRPCClient.swift:306, 6b3f265c7512)
• Current percent calculation uses monthlyLimit as denominator: monthlyUsedPercent divides usage.totalUsed by monthlyLimit, so a renamed or semantically changed weekly field would not be handled by this code path. (Sources/CodexBarCore/Providers/Grok/GrokRPCClient.swift:337, 6b3f265c7512)
• Current usage projection still consumes monthlyUsedPercent: GrokUsageSnapshot.toUsageSnapshot() creates the primary window from billing.monthlyUsedPercent; the web fallback supplies only a parsed percent and reset timestamp. (Sources/CodexBarCore/Providers/Grok/GrokStatusProbe.swift:31, 6b3f265c7512)
• Prior merged fix addressed labeling, not confirmed calculation semantics: Merged pull request Make Grok usage bar label reflect actual reset cycle #1148 made Grok usage labels follow reset windows, but its body and review discussion frame the change as label text, not a new weekly-limit denominator contract. (c644f6874e9a)
• Docs still describe the CLI contract as monthlyLimit: The Grok provider docs still document x.ai/billing as returning monthlyLimit and mapping usage as usage.totalUsed.val / monthlyLimit.val * 100. (docs/grok.md:79, 6b3f265c7512)

Likely related people:

• taibaran: Introduced the Grok provider, CLI billing response model, status probe, tests, and docs that still define the monthlyLimit calculation surface. (role: introduced behavior; confidence: high; commits: 0348028dad91; files: Sources/CodexBarCore/Providers/Grok/GrokRPCClient.swift, Sources/CodexBarCore/Providers/Grok/GrokStatusProbe.swift, Tests/CodexBarTests/GrokBillingResponseTests.swift)
• steipete: Added the Grok web billing fallback and is the most recent merger on current main, including nearby provider fetch hardening. (role: recent area contributor; confidence: high; commits: 6a1eae223a76, 6b3f265c7512; files: Sources/CodexBarCore/Providers/Grok/GrokWebBillingFetcher.swift, Sources/CodexBarCore/Providers/Grok/GrokProviderDescriptor.swift, Sources/CodexBarCore/Providers/Grok/GrokStatusProbe.swift)
• kiankyars: Authored the merged Grok label-cycle change that directly overlaps the weekly/monthly user-visible behavior. (role: adjacent owner; confidence: high; commits: c644f6874e9a; files: Sources/CodexBarCore/Providers/Grok/GrokProviderDescriptor.swift, Sources/CodexBarCore/Providers/Grok/GrokStatusProbe.swift, Tests/CodexBarTests/GrokWebBillingFetcherTests.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.

[steipete]

Maintainer reproduction audit (2026-07-01, CodexBar main 24490b6434d491a5478ea6636f014744ada3cbeb): I could not obtain the one missing artifact—a current authenticated Grok Build billing payload—so I am not changing the parser speculatively.

Current evidence:

• xAI's current Grok Build command documentation documents /usage as token and credit usage for the session. It does not publish the subscription limit/reset contract.
• The installed official CLI is grok 0.1.211. Its current binary still contains the contract names monthlyLimit, billingPeriodStart, billingPeriodEnd, includedUsed, and totalUsed; there is no weeklyLimit contract name.
• A redacted ACP probe successfully initialized the current CLI, then x.ai/billing returned -32601 Method not found. This matches CodexBar's documented limitation, now confirmed on 0.1.211 as well as 0.1.210.
• No authorized Grok Build login/browser session was available in the permitted local sources. No unrelated API-platform credential was used as a substitute for the consumer subscription product.
• Current CodexBar behavior is internally consistent for the known payload: percent is usage.totalUsed / monthlyLimit; reset comes from billingPeriodEnd; when start and end are available, their duration drives the visible Weekly/Monthly label. The web fallback supplies only upstream percent plus reset time, so it cannot prove the denominator or full cycle length.
• Active-PR overlap audit found no open Grok/Grok Build PR or PR touching the Grok provider files.

Minimal proof needed to repair this safely:

1. grok --version.
2. A redacted authenticated x.ai/billing result from a CLI/version where that method succeeds. Keep field names; remove tokens/account/team IDs. Timestamps may be shifted together while preserving the start→end duration. Monetary values may be normalized by one common factor while preserving totalUsed / limit.
3. If the CLI method still fails, a sanitized Grok Build usage screenshot plus the successful billing response captured by Grok's own UI, with cookies/tokens/account identifiers removed. We need the limit field name, used field name, period start/end (or exact duration), and displayed percentage.

The decisive question is whether xAI changed only the billing-cycle duration while retaining monthlyLimit, or introduced a new weekly denominator/field. Those require different fixes. Guessing either could silently display the wrong percentage.

Recommendation: keep open with needs-live-repro; no code/PR until the minimal payload above is available.

Redacted current CLI proof

{"id":1,"result_keys":["_meta","agentCapabilities","authMethods","protocolVersion"],"auth_method_ids":["grok.com"]}
{"id":2,"error_code":-32601,"error_message":"Method not found","result_keys":[]}

[salavatkhafizov]

1. grok 0.2.73 (9ff14c43bbe5) [stable]
2. pls see attachment
3. can't help

Looks like siginificant change - even web chats have weekly limits too.