How Whiskers Works

Whiskers is a runtime layer for local AI: it keeps durable state outside the model, then feeds the model the right recent context when it responds.

Not Another Chatbot

Whiskers does not replace your local model. It sits between the browser UI and the model server, adding persistence, logging, commands, context control, and background summarization.

The model still generates the text. Whiskers controls the session around it.

The Core Problem

The Whiskers Approach

Whiskers makes the conversation state durable. Every interaction is written to an append-only session log, then recent log entries are rebuilt into model-ready context for the next turn.

A separate summarizer model can process the log in the background and write long-term summaries without blocking the active conversation.

Runtime Flow

Whiskers keeps the conversation state outside the model. The model handles replies, while the runtime manages persistence, context rebuilds, and background summaries.

Whiskers functional diagram

The primary model handles the live conversation. Whiskers writes each interaction to session.log, rebuilds the recent context window from that log, and sends that context back into the primary model on later turns. Separately, the summarizer model reads new log entries and writes compressed summaries to session_summaries.log.

Core Mechanisms

Persistent Session Log

The log is the durable source of truth. The UI can reload, the browser can close, and the conversation history still exists on disk.

  • Append-only interaction history
  • Survives restarts and UI reloads
  • Allows the session to be reconstructed later

Recent Context Window

Whiskers does not blindly dump the entire history into the model. It rebuilds a recent interaction window from the log so the model receives relevant near-term context without choking the prompt.

  • Uses recent session entries for active conversation flow
  • Keeps context bounded
  • Preserves continuity without relying on browser state

Background Summarization

A secondary model can summarize new log segments in the background. This creates recovery notes and long-term continuity artifacts without interrupting the live model response.

  • Runs separately from the primary conversation model
  • Processes new log entries
  • Writes summaries to a separate summary log

Shared Session State

The UI is not the source of truth. Because state lives in the runtime and log, multiple browser sessions can reconnect to the same underlying conversation state.

  • Session continuity across browser windows
  • State survives UI reloads
  • The log, not the tab, owns the conversation

What This Enables

Why This Is Different

Typical Local AI

  • Stateless or mostly session-bound
  • Memory tied to the UI
  • Context disappears when the session resets
  • Long conversations drift or collapse under token pressure

Whiskers

  • Stateful runtime layer
  • Append-only log as durable memory
  • Recent context rebuilt from stored session history
  • Background summaries for recovery and long-term continuity

What Whiskers Does Not Claim

Whiskers does not make a weak model brilliant, and it does not magically eliminate hallucinations. It gives the model a better operating environment: durable memory, clearer boundaries, recoverable history, and tools for steering long-running sessions.

Future Potential

The same architecture can support replayable sessions, persistent world state, auditable interaction history, stronger session recovery, and more advanced memory workflows over time.

×