[thepigdestroyer]

Summary

POST /v1/messages without a stream field and with a wildcard Accept header (curl default */*) returns HTTP 502 STREAM_EARLY_EOF in ~1.6s. Stream version (stream:true) works correctly.

Root cause

resolveStreamFlag(undefined, "*/*") falls through to !clientWantsJsonResponse("*/*") which returns true. OmniRoute then takes the streaming branch in chatCore.ts and invokes ensureStreamReadiness on the upstream response.

But Anthropic's Messages API treats stream in the body as the source of truth (Accept header is ignored). Since the body has no stream field, Anthropic returns a single JSON document with Content-Type: application/json. ensureStreamReadiness parses this JSON body as SSE, finds no useful data: {...} frame, hits EOF on the next read, and returns 502.

The bug is OpenAI-format-centric: OpenAI clients omitting stream typically expect SSE by default, but Anthropic's spec is stream: false by default.

Fix

resolveStreamFlag now takes an optional sourceFormat argument:

• sourceFormat === "claude" + ambiguous stream + no explicit text/event-stream in Accept → default to false (matches Anthropic spec).
• All other sourceFormats (or omitting the argument): unchanged. The [BUG]: stream: true ignored when client sends Accept: application/json header #656 fix and OpenAI streaming default are preserved.

Explicit body stream: true|false still wins. Explicit Accept: text/event-stream is honored as an SSE opt-in for /v1/messages.

chatCore.ts passes the already-resolved sourceFormat (from detectFormatFromEndpoint) to the new third argument.

Tests

tests/unit/t26-ai-sdk-accept-header-compat.test.ts (11/11 pass):

• 9 existing tests unchanged.
• New: sourceFormat=claude applies Anthropic non-stream default (3 ambiguous cases default false; 3 explicit cases still win; Accept text/event-stream still streams).
• New: non-claude sourceFormats (openai, gemini, codex) preserve pre-[BUG] no response on startup #2325 streaming default; omitting sourceFormat reproduces legacy two-arg behavior exactly.

Repro

Before:

curl -X POST :20128/v1/messages \
  -H 'Authorization: Bearer ...' \
  -H 'Content-Type: application/json' \
  -d '{"model":"claude/claude-opus-4-7","max_tokens":40,
       "messages":[{"role":"user","content":"hi"}]}'

→ HTTP 502 {"error":{"message":"Stream ended before producing useful content",
              "type":"stream_early_eof","code":"STREAM_EARLY_EOF"}}

After: HTTP 200 JSON in 2.4s (matches the stream:false explicit path).

Out of scope

A separate, narrower edge case remains for clients sending Accept: text/event-stream with no body stream field: upstream Anthropic still returns JSON because body lacks stream. That bug existed pre-#2325 and is not regressed here. A future PR can sync body.stream = true into the upstream passthrough when SSE is being requested.

Files

• open-sse/utils/aiSdkCompat.ts (+23 / -1)
• open-sse/handlers/chatCore.ts (+4 / -1)
• tests/unit/t26-ai-sdk-accept-header-compat.test.ts (+36)

[gemini-code-assist]

Code Review

This pull request introduces a sourceFormat parameter to the resolveStreamFlag utility to handle provider-specific streaming defaults. Specifically, it implements the Anthropic Messages API specification where requests default to non-streaming unless an explicit text/event-stream Accept header is provided, resolving issues with STREAM_EARLY_EOF errors on /v1/messages. The changes include updates to the chat handler, the compatibility utility, and new unit tests to verify the behavior for both Claude and other providers. I have no feedback to provide as there were no review comments.

[diegosouzapw]

Obrigado @thepigdestroyer pela contribuição! 🙌

Seu fix para o bug de STREAM_EARLY_EOF no POST /v1/messages foi integrado na release/v3.8.0. A abordagem de adicionar sourceFormat como parâmetro opcional em resolveStreamFlag é elegante e completamente backward-compatible — preserva o comportamento dos clientes OpenAI/Gemini/Codex enquanto aplica o padrão correto da spec Anthropic.

Este fix estará no OmniRoute v3.8.0. 🚀

[kilo-code-bot]

WARNING: Hardcoded string literal "claude" instead of FORMATS.CLAUDE constant

The rest of chatCore.ts consistently uses FORMATS.CLAUDE (lines 545, 556, 580, 587, 941, 2409, 2599, 4102, 4176) to check for the Claude format. If FORMATS.CLAUDE is ever renamed in open-sse/translator/formats.ts, this hardcoded string will silently break without a compile-time error.

Consider using FORMATS.CLAUDE here or at least typing sourceFormat as a union of known format values to catch mismatches.

[kilo-code-bot]

SUGGESTION: sourceFormat parameter typed as string is too loose

The parameter accepts any string value, making it easy to accidentally pass an incorrect format identifier. Consider typing it more strictly, e.g. sourceFormat?: keyof typeof FORMATS | string or importing a dedicated format type from formats.ts. This would improve type safety and IDE autocomplete for callers.

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found (1 WARNING, 1 SUGGESTION) | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	1

Issue Details (click to expand)

WARNING

File	Line	Issue
open-sse/utils/aiSdkCompat.ts	42	Hardcoded string literal "claude" instead of FORMATS.CLAUDE constant used everywhere else in codebase. If FORMATS.CLAUDE is renamed, this silently breaks.

SUGGESTION

File	Line	Issue
open-sse/utils/aiSdkCompat.ts	32	sourceFormat parameter typed as string — too loose, consider union type or imported format enum for better type safety and IDE autocomplete.

Other Observations (not in diff)

No issues found outside the diff.

Files Reviewed (3 files)

• open-sse/utils/aiSdkCompat.ts - 2 issues
• open-sse/handlers/chatCore.ts - No issues (change is correct — passes sourceFormat from detectFormatFromEndpoint)
• tests/unit/t26-ai-sdk-accept-header-compat.test.ts - No issues (comprehensive coverage of new behavior and backward compatibility)

---

_{Reviewed by qwen3.6-plus · 424,354 tokens}