How do I see errors and exceptions for calls to the OpenAI API?

Rius records a call that OpenAI rejects, such as a 404 for an unknown model, a 429 or a timeout, as an ERROR span with error.type naming the error class, for example openai.NotFoundError. The OpenAI integration does this for you once init() runs. You find the failure as a failed trace on the Traces page, and the span’s detail panel leads with the exception and traceback. Wrap the call in observe when you want the failed call to sit inside your agent’s run.

How it works

The OpenAI integration instruments the client library for the whole process, so every call from anywhere in your code is traced without changes to your call sites. Each chat completion becomes a span for the model call, with the model, token usage and input and output messages.

When OpenAI rejects a call, that span is marked ERROR and carries error.type. In TypeScript this needs @arizeai/openinference-instrumentation-openai 4.4.1 or newer, which ends a rejected call’s span itself. @glassflow-ai/rius 1.1.0 and later require that version as their peer, so an older one gets a peer dependency warning.

Trace status comes from the spans, not from your agent. A trace is failed when at least one span carries an OpenTelemetry ERROR status, normally a recorded exception. This is why one rejected OpenAI call is enough to flag the whole trace.

What needs your own span: the integration records the model call, not the function that wraps it. A call made with no span around it appears as a standalone trace. Wrap the calling function in observe and the model call nests inside your agent’s run, so the failure shows in context. For the wider picture of watching agents, see Monitor AI agents in production.

Set it up

1. Install the instrumentation and initialize Rius once at startup. The extra installs the instrumentation, not openai itself. In TypeScript, install @arizeai/openinference-instrumentation-openai instead and call init() before you create the client. The integration page has the full setup.

pip install "glassflow-rius[openai]" openai

2. Initialize and use the client exactly as before:

import rius
from openai import OpenAI
 
rius.init(api_key="ri_...", service_name="my-agent")
client = OpenAI()  # use the client exactly as before

3. Wrap the function that calls OpenAI in observe, so the call and its error nest inside your agent’s run. Replace answer and messages with your own names:

@rius.observe
def answer(messages):
    return client.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages,
    )

4. Trigger one failing call, for example with a model name that does not exist, and open Traces in the console. The row shows the failed status and a count of errored spans.

5. Open the trace. In the waterfall, failed spans are highlighted along the path from the root to the error. Select the span for the OpenAI call and read the exception and traceback at the top of the detail panel. The Raw tab shows error.type exactly as ingested.

To find errors across many runs, use the Traces page:

• On Traces, filter by the failed status.
• On the Spans tab, choose LLM in the All kinds menu and filter by status to list only failed model calls.
• Add a filter on the error.type field to narrow to one error class. Attribute filters match exact values only.
• Inside an open trace, press ]e and [e to jump to the next or previous failed span.

What you get

• A failed trace for every run that contains a rejected OpenAI call, with the error count on the trace row.
• An ERROR span for each rejected call, with error.type naming the class such as openai.NotFoundError, and the exception and traceback leading the span detail.
• A recovered badge when your agent catches the error, retries or falls back, and the root span finishes without an error of its own. The errors are still counted, only the verdict changes.
• Retry chains collapsed into one row, such as fetch_article · 3 attempts · recovered, when back-to-back calls of the same step with the same input fail until the last one succeeds.
• The model, token counts and cost on the model-call span when the call reports usage. A call with no token usage shows a blank cost, not $0.
• A shareable view: Share on the trace list creates a read-only, frozen link to a filtered list. It carries summary tiles and metadata only, never span content.

When something else fits

If the failure happens in your own code between model calls rather than in the OpenAI call, add observe spans around those steps so they appear in the trace. If your calls go through another provider or framework, the integrations overview lists what each one captures.

Related