Skip to content

feat(messages): translate/polyfill context_management for non-Anthropic upstreams instead of dropping #711

Description

@jarvis9443

Follow-up to #710 (AISIX-Cloud#953).

#710 fixes the 400 by dropping context_management (and other untranslated Anthropic-only fields) on the /v1/messages cross-provider path. That restores compatibility but loses the context-editing semantics the client asked for.

LiteLLM (HEAD 88e03e5) does more:

  • On its OpenAI/Azure path it routes /v1/messages through the Responses API and translates context_management into OpenAI's native compaction param ({"edits":[{"type":"compact_20260112","trigger":{"type":"input_tokens","value":N}}]}[{"type":"compaction","compact_threshold":N}]); non-compact edits are skipped.
  • On its chat-completions path it polyfills context management inside the gateway (experimental_pass_through/context_management/): applies clear_tool_uses/compact edits to the message history before dispatch (compact calls a summarization model), so the upstream never sees the field.

Options for us, in increasing effort:

  1. clear_tool_uses polyfill only (pure message-history rewrite, no extra model call)
  2. full polyfill incl. compact (needs a summarization call + config for which model to use)
  3. Responses-API-style translation if/when we dispatch cross-provider traffic to /v1/responses-capable upstreams

Until then, dropping keeps Claude Code working against GPT models (context editing degrades gracefully — the client just never sees its context shrink).

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Long-tail integrations — backlogenhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions