Usage API timeout too short for WSL2 (5s hardcoded, response takes ~5.3s)

[sh4i-yurei]

Summary

The fetchUsageApi timeout is hardcoded to 5000ms (src/usage-api.ts:399). On WSL2, Node.js https.request to api.anthropic.com/api/oauth/usage consistently takes ~5.2–5.3s due to WSL2 network stack latency (DNS resolution + NAT traversal through the Windows host). The request completes successfully with a 10s timeout — it's not a network failure, just marginal latency exceeding the tight default.

Steps to Reproduce

1. Run Claude Code inside WSL2 (Ubuntu)
2. Enable showUsage: true in HUD config
3. Observe Usage: ⚠ (timeout) in the HUD status line
4. Check ~/.claude/plugins/claude-hud/.usage-cache.json — shows "apiError": "timeout"

Expected Behavior

Usage bar displays utilization percentages, e.g. 65% (31m / 5h) | 6% (67h / 7d)

Actual Behavior

Usage permanently shows ⚠ (timeout). The failure caches for 15s (CACHE_FAILURE_TTL_MS), then retries and times out again in a loop. Usage data is never displayed.

Environment

• OS: WSL2 — Ubuntu 24.04 on Windows 11 (kernel 6.6.87.2-microsoft-standard-WSL2)
• Node/Bun version: Node v24.11.0
• Claude Code version: v2.1.51
• claude-hud version: 0.0.7

Logs or Screenshots

Diagnostic test — Node.js https.request to the same endpoint with a 10s timeout:

Status: 200 Time: 5279 ms
Body: {"five_hour":{"utilization":65.0,"resets_at":"2026-02-24T07:00:00..."}, ...}

The request succeeds at 5279ms — just 279ms over the 5000ms limit. Python urllib with 10s timeout succeeds consistently. Bumping the hardcoded timeout from 5000 to 10000ms in dist/usage-api.js fixes the issue completely.

Cached failure result:

{
  "data": {
    "planName": "Max",
    "fiveHour": null,
    "sevenDay": null,
    "apiUnavailable": true,
    "apiError": "timeout"
  }
}

Suggested Fix

Either:

1. Bump the default timeout to 10s — since results cache for 60s, the extra 5s on first fetch has negligible UX impact
2. Make the timeout configurable via config.json (e.g., usageApiTimeoutMs) so users in high-latency environments can tune it

Option 1 is simpler and sufficient. WSL2 is a common dev environment and the current 5s default is too tight for it.

Related

• fix: use curl for usage API to bypass Cloudflare TLS blocking #143 — also about usage API failures, but different root cause (Cloudflare TLS fingerprint blocking vs. WSL2 network latency)