windowMinutes missing on several providers silently disables pace/forecast (zai, kimi, grok, antigravity)

[psl75011]

Summary

Several providers ship quota windows without windowMinutes. Because pace/forecast
needs the window duration to know what "expected usage at this point" is, the whole
forecasting layer silently disables itself for those providers — no pace line, no
run-out estimate, no "windows remaining" verdict from #2274. The gauges still render,
so nothing looks broken; the feature is simply absent.

Measured (v0.45.2, Linux, serve on :9120)

provider	source	usedPercent	windowMinutes	resetsAt	pace
codex	oauth	63	10080	✅	✅
claude	CodexBar	60	10080	✅	✅
zai	api	13 / 7 / 40	10080 / absent / 300	✅	❌
kimi	Kimi Code API key	43 / 8	absent / 300	✅	❌
grok	grok-web	15	absent	✅	❌
antigravity	cli	0 / 0	absent / absent	✅	❌

Every provider reports usedPercent and resetsAt. Only codex and claude report
windowMinutes on all their windows — and they are exactly the two that get a pace
object. The correlation is 1:1.

Why this matters

resetsAt alone is not enough: it tells you when the window ends, not how long
it is, so "expected consumption at this point in the window" cannot be computed. One
missing declarative field disables the entire downstream chain for four providers.

For most of these the period is not ambiguous — the plans are weekly or monthly and
the cadence is already visible from consecutive resetsAt values. It looks like the
field is simply not populated by those provider adapters rather than genuinely
unknown.

Request

Populate windowMinutes on the zai / kimi / grok / antigravity windows (deriving it
from the known plan period where the API does not return it explicitly), so pace and
the #2274 forecast light up for them the same way they already do for codex and claude.

Related

• Add weekly session-equivalent headroom #2274 — weekly run-out verdict + remaining 5-hour windows (currently only reachable
  for providers that have a pace, i.e. codex/claude).
• Side note: the Add weekly session-equivalent headroom #2274 forecast does not appear in the CodexBarCLI serve JSON output
  at all — it seems to live only in the macOS rendering layer. Exposing it in serve
  would let Linux/headless consumers show the same verdict. Happy to open that as a
  separate issue if preferred.

Environment

CodexBarCLI serve v0.45.2, static musl x86-64, Linux 7.0.0, 7 providers enabled.

[kiranmagic7]

I traced this on current main (cc8da27c). Missing windowMinutes is real on several paths, but filling those nils alone will not enable pace consistently because there is a second capability gate.

• CLI JSON: CLIRenderer.providerPacePayload maps primary to a session pace and secondary to a weekly pace, while PaceKind.supports is hardcoded to Codex/Claude/Ollama (session) and Codex/Claude/OpenCode/Ollama (weekly). z.ai, Kimi, Grok, and Antigravity remain excluded even if their windows gain durations.
• macOS menu cards: pace is opt-in through ProviderDescriptor.pace. z.ai, Kimi, and Antigravity currently use the default unsupported capability. Grok has a custom rule that already falls back to seven days when a web reset is classified as Weekly.

The provider paths also need different treatment:

• Kimi: the Code API primary quota is explicitly the weekly lane, but KimiUsageSnapshot.toUsageSnapshot() emits it with windowMinutes: nil. 10080 looks like the narrowest safe duration fix, paired with an explicit pace capability and CLI slot/mapping coverage.
• z.ai: ZaiUsageSnapshot.rateWindow deliberately drops the API duration for every TIME_LIMIT. In particular, the API's one-minute MCP marker is reinterpreted as Monthly, so copying the raw duration would be wrong. Supporting pace here needs an explicit calendar-month sentinel/capability decision.
• Grok: the CLI billing response has period start and end and already computes billingPeriodMinutes. The web snapshot retains only percentage and the next reset timestamp. A reset timestamp by itself cannot reliably distinguish weekly from monthly late in the cycle; the current remaining-time heuristic becomes unclassified near reset.
• Antigravity: quota-summary buckets already populate 300/10080 for recognized 5-hour/weekly buckets. The nils come from the legacy per-model quota path, whose model payload carries a reset timestamp but no cadence. Inferring a full period from time remaining would invent data.

I would split this before patching:

1. Decide whether CLI pace should become descriptor-driven and window-slot agnostic.
2. Land Kimi weekly duration + capability as the evidence-backed case.
3. Handle z.ai monthly pace only after confirming the intended calendar-month representation.
4. Require a redacted Grok web period fixture and Antigravity legacy cadence evidence before assigning durations on those paths.

That avoids a broad patch which either still produces no pace object or reports a plausible but incorrect forecast.

[steipete]

Status: the Kimi slice of this report landed via #2433 (weekly + API-derived window durations now flow into pace/forecast). The remaining providers stay open by design: z.ai deliberately suppresses TIME_LIMIT duration (one-minute marker means monthly), Grok web only exposes a reset time, and Antigravity legacy model quotas lack cadence — each needs a cadence-contract decision before wiring durations. Separately, CLI PaceKind.supports still predates the #2364 descriptor-driven capability move; that's a candidate refactor. Keeping this open for those parts.

[clawsweeper]

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

Summary
This remains necessary as an umbrella for the provider-specific cadence work not solved by the merged Kimi slice. The owner explicitly kept z.ai, Grok, and Antigravity open because their remaining paths need reliable cadence contracts rather than inferred durations, while the CLI capability follow-up is being addressed separately by an open PR.

Reproducibility: no. single high-confidence reproduction covers all remaining providers. The discussion and merged Kimi work establish the source path, but reliable validation for z.ai, Grok web, and Antigravity needs provider-specific cadence fixtures or contracts.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Include the exact command, prompt, or workflow that triggered it.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
For z.ai, Grok web, and Antigravity legacy quotas, should CodexBar add provider-specific calendar or plan cadence contracts, or continue to omit pace until each upstream source exposes verifiable duration data?	Require verified cadence contracts: Add duration and pace support only where provider documentation or redacted fixtures establish the actual quota cadence; retain gauge-only rendering otherwise.

Why: The remaining behavior is not a mechanical nil fill: choosing inferred monthly, weekly, or session durations determines whether users receive potentially misleading pace and forecast estimates.

Next step
A maintainer must choose the cadence policy for provider responses that lack reliable duration metadata; the existing open CLI PR can be reviewed independently.

Review details

Best possible solution:

Define and test an explicit cadence contract for each remaining provider path, preserving gauge-only output when cadence is unknown; then use the same descriptor rules in menu and CLI rendering.

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

No single high-confidence reproduction covers all remaining providers. The discussion and merged Kimi work establish the source path, but reliable validation for z.ai, Grok web, and Antigravity needs provider-specific cadence fixtures or contracts.

Is this the best way to solve the issue?

No; assigning a common duration to every missing field would be unsafe. The maintainable solution is per-provider, evidence-backed cadence support with fail-closed behavior for unknown windows.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Treating z.ai's one-minute marker as a literal pace duration would misrepresent a calendar-month quota.
• Assigning Grok web or Antigravity legacy windows a duration from only a reset timestamp could show a plausible but incorrect pace or forecast.
• The open CLI work at Use descriptor pace rules in CLI #2489 improves renderer capability selection but does not decide the missing provider cadence contracts.

Codex review notes: model internal, reasoning high; reviewed against 8ef86077e70a.

Label changes

Label changes:

• add P2: The missing pacing information affects several existing provider displays but does not prevent quota gauges or core application use.
• add impact:other: The report concerns missing provider usage-forecast capability rather than a supported auth, message, session, crash, or data-loss category.
• 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.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The missing pacing information affects several existing provider displays but does not prevent quota gauges or core application use.
• impact:other: The report concerns missing provider usage-forecast capability rather than a supported auth, message, session, crash, or data-loss category.

Evidence reviewed

What I checked:

• Maintainer scope decision: The repository owner states that the Kimi slice landed, while z.ai, Grok, and Antigravity remain intentionally open because their paths require cadence-contract decisions before durations are wired into pace. (02b4ba278c81)
• Merged Kimi implementation: The merged Kimi fix supplies a seven-day weekly duration and API-derived rate-limit durations, while deliberately leaving calendar-month and unknown cadence windows without pace metadata. (02b4ba278c81)
• Separate open CLI follow-up: The open CLI follow-up moves CLI pace output toward descriptor-driven rules and adds tertiary output, but it does not establish cadence for the remaining z.ai, Grok, or Antigravity data paths. (f2ada4a04abe)
• Provider-specific uncertainty: The issue discussion distinguishes safe Kimi metadata from z.ai's one-minute monthly marker, Grok web data with only a reset timestamp, and Antigravity legacy quotas without cadence; these cannot safely share a generic duration fallback.

Likely related people:

• steipete: Authored the descriptor-driven pace refactor and the session-equivalent forecast work, and made the current scope decision for the remaining provider paths. (role: feature owner and recent area contributor; confidence: high; commits: cc8da27cec92, 1f422d579437)
• kiranmagic7: Traced the original capability and cadence gates in the discussion and is authoring the open descriptor-driven CLI pace follow-up. (role: current follow-up contributor; confidence: medium; commits: f2ada4a04abe)
• harjothkhara: Authored the merged Kimi metadata fix that established the fail-closed approach for known versus unknown cadence. (role: implemented related provider slice; confidence: medium; commits: 02b4ba278c81)

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.