Deepgram Data Retention (2026): The List Price Opts You Into Model Training

Short answer — what's happening to your audio?

• Hosted API on the published rates (Pay As You Go / Growth) → you're in the Model Improvement Program. Part of your audio is persisted and can be used in training. No published retention window.
• Hosted API with mip_opt_out=true on every request → out of the program; data "retained only for the duration necessary to process the request." You forgo the participation discount.
• Self-hosted Deepgram (Docker, Kubernetes, SageMaker, bare metal) → your infrastructure, your retention. Requires an Enterprise plan.
• Nothing sent at all → for meeting notes specifically this is a real option now, because transcription runs fine on-device.

I make Humla, a Mac meeting notetaker that can use a Deepgram key or no cloud at all, so I have an obvious stake here. Everything below is quoted from Deepgram's own pages, checked 4 August 2026, with links. There's also an uncomfortable finding about my own app further down — I'd rather you hear it from me.

The footnote that is the whole story

Deepgram's pricing page lists Nova-3 speech-to-text in fractions of a cent per minute — the self-serve rates run roughly $0.0042–$0.0092 per minute depending on model, streaming vs pre-recorded, and whether you're on Pay As You Go or Growth (read 4 August 2026). Smart formatting is included; speaker diarization is a metered add-on at $0.0020/min and keyterm prompting at $0.0013/min.

Underneath every one of those tables sits a single sentence:

Rates listed above opt in to the Model Improvement Program.

That is the retention policy, stated as a pricing footnote. The Model Improvement Partnership Program docs describe what participation means:

Deepgram stores fractional increments of data for the continued improvement of our voice AI models and to provide enhanced customer support when needed. The only data we will store and use in future model training is the data that is contractually included through participation in the Deepgram Model Improvement Partnership Program.

Read that second sentence twice. It's simultaneously a reassurance ("only data contractually included") and, once you know the pricing footnote, a description of the default for every self-serve customer.

A Deepgram staff member put it plainly in their GitHub discussions on 18 June 2025, answering someone who transcribes sensitive audio:

we include hosted API users in our Model Improvement Program, which includes persisting audio in part to improve our models.

And on the cost of leaving, in the same reply: opting out "forgoes a 50% discount for participating in the program." The docs are vaguer — they promise "discounted pricing for program participants that yields significant savings" — and the public pricing page doesn't list an opted-out rate at all. So treat the 50% figure as one dated statement from a Deepgram employee rather than published pricing, but treat the direction as settled: privacy here has a list price.

Opting out is one query parameter

To Deepgram's credit, the mechanism is trivial and documented, with copy-paste examples for every SDK:

curl \
  --request POST \
  --header 'Authorization: Token YOUR_DEEPGRAM_API_KEY' \
  --header 'Content-Type: audio/wav' \
  --data-binary @youraudio.wav \
  --url 'https://api.deepgram.com/v1/listen?mip_opt_out=true'

The docs are unambiguous about the effect: "Add mip_opt_out=true as a query parameter of all API requests that you want to be excluded from the Model Improvement Program. Data from opted-out requests is retained only for the duration necessary to process the request."

Note all requests. This isn't an account setting you flip once in a console; it's per-call. Miss it on one code path — a retry, a different endpoint, a batch job someone wrote last year — and that audio is in the program.

What Deepgram doesn't publish

Here's where the comparison with other providers gets unflattering. For opted-in data, Deepgram publishes no retention duration anywhere I can find. Not thirty days, not a year, not "until you delete it." Nothing.

The privacy notice — last updated 26 October 2021 — pushes the question into your contract:

Any Customer Data that we have access to shall be retained, stored, and deleted according to our agreement with our business customer. We store data on servers in the U.S.

For an enterprise customer with a negotiated DPA, that's fine: your retention terms are in the paper. For a self-serve developer whose "agreement" is the standard terms, it resolves to nothing you can point at. When a user asked in Deepgram's GitHub discussions how long audio and transcripts are kept, staff answered by pointing at the Terms and Privacy Policy and inviting deletion requests by email — no duration. A 2026 thread asking for documented zero-retention configuration was, when I read it on 4 August 2026, still unanswered.

That 2021 date matters for a second reason: the privacy notice says data is stored on servers in the U.S., while the current docs advertise EU and Australian endpoints. The public-facing legal page and the engineering docs are describing different companies. Neither is lying; the notice simply hasn't been revised in nearly five years.

To be fair about the training claim itself, the MIP docs make an argument that's technically sound and worth repeating: a trained model "has no rote memory or storage for any of the data used to train it, meaning there is no risk of any data leakage when the model is used in production." Deepgram also commits that it will "never redistribute data to 3rd parties without our customers' permission" and that your data "will never be used to market our services or to create advertising profiles." The exposure isn't that a stranger will prompt your client's name out of Nova-4. It's that a recording of a confidential conversation is sitting in a vendor's training corpus with no published expiry.

Deepgram vs OpenAI, side by side

I wrote up OpenAI's retention policy last week, which makes the contrast easy. Both are reputable vendors; their defaults point in opposite directions.

Deepgram column from deepgram.com and developers.deepgram.com, read 4 August 2026; OpenAI column from OpenAI's own docs, read 28 July 2026. Both change — re-check before making a compliance decision.

The honest summary of that table: OpenAI's default is better and its escape hatch is worse. Deepgram will let any developer with a credit card opt out in one line; OpenAI makes you ask permission for the equivalent. If you're a small shop, Deepgram's control is the one you can actually reach — you just have to know it exists, which the footnote-sized disclosure doesn't help with.

Regions, redaction, and the things that don't fix this

EU and AU endpoints exist and are easy. Swap the base URL to api.eu.deepgram.com and your existing keys work; Deepgram guarantees EU hosting though not a specific country, and Whisper models aren't available in that region. api.au.deepgram.com runs on AWS Sydney with storage and inference in-country. Useful for GDPR posture, but note what it does and doesn't do: region controls where processing happens, not whether your audio joins the training program. Deepgram's own Australian-compliance note makes this explicit — for frameworks requiring that all processing occur in Australia, it's opting out of MIP that satisfies the requirement, not the AU endpoint alone.

Redaction is a transcript control, not a retention control. redact=pci|pii|phi is off by default and strips entities from the transcript you get back. Nothing in the docs says it changes what the Model Improvement Program keeps of your audio. Don't reason about it as a privacy setting for storage.

Self-hosting is the real answer, at enterprise scale. Deepgram ships containers for Docker/Podman and Kubernetes, a SageMaker listing, bare-metal deployment, even FIPS-capable images. Self-service licensing and image credentials are available in the Console — but only for projects "granted access to self-hosted products," and the docs are direct that getting there means enrolling in an Enterprise plan. It's an excellent option for a company with an ops team, and irrelevant to a consultant with a laptop.

The part your notetaking app decides for you

mip_opt_out=true goes in the URL of the request. If you're using Deepgram through someone else's app — a meeting notetaker, a transcription service, an internal tool a contractor wrote — you cannot add it. The app builds the URL. Your key just pays the bill.

This is the hole in the bring-your-own-key story that nobody, including me, has been advertising. BYOK genuinely gets you real things: your own account, your own bill, no unknown middleman pooling everyone's audio. What it does not get you is control over per-request privacy flags. "It's my key" and "it's my retention policy" are different sentences.

So: Humla does not currently send mip_opt_out=true. I checked the source while writing this. The Deepgram adapter posts your audio to api.deepgram.com/v1/listen with the model, smart formatting, punctuation, language, and your custom vocabulary as keyterms — and nothing else. If you picked Deepgram in Humla's settings, your meeting audio has been going to Deepgram on the opted-in default. The EU endpoint isn't selectable in the settings UI either, though the config struct has a slot for it.

That's a defect, not a design decision, and it's going on the fix list for the client. I'm writing it here in the same post that explains why it matters, because a privacy-first notetaker that quietly ships the training-on default is exactly the thing this blog spends its time criticising in other people's products. Until it ships, the accurate statement is: Humla with a Deepgram key inherits the opted-in default, same as any other app that hasn't set the flag.

Two things worth adding for fairness to Deepgram, both verified in Humla's source: Humla never asks Deepgram for speaker diarization — that runs offline on your Mac through a local sidecar — so no audio goes out for that, and no add-on gets billed. And your Deepgram key lives in the macOS Keychain, never in a Humla server, because there is no Humla server in this path at all; the request goes from your Mac straight to Deepgram.

What to actually do

If you write the code:

1. Add mip_opt_out=true to every Deepgram request, on every code path. Check the retries.
2. Switch to api.eu.deepgram.com or api.au.deepgram.com if residency matters to you.
3. If retention needs to be contractual rather than a query parameter, ask for the DPA — that's the only place a duration exists.

If you use somebody's app with your own key:

1. Ask the vendor, in writing, whether they set mip_opt_out. It's a yes/no question with a one-line answer, and a vendor who can't answer it hasn't read the docs you just read.
2. Assume "no" until told otherwise. That's the default, and defaults win.

Or don't send the audio anywhere.

The option of not sending it

Here's my bias, stated plainly: I think for meeting notes specifically, cloud speech-to-text is now optional, and I built a tool on that premise.

Humla records your microphone and the call's system audio with no bot in the meeting, and it can run Whisper on your Mac's GPU with offline speaker labels on the Neural Engine and summaries against a local model through Ollama. Configured that way there is no request, so there's no retention policy to read, no footnote to catch, no flag to remember. You can also mix per language — Norwegian local, English to a cloud provider, or the reverse. It's MIT-licensed, so the request-building code I just criticised is code you can read yourself.

The tradeoffs, honestly: on-device Whisper is slower than Nova-3 on a long meeting and wants a few gigabytes of model download; Deepgram is genuinely excellent at noisy, multi-speaker, far-field audio in a way local models still aren't; and Humla is Apple Silicon only, with no Windows, Linux or mobile. If your calls are hard audio and the content isn't sensitive, paying Deepgram half a cent a minute — opted out — is a perfectly sensible choice. If you're a lawyer or a therapist with a duty of confidentiality, the calculus is different, and "it's in a vendor's training set with no published expiry" is not a sentence you want to explain to a client.

The short version

Deepgram's retention story is not a scandal — it's a disclosure problem. The opt-out is one parameter, self-serve, documented with code samples in six languages, which is more than most vendors offer. But the default is participation in model training, the disclosure is a footnote under a pricing table, there is no published retention period for opted-in data, and the privacy notice that would tell you otherwise hasn't been updated since 2021.

The deeper point survives every policy revision: a retention promise is a setting on somebody else's computer, and in this case a setting you may not even be the one making. See what private actually means here and what runs locally.

All facts above verified against Deepgram's published pages and GitHub discussions on 4 August 2026, and all Humla claims against the app's source on the same date. These pages change; re-check before making a compliance decision on them.