Host a circle and share the link, or join one you were invited to. Everything runs in this browser tab and computes directly between members — the server only introduces you.
Open a private room. You pick the job and who joins.
Enter the 6-character code a friend shared with you.
connecting to signaling server…
Messages travel directly between devices over the same P2P link — the server never sees them.
Point a phone camera at the code — the circle opens straight in their browser. Nothing to install.
Or send the link to people you trust.
Render here and broadcast the video to every device over WebRTC. Viewers move their pointer to interact — their input flows back over the data channel.
Broadcasting the canvas render below. Viewers can nudge the particles with their pointer.
Split a model's layers across the circle (pipeline parallelism). The heavy embedding & head run on capable devices; phones hold interior layers. Each token, only a few KB of hidden_states travel device→device. The host holds the heavy embedding & head; interior stages are placed capability-aware (stronger devices take proportionally more).
The sharded model (running across every device here) writes a scene in game-OSL, a tiny verb language. The finished scene is broadcast to the circle as a few hundred bytes — every phone renders it locally. No video stream, no cloud.
Set up the model pipeline above, then direct. Generation runs in the background across the circle — chat while it thinks.
How the circle's prompts reach the model. Open queue: anyone submits, they run in order. Vote to run: the circle approves each one (majority). Build together: one shared prompt everybody edits, anyone runs it.
Splitting a model across devices takes a little longer than a cloud service — so pass the time. Runs on your CPU, never the GPU the circle needs.
A private in-browser workspace. Every project is editable code: a .wgsl compute shader runs on the circle’s GPUs; .js / .wat / .wasm kernels run across the CPU cores. Build & run farms it across every linked device. New to the output format? Base any visuals on the example projects (Mandelbrot / SIMP / Distributed art): a kernel returns a small typed result — return {kind:"tile", x,y,w,h,rgba} for an image band, a plain number, a string, or {kind:"points"|"json"}. Use kind (not type) and a flat rgba byte array.
CPU kernels export run(lo, hi, chunk) and return a typed result (number, log, tile, image, points). Declare work size in the script — JS: const OSIRIS = {n, parts, label}; WAT/WASM: export osiris_n / osiris_parts. GPU kernels are .wgsl compute shaders: a //!osiris {…} header declares parts/W/H/maxIter/p[], and each writes one packed-RGBA u32 per pixel.
You do not have to write the solver. Open an example project, hand it to any AI with the rules below, tell it what to optimize, and paste the result back into a new file. If it errors, the log prints {kind:"error"} text. Paste that back to the AI and it fixes itself.
Keep: the const OSIRIS = {parts,label} line, the run(lo,hi,chunk) signature, work picked by chunk.index, the typed return (kind with rgba/caption/sub, or a number/json), and pure sandbox-safe code (no imports, no network, no DOM).
Change: the objective, the parameter sweep, the per-point solver, the labels.
Watch: OSIRIS.parts must equal the number of candidates (for a sweep, the product of its dimensions), and each run call must stand alone.
Keep this tab open and in front of you. Your device contributes compute to the circle only while this tab is visible — work runs in a background thread, so the page stays responsive. Close it any time to stop.
Your device is downloading its shard and helping the circle think — pass the time. Runs on your CPU, never the GPU the circle needs.