# Where Are Whisper and Parakeet Models Stored and Loaded in Meetily? A Deep Dive into the Rust Backend > Discover where Meetily stores Whisper and Parakeet models and how its Rust backend loads them at runtime for efficient AI processing. Learn about production and development model locations. - Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily) - Tags: internals - Published: 2026-07-19 --- **Meetily stores Whisper and Parakeet models in OS-specific data directories during production (`~/Library/Application Support/Meetily/models/` on macOS, `%APPDATA%\Meetily\models\` on Windows) or in a local `./models/` folder during development, loading them at runtime through dedicated Rust engine structs that handle discovery, validation, and hardware-accelerated context initialization.** The open-source meeting assistant **Meetily** (Zackriya-Solutions/meetily) relies on two distinct speech recognition backends: OpenAI's Whisper and NVIDIA's Parakeet. Understanding where these model binaries reside and how the Tauri-based Rust backend loads them is critical for custom deployments and debugging. This article examines the exact file paths, discovery mechanisms, and runtime initialization flows defined in the source code. ## Whisper Model Storage Location in Meetily Meetily's Whisper implementation distinguishes between development and production environments using conditional compilation flags. The storage logic resides in `WhisperEngine::new_with_models_dir` within [`frontend/src-tauri/src/whisper_engine/whisper_engine.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/whisper_engine/whisper_engine.rs). ### Development vs. Production Paths In **development mode** (`cfg!(debug_assertions)`), the engine searches for a `models` directory relative to the current working directory: ```rust // https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/whisper_engine/whisper_engine.rs#L92-L124 if cfg!(debug_assertions) { if current_dir.join("models").exists() { current_dir.join("models") } else { // Fallback logic } } else { dirs::data_dir() .or_else(|| dirs::home_dir()) .ok_or_else(|| anyhow!("Could not find system data directory"))? .join("Meetily") .join("models") } ``` In **production**, models reside in the system's standard data directory under a `Meetily/models` subdirectory. On macOS, this resolves to `~/Library/Application Support/Meetily/models/`; on Windows, `%APPDATA%\Meetily\models\`; and on Linux, typically `~/.local/share/Meetily/models/`. ## How Meetily Loads Whisper Models at Runtime Once the directory is established, the `WhisperEngine` performs a structured discovery and loading sequence. ### Model Discovery and Catalog Validation The engine maintains a static catalog (`WHISPER_MODEL_CATALOG`) that maps logical names like `base` or `small` to physical filenames (e.g., `ggml-base.bin`). The `discover_models` method iterates this catalog, verifying each file's existence, size, and integrity via `validate_model_file` before constructing a `ModelInfo` list. ### Hardware-Aware Context Creation When the frontend invokes `load_model`, the engine checks if the requested model is already loaded to avoid redundant operations. If loading is required, it constructs `WhisperContextParameters` optimized for available hardware, then initializes the context: ```rust // https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/whisper_engine/whisper_engine.rs#L61-L66 let ctx = WhisperContext::new_with_params( &model_info.path.to_string_lossy(), context_param, )?; ``` This returns a `WhisperContext` capable of processing audio streams using the specified GGML binary. ## Parakeet Model Storage Location in Meetily The Parakeet engine follows a similar dual-path strategy but uses a nested subdirectory structure for ONNX models. The path resolution occurs in `ParakeetEngine::new_with_models_dir` at [`frontend/src-tauri/src/parakeet_engine/parakeet_engine.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/parakeet_engine/parakeet_engine.rs). ### Directory Structure and Path Resolution Development builds look for models in `./models/parakeet/`, while production builds use `/Meetily/models/parakeet/`: ```rust // https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/parakeet_engine/parakeet_engine.rs#L24-L46 if cfg!(debug_assertions) { current_dir.join("models").join("parakeet") } else { dirs::data_dir() .or_else(|| dirs::home_dir()) .ok_or_else(|| anyhow!("Could not find system data directory"))? .join("Meetily") .join("models") .join("parakeet") } ``` Each supported Parakeet variant (such as `parakeet-tdt-0.6b-v3-int8`) expects specific ONNX files within this directory. ## How Meetily Loads Parakeet Models at Runtime Parakeet loading involves quantization-aware initialization and strict status checking to prevent memory leaks from multiple loaded instances. ### ONNX Model Discovery and Quantization The `discover_models` method enumerates supported Parakeet builds and verifies the presence of required ONNX files. The `ModelInfo` struct tracks the `QuantizationType` (e.g., `Int8` or `FP16`). ### Model Instantiation and State Management Before loading, the engine checks `ModelStatus` and unloads any previously loaded model to free GPU memory. It then instantiates `ParakeetModel` with the appropriate quantization flag: ```rust // https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/parakeet_engine/parakeet_engine.rs#L96-L104 let quantized = model_info.quantization == QuantizationType::Int8; let model = ParakeetModel::new(&model_info.path, quantized)?; ``` The resulting handle is stored in `self.current_model`, making it available for transcription tasks. ## Frontend Integration: Tauri Commands Both engines expose asynchronous Tauri commands that the React/Next.js frontend invokes via the `@tauri-apps/api` bridge. ### Loading Models from the TypeScript UI The frontend triggers model loading through specific command strings mapped to the Rust implementations in [`whisper_engine/commands.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/whisper_engine/commands.rs) and [`parakeet_engine/commands.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/parakeet_engine/commands.rs): ```typescript import { invoke } from '@tauri-apps/api/tauri'; // Load Whisper "small" model async function loadWhisperModel() { try { await invoke('load_whisper_model', { modelName: 'small' }); console.log('Whisper model ready'); } catch (e) { console.error('Model load failed:', e); } } // Load quantized Parakeet model async function loadParakeetModel() { try { await invoke('parakeet_load_model', { modelName: 'parakeet-tdt-0.6b-v3-int8' }); } catch (e) { console.error('Parakeet load failed:', e); } } ``` These commands abstract the underlying directory traversal and hardware initialization, returning only success or error states to the UI. ## Summary - **Storage locations** are environment-dependent: `./models/` for development and OS-specific data directories (e.g., `~/Library/Application Support/Meetily/models/`) for production. - **Whisper models** are GGML binaries validated against a static catalog and loaded into a `WhisperContext` with hardware-specific parameters. - **Parakeet models** are ONNX files stored in a `parakeet/` subdirectory, loaded with quantization awareness via `ParakeetModel::new`. - **Runtime loading** is idempotent—duplicate load requests are ignored—and managed through Tauri commands (`load_whisper_model`, `parakeet_load_model`) that bridge the React frontend and Rust backend. - **Key files** include [`whisper_engine.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/whisper_engine.rs) and [`parakeet_engine.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/parakeet_engine.rs) for path resolution and loading logic, plus [`commands.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/commands.rs) files for UI integration. ## Frequently Asked Questions ### Where does Meetily store Whisper models on macOS after installation? In production builds on macOS, Meetily stores Whisper GGML binaries in `~/Library/Application Support/Meetily/models/`. This path is resolved at runtime using the `dirs::data_dir()` Rust crate, ensuring compliance with macOS application containerization standards. ### Can I customize the model directory path in Meetily? Yes. While the default implementation uses `WhisperEngine::new()` and `ParakeetEngine::new()` to auto-detect paths, both engines expose `new_with_models_dir` methods that accept a custom `PathBuf`. You can pass an absolute path to override the development/production defaults. ### How does Meetily handle missing or corrupted model files? Both engines implement validation before loading. `WhisperEngine::discover_models` checks file existence and size against the `WHISPER_MODEL_CATALOG`, while `ParakeetEngine` verifies required ONNX files. If validation fails, the engine returns an `anyhow::Error` that propagates to the frontend, preventing crashes from invalid model states. ### What hardware acceleration does Meetily use when loading these models? For Whisper, Meetily constructs `WhisperContextParameters` that detect available GPU layers and threads. For Parakeet, the `ParakeetModel::new` constructor accepts a `quantized` boolean (enabling INT8 inference) and leverages underlying ONNX Runtime optimizations for CUDA or DirectML, depending on the build configuration.