bogus 0 tokens -49442 toekn guard

[acoliver]

What happened?

[API Error: Client error: Unknown error (Status: 400)]

/dumpcontext now

ℹ Immediate request context dumped to 20260623-195633-codex-e1bt7l-request.jsonNo model request was sent, so no model response dump was created.Dump directory: /Users/acoliver/.llxprt/dumps

/profile load opusthinking

ℹ Profile 'opusthinking' loaded- Cleared custom base URL for provider 'anthropic'; default endpoint restored.- Use /key to set API key if needed.- API key removed for provider 'anthropic'- Base URL updated to 'https://api.anthropic.com' for provider 'anthropic'.- Model set to 'claude-opus-4-8' for provider 'anthropic'.

continue

Responding with: opusthinking
✓ ✓Shell cat > /tmp/corrupted_files.txt <<'EOF'
packages/cli/src/ui/components/SettingsDialog.test.tsx
packages/cli/src/u…
Shell cat > /tmp/corrupted_files.txt <<'EOF'
packages/cli/src/ui/components/SettingsDialog.test.tsx
packages/cli/src/ui/c…

 23 /tmp/corrupted_files.txt
 --- checking these were only changed in working tree (not committed) ---
  M packages/cli/src/commands/mcp/remove.test.ts
  M packages/cli/src/integration-tests/loadbalancer.integration.test.ts
  M packages/cli/src/integration-tests/todo-continuation.integration.test.ts
  M packages/cli/src/runtime/__tests__/runtimeIsolation.test.ts
  M packages/cli/src/services/todo-continuation/todoContinuationService.spec.ts
  M packages/cli/src/ui/commands/__tests__/formatSessionSection.spec.ts
  M packages/cli/src/ui/commands/__tests__/profileCommand.failover.test.ts
  M packages/cli/src/ui/commands/__tests__/profileCommand.lb.test.ts
  M packages/cli/src/ui/commands/profileCommand.test.ts
  M packages/cli/src/ui/commands/test/subagentCommand.test.ts
  M packages/cli/src/ui/components/Footer.responsive.test.tsx
  M packages/cli/src/ui/components/Footer.test.tsx
  M packages/cli/src/ui/components/ProviderDialog.responsive.test.tsx
  M packages/cli/src/ui/components/SettingsDialog.test.tsx
  M packages/cli/src/ui/components/TodoPanel.responsive.test.tsx
  M packages/cli/src/ui/components/TodoPanel.semantic.test.tsx
  M packages/cli/src/ui/components/__tests__/SessionBrowserDialog.spec.tsx
  M packages/cli/src/ui/components/shared/BaseSelectionList.test.tsx
  M packages/cli/src/ui/hooks/shellCommandProcessor.test.tsx
  M packages/cli/src/ui/hooks/useTodoContinuation.spec.ts
  M packages/cli/src/ui/utils/secureInputHandler.test.ts
  M packages/cli/src/utils/__tests__/formatRelativeTime.spec.ts
  M packages/cli/src/utils/sandbox-proxy-integration.test.ts

ℹ Sending this message (0 tokens) might exceed the remaining context window limit (-49442 tokens). Please try reducing the size of your message or use the /compress command to compress the chat history

Context: 249,442/200,000 tokens in the footer

(we were in gpt but it had an error so we switched to opus which then when told to continue made one tool call and hit the guard probably because the context length was recalcuated

What did you expect to happen?

it shouldn't shoot the context value up like that without a compress and I think tis miscalcuating the ocntext when switching. It might change but it wouln't like double or tripple the ocntext wasn't that fuull

Client information

About LLxprt Code

CLI Version 0.10.0-nightly.260623.8e8f21c92
Git Commit 8e8f21c
Model anthropic:claude-opus-4-8
Provider anthropic
Base URL https://api.anthropic.com
Sandbox no sandbox
OS darwin

Login information

No response

Anything else we need to know?

No response

[acoliver]

@CodeRabbit look into this

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• When switching from opus to gpt the context is miscalculated #1567

🔗 Related PRs

#1274 - fix(core): preserve history after failed compression [closed]
#1315 - fix: guard parallel tool batches against context window overflow [merged]
#1555 - fix(anthropic): prevent prefill 400 for thinking models on --continue (Fixes #1545) [merged]
#1621 - Fix compression errors on default Anthropic opus/sonnet config (Fixes #1566) [merged]
#2043 - Fix stale context limit after profile load (Fixes #2040) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 2139 --repo vybestack/llxprt-code --json title,body,state,labels,assignees,comments,author,createdAt,url

Length of output: 7451

---

🏁 Script executed:

#!/bin/bash
# Find the token guard / context window check logic
rg -n "remaining context window" --type ts -C 5 packages/

# Find where token counts are computed for messages
rg -n "tokens.*exceed\|exceed.*tokens\|context window limit" --type ts -C 5 packages/

# Find how /continue is handled and how outgoing message tokens are counted
rg -n "0 tokens\|outgoing.*token\|token.*outgoing\|message.*token.*count\|countToken" --type ts -C 3 packages/

Length of output: 4061

---

🏁 Script executed:

#!/bin/bash
# Read the full useStreamEventHandlers.ts to understand the flow
cat -n packages/cli/src/ui/hooks/geminiStream/useStreamEventHandlers.ts

# Find where "context window" guard / token limit checks are triggered (what calls onContextWindowLimit or similar)
rg -n "estimatedRequestTokenCount\|remainingTokenCount\|contextWindowLimit\|onContextWindow\|TOKEN_LIMIT\|tokenLimit" --type ts -C 3 packages/cli/src/

# Find how token counting is done for requests before sending
rg -n "countTokens\|count_tokens\|estimateTokens\|tokenCount\b" --type ts -C 3 packages/cli/src/

Length of output: 23694

---

🏁 Script executed:

#!/bin/bash
# Find where context_window_will_overflow / ContextWindowWillOverflow event is emitted
rg -n "contextWindowWillOverflow\|context_window_will_overflow\|ContextWindowWillOverflow\|CONTEXT_WINDOW" --type ts -C 5 packages/

# Find where estimatedRequestTokenCount is computed/passed
rg -n "estimatedRequestTokenCount\|estimatedTokenCount\|requestTokenCount" --type ts -C 5 packages/

# Look at the agentic loop for token counting logic
fd -t f "agenticLoop\|agentic.loop\|AgenticLoop" packages/ --exec cat -n {}

Length of output: 658

---

🏁 Script executed:

#!/bin/bash
# Try finding where the context overflow event is emitted with broader terms
rg -n "overflow\|willOverflow\|tokenCount\|token_count" --type ts -C 3 packages/ | head -200

# Find the agentic loop or similar files
fd -t f -e ts "loop\|Loop" packages/ | head -20

# Search for where the context guard check fires
rg -n "remainingToken\|remaining_token\|contextLimit\|context_limit\|getTokenLimit" --type ts -C 4 packages/ | head -200

Length of output: 581

---

🏁 Script executed:

#!/bin/bash
# Check what packages exist
ls packages/

# List files in core package
find packages/ -name "*.ts" | grep -v node_modules | grep -v ".test." | grep -v ".spec." | head -60

# Find token-related files
find packages/ -name "*.ts" | grep -v node_modules | xargs grep -l "tokenLimit\|token_limit\|contextWindow" 2>/dev/null | head -20

Length of output: 4537

---

🏁 Script executed:

#!/bin/bash
# Read the overflow test and the AgenticLoop to understand the token counting guard
cat -n packages/agents/src/core/agenticLoop/AgenticLoop.ts
echo "---"
cat -n packages/agents/src/core/agenticLoop/loopHelpers.ts
echo "---"
cat -n packages/core/src/core/tokenLimits.ts
echo "---"
# Read overflow-related client code
cat -n packages/agents/src/core/client.sendMessageStream-overflow.test.ts | head -100

Length of output: 38529

---

🏁 Script executed:

#!/bin/bash
# Look at the client sendMessageStream for overflow logic
cat -n packages/agents/src/core/client.sendMessageStream-overflow.test.ts | head -200
echo "==="
# Look at the main client.ts for sendMessageStream implementation
grep -n "sendMessageStream\|contextWindow\|overflow\|tokenCount\|remainingToken\|estimatedToken" packages/agents/src/core/client.ts | head -60
echo "==="
# Check the chatSession contextlimit test for hints
cat -n packages/agents/src/core/chatSession.contextlimit.test.ts | head -100
echo "==="
# Find where the ContextWindowWillOverflow event is emitted
grep -rn "ContextWindowWillOverflow\|contextWindowWillOverflow\|CONTEXT_WINDOW_WILL_OVERFLOW\|willOverflow" packages/ | head -30

Length of output: 16157

---

🏁 Script executed:

#!/bin/bash
# Read the critical section where ContextWindowWillOverflow is emitted
sed -n '240,340p' packages/agents/src/core/MessageStreamOrchestrator.ts
echo "==="
# Also read the broader context around it (token counting logic)
grep -n "tokenCount\|tokenLimit\|contextLimit\|getModel\|estimated\|remaining" packages/agents/src/core/MessageStreamOrchestrator.ts | head -40
echo "==="
# Now look at the client.ts sendMessageStream implementation around line 708
sed -n '690,820p' packages/agents/src/core/client.ts

Length of output: 6815

---

🏁 Script executed:

#!/bin/bash
# Find and read estimateTextOnlyLength
grep -rn "estimateTextOnlyLength" packages/ | head -10
echo "==="
grep -n "getLastPromptTokenCount\|lastPromptTokenCount\|setLastPromptTokenCount" packages/agents/src/core/chatSession.ts | head -20
echo "==="
# Check the PR `#2043` fix details to understand what it changed
grep -rn "getLastPromptTokenCount\|lastPromptTokenCount" packages/ | grep -v ".test." | grep -v ".spec." | head -30
echo "==="
# See what estimateTextOnlyLength does
fd "estimateTextOnly\|textLength" packages/ --exec grep -n "estimateTextOnly" {}

Length of output: 5154

---

🏁 Script executed:

#!/bin/bash
# Read estimateTextOnlyLength implementation
grep -n "estimateTextOnlyLength" packages/agents/src/core/clientHelpers.ts
echo "==="
sed -n '1,50p' packages/agents/src/core/clientHelpers.ts
echo "==="
# Also check what happens to lastPromptTokenCount when profile/provider changes
grep -n "lastPromptTokenCount\|null\|reset\|clear\|invalidat" packages/agents/src/compression/CompressionHandler.ts | grep -i "null\|reset\|clear\|invalidat" | head -20
echo "==="
# Check the clientHelpers test for estimateTextOnlyLength behavior with non-text parts
sed -n '114,180p' packages/agents/src/core/clientHelpers.test.ts

Length of output: 5485

---

🏁 Script executed:

#!/bin/bash
# Check what happens to lastPromptTokenCount on profile change / chat invalidation
grep -n "invalidateChatForProfileChange\|profileChangePending\|lastPromptTokenCount\|compressionHandler" packages/agents/src/core/client.ts | head -30
echo "==="
# Check if lastPromptTokenCount is reset when a new chat session is created
grep -n "CompressionHandler\|lastPromptTokenCount\|new Chat" packages/agents/src/core/chatSession.ts | head -20
echo "==="
# Read the invalidateChatForProfileChange method
grep -n "invalidateChat\|profileChange" packages/agents/src/core/client.ts | head -20
sed -n '550,620p' packages/agents/src/core/client.ts

Length of output: 4605

---

🏁 Script executed:

#!/bin/bash
# Read the invalidateChatForProfileChange method fully
sed -n '235,280p' packages/agents/src/core/client.ts
echo "==="
# Check startChat to see if it resets lastPromptTokenCount
grep -n "startChat\|lastPromptTokenCount" packages/agents/src/core/client.ts | head -20
sed -n '450,550p' packages/agents/src/core/client.ts

Length of output: 5602

---

---

@acoliver Here's a full analysis of issue #2139.

---

Root Cause Analysis

There are two overlapping bugs that combine to produce the confusing "0 tokens / -49442" guard message.

Bug 1 — estimateTextOnlyLength is blind to function-response parts

The overflow pre-check in MessageStreamOrchestrator.ts (lines 272–282) estimates the outgoing message size like this:

const estimatedRequestTokenCount = Math.floor(
  estimateTextOnlyLength(initialRequest) / 4,
);

estimateTextOnlyLength only sums text string content. It explicitly ignores functionCall, functionResponse, inlineData, and fileData parts (this is tested and intentional per the test file at packages/agents/src/core/clientHelpers.test.ts).

When the AgenticLoop feeds back the tool response after the one successful tool call (cat > /tmp/corrupted_files.txt), initialRequest consists entirely of functionResponse parts — no text. So:

estimatedRequestTokenCount = Math.floor(0 / 4) = 0

Bug 2 — Context was already over the limit after the first Claude API call

On /profile load opusthinking:

• invalidateChatForProfileChange() discards the old ChatSession → new one starts with lastPromptTokenCount = null (treated as 0)
• The existing conversation history (from the GPT session) is restored via _storedHistoryService

When the AgenticLoop sends the first message to claude-opus-4-8, Claude's API responds with usage data showing 249,442 input tokens (accumulated history from the GPT session, re-counted by Anthropic's tokenizer — possibly also inflated by cacheReads + cacheWrites being summed in TurnProcessor.ts:619):

this.lastPromptTokenCount = promptTokens + cacheReads + cacheWrites; // = 249,442

Claude's limit for claude-opus-4-8 is 200,000. So immediately after the first successful tool call, lastPromptTokenCount is already 49,442 tokens over the limit.

Why the guard fires

const remainingTokenCount =
  getTokenLimitForConfiguredContext(modelForLimitCheck, config) -  // 200,000
  getChat().getLastPromptTokenCount();                              // 249,442
// remainingTokenCount = -49,442

// Guard condition:
// 0 > (-49,442 * 0.95) = -46,970  →  TRUE (0 > any negative)

The guard fires not because the new message is large (it's 0 tokens), but because the context is already over the limit. The message "Sending this message (0 tokens) might exceed the remaining context window limit (-49442 tokens)" is mathematically correct but deeply misleading — the problem is the history, not what is being sent now.

Why PR #2043 didn't fully cover this

PR #2043 fixed stale token limits after a profile load (using the old model's limit). This issue is different: the limit is correctly updated to 200k for Claude, but the token count from the first Claude API call legitimately shows 249,442 — because the GPT-session history, when processed by Claude's tokenizer, exceeds 200k tokens.

---

Summary of Issues

#	Problem	Location
1	estimateTextOnlyLength returns 0 for pure function-response messages, making the guard message claim "0 tokens" for every tool continuation	packages/agents/src/core/clientHelpers.ts
2	lastPromptTokenCount is set to promptTokens + cacheReads + cacheWrites — when switching providers, the cache-adjusted count from Claude can greatly exceed the actual live context window	packages/agents/src/core/TurnProcessor.ts line 619
3	Guard message is misleading when remainingTokenCount is already negative — it should say "context already exceeds the limit" rather than "sending this message might exceed"	packages/agents/src/core/MessageStreamOrchestrator.ts lines 279–290, packages/cli/src/ui/hooks/geminiStream/useStreamEventHandlers.ts line 449

---

Suggested Fixes

Fix 1 — Improve the guard message for already-exceeded context:

// In useContextOverflowHandler (useStreamEventHandlers.ts)
if (remainingTokenCount <= 0) {
  // Context is already over the limit — don't blame the new message
  text = `Your conversation history already exceeds the context window limit for ${config.getModel()} ` +
    `(current: ${Math.abs(remainingTokenCount) + limit} tokens, limit: ${limit} tokens). ` +
    `Please use the \`/compress\` command to reduce the context.`;
} else {
  text = `Sending this message (${estimatedRequestTokenCount} tokens) might exceed the remaining context window limit (${remainingTokenCount} tokens).`;
}

Fix 2 — Include function-response JSON in token estimation:

// In estimateTextOnlyLength (clientHelpers.ts) — add functionResponse JSON size
function estimatePartLength(part: Part): number {
  if ('text' in part && typeof part.text === 'string') return part.text.length;
  if ('functionResponse' in part && part.functionResponse)
    return JSON.stringify(part.functionResponse).length;
  return 0;
}

Fix 3 — Warn on provider switch when history would exceed new limit:

After invalidateChatForProfileChange() and before the first call, check if the restored history would likely overflow the new model's context window (using estimateTextOnlyLength on the history content) and proactively suggest /compress.