How it works
faxl is a proxy. Your agents talk to faxl, faxl talks to your models, and the saved state stays on disk you own.
One
It saves the work, instead of discarding it
Before a model can answer, it must process your prompt — the system prompt, the tools, the documents, the earlier turns. That processing produces working state. Normally it is thrown away the moment the reply finishes.
faxl writes that state to disk at checkpoints, so the work survives the request that paid for it.
Two
It finds the work again
When a new prompt arrives, faxl fingerprints its prefix and looks for a saved checkpoint that starts with the same text. Most agent traffic is mostly repeat, so most of the time there is one.
Three
It never trusts the fingerprint
A fingerprint match is a candidate, not an answer. Before the model resumes from a checkpoint, faxl confirms the saved tokens against the new prompt token-for-token. Only an exact match is used.
That is the difference between a cache you can put in front of production and one you cannot. Output is byte-identical to an uncached run. A miss costs a little lookup time — never a wrong answer.
- 570 of 570 adversarial reuse decisions correct.
- No wrong or stale state served, in testing or use to date.
- Five model architectures behind one unchanged proxy.
Four
The model processes only what is new
The model resumes from the checkpoint and processes the tail — the part of the prompt it has not seen before. On a repeated prompt that took 5,056 ms to first token, the same prompt through a warm store took 246 ms.
Kimi Linear 48B, one prompt class, on Apple silicon — a hybrid recurrent model, the architecture that breaks ordinary prefix caching. Your result depends on your models and how much your prompts repeat.