OpenClaw Bug Report: Session-Level Cost Estimation Inflated ~9x for MiMo Provider

Summary

OpenClaw's session-level estimatedCostUsd is ~9x higher than the actual API cost for runs using the mimo provider. Per-turn costs in the transcript are correct, but the session aggregate is wrong.

Environment

• OpenClaw version: 2026.5.18 (gateway app)
• OS: Ubuntu 22.04 (Linux 6.8.0-110-generic)
• Provider: mimo (Xiaomi MiMo V2.5 Pro)
• Model: mimo/mimo-v2.5-pro

Repro Steps

1. Configure an agent with model mimo/mimo-v2.5-pro and provider mimo
2. Ensure openclaw.json has explicit cost rates:

   {
     "input": 0.435,
     "output": 0.87,
     "cacheRead": 0.0036,
     "cacheWrite": 0.435
   }

3. Run a multi-turn session (e.g., 60+ API calls with tool use)
4. Check sessions.json for estimatedCostUsd
5. Compare with manual calculation from per-turn usage in transcript

Evidence

Session store values

inputTokens:    295,353
outputTokens:    72,626
cacheRead:      102,272
cacheWrite:           0
estimatedCostUsd:  1.34

Manual calculation (configured rates)

Fresh input:  193,081 × $0.435/M  = $0.0840
Cache read:   102,272 × $0.0036/M = $0.0004
Output:        72,626 × $0.87/M   = $0.0632
─────────────────────────────────────────
Total:                               $0.1476

Per-turn costs from transcript (62 turns)

Sum of per-turn costs: $0.2065

Expected vs Actual

Root Cause Analysis

What works correctly

• Per-turn usage.cost objects in the transcript use correct rates (verified: 1636 input × $0.435/M = $0.000712 ✓)
• estimateUsageCost() in usage-format.ts calculates per-turn costs correctly
• External pricing sources (OpenRouter, LiteLLM) match config rates for mimo-v2.5-pro

What is broken

• persistSessionUsageUpdate() in agent-runner.runtime writes estimatedCostUsd to the session store
• The value stored is ~9x higher than both:
  1. Manual calculation from the same token counts + configured rates
  2. Sum of per-turn costs from the transcript

Suspected cause

The session-level cost aggregation path differs from the per-turn cost path. Possible issues:

1. params.usage passed to estimateSessionRunCostUsd() contains cumulative totals that are interpreted differently (e.g., input includes cache read in one path but not the other)
2. The cost lookup in resolveModelCostConfig() falls through to a different rate source for session aggregation vs per-turn calculation
3. inputTokens (295,353) in the session store does not match the usage.input passed to the cost function

Files to Inspect

• src/agents/usage.ts — normalizeUsage() (lines 45-65): Check if input subtraction logic differs between paths
• src/agents/usage-format.ts — estimateUsageCost(): Verify rates used
• src/agents/agent-runner.ts — persistSessionUsageUpdate() (line ~3040): Check params.usage contents
• src/agents/agent-runner.ts — estimateSessionRunCostUsd() (line ~3033): Check cost config resolution

Impact

• Cost tracking for mimo provider is unreliable
• Evaluators cannot trust estimatedCostUsd for budget tracking
• Affects any agent using mimo provider with multi-turn sessions

Suggested Fix

1. Add debug logging to estimateSessionRunCostUsd() to dump the usage object and resolved cost config
2. Ensure session-level cost uses the same usage normalization and rate lookup as per-turn costs
3. Consider adding a cost reconciliation check: warn if session cost deviates >2x from sum of per-turn costs