Free4Chat: the interrupt is not a kill, the only supported runtime is the newest one, and the default branch is called after a media router

Interrupt is the best you get

There are two interruption controls and the page grades them honestly. The first asks the active turn to yield or cancel, and the caveat is that a slow harness may take time to honour it, so this is not a synchronous process kill. The second is described as steering: your instruction stays the canonical task input, is prioritised ahead of ordinary queued follow-ups, and runs once the current turn yields or settles. Neither stops the agent from finishing the step it is in. That is a meaningful difference from a stop button, and it is the right design for an agent that is halfway through writing a file. It is also the thing to know before you hand an agent a task you need stopped now rather than soon.

Tasks outlive the browser and are not promised past a restart

The persistence story has a precise edge and the page draws it. Long-running local tasks keep working after you close the browser, and you can come back to the same live room from another device to check state, interrupt, redirect or approve. Then the sentence that matters: the project does not promise durable execution across the runtime, the harness, or a machine shutdown. That follows from the ownership split rather than from an omission. Participants keep their own state and the platform keeps bounded shared context and room-scoped grants, so if the thing doing the work is a process on your laptop, the work dies with the laptop. There is no server-side job queue behind a room, and a room that is empty for a while expires along with its transcript.

An agent can publish its own interface into the room

The most consequential capability on the list is not the chat. A task may publish a small sandboxed, room-scoped mini-app for bounded shared state and realtime collaboration, described as generated by the agent itself. Alongside it, a local adapter can project a bounded device or service capability into the room, and the page is specific about the boundary: a generated app can use that capability on an explicit human action, without exposing local endpoints and without exposing credentials. So the shape is an agent that writes a user interface for the room and can reach a slice of a real device, gated behind a click. Everything is described as bounded and sandboxed, and there is a separate live view for small interactive task interfaces as an optional second path.

The stability promise covers two commands

The support statement is short and unusually blunt. The project supports the latest released runtime, because the hosted side and the client evolve together, so an older one may miss current controls, features, semantics or bug fixes and is not guaranteed to work, with the instruction to upgrade before troubleshooting any agent or task behaviour. No version matrix, no compatibility range, no pinning. The only stability claim anywhere on the page is scoped to the two low level create and join commands, which are described as remaining stable machine-readable interfaces for automation. The release history matches the posture: three agent releases in three days, all on the zero five line. If you are automating a room, those two commands are your contract and everything above them is a moving target.

No owner, no admin, and no accounts anywhere

Creating and joining a room compose ordinary temporary participants, and the page is explicit about what that excludes: no owner or admin role, no agent team, no workspace, and no implicit work request. Humans join from a browser and agents join from wherever they already run, over the stateless endpoint or through the local runtime. So a room has no privileged member, which is a clean way to avoid the question of who owns the session, and it also means room-level authorisation is not something the room can express. Two machines can join the same room from a terminal with two commands and nothing else:

# Machine A: create a fresh Room and join Pi.
free4chat-agent room create --agent pi --name Pi

# Machine B: join Codex using the public Room id.
free4chat-agent room join <room-id> --agent codex --name Codex

The grants the platform does hold are described as room-scoped, and everything else, permissions, memory, credentials, stays with the participant who brought it. With no accounts there is also no recovery: no permanent history, no workspace, and a room that empties expires.

The core refuses four jobs on purpose

The stability list includes a design constraint stated as a rule: thin core. The platform connects participants and bounded shared context instead of becoming a central agent platform, a memory system, a credential vault, or a workflow engine. Those four are named as the things it refuses to grow into, which is the most useful sentence on the page for anyone deciding whether to depend on it. A related rule covers cost: client and participant compute is preferred, and high frequency data is meant to stay on the realtime data plane rather than becoming persistent control-plane state. Both rules are about the same boundary. The moment the service holds durable state or long-lived credentials, the temporary-room model stops being true, and it would rather not be the thing that holds your agent's state.

The transcript exists only if a human authorises a host

Human voice and text chat are first-class, and file transfer, screen sharing and emoji are all shipped. The room-wide live transcript has a different origin: it comes from one human-authorised runtime host that is capable of speech to text. So the transcript is not a server-side feature of the room, it is a participant's machine being authorised to listen and write down. That is consistent with the ownership model, and it has an obvious consequence. Close the tab and you lose the transcript unless a host stayed up. It also means the one participant with speech-to-text capability holds a complete written record of the room, which is a property of rooms rather than a defect in this implementation.

A second product boundary and a client-hosted contract

The extension section explains that the room product stays the collaboration core, owning the room and protocol boundary, the sandbox, transport and the trusted-origin host boundary for bounded external surfaces, while a separate lab owns the curated app portfolio, runtime lifecycle, discovery, search engine presence and retirement. The stated reason is to keep membership, security and transport rules in the core without making the core the source of truth for which external apps exist. Two details are worth noting. Discovery and retirement are listed as one unit, so the lab controls the lifecycle of surfaces the room serves. And the canonical runtime and machine contract is a document served from the application's public directory, so the contract an agent fetches is hosted by the product it is a contract for.

Editorial conclusion

Use Free4Chat if what you want is a room that disappears and an agent that keeps its own credentials and memory, because that split is the product and it is stated without hedging. Five things to know first. Read the support statement as a warning rather than a disclaimer: the project calls itself a personal technical and product testbed at your own risk, and the default branch name is a media router experiment, so this is a person building a thing in public. Plan for the runtime to move under you, since only the newest release is supported and the hosted side and the client ship together several times a week, so the stable surface is two low level commands and nothing else. Do not treat interrupt as a stop button; a slow agent may take a while to yield and there is no synchronous kill. Know that a task survives closing the browser but is not promised across a machine restart, because the work lives in your runtime rather than in the platform. And read the generated mini-app and device adapter features carefully before pointing a room at anything physical, because that is where a language model acquires a user interface and a slice of a local capability.

Frequently asked questions

Official sources

1. i365dev/free4chat on GitHub
2. License: MIT
3. Project website
4. README
5. Releases