xiaomimimo/mimo-code

1. This is a TypeScript/Bun monorepo organized around one core product runtime and several adjacent surfaces. The main execution engine lives in packages/opencode, while packages/app, packages/desktop, packages/web, packages/console, packages/enterprise, packages/ui, packages/sdk, and packages/plugin provide alternate clients, cloud services, documentation, and integrations.

2. The heart of the system is packages/opencode: a terminal-native AI coding assistant. Its top-level flow is: CLI bootstrap → config/env loading → runtime initialization → server/session orchestration → provider calls and tool execution → persistence and resume. The runtime is designed around long-lived sessions, not short request/response cycles.

3. Session management is the core domain layer. packages/opencode/src/session, actor, task, workflow, history, memory, inbox, and share implement the long-horizon agent loop: prompt assembly, LLM request/response handling, checkpoints, compaction, retries, task trees, imports, and sharing. The README’s “persistent memory” and “automatic checkpoints” are backed by this layer.

4. The agent/tool boundary is explicit. packages/opencode/src/tool defines the available capabilities such as shell, file read/write/edit, git, ripgrep/search, LSP, MCP, web fetch/search, memory access, tasks, and workflows. Session code decides when to invoke tools; tool modules encapsulate the concrete side effects and permission checks.

5. Model/provider integration is another major boundary. packages/opencode/src/provider normalizes multiple LLM backends and their auth/model schemas, while packages/opencode/src/plugin adds provider-specific adapters and custom behaviors. This is what allows MiMo Auto, Xiaomi MiMo Platform OAuth, Claude imports, and OpenAI-compatible custom providers to coexist under one abstraction.

6. Persistent state is stored locally and is a first-class subsystem. packages/opencode/src/storage and the SQL schema files under session, memory, task, workflow, sync, and related modules indicate a SQLite-backed store with migrations. Memory and history use FTS-style search and are treated as durable context inputs for future sessions, not just logs.

7. The local UI is split across multiple shells. packages/opencode/src/cli/cmd/tui provides the terminal UI, packages/desktop wraps the same product in an Electron-style desktop shell, and packages/app contains a separate Solid/Vite web app that mirrors much of the session UI. These surfaces all sit above the same core session/service layer rather than reimplementing agent logic.

8. packages/ui is the shared presentation library. It contains reusable components, theming, i18n, and small interaction primitives used by the app/desktop/web surfaces. The architecture boundary here is “visual and interaction components only”; business logic stays in opencode or the product-specific apps.

9. packages/console is the cloud control plane for MiMoCode. It is an Astro/Vite app plus backend route handlers, auth, billing, model/provider management, workspace administration, and public marketing/docs endpoints. Unlike the local agent runtime, this side focuses on account lifecycle, subscriptions, rate limiting, provider routing, and enterprise features.

10. The console’s backend is split into packages/console/core, function, mail, and resource. core contains domain logic and database schema/migrations via Drizzle; function holds serverless helpers such as auth/log processing; mail renders transactional email templates; resource declares cloud resources. External dependencies here materially shape the architecture: OAuth, Stripe webhooks, provider APIs, and rate limit enforcement.

11. Sharing and enterprise distribution have their own surface area. packages/enterprise serves shared session/content views, while packages/opencode/src/share and the web app’s pages/s/[id] route support rendering exported conversations. This is a separate read-only publishing path from the interactive session runtime.

12. Integrations are packaged independently. packages/plugin is the generic plugin package, sdks/vscode is a VS Code extension, and packages/extensions/zed is a Zed integration. These consume the core runtime contracts but remain outside the local CLI/session implementation.

13. The documentation and public website are separate from the product runtime. packages/web is the Astro-based docs/marketing site with multilingual content, while packages/console/app also serves product-facing pages and docs routes for the cloud service. These sites are content-heavy and mostly consume shared share-rendering components rather than core agent logic.

14. Cross-cutting build and deployment concerns are centralized in the repo root. sst.config.ts, infra/, and the various script/ and packages/*/script directories orchestrate cloud deployment, releases, code generation, and packaging. The repo uses Bun, Turborepo, Vite, Storybook, Playwright, and extensive tests to keep the local runtime, cloud control plane, and UI surfaces aligned.