Is there an existing issue for this?
Current behavior
When using a LiteLLM proxy with an auto router (complexity router, semantic router), the actual model selected by the router is returned in HTTP response headers like x-litellm-model-api-base and llm_provider-x-ms-deployment-name. The AI SDK captures these headers on the finish-step stream event (value.response.headers), but processor.ts only reads value.usage, value.providerMetadata, and value.finishReason — value.response is discarded entirely.
This means plugins cannot determine which model actually served a request when using proxy-based routing.
Expected behavior
Response headers from LLM provider HTTP responses should be available on the assistant message so plugins can access proxy routing metadata and other provider-specific response headers.
How to reproduce
- Configure OpenCode with a LiteLLM proxy using a complexity/semantic router
- Send a message through the router
- Write a plugin listening for
message.updated events
- Observe that
msg.responseHeaders does not exist — the plugin can only see the router alias in msg.modelID
OpenCode version
dev (latest)
Platform
macOS
Additional context
The APIError schema in the same file already has a responseHeaders field for error responses. This change extends the same pattern to successful responses.
Example plugin that would use this: https://github.com/jtbnz/opencode-routed-model
Is there an existing issue for this?
Current behavior
When using a LiteLLM proxy with an auto router (complexity router, semantic router), the actual model selected by the router is returned in HTTP response headers like
x-litellm-model-api-baseandllm_provider-x-ms-deployment-name. The AI SDK captures these headers on thefinish-stepstream event (value.response.headers), butprocessor.tsonly readsvalue.usage,value.providerMetadata, andvalue.finishReason—value.responseis discarded entirely.This means plugins cannot determine which model actually served a request when using proxy-based routing.
Expected behavior
Response headers from LLM provider HTTP responses should be available on the assistant message so plugins can access proxy routing metadata and other provider-specific response headers.
How to reproduce
message.updatedeventsmsg.responseHeadersdoes not exist — the plugin can only see the router alias inmsg.modelIDOpenCode version
dev (latest)
Platform
macOS
Additional context
The
APIErrorschema in the same file already has aresponseHeadersfield for error responses. This change extends the same pattern to successful responses.Example plugin that would use this: https://github.com/jtbnz/opencode-routed-model