Skip to content
Conduit

mcp server

kepcup

OpenMind product — a local-first, open-source team of AI Bots that behave like real teammates. A local alternative to Grok Bot, Meta Muse, and OpenAI Dot: runs entirely on your machine, bring your own

jooler/kepcupcommunitylistedunreviewed

Set up

Runs on your computer. Pick your agent and operating system.

This project does not publish an install method we can turn into a config. Follow the README instead.

README

synced Oct 21, 2026

KepCup

中文

Build a team. Only for you.

kepcup.app · Docs · v0.1.0 release notes · GPL-3.0

OpenMind

KepCup is an OpenMind product.

OpenMind means opening the thinking—product intent, the hard problems themselves, and how the modules fit together—not just the source tree. In the AI era, that goes further than "just open code": anyone can rebuild these ideas, or fold them into their own product, with coding models and agents. KepCup is free to use, and the design itself is deliberately reusable.

What is KepCup

KepCup is a local-first multi-Bot assistant. It can stand in for hosted teammate products such as Grok Bot, Muse, or Dot: you create Bots on your machine, give them permissions and a working directory, and they collaborate with you—and with each other—without handing your data to a host you do not control.

Bots are designed to be like real people. Collaboration should feel human: shared context, clear roles, and work that actually gets done—not endless Bot small talk.

Dual loop design

A Bot's behavior follows how real people work. Think about how you collaborate with a real person: if I were the one receiving your instructions, here is how I would behave:

  1. First I think through what you have asked. If the instruction is clear, I reply to you right away, then get to work. If it is unclear or needs other resources, I still reply first and work out the coordination with you.
  2. Only after that first round of communication do I start working. On a team I can call on unlimited resources: I just need to provide the right plan and standards, and the executors actually carry out the task.
  3. After that I keep waiting for your next instruction and can take on other tasks. Tasks I have sent out come back with results when they finish, and I then report the outcome back to you.

Throughout this flow I have two responsibilities: 1. communicate with you; 2. produce plans and drive task execution. In KepCup's design, these two responsibilities are implemented as two loops, each calling the LLM. Every incoming message starts a reply loop; task loops start on demand. All loops run independently, powered underneath by a built-in agent (currently Pi Agent) or third-party agents (Claude Code, Codex, OpenCode, Cursor, and others via ACP). Context stays strictly focused and is designed to stay well clear of the context window limits of mainstream models.

sequenceDiagram
  participant U as User
  participant Board as Message list<br/>(distilled board)
  participant Reply as Reply loop
  participant Task as Task loop

  U->>Board: Send message
  Board->>Reply: Start independent reply loop
  Note over Reply: Selective context injection<br/>(not full cumulative history)
  Reply->>Task: Start / route work on demand
  Note over Task: Tools, files, state<br/>stay within the task
  Task-->>Reply: Result / settlement
  Reply-->>Board: Distilled reply posted to board
  Board-->>U: Visible update

How conversations with a Bot achieve "infinite history"

A conversation with a Bot is just a message list for communication: what the user asked, what the key information was, what the final result was—the content itself is lightweight. And when the reply loop starts, the messages it injects are only a few of the most recent messages plus a few of the most relevant messages from history; the full message history is never injected.

flowchart TB
  Send["User sends a message"]

  subgraph List["Message list"]
    direction TB
    Gap1["…"]
    Rel1["Relevant"]
    Gap2["…"]
    Rel2["Relevant"]
    Gap3["…"]
    Rel3["Relevant"]
    Tail3["3rd from last"]
    Tail2["2nd from last"]
    Newest["Newest"]
    Gap1 --- Rel1 --- Gap2 --- Rel2 --- Gap3 --- Rel3 --- Tail3 --- Tail2 --- Newest
  end

  Scattered["3 relevant but non-contiguous messages"]
  Recent["Last 3 messages"]
  Context["Latest message + relevant past conversation"]
  Dual["Dual-loop system"]

  Send -->|Appended as the last item| Newest
  Rel1 --> Scattered
  Rel2 --> Scattered
  Rel3 --> Scattered
  Tail3 --> Recent
  Tail2 --> Recent
  Newest --> Recent
  Scattered --> Context
  Recent --> Context
  Context -->|Injected into the Bot| Dual

  classDef idle fill:#f4f4f5,stroke:#d4d4d8,color:#71717a
  classDef related fill:#eff6ff,stroke:#2563eb,color:#1e3a8a
  classDef recent fill:#fff7ed,stroke:#c2410c,color:#9a3412
  class Gap1,Gap2,Gap3 idle
  class Rel1,Rel2,Rel3 related
  class Tail3,Tail2,Newest recent

Why a project team, not a group chat

Group chat is a human social need; Bots do not have that need. The real scenario is gathering several Bots with different responsibilities to achieve a set goal or maintain some state. It has three cores:

  1. Centralized communication — the user and multiple Bots share one message list
  2. Planning and collaboration — take in inbound information, whether from user input or automation triggers such as a new email: who executes it, and who needs to pick it up next
  3. Shared knowledge and delivery — shared wiki / knowledge

The shared message board and project wiki are ready; board / OKR / schedule planning are still on the roadmap. The product cares about orchestrating multiple Bots to collaborate at high quality, not Bot small talk. See docs/design/41-project-team.md.

Development roadmap

Done

  • Dual-loop core
  • Bot conversation logic
  • Bots' internal communications
  • Bot details (config, memory, skills, wiki, schedules)
  • LLM provider configuration
  • Multimodal I/O capability configuration
  • Web
  • Browser use
  • Hardware sensor architecture + mic / camera
  • User profile
  • Third-party agents via ACP (Claude Code / Codex / Cursor / OpenCode)
  • Extension Center — skills
  • Extension Center — connections (Notion, Linear, Cloudflare, and more)
  • Extension Center — MCP
  • Extension Center — mail
  • Bot on-demand use of Extension Center capabilities
  • Bot authorization, sandbox, unattended mode, command allowlist
  • Schedules — one-shot & recurring
  • Bot micro-app widgets
  • Special Bot — Butler (environment setup, create initial Bots)
  • Workbench — Items (tasks assigned to Bots) & Memos (fleeting thoughts)
  • Project teams — basics & communication
  • Project teams — wiki

Todo

  • Project teams — board
  • Project teams — OKR
  • Project teams — schedule & planning
  • Plugin system
  • Bot message protocol

We are looking for your OpenMind

Issues, discussions, and PRs are welcome—especially around:

  1. Better authorization — mid-execution confirmation interruptions happen too often; we want fewer interruptions while still blocking dangerous commands by default.
  2. Multimodal vendor APIs — every vendor does it differently; we want a unified abstraction layer.
  3. Project teams — beyond board / OKR / planning, what else should there be?
  4. Workbench — it should bring work together in one interface and reduce the mental load of "remembering which Bot / which team." What's missing, and what ideas do you have?

Thanks

KepCup stands on many open-source projects and product inspirations. The acknowledgments below do not imply endorsement or affiliation by any trademark holder; logos and names belong to their respective owners.

Product inspiration

Thanks to Grok Bot (xAI / Cursor product line) for the product inspiration—conversational Bots, the three-column layout, and a flat UI (see design decisions D46 and 12-ui-layout.md). KepCup is an independent implementation and is not an official derivative or affiliate of Grok Bot.

Open-source dependencies

Electron · Svelte · TypeScript · Vite · Tailwind CSS · shadcn-svelte · TipTap · Lucide · pi · MCP · ACP · Anthropic Sandbox Runtime · SQLite · sqlite-vec · ONNX Runtime · Jina Embeddings v2 base-zh · Zod · electron-builder · MinerU · Nodemailer · es-git

Dependency list

Tier 1 — Platform & build

ProjectPurpose
ElectronDesktop shell; Bot browser via webContents + CDP
Node.jsRuntime (engines.node ≥ 22.19)
TypeScriptLanguage across the repo
Vite + electron-viteDesktop build & HMR
pnpmMonorepo (pnpm@11.22.0)
electron-builder / electron-updaterPackaging & in-app updates

(Chromium ships with Electron and is not listed separately.)

Tier 2 — UI

ProjectPurpose
Svelte 5Renderer UI
Tailwind CSS 4Styling
shadcn-svelte (+ bits-ui)Component foundation
LucideIcons
TipTapComposer / rich text
streamdown-svelteStreaming Markdown
PaneforgeResizable panes
mode-watcher / svelte-sonnerTheme & toasts
@pierre/diffs (+ Shiki)Diff display

Tier 3 — AI / protocol / sandbox

ProjectPurpose
pi (@earendil-works/pi-*)Built-in dual loop, tools & MCP wrapper
ACP (@agentclientprotocol/sdk)External agent protocol
MCP (@modelcontextprotocol/sdk)Tool servers & connected apps
Anthropic Sandbox RuntimeDefault sandbox backend (srt)
ONNX RuntimeLocal embedding inference (installed on demand)
Jina Embeddings v2 base-zhDefault local memory vectors (Apache-2.0)

Tier 4 — Data / mail / utility libraries

ProjectPurpose
SQLite (+ better-sqlite3-multiple-ciphers)Encrypted local databases & FTS5
sqlite-vecVector extension
es-gitGit operations for wiki / skills / checkpoints
@napi-rs/keyringOS keychain for the DB master key
ImapFlow / Nodemailer / mailparserExtension Center mail channel
ZodRuntime validation & RPC contracts
birpcMain process ↔ core RPC
undiciHTTP
MinerUDocument-parsing preset skill (AGPL-3.0; see NOTICE)
cron-parser; bash-parser + acorn; pino / ulidScheduling, command parsing, logging & IDs

And to the maintainers of our transitive dependencies (ESLint / Prettier / Vitest / @types, and pure utility libraries such as clsx / tailwind-merge; Playwright is used for e2e, while the in-product browser is Electron CDP).

Optional ACP agents (user-installed peers)

The products below are not npm dependencies. Users can install them locally and connect them to KepCup via ACP as optional peer CLIs (see docs/design/28-external-agents-acp.md):

  • Claude Code
  • Codex
  • Cursor
  • OpenCode
  • DeepSeek Harness

Optional sandbox enhancements (not npm)

The default sandbox is Anthropic Sandbox Runtime. Platforms can also opt into enhancement paths such as Lima (macOS), rootless Podman (Linux), or bubblewrap on Linux; these are guided by environment detection / docs and are not package dependencies of this repository. See docs/design/10-sandbox.md.


Appendix — Development, layout, license

Repository layout (short)

kepcup/
├── apps/desktop/     # Electron desktop app (product entry)
├── apps/website/     # Official marketing site (kepcup.app)
├── packages/core/    # Business logic & data (separate process)
├── packages/shared/  # Cross-process contracts & types
├── packages/testkit/ # Test infrastructure
├── docs/             # design / dev / guides / releases
└── infra/            # Cloudflare and related infrastructure

Details: docs/dev/01-conventions.md, docs/README.md.

Development

Requires Node.js ≥ 22.19 and pnpm@11.22.0 (see root packageManager).

pnpm install
pnpm dev          # build shared/core first, then start the desktop app
pnpm test         # unit / integration (prefer targeted runs while iterating — see AGENTS.md)
pnpm test:e2e     # Playwright e2e (@kepcup/desktop)

Agent conventions: AGENTS.md.

License

The root license is GPL-3.0. The MinerU skill vendored in the preset skills is redistributed separately under AGPL-3.0—see apps/desktop/resources/preset-skills/NOTICE.md. A repository-wide NOTICE file is not yet published.

↑↓ navigate openesc close