Omni-Dashboard

An AWESOME App that is EVERYTHING a Student needs with NO distractions. Fully LOCAL-AI Powered. It is completely OFFLINE-CAPABLE, with NO TELEMETRY.

Comment

Inspiration

Students and developers often struggle with fragmented productivity tools, expensive subscriptions, constant online distractions, and privacy concerns from cloud-based AI services. Omni-Dashboard (Omni-Core) was created to solve these issues by providing an all-in-one, local-first platform designed to enforce focus, maintain strict data sovereignty, and help users optimize their study and work habits without relying on third-party cloud infrastructure.

What it does

Omni-Dashboard replaces fragmented SaaS productivity applications with an offline desktop environment. The Observer Effect runs an active background telemetry thread that monitors system activity every 10 seconds, categorizing time into "Deep Work" or "Distraction." This live memory AI stream feeds real-time system activity directly into a local AI assistant, allowing it to hold users accountable, offer personalized coaching, and interact using ten distinct personas. Through the Autonomous Neural Action Bridge, the AI executes commands directly within the app using structured text tags to create tasks, schedule calendar events, start Pomodoro timers, and complete or delete records. Additionally, the Local RAG & PDF Textbook Engine ingests large academic textbooks, parses page contents using lopdf, and performs heuristic keyword scoring to surface relevant context directly to the local AI model with accurate page citations. For focus sessions, an integrated Multimodal Audio & Offline Music Vault offers local voice generation via the Piper TTS engine and includes a local YouTube audio fetcher (yt-dlp) for ad-free offline playlists.

How I built it

The core stack is engineered around a local-first architecture. The frontend is built with React, TypeScript, Vite, and Tailwind CSS. The backend is powered by Rust using Tauri v2 and tokio for thread management to prevent UI freezing during background operations. All local data relies on an SQLite database configured in Write-Ahead Logging mode to handle concurrent writes from the telemetry observer and chat sessions. The system interfaces locally with Ollama (@ 127.0.0.1:11434) running lightweight open models such as llama3.2:3b, qwen2.5-coder:3b, phi4-mini, and nemotron-mini. Finally, the audio pipeline integrates Piper TTS for speech synthesis and yt-dlp for offline media management.

Challenges I ran into

Local LLMs consume significant RAM and VRAM, so a dynamic purging system was implemented to terminate and flush previous models from memory when switching tasks to avoid system crashes. Getting smaller, local LLMs to produce structured outputs reliably was solved by designing a regex-free tokenizer parsing simple bracketed tags, paired with string normalization and delay mechanisms to avoid database ID collisions. Additionally, running a continuous background thread logging system activity while simultaneously handling read/write commands required enabling SQLite WAL mode to ensure asynchronous database operations without locking up the application.

Accomplishments that I am proud of

I am proud that I successfully built a zero-cloud application capable of running RAG on dense textbooks, voice synthesis, live telemetry tracking, and task scheduling strictly on local hardware. We developed an un-bypassable activity tracking system that injects user activity directly into LLM prompts for personalized, real-time accountability. We also engineered a reliable action-execution pipeline that bridges local AI model outputs directly into database actions without using external APIs or cloud dependencies.

What I learned

Designing desktop software around a Local-First Architecture requires strict memory, thread, and process management, particularly when bundling embedded databases with local inference engines. Constraining small language models through structured tag-based formats drastically improves output reliability compared to expecting raw code or complex JSON formats from lightweight local models. We also learned that asynchronous concurrency models in Rust (like tokio) are essential for handling continuous background processes without compromising frontend UI responsiveness.

What's next for Omni-Dashboard

Next, we plan to implement system audio capture (WASAPI loopback) to transcribe and summarize live online classes or meetings in real-time. We also aim to optimize builds across Linux and macOS environments to ensure feature parity with Windows builds. Finally, we intend to refine system prompts and voice models to expand custom personality modes for tailored productivity feedback.

Built With

Share this project:

Updates

Submission history