fix(chutes): keep usage percent in 0..=100 units

[Finesssee]

Why

percent_from_object in rust/src/providers/chutes/mod.rs applied an ambiguous fraction heuristic: any value <= 1.0 found under the usage_percent / usagePercent / percent_used / percentUsed keys was rescaled by 100. A real whole 1% satisfied v <= 1.0 and became a false 100% exhausted state; a real 0.5% became 50%. This is the same bug class already fixed for the OpenCode Go API path in #407 (and #247 / upstream steipete#3216 before that).

Fixes #408.

Unit-contract evidence

• The Chutes OpenAPI spec (https://api.chutes.ai/openapi.json) defines GET /users/me/subscription_usage but leaves its 200 response schema empty ({}); no schema in components/schemas contains a percent-named field. The official docs (https://chutes.ai/docs/api-reference/users, https://chutes.ai/llms-full.txt) likewise document no percent field for any usage/quota endpoint.
• The best available redacted live payload (Use new quota API endpoint sigmanor/vscode-chutes-quota#5, 2026-04, corroborated by Chutes Support steipete/CodexBar#176) shows the documented shape carries only counts: "four_hour": {"usage": 0.86, "cap": 4.17, "remaining": 3.31, "reset_at": ...} (USD-denominated usage vs cap) — no percent keys at all.
• Conclusion: no Chutes field is documented as a 0..=1 fraction, so the whole-percentage interpretation is the best-supported contract. Because percent_from_object is reached via collect_windows, which recursively scans arbitrary nested JSON, the key list may fire on payloads the docs never mention; the comment at the parse site states this explicitly. Values are now clamped to 0..=100 instead of rescaled.

Scope

• rust/src/providers/chutes/mod.rs only: dropped the if v <= 1.0 { v * 100.0 } rescale in percent_from_object, replaced with v.clamp(0.0, 100.0) plus a unit-contract comment citing chutes: same ambiguous 0..=1 fraction rescale heuristic as #407 (real 1% becomes 100%) #408 / fix(opencodego): keep API percent in 0..=100 units #407 / [Bug] OpenCode Go: rolling 5-hour usage shows 100% / "Exhausted Weekly" when opencode.ai reports 1% #247 / upstream OpenCode Go: weekly usage shows 100% when the true value is 1% (fraction heuristic misreads whole-percent API values) steipete/CodexBar#3216. Kept the existing four-key scan unchanged.
• Added three regression tests in the existing mod tests: usage_percent of 1 stays 1, 0.5 stays 0.5, 100 stays 100 (nested inside a quota object, matching existing test style).
• No new dependencies, no cross-provider changes.

Tradeoffs

• Public evidence for the unit contract is indirect (empty response schema; redacted third-party payload; no official percent-field docs). If Chutes ever ships a genuinely fractional field under one of these keys, it will now be read as a whole percent and clamped — accepted, because the previous heuristic was strictly worse (false 100% on a real 1%) and matches the precedent set in fix(opencodego): keep API percent in 0..=100 units #407.

Blast Radius

• Single provider module; only the Chutes provider's percent extraction changes. The used/limit ratio fallback path is untouched. Other providers unaffected. No UI, tray, or shell changes; no schema/DTO changes.

Verification

• cargo test --manifest-path rust/Cargo.toml --lib providers::chutes — all 7 chutes tests pass, including the 3 new regression tests (test-first: they were committed failing, with 1 → 100 and 0.5 → 50 reproducing the bug before the fix).
• cargo clippy --manifest-path rust/Cargo.toml --all-targets -- -D warnings — exit 0, no warnings.
• cargo fmt --all applied; git diff --stat shows only rust/src/providers/chutes/mod.rs (+13/−3 across both commits).

Summary by CodeRabbit

• Bug Fixes
  • Corrected Chutes usage percentage handling so values are interpreted consistently on a 0–100 scale.
  • Usage percentages are now safely limited to the valid 0–100 range.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 9c36df24-dc0d-4106-a40d-09837858a495

📥 Commits

Reviewing files that changed from the base of the PR and between ddaefd6 and 8da2d2d.

📒 Files selected for processing (1)

• rust/src/providers/chutes/mod.rs

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

Chutes usage parsing now treats provider values as percentages from 0..=100. The parser clamps values to that range without fraction conversion. Tests verify values 1, 0.5, and 100.

Changes

Chutes usage reporting

Layer / File(s)	Summary
Percentage parsing and regression coverage rust/src/providers/chutes/mod.rs	percent_from_object now clamps percentage values directly to 0..=100. Tests verify that 1, 0.5, and 100 remain unchanged.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 8da2d

The change corrects Chutes usage percentages so values such as 1% and 0.5% are no longer overstated, while preserving the existing bounded 0–100% behavior. No actionable merge-blocking risk remains beyond normal checks and review.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: preserving Chutes usage percentages in 0..=100 units.
Linked Issues check	✅ Passed	The pull request satisfies issue #408 by removing fraction rescaling, clamping values to 0..=100, and adding regression tests for 1, 0.5, and 100. The whole-percent contract is applied consistently.
Out of Scope Changes check	✅ Passed	The changes are limited to the Chutes provider parsing logic and related regression tests. No unrelated providers, dependencies, or other scope changes are included.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 1 files.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/chutes-percent-units

---

_{Comment @coderabbitai help to get the list of available commands.}

[Finesssee]

Verdict

Approve. The change deletes an ambiguous heuristic instead of rearranging complexity — the right shape for a unit-contract bug.

Structural

Removed the if v <= 1.0 { v * 100.0 } rescale in percent_from_object. Under that rule a real whole 1% was indistinguishable from a 1.0 fraction and was rescaled into a false 100% exhausted state; a real 0.5% became 50%. Replaced with an explicit clamp(0.0, 100.0) unit contract and a parse-site comment citing #408 / #407 / #247 / upstream steipete#3216. Direct, boring, correct.

No spaghetti growth

One file, +34/−3 across the two commits. The let Some(v) = ... else { continue } shape is cleaner than the old early-return-in-loop form, and the key list, fallback ratio path, and all sibling functions are untouched.

Test discipline

Three regression tests were committed first and observed failing (1 → 100 and 0.5 → 50 reproduced the bug before the fix), then pass after — proper test-first sequencing. All 7 chutes tests pass on the head commit.

Evidence honesty

The PR body states plainly that the Chutes docs are silent on percent fields (empty response schema in the OpenAPI spec; the documented payload carries only counts) and names the residual risk if a genuine fraction field ever appears. That is the right call — the previous heuristic was strictly worse regardless.

Reviewer verification

Focused suite cargo test --manifest-path rust/Cargo.toml --lib providers::chutes passes 7/7 on the head commit; diff read in full.

Note: a formal GitHub "Approve" review is not possible here — the review identity is the PR author (Finesssee), and GitHub rejects self-approval. This comment carries the review content in its place.