Privacy and data handling
Local storage, provider egress, retention, and telemetry behavior.
FusionKit runs locally, but fused work can include code, prompts, diffs, and tool results. This page explains what is stored and which providers see your code.
What is stored locally
Durable sessions live in ~/.fusionkit/sessions/ unless FUSIONKIT_SESSIONS_DIR overrides it. Each session directory can include:
turns.jsonl: full message arrays for each turn, including code and tool results.meta.json: session metadata such as tool, repo, model ids, timestamps, and panel state.costs.jsonl: per-turn token and USD estimates when pricing data is available.
Retention
FusionKit keeps local session files until you delete them:
fusionkit sessions
fusionkit sessions rm <id>FusionKit has no separate cloud-cost consent file or consent prompt. Review the
RouteKit providers and live model catalog before launch and use --budget to
cap observed spend.
Telemetry is opt-in
FusionKit sends no telemetry unless you explicitly turn it on with fusionkit telemetry on, and has no hosted control plane. When enabled, two anonymous event kinds are sent (via PostHog) from a fixed allow-list: command usage, and fused-session aggregates such as panel size, provider names, judge decision, and token totals. It never sends prompts, code, diffs, file paths, repo names, or model outputs.
fusionkit telemetry status prints the effective state and the complete field list; DO_NOT_TRACK=1 or FUSIONKIT_TELEMETRY=0 force it off above any stored consent. The consent file lives at ~/.fusionkit/telemetry.json unless FUSIONKIT_TELEMETRY_PATH overrides it. The only identifier is a random install UUID, deleted by fusionkit telemetry off.
Tracing is OpenTelemetry-based and exports nowhere by default: --observe points spans and events at the local scope dashboard over loopback, and only a user-configured OTEL_EXPORTER_OTLP_ENDPOINT (or the signal-specific traces/logs variants) sends them anywhere else.
Where code travels
A fused turn is sent to the providers named by the namespaced RouteKit model IDs in your active ensemble. Inspect both layers before a run:
fusionkit config show
cat .routekit/router.yaml
fusionkit doctorThis inspects the default embedded-router path. If router.url connects to the
standalone RouteKit singleton, inspect that external router with
routekit config show, routekit providers status, and routekit models list.
Daemon-backed RouteKit commands do not discover project configuration by
working directory.
The RouteKit route and billing disclosures name the credential owner, billing mode, egress destination, aggregator, failover boundary, limitations, and qualification evidence for every first-launch route.
The repository's .fusionkit/fusion.json contains namespaced model IDs only; its
.routekit/router.yaml maps them to OpenRouter and therefore requires
OPENROUTER_API_KEY. OpenRouter is an aggregator, so requests from this
checkout go to OpenRouter and then to the selected upstream models. In your own
repo, run fusionkit init, choose providers in .routekit/router.yaml, and
compose those live provider/model IDs in the Fusion config.
Rate-limit failover
The default policy is onRateLimit: fusion. If a passthrough vendor returns a rate-limit, quota, or billing error, FusionKit re-sends the failed turn to your configured panel providers so the session can continue. Use --on-rate-limit passthrough or --on-rate-limit fail when you do not want that provider expansion.