Stateless Core

What is a Stateless Core, and how does it differ from a stateful protocol design?

A stateless core refers to redesigning a protocol's operation around a request/response model: every call is an independent request carrying its own complete context, and the server responds once it's processed — with no need to remember which connection this is, which turn in that connection's history it's on, or what context has accumulated so far. This is the opposite of the original bidirectional, stateful protocol design, where the server has to continuously track each connection's current state in order to correctly handle its next interaction.

The most direct difference is whether the server "has to stay running." A stateful protocol requires the server to maintain a long-lived connection and remember state, meaning the server instance must keep running continuously. Under a stateless core, because every request is self-sufficient, a server instance can be torn down right after handling one request, and a fresh instance can spin up to handle the next one — no continuity of memory is required between them.

Why is a Stateless Core needed, and what problem does it solve?

A stateful protocol design works naturally enough when connection volume is small and the number of servers is fixed, but once usage scales to millions of users and thousands of servers running concurrently, a concrete scalability problem emerges: servers have to stay running continuously just to hold onto state memory, which means they can't take advantage of serverless architecture's ability to elastically scale compute resources up and down with traffic — because serverless instances are, by design, short-lived and disposable, unable to hold connection state over the long term.

A stateless core solves exactly this problem: it removes the responsibility of "remembering connection state" from the server, letting it deploy directly on serverless or edge computing infrastructure, automatically adding compute instances when traffic is high and scaling them back down when it's low, without needing to keep servers continuously running just to maintain a handful of long-lived connections. This makes the protocol itself far easier to scale as usage grows, instead of getting bottlenecked by the requirement to maintain connection state.

How does a Stateless Core actually work, and what concretely changes for developers building a server?

Under a request/response model, every request the caller (such as Claude) sends must carry its own full necessary context; the server receives the request, processes it, returns the result, and doesn't need to retain the information required for that interaction afterward. This means the connection-state management logic developers previously had to design themselves (using a database or in-memory cache to track what step a given connection is currently at) is no longer necessary under a stateless core — server code can simplify down to a plain request-handling function, with no need to maintain a separate state-storage layer.

For application scenarios that have always needed to remember context accumulated across multiple interactions (say, needing to recall what a user did in a previous step to decide the next step's logic), developers need to switch to other ways of linking these interactions together — attaching the necessary context directly to every request, for instance, or designing a state-storage mechanism independent of the protocol itself. In practice, this means migrating to a stateless core isn't simply a change of deployment method, but requires re-examining which parts of the application logic previously relied on long-term server-side memory.

What does a Stateless Core actually mean for me, and when should I consider migrating my own server to it?

If your current server implementation is small in scale, stable, and has no obvious pressure around scaling or operational cost, it's a reasonable call to place migrating to a stateless core lower in priority — this is a change spanning the protocol's core design, and it takes time to confirm whether any part of your application logic relies on server-side memory; migration isn't zero-cost.

If your current pain point is precisely the operational complexity that connection-state management brings, or you want your server to scale automatically with traffic but your current architecture can't because it has to maintain connection state, that means a stateless core offers exactly the technical fix you need, and the return on migrating is fairly direct. In practice, it helps to first list out which parts of your current server logic genuinely need to remember "which turn of this same connection is this," and which parts could actually be handled as independent, one-off requests — that list helps gauge how much real migration work is involved.