Privacy & Data Handling A local tool, not a service

Frame Minion is built on a simple principle: it's a local tool, not a service. It runs entirely inside your VS Code, talks directly to the AI providers you configure, and keeps everything else on your machine. There's no Frame Minion account, no Frame Minion server, and nothing phones home.

We never see your keys
They're stored locally in your OS vault and sent straight to each provider — never through us.
We collect nothing
No telemetry, analytics, prompts, media, or logs — there's no backend to collect them to.
We never run a server
No database, no account system. Your work stays in your workspace folder.

The short version

  • Your API keys never pass through us. They're stored locally and sent straight to each provider.
  • We collect nothing. No telemetry, analytics, usage stats, prompts, media, or logs — there's no backend to collect them to.
  • Your work stays local. Projects, frames, videos, and renders are written to your workspace folder.
  • Data leaves your machine only when you ask for a generation — and then only to the specific provider fulfilling it.
Your API keys
Frame Minion is not in the middle of your keys. They go to your OS credential vault and attach directly to each provider.

When you paste an OpenRouter, fal.ai, or AWS key into Settings, it goes into VS Code's encrypted secret storage — backed by your operating system's credential vault (macOS Keychain, Windows Credential Manager, or libsecret on Linux). Keys are never written to plain settings, never written to project files, and never written to logs.

At request time, the relevant key is read from that vault and attached directly to the provider's API. Frame Minion does not proxy, relay, or mirror your traffic through any intermediary — the request goes from your machine to the provider and back.

A few practical consequences

  • Secrets are not synced. VS Code Settings Sync doesn't sync secret storage, so your keys don't ride along to other machines via Frame Minion.
  • Keys are easy to remove. Clearing a key in Settings deletes it from the OS vault.
  • Good hygiene still applies. Scope each provider key narrowly, set spend limits in the provider dashboard, and rotate keys periodically — the same as any API credential.
What Frame Minion collects: nothing
No telemetry, analytics, crash reporting, or usage tracking of any kind.

Frame Minion has no server, no database, and no account system — so there is no place for your prompts, images, audio, model choices, or logs to be sent. None of it is gathered, aggregated, or transmitted to the extension's authors.

Where your data actually goes
The only outbound calls are to the providers you configure (plus a one-time, user-initiated ffmpeg download). Nothing routes through a Frame Minion service.
DestinationWhenWhat's sent
OpenRouter openrouter.ai Planning, image & video generation, balance checks Your prompts, reference images (inline base64 for image gen), audio (base64, for planning), model name, and your OpenRouter key.
fal.ai queue.fal.run, *.fal.media Wan / lip-sync video; uploading video reference media; balance checks Video prompts, uploaded reference frames/audio, and your fal key.
Amazon S3 your bucket Only if you choose S3 storage Uploaded video reference media, signed with your AWS credentials.
GitHub github.com Only if you click Download & Install ffmpeg A standard binary download (no payload from you beyond ordinary request metadata). The binary is SHA-256-verified.
Image generation is the most private path
Its references are sent inline as base64 directly to OpenRouter, never uploaded to any CDN or bucket. Image-only use touches OpenRouter and nothing else.
Reference media & storage URLs — the video path
The one place worth understanding in detail, because video models work differently from image models.

A video generator can't accept your reference frames or audio inline — it fetches them from a URL. So when a clip needs a start/end frame or a lip-sync audio slice, Frame Minion uploads that file somewhere reachable and hands the generator a link. You choose where, via the storage provider setting.

Default: the fal CDN vs. power-user S3

fal
fal CDN
Default · zero setup
  • Obscured — a long, random, unguessable capability link. Not tied to your identity, not listed, not enumerable.
  • Time-limited — the link carries an expiration. (fal may retain the underlying object longer than the link, per fal's policy.)
  • Narrowly shared — sent only to the video generator that needs it, nowhere else.
  • Locally auditable — the URL appears in Frame Minion's debug output so you can see what was uploaded.
S3
Amazon S3
Power-user · you own it
  • In storage you control — uploads to your own bucket, governed by your account.
  • You set the exact expiry — a pre-signed URL scoped to your account, expiring exactly when you specify.
  • Lifecycle + least-privilege IAM — layer on bucket rules and tightly-scoped credentials.
  • Requires setup — AWS credentials, a bucket, and a region.
The shared caveat: both are bearer URLs
A signed S3 URL is still a bearer capability — not authenticated per-recipient. Anyone holding a copy can use it within its expiry window, just like the fal link. That's the same mechanic, because it's what video generators require: a URL the model fetches anonymously. S3's real edge is that the bytes sit in storage you own and govern, with an expiry you set.

Bottom line: both options exist because video models fetch references by URL. fal is zero-setup with obscure, expiring links and provider-side retention; S3 puts the bytes and the expiry under your control at the cost of setup. Choose based on how much control you need over where the bytes live.

Logs
Diagnostic logs go to the "Frame Minion" channel in the VS Code Output panel — and only there. They're local; never uploaded.
  • What's in them: prompts, model names, request status, timings, and — for the video path — the reference media URLs above (so you can audit them).
  • What's not in them: your API keys are never logged.
Scrub URLs before sharing logs
Because debug logs can contain live, fetchable media URLs, don't paste raw logs into public issues or chats while those links are within their expiration window. You control verbosity through the log level — lowering it reduces what's written.
Provider-side data handling — out of our hands
Once a request reaches OpenRouter, fal.ai, or AWS, what happens is governed by that provider's policies, not Frame Minion's.

Providers may log requests for abuse monitoring, retain media for a period, or — depending on the model and your account settings — use data for model improvement unless you opt out. Frame Minion can't change any of that; it can only send your request directly and faithfully.

If data handling matters to you, configure it at the source: review each provider's privacy and retention policy, set model/account-level data controls in their dashboards, and prefer providers/models whose terms match your needs.

Recommendations checklist

  • Scope and limit your keys — minimal permissions, spend caps, periodic rotation.
  • Prefer image-only flows when you want the smallest footprint (no uploads at all).
  • Pick storage deliberately — fal for convenience, S3 for control; understand both hand the model a bearer URL.
  • For S3, use least-privilege IAM and bucket lifecycle rules to auto-expire old reference media.
  • Treat debug logs as sensitive while media links are live; scrub URLs before sharing.
  • Read your providers' policies — they, not Frame Minion, decide what happens to data after it's sent.