Frequently Asked Questions (FAQ)

Direct answers to the most common questions about fak, the agent kernel. Each answer is written to stand on its own. For the full story, start with the README; for runnable proof, see the 2-minute repro.

Jump to a topic: The essentials — answered here · deep-dive themes on their own pages: Core concepts and the mental model · The lock — how adjudication works · The wall — how result quarantine works · The addressable KV cache, in detail · Inside fak serve (the gateway) · The in-kernel model engine · Sessions, recall, and persistence · Performance and the numbers · Security and the threat model · Operations, configuration, and deployment · Integrations and migration · Comparisons with other tools · Observability, audit, and debugging · Limitations and honest scope

The essentials

The most common questions, answered to stand on their own. The deeper topic sections below go into how each piece actually works.

What is fak?

fak is one static Go binary you put in front of the AI agent you already run — Claude Code, Codex, Cursor, or any OpenAI / Anthropic / MCP client — by repointing a single base URL, with no rewrite. It makes long sessions cheaper (shedding old turns while keeping the provider’s prompt-cache prefix byte-identical), routes each tool call to the right model, can run local GGUF models in-process, and records an auditable verdict for every call. Under the hood it is an agent kernel: an in-process tool-call control plane fused with an addressable, bit-exact KV cache, so one checkpoint handles reuse, routing, policy, quarantine, and audit for the agent loop.

What problem does fak solve?

It gives you control over the parts of a real agent loop that get expensive or go wrong — at one boundary, the tool call:

  1. Long sessions get expensive. A growing conversation re-sends its whole transcript every turn, and the provider only discounts it while the cached prefix stays byte-for-byte identical. fak sheds the un-cacheable middle turns by splicing on the original bytes, so the cache discount survives instead of breaking. fak guarantees prefix byte-identity; whether the provider reuses the cache is the provider’s call, which fak relays rather than claims.
  2. One model rarely fits every call. fak routes an aspect — a tool call, a reasoning step, a stage — to a different model, with first-class ensembles. The routing decision is shipped and testable offline; live dispatch is the next step.
  3. Agents waste turns and tokens re-processing shared context and retrying malformed calls. fak serves a repeated read locally, repairs a malformed call in place, and makes the KV cache a kernel object so shared work is computed once.
  4. Dangerous and poisoned calls. Irreversible actions (refunds, deletes, sends) are gated by a reviewable allow-list checked inside the kernel — default-deny and fail-closed — and suspicious tool results are quarantined so they never enter the model’s context.

Do I have to configure anything to save tokens?

No. fak manage -- claude turns on six safe token-saving methods by default, with no flags and no config. Three are lossless and cannot change a single output token: provider prompt-cache passthrough (it forwards the cache breakpoints byte-for-byte so the provider’s discount holds), tool-floor pruning (it drops tool definitions the policy would deny anyway), and vDSO dedup (it answers an identical repeated call from the previous result). Three are bounded — they keep the model’s working set intact and each carries an honest note on what it sheds: history compaction, oversized-result elision, and a planned context view. You never pick, tune, or re-check them; the defaults are re-derived from the binary’s own entry points and pinned by a test, so a new release cannot silently drop one. See them live with fak token-defaults-scorecard (grade A, six of six on), or read the token-saving-defaults scorecard.

What token savings does fak give me out of the box?

Two things, kept honestly separate. First, fak keeps your provider’s prompt-cache discount alive as the session grows. That discount is often the difference between paying full price and a small fraction of it on a long run, and it only holds while the cached prefix stays byte-for-byte identical — which is exactly what breaks when a session outgrows the window, or when a naive setup summarizes to save room. fak holds the prefix identical and relays the provider’s own saved-token count each turn rather than claiming it. On the flagship Claude Code route that provider discount is the biggest line item, and it is the provider’s, not fak’s. Second, fak adds its own savers on the uncached remainder (tool-floor pruning, history compaction, result elision, the planned view) and catches malformed or dead-end tool calls before they cost a wasted round-trip. The value is one portal that keeps the whole stack on and proves it each turn, so you are not wiring up and babysitting each technique yourself. The full attribution on a real 122-turn session is in what fak changed, and what the provider did.

How is fak different from a normal firewall or API gateway?

A normal firewall or gateway screens traffic from the outside and typically fails open when it crashes or times out. fak puts the permission check on the same call path as the tool call (one address space, no inter-process call), so it is something the call passes through, like read() through an OS kernel. It is default-deny: an action that was never allow-listed cannot run, no matter what the model was talked into.

How does fak prevent prompt injection?

It uses two independent gates rather than one classifier:

The detector that flags suspicious results is deliberately treated as evadable (~100% evadable by design): it is a bonus, never the floor. An attacker has to beat two structural gates rather than fool one screener. In live tests, prompt injection reached the unprotected baseline 5/5 and fak walled it off 5/5. The full before/after walk-through — the same injected prompt against a classifier stack and against fak — is in Why default-deny beats a classifier.

Does fak address the OWASP Agentic Top-10 and the MCP Top-10?

Yes, structurally. It targets Tool Poisoning (MCP03) and Memory Poisoning (T1) by keeping untrusted tool results out of the model’s context (containment) and by gating which effects are even possible (the capability floor). Rather than recognizing each attack, it leans on the dangerous lever not existing and the poisoned bytes never arriving.

What is an addressable KV cache?

A KV cache is the scratchpad a model builds as it reads, so it doesn’t re-read from scratch each turn. Every shipped engine (vLLM, SGLang, the OpenAI/Anthropic prompt caches) only reuses it from the front: change anything in the middle and everything after is recomputed. An addressable KV cache lets policy reach into the middle of a kept run and evict a single span: a poisoned result, an expired secret. It leaves the cache bit-for-bit identical to a run that never saw it, verified at max|Δ| = 0. fak can do this because it owns the cache as a kernel object instead of renting it from a serving engine. See Addressable KV cache.

What is the deployment-substrate axis?

The deployment-substrate axis is the third axis along which the same ak kernel is invariant — from a battery-powered IoT sensor, through edge gateways and laptops, up to multi-GPU hyperscaler fleets.

The claim is that the workload shape (an agent loop proposing tool calls) and the invariants (default-deny, quarantine, bit-exact reuse, tamper-evident audit) do not change with the box, so an operator who learns ak on a laptop already knows it on a fleet. See The cross-platform spine.

Is fak a faster model server? How does it compare to vLLM, SGLang, or llama.cpp?

No. fak is not a faster model server. It does not try to beat vLLM, SGLang, or llama.cpp at raw throughput or front-of-prompt prefix caching. Those engines win that, and fak measures itself against them honestly rather than against a strawman. fak owns the orthogonal questions they don’t. Which effects are allowed, which results may enter memory, when reuse is still legal, and what survives a session boundary. You can even run fak serve in front of one of those engines and keep using it. The comparison that does favor fak is operational surface, not throughput (see the next question).

Why one Go binary instead of a Python serving stack like vLLM or SGLang?

Because serving an agent safely is a whole stack, not just a token engine, and most of that stack is governance rather than throughput. A model server (vLLM, SGLang) gives you fast tokens. To run a governed agent fleet you then assemble several pieces around it: a gateway and a capability/policy layer, a result-screening layer and an audit pipeline, and an MCP bridge plus a reverse proxy for auth. Those engines are Python on a CUDA/PyTorch stack and multi-process by design. Their production container is multi-GB because it bundles CUDA + PyTorch (pip/uv into an existing env is the lighter path), and vLLM’s own security docs direct you to front it with a reverse proxy for auth and endpoint allow-listing. Its --api-key covers only the /v1 routes.

fak collapses the governance + gateway half of that stack into one static Go binary whose whole external dependency set is two golang.org/x extended-standard-library modules (pinned by a 4-line go.sum: no Python, no CUDA toolchain). That one binary does a lot at once. It speaks the OpenAI and Anthropic wires plus MCP, enforces a reviewable capability floor, quarantines tool results, emits a trace-correlated audit log, and exposes Prometheus metrics. It runs on a laptop CPU with no key, model, or network.

Going from a developer’s laptop to a hardened fleet means adding flags (--policy floor.json, --require-key-env) rather than new components. fak fronts the fast token engine instead of replacing it. The honest fence: the contrast is operational surface rather than tokens per second, and fak’s own in-binary model is a correctness reference, not a production server. See One binary is the whole surface.

How much faster is fak for agent fleets?

The win is in reread-rate, not raw GPU speed. On a 50-turn × 5-agent run it is about 4× fewer tokens than a tuned warm-cache stack: the apples-to-apples comparison (~60× only against the naive re-send-everything baseline, not the headline). Over the real WebVoyager set (643 tasks) a deterministic geometry model puts the prefill work-elimination at 8.8–9.7× vs the naive floor (only 1.0–1.1× vs a tuned per-agent-KV stack) — modeled, not a wall-clock. The reuse win is self-host only. An app that merely calls a frontier API gets the safety floor but not the savings. Every number is traced to a commit and artifact in the benchmark authority.

Is fak a CDC or Debezium tool? Does it replicate my database?

No. fak is not a database-replication CDC tool, and it is not Debezium. It does not tail your Postgres or MySQL WAL, it does not replicate your tables into Kafka, and there is no Flink or streaming-SQL layer. What fak does ship is the change-data-capture pattern applied to the agent loop: its wire feeds — the coherence bus, the hash-chained journal, and the drive-state stream — are bounded, cursor-ordered, tombstone-carrying changelogs of agent, cache, and session state, which a data engineer already knows how to consume (/v1/fak/changes + /v1/fak/events, drained by cursor). The load-bearing fence is source, not sink: fak is a change source for agent work, never a replica of your database, and it captures agent state, not your tables. If you need to replicate a relational database, Debezium is the answer; fak captures a different changelog. The full mapping (CDC↔fak, the source-not-sink fence, how to consume the feed) is in change data capture for agents.

Is fak novel? What did the prior-art audit find?

A 29-claim prior-art audit scored 0/29 novel. Every individual primitive (capability security, quarantine, KV caching, content-addressed storage) is established prior art. The contribution is the assembly: putting them together as one in-process gate where the tool call is the checkpoint, so the security boundary and the reuse boundary become the same boundary. fak is built to survive a skeptic reading the code. See the claims ledger, where every capability carries one machine-checked tag.

How do I install fak?

One static binary, no clone or Go toolchain required:

curl -fsSL https://raw.githubusercontent.com/anthony-chaudhary/fak/main/install.sh | sh

Or download a prebuilt archive (linux_amd64, darwin_amd64, darwin_arm64, windows_amd64), or run it in a container. Full guide: Getting Started.

Can I try fak without a model, API key, or GPU?

Yes. With just Go 1.26+:

go run ./cmd/fak preflight --policy examples/customer-support-readonly-policy.json --tool refund_payment --args "{}"
go run ./cmd/fak agent --offline

refund_payment returns DENY (POLICY_BLOCK); search_kb returns ALLOW; and agent --offline runs the same task twice (tools wired directly vs. behind fak) and prints the before/after. Full walkthrough: repro packet.

What language and license is fak?

fak is written in Go (requires Go 1.26+ to build from source) and licensed under Apache-2.0.

How do I put fak in front of my existing model?

fak serve fronts any OpenAI-compatible server (Ollama, vLLM, a cloud provider). You keep your model and stack and gain a reviewable allow-list, result quarantine, and an audit trail:

fak policy --dump > floor.json   # a starter allow-list you can edit and review
fak serve --addr 127.0.0.1:8080 --base-url http://localhost:11434/v1 --model qwen2.5:1.5b

This is where most people should start; it is a complete product by itself. See the getting started guide.

How do I put fak in front of my agent or framework (Claude Code, Cursor, an SDK, or MCP)?

You usually change one thing: the base URL your agent already points at. fak serve speaks the OpenAI (/v1/chat/completions), Anthropic (/v1/messages), and MCP (--stdio or /mcp) wires, so any agent or framework that lets you override the base URL drops in with no agent-side code change. Every tool call it proposes is adjudicated by the capability floor before it runs.

Where the base URL goes depends on the agent:

The integration index has the which-agent routing table, per-framework snippets, and a 60-second offline proof. The per-tool guides are Claude Code, Cursor, and OpenAI Codex.

Who is fak for?

Teams running long-lived or self-hosted LLM agent loops who need three things at once: cache-efficient inference, per-call model routing, and reviewable tool-call control. It is useful at every rung. Front your existing model for auditable verdicts and policy; go all-in on the fused kernel with a self-hosted model to also get the reuse wins.

Where do I report a security vulnerability?

See SECURITY.md for the disclosure process. Please do not open a public issue for an undisclosed vulnerability.

Where can I learn more?

Deep-dive themes

Each theme lives on its own page so this front-door FAQ stays a bounded read; every question is preserved verbatim: