Skip to main content
The SDK normalizes common provider errors into typed, provider‑agnostic exceptions so your application can handle them consistently across OpenAI, Anthropic, Groq, Google, and others. This guide explains when these errors occur and shows recommended handling patterns for both direct LLM usage and higher‑level agent/conversation flows.

Why typed exceptions?

LLM providers format errors differently (status codes, messages, exception classes). The SDK maps those into stable types so client apps don’t depend on provider‑specific details. Typical benefits:
  • One code path to handle auth, rate limits, timeouts, service issues, and bad requests
  • Clear behavior when conversation history exceeds the context window
  • Backward compatibility when you switch providers or SDK versions

Quick start: Using agents and conversations

Agent-driven conversations are the common entry point. Exceptions from the underlying LLM calls bubble up from conversation.run() and conversation.send_message(...) when a condenser is not configured.

Avoiding context‑window errors with a condenser

If a condenser is configured, the SDK emits a condensation request event instead of raising LLMContextWindowExceedError. The agent will summarize older history and continue.
See the dedicated guide: Context Condenser.

Handling errors with direct LLM calls

The same exceptions are raised from both LLM.completion() and LLM.responses() paths, so you can share handlers.

Example: Using .completion()

Example: Using .responses()

Exception reference

All exceptions live under openhands.sdk.llm.exceptions unless noted.
CategoryErrorDescription
Provider / transport (provider-agnostic)LLMContextWindowExceedErrorConversation exceeds the model’s context window. Without a condenser, thrown for both Chat and Responses paths.
LLMAuthenticationErrorInvalid or missing credentials (401/403 patterns).
LLMRateLimitErrorProvider rate limit exceeded.
LLMTimeoutErrorSDK or lower-level timeout while waiting for the provider.
LLMServiceUnavailableErrorTemporary connectivity or service outage (e.g., 5xx responses, connection issues).
LLMBadRequestErrorClient-side request issues (invalid parameters, malformed input).
Response parsing / validationLLMMalformedActionErrorModel returned a malformed action.
LLMNoActionErrorModel did not return an action when one was expected.
LLMResponseErrorCould not extract an action from the response.
FunctionCallConversionErrorFailed converting tool/function call payloads.
FunctionCallValidationErrorTool/function call arguments failed validation.
FunctionCallNotExistsErrorModel referenced an unknown tool or function.
LLMNoResponseErrorProvider returned an empty or invalid response (rare; observed with some Gemini models).
CancellationUserCancelledErrorA user explicitly aborted the operation.
OperationCancelledA running operation was cancelled programmatically.
All of the above (except the explicit cancellation types) inherit from LLMError, so you can implement a catch‑all for unexpected SDK LLM errors while still keeping fine‑grained handlers for the most common cases.