Real colleagues and virtual employees, in the same group chat

Features, one recording at a time

The link under each recording does not go to a marketing page: it goes to the section of the repository that explains how the capability is implemented and why it was designed that way. Every number below is a measured reading or a constant in the code, not a configuration ceiling.

The recordings run in a demo environment: the model endpoint is the built-in demo://local and the terminal dials a local ttyd fixture. So the frames show no token-by-token streaming, no chain of thought and no token usage — the demo endpoint answers each request in one block and reports neither, and the UI says so literally ("this backend does not report usage"). Attach a real upstream and all three become measured values; the SSE streaming, the reasoning tab and the cache-hit bar described in the body copy are what happens then.

@ a virtual employee in the group

An @ is not an HTTP request sitting in a queue; it is a letter dropped into that employee's virtual inbox. The badge next to the message is that letter's state: queued = unread, claimed = processing, finished = read, with failures and cancellations labelled separately. Replies stream out as the SSE arrives; a colleague who interrupts mid-call cuts the upstream and re-answers against the new message.

• One (employee, stream) pair runs at most one letter at a time, strict FIFO inside a stream
• The @ inside an employee's reply is handed to the next one, relay depth capped at 3
• Chain of thought is readable only in the trajectory view and never enters the group

End-to-end flow, taking mail and allocating slots §1, §3.1–§3.3

One desk advancing several groups at once

A group is a stream. The home panel lays streams out as a card grid or a list, with 2/4/9-pane splits in the top-right corner so several groups sit on one desk and each pane can dispatch an @ directly; a stream's border pulses with task state — amber while queued, green once it has just been advanced. The Stream flow on the employee detail page draws "which letter got claimed in which slice" as a timeline: horizontal is when the letter entered a time slice, vertical is streams ordered from highest to lowest weight.

• Each employee allocates the slice budget across streams by weight (1–20, per-stream override) using the largest-remainder method
• Tasks are claimed with a compare-and-write; orphaned running tasks are caught by expiry reclaim
• A resident worker keeps the queue moving when no browser is open

Scheduling algorithm and burst load test §3.1–§3.3, §6.3

Why the answer came out this way

Whatever the model saw in a round can be reconstructed. The trajectory inspector lists the prompt blocks of that step and where the cache breakpoints sit, keeps chain of thought in its own tab (it never enters the streamed body), and totals usage and KV hits per stream weighted by tokens. Rounds whose upstream reported no usage are labelled "not reported" instead of being passed off as 0%.

• Stable blocks first, blocks that change every round last — that is what keeps the prefix cache paying
• Compaction pushes the watermark forward in the background, and its coverage is enumerable and reconciled
• Summaries that do not fit the input budget are recorded honestly as "not merged in this step"

Block order as cache order, compaction, and why not 100% §5, §6.1–§6.2

Human and employee attach the same session

A group with an authorised VM that has a gateway address gets an SSH console entry in the top bar, and every row of "machines connected to this group" in the settings drawer opens it too. In a wide window it is a real split: chat and the composer keep working on the left, the terminal sits on the right. The recommended gateway is ttyd -p 7681 tmux new-session -A -s work, so you can watch dmesg -wT and ls while watching the employee work in the same session.

• The browser dials the gateway directly; WorkStream only stores the address and never proxies the session
• There is no reason to ship the VM password to the frontend: the gateway authenticates with its own credentials
• The write endpoint accepts only ws/wss/http/https and rejects a URL carrying user:pass@, a query string or a fragment

Where this boundary is documented: README "Launch status"; the client lives in src/lib/terminal.ts

Capabilities

Every number below comes from a constant in the code, the migration sequence, or the self-check output — not from a roadmap target.

Download by tag

Each archive is built with git archive from the commit the tag points at, byte-faithful to that commit, and unpacks into one version-named directory. The inventory and digests are generated at build time by scripts/releases.mjs; the page never calls a repository API.

The repository is private on Gitee: anonymous reads answer 403 on the web pages and 404 from /api/v5, so the download area does not depend on cloud release objects — the archives live in the site's own downloads/. The sha256 column prints only its first 16 characters as a human check; the full digest is in assets/releases.json.

The release-notes column quotes the annotated tag message verbatim, and that message is written in Chinese. The site does not paraphrase a release, so nothing here is a translation of what the tag actually says.

Architecture design

Every feature recording above links into a specific section of these documents. The repository is private, so a link needs your own access; the source archive carries the same markdown, so it stays readable offline.

Citing WorkStream in a paper

This block is the same content as assets/workstream.bib, and the copy button copies the file itself. The author field names the project; edit that line if you want it signed to a person.

Reading assets/workstream.bib…