fix(session): clamp token usage counts

[pascalandr]

Issue for this PR

Closes #15293

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Provider usage payloads can report cache read/write tokens larger than the normalized input token count. Session.getUsage() subtracted those values directly, which could persist negative tokens.input values and produce misleading analytics/cost data. This clamps raw and derived token counters to zero while preserving cache read/write accounting.

How did you verify your code works?

• bun test test/session/compaction.test.ts -t "SessionNs.getUsage"
• bun typecheck from packages/opencode
• pre-push bun turbo typecheck

Screenshots / recordings

N/A, non-UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

PR #24232: fix(session): honor noCacheTokens in usage accounting
#24232

This PR is related because it also deals with session token usage accounting. Since PR #24336 addresses issues with cache read/write tokens and negative input token counts in Session.getUsage(), it may be working on the same area of code as PR #24232. However, they appear to be addressing different aspects of token accounting (this one focuses on clamping negative values, while #24232 focuses on honoring the noCacheTokens flag).

The other PRs that appeared in results (#22077, #14743, etc.) are related to token accumulation and cache configuration but don't appear to be duplicates of this specific fix.

[pascalandr]

#24232 is related and touches the same Session.getUsage() accounting path, but it is not exactly the same scope:

• fix(session): honor noCacheTokens in usage accounting #24232 fixes the semantic accounting issue for providers that expose noCacheTokens / cachedInputTokens shapes and clamps the adjusted input fallback.
• This PR is the defensive guard for [BUG] Negative amount of tokens used in session #15293: token counters derived from provider data should never persist negative values, including adjusted input and adjusted output, even when a provider reports inconsistent usage details.

If #24232 merges first, I can rebase this and keep only the remaining defensive clamp behavior that is not covered there, or close this if maintainers consider #24232 sufficient.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.