[FEATURE] Expose Otari request IDs in the hand-written shell

[njbrake]

Problem or use case

The gateway returns Otari-Request-ID on inference responses and this SDK discards it, so callers cannot correlate a call with routing, latency, or usage telemetry. It is also the lookup key for the platform's request-cost API.

otari-sdk-python is adding this in mozilla-ai/otari-sdk-python#32. The generated core differs per language and each shell is hand-written in its own repo, so there is no way to share the implementation. Nothing catches the gap either: the only cross-SDK gate is the endpoint-coverage manifest, and this is shell ergonomics rather than a new endpoint.

Proposed solution

Match the Python behavior: opt in rather than changing existing return types, surface the ID alongside the payload for non-streaming calls, and expose it on streaming calls once the HTTP response is open and before the first event.

This one is harder than the other three, and the non-streaming half needs a design decision first. The generated core discards success-path headers: chat_completions_v1_chat_completions_post returns Result<models::ChatCompletion, Error<...>>, and only the error path carries a ResponseContent. There is no *_with_http_info analogue to reach for, unlike Python (ApiResponse), TypeScript (*Raw()), and Go (*http.Response). Options:

• issue the non-streaming request from the shell with its own reqwest call, the way the streaming path already does, and parse into the generated model
• add a response-inspection layer around the generated client
• change the generator config or templates so the core returns headers, which would be an upstream change in mozilla-ai/otari and would affect the generated core for every endpoint

The streaming half is straightforward, since src/core.rs already owns its own HTTP call.

Alternatives considered

Shipping streaming-only support would be half a feature and would make the API inconsistent with the other three SDKs.

Notes

The header is sent on every Chat, Messages and Responses answer in both runtime modes. In hybrid mode it carries the platform's ID for the request; a standalone gateway mints its own. It is also returned on MCP responses, on success and on failure alike.

Note: this issue was drafted by Claude Opus 5 via back-and-forth with @njbrake. The reasoning and decisions are his; the prose is Claude's.

[peteski22]

Corrected the body above for two things that would have sent an implementer the wrong way.

The header is now Otari-Request-ID. mozilla-ai/otari#1485 renames the gateway's four X-Otari-* response headers to drop the X- prefix, per RFC 6648. There is no deprecation window, so the old name is simply gone from the release that carries it. Anyone implementing this issue against X-Otari-Request-ID would read nothing, and would read it silently, because a header that is not sent looks the same as one a client chose to ignore.

The Notes section was wrong about hybrid mode. It said the ID is absent against a standalone gateway. The gateway sets the header on both branches: hybrid mode carries the platform's ID, and a standalone gateway mints a UUID of its own. Otari's API reference documents that, and its standalone integration tests assert the header parses as a UUID. So the ID is available in both modes and should not be documented as a hybrid-only feature.

Nothing else in the issue changed. The design discussion and the per-language notes stand.

Note: this comment was drafted by Claude Opus 5 in session with @peteski22, who directed and approved the correction.