Skip to content

Bug: Context token count always shows 0 after compaction #50795

@wuwahe3

Description

@wuwahe3

Issue: Context Token Count Always Shows 0 After Compaction

Summary

The 📚 Context counter in the TUI always displays 0/1.0m (0%) even after successful LLM responses. This happens because the clearStaleAssistantUsageOnSessionMessages() function incorrectly clears all assistant message usage data after any compaction, instead of only clearing usage for messages that existed before the compaction.

Root Cause Analysis

Problem Location

  • File: src/agents/pi-embedded-subscribe.handlers.compaction.ts
  • Function: clearStaleAssistantUsageOnSessionMessages()

Current (Broken) Implementation

function clearStaleAssistantUsageOnSessionMessages(ctx: EmbeddedPiSubscribeContext): void {
  const messages = ctx.params.session.messages;
  if (!Array.isArray(messages)) {
    return;
  }
  for (const message of messages) {
    if (!message || typeof message !== "object") {
      continue;
    }
    const candidate = message as { role?: unknown; usage?: unknown };
    if (candidate.role !== "assistant") {
      continue;
    }
    // BUG: This clears ALL assistant usage, not just stale data!
    candidate.usage = makeZeroUsageSnapshot();
  }
}

Why This Is Wrong

  1. This function is called after every compaction ends (that doesn't retry)
  2. It unconditionally zeros out all assistant message usage, including messages created after the compaction
  3. The newly created assistant messages have valid usage data from the LLM API, which should be preserved
  4. Only usage data from messages before the compaction should be cleared (they reflect the old, larger context)

Evidence

  1. ✅ Bailian API correctly returns usage data in streaming mode with stream_options.include_usage: true
  2. ✅ OpenAI SDK correctly parses the usage chunks
  3. ✅ pi-ai correctly stores usage in the assistant message
  4. ❌ OpenClaw clears all usage data in clearStaleAssistantUsageOnSessionMessages()

Related Correct Implementation

The file src/agents/pi-embedded-runner/google.ts contains a correct implementation: stripStaleAssistantUsageBeforeLatestCompaction() which only clears usage for messages older than the latest compaction.

Proposed Fix

function clearStaleAssistantUsageOnSessionMessages(ctx: EmbeddedPiSubscribeContext): void {
  const messages = ctx.params.session.messages;
  if (!Array.isArray(messages)) {
    return;
  }

  // Find the latest compaction summary to determine which usage entries are stale.
  let latestCompactionTimestamp: number | null = null;
  for (const entry of messages) {
    if (!entry || typeof entry !== "object") {
      continue;
    }
    const candidate = entry as { role?: unknown; timestamp?: unknown };
    if (candidate.role !== "compactionSummary") {
      continue;
    }
    const ts = parseMessageTimestamp(candidate.timestamp);
    if (ts !== null) {
      latestCompactionTimestamp = ts;
    }
  }

  // If no compaction occurred, don't clear any usage data.
  if (latestCompactionTimestamp === null) {
    return;
  }

  // Clear usage only for assistant messages older than the latest compaction.
  for (const message of messages) {
    if (!message || typeof message !== "object") {
      continue;
    }
    const candidate = message as { role?: unknown; usage?: unknown; timestamp?: unknown };
    if (candidate.role !== "assistant") {
      continue;
    }
    if (!candidate.usage || typeof candidate.usage !== "object") {
      continue;
    }
    const messageTimestamp = parseMessageTimestamp(candidate.timestamp);
    if (messageTimestamp === null || messageTimestamp > latestCompactionTimestamp) {
      // This message is newer than the compaction - keep its usage.
      continue;
    }
    // Clear stale usage that reflects pre-compaction context size.
    candidate.usage = makeZeroUsageSnapshot();
  }
}

function parseMessageTimestamp(value: unknown): number | null {
  if (typeof value === "number" && Number.isFinite(value)) {
    return value;
  }
  if (typeof value === "string") {
    const parsed = Date.parse(value);
    if (Number.isFinite(parsed)) {
      return parsed;
    }
  }
  return null;
}

Impact

  • Severity: Medium
  • User Impact: Users cannot see accurate context token usage, making it difficult to know when compaction will occur
  • Workaround: None (disabling auto-compaction is not a real solution)

Testing

  1. Run any LLM request with a model that returns usage data (e.g., OpenAI, Bailian/Qwen)
  2. Observe 📚 Context: 0/1.0m (0%) after the response
  3. Check transcript file - all usage objects show zeros

Labels

  • bug
  • context-usage
  • compaction

Pull Request: Fix context token count zeroed after compaction

Summary

Fixes the issue where 📚 Context token count always shows 0 after compaction.

Changes

  • Modified clearStaleAssistantUsageOnSessionMessages() in src/agents/pi-embedded-subscribe.handlers.compaction.ts
  • Now only clears usage for assistant messages older than the latest compaction
  • Added parseMessageTimestamp() helper function

Testing

  • Manual testing verified that usage data is now preserved for post-compaction messages
  • Context token count correctly reflects actual token usage

Related

  • Issue: Context Token Count Always Shows 0 After Compaction

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:data-lossCan lose, corrupt, or silently drop user/session/config data.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions