Summaries and providers

Setting Settings → Summarization → Provider to Auto, which is the default, means Oris tries the providers in order and summarizes with the first one that’s configured. The order it starts with is OpenAI, Anthropic, Azure OpenAI, Ollama, Local (mlx). A provider counts as ready only when everything it needs is filled in: a key for OpenAI or Anthropic, the endpoint, key and deployment together for Azure, and for Ollama a reachable server that actually has a model installed. Local (mlx) sits at the end as the guaranteed last resort, so Auto falls back to it even when nothing else is set up: Oris would rather run the on-device path and tell you if it failed than report that no provider was available.

The order reflects a simple bet. If you have paid for a cloud key you probably want it used, a local Ollama server is quicker than spinning up the on-device model, and the on-device model is the always-available free fallback that needs no account at all.

You can override the auto-pick at any time by choosing a specific provider in the same dropdown. An explicit choice is always honored, and the fallback order stops applying the moment you make one.

Changing the order

With Provider set to Auto, the Summarization tab shows a drag-reorderable list of every provider. Drag a row up or down and that becomes the order Oris tries. The change saves as you drop it, with no Save step, and each row tells you whether that provider is configured, so you can see at a glance which ones are actually in play. Providers you haven’t set up are skipped wherever they sit in the list, so it is fine to leave all of them listed and let the order matter only for the ones you use.

Leave the list alone and Oris uses the built-in order above.

When Auto lands on the on-device provider, the model it uses scales to the length of the transcript, so a standup doesn’t pay for a model sized for a strategy session. Pinning one model instead is a single field: see pinning one local model.

On-device: Local (mlx)

Local (mlx) summarizes on your Mac, using Apple’s MLX framework. No API key, no cost, and your transcript text stays on the machine along with the audio. It’s what Oris uses out of the box, and what Auto falls back to when no other provider is configured.

The only time it touches the network is to fetch a model. Oris downloads the default one for you during setup, so your first summary doesn’t stall on it, and any larger model is fetched once, the first time something actually needs it. See preparing the model for what that looks like while it’s happening.

Which model runs is picked from the length of the transcript: a short one gets the small model, a long one gets a bigger one. That choice is also capped by what your Mac can actually hold, so a long meeting on a smaller machine gets the best model that fits rather than one that would swamp it, which is what keeps a big transcript on a small machine from being the reason a summary fails. It can still fail, the same as any provider; summaries are best-effort everywhere, and the transcript lands regardless. To pin one model and skip the switching entirely, see pinning one local model.

Cloud and network providers

If you already pay for a cloud model, Oris will use it. The three cloud backends are bring-your-own-key, billed to you by the provider you chose, with nothing proxied through a service of ours. Ollama is the fourth option and works differently: it is a server you run yourself, on this Mac or another one on your network, so there is no key and no bill. What they share is that only the transcript text is sent, and only where you pointed it. The audio itself is never sent to them either way.

Pick the provider under Settings → Summarization → Provider, and the fields below it change to match:

• OpenAI — an API key, and an optional Model. Leave the model blank and Oris uses a fast, inexpensive default (gpt-4o-mini). This is the general-purpose choice.
• Anthropic — an API key, and an optional Model, defaulting to claude-haiku-4-5. The best summaries we have measured, at slightly more latency.
• Azure OpenAI — an Endpoint, an API key, a Deployment name, and an optional API version. For anyone whose keys live in an Azure tenant.
• Ollama — an Endpoint, pointing at http://localhost:11434 by default, and an optional Model. Leave the model blank and Oris uses the first model your Ollama server lists, so name one here if you care which.

Any of them changes which model writes the summary, not what the summary looks like. The shape is the same whichever backend runs: the same sections, the same transcript below it, the same footer naming what produced it.

Test connection

Each provider gets a Test button, on its card when you have picked that provider and on its row in the fallback list when the provider is Auto. It takes the values currently in the form, before you have recorded anything, and makes one small live request that exercises the key, the model name and the endpoint together. You get back either Connected or a specific error naming the actual problem, along the lines of “Invalid API key (401)”, “Model not found” or “Endpoint unreachable”. It’s a couple of seconds, and it’s a far better way to find out a key is wrong than a meeting that comes back without a summary.

Pinning one local model

By default the on-device summarizer picks its model from the length of the transcript. To use one model for everything instead, put a compatible HuggingFace repo id into the Model override field under Settings → Summarization → Local (mlx). Leave it blank and Oris goes back to choosing for you.

It’s worth pinning when you have benchmarked a particular model and want output you can compare across meetings, when you have already downloaded something larger and would rather it were always used, or when you want to try a different model family and see how its summaries read.

Turning summaries off

Turn off Enable summaries under Settings → Summarization and Oris skips the model call altogether. The transcript still lands in your note, just as a plain section rather than a collapsed one with a summary above it.

People turn this off for good reasons: you already process transcripts somewhere else, you would rather read the conversation yourself for the kind of thing you record, you’re keeping cloud spend down, or an on-device summary takes longer on your machine than you want to wait. Switch it back on whenever you like, and the next recording gets a summary again. Nothing about the recordings you made in between changes.

When a summary fails

Summarization is best-effort. If the provider is unreachable, the key is wrong, or the model comes back empty, the transcript is inserted into your note exactly as it would have been, with a ⚠️ block where the summary should be. Oris keeps the failure, so nothing about that recording is lost while you go and fix the cause.

Fixing the cause usually means a corrected key or a switch to a different provider under Settings → Summarization. Once that’s done, there are two ways to retry, and both run the same thing.

The Oris app’s recordings history shows a Retry button on any row whose summary failed. One click re-summarizes just that recording, the row spins while it works, and it settles into a green check when the summary lands.

Inside Obsidian, two commands cover the same loop without leaving the editor: Oris: Show failed summaries (no retry) lists what’s pending, and Oris: Retry failed summaries works through all of them and reports back.

The ⚠️ block in your note names the app first and Obsidian second. A recording made without Obsidian can land in the note of someone who doesn’t have Obsidian installed, so the app’s retry is the one route that always applies.

Either way, a retry reuses the transcript that already exists rather than re-transcribing the audio, so it takes as long as a summary and not as long as a meeting. On a file destination, an Obsidian vault or a Markdown folder, it then patches the original note in place, replacing the ⚠️ block with the real summary. A retry that fails again leaves the note untouched, ⚠️ block and all, and records the newer error against that recording instead. The note stays as it was, while the failure you see in the app’s history is always the most recent attempt.

An Apple Notes destination recovers differently, because patching a block inside a Notes note is not shipped yet. There, a successful retry delivers the fresh summary as its own note, titled Summary — <the original note's title>, in the same folder. The original note keeps its ⚠️ block as the pointer to where the summary went. Retrying again with the same summary doesn’t stack copies: the same content is recognized and lands once. Patching in place is planned.

A successful retry is also written down twice, each record with its own job: the note write lands through the delivery core and leaves a receipt naming the note it landed in, and the retry’s outcome is recorded against the recording itself, which is what heals the row in the recordings history to a green check.

When there was no note yet

A recording started without Obsidian has no note while it’s being summarized — the note is created afterwards, wherever your destination puts it. So when the summary fails on one of those, the failure Oris writes down doesn’t name a note, because at that moment there wasn’t one.

Retrying still finds it. Oris records where each recording’s note landed, and a retry with nothing else to go on asks the delivery core for that landing, then heals the note it actually created. You get the same result as any other retry: the ⚠️ block replaced on a file destination (or the sibling summary note created on Apple Notes), the sidecar cleared, a receipt written.

If the landing can’t be worked out, because the record of it was lost to a crash or a cleared state directory, the retry reports the attempt as unsuccessful. It leaves the recovered summary in a file next to the audio so the work isn’t lost, and keeps the failure so the Retry button stays where you can see it. The rule throughout this loop: a retry counts as a success only when the text reached the note you’d open.

How it works underneath

Every control on the Summarization tab

• Enable summaries — turn this off to skip the summary step entirely. The transcript still lands in your note. See turning summaries off.
• Provider — pick the backend: Auto, Local (mlx), Ollama, OpenAI, Anthropic, or Azure OpenAI. The credential fields below change to match the provider you selected, and values for all providers are kept, so switching back doesn’t lose them.

Each cloud or network provider gets its own card of labeled fields:

• OpenAI — API key, and an optional Model.
• Anthropic — API key, and an optional Model.
• Azure OpenAI — Endpoint, API key, Deployment, and an optional API version.
• Ollama — Endpoint, and an optional Model.
• Local (mlx) — no credentials, since it runs on your Mac. A Model override field pins one model instead of letting Oris pick by transcript length. See pinning one local model.

Every cloud and network provider gets a Test button, on its card when you have picked that provider and on its row in the fallback list when the provider is Auto. It checks the values currently in the form with a small live request that exercises the key, the model name, and the endpoint together, then shows either Connected or a specific error pointing at the exact problem. You find out a key is wrong in a second rather than after a meeting.

Fallback order

With Provider set to Auto, the tab shows a drag-reorderable list of providers. Drag them to set the order Oris tries, and each row tells you whether that provider is configured. Providers you haven’t set up are skipped wherever they sit in the list. See Changing the order.