Skip to content

Dialect scope: chat completions only, or also reasoning_content / Responses API / Anthropic? #56

Description

@weselben

Status

Options A/B/C posted in a follow-up comment. Waiting on user reply.

Question

Question

The prototype only inspects choices[].delta.content (OpenAI chat-completions SSE). reasoning_content, the Responses API event envelope, and the Anthropic messages dialect pass through unguarded. Which dialects must the first shipped version cover?

Activity

  1. weselben commented on Sep 1, 2026

    @weselben
    OwnerAuthor

    Phone-friendly options (reply with a letter):

    • A (recommended): chat completions only for v1. The gateway's translated route covers choices[].delta.content; other dialects pass through unguarded (documented limitation).
    • B: + reasoning_content. Also accumulate choices[].delta.reasoning_content into a second detection stream. Cheap; catches thinking-mode loops (the NVIDIA/Kimi K2.6 class of bug from the prior-art survey).
    • C: + Responses API + Anthropic dialects. Full coverage; each dialect needs its own event parser and rewrite path — roughly 3x the prototype's parsing code.

    Grill note: vLLM/oh-my-pi bugs in the wild were mostly reasoning-stream loops, so B is the sweet spot if you want v1 to catch the common case without tripling scope.

  2. weselben commented on Sep 1, 2026

    @weselben
    OwnerAuthor

    WE should built IT into the global requests handler If possible somehow so we can achive ITS simply (kiss) active under all endpoints even when there are new coming in the future ?

  3. weselben commented on Sep 1, 2026

    @weselben
    OwnerAuthor

    Chokepoint inventory (from code, not guesswork). Model SSE leaves the gateway through exactly two families:

    1. Translated routes — chat completions, Responses API, Anthropic messages. All three already funnel through StreamResult.WrapDeliveryStream (translated_inference_service.go:149, :329, messages_handler.go:223). The guard is already active here via the wiring we shipped.
    2. Passthrough routes (/p/{provider}/...) — passthrough_support.go streams provider SSE directly to the client (flush at :359/:371), bypasses WrapDeliveryStream today. Guarding it means wrapping that response writer path too.

    Non-model SSE (admin live tail, MCP) is out of scope.

    Confirm: should v1 also wrap the passthrough family (small extra wrapper, same guard), or is translated-routes-only fine for v1 with passthrough documented as unguarded? Reply wrap or v1-translated-only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions