DeepSeek V4 Flash — OpenCode (Ollama Cloud)

Modelfile & provider preset tuned for stable work inside OpenCode over Ollama Cloud.

Background

When using Ollama Cloud models from OpenCode, several issues surface out of the box:

• Stream stalls — the response repeatedly pauses mid-token.
• Stream freezes → timeout — long stalls trip the upstream timeout.
• Same issues on plain HTTP — disabling streaming does not make them go away.
• Reasoning loops — some models (notably DeepSeek) get stuck inside their own reasoning trace and never escape.

The settings below were arrived at empirically and raise the stability of Ollama Cloud + OpenCode to roughly 95%. The remaining edge cases look like Ollama Cloud throughput / model overload bugs, not configuration problems.

⚠️ These settings are experimental. They are not endorsed by Ollama or OpenCode — they are what happened to work best in our environment.

TL;DR

Modelfile

FROM deepseek-v4-flash:cloud

PARAMETER num_ctx         1048576
PARAMETER num_predict     16384
PARAMETER temperature     1.0
PARAMETER top_p           1.0
PARAMETER repeat_penalty  1.15
PARAMETER repeat_last_n   1024
PARAMETER stop              "<|im_start|>"

OpenCode configuration

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama",
      "options": {
        "baseURL": "http://localhost:11434/v1",
        "timeout": 1200000,
        "headerTimeout": 1200000
      },
      "models": {
        "igovet/deepseek-v4-flash-opencode": {
          "_launch": false,
          "name": "DeepSeek V4 Flash OpenCode",
          "limit": {
            "context": 1048576,
            "output": 1048576
          },
          "variants": {
            "high":   { "reasoningEffort": "high",   "max_tokens": 12288 },
            "medium": { "reasoningEffort": "medium", "max_tokens": 8192 },
            "low":    { "reasoningEffort": "low",    "max_tokens": 4096 },
            "none":   { "reasoningEffort": "none",   "max_tokens": 2048 }
          }
        }
      }
    }
  }
}

Notes

Why output is set equal to context

Ollama does not honor a separate output (max output tokens) reliably through the OpenAI-compatible surface that @ai-sdk/openai-compatible speaks to. If you set output near 16384 you will see the stream cut off mid-response with no error.

The workaround used here is to make output formally equal to context. The model still decides when to stop on its own; we just stop clipping it on the client side.

Long timeouts

timeout and headerTimeout are bumped to 20 minutes (1200000 ms). Cloud models occasionally queue for several minutes during peak load, and the default AI SDK timeouts will fire long before that.

Loop Prevention

DeepSeek V4 Flash can get stuck in infinite R1-style thinking loops — the model enters a self-correcting cycle where it re-evaluates its own output, finds it wanting, and starts over without ever producing a final answer. This manifests as unbounded token generation that eventually hits num_predict or times out.

Current approach (variant C)

Three layers of defense are applied:

1. repeat_penalty and repeat_last_n — token-level repetition suppression

repeat_penalty is the primary loop-prevention mechanism. R1-style loops are characterized by verbatim phrase repetition (the model re-stating the same reasoning step in nearly identical words). A penalty of 1.15 over the last 1024 tokens catches this pattern without suppressing legitimate reasoning.

2. Stop sequence — infrastructure-level guard

Only one stop sequence is used. Thinking-marker stops (Wait,, Actually,, Let me reconsider, Let me re-examine) were removed because they truncated mid-thought at arbitrary points, producing incomplete responses. The <\|im_start\|> stop is infrastructure-level — it prevents the model from beginning a new conversational turn, which is the actual escape hatch for loop behavior.

3. Per-variant max_tokens — per-tier output cap

The Modelfile sets num_predict 16384 as a hard ceiling — the absolute maximum tokens the model can generate in a single response. This is a safety net, not an effective limit for most use cases.

The effective limit is set per-variant in opencode.json:

How num_predict and max_tokens interact:

• num_predict (Modelfile, 16384) is the absolute ceiling — the model will never generate more than this, regardless of the variant.
• max_tokens (opencode.json variant) is the effective limit — the AI SDK caps output at this value before sending to the model.
• The effective limit is min(num_predict, max_tokens). For all variants, max_tokens is lower than num_predict, so the variant setting is the binding constraint.
• This two-layer design means: if a variant’s max_tokens proves too restrictive, you can raise it without touching the Modelfile (up to 16384). The Modelfile ceiling prevents runaway generation even if a variant is misconfigured.

Iteration History

Iteration 1 tried: presence_penalty 0.15, frequency_penalty 0.1, four thinking-marker stop sequences (Wait,, Actually,, Let me reconsider, Let me re-examine), narrow repeat_last_n 512, and lower per-variant max_tokens (8192/4096/2048/1024). This approach failed because presence/frequency_penalty penalized legitimate reasoning patterns (the model naturally re-states conclusions), thinking-marker stops truncated mid-thought at arbitrary points, and narrow max_tokens cut off long reasoning before conclusion.

Iteration 2 (current, variant C): Removed presence_penalty and frequency_penalty entirely. Removed the four thinking-marker stop sequences. Widened repeat_last_n to 1024 to avoid penalizing constructive repetitions within long thinking blocks. Strengthened repeat_penalty to 1.15 as the primary loop-prevention mechanism. Raised per-variant max_tokens to 12288/8192/4096/2048 to give reasoning room to complete naturally. The result is fewer truncated responses and no increase in observed loop frequency.

Reasoning effort — when to pick what

The model supports max, but two practical constraints shape what’s exposed:

1. The OpenAI-compatible API surface used here has no max value — only low / medium / high.
2. Ollama does not currently expose xhigh for this model.

So the OpenCode variants map as:

Recommended use inside OpenCode:

• high — multi-step delegation, architecture review, debugging subtle bugs across files. Use when the orchestrator agent is the one driving.
• medium — sub-agents (backend-developer, frontend-developer, refactorer) doing concrete edits on a known scope.
• low — qa-engineer, code-reviewer, security-auditor on small diffs.
• none — fast inline completions / classification (rarely worth it for a reasoning model).