fix(conversation): count tokens from length-truncated responses

[liuhao1024]

What does this PR do?

Fixes token accounting for length-truncated responses. When finish_reason == "length" triggers a continuation retry, the tokens consumed by the truncated API call were never tracked — causing underreported usage in /insights and the session DB.

Related Issue

Fixes #38458

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/conversation_loop.py: Track token usage (prompt, completion, total, cache, reasoning) and estimated cost from the truncated response in the restart_with_length_continuation handler, before boosting the output cap and continuing the loop.
• tests/run_agent/test_run_agent.py: Add test_length_continuation_counts_truncated_tokens — verifies that both the truncated and continuation response tokens are counted in session totals.

How to Test

1. Ask the model to produce a response that exceeds max_output_tokens (triggers finish_reason="length")
2. After the continuation retry completes, check /insights — token counts should include both the truncated and continuation calls
3. Run pytest tests/run_agent/test_run_agent.py::TestRunConversation::test_length_continuation_counts_truncated_tokens -xvs

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Code Intelligence

• Analyzed: agent/conversation_loop.py:run_conversation — the restart_with_length_continuation handler (line ~3514)
• Callers: AIAgent.run_conversation() → called by CLI, gateway, batch_runner, cron
• Blast radius: LOW — only affects token accounting in the length-continuation path; no behavioral change to the retry/continuation logic itself
• Related patterns: existing token tracking at line ~1879 (normal path) and line ~1712 (thinking-exhausted path); this fills the gap in the third early-exit path

[teknium1]

Thanks for identifying the continuation-accounting gap. The premise remains valid on current main: a truncated text response sets _retry.restart_with_length_continuation at agent/conversation_loop.py:1948, and the outer handler continues at agent/conversation_loop.py:4227-4242 before normal accounting runs.

Problems

• The patch predates the current accounting pipeline. Current normal-response processing at agent/conversation_loop.py:2059-2247 normalizes usage, updates the context engine, accumulates all session buckets, prices usage, and writes a per-call SessionDB delta. The proposed inline counter update at the old handler site would not preserve that full contract.
• The added test verifies only in-memory aggregates, not the claimed SessionDB//insights result.

Suggested changes

• Rework the salvage around the current continuation handler to reuse/extract the canonical accounting path.
• Add a temp-SessionDB regression covering truncated plus continuation usage and persisted accounting.

Automated hermes-sweeper review.

[teknium1]

Current main's normal accounting also updates the context engine and writes a per-call SessionDB delta (agent/conversation_loop.py:2059-2247). Please salvage this through that canonical pipeline rather than maintaining a reduced parallel counter/cost update here.