How the Meetily Ollama Module Communicates with Local LLM Servers via the OpenAI-Compatible API

The Meetily Ollama module uses Rust-based HTTP clients to send OpenAI-compatible requests to local Ollama servers, enabling seamless AI-powered meeting summaries without external API keys.

The Ollama integration in Meetily transforms locally-running LLM servers into OpenAI-compatible endpoints, enabling seamless AI-powered meeting summaries without external API dependencies. This architecture, implemented in the Tauri Rust backend under frontend/src-tauri/src/ollama/, treats your local Ollama instance as a standard HTTP service using the OpenAI chat completion schema.

Endpoint Configuration and Localhost Detection

The module determines the target server through the ollama_endpoint configuration parameter. If no endpoint is provided, it defaults to http://localhost:11434.

In frontend/src-tauri/src/ollama/ollama.rs (lines 68-78), the helper function is_localhost_endpoint evaluates whether the configured endpoint points to a local instance. This distinction matters because the module falls back to CLI commands when HTTP requests fail against non-localhost endpoints.

OpenAI-Compatible Request Construction

When generating summaries, the generate_summary function in frontend/src-tauri/src/summary/llm_client.rs matches against LLMProvider::Ollama to construct OpenAI-compatible HTTP requests.

The request URL follows the OpenAI chat completions pattern:

let host = ollama_endpoint.unwrap_or_else(|| "http://localhost:11434".to_string());
let api_url = format!("{}/v1/chat/completions", host);

The request body uses a ChatRequest struct that mirrors the OpenAI payload format, containing:

• model: The specific Ollama model identifier (e.g., llama3.2:1b)
• messages: Array of chat messages with roles and content
• max_tokens: Optional token limit
• temperature: Sampling temperature
• top_p: Nucleus sampling parameter

Source: llm_client.rs lines 64-71 and 151-170.

HTTP Headers and Authentication

Unlike cloud LLM providers, Ollama does not require API key authentication. The module sends only standard HTTP headers:

// Content-Type: application/json
// No Authorization header required

This implementation appears in llm_client.rs lines 200-210 within the LLMProvider::Ollama match arm, where the header map remains minimal compared to other providers.

HTTP Client Configuration and Timeouts

The module utilizes a shared reqwest::Client instance configured with a 300-second timeout to accommodate potentially slow local inference on consumer hardware. The client supports optional cancellation for long-running requests.

Source: llm_client.rs lines 58-66.

Response Parsing and Content Extraction

Responses from the Ollama server conform to the OpenAI chat completion schema. The module parses JSON into a generic ChatResponse struct, extracting the generated content from choices[0].message.content.

Source: llm_client.rs lines 99-107 and 111-119.

Model Lifecycle Management

The Ollama module provides comprehensive model management through the OpenAI-compatible API and native Ollama endpoints.

Listing Available Models

The get_ollama_models function attempts an HTTP GET request to /{endpoint}/api/tags. If the HTTP request fails (particularly for non-localhost endpoints), it automatically falls back to executing the ollama list CLI command.

Source: ollama.rs lines 96-110, 118-131, and 162-183.

Pulling Models with Progress Streaming

To download new models, pull_ollama_model sends a POST request to /{endpoint}/api/pull with stream: true in the request body. The implementation handles NDJSON streaming responses, parsing progress fields like completed and total to calculate download percentages.

The function emits Tauri events throughout the process:

• ollama-model-download-progress during download
• ollama-model-download-complete on success
• ollama-model-download-error on failure

Source: ollama.rs lines 260-332, 336-380, and 424-430.

Deleting Models

Model removal occurs through delete_ollama_model, which sends a DELETE request to /{endpoint}/api/delete.

Source: ollama.rs lines 436-470.

Context Size Caching

The module maintains a ModelMetadataCache to avoid redundant API calls for model metadata. The get_ollama_model_context function queries this cache, which internally fetches context_size from the /api/tags endpoint.

Source: ollama.rs lines 77-89 and 95-104.

Implementation Examples

TypeScript Frontend Integration

Call the Rust backend from your frontend to generate summaries using Ollama:

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

async function summarizeWithOllama(text: string) {
  const result = await invoke<string>('generate_summary', {
    provider: 'ollama',
    modelName: 'llama3.2:1b',
    apiKey: '',                     // Not required for Ollama
    systemPrompt: 'Summarize the meeting.',
    userPrompt: text,
    ollamaEndpoint: 'http://localhost:11434' // Optional
  });
  console.log('Summary:', result);
}

This invocation routes through generate_summary in llm_client.rs, which constructs the OpenAI-compatible HTTP request to your local Ollama server.

Listing Models in Rust

use crate::ollama::get_ollama_models;

#[tauri::command]
async fn list_models() -> Result<Vec<OllamaModel>, String> {
    // Uses the default localhost endpoint
    get_ollama_models(None).await
}

Pulling Models with Progress Tracking

use crate::ollama::pull_ollama_model;
use tauri::AppHandle;

#[tauri::command]
async fn download_model(app: AppHandle, model: String) -> Result<(), String> {
    pull_ollama_model(app, model, None).await
}

During execution, the Rust code streams NDJSON lines from the Ollama API, calculates progress percentages, and emits Tauri events that your UI can observe to display download progress bars.

Summary

• The Meetily Ollama module communicates via HTTP using reqwest clients to OpenAI-compatible endpoints at /v1/chat/completions.
• Default configuration targets localhost at http://localhost:11434 with automatic fallback to CLI commands for remote endpoints.
• No authentication required—Ollama servers run locally without API keys, using only standard JSON content headers.
• Full model lifecycle support includes listing via /api/tags, pulling with streaming NDJSON progress, and deleting via /api/delete.
• Meeting summaries use standard OpenAI schemas for requests and responses, ensuring compatibility with any Ollama version supporting the OpenAI API format.

Frequently Asked Questions

What endpoint does Meetily use to communicate with Ollama?

Meetily defaults to http://localhost:11434 but accepts custom endpoints through the ollama_endpoint parameter. The module constructs OpenAI-compatible chat completion URLs by appending /v1/chat/completions to the configured host, as implemented in llm_client.rs lines 64-71.

Does the Ollama module require an API key?

No. The Ollama module sends requests without authentication headers, as local Ollama servers do not implement API key security. The header map in llm_client.rs (lines 200-210) includes only Content-Type: application/json for Ollama requests, leaving the authorization field empty.

How does Meetily handle model downloads from Ollama?

The pull_ollama_model function in ollama.rs streams download progress by posting to /api/pull with stream: true, parsing NDJSON response lines to extract completed and total byte counts. It emits Tauri events (ollama-model-download-progress) that frontend applications can subscribe to for real-time progress updates.

What happens if the Ollama HTTP server is not running?

If the HTTP request to the Ollama endpoint fails and the target is not localhost, the get_ollama_models function falls back to executing the ollama list CLI command directly. For summary generation, however, a running HTTP server is required since the generate_summary function relies exclusively on the OpenAI-compatible HTTP API rather than CLI fallbacks.

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