The buildCompactURL function does not handle the RawURL configuration option. This is inconsistent with other URL building functions in the transformer, such as buildFullRequestURL in llm/transformer/openai/outbound.go. If t.config.RawURL is true, it should return t.config.BaseURL directly to support custom endpoints.

func (t *OutboundTransformer) buildCompactURL() string {
	if t.config.RawURL {
		return t.config.BaseURL
	}
	return t.config.BaseURL + "/responses/compact"
}

The Model field of the llm.Response is not being set. It should be populated from the upstream response. After adding the Model field to responses.CompactAPIResponse, you can use compactResp.Model to populate this.

This file is almost identical to llm/transformer/openai/responses/compact_outbound.go. This code duplication makes maintenance harder. Consider refactoring the common logic for handling compact requests and responses into a shared package or utility function that both openai.OutboundTransformer and responses.OutboundTransformer can use. This would improve maintainability and ensure consistency. For example, you could create a compact package inside llm/transformer/shared and move the transformation logic there.

The CompactAPIResponse struct is missing the Model field. It's a good practice for API responses to include the model that was used to generate the response, especially since the request includes it. This information is valuable for clients and for debugging.

Following the suggestion to add a Model field to CompactAPIResponse, you should populate this field from the llm.Response. The llm.Response contains the model information that was used.

This implementation creates a new InboundTransformer instance on every call to TransformError. Since InboundTransformer is stateless, this is inefficient. Consider refactoring this to avoid repeated allocations, for example by using a package-level variable for the InboundTransformer instance and reusing it here. This would improve performance by reducing garbage collection pressure.

The Model field in the llm.Response is being set to an empty string. This field should be populated with the model name from the upstream response. After adding the Model field to CompactAPIResponse, you can use compactResp.Model to populate this.

🟡 convertUserMessage nests compaction items inside message content instead of emitting them as top-level items

In convertUserMessage, compaction content parts are added to the message's contentItems slice, which gets wrapped inside Content: &Input{Items: contentItems} of a single message Item. This produces {"type": "message", "role": "user", "content": [{"type": "compaction", ...}]}, where the compaction item is incorrectly nested as a message content item.

In contrast, convertAssistantMessage at llm/transformer/openai/responses/outbound_convert.go:262-270 correctly uses the flushMessage() pattern to break compaction items out as separate top-level items. The Responses API expects compaction and compaction_summary to be top-level input items, not nested inside a message content array. While current code paths don't create user/developer messages with compaction parts (since compactionMessageFromItem always creates assistant messages), any future code that does would produce invalid API payloads that the upstream provider would likely reject.

Refactor convertUserMessage in llm/transformer/openai/responses/outbound_convert.go to return []Item instead of a single Item, and use the same flushMessage() pattern that convertAssistantMessage uses (lines 241-281) to emit compaction/compaction_summary parts as separate top-level items instead of nesting them inside the message content array. The call site in convertInputFromMessages (line 114) should then use `items = append(items, convertUserMessage(msg)...)` instead of `items = append(items, convertUserMessage(msg))`.

Was this helpful? React with 👍 or 👎 to provide feedback.