Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4131687ff5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
|
||
| `MY_TRACING_ENDPOINT` and `MY_TRACING_API_KEY` are application-defined environment variables read by this example, not variables that the SDK reads automatically. For example, the endpoint could be `https://tracing.example.com/v1/traces/ingest`. A service that implements model endpoints does not necessarily implement traces ingestion; use a compatible receiver or an [ecosystem integration](#ecosystem-integrations). | ||
|
|
||
| The exporter sends its API key as a Bearer token to the configured endpoint. If `api_key` is omitted, the exporter falls back to `OPENAI_API_KEY`; per-run keys configured through `RunConfig.tracing` take precedence over the exporter's key. The exporter also falls back to `OPENAI_ORG_ID` and `OPENAI_PROJECT_ID` for its organization and project headers. Configure these credentials and headers for the intended tracing destination. Using `add_trace_processor()` instead of `set_trace_processors()` keeps the default OpenAI exporter active as an additional destination. |
There was a problem hiding this comment.
When an application follows the last sentence to retain the default OpenAI exporter and also uses the documented RunConfig.tracing={"api_key": ...}, both processors receive the same trace item and each BackendSpanExporter chooses that item-level key over its own configured key. The OpenAI key is therefore sent as a Bearer token to the custom endpoint, or the custom service's key is sent to OpenAI, while one destination also receives the wrong credential. Do not recommend this multi-destination setup without explaining that per-run keys cannot provide per-destination credentials and giving a safe alternative.
AGENTS.md reference: AGENTS.md:L16-L18
Useful? React with 👍 / 👎.
|
|
||
| Model requests and trace exports use separate clients and destinations. Setting `OPENAI_BASE_URL` or a model client's `base_url` changes model requests; the default tracing exporter still posts to `https://api.openai.com/v1/traces/ingest`. Configure tracing separately when using a model gateway or a self-hosted model. | ||
|
|
||
| To send traces to a different service that accepts the OpenAI traces ingest payload, configure [`BackendSpanExporter`][agents.tracing.processors.BackendSpanExporter] with the full ingest URL and a credential for that service. Replace the default processor during application startup, before creating traces or running agents: |
There was a problem hiding this comment.
When this endpoint is an OpenAI-compatible gateway or proxy, BackendSpanExporter skips _sanitize_for_openai_tracing_api() because its URL differs from the hard-coded OpenAI URL. Ordinary task, turn, and response spans consequently retain usage fields that the sanitizer identifies as rejected by traces ingest, and oversized inputs remain untruncated, so a receiver that forwards or strictly implements the advertised OpenAI ingest contract can reject and drop the batch. Either limit this guidance to receivers accepting the SDK's unsanitized payload or provide a way to enable ingest sanitization for compatible endpoints.
AGENTS.md reference: AGENTS.md:L166-L166
Useful? React with 👍 / 👎.
1 participant
Summary
OPENAI_BASE_URLcan redirect model requests while traces still go to the default OpenAI ingest endpoint. This pull request updates the tracing guide with the existing way to configure a separate destination usingBackendSpanExporterand replace the default processor during application startup.The example uses separate application-defined tracing credentials and explains receiver compatibility, per-run key precedence, organization/project header fallbacks, and why adding a processor keeps the default destination active. SDK behavior is unchanged.
Test plan
v0.22.2source, with all HTTP calls mocked. Verified that the model base URL leaves the default trace endpoint unchanged, while the example exports one synthetic trace to the selected receiver with its own key and configured routing headers.uv run --frozen pytest tests/test_trace_processor.py tests/tracing/test_processor_api_key.py -k 'custom_endpoint or test_processor' -q: 6 passed, 53 deselected.make build-docs.No live model or tracing API calls were made. The full SDK verification stack is not applicable to this documentation-only change under the contributor guide.
Issue number
Related to #5008. This addresses the documentation portion; it does not add the suggested automatic environment override or warning.
Checks
.agents/skills/code-change-verification/scripts/run.sh(not applicable: documentation-only change).