nishal77/opencode

1. This is a Bun/TypeScript monorepo for OpenCode: a local AI coding agent with multiple user surfaces, shared domain libraries, a typed HTTP API, and separate cloud services for auth, billing, sharing, and analytics. The main architectural center is the agent runtime plus its session/tool/provider model.

2. packages/core is the domain kernel. It owns the canonical definitions for sessions, tools, prompts, permissions, providers/models, filesystem/git/project behavior, config parsing, database schemas/migrations, and effect-based runtime primitives. Most other packages depend on this layer rather than duplicating business logic.

3. packages/opencode is the main product/runtime assembly. It combines CLI commands, the interactive TUI, session processing, LLM orchestration, plugin loading, workspace/bootstrap logic, sync, storage, and the local HTTP API server into the end-user executable.

4. packages/llm is the provider/protocol adapter layer. It normalizes differences between OpenAI, Anthropic, Gemini, Bedrock, Cloudflare, OpenRouter, xAI, GitHub Copilot, and other providers, including streaming and tool-call behavior, into one internal model that OpenCode can consume consistently.

5. The user-facing surfaces are split by interaction mode: packages/tui for terminal UX, packages/desktop for the Electron app, packages/app for the larger SolidJS app, and packages/ui as the shared component/theme library. These clients mostly render state and send actions into the local runtime/API boundary.

6. The core data flow is: user prompt/input → session processor/runner → model provider request → tool execution → persisted events/messages → UI projections. Tool results can mutate files, run shell commands, query LSP/MCP integrations, or emit structured outputs, and those changes are reflected back through session views, timelines, and sync streams.

7. packages/server is a typed HTTP boundary over the domain model. Its route groups are organized by feature area—agent, session, filesystem, model, provider, pty, permission, question, reference, project-copy, integration, and health—with middleware for authorization, schema validation, and session/location scoping.

8. Plugins and integrations are intentionally isolated. packages/plugin exposes the v2 effect-based plugin API, while OpenCode’s own runtime has plugin loaders, host adapters, and workspace adapters. MCP servers, IDE/LSP support, Git integration, and provider-specific extensions are all treated as pluggable capabilities at the edges.

9. Persistence is split between local embedded state and service-side databases. Core/opencode carry Drizzle-backed schemas and migrations for sessions, workspaces, credentials, events, and permissions; the console/stats services have their own databases and ingestion paths for usage and analytics. Long-lived state is therefore shared by schema, but separated by deployment target.

10. The cloud/control-plane side lives mainly in packages/console, packages/enterprise, and packages/stats. Console handles auth, billing, model proxying/rate limiting, and usage batching; enterprise hosts share views and APIs; stats ingests telemetry and serves analytics. The infra/ modules wire these services into SST-managed deployments.

11. packages/web is the documentation and marketing site, built with Astro/Starlight and multilingual content. packages/sdk/js is the generated OpenAPI-based client/server SDK that external consumers and internal tools use to talk to the same APIs as the built-in apps.

12. Cross-cutting tooling is substantial: Storybook supports the UI library, Playwright and recorded integration tests cover the app surfaces, Electron Builder packages desktop, and GitHub Actions plus release scripts drive publishing. These tools reinforce the same package graph rather than introducing separate architectural tiers.