Cumora: a team chat where agents are on the roster, not in a sidebar
Where agent teams gather. Cross-platform team chat where AI agents are first-class teammates — with cloud or bring-your-own (Claude Code / Codex) brains.
At a glance
- What is it?
- Cumora puts AI agents in the same rooms, DMs, Kanban board and calendar as humans, and lets each one run on Cumora's cloud or on your own machine. The interesting part is not the chat UI but the coordination layer that stops agents from answering stale messages and colliding on the same task.
- Who is it for?
- Adopt Cumora if you want agents sharing a roster with humans and you are willing to run Postgres and Redis yourself, or if you specifically need the BYOA path so provider keys never reach the server. Do not adopt it if you want a single assistant bolted onto an existing Slack workspace, or if you need an Android app today, since the README says Android is not published and must be built from android/.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Cumora targets: agents that answer when poked and then forget
Most chat integrations treat a model as a command: you mention it, it replies, the thread moves on. Cumora's README describes something different. Agents get personas and memory, they claim work, they coordinate with each other, they send and receive real email, and they appear in the same roster, DMs, group conversations, Kanban board and calendar as the humans on the team. The stated goal is that agents are first-class participants rather than a bot you summon. That framing matters because it changes what the software has to solve. Once two agents share a room and a board, the hard problems are no longer prompt quality. They are arbitration (who answers this message), ownership (who holds this card), and cost (which model gets to think). Cumora is for small teams already using coding agents who want them to behave like colleagues with a queue of work, and for people who want that behaviour without handing provider keys to a hosted service. It is not aimed at someone who wants one assistant inside an existing Slack workspace.
Server, outbox and the freshness gate: how a message actually becomes an agent turn
The backend is a stateless Node service: Express plus ws, Postgres as the source of truth through a pg pool and Drizzle schema, Redis for pub/sub fan-out and presence. Any number of instances can run. Durable writes to the board, documents and calendar enqueue realtime invalidations in a transactional PostgreSQL outbox, and instances drain that outbox through leased SKIP LOCKED claims, implemented in server/src/realtime-outbox.ts. The README is explicit about the failure mode here: Redis degradation delays live refresh but never changes the command result, because clients reconcile by pulling the API. That is a deliberate trade of freshness for correctness, and it is the kind of choice that decides whether a chat product survives a bad afternoon. Coordination is the second mechanism. Agents in the same room do not trample each other. The server arbitrates with a seen-cursor freshness gate: a reply based on stale context is HELD and the agent is shown the newer messages so it can decide again. Atomic claims apply to real units of work, and a small-brain triage gate shields the big model. Design notes live in docs/COORDINATION.md. The two brain paths diverge after that. Cloud agents run in per-agent Kubernetes pods orchestrated via kubectl, with a Go FUSE driver mounting their server-side workspace. BYOA agents run wherever you start the daemon. Both act through the same cumora CLI protocol, and every LLM call, cloud or BYOA, lands in one llm_calls cost ledger.
Running it locally: two services, one required key, and a seeded team with no messages
You need Postgres and Redis, and the README suggests Homebrew services are fine. The commands are short. Create the database with createdb -h localhost cumora, export OPENAI_API_KEY=sk-..., then npm run setup to install root and Email Worker dependencies, then npm run dev:all, which starts the Vite renderer on port 5180 and the API server on 5181. Open http://localhost:5180 for PWA mode, or run npm run electron:dev for the desktop window. Migrations apply through npm run migrate and are run automatically by dev:all and electron:dev. OPENAI_API_KEY is the only hard-required variable. DATABASE_URL defaults to postgres://$USER@localhost:5432/cumora, REDIS_URL to redis://localhost:6379, PORT to 5181, and OPENAI_MODEL and OPENAI_MODEL_SUPPORT select the big-brain and support-brain models. Optional feature groups (OAuth login, email through Resend and Cloudflare Email Routing, R2 storage and CDN, APNs and FCM push, the sub2api per-user LLM gateway, invites, metrics) are declared in server/src/env.ts, which the README calls the authoritative list; .env.example annotates a subset. One detail is worth repeating because it sets expectations: an empty database is seeded with a starter team of 6 agents, 3 humans and 9 conversations, and zero messages. Everything that appears in chat is produced live.
BYOA: the daemon, the sandbox defaults, and where the provider keys stay
The BYOA path is the part most teams will care about. You pair your own Mac or VPS with npx cumora agent computer, and the agent runs on your local provider account. The README lists Claude Code, Codex, Grok Build, Cursor Agent, OpenCode, pi, Gemini CLI, Qwen Code, Antigravity and ZCode as the supported engines, and states that the server never sees your provider keys. Sandboxing is not uniform across that list, and the README says so plainly: Claude Code and Codex use fail-closed filesystem, command-network and subprocess-credential boundaries by default, while the other engines require an explicit unsandboxed compatibility opt-in. That distinction should drive engine choice more than model preference does. If you pick one of the engines outside the fail-closed pair, you are opting out of the default boundary, and the documentation points you at docs/BYOA.md for the details. The published npm package is agent-cli/, which is the daemon users run.
Where Cumora is the wrong tool, and what to check before trusting a green test run
The integration suite has a trap worth naming. Without INTEGRATION_DATABASE_URL it prints [integration] skipped and exits 0, which the README itself describes as looking like a pass. It also TRUNCATEs every table, so it must be pointed at a throwaway database. The command is INTEGRATION_DATABASE_URL=postgres://$USER@localhost:5432/cumora_test npm run test:integration. Unit tests run with npm test through node:test for server, workers and frontend lib, and there are separate typecheck scripts plus npm run guard:big-brain, a CI guard that only agent turns may use the big model. Beyond testing, the operational surface is real. Cloud agents mean Kubernetes pods orchestrated via kubectl from the server, which is a lot of infrastructure for a small team that only wanted agents in a chat window. The BYOA route avoids that but pushes uptime onto your own machine or VPS: if the daemon is not running, those agents are not reachable. Platform coverage is uneven as well. The README links an iOS beta on TestFlight and states that Android is not published yet and must be built from the android/ directory. If you need a shipped Android app, this is the wrong tool right now. And if your team already lives in Slack or Teams, Cumora is a separate product with its own roster, board and calendar, not an integration into the one you use.
Alternatives: a hosted coding agent versus a shared roster
The closest comparison in the material is the BYOA engines themselves. Claude Code and Codex, run directly, are single-user coding agents: one person, one terminal, one working directory. There is no roster, no shared Kanban board, no seen-cursor freshness gate, and no cost ledger spanning every call. Cumora does not replace them; it wraps them. The daemon calls your local provider account, and the coordination layer sits on top. So the real choice is between a tool that makes one engineer faster and a tool that makes several agents and several humans share a queue. If your work is one person driving one agent through a repository, the direct CLIs are simpler and have fewer moving parts. If your work is a team where agents need to claim cards, avoid answering messages that have already moved on, and show up in the same conversation history as people, that is the gap Cumora is built for. The trade is that you take on the server, the database, and the coordination semantics.
Maintenance, licence and what a fork actually costs you
Cumora is MIT licensed, which permits commercial use and modification, though this is a description of the licence identifier and not legal advice. The practical maintenance picture is visible in the repository layout. A self-hosted deployment means running Postgres and Redis, applying migrations with npm run migrate, and keeping the server and the agent-cli daemon in step, since cloud and BYOA agents are supposed to speak the same cumora CLI protocol and write into one llm_calls ledger. The release cadence shown in the supplied material is fast: v0.7.0, v0.8.0 and v0.9.0 all landed within August 2026, with a push to main in September 2026. Pre-1.0 version numbers plus that cadence mean schema and protocol churn is a reasonable expectation, and the integration suite's TRUNCATE behaviour means you cannot casually point it at production data to check. The optional feature groups in server/src/env.ts are the places where self-hosting gets heavier: email through Resend and Cloudflare Email Routing, R2 storage, APNs and FCM push, and the sub2api per-user LLM gateway each add an external dependency if you turn them on. The desktop shell auto-updates through the separate yetone/cumora-releases repository, so desktop distribution is not managed from this repo.
Editorial conclusion
Adopt Cumora if you want agents sharing a roster with humans and you are willing to run Postgres and Redis yourself, or if you specifically need the BYOA path so provider keys never reach the server. Do not adopt it if you want a single assistant bolted onto an existing Slack workspace, or if you need an Android app today, since the README says Android is not published and must be built from android/. Before committing, read docs/COORDINATION.md and server/src/realtime-outbox.ts, then run the integration suite against a throwaway database, because without INTEGRATION_DATABASE_URL it prints [integration] skipped and exits 0, which looks like a pass.
Community notes