BoundaryML/baml · error · VmBamlError

LLM client error: {message}

Error message

LLM client error: {message}

What it means

This is the LlmClient variant of the VM error enum. It wraps any failure raised by the underlying LLM client layer — connection errors, HTTP failures from the model provider, client misconfiguration, streaming failures — after the prompt was rendered and dispatched. The VM surfaces it so callers can distinguish LLM-layer problems from prompt/VM-layer problems.

Source

Thrown at baml_language/crates/bex_vm_types/src/errors.rs:137

    #[error("I/O error: {message}")]
    Io { message: String },

    #[error("timeout: {message}")]
    Timeout {
        message: String,
        duration_ms: Option<i64>,
    },

    #[error("unsupported: {message}")]
    Unsupported { message: String },

    #[error("access error: {message}")]
    AccessError { message: String },

    #[error("render prompt: {message}")]
    RenderPrompt { message: String },

    #[error("LLM client error: {message}")]
    LlmClient { message: String },

    /// An error value from the host language that has no direct BAML
    /// representation. The `handle` is the load-bearing field — it
    /// references the original host exception object via the
    /// process-global host-value table, so the originating runtime can
    /// recover the exact native exception on round-trip. The
    /// `class_name` / `message` / `language` / `traceback` fields are
    /// purely metadata for debugging, logging, and user-facing
    /// formatting — they do not participate in error matching or
    /// rehydration.
    ///
    /// Surfaces in BAML as a `baml.errors.HostCallable` Instance whose
    /// `_handle` field is materialized from `handle`. Engine-side
    /// failures with no underlying host exception (bridge serialization
    /// faults, missing-bridge errors, etc.) MUST use a different
    /// variant — they are not host-language errors and have nothing to
    /// rehydrate. Such SDK/bridge faults route through fatal

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Verify the provider API key/credentials are present and valid for the configured client.
2. Check the provider status page and retry with backoff if it is an outage or rate limit.
3. Validate the client config (model name, base_url, provider options) against the provider's current API.
4. Enable BAML/provider logging to inspect the exact HTTP request and response that failed.

Example fix

// before
client<llm> Gpt4 {
  provider openai
  model gpt-4-0613 // deprecated/removed model
}
// after
client<llm> Gpt4 {
  provider openai
  model gpt-4o
  options { api_key env.OPENAI_API_KEY }
}

match vm_result {
    Err(BexError::LlmClient { message }) => {
        if is_transient(&message) { backoff_retry()?; }
    }
    other => other?,
}

When it happens

Trigger: Calling a BAML function whose provider call fails: invalid or missing API key, unreachable provider endpoint, provider returning a non-success status, timeouts, malformed client config (bad model name, bad base_url).

Common situations: Expired or rotated API keys; provider outages or rate limiting; wrong base_url for self-hosted/proxied endpoints; model name changes after provider deprecations.

Related errors

• timeout: {message}
• baml.fetch_as: HTTP request failed: HTTP {} Body: {} at {:?}
• Failed to fetch media: {e:?}
• Failed to fetch media bytes: {e:?}
• Failed to fetch media: {} {}, {}

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/3a5e3f5cde2da97a. Report an issue: GitHub.