How to Use DeepSeek with OpenCode

OpenCode can use DeepSeek directly as the model provider behind its coding agent. For the current setup, install OpenCode V2, create a DeepSeek Platform API key, run OpenCode inside your project, select DeepSeek through /connect, and choose the current DeepSeek model through /models.

For a direct DeepSeek connection, you do not need an OpenCode Go subscription or an MCP server. OpenCode sends model requests to the official DeepSeek API, and DeepSeek bills the resulting token usage to your DeepSeek Platform account.

Last reviewed: October 16, 2026. This guide targets OpenCode V2, with V2.0.30 as the release reference, and the current direct DeepSeek API. The instructions were checked against the documentation; they are not a claim that an authenticated DeepSeek request was executed for this review.

Important distinction: This guide explains how to make DeepSeek the language-model provider that powers OpenCode. It does not cover a DeepSeek-named MCP server, a third-party automation platform, OpenCode Go, OpenRouter, or a locally hosted DeepSeek model.

DeepSeek with OpenCode: the setup in six steps

1. Check that you are running OpenCode V2.
2. Create a DeepSeek API key and make sure the account can pay for API usage.
3. Open a terminal in your project and start OpenCode.
4. Run /connect, select DeepSeek, and enter the API key.
5. Run /models and select deepseek/deepseek-flash.
6. Apply the permission settings below, then verify the provider, model, and an inspection-first request in a disposable repository.

No manual provider definition should be necessary for this normal setup because DeepSeek is included in OpenCode’s provider catalog.

Check your OpenCode version before configuring DeepSeek

Check the installed version before changing any configuration:

opencode --version

The OpenCode changelog lists V2.0.30, released October 15, 2026, as the latest release visible at this review. The examples below use native V2 syntax. Recheck the release notes when updating rather than assuming an older version remains current.

This version check matters because the short DeepSeek OpenCode integration guide still refers to OpenCode 1.18.30 or later and uses the older display name DeepSeek-V4-Flash. Its basic connection sequence—start OpenCode, run /connect, choose DeepSeek, and enter a key—is still useful, but new installations should use current OpenCode V2 commands, configuration fields, and model IDs.

Native V2 examples use providers, package, settings, permissions, shell, and subagent. Older examples can use different names. However, the current migration guide says supported V1 configuration is normalized automatically; conversion to native V2 is optional. Do not label every V1 field broken. Keep each nested provider, model, agent, or command entry internally consistent, and review warnings for unsupported fields.

If opencode --version reports V1, review the official V1-to-V2 migration guide. V1 and V2 both use the opencode command and are not installed side by side under that default name. OpenCode recommends removing a package-managed V1 installation before installing V2; the V2 curl installer can replace a V1 binary installed through the earlier curl method.

Install or update OpenCode

Install OpenCode on macOS or Linux

The primary V2 installation command is:

curl -fsSL https://opencode.ai/v2/install | bash

Homebrew users can install the V2 formula instead:

brew install anomalyco/tap/opencode-v2

Another official option is the current npm package:

npm install -g @opencode/cli

Use one installation method consistently. Installing the same command through several package managers can leave an older binary earlier in your PATH.

The curl command downloads a script and immediately executes it. In a managed environment, download and review the official installer before running it, or use an approved package-manager route. Do not run an installer with elevated privileges merely because a tutorial suggests it.

Install OpenCode on Windows

The V2.0.28 release notes document official WinGet packages. For the Windows CLI, use:

winget install --id Anomaly.OpenCode -e

For the separate desktop application, the documented package is:

winget install --id Anomaly.OpenCode.Desktop -e

There is a documentation mismatch: the V2 startup page still says Windows package managers are unsupported, while the dated release notes announce WinGet support. The commands above follow the release notes. Alternatively, use the startup page’s x64 or ARM64 standalone CLI, extract opencode.exe, and add its directory to PATH. Avoid installing the same CLI through multiple routes.

Open a new PowerShell or terminal window after changing PATH, then verify the binary:

opencode --version

Update an existing V2 installation

OpenCode V2 documents the following upgrade command:

opencode upgrade
opencode --version

If the upgrade command reports that it cannot determine the installation method, update OpenCode through the same package manager or download route used for the original installation.

An installed update does not necessarily restart the shared server. Save active work and restart OpenCode’s service when needed to activate the new version; that service can be shared by several local clients.

Create a DeepSeek API key and check billing

Sign in to the DeepSeek Platform, open the API Keys page, and create a key for OpenCode. Copy it when it is displayed and store it in a password manager or another approved secret-management system.

If you need help creating or rotating the credential, follow our DeepSeek API key guide.

A direct API key is separate from access to the consumer DeepSeek chat application, an OpenCode Go subscription, or an OpenCode Zen gateway account. DeepSeek charges the direct API account according to the selected model and its token usage.

Check the DeepSeek account’s balance before troubleshooting the integration. The official error documentation defines HTTP 402 as insufficient balance, so a syntactically valid key can still fail when the account cannot fund the request.

Do not put the key in a project file. Avoid adding it to opencode.jsonc, AGENTS.md, source code, screenshots, shell commands, shared logs, or Git commits. The normal /connect flow prompts for the secret interactively.

The V2 provider documentation says saved API keys and OAuth tokens live in the local server’s SQLite database. Print its actual path with:

opencode debug paths db

The usual local path is ~/.local/share/opencode/opencode.db, but release channels, XDG settings, and the OPENCODE_DB variable can change it. Do not edit the database manually to add, rotate, or remove a credential; use OpenCode’s provider commands.

How to connect DeepSeek to OpenCode

Open a terminal in the repository you want OpenCode to work with:

cd /path/to/your/project
opencode

The first line above represents your own project path. The second starts the OpenCode terminal interface.

Inside the OpenCode interface—not in the normal shell—enter:

/connect

1. Search for DeepSeek.
2. Select the official DeepSeek provider.
3. Choose the API-key authentication method if OpenCode presents more than one method.
4. Paste the DeepSeek API key into the protected prompt.
5. Complete the connection and return to the session.

You can perform the same interactive provider login without opening the full TUI:

opencode auth login deepseek

The command opens the available DeepSeek authentication methods. Using the picker is safer than assuming that a method ID from another provider applies to DeepSeek.

Select the current DeepSeek model

After connecting the provider, enter this command inside the OpenCode interface:

/models

Choose the DeepSeek entry displayed by /models, checking its provider and API identifier rather than relying on a display name. The direct Models.dev catalog includes deepseek-flash; use this OpenCode model reference for the Flash setup:

deepseek/deepseek-flash

The part before the slash is the OpenCode provider ID. The part after it is the DeepSeek model ID. The corresponding model is DeepSeek V4.1 Flash.

Flash is a reasonable starting point for this guide, not a claim that it is best for every repository. DeepSeek’s current model table documents tool calling, reasoning, and image input for deepseek-flash. Model capabilities still depend on what the client and selected integration can use.

Do not use deepseek-v4-flash or deepseek-v4-flash-vision-exp in a new configuration. DeepSeek still accepts those legacy aliases, but the corresponding models have been retired and their requests are routed to V4.1 Flash. Using deepseek-flash avoids depending on a compatibility alias.

The same direct catalog also lists deepseek-v4-pro, referenced in OpenCode as deepseek/deepseek-v4-pro. It remains a separate API option with its own rates; it is not another name for Flash. Pro is text-only in the current official table. Select it through the picker only when its behavior and cost fit your task.

If OpenCode shows a model variant after the main model ID, select only a variant listed by the current picker. Do not add values such as #high from another provider unless OpenCode currently exposes that variant for the selected DeepSeek model.

Verify that OpenCode is actually using DeepSeek

Saving a key is not proof that an API call succeeded. Before the first model request, use a clean, disposable repository with no real secrets, apply the permission policy, and leave auto-accept disabled. The first request can incur DeepSeek API charges and send the selected repository context to DeepSeek.

1. Confirm the provider account

opencode auth list

The output should contain a saved or active DeepSeek connection. If several DeepSeek accounts are present, make sure the intended account is active.

2. Confirm the model is available

opencode models

Find deepseek/deepseek-flash in the output. OpenCode’s model selector shows only enabled models whose providers are available in the current project, so a missing entry usually points to a provider, credential, catalog, or project-configuration problem.

3. Run an inspection-first request

From the disposable project directory, specify the Plan agent and model explicitly. The prompt below asks for inspection only; it is not a permission boundary:

opencode run --agent plan --model deepseek/deepseek-flash "Use file-reading tools to inspect this disposable repository. Do not edit files, run shell commands, or delegate to another agent. Report the primary programming language and the build and test commands documented in the repository. Do not execute them. Say when a command cannot be verified."

Plan restricts ordinary file edits, but it is not an operating-system read-only mode. Shell and delegated tools have separate permissions. If the non-interactive run needs an approval it cannot obtain, use the same prompt in an interactive Plan session and review or reject the requested action; do not enable blanket approval just to finish the test.

A successful verification has four parts:

• DeepSeek appears in opencode auth list.
• deepseek/deepseek-flash appears in opencode models.
• The inspection request returns a repository-specific response without unauthorized actions.
• The active session identifies the intended DeepSeek model rather than another provider.

You can also check the DeepSeek Platform’s usage or balance records after the request. Provider-side usage is a useful secondary confirmation that the call reached the intended DeepSeek account.

Set DeepSeek as the default OpenCode model

Selecting a model through /models changes the current session. To make DeepSeek the project default, add or update the root model field in your existing opencode.jsonc. This minimal example shows only the model setting; do not replace an existing permission policy or unrelated settings with it:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "deepseek/deepseek-flash"
}

Reload the OpenCode configuration:

opencode reload

The configured model is the default for new work when it is enabled and its provider is available. A model already selected for an existing session takes precedence, and changing opencode.jsonc does not rewrite that session’s saved selection. Start a new session or select the model again when testing a changed default.

Project files can be opencode.json, opencode.jsonc, or the equivalent files under .opencode/. Global configuration is normally under ~/.config/opencode/. Project settings can override global settings, while system-managed settings have higher precedence. Inspect configuration locations and precedence and run opencode debug config instead of assuming the file you edited is the final authority.

Add project instructions with AGENTS.md

Use AGENTS.md to supply the repository’s real build, test, architecture, and review instructions. This gives OpenCode explicit project guidance; it does not replace enforceable tool permissions.

For a Node.js repository, a practical starting file could be:

# Project instructions

- Use npm for dependency and script commands.
- Read the relevant implementation and tests before proposing a change.
- Prefer the smallest change that satisfies the request.
- Follow the existing naming, formatting, and error-handling conventions.
- Do not add or upgrade dependencies without explicit approval.
- Do not edit generated files, lockfiles, migrations, CI configuration, or environment files unless the task specifically requires it.
- Validate code changes with `npm test` and `npm run lint`.
- Report every changed file, every verification command run, and any unresolved risk.
- Never push commits or rewrite Git history.

Replace the npm-specific commands with the repository’s real documented commands when the project uses another language or package manager. Do not give the agent a test command that does not exist merely to make the instruction file look complete.

Commit repository-level instructions so other contributors and OpenCode sessions receive the same guidance. OpenCode can combine a global AGENTS.md with files at the repository and nested-directory levels.

V2 recognizes AGENTS.md, not an automatic CLAUDE.md fallback. The current instruction-loading documentation distinguishes updates: global and upward-discovered instruction files can refresh before the next model request, while nested files discovered during exploration are not automatically refreshed after loading. Start a new session when a changed nested file must apply immediately or its loaded state is unclear.

Complete a safe first coding task

Apply the permission policy before starting repository work. Keep the first task small, work in a disposable or approved development environment, and follow a plan-review-build sequence rather than requesting a broad refactor.

1. Inspect the Git state

git status --short

Resolve or preserve unrelated local changes before giving an agent write access. Work on an appropriate branch according to the repository’s normal workflow.

2. Start with the Plan agent

OpenCode V2 includes two visible primary agents:

• Plan: restricts edits to normal project files but can write its own plan files. Shell commands remain governed by their separate permissions.
• Build: the default coding agent, with tools available according to the configured permissions.

Switch to Plan through the agent selector or the configured agent-switch key, then use a bounded request such as:

Find where user-facing display names are validated. Do not edit files. Propose the smallest change that rejects names containing only whitespace without changing behavior for valid names. Identify the relevant tests, acceptance criteria, and any compatibility risk.

Review the returned file references and plan. Ask the agent to correct assumptions before allowing any edit.

Do not treat the Plan label or an AGENTS.md instruction as isolation. A child agent uses its own configured permissions, not a guaranteed subset of its parent’s. Review enabled agents and integrations before approving delegation.

3. Switch to Build for the approved change

Implement the approved display-name validation plan. Change only the files needed for this behavior, add or update focused tests, run the repository's existing relevant verification commands, and stop if the repository instructions conflict with the plan.

Review each proposed shell command and any request to access a sensitive file. Do not approve an operation merely because it was generated by the same model that produced the plan.

4. Inspect the resulting patch yourself

git diff --check
git diff

Then run the repository’s documented tests, formatter, linter, type checker, or build command. A model’s statement that tests passed is not a substitute for reviewing the actual command and its output.

Finish by asking OpenCode for a concise handoff:

Summarize the changed files, the reason for each change, every verification command actually run, any failed or skipped check, and the remaining risks. Do not make additional edits.

Restrict shell commands and secret access

Use this conservative starting policy for the direct DeepSeek setup. It has no automatic shell-command allow rules, blocks commands matching git push *, requests review for external-directory and grep checks, and restricts environment-file access through the read and editing tools. Back up the existing configuration and merge these rules; do not create duplicate permissions keys.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "deepseek/deepseek-flash",
  "permissions": [
    {
      "action": "shell",
      "resource": "*",
      "effect": "ask"
    },
    {
      "action": "shell",
      "resource": "git push *",
      "effect": "deny"
    },
    {
      "action": "external_directory",
      "resource": "*",
      "effect": "ask"
    },
    {
      "action": "grep",
      "resource": "*",
      "effect": "ask"
    },
    {
      "action": "read",
      "resource": "*.env",
      "effect": "deny"
    },
    {
      "action": "read",
      "resource": "*.env.*",
      "effect": "deny"
    },
    {
      "action": "read",
      "resource": "*.env.example",
      "effect": "ask"
    },
    {
      "action": "edit",
      "resource": "*.env",
      "effect": "deny"
    },
    {
      "action": "edit",
      "resource": "*.env.*",
      "effect": "deny"
    },
    {
      "action": "edit",
      "resource": "*.env.example",
      "effect": "ask"
    }
  ]
}

The .env.example exceptions require review too: a filename is not proof that a file contains only dummy values. Extend the path rules to the secret-bearing files in your project, but do not describe this example as a complete secret scanner.

Why git diff is not automatically approved

The Git diff reference documents --output=<file>, which writes the diff to a file. Therefore, a wildcard such as git diff * also covers operations that write output; it is not a read-only guarantee. Review the full command, arguments, working directory, and any redirection before approving it. This guide leaves both git diff and git status under the shell approval rule rather than publishing a broad automatic exception.

Check the effective policy, not just this JSON

OpenCode uses ordered permission rules: the last match wins. Saved Allow always approvals can satisfy an ask, though they do not override a configured deny. Remove old broad approvals, keep auto-accept off, and prefer Allow once during testing. Later agent rules also matter; review each permitted subagent separately.

Before the first request, inspect the configuration sources and agent definitions, then reload your changes:

opencode debug config
opencode debug agents
opencode reload

Use those diagnostics with the client’s permission settings to review the active project; their output alone does not prove that no saved approval exists. The git push * denial is pattern-specific, not a complete remote-write firewall. Other command forms still need review. Organizations needing centrally enforced restrictions should use the documented managed policy controls and appropriate host restrictions.

File-tool restrictions are not a sandbox

The tool reference assigns separate permission checks to reads, edits, searches, and shell commands. In particular, grep matches the requested search expression rather than a filename, so a read denial for .env must not be described as a universal search exclusion. Review search scope as well as returned content.

Shell runs with the host user’s filesystem, process, and network access. An approved command or external tool can expose data through a different route. Keep real secrets out of the test workspace; use a restricted account or properly isolated environment with limited mounts, credentials, and network access when stronger protection is required. These JSON rules, Plan mode, and prompt instructions are not operating-system isolation.

Who charges you for this setup?

With the direct setup in this guide, DeepSeek supplies the model and bills the DeepSeek Platform account. OpenCode provides the local coding-agent interface and sends requests directly to the configured provider.

An OpenCode Go or Zen purchase is not required for this route. Those are separate OpenCode-operated model-access options with their own credentials, model catalogs, billing arrangements, and privacy terms.

DeepSeek pricing is token based and can differ by model, input cache status, output tokens, and peak or off-peak time. Check the current official DeepSeek models and pricing page rather than copying a price from an older setup guide.

OpenCode can report local usage information:

opencode stats --models
opencode stats --cost

Use these reports for local visibility, but treat the DeepSeek Platform balance and billing records as the authority for the amount charged by DeepSeek. Our DeepSeek API billing guide explains balance checks and usage reconciliation.

What code and data are sent to DeepSeek?

In this local direct-provider setup, OpenCode runs the client, server, and file tools on your computer. Its local-server documentation describes locally managed sessions, configuration, permissions, and tool execution; saved credentials also remain in the local database. Do not interpret privacy-oriented product messaging as a promise that your machine keeps no session data.

That does not mean your project remains entirely on your computer. When DeepSeek is the selected provider, the prompts, file excerpts, instructions, tool results, and other context OpenCode includes in a model request are transmitted to DeepSeek. OpenCode does not necessarily upload the entire repository automatically, but any material added to the model context has left the local machine.

DeepSeek’s privacy policy, last updated February 10, 2026, states that its services may collect user inputs such as text, prompts, uploaded files, feedback, and chat history. It also describes use of personal data to provide, improve, and train its technology, provides a right to opt out of certain training use, and states that collected personal data may be processed and stored in the People’s Republic of China. For a fuller review of these terms, see our DeepSeek privacy policy explanation.

Before using DeepSeek with confidential, regulated, customer-owned, or proprietary source code:

• Review DeepSeek’s current privacy policy, terms, and any applicable API-specific agreement.
• Confirm that the provider and data location are permitted by your organization.
• Remove secrets, production records, credentials, and unnecessary personal data from model context.
• Restrict access to .env and other secret-bearing files.
• Use an approved internal gateway or local model instead when policy prohibits direct external processing.

The V2.0.30 release notes remove the retired session-sharing backend and unavailable /share command. That does not eliminate exposure through provider requests, exports, remote access, or optional integrations; review those separately.

Troubleshoot the OpenCode DeepSeek integration

For background-service problems, use these non-destructive diagnostics:

opencode service status
opencode api get /api/info
opencode debug config
opencode debug paths

If the service is confirmed to be stuck, restart it:

opencode service restart

Do not begin troubleshooting by deleting the OpenCode database or every configuration file. Those actions can remove useful state without identifying whether the problem is the client, background server, current project, provider account, or model catalog.

For provider-side HTTP failures, use our DeepSeek API error-code guide; reinstalling OpenCode does not resolve an invalid key or an unfunded DeepSeek account.

Rotate or remove the DeepSeek connection

List the saved provider accounts:

opencode auth list

To rotate the key safely:

For routine rotation, verify the replacement before removing the old connection. If the key is suspected to be exposed, revoke it immediately rather than keeping it active for a seamless handover.

1. Create a new key in DeepSeek Platform.
2. Add it through /connect or opencode auth login deepseek.
3. Make the new account active and run an explicit test with deepseek/deepseek-flash.
4. Revoke the old key in DeepSeek Platform only after the new connection succeeds.
5. Remove the old OpenCode account through the provider account picker.

The CLI commands can open interactive account pickers when identifiers are omitted:

opencode auth switch
opencode auth logout

You can also run /connect again, select an already connected provider, and activate, rename, or delete one of its saved accounts.

Removing a saved OpenCode account is not the same as revoking its API key in DeepSeek Platform. If authentication is supplied through a server environment variable instead of a saved account, remove that environment setting as well; auth logout does not unset it.

To stop making DeepSeek the default without removing its credential, delete or replace the root model value in the relevant opencode.jsonc, run opencode reload, and select the desired provider through /models.

Direct DeepSeek API versus other OpenCode routes

These routes are not interchangeable. A model with “DeepSeek” in its display name may have different versions, tool support, context limits, prices, availability, and privacy terms depending on the provider serving it.

For the separate local-runtime route, start with our guide to running DeepSeek locally. Its hardware and runtime instructions do not replace the hosted-provider setup on this page.

Final verification checklist

• opencode --version reports OpenCode V2.
• The DeepSeek API key was entered through the provider flow, not committed to the repository.
• opencode auth list shows the intended DeepSeek account.
• opencode models includes deepseek/deepseek-flash.
• An inspection-first Plan request succeeds with the intended model and without unauthorized actions.
• The project default in opencode.jsonc is correct, if a default is needed.
• AGENTS.md contains real build, test, convention, and safety instructions.
• The first task begins in Plan and moves to Build only after review.
• The permission policy, saved approvals, auto-accept settings, and enabled agents have been reviewed; broad Git wildcards are not treated as read-only guarantees.
• The Git working tree and final diff are reviewed by a human.
• Actual test output is checked rather than accepting the agent’s summary alone.
• The DeepSeek balance, pricing, privacy policy, and organizational data rules have been reviewed.

Sources checked

The following documentation and catalog pages were reviewed on October 16, 2026. OpenCode release notes are dated separately from this article’s review date.

• OpenCode V2 installation and startup documentation
• OpenCode V2 provider configuration
• OpenCode V2 model selection and defaults
• OpenCode V2 provider authentication and credential storage
• OpenCode V2 built-in agents
• OpenCode V2 permission rules
• OpenCode V2 AGENTS.md instructions
• OpenCode V1-to-V2 migration guide
• OpenCode changelog
• Models.dev DeepSeek provider catalog
• Official DeepSeek OpenCode integration guide
• Official DeepSeek models and pricing documentation
• Official DeepSeek API error codes
• DeepSeek privacy policy
• OpenCode V2 configuration and precedence
• OpenCode V2 command reference
• OpenCode V2 tool permission boundaries
• OpenCode V2 managed policies
• Git diff options, including file output