Skip to content
Direct Inference

Coding agents & orchestrators

Agentic coding tools — OpenCode, Cline, Roo Code, Continue, Goose, Kilo Code, Zed, Aider, Crush — run on DirectInference the same way your application does: one base URL, one llm_live_… key, any model id. The difference from a plain SDK swap is that these tools don’t model an endpoint as “a base URL and a key.” They model it as a provider with per-model settings, and they decide what a model is allowed to do — call tools, stream reasoning, accept images — from the model id. The id di-fusion is new to them, so you turn those capabilities on yourself. This page has the exact block to paste for each tool.

Why these tools need a little more

Section titled “Why these tools need a little more”

A tool’s “does this model support tools / reasoning / vision?” answer normally comes from a built-in catalog keyed by model id (models.dev, a bundled allowlist, or name-matching). DirectInference exposes one model — di-fusion — and it is on no tool’s catalog, so for an unknown id those capabilities can default off. With DirectInference, capability is a property of the request shape, not the model id: send tools and they are served; send an image and it is served as a vision request. So the rule for every tool below is the same — when it offers a tool / reasoning / vision switch or a per-model capability field, turn it on, and give it a context-window number so its prompt budgeting works.

Which id to use

Section titled “Which id to use”

There is one model; the id is a label that is read as intent and echoed back unchanged. Use whichever fits the slot:

IdUse it for
di-fusionThe default. The single model, effort chosen automatically per request.
di-saverA tool’s small / background / weak slot (titles, commit messages, summaries) — effort pinned low.
di-maxA tool’s large / main slot for hard work — effort pinned high.

Tools with two model slots (a fast background model and a main model) map cleanly to di-saver and di-max; single-slot tools should use di-fusion.

Per-tool setup

Section titled “Per-tool setup”

Add a provider to opencode.json (project root) or ~/.config/opencode/opencode.json. OpenCode auto-installs the @ai-sdk/openai-compatible package referenced by npm; you do not add it to a package.json.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "directinference/di-fusion",
  "small_model": "directinference/di-saver",
  "provider": {
    "directinference": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "DirectInference",
      "options": {
        "baseURL": "https://api.directinference.com/di/v1",
        "apiKey": "{env:DIRECTINFERENCE_API_KEY}",
        "headers": { "X-Title": "opencode" }
      },
      "models": {
        "di-fusion": { "name": "DirectInference",         "tool_call": true, "reasoning": true,  "attachment": true, "limit": { "context": 200000, "output": 32000 } },
        "di-saver":  { "name": "DirectInference (saver)", "tool_call": true, "reasoning": false, "attachment": true, "limit": { "context": 200000, "output": 16000 } },
        "di-max":    { "name": "DirectInference (max)",   "tool_call": true, "reasoning": true,  "attachment": true, "limit": { "context": 200000, "output": 64000 } }
      }
    }
  }
}

Then export DIRECTINFERENCE_API_KEY=llm_live_… (or run opencode auth login). Enable: tool_call, reasoning, and attachment per model, plus limit — for an unknown id OpenCode otherwise leaves reasoning/vision off and the context at zero. Gotcha: keep npm as @ai-sdk/openai-compatible (not @ai-sdk/openai) so requests go to /v1/chat/completions.

Confirm it’s working

Section titled “Confirm it’s working”

Two signals prove the tool is actually reaching DirectInference and not silently falling back to a previous provider:

  1. The model echo — responses carry back the exact id you configured (di-fusion).
  2. The header — every DirectInference response carries X-DI-Request-Type (pro, code, vision, document, long, json, reason, or flash). It is the one customer-visible signal and only DirectInference sets it. Prove the base URL and key independently of any tool:
Terminal window
curl -s -o /dev/null -D - https://api.directinference.com/di/v1/chat/completions \
  -H "Authorization: Bearer llm_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "model": "di-fusion", "messages": [{ "role": "user", "content": "ping" }] }' \
  | grep -i x-di-request-type
# x-di-request-type: flash

The request also appears in Traces and Usage; set X-Title (where a tool exposes custom headers) to give it its own line in per-application usage. To bias every request the tool sends toward cost or quality, send X-DI-Effort (fast … max) — details in Effort.

Known limitations

Section titled “Known limitations”
  • Computer-use tools are not served. Tools that expose a “Computer Use” toggle (Kilo Code, others) drive a provider’s hosted computer-use tool, which DirectInference does not serve — leave it off. Client-defined function tools and the tools’ own edit/command protocols are fully served.
  • di-fusion is a chat model, not a tab-autocomplete (FIM) model. Where a tool has a separate inline-completion / autocomplete slot, point it at a dedicated completion endpoint rather than di-fusion.
  • Provider server-side tools stay on their origin. Web search / grounding, code execution, and URL context are rejected with a descriptive 400; keep those call sites on their original provider. The full served / not-served list is in Capabilities.

For the field-by-field reference behind any “custom provider” form, see Custom providers; for the underlying SDK swaps these tools are built on, see Frameworks.