Topic Guide

OpenCode Local Coding with Qwen and ZINC

OpenCode can use ZINC and Qwen through the same OpenAI-compatible `/v1/chat/completions` API that powers the browser chat UI. The useful setup is local and boring: run ZINC, point OpenCode at localhost, keep tools enabled, set honest context limits, and use the trace proxy while testing coding workflows.

Practical Answer

For OpenCode local coding, run ZINC on a localhost `/v1` endpoint and configure a custom `@ai-sdk/openai-compatible` provider. Use a Qwen-family model with stable thinking and tool behavior, keep `ZINC_TOOL_CALLING` enabled, and start with conservative context/output limits such as 4096/2048. If OpenCode runs on a laptop while ZINC runs on a GPU box, use an SSH tunnel so the OpenCode config still contains only `127.0.0.1`.

When This Page Helps

Use this page when you want a local coding assistant backed by ZINC rather than a hosted API. It is focused on operator setup, not benchmark marketing: provider config, local ports, tool calls, thinking, context budgets, and trace-based debugging.

Status Snapshot

Best current answer
OpenCode works best through ZINC's OpenAI-compatible chat endpoint, with the optional trace proxy in front during compatibility testing.
Reader problem
Users need the exact local-provider shape without leaking private GPU-node addresses or hardcoding machine-specific secrets into a repo.
Main bottleneck
Correct agent behavior depends on tool-call round trips, enough output budget, and enough context for source snapshots. Raw tokens per second is only one part of usability.

Action Plan

  1. Start ZINC locally Run the server on `127.0.0.1`, usually port 9090, and verify `/health` plus `/v1/models` before opening OpenCode.
  2. Configure one provider Use OpenCode's OpenAI-compatible provider config with `baseURL` set to `http://127.0.0.1:9090/v1` or to the local trace proxy.
  3. Keep tools on Do not disable `ZINC_TOOL_CALLING` for coding sessions. ZINC parses model tool calls; OpenCode executes local tools.
  4. Tunnel remote servers If the GPU is remote, forward it with SSH and keep the OpenCode config pointed at localhost. Never publish private hosts, ports, usernames, or model paths.

Operator Checklist

  • Health check first `curl http://127.0.0.1:9090/health` should pass from the same machine that runs OpenCode.
  • Model shape Use a Qwen/ChatML-family coding model when tool calling matters, and keep the `model` id consistent between ZINC and OpenCode.
  • Context budget Set OpenCode `limit.context` at or below the context length ZINC actually has available for the loaded model.
  • Trace locally Use `tools/opencode_trace_proxy.mjs` when diagnosing repeated reads, malformed tool paths, short answers, or thinking/tool-choice behavior.

What Matters

  • Use `/v1/chat/completions`; it is the endpoint with streaming, thinking, and tool-call support.
  • ZINC never executes tools. OpenCode executes tools locally and sends tool results back to ZINC.
  • Thinking mode is a request setting; the trace proxy can force it when the client does not expose a direct toggle.
  • A localhost SSH tunnel is the safest way to use a remote GPU box from a laptop without leaking private infrastructure.

What To Measure

Tool-call success
The key coding metric is whether OpenCode can read, edit, write, run tests, and incorporate tool results in the next turn.
First useful action
Measure how long it takes to produce the first correct read or edit tool call, not only final answer latency.
Context usage
Track prompt tokens, visible source snapshots, and output budget so local runs fail predictably instead of silently truncating.
Trace deltas
Compare direct ZINC requests against proxy traces to see whether failures come from model output, client behavior, or compatibility repair.

Common Traps

  • Publishing private endpoints Do not paste GPU-node IPs, SSH ports, usernames, raw model paths, API keys, or trace files into docs, commits, screenshots, or public issues.
  • Using raw completions OpenCode needs chat completions and tool semantics. `/v1/completions` is not the right endpoint for agentic coding.
  • Undersizing output A tiny output cap can look like model failure because the response stops before the tool call or final summary is complete.

Useful Next Posts

  • Local coding agent smoke test A small reproducible project where OpenCode must read files, patch a bug, and run tests against ZINC.
  • Tool calling on Qwen in practice Show the exact request, generated `<tool_call>`, structured OpenAI response, and follow-up tool-result prompt.
  • Which Qwen model for local OpenCode Compare Qwen3.6 35B-A3B, Qwen3.6 dense, and smaller Qwen targets for local coding latency, tool-call quality, and context headroom.
  • Remote GPU, local editor A security-focused walkthrough for SSH tunnels, localhost configs, traces, and avoiding credential leaks.

Run It

Common Questions

Can OpenCode use ZINC as a local model backend?

Yes. Configure OpenCode with an OpenAI-compatible provider whose base URL points at the ZINC `/v1` endpoint, usually `http://127.0.0.1:9090/v1` or a local trace proxy.

Which Qwen model should I use for OpenCode local coding?

Start with a Qwen/ChatML-family model because ZINC validates thinking and tool calling on that template family. Use a smaller Qwen model for setup tests and a larger Qwen3.6 target when you have enough memory and want better coding behavior.

Should I expose the GPU server directly to OpenCode?

Usually no. Keep ZINC bound to localhost on the GPU machine and use an SSH tunnel from the OpenCode machine. The committed config should still contain only localhost URLs and environment placeholders.

Does ZINC run the tools?

No. ZINC renders tool definitions and returns structured tool calls. OpenCode executes local tools, then sends the tool results back to ZINC in the next chat request.