Product Matrix

Use this matrix before picking an install route. Wenlan is the source-backed LLM wiki; the daemon/runtime owns behavior, while the CLI, local and remote MCP, Claude Code plugin, Codex plugin, ChatGPT, other clients, and optional desktop app are ways to reach it.

The daemon owns the database, pages, sessions, and retrieval behavior. Client surfaces should be debugged by checking daemon health first, then the client-specific config.

Do not collapse runtime support and desktop app support into one claim. The current product release workflow publishes the runtime for macOS Apple Silicon, Linux x86_64, Linux aarch64 glibc, and Windows x86_64. The optional desktop app release path is narrower and currently targets macOS Apple Silicon.

macOS Intel still has a launchd service model in the code path, but there is no current prebuilt runtime or desktop app target in the public release workflow. Treat that as source/dev-only until a release workflow adds an artifact.

If you are new to Wenlan, start with setup instead of choosing packages by hand. The setup path installs the local runtime under ~/.wenlan/bin, verifies the daemon, and gives MCP clients a stable connector path.

Once setup is green, the daily loop is brief or context at session start, capture when a durable fact appears, recall when history matters, and handoff when a work session should survive the chat.

Use the concept docs when you need to explain memory types, review queues, spaces, source-backed pages, or why a client is not the source of truth.

Use the architecture page when a bug report or integration question needs ownership. Daemon behavior belongs in the main Wenlan repo; desktop UI behavior belongs in the app repo; the website owns public education and SEO surfaces.

Use the packages page when names are confusing: wenlan is the setup/plugin package, wenlan-mcp is the connector, wenlan-types is the shared wire type crate, and GitHub Releases are the stable artifact record.

Use the MCP client docs for Codex, Cursor, Claude Desktop, VS Code, Gemini CLI, ChatGPT, Claude.ai, and manual fallback config. Local clients use wenlan connect; web clients use Streamable HTTP MCP through a URL you control.

The desktop app is a GUI client over the same daemon, not a requirement. Current app releases live in the wenlan-app repo and should be verified against the app version, .wenlan-backend-version pin, and release target before public copy claims support.

When something fails, diagnose in order: daemon health, local CLI, MCP generated config, client restart state, then app-specific UI. That order keeps client bugs from being mistaken for product-data drift.

Shipped facts come from version.txt, CHANGELOG.md, release workflows, and repo-owned app pins. Merged main-branch work is not a public release until a release entry and artifact exist.

This route checklist is intentionally public. It is the website-level contract for whether users can move from setup, to concepts, to platform support, to troubleshooting without relying on private repo knowledge.