Is there a way to disable streaming mode?

Can OpenCode work without Streaming mode? The proxy provider I'm using doesn't support streaming at the moment:

AI_APICallError: Streaming is not supported in Credal OpenAI Proxy

+1, because you now need to be verified organization to use steaming with gpt5, so being able to turn off streaming would be great.

Facing the same issue

+1

Is this something an outside contribution could solve or does it need a lot of work?

im also interested in testing non-streaming mode for opencode, that may save some network, making debugging of problems in the protocol easier too.

+1

Hitting this too. For us streaming isn't just unsupported, it corrupts output. Our self-hosted vLLM (Gemma 4 31B) backend has a streaming-only tool-call parser bug that duplicates characters in large tool-call arguments (file contents in write/edit): <html → <<htmlhtml. The identical request with stream:false is clean. So every edit OpenCode makes comes back garbled and it loops re-writing the file.

Setting options.streaming: false in the provider config has no effect (v1.15.13). It looks like the field isn't consumed at runtime (related: #5674, and the buildParams() hardcoded stream:true noted in #24815). Our only workaround is a local proxy that forces stream:false upstream and re-serialises the response as SSE.

Requesting a respected per-provider/per-model option to disable streaming, e.g.:

"provider": {
  "vllm": {
    "npm": "@ai-sdk/openai-compatible",
    "options": { "baseURL": "…", "streaming": false },
    "models": { "…": {} }
  }
}

so it actually sends stream:false to the provider. This unblocks both providers that can't stream and providers whose streaming output is broken.

feat(opencode): respect provider/model streaming:false to disable res…

FYI: For those of you having problem using Gemma 4 31B on vLLM with OpenCode. Updating vLLM to 0.24.0 and using the vLLM example template solved all of our issues.

FYI: For those of you having problem using Gemma 4 31B on vLLM with OpenCode. Updating vLLM to 0.24.0 and using the vLLM example template solved all of our issues.

Any clue how to make DeepSeek v4 Flash 0731 work with streaming? It's the same issue there: corrupted tool calls. Both on vLLM and sglang (used latest dev nightly builds).

FYI: For those of you having problem using Gemma 4 31B on vLLM with OpenCode. Updating vLLM to 0.24.0 and using the vLLM example template solved all of our issues.

Any clue how to make DeepSeek v4 Flash 0731 work with streaming? It's the same issue there: corrupted tool calls. Both on vLLM and sglang (used latest dev nightly builds).

Haven't been able to test, as we're not allowed to deploy Chinese models at work, unfortunately...

@izogfif

@izogfif Use a litellm proxy

model_list:
    -  model_name: deepseek-ai/DeepSeek-V4-Flash
       litellm_params:
            model: hosted_vllm/deepseek-ai/DeepSeek-V4-Flash-0731
            api_base: http://localhost:8000/v1
            api_key: dummy

@junwha

@junwha

Use a litellm proxy

Does it generate fake / empty streaming tokens in response? Opencode has some kind of built-in timeout (around 300 seconds, I think). If it doesn't receive at least one streaming response token within that limit, it will consider API endpoint timed out and retry the request. And I often encounter situations when it takes more than 300 seconds to generate the full non-streaming response.
Here is what Google AI told me but I'm not sure if it's true:

While LiteLLM does have an internal "fake streaming" mechanism (MockResponsesAPIStreamingIterator) that translates a stream=true request into a non-streaming upstream call, it waits for the complete upstream non-streaming response to finish before it splits that response up into chunks and sends them back to your consumer. It does not proactively emit periodic "keep-alive" or empty filler tokens to the client while the upstream endpoint is still thinking.

To prevent opencode from timing out while waiting for a slow non-streaming backend, you will need to intercept the request and handle the keeping-alive yourself.

Sources :

[Feature]: Support enabling fake streaming generally for all providers, or at least for OpenAI BerriAI/litellm#30208

[Bug]: Responses API streaming falls back to fake stream for custom models, silently dropping function_call events BerriAI/litellm#21090

[Feature]: Force enable fake streaming per model BerriAI/litellm#5416

Reminder: https://github.com/crashr/llama-stream could be a workaround.

+1

Navigation Menu

Repository navigation

Is there a way to disable streaming mode? #785

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Is there a way to disable streaming mode? #785

Description

Activity

McAvity commented on Aug 8, 2025

harkairt commented on Aug 10, 2025

archodev commented on Aug 17, 2025

jordanbaindev commented on Sep 8, 2025

LeonMusCoden commented on Sep 15, 2025

JeongJuhyeon commented on Sep 25, 2025

trufae commented on Oct 16, 2025

HansuHessu commented on Oct 25, 2025

dayeguilaiye commented on Oct 27, 2025

jayteaftw commented on Nov 7, 2025

eleqtrizit commented on Jan 17, 2026

csawtelle commented on Jan 23, 2026

smetay commented on Feb 2, 2026

RawthiL commented on Feb 3, 2026

10 remaining items

Snowy117 commented on Jun 3, 2026

trufae commented on Jun 3, 2026

sebdanielsson commented on Jun 8, 2026

sebdanielsson commented on Jul 3, 2026

izogfif commented on Aug 9, 2026

sebdanielsson commented on Aug 10, 2026

junwha commented on Aug 21, 2026

izogfif commented on Aug 28, 2026

crashr commented on Aug 28, 2026

StroepWafel commented on Sep 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions