Your own model for meetings: when a local server wins

What does the built-in model do with a meeting?

Out of the box, Meeting Notes writes with Gemma, the same on-device model that cleans up dictation. Recognition happens on your Mac, the write-up happens on your Mac, and the audio is never written to disk. Nothing has to be installed or configured, and nothing is sent anywhere.

Its limit is size, not privacy. The built-in model reads 8k tokens at a time, and Model, on a meeting's Setup tab, shows that number next to its name. That has to hold the instructions, the meeting's setup, a stretch of transcript and room for the answer, which leaves well under an hour of conversation per read.

A longer meeting is not cut off. It is read in parts, each part summarized, and the parts merged into one set of notes. Other write-ups, the chooser beside the write-up button, says how many passes an output will take whenever it is more than one, before you press anything, and a long call on the built-in model can mean several minutes of waiting at the end.

There is a ceiling. Notes are read in at most twelve parts. A meeting longer than that gets notes on its most recent stretch, and the result says so rather than presenting a partial meeting as a whole one. The four write-ups and what each is for are described in which write-up to ask for.

What changes with a local server?

A local server is a program such as Ollama or LM Studio that runs a model you chose, on hardware you control. Dictera has six of them preset: Ollama, LM Studio, llama.cpp server, Jan, vLLM, LocalAI. It talks to the server; it does not start it or download models into it.

Three things change when Meeting Notes uses one.

• The window. A model loaded with a 32k or 128k window reads a long call in one or two passes instead of eight. The pass count drops with it, and so does the wait.
• The model. You can run something larger than Gemma, if your Mac has the memory for it, or a model you already trust for summaries in your field.
• The machine. The server does not have to be your laptop. A desktop or a small server on your network can run a model that would make a laptop fan spin for the whole afternoon.

What does not change is where the call is heard. Both sides are still transcribed on your Mac. The engine only ever receives text: the transcript, the meeting's setup, and any screenshots you captured during the call.

Why not just use a cloud provider?

For many meetings, you could. A cloud model under your own key has a large window and needs no hardware. Dictera presets seven providers (OpenAI, OpenRouter, Groq, Mistral, DeepSeek, Together AI, xAI), and the key is kept in the macOS Keychain.

The difference is who reads the transcript. With a cloud provider, every meeting you write up is sent to that company, under your key and on its terms. That may be fine for a product sync. It is a different question for a performance review, a call with a client's lawyer, or a board meeting, and those are often the long meetings where the window matters most.

A local server answers that question the same way the built-in model does. The transcript goes from Dictera to a program you run, and the company that trained the model never sees it. The meetings that cannot have a bot in them are usually the same ones that cannot go to a cloud model either.

Does a server on another machine still count as private?

It depends on where it is, and Dictera draws the line in one place: a server at localhost is treated as this Mac, and anything else is treated as leaving it.

That is deliberate. A desktop in the next room is your hardware, but the transcript still crosses your network to reach it. When you add a server at any address other than localhost, the Add Model sheet warns you before you save. If the address is plain http, the warning adds that the text travels unencrypted. A server you run on a home or office network is usually fine; one on a shared or public network is the case the warning is there for.

macOS also stands in the way of the first connection. Reaching another machine on your network needs the Local Network permission, and if it is missing, Dictera says so and names the setting in System Settings ▸ Privacy & Security ▸ Local Network, rather than reporting a server that is merely down.

One more line is drawn around calendar names. If your calendar is connected, attendee names from the invite are part of the meeting's setup. Send attendee names to remote engines, in Settings ▸ Calendar, starts off, and while it is off those names go to the built-in model only. Any other engine, including a server on your own Mac, gets the meeting without them. The security page lists every destination the app can send to.

How big a window does Dictera think my model has?

It asks. When you click Test Connection, Dictera queries the server for the window of the model you named. llama.cpp, Ollama and LM Studio each report it in their own way, and when one does, the field is filled in for you. You can also type it yourself.

When nobody has said, Dictera assumes the model is as small as the built-in one. Guessing low means a meeting is read in more parts than it needed; guessing high means a request the server rejects or quietly truncates. If a server does reject a prompt as too long, Dictera lowers the number it has stored and tries again, so the mistake happens once.

The number that matters is the one the server loaded the model with, not the one on the model's card. Some servers load a model with a much smaller window than it supports unless they are told otherwise. If the passes count stays higher than you expected, that setting on the server is the first place to look.

Which model should I load for meetings?

The opposite of the advice for cleanup. Cleanup runs after every dictation, so a small, fast model is right; the wait shows up every time you stop talking. Meeting notes run once, after Stop, on a long input, and a minute of extra wait buys a better write-up.

• Prefer a larger window to a larger model. A mid-sized model that reads the whole meeting at once usually beats a bigger one that reads it in eight parts and merges the summaries.
• Check the language. The built-in model covers 140+ languages. A model you choose may cover far fewer, and the notes are only as good as the model is in the language the meeting was held in.
• Be careful with reasoning models. They spend part of the window thinking before they write, and on a long transcript that is window the meeting could have used.

Do I have to move everything to the server?

No. Assist, Meeting Notes and Chat each choose their own engine, and so do cleanup and translation. A common split is the built-in model for Assist, where a short answer during the call matters more than a long one, and a local server for Meeting Notes, where the whole meeting has to fit.

The setup is the one in pointing cleanup at Ollama or LM Studio: add the server in Settings ▸ Engine Models and test it. Then choose it under Model on a meeting's Setup tab, where each engine is listed with its window. Manage Models… in the same list opens the settings if it is not there yet.

So when is the built-in model enough?

For most short calls. A fifteen-minute standup fits in a pass or two, the write-up arrives quickly, and there is nothing to keep running in the background. If Other write-ups shows no pass count, or two at most, for the meetings you actually have, there is no reason to change anything.

The case for a local server starts when that number climbs: hour-long calls, workshops, interviews you need written up properly, on a model you choose and on hardware you control. Every engine Meeting Notes can use is listed on the features page, and the mode itself is described on the Meeting Notes page.