Run OpenCode with your whole team, in your own cloud

Published August 14, 2026 · by the AQ team

OpenCode is the open source AI coding agent: an MIT licensed harness from the Anomaly team (the people previously known for SST) that runs as a terminal TUI, a desktop app in beta, and IDE extensions, and connects to 75+ model providers plus local models, per its documentation as of August 2026. AQ runs OpenCode in cloud workspaces your whole team shares: the same live terminal, code editor, and app preview, streamed to everyone's browser. Sessions run in tmux on a VM you control, so they survive closed laptops, and each workspace gets its own isolated git worktree, so parallel runs never collide.

This page covers what OpenCode is and how its model access actually works today, how to wire Linear into it over MCP, and what changes when you run it inside AQ instead of on one person's machine.

What OpenCode is, and why teams pick it

OpenCode's defining trait is that it is not tied to one model vendor. Its documentation, as of August 2026, describes support for 75+ LLM providers through the AI SDK and Models.dev, plus local models served by tools like Ollama and LM Studio through OpenAI-compatible endpoints. You can switch models mid-session, and configuration lives in a versionable opencode.json file at the project root, which makes team-wide conventions easy to commit alongside the code.

The harness itself is featureful in ways that matter for real work:

• Primary agents and subagents. OpenCode ships a full-access "build" agent and a read-by-default "plan" agent you cycle with the Tab key, plus built-in subagents (general, explore, scout) that the primary agent can invoke for multi-step or research work. Custom agents are plain markdown files in .opencode/agents/, so a team can define and version its own.
• Permissions. Tool access is configurable per agent as allow, ask, or deny, gating file edits, shell commands, and web access.
• Headless mode. opencode run "prompt" executes non-interactively and streams to stdout, which is how people script it in CI or batch jobs.
• Session sharing. A /share command generates a public read-only link to a conversation transcript, updating as the session progresses. It shares the conversation, not the terminal: viewers see prompts, responses, and tool calls, but they cannot type into the session.
• MCP servers. Local and remote MCP servers are first-class in config, with OAuth handled automatically for remote servers that support it. That is the doorway for Linear, covered below.

Model access in OpenCode, as of August 2026

Because OpenCode is a third-party harness rather than a model vendor's own CLI, how you pay for models is the detail worth getting right, and it changed this year. As of August 2026:

• OpenAI models support browser-based sign-in with a ChatGPT Plus or Pro subscription, and manual API keys also work, per OpenCode's documentation.
• Anthropic models run on a metered Anthropic API key. Anthropic's terms do not permit Claude Pro and Max subscriptions to be used through third-party harnesses (a policy it enforced broadly in April 2026), and OpenCode's documentation notes it no longer bundles the subscription sign-in. The models remain fully supported; the billing path is the API.
• OpenCode Zen is the project's own optional gateway: a curated, benchmarked list of 60+ models billed pay-as-you-go per request, with team spending caps. It is one /connect and an API key, useful when you want several frontier models behind a single bill.
• Local models work by pointing a provider at a local OpenAI-compatible endpoint, so nothing has to leave your network at all.

The practical upshot for a team: budget OpenCode as metered usage (provider keys or Zen), except where a ChatGPT subscription covers it. If part of your team prefers subscription-covered Claude, the supported path for that is Anthropic's own Claude Code CLI, and there is no reason to choose: both are just CLIs, and they can run side by side.

Connect Linear to OpenCode over MCP

Linear ships an official hosted MCP server, so OpenCode can read and update issues without any local install. Add it to your project's opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "linear": {
      "type": "remote",
      "url": "https://mcp.linear.app/mcp",
      "enabled": true
    }
  }
}

On first use, OpenCode's OAuth support opens a browser window to authorize your Linear workspace, then reuses the credential. If you want the agent to read issues but never touch them, Linear also hosts a read-only variant at https://mcp.linear.app/mcp/readonly. From there, prompts like "read ENG-142 and implement it" or "comment your plan on the issue" work directly. The same server works across harnesses, so the setup notes in connecting Linear to Codex and adding Linear MCP to Claude Code translate almost verbatim.

What running OpenCode in AQ adds

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. OpenCode single-player is excellent. What AQ adds is everything that starts to matter the moment more than one person cares about the work:

• Always-on sessions. OpenCode runs in tmux on the workspace VM, not on your laptop. Close the lid, switch devices, lose Wi-Fi: the run keeps going, and the full scrollback is waiting when you come back, from any device.
• A live terminal, not a transcript. OpenCode's own /share gives read-only conversation links. An AQ workspace streams the actual tmux session: a teammate opens the workspace and sees the same live terminal, editor, and running preview. Typing into someone else's terminal is delegated: the owner approves a control request in one click and keeps their own input.
• Parallel sessions without collisions. Every workspace is an isolated git worktree on the same repository (branch ai/{id}-{slug}, dependencies installed automatically, one-click rebase onto main), so five OpenCode sessions work five tasks with zero conflicts. (Why worktrees: git worktrees for AI coding agents.)
• Previews people can react to. Each workspace can serve its dev server on a shareable link that works without an account for viewing, and comments pinned on the preview can be sent to the agent as prompts (teammates can attach screenshots; outside reviewers comment through a review link after a quick email sign-in).
• Work arrives from Linear. Beyond MCP, AQ has native Linear intake: label an issue "ai-task" and a workspace appears in the team sidebar, ownership follows the assignee, and status syncs both ways. A human starts the agent; nothing auto-launches.
• PRs tracked per workspace. OpenCode commits, pushes, and opens pull requests with your own GitHub sign-in, and AQ records opened, merged, and closed PRs against the workspace.

How setup works

Create a workspace (from a prompt, a branch, or a Linear issue), open its terminal, and install OpenCode with the standard one-line installer, exactly as you would on any Linux box. Sign in to your providers with OpenCode's own /connect flow, once per user: your keys and accounts, on your team's VM, with AQ never marking up or reselling model usage. On the Free plan agents run on a personal sandbox machine AQ creates for you in an isolated network; on the Team plan they run on VMs you connect from your own cloud or on a dedicated always-on AQ-managed VM. Teammates who open the workspace join the same session with nothing to install.

What AQ deliberately does not change

AQ is a harness, not a fork. The OpenCode inside an AQ workspace is the unmodified CLI in a real terminal: your opencode.json, your custom agents, your MCP servers, your provider logins. When the OpenCode team ships a feature, you have it the moment the CLI updates. And if you leave AQ, the workflow ports out cleanly, because it was always just OpenCode, git worktrees, and tmux.

OpenCode alongside every other agent

AQ is agent-agnostic: the same workspace model runs Claude Code, Codex, Cursor Agent, Kimi, Grok, and plain shells. Teams use that for side-by-side comparisons (same task, OpenCode with one model in one worktree, Claude Code in another) and for mixing billing models: subscription-covered agents where a subscription exists, OpenCode with metered keys or local models where flexibility wins.