Checkpoint: The Local-First Operating Model

A single NextChat prompt is enough to expose the relationships established so far: stored conversation state determines the context, a provider adapter translates it, a web or desktop transport carries it, and the response returns to a local session. This checkpoint connects those relationships so readers can judge what “local-first” actually means when a prompt is processed remotely. The useful result is a complete first-pass model of NextChat, not a list of independent features.

The same prompt is a chain of transformations

Imagine a user continuing a conversation about a report. The visible action is a new sentence in an existing session, but the request begins before that sentence reaches a model. NextChat looks at the session’s messages, the mask attached to the conversation, model settings, any stored summary, and the point at which the user may have cleared context. It selects the eligible context and places the new input after it.

That selected context is a logical object. It answers: what should the model know for this turn? It can contain a system instruction, a mask’s ordered prompts, long-term memory, and a recent message window. It is not yet a provider request, and it is not the same thing as the complete session stored in the browser. The distinction prevents two common errors: assuming that every stored message will be sent, and assuming that every locally stored message stays local during processing.

The selected context then meets the provider adapter. The adapter decides how to represent roles, images, safety settings, tools, and model parameters for the chosen provider. The same logical conversation may be serialized differently for OpenAI-compatible, Anthropic, or Google endpoints. A setting can be preserved, rewritten, or omitted at this boundary. The request’s meaning is therefore the result of two decisions: what NextChat selected and how the adapter translated it.

Only after those decisions does transport determine how the request travels. A web deployment sends it through a NextChat route that authenticates and forwards it. A desktop build can use a native Tauri transport to reach a configured provider endpoint more directly. The provider processes the request and returns a response stream. NextChat carries that stream back into the client, updates the assistant message, and retains the resulting session state locally.

flowchart LR M["Mask and memory state"] -.-> Q["Selected context"] I["User input"] --> Q Q --> A["Provider adapter"] A --> W["Web route"] A --> T["Desktop transport"] W --> P["Model provider"] T --> P P --> R["Response stream"] R --> U["NextChat session update"] U --> L["Local persistent state"] L -.-> X["Optional remote copy"]

The arrows show different kinds of ownership. The mask and memory state influence selection; the adapter owns provider translation; the web route or desktop transport owns delivery; the provider owns model processing; and the client updates the session after the response returns. The local store is where the conversation can persist, but it is downstream of a request that may already have crossed several other boundaries.

This chain also explains why a single visible answer can conceal several distinct failures. If a system message is not accepted by a particular model, the adapter may remove or reshape it. If the endpoint or access policy rejects the request, the provider may never see it.