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

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 (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 (lines 13-14). The corresponding data structures in 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 and 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 and instantiated in 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 (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 (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 (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, passing the provider and model identifiers as parameters.

Invoking Ollama for local processing:

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:

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:

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 unifies Ollama, OpenAI, and compatible services under a single interface.
• Dynamic configuration: SQLite-backed settings in 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 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.

What happens if the Ollama server is unreachable?

The Ollama client implementation in 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}