What vidspawn sends, and when
vidspawn is a local-first app: your recordings, your transcripts and your library database are files on your own Mac. The app makes two calls on its own: an update check, and five anonymous usage counters that are on by default, disclosed by a notice at first launch and stopped by one toggle in Settings. This page documents both, field by field, so a packet capture matches the copy.
Reviewed 19 September 2026
What stays on your Mac
vidspawn uploads none of this anywhere. It lives in the media folder you picked and in one SQLite file.
- Recordings and thumbnails. Ordinary video files in a folder you choose, never blobs inside a database.
- The library database. One SQLite file holding titles, notes, tags, chapters and the trash.
- Diarization, embedding and search. Who spoke when, the chunking, the embeddings and the search index are computed on your Mac, always, whatever you choose for transcription and summaries.
- Edit drafts. Cuts, trims and timelines live as a draft on the machine that made them, and the source recording is never modified.
What leaves, and exactly when
Four things cross the network. Three of them wait for you, and the fourth is a plan that is not built.
When you share a clip
Sharing uploads the clip, a manifest and a self-contained viewer page to your own Cloudflare or Backblaze account, on your credentials. Nothing uploads until you press Share. A share page is public to anyone holding the link, the bytes expire on the schedule you set, and revoking deletes the objects.
If you route AI work to your own provider
Transcription and summaries run on your Mac by default: whisper and a local model you download once. In Settings you can send that work to your own API key or your own agent CLI instead. Then the audio, or the transcript text, goes to the provider you picked, on your credentials, and never through vidspawn.
The first time a model is needed
whisper, the diarization models and the local language model download from Hugging Face on first use, and each one is checked against a pinned hash before it loads. The app bundle ships no models.
Only if you pick the hosted plan
The planned Hosted + AI edition would be the one place recordings reach vidspawn's own infrastructure, by explicit choice and priced for it. It is not built, nothing opts you into it, and on every plan that exists today the bytes go to storage you own or nowhere at all.
The call that counts active installs
vidspawn asks our server whether a newer build exists. Apart from this and the usage counters below, nothing in the app opens a connection unless you ask it to: a share, a model download, a URL import, or a cloud provider you configured yourself.
When it fires: once when the app launches, once every 24 hours while the app stays open, and again each time you press Check for updates in the About window.
GET https://www.vidspawn.app/releases/check?version=…&target=…&arch=…Three values ride in the URL, five more in headers, and the HTTP client adds its own user agent. That is all of them.
| Field | What it is | Why it is there |
|---|---|---|
version | The version of vidspawn running on your Mac, for example 0.3.1. | So the server can answer whether a newer build exists. |
target | The build platform the updater is asking for: macOS. | The updater library sends it so a feed can hand back a build for that platform. |
arch | The processor family: Apple Silicon. | Same reason. Today there is one build, for Apple Silicon. |
x-vidspawn-os | Your macOS version, for example 15.6.1. | So we know which macOS versions still need supporting. The server records it and does nothing else with it. |
x-vidspawn-install | A random UUID minted on your Mac the first time vidspawn launches. Not derived from your hardware, not tied to any account, not used anywhere else in the app. | So one Mac checking in twice a day counts as one install and not two. It is how we know how many people run vidspawn. |
x-vidspawn-mcp | A single 1 or 0: whether an AI agent called a vidspawn MCP tool on this Mac in the last 7 days. Not which tool, not how often, not what the agent did. The app keeps only the time of the last call, in the same local table as the install id. | So we can count the machines where an agent actually uses vidspawn, the number the whole MCP surface is built for. It is always sent, so a 0 means no agent here rather than an older build. |
x-vidspawn-recorded | A single 1 or 0: whether a recording finished on this Mac in the last 7 days. Not how many, not how long, not what was on screen, not when. The app keeps only the time of the last recording, in the same local table as the install id. | So we can count activation, the share of installs that get as far as a finished recording, as machines rather than as events. It is always sent, so a 0 means nothing recorded here in the last 7 days rather than an older build. |
x-vidspawn-shared | A single 1 or 0: whether a clip was shared from this Mac in the last 7 days. Not which clip, not how many, not where the bytes went. The app keeps only the time of the last share, in the same local table as the install id. | So we can count the share rate, the share of installs that put a clip somewhere someone else can watch it, as machines rather than as events. It is always sent, so a 0 means nothing shared here in the last 7 days rather than an older build. |
User-Agent | The updater library's own name and version, tauri-plugin-updater, set by the library rather than by us. | Every HTTP client sends one. It shows up in a packet capture, so it belongs on this page. |
What the server keeps
The endpoint is a small Cloudflare Worker in vidspawn's own account. It records the fields above, with the user agent reduced to a coarse family label before it is written, plus the country the request came from, which Cloudflare derives from the connection. Your IP address is not stored, no cookie is set, and there is no account for any of it to be attached to. Raw rows expire 90 days after they are written.
Resetting the install id
The id is one row in vidspawn's local database: the key install_id in the app_meta table of app.db. Delete that row and the next launch mints a fresh one, and from then on the count treats you as a new install. Nothing else in the app reads it. The three bits are three more keys in the same table, mcp_last_call_at, recording_last_at and share_last_at; delete one and the next check sends 0 for it.
Five counters, on by default
vidspawn counts five things about how the app gets used, and they are on by default. Before a single one is sent, the app shows you a notice at first launch, on every install, saying what they are and offering Keep sending or Turn off. Not one counter leaves your Mac until you have answered: they queue in your local database and the sender stays quiet. Press Keep sending and the queued rows go out; press Turn off and they are deleted on the spot, in the same step as the flag, so nothing left waiting is sent later. The switch afterwards is the Help us improve vidspawn toggle under Settings > General > Privacy. While the counters are on, all five go to the same server as the update check, each one carrying your random install id, the app version and the time, and nothing about the recording. One more number is worked out on the server from the counters it already has, and the app never sends it.
Help us improve vidspawn
vidspawn sends five anonymous counters to our own server so we can see which features get used. Each one carries a random install id and the app version, never anything from a recording. They are on by default, and you can turn them off here or later in Settings.
- app launched
- recording finished
- clip shared
- summary generated
- agent tool called, and which tool
With each: a random install id and the app version.
Never: a recording, a transcript, a title, a file name, a hardware id, or an account.
Keep sending · Turn off
Every byte, on vidspawn.app/privacy
When it sends: once when the app launches, every 15 minutes while the app stays open, and as soon as you answer the notice with Keep sending or turn the toggle on. A batch carries at most 100 counters, and one failed send stops the sender for an hour.
The whole request as it leaves the app, here with three counters queued: two headers the app sets itself, then one JSON body.
POST https://www.vidspawn.app/stats/events
content-type: application/json
user-agent: vidspawn/0.3.1
{
"install": "f6d9b0c2-4a1e-4c33-9b7a-2f0c5d8e1a44",
"version": "0.3.1",
"events": [
{ "name": "app_launched", "props": {}, "at": "2026-09-08T09:14:02Z" },
{ "name": "recording_completed",
"props": { "kind": "screen", "duration_bucket": "1to5m" },
"at": "2026-09-08T09:31:47Z" },
{ "name": "mcp_tool_called",
"props": { "tool": "list_media", "surface": "app" },
"at": "2026-09-08T09:32:10Z" }
]
}The app sets content-type and user-agent itself rather than leaving them to the HTTP library, so they read the same on every send, and user-agent names the version the body carries. The HTTP stack adds only protocol fields such as the host and the content length. No cookie, no authorization header, no query string.
Five fields, and they are the whole body: install and version once per batch, then events, a list where every entry carries name, props and at.
install.The same random UUID the update check sends, minted on your Mac at first launch, so one Mac counts once instead of once per counter.version.The version of vidspawn that produced the counters, for example 0.3.1, so a change in a number can be read against the release it came from.events[].name.Which of the five counters this entry is. Nothing outside the table below can be queued.events[].props.The counter's properties, each one a word from the fixed list in the table below. The server checks the list again on arrival and drops anything else.events[].at.When the counter was queued, in whole seconds, UTC. The server does not read it: rows are timestamped on arrival.
Five counters leave the app. These are all of them, with every value they are allowed to carry.
| Event | What it counts | Values |
|---|---|---|
app_launched | The app started. Once per launch. | None. |
recording_completed | A recording finished and landed in your library. | kind: screen, window, camera, audio. duration_bucket: under1m, 1to5m, 5to30m, over30m. |
share_created | A clip's bytes went to storage you own. | backend: cloudflare, backblaze. |
enrichment_generated | A summary, chapters or tasks were asked for. | kind: summary, chapters, tasks, all. engine: local, cli, cloud. |
mcp_tool_called | An AI agent called a vidspawn MCP tool. | tool: the name of the tool, from vidspawn's own catalog and never from the call's arguments. surface: app, headless. |
One more number, first_recording_completed, is worked out on the server from the earliest recording_completed seen for an install id. It is not a counter and the app never sends it.
What the server keeps
The same small Cloudflare Worker that answers the update check, in vidspawn's own account. It records the counter's name, the app version, the install id, the counter's values and the country the request came from, and it drops any event or value that is not on the list above. No IP address is stored, no cookie is set, and raw rows expire 90 days after they are written.
Turning them off
The Help us improve vidspawn toggle under Settings > General > Privacy writes the flag and deletes the queued rows in the same step, so nothing already counted is sent afterwards. The flag is one row in vidspawn's local database, the key usage_stats in the app_meta table of app.db, and the queue is the usage_events table beside it. Delete the flag row and the notice comes back at the next launch, with the counters queueing again in the meantime: the toggle is the way to stop them, and deleting the row is the way to be asked again. Every field on this page is also in TELEMETRY.md, next to the source that sends it.
What vidspawn never sends
None of this reaches vidspawn on any plan that exists today.
- Usage events on the update check. It carries three yes-or-no bits and nothing more: an agent called a tool, a recording finished, a clip was shared, each one a yes or no for the last 7 days rather than an event. The five counters described above are the only other thing the app sends on its own. They are on by default, a notice at first launch says so, one toggle in Settings stops them, and every one of them is listed here. The three bits are not behind that toggle: they go with every update check.
- Anything from your library: file names, titles, notes, transcript text, folder paths, thumbnails.
- Hardware identifiers. No serial number and no device fingerprint. The install id is a random UUID, derived from nothing about your machine.
- An account. vidspawn has no sign-in, so there is no profile for any of this to hang off.
This website, and share pages
The same rule holds for the pages, by a different mechanism rather than a different promise.
vidspawn.app and the share viewer run no analytics script and set no cookies. There is no third-party tag, no pixel and no tag manager in the page.
What gets counted is counted on our own server instead: a download, an update check, a click on a referral link, and a view of a share page. That runs in vidspawn's own Cloudflare account, with no third party in the path.
A share-page view is recorded as the page type, the country, a flag for link-preview crawlers, and a salted hash of the viewer's connection details that rotates daily. The raw address is never written down. Views inside an embedded player are not counted at all.
If any of this ever changes
Every byte vidspawn sends on its own is listed here, field by field, and in TELEMETRY.md beside the source that sends it, before the build that sends it ships, and named in the changelog first. Before the first of the five usage counters leaves your Mac you get a notice saying what they are, and the Help us improve vidspawn toggle stops them. That toggle covers the counters and nothing else: the three yes-or-no bits on the update check go out with every check, toggle on or off, because they ride the request the app makes to find a new build. Deleting a bit's row in app.db, as described above, is what makes its next check send 0. No hardware identifier, no account, and nothing out of your library: not a file name, not a title, not a word of a transcript, not a frame of video. Open-sourcing vidspawn under AGPL-3.0 is on the roadmap, and that source is how you get to hold us to it.
2026-09: this promise changed, and we are not quietly editing the old one out. This page used to say that any usage statistics beyond the update check would be opt-in and off by default. The five counters ship on by default instead. A notice on every install says so before the first one is sent, and the Help us improve vidspawn toggle under Settings > General > Privacy stops them. We changed it because the opt-in version measured nothing: installs that upgraded never saw the ask, so the counts were of almost no one. What did not change: every byte is listed on this page and in TELEMETRY.md before the build that sends it ships, the change goes in the changelog first, and there is still no hardware identifier, no account, and nothing out of your library.