Skip to content

Status: cap cached percentage for stale totals#32561

Open
zwright8 wants to merge 1 commit intoopenclaw:mainfrom
zwright8:codex/pr26712-status-stale-total-cap
Open

Status: cap cached percentage for stale totals#32561
zwright8 wants to merge 1 commit intoopenclaw:mainfrom
zwright8:codex/pr26712-status-stale-total-cap

Conversation

@zwright8
Copy link
Copy Markdown

@zwright8 zwright8 commented Mar 3, 2026

Summary

Validation

  • pnpm exec vitest run src/commands/status.format.test.ts

Context

This PR is one focused slice extracted from:

@openclaw-barnacle openclaw-barnacle bot added commands Command implementations size: XS labels Mar 3, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 3, 2026

Greptile Summary

This PR extracts a focused fix from #26712 that prevents the status formatter from displaying impossible cache hit rates (e.g. "1141% cached") when totalTokens is stale or misaligned relative to cacheRead. The change picks the largest of totalTokens, fallbackTotal, and cacheRead as the effective denominator and then caps the result at 100%, keeping the display sensible for users. It also incidentally fixes a latent divide-by-zero for totalTokens === 0. Two new Vitest cases cover both the happy path and the stale-total edge case.

Key changes:

  • effectiveTotal = Math.max(total, fallbackTotal, cacheRead) ensures the denominator is never smaller than cacheRead, preventing rates > 100%.
  • Math.min(100, ...) adds an explicit hard cap as a final safety net.
  • Added used > 0 guard so a zero totalTokens correctly falls back to fallbackTotal instead of producing Infinity.
  • New test file status.format.test.ts validates both the standard and stale-total cases.

Minor observation: A test for the totalTokens = null/undefined path would round out coverage, but the existing logic correctly handles it via the typeof used === "number" && used > 0 guard.

Confidence Score: 5/5

  • This PR is safe to merge — the change is narrowly scoped to display formatting logic with no side effects on data or state.
  • The logic is correct: effectiveTotal is always ≥ cacheRead > 0, so division is safe and the result is bounded to [0, 100]. The used > 0 addition also closes a pre-existing divide-by-zero for zero totalTokens. Both test cases pass the new code path, and the change does not touch any persistence, API, or state management code.
  • No files require special attention.

Last reviewed commit: 3a91d23

@zwright8 zwright8 force-pushed the codex/pr26712-status-stale-total-cap branch from 3a91d23 to cf7a963 Compare March 3, 2026 05:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

commands Command implementations size: XS

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant