Models

Every Agent ultimately calls an LLM. The SDK abstracts models behind two lightweight interfaces:

Model – knows how to make one request against a specific API.
ModelProvider – resolves human‑readable model names (e.g. 'gpt-5.6-sol') to Model instances.

In day‑to‑day work you normally only interact with model names and occasionally ModelSettings.

import { Agent } from '@openai/agents';

const agent = new Agent({
  name: 'Creative writer',
  model: 'gpt-5.6-sol',
});

Choosing models

Default model

When you don’t specify a model when initializing an Agent, the default model will be used. The default is currently gpt-5.4-mini with reasoning.effort: "none" and text.verbosity: "low" for a balance of quality and latency.

If you want to switch to another model like gpt-5.6-sol, there are two ways to configure your agents.

First, if you want to consistently use a specific model for all agents that do not set a custom model, set the OPENAI_DEFAULT_MODEL environment variable before running your agents.

export OPENAI_DEFAULT_MODEL=gpt-5.6-sol
node my-awesome-agent.js

Second, you can set a default model for a Runner instance. If you don’t set a model for an agent, this Runner’s default model will be used.

import { Runner } from '@openai/agents';

const runner = new Runner({ model: 'gpt‑4.1-mini' });

GPT-5.x models

When you use any GPT-5.x model such as gpt-5.6-sol in this way, the SDK applies default modelSettings. It sets the ones that work the best for most use cases. To adjust the reasoning effort for the default model, pass your own modelSettings:

import { Agent } from '@openai/agents';

const myAgent = new Agent({
  name: 'My Agent',
  instructions: "You're a helpful agent.",
  // If OPENAI_DEFAULT_MODEL=gpt-5.6-sol is set, passing only modelSettings works.
  // It's also fine to pass a GPT-5.x model name explicitly:
  model: 'gpt-5.6-sol',
  modelSettings: {
    reasoning: { effort: 'high' },
    text: { verbosity: 'low' },
  },
});

If latency matters, start with the default gpt-5.4-mini configuration or use reasoning.effort: "none" on another GPT-5.x model, then increase reasoning effort only if your task needs more deliberate reasoning.

Non-GPT-5 models

If you pass a non–GPT-5 model name without custom modelSettings, the SDK reverts to generic modelSettings compatible with any model.

OpenAI provider configuration

The OpenAI provider

The default ModelProvider resolves names using the OpenAI APIs. It supports two distinct endpoints:

API	Usage	Call `setOpenAIAPI()`
Chat Completions	Standard chat & function calls	`setOpenAIAPI('chat_completions')`
Responses	New streaming‑first generative API (tool calls, flexible outputs)	`setOpenAIAPI('responses')` (default)

Authentication

import { setDefaultOpenAIKey } from '@openai/agents';

setDefaultOpenAIKey(process.env.OPENAI_API_KEY!); // sk-...

You can also plug your own OpenAI client via setDefaultOpenAIClient(client) if you need custom networking settings.

Provider options reference

When you instantiate OpenAIProvider directly, these options control client construction, endpoint selection, and feature validation:

Option	Purpose
`apiKey`	API key used when the provider creates its own OpenAI client. Defaults to the SDK-wide OpenAI key.
`baseURL`	HTTP base URL for OpenAI-compatible endpoints. Cannot be combined with `openAIClient`.
`websocketBaseURL`	WebSocket base URL for Responses WebSocket transport. Cannot be combined with `openAIClient`.
`openAIClient`	Preconfigured OpenAI client instance. Cannot be combined with `apiKey`, `baseURL`, or `websocketBaseURL`.
`organization` / `project`	Organization and project values passed when the provider creates its own OpenAI client.
`useResponses`	Select the Responses API (`true`) or Chat Completions API (`false`) for string model names resolved by this provider. Defaults to the process-wide `setOpenAIAPI(...)` setting.
`useResponsesWebSocket`	Use the WebSocket transport for Responses models resolved by this provider. Defaults to the process-wide `setOpenAIResponsesTransport(...)` setting.
`cacheResponsesWebSocketModels`	Reuse websocket-backed Responses model wrappers for connection reuse. Defaults to `true`; call `provider.close()` during shutdown to close cached wrappers.
`responsesWebSocketOptions`	Advanced options forwarded to websocket-backed Responses model wrappers.
`strictFeatureValidation`	For Chat Completions models, raise `UserError` for Responses-only features such as `previousResponseId`, `conversationId`, and `prompt`. By default those features are warned and ignored.

Responses WebSocket transport

When you use the OpenAI provider with the Responses API, you can send requests over a WebSocket transport instead of the default HTTP transport.

Enable it globally with setOpenAIResponsesTransport('websocket'), or enable it per provider with new OpenAIProvider({ useResponses: true, useResponsesWebSocket: true }).

You do not need withResponsesWebSocketSession(...) or a custom OpenAIProvider just to use the WebSocket transport. If reconnecting for each run/request is acceptable, your existing run() / Runner.run() usage will continue to work after enabling setOpenAIResponsesTransport('websocket').

Transport selection follows model resolution:

setOpenAIResponsesTransport('websocket') only affects string model names that are later resolved through the OpenAI provider while using the Responses API.
If you pass a concrete Model instance to an Agent or Runner, that instance is used as-is. OpenAIResponsesWSModel stays on WebSocket, OpenAIResponsesModel stays on HTTP, and OpenAIChatCompletionsModel stays on Chat Completions.
If you provide your own modelProvider, that provider controls model resolution. Enable WebSocket there instead of relying on the global setter.
If you route through a proxy, gateway, or other OpenAI-compatible endpoint, the target must support the WebSocket /responses endpoint. You may also need to set websocketBaseURL explicitly.

Use withResponsesWebSocketSession(...) or a custom OpenAIProvider / Runner only when you want to optimize connection reuse and manage the websocket provider lifecycle more explicitly:

withResponsesWebSocketSession(...): convenient scoped lifecycle with automatic cleanup after the callback.
Custom OpenAIProvider / Runner: explicit lifecycle control (including shutdown cleanup) in your own app architecture.

Despite the name, withResponsesWebSocketSession(...) is a transport lifecycle helper and is unrelated to the memory Session interface described in the sessions guide.

If you use a websocket proxy or gateway, configure websocketBaseURL on OpenAIProvider or set OPENAI_WEBSOCKET_BASE_URL.

If you instantiate OpenAIProvider yourself, remember that websocket-backed Responses model wrappers are cached by default for connection reuse. Call await provider.close() during shutdown to release those cached connections. withResponsesWebSocketSession(...) exists largely to manage that lifecycle for you: it creates a websocket-enabled provider and runner, passes them to your callback, and always closes the provider afterward. Use providerOptions for the temporary provider and runnerConfig for callback-scoped runner defaults.

See examples/basic/stream-ws.ts for a full streaming + HITL example using the Responses WebSocket transport.

Responses-only deferred tool loading

toolSearchTool(), toolNamespace(), and function tools or hosted MCP tools that set deferLoading: true require the OpenAI Responses API. The Chat Completions provider rejects namespaced or deferred function tools, and the AI SDK adapter does not support deferred Responses tool-loading flows. Use a Responses model directly when you need tool search.

Tool search is supported only on GPT-5.6 Sol and newer model releases that support it in the Responses API.

When a run includes deferred tools, add toolSearchTool() to the same agent and keep modelSettings.toolChoice on 'auto'. The SDK does not let you force the built-in tool_search tool or a deferred function tool by name because the model needs to decide when to load those definitions. See the Tools guide and the official OpenAI tool search guide for the full setup.

Hosted Multi-agent (Experimental)

Install the provider package and OpenAI client as direct dependencies because the example imports both packages directly:

npm install @openai/agents-openai openai

Hosted Multi-agent lets GPT-5.6 models create and coordinate a tree of subagents through the Responses API. This differs from SDK handoffs and agents-as-tools: the application does not create local Agent objects for hosted subagents or schedule their work. The hosted root agent delegates work, the service coordinates the subagents, and /root synthesizes the final answer. See the official Multi-agent guide for the beta API behavior and supported models.

Configure the experimental model

Construct OpenAIHostedMultiAgentModel explicitly and pass it to an SDK Agent. Constructing the model is the opt-in; there is no separate enabled flag.

The experimental model uses a persistent Responses WebSocket. Local function outputs are injected into the active hosted response with response.inject, so keep the same model instance for the entire run and close it when it is no longer needed.

import OpenAI from 'openai';
import { Agent, run, tool } from '@openai/agents';
import {
  OpenAIHostedMultiAgentModel,
  getHostedAgentMetadata,
} from '@openai/agents-openai/experimental/hosted-multi-agent';
import { z } from 'zod';

const lookupProject = tool({
  name: 'lookup_project',
  description: 'Return details about a project.',
  parameters: z.object({ project: z.string() }),
  execute: async ({ project }, _context, details) => {
    const caller = getHostedAgentMetadata(details);
    console.log(`Tool called by ${caller?.agentName ?? 'unknown'}`);
    return { project, status: 'on track' };
  },
});

const model = new OpenAIHostedMultiAgentModel(new OpenAI(), 'gpt-5.6-sol', {
  maxConcurrentSubagents: 3,
});

try {
  const agent = new Agent({
    name: 'Hosted coordinator',
    model,
    tools: [lookupProject],
    instructions:
      'Delegate project research to hosted subagents, wait for them, and synthesize the result.',
  });

  const result = await run(agent, 'Compare projects alpha and beta.');
  console.log(result.finalOutput);
} finally {
  await model.close();
}

For streaming observability, including hosted collaboration records and subagent messages, see the complete example.

Omit maxConcurrentSubagents to keep the service default, currently three. A supplied value must be a positive integer.

Tool execution and attribution

Every hosted agent uses the request’s model and sees the same local tool definitions. When any hosted agent emits a normal function_call, the existing Agents SDK runner executes the application tool. The Responses API’s call ID is the routing token: the SDK injects the matching function_call_output into the active hosted response for the caller that requested it.

getHostedAgentMetadata(details) reads the hosted agent name from a tool callback’s third argument. This metadata is useful for logs and application authorization, but it does not control routing. Do not dispatch a function result by agent name; preserve and use the call ID.

Tool arguments arrive from the service over the WebSocket, and tool outputs are injected back into the active hosted response. Keep sensitive-data policy, tool authorization, and approval checks in the application. If a tool has side effects, make it idempotent by call ID so an interrupted continuation cannot repeat the effect.

Output and streaming behavior

Only the /root message whose phase is final_answer becomes ordinary assistant output and contributes to finalOutput. Function calls remain ordinary SDK tool calls so the runner can execute them, and stable Responses items such as reasoning and hosted tool calls keep their existing SDK representations. Subagent messages, root commentary, and hosted collaboration records stay on the active WebSocket response and are not added to SDK history.

Raw streaming events remain available through raw_model_stream_event, including hosted records and subagent messages. High-level item streaming keeps stable Responses items while filtering beta-only collaboration records, and high-level text streaming contains only the root final answer. This keeps RunState and session history provider-neutral while preserving the complete hosted event stream for observability.

Consume a streamed run through its terminal event. If the stream consumer stops early, the SDK closes the WebSocket and abandons the active hosted response; a later run starts a new hosted response instead of resuming the abandoned one.

Current limitations

The experimental SDK model supports Responses WebSocket transport only. The beta Responses API also supports hosted Multi-agent over HTTP, but OpenAIHostedMultiAgentModel keeps one WebSocket open so the SDK runner can inject each local function output into the active response before continuing.

Continuation state for an in-progress hosted response is held by the OpenAIHostedMultiAgentModel instance. The model can reconnect a closed WebSocket before injecting a pending function output, but approvals and interrupted tools must still be resumed with the same model instance and the same WebSocket transport headers and query. Recreating the model loses the continuation state. One model instance also supports only one active run at a time.

Transport failures are replay-safe only when the SDK knows the request frame was not sent. Once the server may have received the frame, the SDK marks the error as unsafe to replay and does not automatically repeat the hosted turn. See Model retries for the general retry policy.

Do not combine this model with SDK handoffs, reasoning.summary, or max_tool_calls; these combinations fail before the request is sent. Server-side compaction thresholds configured with modelSettings.contextManagement remain supported, while explicit calls to the Responses compaction endpoint are outside this model’s lifecycle. You can continue using SDK handoffs and agents-as-tools with the stable OpenAIResponsesModel.

Model behavior and prompts

ModelSettings

ModelSettings mirrors the OpenAI parameters but is provider‑agnostic.

Field	Type	Notes
`temperature`	`number`	Creativity vs. determinism.
`topP`	`number`	Nucleus sampling.
`frequencyPenalty`	`number`	Penalise repeated tokens.
`presencePenalty`	`number`	Encourage new tokens.
`toolChoice`	`'auto' \| 'required' \| 'none' \| string`	See forcing tool use. On OpenAI Responses, `toolChoice: 'computer'` forces the GA built-in computer tool when available.
`parallelToolCalls`	`boolean`	Allow parallel function calls where supported.
`truncation`	`'auto' \| 'disabled'`	Token truncation strategy.
`maxTokens`	`number`	Maximum tokens in the response.
`store`	`boolean`	Persist the response for retrieval / RAG workflows.
`promptCacheRetention`	`'in-memory' \| '24h' \| null`	Controls the legacy maximum prompt-cache retention policy when supported. This is independent of `promptCacheOptions.ttl`.
`promptCacheOptions`	`{ mode?: 'implicit' \| 'explicit'; ttl?: '30m' }`	Controls implicit or explicit prompt-cache breakpoints for GPT-5.6 and later models.
`contextManagement`	`ModelSettingsContextManagement`	Controls provider context management, such as server-side compaction.
`reasoning.effort`	`'none' \| 'minimal' \| 'low' \| 'medium' \| 'high' \| 'xhigh' \| 'max'`	Reasoning effort for supported gpt-5.x models. `max` is supported by GPT-5.6.
`reasoning.mode`	`'standard' \| 'pro' \| string`	Selects the reasoning execution mode. This setting requires the Responses API.
`reasoning.context`	`'auto' \| 'current_turn' \| 'all_turns' \| null`	Controls which reasoning items are rendered back to the model on later turns. This setting requires the Responses API.
`reasoning.summary`	`'auto' \| 'concise' \| 'detailed'`	Controls how much reasoning summary the model returns.
`text.verbosity`	`'low' \| 'medium' \| 'high'`	Text verbosity for gpt-5.x etc.
`providerData`	`Record<string, any>`	Provider-specific passthrough options forwarded to the underlying model.
`retry`	`ModelRetrySettings`	Runtime-only opt-in retry config. See Model retries.

Attach settings at either level:

import { Runner, Agent } from '@openai/agents';

const agent = new Agent({
  name: 'Creative writer',
  // ...
  modelSettings: { temperature: 0.7, toolChoice: 'auto' },
});

// or globally
new Runner({ modelSettings: { temperature: 0.3 } });

Runner‑level settings override conflicting per-agent settings. Nested fields in reasoning, text, promptCacheOptions, and retry are merged across runner and agent settings unless you explicitly clear an inherited value with undefined.

GPT-5.6 reasoning and prompt-cache controls

GPT-5.6 adds request-level reasoning modes and explicit prompt-cache breakpoints. reasoning.mode and reasoning.context are Responses-only settings. OpenAIChatCompletionsModel warns once and ignores them, or raises a UserError before the request when strict feature validation is enabled. reasoning.effort remains available on supported Chat Completions models.

promptCacheOptions is forwarded by both the Responses and Chat Completions model paths. The default implicit mode lets OpenAI choose an automatic breakpoint in addition to any explicit breakpoints. Set mode: 'explicit' to use only content parts marked with promptCacheBreakpoint: { mode: 'explicit' }. The currently supported minimum cache lifetime is 30m.

import { Agent, run } from '@openai/agents';

const agent = new Agent({
  name: 'Research assistant',
  model: 'gpt-5.6',
  modelSettings: {
    reasoning: {
      mode: 'pro',
      effort: 'max',
      context: 'all_turns',
    },
    promptCacheOptions: {
      mode: 'explicit',
      ttl: '30m',
    },
  },
});

await run(agent, [
  {
    role: 'user',
    content: [
      {
        type: 'input_text',
        text: 'Treat this research brief as a reusable prompt prefix.',
        promptCacheBreakpoint: { mode: 'explicit' },
      },
      {
        type: 'input_text',
        text: 'Summarize the brief and identify its main risks.',
      },
    ],
  },
]);

Explicit breakpoints are supported on GPT-5.6 and later models. The supported content-part types and breakpoint limits vary by API; see the official prompt cache breakpoint guide for current details.

Model retries

Retries are runtime-only and opt-in. The SDK does not retry model requests unless you configure modelSettings.retry and your policy returns a retry decision.

import { Agent, Runner, retryPolicies } from '@openai/agents';

const sharedRetry = {
  maxRetries: 4,
  backoff: {
    initialDelayMs: 500,
    maxDelayMs: 5_000,
    multiplier: 2,
    jitter: true,
  },
  policy: retryPolicies.any(
    retryPolicies.providerSuggested(),
    retryPolicies.retryAfter(),
    retryPolicies.networkError(),
    retryPolicies.httpStatus([408, 409, 429, 500, 502, 503, 504]),
  ),
};

const runner = new Runner({
  modelSettings: {
    retry: sharedRetry,
  },
});

const agent = new Agent({
  name: 'Assistant',
  instructions: 'You are a concise assistant.',
  modelSettings: {
    retry: {
      maxRetries: 2,
      backoff: {
        maxDelayMs: 2_000,
      },
    },
  },
});

await runner.run(agent, 'Summarize exponential backoff in plain English.');

ModelRetrySettings has three fields:

Field	Type	Notes
`maxRetries`	`number`	Number of retry attempts allowed after the initial request.
`backoff`	`{ initialDelayMs?, maxDelayMs?, multiplier?, jitter? }`	Default delay strategy when the policy retries without returning `delayMs`. `backoff.maxDelayMs` caps this computed backoff delay only; it does not cap explicit `delayMs` values returned by a policy or retry-after hints.
`policy`	`RetryPolicy`	Callback that decides whether to retry. This function is runtime-only and is not serialized into persisted run state.

A retry policy receives a RetryPolicyContext with:

attempt and maxRetries so you can make attempt-aware decisions.
stream so you can branch between streamed and non-streamed behavior.
error for raw inspection.
normalized facts such as statusCode, retryAfterMs, errorCode, isNetworkError, and isAbort.
providerAdvice when the underlying model/provider can supply retry guidance.

The policy can return either:

true / false for a simple retry decision.
{ retry, delayMs?, reason? } when you want to override the delay or attach a diagnostic reason for logging.

The SDK exports ready-made helpers on retryPolicies:

Helper	Behavior
`retryPolicies.never()`	Always opts out.
`retryPolicies.providerSuggested()`	Follows provider retry advice when available.
`retryPolicies.networkError()`	Matches transient transport/connectivity failures.
`retryPolicies.httpStatus([..])`	Matches selected HTTP status codes.
`retryPolicies.retryAfter()`	Retries only when a retry-after hint is available, using that hint as an explicit delay that is not capped by `backoff.maxDelayMs`.
`retryPolicies.any(...)`	Retries when any nested policy opts in.
`retryPolicies.all(...)`	Retries only when every nested policy opts in.

When you compose policies, providerSuggested() is the safest first building block because it preserves provider vetoes and replay-safety approvals when the provider can distinguish them.

Safety boundaries

Some failures are never retried automatically:

Abort errors.
Streamed runs after any visible event or raw model event has already been emitted.
Provider advice that marks replay as unsafe.

Stateful follow-up requests using previousResponseId or conversationId are also treated more conservatively. For those requests, non-provider predicates such as networkError() or httpStatus([500]) are not enough by themselves. The retry policy must include a replay-safe approval from the provider, typically via retryPolicies.providerSuggested().

Runner and agent merge behavior

retry is deep-merged between runner-level and agent-level modelSettings:

An agent can override only retry.maxRetries and still inherit the runner’s policy.
An agent can override only part of retry.backoff and keep sibling backoff fields from the runner.
If you need to remove an inherited policy or backoff, set that field to undefined explicitly.

See examples/basic/retry.ts and examples/ai-sdk/retry.ts for fuller examples with logging.

Prompt

Agents can be configured with a prompt parameter, indicating a server-stored prompt configuration that should be used to control the Agent’s behavior. Currently, this option is only supported when you use the OpenAI Responses API.

prompt can be either a static object or a function that returns one at runtime. For the callback shape, see Dynamic prompts.

Field	Type	Notes
`promptId`	`string`	Unique identifier for a prompt.
`version`	`string`	Version of the prompt you wish to use.
`variables`	`object`	A key/value pair of variables to substitute into the prompt. Values can be strings or content input types like text, images, or files.

import { parseArgs } from 'node:util';
import { Agent, run } from '@openai/agents';

/*
NOTE: This example will not work out of the box, because the default prompt ID will not
be available in your project.

To use it, please:
1. Go to https://platform.openai.com/chat/edit
2. Create a new prompt variable, `poem_style`.
3. Create a system prompt with the content:
   Write a poem in {{poem_style}}
4. Run the example with the `--prompt-id` flag.
*/

const DEFAULT_PROMPT_ID =
  'pmpt_6965a984c7ac8194a8f4e79b00f838840118c1e58beb3332';
const POEM_STYLES = ['limerick', 'haiku', 'ballad'];

function pickPoemStyle(): string {
  return POEM_STYLES[Math.floor(Math.random() * POEM_STYLES.length)];
}

async function runDynamic(promptId: string) {
  const poemStyle = pickPoemStyle();
  console.log(`[debug] Dynamic poem_style: ${poemStyle}`);

  const agent = new Agent({
    name: 'Assistant',
    prompt: {
      promptId,
      version: '1',
      variables: { poem_style: poemStyle },
    },
  });

  const result = await run(agent, 'Tell me about recursion in programming.');
  console.log(result.finalOutput);
}

async function runStatic(promptId: string) {
  const agent = new Agent({
    name: 'Assistant',
    prompt: {
      promptId,
      version: '1',
      variables: { poem_style: 'limerick' },
    },
  });

  const result = await run(agent, 'Tell me about recursion in programming.');
  console.log(result.finalOutput);
}

async function main() {
  const args = parseArgs({
    options: {
      dynamic: { type: 'boolean', default: false },
      'prompt-id': { type: 'string', default: DEFAULT_PROMPT_ID },
    },
  });

  const promptId = args.values['prompt-id'];
  if (!promptId) {
    console.error('Please provide a prompt ID via --prompt-id.');
    process.exit(1);
  }

  if (args.values.dynamic) {
    await runDynamic(promptId);
  } else {
    await runStatic(promptId);
  }
}

main().catch((error) => {
  console.error(error);
  process.exit(1);
});

Any additional agent configuration, like tools or instructions, will override the values you may have configured in your stored prompt.

When a stored prompt already defines the model, the SDK does not send the agent’s default model unless you explicitly override it. That matters for computerTool(): prompt-managed runs keep the legacy preview wire shape by default for compatibility. To opt into the GA Responses computer tool on a prompt-managed run, explicitly set modelSettings.toolChoice: 'computer' or send an explicit model such as gpt-5.6-sol. See Tools for the surrounding computer-use details.

Advanced providers and observability

Custom model providers

Implementing your own provider is straightforward – implement ModelProvider and Model and pass the provider to the Runner constructor:

import {
  ModelProvider,
  Model,
  ModelRequest,
  ModelResponse,
  ResponseStreamEvent,
} from '@openai/agents-core';

import { Agent, Runner } from '@openai/agents';

class EchoModel implements Model {
  name: string;
  constructor() {
    this.name = 'Echo';
  }
  async getResponse(request: ModelRequest): Promise<ModelResponse> {
    return {
      usage: {},
      output: [{ role: 'assistant', content: request.input as string }],
    } as any;
  }
  async *getStreamedResponse(
    _request: ModelRequest,
  ): AsyncIterable<ResponseStreamEvent> {
    yield {
      type: 'response.completed',
      response: { output: [], usage: {} },
    } as any;
  }
}

class EchoProvider implements ModelProvider {
  getModel(_modelName?: string): Promise<Model> | Model {
    return new EchoModel();
  }
}

const runner = new Runner({ modelProvider: new EchoProvider() });
console.log(runner.config.modelProvider.getModel());
const agent = new Agent({
  name: 'Test Agent',
  instructions: 'You are a helpful assistant.',
  model: new EchoModel(),
  modelSettings: { temperature: 0.7, toolChoice: 'auto' },
});
console.log(agent.model);

If you want every run() call and every newly constructed Runner to use the same provider by default, set it once during app startup:

import { setDefaultModelProvider } from '@openai/agents';

setDefaultModelProvider({
  async getModel() {
    // Return any Model implementation here.
    throw new Error('Provide your own model implementation.');
  },
});

This is useful when your app standardizes on a non-OpenAI provider and you do not want to pass a custom Runner everywhere.

AI SDK integration

If you want to use non-OpenAI models without implementing ModelProvider yourself, see Using any model with Vercel’s AI SDK. That adapter lets you plug an AI SDK model into the Agents runtime directly, which is useful when your app already standardizes on AI SDK providers or you want access to the wider provider ecosystem. It also documents how Agents SDK providerData maps to AI SDK providerMetadata, plus the stream helpers available for AI SDK UI routes.

Tracing credentials

Tracing is already enabled by default in supported server runtimes. Use setTracingExportApiKey() only when trace export should use a different credential than the default OpenAI API key:

import { setTracingExportApiKey } from '@openai/agents';

setTracingExportApiKey('sk-...');

This sends traces to the OpenAI dashboard using that credential. For exporter customization such as custom ingest endpoints or retry tuning, see the Tracing guide.

Next steps

Explore running agents.
Give your models super‑powers with tools.
Add guardrails or tracing as needed.