# How Meetily Integrates with Multiple AI Providers: Ollama, Claude, Groq, and OpenRouter

> Discover how Meetily integrates with Ollama, Claude, Groq, and OpenRouter using a unified interface. Learn about its flexible LLM client abstraction layer.

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

---

**Meetily uses a flexible LLM client abstraction layer in its Tauri backend to route requests between Ollama, Claude, Groq, OpenRouter, and other providers through a unified interface.**

Meetily is an open-source meeting assistant built by Zackriya-Solutions that leverages various large language models for transcript summarization. The application achieves seamless multi-provider support through a modular Rust backend architecture that standardizes authentication, request formatting, and model discovery across disparate AI services.

## Provider Abstraction Architecture

The foundation of Meetily’s multi-provider support lies in a centralized enumeration that defines all supported backends. 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), the `LLMProvider` enum variants include:

- **OpenAI** – Default cloud provider
- **Claude** – Anthropic’s Claude models
- **Groq** – Groq’s OpenAI-compatible API
- **Ollama** – Local Ollama server requiring no API key
- **OpenRouter** – OpenRouter model marketplace
- **BuiltInAI** – Internal endpoints
- **CustomOpenAI** – User-supplied custom endpoints

The enum implementation provides a `from_str` conversion method and a `provider_name` helper for human-readable labels. This abstraction allows the rest of the codebase to treat providers interchangeably while preserving type safety.

## Request Routing and Service Layer

The **summary service** ([`frontend/src-tauri/src/summary/service.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/service.rs)) orchestrates the flow between the frontend and AI providers. When the UI invokes the `summarize` command, the service performs four critical operations:

1. Parses the provider string into an `LLMProvider` enum using `LLMProvider::from_str()`
2. Retrieves the API key only for cloud providers (skipping authentication for local options)
3. For Ollama, optionally reads a custom endpoint defaulting to `http://127.0.0.1:11434`
4. Passes normalized data to the LLM client for HTTP payload construction

The API key logic explicitly excludes local providers:

```rust
let provider = LLMProvider::from_str(&model_provider)?;
let api_key = if provider == LLMProvider::Ollama
              || provider == LLMProvider::BuiltInAI
              || provider == LLMProvider::CustomOpenAI {
    None
} else {
    Some(user_provided_key)
};

```

## Provider-Specific Implementation Modules

Each AI service integrates through dedicated modules that handle unique authentication schemes, model discovery, and request formatting.

### Ollama Local Integration

The [`frontend/src-tauri/src/ollama/ollama.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/ollama/ollama.rs) module manages local AI inference without API keys. It validates the endpoint configuration, discovers available models via the `/api/tags` endpoint, handles automatic model downloads, and constructs Ollama-specific request bodies for local processing.

### Claude (Anthropic) Integration

Located in [`frontend/src-tauri/src/anthropic/anthropic.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/anthropic/anthropic.rs), this module defines Claude model listings and builds Anthropic-specific JSON schemas. It injects the required `anthropic-version` header and manages the distinct message format that Claude expects compared to OpenAI-compatible endpoints.

### Groq Cloud Integration

The [`frontend/src-tauri/src/groq/groq.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/groq/groq.rs) module queries Groq’s `/v1/models` endpoint and caches results for the model picker. Despite Groq’s distinct infrastructure, it uses a standard OpenAI-style request schema, allowing Meetily to reuse existing serialization logic while adding Groq-specific authentication headers.

### OpenRouter Marketplace

[`frontend/src-tauri/src/openrouter/openrouter.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/openrouter/openrouter.rs) retrieves the OpenRouter model catalog and sets the `Authorization` header with the user’s OpenRouter API key. This module handles the unified routing that OpenRouter provides to hundreds of underlying models through a single consistent interface.

### Custom and Built-in Endpoints

For enterprise or self-hosted scenarios, [`frontend/src-tauri/src/summary/summary_engine/client.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/summary_engine/client.rs) supports custom OpenAI-compatible endpoints. Users can point Meetily at privately hosted LLM servers while maintaining the same interface as commercial providers.

All modules expose a standardized signature: `fn get_<provider>_models(...) -> Result<Vec<Model>, String>`, enabling the UI to display a unified model selection interface regardless of the backend source.

## Unified Request Handling and Token Management

The [`llm_client.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/llm_client.rs) file centralizes HTTP communication through `reqwest::Client`. It selects appropriate request bodies—using generic OpenAI schemas for most providers while applying Claude’s distinct structure when necessary—and attaches provider-specific headers dynamically.

Token limit handling varies by provider capability. The summary processor ([`frontend/src-tauri/src/summary/processor.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/processor.rs)) applies conditional chunking logic:

```rust
if (provider != &LLMProvider::Ollama && provider != &LLMProvider::BuiltInAI)
   || total_tokens < token_threshold { … }

```

Local providers (Ollama and BuiltInAI) receive full transcripts since they operate without strict token limits, while cloud providers receive intelligently chunked content to respect their constraints.

## Frontend Integration Example

The frontend invokes summarization through Tauri’s command system without concerning itself with provider-specific details:

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

async function summarize(meetingId, provider) {
  const result = await invoke('summarize', {
    meetingId,
    modelProvider: provider, // "ollama", "claude", "groq", "openrouter"
  });
  return result;
}

```

On the backend, request construction adapts to the selected provider:

```rust
let request_body = if provider != &LLMProvider::Claude {
    serde_json::json!({
        "model": model_name,
        "messages": messages,
        "max_tokens": max_tokens,
        "temperature": temperature,
    })
} else {
    // Claude uses its own request struct
    serde_json::json!(ClaudeRequest { … })
};

```

## Summary

- Meetily supports seven provider types through the `LLMProvider` enum in [`llm_client.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/llm_client.rs), including Ollama, Claude, Groq, and OpenRouter.
- The summary service routes requests based on provider type, conditionally requiring API keys only for cloud services while allowing local Ollama instances to run without authentication.
- Provider-specific modules handle unique requirements: Ollama manages local endpoints, Claude requires special headers and request formats, while Groq and OpenRouter use OpenAI-compatible schemas with custom authentication.
- Token management adapts to provider capabilities, sending full transcripts to local models while chunking content for cloud APIs with stricter limits.
- The architecture exposes a single Tauri command to the frontend while managing provider complexity transparently in the Rust backend.

## Frequently Asked Questions

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

Meetily only requires API keys for cloud-based providers. According to the logic in [`frontend/src-tauri/src/summary/service.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/service.rs), the application returns `None` for the API key when the provider is `Ollama`, `BuiltInAI`, or `CustomOpenAI`, allowing these local or internal endpoints to operate without external authentication. For OpenAI, Claude, Groq, and OpenRouter, the application retrieves the user-provided key from secure storage and attaches it to request headers.

### Can Meetily work completely offline with local AI models?

Yes. By selecting the **Ollama** provider, Meetily routes all inference requests to a local Ollama server running on `http://127.0.0.1:11434` (or a custom endpoint). The [`ollama.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/ollama.rs) module discovers available models through the local `/api/tags` endpoint and handles model downloading without requiring internet connectivity or API keys, enabling fully offline meeting summarization.

### How does Meetily manage different token limits across providers?

The [`processor.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/processor.rs) module implements provider-aware token handling. Local providers like Ollama and BuiltInAI receive complete meeting transcripts since they can handle larger contexts, while cloud providers receive chunked content when transcripts exceed defined thresholds. This ensures optimal performance without exceeding provider-specific rate limits or context windows.

### Is it possible to add custom OpenAI-compatible endpoints to Meetily?

Yes. The `CustomOpenAI` variant in the `LLMProvider` enum allows users to configure self-hosted or third-party OpenAI-compatible servers. The summary engine client in [`summary/summary_engine/client.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/summary/summary_engine/client.rs) handles these custom endpoints using standard OpenAI request schemas while skipping default API key requirements, enabling integration with private LLM deployments or alternative hosting providers.