OpenCode separates client communication, runtime execution, and model reasoning into distinct layers. The server owns session management, context preparation, tool orchestration, and provider abstraction.
The terminal window is what most developers see when they launch OpenCode. That terminal, the TUI layer, captures prompts, displays responses, surfaces code diffs, and requests approvals. It's also the least interesting part of the system.
OpenCode is an open-source AI execution runtime written in TypeScript. Its architecture separates three things: how clients communicate, how the runtime executes, and how the model reasons. The TUI is one client among many. The same server that serves a developer's terminal session can also serve an IDE extension, a web portal, or an enterprise automation platform.
The server owns everything.
The OpenCode Server exposes an HTTP service defined through the OpenAPI specification. That specification is the contract between every client and the runtime. It describes endpoints for creating sessions, exchanging messages, inspecting projects, and controlling agent execution. Standard HTTP requests initiate operations. Server-Sent Events (SSE) establish a persistent stream that delivers model responses, tool execution results, session updates, and other runtime events back to the client in real time.
Execution state lives inside the server, not in the communication protocol. Each client creates or resumes an explicit session. Conversations, execution history, and agent state persist independently of individual HTTP requests. That separation between communication and execution is the foundation of the architecture.
The pipeline, step by step.
Once a request reaches the server, it enters a pipeline that every task follows, regardless of the client's origin.
Session management creates or resumes sessions, maintains conversation history, tracks execution state, manages permissions, and coordinates the lifecycle of an AI workflow.
Context preparation assembles the provider-ready input. It combines the system prompt, project instructions, conversation history, referenced files, tool results, and runtime state into a single request. It also manages context compaction to stay within the model's context window while preserving the information most relevant to the current task.
The agent execution loop plans the next action, invokes the language model, interprets the response, executes tools when required, observes the results, and repeats until the objective is complete.
Tool execution provides controlled access to the filesystem, shell commands, Git operations, and external capabilities exposed through Model Context Protocol (MCP) servers.
Provider abstraction isolates the runtime from any specific language model provider. It handles provider selection, authentication, request translation, and streaming responses through a unified interface.
The model reasons. The runtime executes.
The server does not perform reasoning. It delegates that to a language model through the Provider Abstraction layer. The same execution pipeline works with Anthropic Claude, OpenAI GPT, Google Gemini, Cloudflare Workers AI, OpenRouter, or self-hosted models. The server prepares the context, invokes the model, processes the response, executes tools when necessary, and continues the agent loop until the task is complete.
This separation lets the reasoning engine evolve independently from the execution runtime. Organizations can evaluate new models, switch providers, optimize for cost or performance, or deploy private models without changing their applications or execution workflows. The language model becomes a replaceable reasoning component. OpenCode remains the stable execution platform.
Context is the real intelligence.
A language model has no inherent understanding of a business, codebase, or engineering practices. It performs stateless inference over the information provided in a single request. Context preparation is the runtime responsibility that assembles that request before every model invocation.
The knowledge itself lives outside the runtime as durable assets: source code, documentation, architecture decisions, project conventions, configuration, and execution history. Context preparation continuously transforms a subset of that knowledge into the execution context consumed by the model. As reasoning models become increasingly interchangeable, architectural value shifts from the reasoning engine to the runtime's ability to construct high-quality context. Better context produces better reasoning, more reliable tool execution, and more consistent outcomes regardless of which language model performs the inference.
Three layers, one architecture.
The key architectural principle is the separation of communication, execution, and reasoning. Clients communicate with the runtime through a stable API. The runtime owns the complete execution lifecycle by managing sessions, preparing context, orchestrating the agent loop, coordinating tools, and maintaining workflow state. The language model contributes only reasoning over the execution context it receives.
Because these responsibilities are isolated behind well-defined interfaces, clients, models, providers, and tools can evolve independently without changing the overall architecture. Traditional systems separated the presentation layer, application server, and database. AI-native systems introduce an AI execution runtime that coordinates every model invocation rather than sending prompts directly to a language model. The model becomes one component of the system. The runtime becomes the platform that orchestrates the complete AI execution lifecycle.
Drafted by a large language model from the source reporting linked above, then screened by automated publishing checks. It is not read by a journalist before publication. Some articles cite our Alpha Score. Verify prices and figures against the original source. Educational coverage, not personalized advice.