Every thought an agent saves in FAVA Trails begins as a draft, and the Trust Gate decides whether it deserves to become shared, permanent memory. The gate reviews each candidate by asking whether a future agent, with no context about the conversation that produced it, would find it useful, and it rejects secrets, vague claims, transient state, and instructions disguised as facts. Until recently that review required a hosted model: by default, promotion candidates travel through OpenRouter to Google Gemini, which works well but means every candidate crosses an external inference boundary and costs a small fee before it can be promoted.
As of v0.6.0, the review can happen on your own machine. The Trust Gate speaks to any OpenAI-compatible endpoint, such as Unsloth Studio or vLLM, through the same provider-neutral interface it uses for hosted models. Promotion candidates stay local, the per-thought inference fee disappears, and no hosted provider sits in the critical path of your agents’ memory. OpenRouter remains the default for anyone who prefers it, and because the local settings live in per-machine configuration, one workstation can run a local gate while other machines on the same trails keep using a hosted one.
Can a quantized model be trusted with this job?
Before relying on a local gate, we benchmarked an Unsloth-served quantized Qwen 3.6 27B model against 49 historical promotion decisions that carried prior Google Gemini verdicts. It proved on par with Gemini for this task, and its mistakes leaned in the safe direction: every disagreement was an additional rejection, which leaves the thought visible as a draft where it can be revised and resubmitted, rather than a quiet approval that lets weak material into institutional memory. It returned a valid structured verdict in all 49 cases and never reversed a historical rejection. The raw numbers, the second-model audit of every disagreement, and the limitations are recorded in the public benchmark evidence.
The full story on Substack
Why the direction of the errors matters more than the agreement rate, what the nine disagreements with Gemini revealed, and where a quantized model struggles.
Read the benchmark write-up →Point the gate at your local endpoint
Local Trust Gate settings belong in the standard per-machine configuration at ~/.config/fava-trails/config.yaml (or $XDG_CONFIG_HOME/fava-trails/config.yaml). Shared trail configuration in your data repo does not change.
trust_gate: llm-oneshot
trust_gate_provider: openai
trust_gate_model: <exact-model-id-served-by-your-endpoint>
trust_gate_api_base: http://127.0.0.1:<port>/v1
trust_gate_api_key_file: /path/to/owner-only/api-key
# Slow quantized local models may need more time; keep this below tool_timeout_secs.
trust_gate_timeout_secs: 240A few properties are worth knowing before you switch. The credential file must be a regular, non-symlink file owned by you with mode 0600, and it is reread for every promotion, so you can rotate keys without restarting the server. Quantized models can be slow on long inputs, which is why trust_gate_timeout_secs deserves a generous value that still stays below the outer tool_timeout_secs. Most importantly, the gate stays fail-closed: if the local endpoint is unavailable, times out, or returns malformed output, FAVA Trails does not silently fall back to a hosted provider and promote the thought anyway.
The setup instructions in the main repository have the full configuration reference, including the complete Trust Gate field table and per-trail overrides. If you are new to FAVA Trails, pip install fava-trails and the README will get you from zero to a working memory repo first.