video1.0<iframe src="https://www.loom.com/embed/8909d82ccb88495688692f2cb05f90fe" frameborder="0" width="3840" height="2880" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>28803840Loomhttps://www.loom.com28803840https://cdn.loom.com/sessions/thumbnails/8909d82ccb88495688692f2cb05f90fe-167514e30b798629.gif79.966667HI, I'm Alessandro. I built Fluxychat over the past 2 months because I wanted a small, inspectable realtime chat stack on Cloudflare (Workers + Durable Objects + D1) instead of running a separate socket fleet and a heavy SaaS bill for “just rooms + delivery + ops hooks.” What it is: FluxyChat is a hosted multi-tenant chat backend (REST + WebSocket) with a Next.js operator console and a JavaScript SDK. A room is a channel; JWTs are scoped by tenant/project; the Worker holds room state in Durable Objects. Live URLs: - Try / sign up: https://www.fluxychat.com/get-started (→ onboarding → console) - Console (after auth): https://www.fluxychat.com/rooms and https://www.fluxychat.com/agents - API: https://api.fluxychat.com - Overview + demo video: https://www.fluxychat.com/landing - In-app docs: https://www.fluxychat.com/docs How to try it today (beta, account required): 1. Open https://www.fluxychat.com/get-started and create an account (Clerk — email verification may apply). 2. Complete the onboarding wizard (creates a project and shows your API key flow). 3. Open Rooms — create or join a room, send messages over WebSocket. 4. Open Agents — configure an agent (your LLM provider keys go to the Worker/console, not the npm package), open the agent room chat, @mention the agent or invoke from the UI. There is no anonymous guest room yet; signup is the friction I’d like feedback on. What’s in this open beta (shipping in prod now): - Worker on Cloudflare: rooms, messages, presence-style realtime over WebSockets, webhooks, quotas in D1. - Dashboard: projects, rooms, search, agent profiles, LLM provider registry + credentials. - Agents: tool calls and tool results streamed in the thread; run status (latency/tokens/errors) on the wire; reply-to via parent_id; optional history replay modes in the SDK (connect vs explicit request). - Operator UX: prompt templates picker, assistant room entry from /rooms, LLM fallback provider in agent config. - SDK: @fluxy-chat/sdk — FluxyChatClient, useChat, FluxyRealtimeProvider; cookbook for bot streaming: (add your public doc URL if published, e.g. GitHub docs path) What I am NOT claiming / not in this beta: - Not a hosted MCP server or OpenCode-style TUI clone. - No separate “sessions” API — we use rooms as channels by design. - Threads/polls/machine translation are left to your product layer; Fluxychat ships the realtime core. Architecture (factual): - Browser → Next.js dashboard (Vercel, www.fluxychat.com). - Browser & your backends → Worker API (api.fluxychat.com): HTTP + WebSocket. - Hot path: one Durable Object per room for coordination/delivery (details in repo/docs). - LLM keys: configured per project/agent on the Worker side; the SDK only carries your Fluxy member JWT / project API key for auth. Backstory / why it might be interesting: I kept scope narrow on purpose: multi-tenant chat with clear quotas, middleware hooks, and a console for day-two ops — without bundling a full “AI IDE.” The current push is making agent runs observable in the same room timeline (tools + run metadata) so you can debug automations like you debug chat. Repo: - GitHub URL: https://github.com/AlessandroFare/fluxychat I’d especially like feedback on: 1. Whether the signup/onboarding path is acceptable or if I should prioritize a no-login demo room. 2. SDK DX (useChat, replay modes, error surfaces on agent runs). 3. Pricing/quotas model for a Worker-native chat SaaS — what would make you try vs self-host? Thanks for poking at it — happy to answer technical questions on DO layout, auth, and agent invoke paths.