Agent Timeout Does Not Display Error in Web UI - UI Hangs Indefinitely

Fri, 10 Apr 2026 00:00:00 +0000

Symptom

When an LLM request exceeds the agent timeout threshold, the following behavior is observed:

Gateway logs show ConnectionAbortedError: [WinError 10053] indicating the client aborted the connection
Agent logs correctly log the timeout with decision=surface_error reason=timeout
Web UI continues to display a loading spinner indefinitely
No error message is presented to the user
User cannot retry without manually refreshing the page, losing conversation context

The user expects to see a timeout error message and have the ability to retry, but instead the UI becomes unresponsive.

Root Cause Analysis

The investigation reveals that the root cause is a race condition in error event propagation:

When the agent detects an LLM timeout, it correctly identifies the timeout condition and decides to surface an error (decision=surface_error reason=timeout)
However, the agent’s timeout mechanism terminates the connection (causing ConnectionAbortedError) before the WebSocket can send the final event containing the status: "timeout" information
The Web UI client never receives the final event because the connection has already been terminated, leaving it in an indeterminate state showing a perpetual loading spinner
The custom gateway (ai_router.py) functions correctly with retry logic, but cannot compensate for the agent aborting the connection prematurely

The core issue is that the error status is logged but not communicated to the UI before the connection teardown occurs.

Solution

To resolve this issue, ensure that the final event with error status is always sent to the Web UI before or during connection teardown when a timeout occurs:

Modify the agent timeout handler to ensure the final event is flushed to the WebSocket before the connection is terminated
Wrap the error propagation in a try-finally block that guarantees the final event is sent even when the connection is being aborted: try: # timeout handling logic finally: # Ensure final event is sent before connection abort await send_final_event(status=“timeout”, error=“Agent request timed out”) # Then safely abort the connection
Add a timeout buffer that allows the final event to be delivered before the connection is forcibly closed
Verify WebSocket closure order - the final event should be sent and acknowledged before ConnectionAbortedError is raised

Code Location

The fix should be implemented in the agent’s timeout handling logic where the connection abort occurs, ensuring proper event sequencing.

Prevention

To prevent this issue from recurring:

Implement event-before-abort pattern: Always send status events before terminating connections in any error scenario, not just timeouts
Add integration tests: Create tests that verify the UI receives proper error events when agents timeout, specifically checking for final event delivery
WebSocket health checks: Add monitoring to detect when the UI is stuck in a loading state and automatically trigger recovery
Timeout handler review: Audit all timeout and abort code paths to ensure consistent error event propagation
Client-side timeout handling: Add a client-side timeout fallback in the Web UI that detects when no events have been received for a configured period and displays an appropriate message

Additional Information

Affected deployment: Docker deployment on Ubuntu-based container with Windows 11 host
Frequency: Intermittent - occurs when LLM response exceeds the 60-second agent timeout threshold
Workaround: Refresh the page (loses conversation context)
Related components:
- Agent timeout handler
- WebSocket event dispatcher
- Web UI state management

Sources

GitHub Issue #64793

Token Usage Statistics Show as 0 for Local Providers (LM Studio)

Sun, 15 Mar 2026 00:00:00 +0000

Symptom

When using LM Studio (or other local LLM providers) with OpenClaw, the web interface shows 0 tokens for both lifetime and past 30-day usage statistics. This occurs even though:

The model is actively being used for inference
Token usage data is being returned in the API responses from the local provider
Curl requests to the provider confirm the usage field is present in responses

Example API Response from LM Studio: { “usage”: { “prompt_tokens”: X, “completion_tokens”: Y, “total_tokens”: Z } }

The token counts are available but not being displayed in OpenClaw’s statistics dashboard.

Root Cause Analysis

The root cause is that OpenClaw is not capturing or displaying token usage statistics for local providers. While cloud providers (OpenAI, Anthropic, etc.) have built-in support for tracking and displaying usage metrics, local providers like LM Studio appear to lack this integration.

Specifically:

LM Studio does expose token usage data via the standard usage field in API responses
The OpenClaw web interface is designed to show usage statistics from stored/aggregated data
Local provider responses may not be properly parsed, stored, or retrieved for display in the UI
The routing and display logic may be optimized for cloud providers and not account for local provider metadata

This is a feature gap in the local provider integration, not a crash or data corruption issue.

Solution

For Users (Workaround):

Manual tracking: Keep a separate log of token usage by monitoring API response payloads directly via curl or a proxy tool
Check provider dashboard: Some local providers like LM Studio may have their own usage tracking (verify in LM Studio’s interface)
Use logging: Enable detailed API logging in OpenClaw to capture raw responses and manually calculate usage

For Developers (Fix Required):

The fix involves modifying the OpenClaw codebase to:

Parse the usage field from local provider API responses
Store token usage data in the same manner as cloud providers
Ensure the usage data flows through to the web UI’s statistics components
Add LM Studio and other local providers to the supported usage tracking list

Relevant code areas to investigate:

Provider response parsing logic (likely in src/providers/)
Usage statistics storage and retrieval (likely in src/database/ or src/storage/)
Web UI statistics rendering (likely in src/web/components/usage-statistics/)

Prevention

When using local providers, be aware that OpenClaw’s built-in usage statistics may not reflect actual token consumption
Consider using provider-native monitoring tools alongside OpenClaw
When evaluating token efficiency with local models, rely on direct API response analysis rather than OpenClaw’s dashboard

Additional Information

Affected Provider: LM Studio (and likely other local LLM providers with similar API structures)
Tested Endpoint: http://localhost:1234/v1/chat/completions
Confirmed Working: LM Studio does return standard OpenAI-compatible usage data
Environment: Tested with model qwen/qwen3.5-35b-a3b on Ubuntu 22.04

This issue represents a missing feature rather than a defect—local providers expose the necessary data, but OpenClaw’s frontend does not consume and display it.

Sources

GitHub Issue #49890

Web-Ui on FixClaw

Agent Timeout Does Not Display Error in Web UI - UI Hangs Indefinitely

Symptom

Root Cause Analysis

Solution

Code Location

Prevention

Additional Information

Sources

Token Usage Statistics Show as 0 for Local Providers (LM Studio)

Symptom

Root Cause Analysis

Solution

For Users (Workaround):

For Developers (Fix Required):

Prevention

Additional Information

Sources