kelabo

<p align="center"> <img src="logo/mark_readme.png" width="180" alt="Kelabo logo"> </p> <h1 align="center">Kelabo</h1> <p align="center"> Live rooms with transcription, an AI assistant that answers <em>into the meeting</em>,<br> <a href="#bring-your-coding-agent-into-the-meeting">your own coding agent</a> in the meeting, helping live and then building what was agreed,<br> minutes written for you, and a searchable archive of everything your team decided. </p> <p align="center"> <a href="LICENSE"><img alt="MIT license" src="https://img.shields.io/badge/license-MIT-2aa4b8"></a> <a href="docs/self-hosting.md"><img alt="Self-hostable" src="https://img.shields.io/badge/self--host-AWS-2aa4b8"></a> <a href="https://kelabo.me"><img alt="Hosted at kelabo.me" src="https://img.shields.io/badge/hosted-kelabo.me-2aa4b8"></a> </p>

---

[!IMPORTANT] Kelabo is transparent by design, and that is not a setting you can turn off. Everything said in a kelabo with the mic on is transcribed live and shown to everyone in the room. The assistant reads all of it and answers onto a board that everyone sees; it has no private channel to any one person. When a participant brings their own coding agent, the room is told. A kelabo ends as written minutes and a searchable record of who said what and what was decided.

Kelabo is built for organisations and people who genuinely believe in fair, open communication, where what is said in a meeting stays on the record and the people who were there can read it back. If your team is not ready to work that way, Kelabo is not the right choice. We would rather you know that before you start.

Each live room is a kelabo — not quite a call, not quite a meeting, its own kind — and that is the word the app, the code and the URLs use. Open source, MIT. You can run the whole thing in your own AWS account, or use the hosted service at kelabo.me. Same product either way; this README is the guide to choosing.

Bring your coding agent into the meeting

If you already work with Claude Code or opencode, this is the part to read. Kelabo lets your own coding-agent session join a kelabo as a participant. It keeps your model, your repository, your MCP servers and your permission prompts. It hears the meeting, contributes while it is happening, and is still in your terminal when the meeting is over, with the whole discussion in context.

Before the meeting. Attach the agent to a scheduled kelabo. It reads the agenda note, investigates your codebase, and posts what it found to the board, so the findings are waiting when the first person walks in.

During the meeting. The transcript streams into your session as it is spoken. The agent stays quiet by default. When someone addresses it ("Kelabo, where do we retry failed uploads?") or asks something the room cannot answer, it searches your repository in the background and posts a short answer that cites file:line, while it keeps listening. Kelabo never runs your agent and never sees your code; only what the agent chooses to post reaches the room. Every tool call still asks for your approval in your own terminal, and the room can see that an agent is present.

After the meeting, skip the briefing. The kelabo ends; your coding session does not. It heard the requirements, the trade-offs that were argued, the constraints someone mentioned in passing and what was finally agreed. So the next thing you type can be "right, build what we just decided". You do not have to retype the design background into a fresh prompt or paste the minutes into a new chat. If the kelabo belongs to a journey, the agent can also read earlier meetings' minutes, documents and reports. When the work is done, it can post the outcome back to the journey, so the next meeting starts from it.

npm i -g @kelabome/agents
kelabo setup        # wires Claude Code and/or opencode, and pairs this machine with your Kelabo account
kelabo claude       # or: kelabo opencode, then /kstart

Then ask your agent to join your kelabo. This works against kelabo.me and against a self-hosted deployment alike, and kelabo uninstall restores your agent's configuration exactly as it was. Details: connector/README.md and docs/components/16-agent-bridge.md.

Two ways to run Kelabo

| | Self-hosting | kelabo.me | |---|---|---| | What it is | The full product deployed into your AWS account | The same product, operated as a hosted service | | You need | An AWS account and real comfort deploying AWS services, a domain on Route 53, your own supplier accounts (Soniox or Deepgram, an LLM provider of your choice, optionally Cloudflare), and an approved SES production-access request | An email address | | Time to first kelabo | An afternoon, mostly waiting on signups and certificates | Minutes | | Functionality | Identical | Identical | | Cost | Your own AWS + supplier bills (an idle deployment ≈ US$15–20/month) | Run at cost: prepaid top-up, per-call metered pricing with published rates, a weekly free allowance — no seats, no plans, no subscription | | Data boundary | Everything stays in infrastructure you control | Hosted — though audio still never touches any Kelabo server, in either deployment (see transcription) |

Neither path is the "right" one — they trade effort for control.

Self-host if you (or someone at your organisation) are genuinely familiar with AWS. The self-hosting guide walks from an empty account to kelabo.mycompany.com, but be honest about what it takes:

• an AWS account with admin access, and comfort with a terminal, DNS, CDK deployments and an AWS bill (the stack is CloudFront + Lambda + one Fargate container + DynamoDB/S3);
• a domain (or delegated subdomain) whose DNS lives in a Route 53 hosted zone — if your domain is managed elsewhere and cannot be delegated, stop here;
• your own accounts and API keys with the suppliers: Soniox or Deepgram (speech-to-text), an LLM provider you trust with your meeting text (the assistant and minutes — Anthropic, OpenAI, or any OpenAI-compatible endpoint, including one you host yourself; see choosing a model), and optionally Cloudflare Realtime (conference audio/video at scale);
• an application to AWS for SES production access so sign-in emails reach your team — approval usually takes a day, refusals happen (there is a MailerSend fallback, but it is one more account and one more DNS setup).

None of this is exotic to someone who deploys to AWS regularly, and from then on upgrades are git pull && make deploy. If that list reads like a normal Tuesday, self-host — you get the identical feature set with the data boundary inside your own account.

Use kelabo.me if that list does not describe you — a small business without its own managed domain, a team with nobody who wants to own an AWS deployment, or anyone who just wants to try Kelabo before deciding. Sign in with any email address (or Google/Apple) and you are in a kelabo minutes later; guests can even join a room with nothing but a display name. kelabo.me is run as a communication utility, at cost: you top up a prepaid balance, each call is billed at the exact metered supplier cost plus small published flat amounts, every account gets a weekly free allowance, and the rate card and running figures are public on the site. No per-seat pricing, no subscription, no invoice arriving later.

The two ideas: kelabos and journeys

A kelabo is one live room: conference audio, live transcript, a chat, a shared board the assistant posts to. When it ends it is archived — transcript, board and generated minutes — and becomes a searchable record.

A journey is what carries memory between kelabos. Two people finish a kickoff having made three decisions; three weeks later the follow-up kelabo would normally start from nothing. Link both into a journey and the second room starts with the first one's minutes, the journey's running description, health/progress indicators, pinned board messages and pasted documents — all visible to the people in the room and injected into the assistant's context, so it answers from what the project already decided instead of researching it again. A journey also keeps an append-only Q&A history: ask it a question ("what did we decide about the rollout?") and the answer is generated from every linked kelabo's minutes and stored forever next to the question. Journeys are many-to-many (a kelabo can belong to several), public to your organisation or private to a chosen roster, and everything that happens in one lands on a filterable timeline. Full design: docs/20-journey.md.

What you get

• A live room with conference audio, camera and screen share. Two transports: sfu (Cloudflare's edge, scales) or mesh — a "secure kelabo" where media stays peer-to-peer and no server can decrypt it. Peer-to-peer means the media path, not "serverless": browsers cannot find each other on their own, so a mesh call still needs the Gateway to relay signalling (SDP offers/answers and ICE candidates) and a STUN server for each browser to learn its public address. Where no direct route exists (symmetric NAT, strict firewalls) the media is relayed through TURN — still encrypted end to end, so the relay cannot decrypt it either. docs/components/15-conference-rtc.md.
• Live transcription as people speak, streamed browser → STT provider directly: the server receives transcripts, never audio.
• Messages beside the transcript — the room's chat, with history that survives leaving and re-entering, day dividers when a room outlives a day, and paging back through weeks of it.
• An assistant in the room that answers while the question still matters, onto a shared board. Address it directly with @kelabo.
• Minutes, written for you, and a searchable archive of every ended kelabo.
• Journeys — named containers that link related kelabos so decisions, documents and Q&A history carry from one meeting to the next.
• Scheduling and invitations — schedule a kelabo, invite by email, change the roster before it starts; cancellations and reschedules notify everyone.
• Contacts and presence — see who in your organisation is online, and ring them into a huddle straight from Contacts.
• Your organisation's directory, imported — upload the people list your mail system already exports (Microsoft 365, Google Workspace, or any CSV) and invite fields find colleagues by name, typos and all, before they have ever signed in.
• Bring your own coding agent. Attach your own opencode or Claude Code session to a kelabo. It hears the transcript, answers onto the board, and leaves the meeting with the whole discussion in context (above).
• Everything optional degrades, nothing jams. No STT key? The room is typed messages and calls. No LLM? No assistant surface at all — not a broken one. No Cloudflare creds? Peer-to-peer calling still works, over public STUN only — so peers on networks that need a TURN relay cannot connect. The capability ladder is a design rule, not an accident: docs/19-optional-capabilities.md.
• An admin console, so day two is not a deploy. /admin publishes the model, the transcription engine, the mail transport, every rate limit and TTL, and holds the supplier keys — live in seconds, versioned, with an author and a note on every change. What still needs a deploy is what CloudFormation reads at synth: the account