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

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, 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) 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:

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 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, 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 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 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 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 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) applies conditional chunking logic:

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:

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:

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, 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, 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 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 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 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.

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