CFP (Cloudflare Playground) Streaming Works in Brave Leo AI but Fails in OpenCode with "Stream ended before producing a non-ping SSE event"

[linuxtopia]

Environment

• OmniRoute Version: v16.3.1
• Client: OpenCode Desktop (Electron app using @ai-sdk/openai-compatible)
• Models Affected: All CFP models (e.g., cfp/deepseek-ai/deepseek-v4-pro-0813, cfp/zai-org/glm-5.2)
• Playwright: Installed via bunx (headless Chromium available at ~/.cache/ms-playwright/)

Problem Description

CFP models work perfectly via:

• ✅ curl (both streaming and non-streaming)
• ✅ Brave Leo AI (BYOM feature using the same OmniRoute endpoint)

But fail consistently in OpenCode with:

Stream ended before producing a non-ping SSE event [retrying in 1s attempt #2]

The stream never produces any content chunks in OpenCode, even though OmniRoute logs show successful responses.

Reproduction Steps

1. curl Test (✅ Works)

Non-streaming:

curl -X POST http://localhost:20128/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${API_KEY}" \
  -d '{
    "model": "cfp/deepseek-ai/deepseek-v4-pro-0813",
    "messages": [{"role": "user", "content": "hi"}],
    "max_tokens": 100,
    "stream": false
  }'

Response: ✅ Full response with content

Streaming:

curl -X POST http://localhost:20128/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${API_KEY}" \
  -d '{
    "model": "cfp/deepseek-ai/deepseek-v4-pro-0813",
    "messages": [{"role": "user", "content": "3 sentences about cats"}],
    "max_tokens": 500,
    "stream": true
  }'

Response: ✅ 60+ SSE chunks with data: {...} format, includes reasoning_content and content, ends with data: [DONE]

2. Via Brave's Leo Bring Your Own Model (BYOM) AI Test for Omniroute-CFP (✅ Works)

Configuration in Brave BYOM:

Label: CFP DeepSeek V4 Pro
Model: cfp/deepseek-ai/deepseek-v4-pro-0813
Endpoint: http://localhost:20128/v1/chat/completions
Context Size: 8000

Result: ✅ Full 4-paragraph response, streaming works perfectly

3. OpenCode Test (❌ Fails)

OpenCode Config (~/.config/opencode/opencode.json):

{
  "provider": {
    "omniroute": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "OmniRoute",
      "options": {
        "baseURL": "http://localhost:20128/v1",
        "apiKey": "sk-c..."
      },
      "models": {
        "cfp/deepseek-ai/deepseek-v4-pro-0813": {
          "name": "CFP DeepSeek V4 Pro",
          "maxTokens": 8192
        },
        "cfp/zai-org/glm-5.2": {
          "name": "CFP GLM 5.2",
          "maxTokens": 8192
        }
      }
    }
  }
}

Test in OpenCode:

1. Select model: "CFP DeepSeek V4 Pro"
2. Send prompt: "Write 4 paragraphs about quantum computing"
3. Result: ❌ Stream ended before producing a non-ping SSE event [retrying attempt #2]

Analysis

Observations

1. OmniRoute streaming works (proven by curl and Brave Leo AI)
2. OpenCode's @ai-sdk/openai-compatible fails with CFP models specifically
3. Other OmniRoute providers work fine in OpenCode (e.g., kiro/claude-sonnet-4.5, puter/gpt-4o)

Hypothesis: First-Chunk Timeout

Based on research into Vercel AI SDK issues (vercel/ai#16538), the @ai-sdk/openai-compatible library has streaming timeout issues:

• CFP models use WebSocket + Playwright (per PR feat(providers): add Cloudflare AI Playground as a No Auth provider (closes #10389) #10442)
• The browser needs to launch, establish WebSocket, and translate cf_agent RPC frames to SSE
• This causes a 10-15 second delay before the first content chunk
• The AI SDK's chunkMs timeout doesn't cover this "pre-first-chunk window"
• OpenCode gives up before receiving the first actual content chunk

Timing Breakdown

OpenCode sends request → OmniRoute receives
  ↓
OmniRoute spawns Playwright browser (~2-3s)
  ↓
Browser connects to CF Playground WebSocket (~1-2s)
  ↓
WebSocket sends cf_agent RPC request (~0.5s)
  ↓
CF Playground starts inference (~5-10s for large models)
  ↓
First reasoning_content chunk arrives (~10-15s total)
  ↓
⚠️ OpenCode times out here: "Stream ended before producing a non-ping SSE event"

Why Brave Leo AI Works But OpenCode Doesn't

Brave Leo AI:

• Native browser environment
• Likely has higher/no timeout for first chunk
• Handles SSE streams with browser-native EventSource or custom parser

OpenCode:

• Uses Vercel AI SDK's @ai-sdk/openai-compatible
• Has a hardcoded or short timeout for first chunk
• No config option to extend the "pre-first-chunk" timeout

Attempted Solutions

1. ✅ Installed Playwright

bunx playwright install chromium

Confirmed working: OmniRoute can launch headless Chromium and CFP models work via curl.

2. ❌ Added API Key to OpenCode Config

"apiKey": "sk-c"

No change in behavior.

3. ❌ Increased maxTokens

"maxTokens": 8192

No change in behavior.

4. ❌ Built Custom Proxy

Created a Node.js proxy to convert streaming to non-streaming, then wrap back to SSE:

// Proxy: localhost:20130 → localhost:20128
// Convert stream:true → stream:false for CFP models
// Wrap non-streaming response back into SSE chunks

Result: Proxy worked with curl, but OpenCode still timed out.

Questions

1. Is there a way to configure streaming timeouts in OpenCode?

   • Can @ai-sdk/openai-compatible be configured to wait longer for the first chunk?
   • Is there a global streaming timeout setting in OpenCode?

2. Is this a known limitation of CFP models with OpenCode?

   • Should CFP models be marked as "incompatible with streaming-only clients"?
   • Is there a recommended workaround?

3. Can OmniRoute detect slow-starting providers and add SSE ping frames?

   • Could OmniRoute send periodic data: {"type":"ping"} frames during the Playwright startup phase?
   • Would this keep OpenCode's streaming connection alive?

Request

Is there a way to make CFP models work in OpenCode, or is this a fundamental incompatibility between:

• CFP's slow startup time (WebSocket + Playwright)
• OpenCode's streaming timeout expectations

Any guidance would be appreciated!

---

Additional Context:

• OmniRoute GitHub Issues show many "stream ended" bugs were fixed (e.g., [BUG] Misleading "Stream ended before producing useful content" error when model produces reasoning_only response #2520, [BUG] Stream ended before producing useful content #2000, [BUG] Minimax m3, qwen3.5 397b, glm5.1 on nvidia nim shows the error Stream ended before producing useful content #3758, fix(resilience): ensureStreamReadiness discards executor error-only SSE frames #8972)
• But none mention OpenCode specifically or the "pre-first-chunk" timeout window
• Brave Leo AI proves the underlying streaming does work — the issue is client-side timeout handling

[linuxtopia]

✅ Resolved: stream:true → stream:false proxy works

Confirmed root cause matches your analysis — CFP's Playwright + WebSocket startup takes 10-15s, which exceeds the AI SDK's pre-first-chunk window.

Solution that works

A small Node proxy that converts stream:true → stream:false for CFP models only, then wraps the JSON response back into SSE chunks. This fully bypasses the pre-first-chunk timeout because no chunk is sent until the entire response is ready.

#!/usr/bin/env node
// cfp-proxy.mjs - listens on 20130, forwards to OmniRoute 20128
import { createServer } from 'node:http';

const UPSTREAM = 'http://localhost:20128';
const PORT = 20130;
const API_KEY = '<YOUR_OMNIROUTE_KEY>';

const server = createServer(async (req, res) => {
  if (req.method !== 'POST' || req.url !== '/v1/chat/completions') {
    res.writeHead(404); res.end(); return;
  }
  const chunks = [];
  for await (const c of req) chunks.push(c);
  const body = Buffer.concat(chunks).toString();
  const parsed = JSON.parse(body);
  const wantStream = parsed.stream === true;
  const isCfp = parsed.model?.startsWith('cfp/');

  // Force non-streaming for CFP, so we wait for the full response
  if (isCfp && wantStream) parsed.stream = false;

  const upstream = await fetch(`${UPSTREAM}/v1/chat/completions`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': req.headers.authorization || `Bearer ${API_KEY}`,
    },
    body: JSON.stringify(parsed),
  });

  if (isCfp && wantStream) {
    const result = await upstream.json();
    if (result.error) {
      res.writeHead(upstream.status, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify(result));
      return;
    }
    // Re-emit the JSON response as a sequence of SSE chunks
    const msg = result.choices?.[0]?.message;
    const base = { id: result.id, object: 'chat.completion.chunk',
                   created: result.created, model: result.model };
    res.writeHead(200, { 'Content-Type': 'text/event-stream',
                         'Cache-Control': 'no-cache', 'Connection': 'keep-alive' });
    res.write(`data: ${JSON.stringify({ ...base, choices: [{ index: 0,
      delta: { role: 'assistant' }, finish_reason: null }] })}\n\n`);
    if (msg?.reasoning_content) {
      res.write(`data: ${JSON.stringify({ ...base, choices: [{ index: 0,
        delta: { reasoning_content: msg.reasoning_content },
        finish_reason: null }] })}\n\n`);
    }
    if (msg?.content) {
      res.write(`data: ${JSON.stringify({ ...base, choices: [{ index: 0,
        delta: { content: msg.content }, finish_reason: null }] })}\n\n`);
    }
    res.write(`data: ${JSON.stringify({ ...base, choices: [{ index: 0,
      delta: {}, finish_reason: 'stop' }], usage: result.usage })}\n\n`);
    res.write('data: [DONE]\n\n');
    res.end();
    return;
  }
  // Non-CFP or already non-streaming: pass through
  res.writeHead(upstream.status, { 'Content-Type': 'application/json' });
  res.end(await upstream.text());
});

server.listen(PORT, '127.0.0.1');

OpenCode config
Point a separate provider at the proxy port 20130 instead of 20128:

{
  "provider": {
    "omniroute-cfp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "OmniRoute CFP (non-streaming proxy)",
      "options": {
        "baseURL": "http://localhost:20130/v1",
        "apiKey": "<YOUR_OMNIROUTE_KEY>"
      },
      "models": {
        "cfp/deepseek-ai/deepseek-v4-pro-0813": { "maxTokens": 8192 },
        "cfp/zai-org/glm-5.2": { "maxTokens": 8192 }
      }
    },
    "omniroute": {
      "name": "OmniRoute",
      "options": { "baseURL": "http://localhost:20128/v1", "apiKey": "<YOUR_KEY>" }
    }
  }
}

Non-CFP models keep using the original omniroute provider with native streaming. Only omniroute-cfp routes through the proxy.

Trade-off

The user sees a 10-15s blank window before any chunks arrive (because we wait for the full response). Once it arrives, reasoning_content and content stream back-to-back. This is the price of bypassing the timeout — there's no way to have both sub-second TTFB and survive the CFP startup.

Other things I tried that didn't work

• Sending periodic SSE ping frames (: ping\n\n) every 2s: the AI SDK still validates the first event schema and errors out, because the very first data: line carries the ping JSON which fails Zod validation against the chunk schema.
• Header user-agent: curl/... and Content-Length rewrite: no effect, the timeout is on first-content-arrival.
• Disabling keep-alive, custom HTTP agent: no effect.

Suggestion for OmniRoute itself

Two upstream changes would eliminate the need for an external proxy:

1. CFP provider: send data: {"type":"ping"}\n\n immediately after accepting the request — before Playwright is even launched. This keeps the connection warm, but won't help with AI SDK's first-event schema check (needs the ping to be a valid chunk or true SSE comment).

2. CFP provider: emit an early data: {"choices":[{"delta":{"role":"assistant"}}]}\n\n chunk with finish_reason: null the moment the browser is launched. AI SDK sees a valid first chunk and stops timing out. Real content follows later. This is the cleanest fix.
   Hope this helps anyone else stuck on this — it took me a few hours of dead ends to find this works reliably.

[diegosouzapw]

Glad you got it working, @linuxtopia — and thanks for coming back to post the actual solution instead of leaving it hanging. Your diagnosis holds up: the failure is in the window before the first chunk, not in the stream itself, which is why curl (no client-side patience limit) and Brave Leo (different SSE consumer) both pass while the AI SDK's pre-first-chunk timer gives up.

Your proxy works because non-streaming has no pre-first-chunk window to exceed — nothing is sent until everything is ready. That is the correct workaround for the constraint, not a hack.

Worth noting for anyone who lands here: this is specific to providers with an expensive session bring-up. CFP has to start Playwright and establish a WebSocket before the first token can exist, so the gap between "request accepted" and "first byte" is structural, not load-dependent. Providers that talk straight to an HTTP API do not have this shape.

The real fix on our side would be emitting a keep-alive during that bring-up so the client's timer never fires — the same trick your proxy sidesteps by not streaming at all. Want me to open an issue for that? Your write-up is already a complete repro, and I would credit it. Say the word and I will file it, or file it yourself if you would rather have it under your name.

[linuxtopia]

as a great maintainer / dev I would be appreciated if you do it for me-us.

really thanks for your all efforts, you work hard as I see.

[diegosouzapw]

@linuxtopia — fair ask, and yes, I would rather fix this in OmniRoute than have every user rediscover your proxy.

Being precise about what the fix is, since "make it work" has more than one implementation and they are not equally good:

Not switching CFP to non-streaming. Your proxy is the correct workaround for you, but as a built-in it would take streaming away from clients that handle the delay fine — trading a real capability for a compatibility patch.

The right shape is to make the pre-first-chunk window survivable. Your own diagnosis contains the fix: the failure is entirely in the gap between "request accepted" and "first token", and the AI SDK gives up in that gap. If OmniRoute opens the SSE stream and emits a keep-alive preamble as soon as the request is accepted — before the upstream has produced anything — the client's pre-first-chunk timer never fires, because from its side bytes are arriving. The Playwright/WebSocket bring-up then completes underneath, and the real first chunk follows.

That is a small change and it fixes the whole class, not just CFP: any provider with an expensive session bring-up has the same structural gap, as I noted above.

Two things it has to get right, which is why it is not a one-liner:

• A preamble must never be mistaken for content. It has to be an SSE comment or an equivalent no-op frame that no downstream parser turns into a token — otherwise we trade a timeout for corrupted output, which is worse.
• It must not mask a genuinely dead upstream. Holding a stream open with heartbeats forever turns a fast failure into an infinite hang. There has to be a ceiling after which the request fails honestly.

I am not putting a date on it. Keep your proxy running in the meantime — it is not a hack, it is the correct answer for the constraint you have today.

And thanks again for posting the actual diagnosis rather than just "it does not work". The reason this has a clear fix is that you did the hard half.

[diegosouzapw]

@linuxtopia — I owe you a correction on my last reply here, and it changes the fix.

That error string is ours, not the client's. Stream ended before producing a non-ping SSE event is emitted by OmniRoute's stream-readiness guard as a 502 STREAM_EARLY_EOF (open-sse/utils/streamReadiness.ts:614-635). It fires when the upstream stream reaches done having never produced a usable SSE event — an early EOF, not a timeout. The [retrying in 1s attempt #2] around it is OpenCode reacting to our 502.

So my 09-07 answer was wrong in its premise. I described it as the AI SDK giving up during the pre-first-chunk gap and proposed a keepalive preamble. A keepalive cannot rescue a stream the upstream already closed, so that would not have fixed your case.

Two related facts, since they are easy to conflate:

• The keepalive mechanism I described as missing already exists: withEarlyStreamKeepalive (open-sse/utils/earlyStreamKeepalive.ts:192), and cfp is on the deliberately long 15 s tier because it is a no-auth/browser-session provider (open-sse/utils/keepaliveThreshold.ts:37-51). It was re-priced yesterday in fix(sse): price the default keepalive threshold below the client watchdog and stop leaking Anthropic finish reasons #14247 for a different client that was racing the default tier.
• Your own evidence already rules a timeout out: curl streams 60+ chunks against the same model and endpoint.

What actually distinguishes your two runs is the request, not the transport. curl and Brave Leo send a plain chat payload; OpenCode sends tools, a large system prompt and its own parameter set to the same endpoint. A CFP session that ends the stream with nothing for one payload and streams fine for another points at the upstream playground rejecting or dropping that request shape.

To pin it down I need two things:

1. The OmniRoute log entry for one failing OpenCode request — Dashboard -> Logs, open it and paste the provider response block. The 502 carries an upstreamDiagnostic when the upstream said anything at all, and that field is the whole answer if present.
2. A curl with the same body OpenCode sent (copy it from that same log entry, tools included) against the same model. If curl also fails with that body, it is the payload and I can fix it in the CFP executor; if curl succeeds with it, it is transport-level and I will look at the streaming path.

Sorry for the detour — you did the careful half of this and deserved a correct reading of it.

[diegosouzapw]

@linuxtopia -- still happening on the latest version (3.8.52)? Otherwise I'll close this in 7 days for inactivity.