The Summary Decision: Local, Cloud, or Custom
Meetily’s summary decision begins after a transcript has been created and stored: which service or process should receive that text, and what controls shape the report that comes back? This chapter compares the local, cloud, and custom paths in the current application, then follows the prompt, template, context, language, cache, and cancellation logic that makes those choices meaningful. The goal is not to name one universal winner, but to give the reader a defensible way to choose a summary boundary for a particular meeting policy.
That distinction matters because summary generation is a new data transformation. The recognizer may have kept the original audio on the workstation, but the summary layer reads transcript text and optional user context. The place where that text is processed can be different from the place where the audio was recorded or transcribed.
The provider determines where transcript text goes
Meetily’s summary layer supports several provider categories. Ollama is addressed through a local endpoint by default. The built-in AI option runs a local model through a bundled sidecar process. OpenAI, Claude, Groq, and OpenRouter are named cloud-provider paths. A custom OpenAI-compatible endpoint can point to a service chosen by the user, whether that service is on the same machine, inside an organization’s network, or hosted elsewhere.
The common input is the transcript, with optional user-provided context. The summary service selects a provider, obtains the relevant model configuration and any needed API key from local settings, builds a request, and waits for the result in the background. What changes from one option to another is not only the URL. It is who performs inference, who controls the runtime, where the text travels, how much setup the operator owns, and which failure modes can interrupt the report.
A compact comparison helps, provided the criteria are interpreted rather than treated as a feature count:
| Summary path | Where inference is intended to run | Main boundary | Main operational cost | What the repository does not establish |
|---|---|---|---|---|
| Ollama | A user-selected local Ollama service, localhost by default | The configured endpoint and local model | Running and maintaining the local service and model | The privacy or security of a non-local custom Ollama endpoint |
| Built-in AI | A bundled local llama-helper sidecar |
The local process, model files, and host machine | Model download, memory, CPU/GPU capacity, and sidecar lifecycle | A benchmark or cryptographic provenance for every model file |
| Named cloud provider | The provider’s HTTPS API | Transcript text sent to that provider | API keys, network availability, provider policy, and service cost | Provider retention, training, or jurisdiction terms |
| Custom OpenAI-compatible endpoint | Wherever the configured endpoint runs | The user’s endpoint and its operator | Compatibility, network routing, and endpoint administration | Whether the endpoint is actually local, private, or trustworthy |
The first decision criterion is therefore information policy. If the rule is that transcript text must not leave the workstation, a local Ollama service or built-in AI path is the relevant class of option. If an organization operates an approved internal endpoint, custom OpenAI compatibility may provide a controlled middle path. If convenience, a familiar model, or remote capacity is more important, a named cloud provider may be acceptable—but the transcript crosses a boundary that Meetily cannot govern after submission.
The endpoint name alone does not settle the question. Ollama is local by default in the current code, but the service can be configured through an endpoint setting. A custom endpoint might be a private server inside an organization or a public host. “Custom” describes configurability, not locality. The operator must identify the network location and the party responsible for retention.
The same separation applies to API keys. For cloud providers, the summary service retrieves the key from the local settings store and attaches it to the provider-specific request. Ollama, the built-in AI route, and custom OpenAI-compatible handling use different configuration rules. Storing a key locally is not the same as keeping the transcript local: the key authorizes the request, while the provider location determines where the text is processed.