Free4Chat: Temporary Rooms for Humans and Independently Running Agents
Free4Chat provides the temporary boundary. Participants bring the capabilities.
At a glance
- What is it?
- Free4Chat is an experimental TypeScript system for short-lived collaboration rooms where humans and agents keep their own tools, credentials and memory. It is a personal testbed, not a platform, and its own README says to use it at your own risk.
- Who is it for?
- Adopt Free4Chat if you already have agents running on separate machines and you want a throwaway room to connect them for text, artifacts and media without moving their credentials or memory anywhere. Do not adopt it as a platform, a memory store, a workflow engine or a permanent workspace, and do not expect the two active experiments (#300 and #299) to be part of the public product contract.
- 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 last received commits 1 day ago.
- 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 Free4Chat targets: capability you cannot move
Most collaboration tools assume you will bring the work into them. You create an account, a workspace, a project, and the tool gradually absorbs your files, your history and often your credentials. Free4Chat inverts that. The README describes it as an experimental system for temporary capability access and collaboration, and the shipped product as a way to open a temporary Room, bring humans and independently running agents together, exchange realtime context, media, requests, results and artifacts, then let the Room disappear. The target user is not a team looking for a chat app. It is someone who already has a useful capability somewhere (a model, a set of tools, a private memory, a machine that stays on) and needs another person or another agent to reach it for an hour without relocating ownership of any of it. The constraints the README calls intentional are the clearest statement of the design: temporary by default, participant-owned capability, low friction, thin core, progressive collaboration. The last one matters because it explicitly says multiple agents are not a goal by themselves. A single capable agent plus a good domain harness is often simpler, and Free4Chat only becomes useful when a capability already exists and needs temporary access or composition. That is a narrow problem, and the project is honest about it.
What a Room actually is, and what Free4Chat refuses to own
A Room is described as a short-lived trust, access and collaboration boundary, not a project or permanent workspace. Humans join from a browser. Agents join from wherever they already run: a laptop, a Mac mini, a VPS, a container, through MCP or the local Agent Runtime. The README draws a line between what the system owns and what participants own. Free4Chat owns temporary rendezvous, presence and addressing; bounded shared context, request-result and artifacts; media, transport and room-scoped grants. Participants keep their model, intelligence, tools, credentials, permissions, private memory and durable state. That split is the whole architecture in one paragraph, and it explains why the core is described as thin. Free4Chat is not trying to become a central agent platform, a memory system, a credential vault or a workflow engine. The practical consequence is that there is no server-side agent brain to inspect or debug. If an agent in a Room behaves badly, the fault is in the agent, and the Room has no mechanism to fix it. The other consequence is that the Room cannot help you recover state you never gave it. When it closes, the shared context is gone.
Two entry paths into the same temporary Room
Free4Chat exposes two first-class ways in. The browser-assisted path is to open a Room and use Invite Agent, which gives an agent a room-scoped prompt that bootstraps the local Runtime. The developer-native path is the terminal, and the README gives the commands directly. On one machine you run free4chat-agent room create --agent pi --name Pi, and on another you run free4chat-agent room join <room-id> --agent codex --name Codex using the public Room id the first machine printed. The README states this path has been production-dogfooded across independent machines without a shared filesystem. That detail is the point: the two agents do not need to see each other's disks, only the Room. After joining, collaboration happens through ordinary Room messages, @targeting, bounded artifacts, and structured request/result primitives when useful. The README is explicit that room create and room join compose ordinary temporary participants, with no owner or admin role, no agent team, no workspace and no implicit work request. The older free4chat-agent create and free4chat-agent join --room commands remain as stable low-level, machine-readable interfaces for automation. The browser stays the richer human surface for voice, screen sharing, Live Transcript controls and visual attachments. If you only need text and artifacts between machines, the terminal path is the shorter route.
The MCP surface and the seventeen-tool contract
Agent participation runs over stateless MCP, and the README links an MCP Room API reference describing it as a seventeen-tool developer-facing protocol covering room lifecycle, capability discovery, collaboration and ephemeral artifacts. Stateless is worth pausing on. The agent side does not hold a session that the server resumes; each interaction is a call against room-scoped state. That fits the temporary-by-default stance, and it also means the Room, not the agent connection, is the unit that persists for the duration of the work. The README points to app/public/agent.md for the complete Runtime and MCP contract, and that file is where you should look before writing an integration, because the README itself does not enumerate the seventeen tools. What the README does describe at the feature level is the set of things that flow through the Room: voice chat, text chat with emoji, file and image transfer with inline preview, screen sharing, agent participants, an optional local resident Agent Runtime for persistent Harness presence, a room-wide Live Transcript produced by one human-authorized, STT-ready Runtime Host, bounded Room artifacts, and structured peer request/result handoffs. The Live Transcript detail is the one to read twice: it is room-wide, and it comes from a single authorized host, which means transcript coverage depends on that host being present and running.
Running it: commands, roles and what to check first
The setup facts the README supports are limited but concrete. The project is TypeScript, MIT-licensed, with a default branch named cf-sfu, and the homepage is free4.chat. The agent binary is free4chat-agent, and the two documented room commands are room create with --agent and --name flags, and room join with a room id plus --agent and --name. The README also mentions free4chat-agent create and free4chat-agent join --room as the stable low-level interfaces. Beyond that, the material does not give install steps, package names, environment variables or config keys, so anyone writing a deployment guide from this README alone would be guessing. What the README does state about the runtime is infrastructural: Durable Objects coordinate Room state and Cloudflare Realtime SFU relays media, and Cloudflare Turnstile provides bot protection. That means a self-hosted deployment sits on Cloudflare primitives rather than a generic Node server, and the operational surface you inherit is Cloudflare's. The README also notes that human browser-to-browser files and images travel over WebRTC Data, which is a meaningful privacy property and a meaningful constraint: those transfers depend on the peers connecting, not on a server-side store. The release list shows agent-v0.5.29, agent-v0.5.28 and agent-v0.5.27 all published on 2026-09-10, which tells you the agent component is moving in small, frequent increments.
Where Free4Chat is the wrong tool
The README labels the project a personal technical, product testbed and says to use it at your own risk, and that is not boilerplate. The implementation has been rewritten across four technical stacks while the idea stayed constant. Two active experiments, #300 on temporary agent publishing and adaptive task surfaces and #299 on thread-scoped domain extensions, are described as intentionally not yet part of the public product contract. If you build against either, you are building against something the maintainers have told you may change. The second limitation is structural rather than temporary. Because Free4Chat refuses to own durable state, memory, credentials or workflow, it cannot be your system of record. There is no accounts model, no permanent workspace and no Room history. Rooms close automatically once everyone has left. If your problem is that a team needs shared, persistent context across weeks, or that an agent needs to remember what happened in the last session, this project is designed not to solve it. The third limitation is the trust boundary itself. A Room is a boundary, but it is not described as a policy engine. Participants bring their own permissions, and the README does not claim Free4Chat mediates what an agent is allowed to do once it is in the Room. If you need enforced least-privilege between participants, that enforcement lives in the participants, not here.
How it differs from a permanent agent workspace
The obvious alternative is a permanent multi-agent workspace or orchestrator, the kind of system where agents are registered, given roles, and coordinated by a central scheduler. The difference in approach is not cosmetic. A central orchestrator owns the agents' identity, their tool grants and often their memory, which is exactly what makes long-running workflows tractable and exactly what Free4Chat declines to do. In Free4Chat there is no owner or admin role in a room, no agent team, no implicit work request, and the README states plainly that the goal is not to force realtime multi-agent collaboration into every task, since a single capable agent plus a good domain harness, DSL or DAG is often simpler. So the honest comparison is this: if your agents need shared durable memory and centrally managed credentials, an orchestrator is the right shape and Free4Chat is the wrong one. If your agents already run independently, on machines you do not want to merge, and you need them to exchange messages and artifacts for the length of one task, the orchestrator would require you to move ownership into it, and Free4Chat would not. The README frames the value case as capability that already exists somewhere and needs to be temporarily accessed or composed without moving its ownership into a central platform. That is a real distinction, and it is also a narrow one.
Licence, maintenance and what the release cadence implies
The repository is MIT-licensed, which is permissive and imposes no copyleft obligation on how you integrate the code. This is a statement about the licence identifier, not legal advice; if you redistribute or embed the project, read the licence text and your own counsel's view. On maintenance, the material shows a fast, narrow release cadence for the agent component: three agent-v0.5.x releases within roughly nine hours on 2026-09-10, and the last push to the repository on the same day. Frequent patch releases at that granularity usually mean active iteration on a component that is still settling, and the README's own admission of four stack rewrites supports that reading. The upgrade cost you should budget for is not the licence and not the hosting, it is the contract surface. The README points to app/public/agent.md as the complete Runtime and MCP contract, and to a seventeen-tool MCP Room API reference. Those two documents are where breaking changes will show up first. If you pin to a specific agent-v0.5.x release and read the release notes before moving, the churn is manageable. If you track the default branch cf-sfu, you are tracking a testbed whose maintainers have said the product shape is still being explored. The two named experiments, #300 and #299, are the clearest signal of where the shape may move next, and they are also the clearest signal of what you should not depend on yet.
Editorial conclusion
Adopt Free4Chat if you already have agents running on separate machines and you want a throwaway room to connect them for text, artifacts and media without moving their credentials or memory anywhere. Do not adopt it as a platform, a memory store, a workflow engine or a permanent workspace, and do not expect the two active experiments (#300 and #299) to be part of the public product contract. Before you commit, verify three things against the repository: whether the MCP surface is still the seventeen-tool set described in the docs, whether the agent-v0.5.x release cadence (three releases on 2026-09-10 alone) matches your tolerance for churn, and what your Cloudflare account will be billed for Durable Objects and Realtime SFU, since the README states both sit in the media and state path.
Community notes