Privacy

edytlab is a local-first desktop application. It has no server of ours behind it, it sends no telemetry, and we do not handle your audio. The website is separate from the app and does use analytics, described under “Telemetry and analytics” below.

Audio files

Every audio file you load is decoded, processed, and rendered on your machine. Editing, mixing, and rendering run locally, and so does transcription, once you have downloaded the speech model, and so do speaker detection and stem separation, once you have downloaded their models; none of them sends audio anywhere. We do not upload, copy, mirror, or otherwise transmit your audio. There are no “cloud projects” and there is no server-side processing.

LLM API keys

edytlab supports six API providers (Anthropic, OpenAI, Google Gemini, Groq, and OpenRouter, plus Ollama for a local model, which needs no key) and your ChatGPT plan, which has no API key (see “Signing in with ChatGPT” below). An API key you add is stored in your operating system's secure credential store: macOS Keychain, Credential Manager on Windows, or the Secret Service (GNOME Keyring, KWallet or KeePassXC) on Linux. On a Linux desktop with no Secret Service running, keys are held in the kernel keyring until you restart your computer, and the app tells you so, at launch and again at Save if the service went away after the app started. Keys are never written to plain-text files and never sent anywhere except directly to the provider whose key it is.

All your keys, and the ChatGPT sign-in token below, are kept together in one entry of that store, so macOS asks for your login password at most once per launch rather than once per key. What you chose (the active provider, each provider's model, a base URL, a reasoning effort) is not a secret and is not in the store: it is in a small settings file, provider-settings.json, in the app's config folder, and no key is ever written to it. An install that kept its keys one entry each moves them into the single entry the first time it starts and deletes the old entries only once the new ones read back; that first launch may ask once for each old entry.

Network traffic

During normal use, the app's outbound network traffic goes to the LLM provider you have selected. Chat requests contain your prompt text, agent context, and tool-call results — never your raw audio. A tool-call result can carry text taken from your audio, the words of a transcript (see “Transcripts” below). When you open Settings, the app also asks the provider shown there for its list of models; that request carries your API key (the saved one, or one you have typed) but no prompt and no audio, and for Ollama it goes to the address you gave it. With the ChatGPT plan the provider is OpenAI, the requests carry your ChatGPT access token in place of a key, and signing in, staying signed in and signing out also contact auth.openai.com (see “Signing in with ChatGPT” below). Beyond that, the app connects only where you tell it to: a plugin you install from a URL is downloaded from that URL, an MCP server you add is contacted at the address you gave it, and the speech, speaker and stem models are each downloaded from Hugging Face when you click their Download (below). Your OS network tools show every request.

The speech model download. Settings → Account has a Download button for the speech model (Whisper base, about 139 MB). The app contacts Hugging Face only when you click Download. It does not download anything at launch, when Settings opens, or when the assistant asks; no tool and no part of the app starts it. The click sends GET requests to huggingface.co, one for each of three files (an interrupted download is continued with an HTTP Range request, so a retry or a resume makes more), fixed to one commit of the onnx-community/whisper-base_timestamped repository (a copy of OpenAI's whisper-base, Apache-2.0). Hugging Face redirects the requests to its content delivery network. What Hugging Face sees is what any download shows it: your IP address, the time, which file you asked for, and a User-Agent of the form edytlab/<version>, so it also learns that the request comes from edytlab and which version of it. It sees nothing about your audio, your projects, your chat or your API keys, none of which is part of the request. The app checks each file against its SHA-256 hash before keeping it, and Remove in the same place deletes the files again. There is no telemetry: the app reports nothing back to us about the download, and we run no server that sees it. Hugging Face handles the requests under its own privacy policy. Transcribing makes no network request of its own; the model is only read from your computer.

The speaker model download. Settings → Account has a second Download button, for the speaker model that finds who speaks when (about 33 MB). It works the same way as the speech model's: the app contacts Hugging Face only when you click it, and not at launch, when Settings opens, or when the assistant asks. The click sends GET requests to huggingface.co, one for each of two files (a retry or a resume makes more), each fixed to one commit: the segmentation network from onnx-community/pyannote-segmentation-3.0 (an export of pyannote's segmentation-3.0, MIT licence) and the voiceprint network from Wespeaker/wespeaker-voxceleb-resnet34-LM (CC BY 4.0). What Hugging Face sees, the checks against SHA-256 hashes, Remove, and the absence of any telemetry are the same as for the speech model above, and it sees nothing about your audio. Using the model makes no network request of its own; it is only read from your computer.

The stem model download. Settings → Account has a third Download button, for the stem model that splits a recording into vocals, drums, bass and other (about 171 MB). It works the same way as the other two: the app contacts Hugging Face only when you click it, and not at launch, when Settings opens, or when the assistant asks. The click sends GET requests to huggingface.co, one for each of two files (the graph and its weights; a retry or a resume makes more), fixed to one commit of Intel/demucs-openvino, Intel's ONNX export of Meta's HT-Demucs v4 (MIT licence). What Hugging Face sees, the checks against SHA-256 hashes, Remove, and the absence of any telemetry are the same as for the speech model above, and it sees nothing about your audio. Separating stems makes no network request of its own; the model is only read from your computer. The four stems are written as audio files inside your project folder and are never uploaded; the assistant is told where they are, as it is told the result of any tool, so those paths reach the AI provider you chose in the chat, as text and never as audio.

Transcripts. Transcription runs on your computer with the model you downloaded, and your audio is not sent anywhere. But the words the model finds come back to the assistant as a tool result, like any other tool's, and go to the AI provider you chose in the chat. That is text, never audio, bounded for each call: word by word with their times when they fit, and as sentence-length segments when they do not. With Ollama the chat stays on your computer, so the words do too. If you do not want what was said in a recording to reach a hosted provider, do not ask the assistant to transcribe it, or use Ollama.

Signing in with ChatGPT

Settings → Account can run the assistant on your ChatGPT plan instead of an API key, through OpenAI's Sign in with ChatGPT for open-source apps, which OpenAI documents as a preview. Until you click Continue with ChatGPT, the app makes none of them. Every request goes from your computer to OpenAI, and nothing is reported to us.

Signing in. Continue with ChatGPT opens your default browser at auth.openai.com, where you sign in on OpenAI's page and see what edytlab is asking for. The address carries edytlab's client ID (see below), this installation's random host ID, the scopes openid, profile, email, offline_access, resource.invoke and chatgpt.tokens.use.direct, and a return address on 127.0.0.1. The first time it also carries the name edytlab; on a later sign-in to the same account it carries your email address as a hint, so that OpenAI can pre-select the account. When you finish, your browser goes to the return address: a listener that edytlab opens on your own computer for up to five minutes, so that step does not leave the machine. edytlab then sends the code to auth.openai.com to exchange it for tokens, and checks the signed identity token that comes back against OpenAI's published keys. Per OpenAI's documentation, using a ChatGPT plan “doesn't grant access to the user's API key or conversations”.

Staying signed in. An access token is valid for one hour and a refresh token for 30 days, which each renewal extends (OpenAI's token reference). When the assistant or the model list needs an access token that has expired or is about to, edytlab sends the refresh token to auth.openai.com and receives a new access token and a replacement refresh token, which it saves in place of the old one. It also reads OpenAI's public sign-in configuration and signing keys from the same host when it needs them. None of these requests carries your chat.

What a turn sends. With the plan active, the assistant's requests go to api.openai.com (POST /v1/responses) with your access token as the bearer, in place of an API key. They carry what any provider's request carries: your prompt text, agent context and tool-call results, as text and never your raw audio, and the “Transcripts” paragraph above applies to them as it does to any hosted provider. OpenAI's rules for this flow have the request set store to false and carry the conversation each time (preview limitations); what OpenAI does with the text is covered by its own terms and privacy policy. The same bearer asks api.openai.com for the models your account can use (GET /v1/models), when the assistant is set up on the plan and when Settings lists them, so that it can offer them and their reasoning levels; that request has no prompt and no audio. OpenAI sees your IP address and the text, as any provider does, and because the bearer belongs to your ChatGPT account it can tie the requests to that account, to edytlab's registration and to this installation's host ID, which is how it counts plan usage for each app (OpenAI's overview). edytlab does not retry a failed plan request on another provider, or with an API key.

What edytlab keeps. Only the refresh token is a secret that edytlab keeps. It goes in your operating system's credential store, in the same entry as your API keys (as chatgpt_refresh_token), and is replaced at every renewal. On Linux with no Secret Service running it is held in the kernel keyring until you restart, and on Windows a token that does not fit in Credential Manager (the entry is shared with your keys) is held in memory only; in either case Settings says so, and you sign in again after a restart. The access token is held in memory and never written anywhere, and the identity token is not kept once it has been checked. The rest is in a file, registration.json, in a chatgpt folder inside the app's config folder (app.edytlab.desktop in your user config directory), readable by your user only on macOS and Linux: the host ID (a random urn:uuid: value, not derived from you, that OpenAI documents as not being a credential), the client ID OpenAI issued for edytlab, the account's identifier and email address, the scopes granted, the time it was saved and a few claims from the sign-in's identity token that later ones are checked against. The email address is shown in Settings as “Signed in as”, and is sent back to OpenAI as the hint above; edytlab does not write it to its logs.

Signing out. Sign out sends the refresh token to OpenAI's revocation endpoint, named in its sign-in configuration, and then deletes it from the credential store. If OpenAI's answer cannot be confirmed (you are offline, say), the token is still deleted from your computer, and Settings tells you that edytlab could not confirm that OpenAI ended the sign-in. Signing out keeps registration.json, including the email address, so that the next sign-in reuses the same registration instead of adding another connection to your ChatGPT settings. Start over signs out and then forgets the registration (the client ID, the account and the email), keeping only the host ID, so the next sign-in registers edytlab again. When you use another account, the first account's refresh token is revoked and removed once the second sign-in has succeeded.

Signing out does not disconnect edytlab in ChatGPT. OpenAI's Help Center says it plainly: “Signing out of the app ends your session there, but does not disconnect it from ChatGPT or stop its authorized use of your plan.” To disconnect edytlab, open ChatGPT, go to Settings → Security and login, choose Sign in with ChatGPT under Login connections, select edytlab and choose Disconnect, where ChatGPT shows those controls. That also removes an entry that Start over left behind. Disconnecting does not reverse usage already recorded, and OpenAI does not tell edytlab when you disconnect it: the next time edytlab uses the session it finds out, and asks you to sign in again (Help Center, errors and recovery). The Manage usage button opens chatgpt.com/settings/usage in your browser; the app itself sends nothing there.

Telemetry and analytics

The desktop app does not send telemetry or usage analytics.

This website uses two Vercel products, which are loaded by the website only and are not part of the desktop app:

• Vercel Web Analytics records page views. Each data point can include the time, the page URL, the referrer, query parameters (filtered), geolocation, the device's operating system and version, the browser and version, and the device type (mobile, tablet or desktop). It does not use cookies. Instead of a cookie, a visitor is identified by a hash created from the incoming request. Per Vercel, that hash is valid for a single day, after which it is automatically reset, so visitors can't be tracked between different days or different websites.
• Vercel Speed Insights records page performance based on the Core Web Vitals. Each data point can include the route and URL, network speed, browser, device type, device operating system, country, the web vital measured and the page element it is attributed to.

Vercel states that Web Analytics does not collect personal identifiers that track and cross-check end users' data across different applications or websites, and does not collect or store information that would enable reconstructing an end user's browsing session across different applications or websites or personally identifying an end user. It states that Speed Insights does not collect or store information that would enable reconstructing a browsing session across pages or identifying a user. We see the results only as aggregated statistics in the Vercel dashboard for this website. We do not run Google Analytics, Plausible, Mixpanel, Segment, or any other analytics provider.

See Vercel's Web Analytics privacy and compliance and Speed Insights privacy and compliance pages, and its Privacy Notice, for the details.

Crash reports

Future builds may include opt-in crash reporting for stability debugging. If we add it, it will be off by default, surfaced in settings, and limited to stack traces with no user content attached.

Updates

The app does not check for updates and makes no request to find out whether a new release exists. New versions are published on the GitHub releases page and announced on this website; you download and install them yourself. It does not check for newer models either: the speech, speaker and stem models' files are pinned to one fixed version, and only your click on Download fetches them.

Contact

Questions about this policy can be raised as an issue in the public GitHub repository.