# How Meetily Integrates with Ollama, OpenAI, and Other AI Services for Summaries

> Discover how Meetily integrates with Ollama, OpenAI, and more for local AI summaries. Explore its provider-agnostic Rust architecture for flexible LLM selection and private audio processing.

- Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily)
- Tags: how-to-guide
- Published: 2026-07-30

---

**Meetily implements a provider-agnostic Rust architecture that routes meeting transcripts to Ollama, OpenAI, Groq, Claude, or custom OpenAI-compatible endpoints through a unified LLM client interface, ensuring all audio processing remains local while supporting flexible LLM selection.**

Meetily is a privacy-first desktop meeting assistant built with Tauri and Rust that generates AI summaries without transmitting raw audio data to external servers. The application achieves this by implementing a sophisticated provider-agnostic architecture in its Rust backend, allowing seamless integration with local LLMs via Ollama or cloud-based services like OpenAI. This article examines the technical implementation of how Meetily integrates with Ollama, OpenAI, and other AI services for summaries, tracing the flow from frontend invocation to LLM response generation according to the Zackriya-Solutions/meetily source code.

## The Provider-Agnostic Architecture

Meetily's summary engine centers on the **provider abstraction** defined by the `LLMProvider` enum in [`frontend/src-tauri/src/summary/llm_client.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/llm_client.rs) (lines 66-68), which enumerates all supported AI providers including Ollama, OpenAI, Groq, Claude, and OpenRouter. This abstraction allows the application to treat every LLM service uniformly, regardless of whether it runs locally or in the cloud.

The `LLMClient::new()` constructor accepts the provider type along with endpoint configurations and API keys, returning a concrete client implementation that handles provider-specific HTTP semantics. For **Ollama**, this means targeting `http://127.0.0.1:11434` by default, while **OpenAI** clients target either the official endpoint or a custom OpenAI-compatible URL specified in user settings.

## Configuration Management and Storage

All provider-specific credentials and endpoints persist in a local SQLite database managed by the `SettingsRepository` in [`frontend/src-tauri/src/database/repositories/setting.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/database/repositories/setting.rs) (lines 13-14). The corresponding data structures in [`frontend/src-tauri/src/database/models.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/database/models.rs) (lines 86-94) define fields for `ollama_endpoint`, `ollama_api_key`, `custom_openai_endpoint`, and service-specific API keys.

When a user generates a summary, the application queries these stored settings to configure the LLM client dynamically. This architecture eliminates hardcoded credentials and allows users to switch between providers without restarting the application.

## The Summary Generation Pipeline

The summary generation process follows a strict pipeline orchestrated through [`frontend/src-tauri/src/summary/service.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/service.rs) and [`frontend/src-tauri/src/summary/processor.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/processor.rs). The backend handles transcription locally using Whisper, then routes the resulting text through the LLM abstraction layer.

### Step 1: Metadata Caching for Local Models

For Ollama integration specifically, Meetily implements a **ModelMetadataCache** defined in [`frontend/src-tauri/src/ollama/metadata.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/ollama/metadata.rs) and instantiated in [`frontend/src-tauri/src/summary/service.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/service.rs) (lines 23-26). This cache stores Ollama model metadata—such as context window lengths—for five minutes, reducing redundant API calls to the local Ollama server when processing multiple summaries in succession.

### Step 2: Client Initialization and Routing

The system constructs the appropriate client based on the `provider` parameter passed from the frontend. In [`frontend/src-tauri/src/ollama/ollama.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/ollama/ollama.rs) (lines 11-13), the Ollama wrapper handles local HTTP API calls including `get_ollama_models`, `pull_ollama_model`, and chat completions. Conversely, [`frontend/src-tauri/src/openai/openai.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/openai/openai.rs) (lines 104-105) implements the OpenAI-compatible protocol for cloud providers, supporting both the official `https://api.openai.com/v1/chat/completions` endpoint and custom enterprise URLs.

For custom OpenAI endpoints, the client uses the `custom_openai_endpoint` field from settings instead of the default, enabling enterprise deployments and OpenRouter integrations without code modifications.

### Step 3: Template Processing and Execution

Once initialized, the client receives a language-aware prompt generated by the **template system** in `frontend/src-tauri/src/summary/templates`. The `generate_meeting_summary` function in [`frontend/src-tauri/src/summary/processor.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/processor.rs) (line 323) orchestrates this conversion, transforming raw meeting markdown into structured prompts optimized for the selected model's context window.

The LLM client then executes the HTTP request, and the Rust backend caches the English-language response before emitting it to the UI via Tauri events. This caching layer prevents redundant API calls when regenerating summaries for the same meeting content.

## Frontend Integration Examples

The TypeScript frontend invokes summary generation through Tauri commands registered in [`frontend/src-tauri/src/lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/lib.rs), passing the provider and model identifiers as parameters.

**Invoking Ollama for local processing:**

```typescript
import { invoke } from '@tauri-apps/api/tauri';

async function summarizeWithOllama(meetingId: string) {
  const result = await invoke<string>('generate_meeting_summary', {
    meetingId,
    provider: 'ollama',
    model: 'llama3:8b',
    whisperModel: 'small',
  });
  console.log('Summary:', result);
}

```

**Using a custom OpenAI-compatible endpoint:**

```typescript
await invoke<string>('generate_meeting_summary', {
  meetingId,
  provider: 'custom-openai',
  model: 'gpt-4o-mini',
  customOpenaiEndpoint: 'https://my.company.ai/v1/chat/completions',
});

```

**Rust client construction:**

```rust
let client = LLMClient::new(
    provider,                         // LLMProvider enum variant
    ollama_endpoint,                  // Option<&str>
    custom_openai_endpoint,           // Option<&str>
    api_key,                          // Option<String>
).await?;
let response = client.generate(prompt).await?;

```

## Privacy-First Local Processing

Unlike cloud-based meeting assistants, Meetily's architecture preserves privacy by executing transcription and LLM orchestration entirely within the Rust backend. Raw audio and transcript data never leave the user's device, even when using cloud LLMs—only the processed text summary gets transmitted to the selected AI provider. This local-first approach, implemented without any external backend dependency, positions Meetily as a secure alternative for organizations handling sensitive meeting content.

## Summary

- **Provider abstraction:** The `LLMProvider` enum in [`llm_client.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/llm_client.rs) unifies Ollama, OpenAI, and compatible services under a single interface.
- **Dynamic configuration:** SQLite-backed settings in [`database/repositories/setting.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/database/repositories/setting.rs) store endpoints and API keys for seamless provider switching.
- **Performance optimization:** A five-minute metadata cache for Ollama models reduces redundant local API calls.
- **Flexible deployment:** Support for custom OpenAI-compatible endpoints enables enterprise and OpenRouter integrations.
- **Privacy preservation:** All orchestration happens locally in Rust, with only final summary requests sent to external LLMs.

## Frequently Asked Questions

### How does Meetily handle API authentication for different providers?

Meetily stores provider-specific API keys and endpoints in a local SQLite database managed by `SettingsRepository`. When initializing the `LLMClient`, the system retrieves these credentials from [`database/models.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/database/models.rs) structures and injects them into HTTP headers for OpenAI-compatible requests or the Ollama client constructor. This allows the application to support multiple providers simultaneously without exposing credentials in frontend code.

### Can I use Meetily with a self-hosted LLM that isn't Ollama?

Yes. Meetily supports any OpenAI-compatible HTTP endpoint through the `custom-openai` provider type. By specifying your self-hosted endpoint URL in the `custom_openai_endpoint` field and providing the appropriate API key in settings, the application routes requests to your local vLLM, LM Studio, or Text Generation Inference instance using the standard OpenAI chat completions format implemented in [`openai/openai.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/openai/openai.rs).

### What happens if the Ollama server is unreachable?

The Ollama client implementation in [`ollama/ollama.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/ollama/ollama.rs) wraps HTTP calls to the local endpoint (default `http://127.0.0.1:11434`). If the server is unavailable, the Rust backend returns a connection error through the Tauri command interface, which the frontend handles gracefully. The five-minute metadata cache in [`summary/service.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/summary/service.rs) lines 23-26 also prevents excessive retry attempts when the service is temporarily down.

### Does Meetily support switching between providers for different meetings?

Absolutely. The `generate_meeting_summary` Tauri command accepts the `provider` and `model` parameters for each invocation, allowing users to summarize one meeting with a local Ollama model and another with OpenAI's GPT-4o without changing global settings. The `SettingsRepository` simply provides default configurations, while per-request overrides determine the actual LLM client instantiation in [`llm_client.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/llm_client.rs).