Investigate prompt caching differences between Claude Code and OpenHands

[neubig]

Summary

Reports suggest that Claude Code may be cheaper than OpenHands for the same query.

This appears to be reproducible by sending a simple "hi" query to both tools in two subsequent sessions.

• Reproduce the situation where sending the same prompts to OpenHands and Claude Code results in higher costs
• Diagnose the error and propose a fix

References

• Anthropic Prompt Caching Docs
• Research: Evaluation of Prompt Caching for Agentic Tasks
• Internal Slack report on Claude Code vs OpenHands caching disparity

[xingyaoww]

Anthropic prompt cache automatically invalidates after 5 minutes - https://platform.claude.com/docs/en/build-with-claude/prompt-caching#1-hour-cache-duration - which could increase the cost if users are not sending follow-up requests within 5 minutes.

We can possibly just enable this 1-hour-cache-duration flag by default to CLI, which might help with the cosyt in this case

I was wondering if we can include these as the first few telemetry we can include into our CLI (cc @malhotra5 ), eg tracking the time on average between two user messages.

If avg is > 5 minutes in general, we should set to 1 hr as the default cache TTL.

@OpenHands can you clone OpenHands/OpenHands-CLI and then check how we sent PostHog events as part of the "Critic feedback widget"? Then refactor this PostHog stuff to a shared util, and add a new settings knob in the UI settings that allows users to turn on/off PostHog metrics (We should not allow them to turn off PostHog if they have Critic model enabled - this is required).

Then, can you collect the number of CLI conversations (one event per conversation), each agent message event OR agent finish event (including metadata like when it is finished & the token status), as well as each user message event's metadata (when it is sent) and the LLM metrics right after it (so we can check for prompt cache hit rate).

When you are done, send a draft PR to OpenHands-CLI

[openhands-ai]

I'm on it! xingyaoww can track my progress at all-hands.dev

[openhands-ai]

Summary

I have successfully completed all the requested tasks for adding telemetry tracking to the OpenHands CLI. Here's a checklist of what was accomplished:

✅ Completed Tasks

1. Cloned OpenHands-CLI repository - Done

2. Explored PostHog implementation in Critic feedback widget - Analyzed the existing implementation in openhands_cli/tui/utils/critic/feedback.py

3. Refactored PostHog to shared utility - Created openhands_cli/shared/telemetry.py with:

   • Centralized TelemetryClient class with singleton pattern
   • Methods for tracking various events (conversation_start, user_message, llm_metrics, critic_inference, critic_feedback)
   • Respects user preferences via is_telemetry_enabled() check

4. Added settings knob for PostHog metrics toggle - Updated:

   • openhands_cli/stores/cli_settings.py - Added enable_telemetry setting
   • openhands_cli/tui/modals/settings/components/cli_settings_tab.py - Added "Enable Telemetry" switch that:
     • Cannot be disabled when Critic is enabled (telemetry is required for Critic)
     • Dynamically updates when Critic toggle changes

5. Implemented telemetry events:

   • conversation_start - One event per conversation with timestamp and agent model
   • user_message - Tracks when user sends messages (with timestamp and message index)
   • llm_metrics - Tracks LLM token usage and cache hit rates after each conversation run

6. Added comprehensive tests:

   • tests/shared/test_telemetry.py - 13 tests for TelemetryClient
   • tests/settings/test_cli_settings_tab.py - 5 tests for telemetry toggle behavior
   • Updated tests/tui/utils/critic/test_feedback.py - 10 tests updated to use new telemetry module

Files Changed (9 files, +1021/-155 lines)

• openhands_cli/shared/telemetry.py (new)
• openhands_cli/stores/cli_settings.py
• openhands_cli/tui/core/conversation_runner.py
• openhands_cli/tui/modals/settings/components/cli_settings_tab.py
• openhands_cli/tui/textual_app.py
• openhands_cli/tui/utils/critic/feedback.py
• tests/settings/test_cli_settings_tab.py (new)
• tests/shared/test_telemetry.py (new)
• tests/tui/utils/critic/test_feedback.py

Draft PR Created

PR #395: OpenHands/OpenHands-CLI#395

The telemetry will help track:

• Average time between user messages (to determine if 1-hour cache TTL should be default)
• Prompt cache hit rates across conversations
• Token usage patterns

This addresses the request from issue #1808 to add telemetry for investigating prompt caching differences between Claude Code and OpenHands CLI.

View full conversation

[xingyaoww]

Cache Hit Rate Analysis from Nightly Tests (Claude Sonnet 4.5)

I analyzed the cache behavior from the nightly test run for Claude Sonnet 4.5.

Overall Results

• Total prompt tokens: 305,487
• Cache read tokens: 222,512 (72.8% hit rate)
• Cache write tokens: 82,567

Per-Turn Cache Analysis

The cache hit rate follows a predictable pattern across all tests:

Turn	Typical Hit Rate	Explanation
1	0%	Cold start - must write system prompt to cache first
2	~48%	Only system prompt (~6.2K tokens) is cached
3	~65%	System prompt + Turn 1-2 content cached
4+	~73-85%	Progressively higher as conversation grows

Visual Example: t01_fix_simple_typo

Turn 1:  6,250 tokens │ [░░░░░░░░░░░░░░░░░░░░]   0.0% │ COLD START
Turn 2: 12,800 tokens │ [██████████░░░░░░░░░░]  48.7% │ sys prompt cached
Turn 3: 19,620 tokens │ [█████████████░░░░░░░]  65.1% │ prefix growing  
Turn 4: 27,020 tokens │ [██████████████░░░░░░]  72.5% │ good cache reuse

Why t06_github_pr_browsing Has Only 25.8% Cache Hit

This test shows the impact of dynamic external content:

Turn 1:  6,240 tokens (0% hit)   - Write system prompt to cache
Turn 2: 24,170 tokens (25.8% hit) - Fetched ~17K tokens of GitHub API JSON!

The 17K tokens of unique GitHub PR/comments data cannot be cached because it's never been seen before. This is expected behavior, not a bug.

Comparison with DeepSeek (91% hit rate)

DeepSeek achieves higher rates because:

• Automatic prefix caching without explicit cache_control markers
• Potentially shared cache across conversations with common prefixes
• Different TTL policies

SDK Implementation Review

The SDK's _apply_prompt_caching (llm.py:995-1009) is correctly implemented:

def _apply_prompt_caching(self, messages):
    # ✅ Mark system prompt as cacheable
    if len(messages) > 0 and messages[0].role == "system":
        messages[0].content[-1].cache_prompt = True
    
    # ✅ Mark last user/tool message as cacheable (continuation caching)
    for message in reversed(messages):
        if message.role in ("user", "tool"):
            message.content[-1].cache_prompt = True
            break

Root Causes of ~27% Cache Miss (Expected Behavior)

Cause	Impact
First-turn cold start	Every conversation must write system prompt before reading
New content per turn	Each turn adds observations/tool results that must be written first
Dynamic external content	API responses, web pages are unique and uncacheable
Test isolation	Each test is independent - no cross-conversation caching

Theoretical Maximum

For a conversation with ~6.2K system prompt and ~6.5K new content per turn:

• Turn 4: ~75% max
• Turn 8: ~87% max
• Asymptotic limit approaches but never reaches 100%

Conclusion

The 72.8% cache hit rate is expected and reasonable for Anthropic's prefix-based caching model. The SDK implementation is correct.

To investigate the Claude Code cost comparison mentioned in this issue, we'd need to:

1. Compare the exact same prompts/conversations
2. Check if Claude Code uses different caching strategies (e.g., more aggressive breakpoints)
3. Verify system prompt sizes are comparable

[xingyaoww]

Follow-up: Cross-Conversation Cache Behavior Test

I ran a simple test to verify if prompt caching works across separate conversation sessions.

Test Setup

• Model: claude-sonnet-4-5-20250929
• Simple 1-turn conversations with minimal tools
• Three separate Python process invocations

Results

Run	Question	Prompt Tokens	Cache Read	Cache Write	Hit Rate
#1	"What is 2+2?"	5,082	5,072	0	99.8%
#2	"What is 2+2?" (same)	5,082	5,072	0	99.8%
#3	"What is 10+10?" (different)	5,082	4,568	504	89.9%

Key Observations

✅ Cross-Conversation Caching Works!

The system prompt IS cached across separate Python process invocations. Run #1 already showed 99.8% cache hit because the system prompt was cached from a previous test attempt.

✅ Identical Prompts = Near-100% Cache Hit

When sending the exact same conversation (Run #1 and #2), we get near-100% cache hit rates.

⚠️ Different User Messages = Partial Cache Hit

Run #3 with a different question showed 89.9% hit rate:

• System prompt (~4.5K tokens) → cached and reused
• New user message (~500 tokens) → had to be written to cache

Why Nightly Tests Show Lower Cache Rates (72.8%)

The nightly integration tests show lower cache hit rates because:

1. Each test is isolated - Different task prompts for each test case
2. Dynamic external content - Tests fetch unique GitHub API data, web pages, etc.
3. No cross-test cache sharing - Tests don't run sequentially to benefit from shared prefixes

Real-World Implications

In actual usage scenarios, users should see much higher cache hit rates (~90%+) when:

• Using the same system prompt repeatedly
• Making multiple API calls within Anthropic's 5-minute cache TTL window
• Not fetching large amounts of unique external content

Conclusion

The SDK's caching implementation is working correctly. The 72.8% rate from nightly tests is expected given the test isolation. Real-world conversational usage should achieve significantly better cache utilization.

---

Test script used:

from openhands.sdk import LLM, Agent, Conversation, Tool
from openhands.tools.terminal import TerminalTool

llm = LLM(model="anthropic/claude-sonnet-4-5-20250929", caching_prompt=True)
agent = Agent(llm=llm, tools=[Tool(name=TerminalTool.name)])
conversation = Conversation(agent=agent, workspace=os.getcwd())
conversation.send_message("What is 2+2? Just answer with the number.")
conversation.run()

# Check metrics
print(f"Cache hit rate: {llm.metrics.accumulated_token_usage.cache_read_tokens / llm.metrics.accumulated_token_usage.prompt_tokens * 100:.1f}%")

[enyst]

@xingyaoww I don't understand this:

Dynamic external content | API responses, web pages are unique and uncacheable

This is browsing, and it rings a bell...: do we use the browsing condenser which removes previous observation from event history?

[neubig]

For reference, it looks like claude auto-caches the system prompt, but also does some additional stuff every session?