Freya is a local-first Tauri desktop assistant with a Freya-native frontend and native Rust/Tauri web-search and llama.cpp boundaries. It contains no cloned repository, no downloaded Jan source archive, no embedded external application, and no runtime dependency on Jan.
The implemented foundation includes persistent conversations, streamed offline responses, native llama.cpp process management for GGUF models, automatic backend detection and download, first-run model onboarding, automatic GGUF download into Freya’s local data directory, calculator and clock tools, web search and source normalization, page retrieval, citation-aware source cards, text-file attachments, opt-in SQLite-backed long-term memory for explicit preferences and personal facts, settings, local data reset, a native health command, and Freya product identity.
The frontend is bundled by Vite for the Tauri shell, while all desktop web-search execution runs natively through Rust/Tauri commands. On first launch, Freya checks its local data directory, offers to install the official llama.cpp Windows CPU backend, and downloads a compact Qwen2.5 GGUF starter model. After both are ready, Freya starts and health-checks llama-server automatically; users do not enter executable or model paths. When setup is unavailable or incomplete, Freya remains usable through its deterministic offline response path.
pnpm install
pnpm test
pnpm --filter @freya/desktop build
cargo check --manifest-path apps/desktop/src-tauri/Cargo.toml
cargo build --manifest-path apps/desktop/src-tauri/Cargo.toml
Run the Tauri desktop app with the repository’s normal desktop development command. No separate web-search Node process is required.
Runtime data belongs under the user-local Freya data directory selected by the platform adapter. Freya stores the downloaded llama.cpp runtime under Freya/runtime, GGUF models under Freya/models, and opt-in long-term memories in Freya/memories.sqlite. Memory persistence is implemented through the native Tauri command boundary and freya-storage; the frontend never writes directly to SQLite. Freya never depends on a Jan installation or source checkout.
Freya uses Exa as the primary web-search and page-fetch provider through native Rust/Tauri commands. Exa uses its keyless hosted endpoint by default; set FREYA_EXA_API_KEY before launching the Tauri app to use Exa’s keyed REST endpoints. Provider failures or empty results automatically fall back to DuckDuckGo. The settings page exposes the provider choice, fallback toggle, structured tool-calling toggle, and global web-search toggle; the chat composer also has a per-chat Web Search control.
The local model receives native OpenAI-compatible web_search and web_fetch tool definitions when structured tool calling is enabled. Freya keeps a prompt/JSON compatibility path for older llama.cpp models that reject explicit tool schemas. Search results and fetched pages are returned as first-class tool messages internally and as visible tool-event cards in the chat UI.