Use Detect not Passthrough for the generic OpenRouter lane (preserve OTel telemetry)

Date: 2026-06-20 Status: Accepted Decision: hl-l875 Deciders: Sean Brandt

Context

The generic passthrough lane forwards arbitrary request bodies and paths verbatim to OpenRouter. Two agentgateway route types support this: Detect (forwards as-is but extracts the model field and usage for OTel) and Passthrough (fully opaque — no telemetry extraction). The choice determines whether the cluster’s OTel provider/model/token pipeline captures this lane at all.

Decision

Use routes: { "*": Detect } on the generic backend so agentgateway forwards bodies and paths verbatim while still scraping the model and token-usage fields for OTel.

Rationale

• Passthrough provides no telemetry benefit for a forward-as-is lane; Detect achieves the same transparent forwarding while keeping the cluster OTel provider/model/token labels intact.
• Under both Detect and Passthrough, agentgateway’s set_default_path early-returns (pathPrefix ignored, client path forwarded verbatim), so path handling is equivalent between the two options.

Alternatives Considered

• Detect (chosen): transparent forwarding plus OTel usage/token labels, cost attribution, and per-model rate-limiting. Cost: the body must be parseable enough to extract the model field; SSE-stream telemetry completeness is unverified.
• Passthrough (rejected): fully opaque with zero parsing — the OTel pipeline goes dark for the generic lane, with no cost attribution or per-model rate-limiting.

Consequences

• Positive: OTel captures provider, model, and token usage for the generic lane; rate-limiting and cost attribution remain possible.
• Negative: telemetry completeness for streamed SSE responses and non-chat endpoints (e.g. /v1/responses) is a live-verification risk.
• Neutral: client base URL and path behavior are identical to what Passthrough would give.