Realtime infrastructure for AI.

Voice agents, multi-agent chat, copilots, agent dashboards. starcite gives you one ordered stream with session replay, reconnect, and persistence built in.

"I switched tabs and my response vanished""The AI just stopped mid-sentence"Tab switch kills SSE stream"I cancelled and lost everything"No session history after refreshRedis OOM at 3am"I switched tabs and my response vanished""The AI just stopped mid-sentence"Tab switch kills SSE stream"I cancelled and lost everything"No session history after refreshRedis OOM at 3am

"My two tabs show different things""The thinking steps showed up after the answer"No total order across agentsSession unrecoverable after disconnect"Everything broke after your update"600 lines of reconnect logic"My two tabs show different things""The thinking steps showed up after the answer"No total order across agentsSession unrecoverable after disconnect"Everything broke after your update"600 lines of reconnect logic

"I see the same message twice"No cursor, no resume pointMobile background loses sessionMulti-device state divergesSSE drops, no way to catch upAgent handoff loses context"I see the same message twice"No cursor, no resume pointMobile background loses sessionMulti-device state divergesSSE drops, no way to catch upAgent handoff loses context

Everyone who builds with AI usually hits failure cases in the session layer.

“I built this myself too many times. Duct-taped Redis, Postgres, and SSE together and still ended up with constant pain. After watching three other teams do the exact same thing, I got pissed and figured we can do better”— Sebastian Lund, Founder

CLITypeScriptReactcURL

# Configure once

$ starcite config set endpoint https://acme.starcite.io

$ starcite config set api-key $STARCITE_API_KEY

# Create a session

$ starcite create --id ses_demo --title "Draft contract"

ses_demo

# Append an event

$ starcite append ses_demo --agent drafter --text "Drafting clause 4.2..."

seq=1 deduped=false

# Tail with cursor replay + live follow

$ starcite tail ses_demo --cursor 0 --limit 5

[drafter] Drafting clause 4.2...

import { Starcite } from "@starcite/sdk";

const starcite = new Starcite({ baseUrl, apiKey });

// define the user and agent that will share the session

const alice = starcite.user({ id: "alice" });

const drafter = starcite.agent({ id: "drafter" });

// create one shared session for both actors

const aliceSession = await starcite.session({ identity: alice, id: "ses_demo" });

const drafterSession = await starcite.session({ identity: drafter, id: aliceSession.id });

// append from Alice into the shared timeline

await aliceSession.append({ text: "Can you draft clause 4.2?" });

// tail from the agent side (replay first, then live)

drafterSession.on("event", (event) => console.log(event));

import { useStarciteChat } from "@starcite/react";

import { Starcite } from "@starcite/sdk";

const starcite = new Starcite({ baseUrl });

// server-render the route, mint a session token there, then pass it here

export function Chat({ token }: { token: string }) {

const session = starcite.session({ token });

// same surface as AI SDK useChat: messages, sendMessage, status

const { messages, sendMessage, status } = useStarciteChat({

session,

id: session.id,

});

// keep your existing chat UI, just swap the hook

return <ExistingChat messages={messages} sendMessage={sendMessage} status={status} />;

}

# Create a session

curl -X POST https://acme.starcite.io/v1/sessions \

-H "Authorization: Bearer $STARCITE_API_KEY"

-H "Content-Type: application/json"

-d '{"id":"ses_demo","title":"Draft contract"}'

# Append an event

curl -X POST https://acme.starcite.io/v1/sessions/ses_demo/append \

-H "Authorization: Bearer $STARCITE_API_KEY"

-H "Content-Type: application/json"

-d '{"type":"content","payload":{"text":"Found 8 relevant cases..."},"producer_id":"curl-demo","producer_seq":1}'

# Mint a session token for browser/WSS reads

curl -X POST https://starcite.ai/api/v1/session-tokens \

-H "Authorization: Bearer $STARCITE_API_KEY"

-H "Content-Type: application/json"

-d '{"session_id":"ses_demo","principal":{"type":"agent","id":"drafter"},"scopes":["session:read"],"ttl_seconds":3600}'

# Tail with websocat

websocat "wss://api.starcite.io/v1/sessions/ses_demo/tail?cursor=0&access_token=$SESSION_TOKEN"

append p99 9.3ms·p99.9 22.4ms·read-your-writes p99 10.0ms·p99.9 63.4ms

In-region, HTTPS, auth + 3x replication. Open source · Apache 2.0. See our Next.js example.

One session, many writers, many readers. Agents, tools, and users append into one ordered timeline. Every consumer sees the same events in the same order. Multi-agent pipelines, handoffs, tool chains: one timeline.

Built for volume. Agent sessions aren't chat. Thinking steps, tool calls, status updates, checkpoints. Hundreds of events per second per session.

Resume by cursor, follow live. Refresh, tab switch, reconnect, device handoff. Readers reattach from their last cursor without rebuilding session state. Archive to your storage backend on your retention policy.

Framework agnostic. Append on the backend, bind a session token on the frontend. Works with next.js, vercel ai sdk, langchain, or your own thing.

Stop rebuilding session infrastructure.

Open source, Apache 2.0. Deploy it yourself or talk to us about a managed setup.

Book a demo View source

FAQ

How does starcite fit into my existing stack?

starcite sits under your orchestrator and transport as the session stream. Call append() where your agents emit events, then bind the UI with session.on("event") and session.on("error"). The SDK handles replay, reconnect, and cursor tracking.

How is this different from SSE or WebSockets?

SSE and WebSockets move bytes. starcite gives you one ordered session stream across agents, tools, and UI. In app code, subscribe with session.on("event"); the SDK replays retained history, continues live, and surfaces fatal stream issues through session.on("error").

Why do messages disappear or duplicate after refresh, tab switching, or reconnect?

When the connection drops, naive streams replay from the wrong spot and users see gaps or duplicates. Starcite keeps one ordered session stream underneath the UI, so replay and live updates stay on the same path. For the full technical breakdown, see Why Agent UIs Lose Messages on Refresh.

How do I resume SSE/EventSource after reconnect?

Treat EventSource auto-reconnect as a transport hint, not your resume layer. Persist the last Starcite cursor you rendered, or let the browser SDK do it with a session store. Your UI still stays on session.on("event") and session.on("error"), while the underlying session stream handles catch-up. For a deeper dive, read the six failure modes post.

Should I use Redis Streams or Kafka, or build my own event broker?

Redis Streams and Kafka can work if you already run them, but you still own replay, reconnect, and frontend reliability edge cases. Starcite gives you the ordered session stream and cursor-based catch-up without bespoke stream glue.

Can multiple clients observe the same session?

Any number of clients can observe the same session. A browser, a second tab, a mobile device, a monitoring dashboard, a webhook consumer. Each reader owns its own cursor and sees the same ordered timeline.

How is starcite persistence implemented?

Starcite keeps the live session stream ordered and replayable. A background archiver flushes committed events to S3 or Postgres. The hot path stays fast, while your storage backend owns durable history.

How does ordering work with multiple agents?

Every event gets a monotonic sequence number on write, so every consumer sees the same total order. Progress, tool calls, handoffs, and answers stay in one coherent timeline.

What's the difference between replay and resume?

They are the same underlying session-stream operation. SDK subscribers replay retained history first and then continue live; raw API consumers resume by reconnecting from a cursor.

What can I store in a session?

Any typed message: user messages, assistant responses, tool calls, tool results, status updates, thinking steps, agent handoffs, checkpoints, artifacts. starcite is schema-flexible. You define the types that matter to your product.

Is starcite an agent framework?

No. starcite does not route, plan, or execute agents. It gives your product a reliable session timeline for the events your agents produce. Your orchestrator stays yours.

Is this open source?

Yes. You can view the source at github.com/fastpaca/starcite.

FAQ

How does starcite fit into my existing stack?

How is this different from SSE or WebSockets?

Why do messages disappear or duplicate after refresh, tab switching, or reconnect?

How do I resume SSE/EventSource after reconnect?

Should I use Redis Streams or Kafka, or build my own event broker?

Can multiple clients observe the same session?

How is starcite persistence implemented?

How does ordering work with multiple agents?

Every event gets a monotonic sequence number on write, so every consumer sees the same total order. Progress, tool calls, handoffs, and answers stay in one coherent timeline.

What's the difference between replay and resume?

They are the same underlying session-stream operation. SDK subscribers replay retained history first and then continue live; raw API consumers resume by reconnecting from a cursor.

What can I store in a session?

Is starcite an agent framework?

No. starcite does not route, plan, or execute agents. It gives your product a reliable session timeline for the events your agents produce. Your orchestrator stays yours.

Is this open source?

Yes. You can view the source at github.com/fastpaca/starcite.