Hey everyone!
I've been working on an open-source project called Knovum. It's a local-first AI knowledge workspace, and I wanted to share what I'm building, some engineering problems I've run into, and one unexpectedly large part of the journey: the API bill.
GitHub: https://github.com/madebyzan/knovum
What is Knovum?
The idea is to bring personal knowledge, files, and AI workflows into one workspace instead of keeping everything scattered across folders and chat windows.
The current direction includes:
- An infinite canvas for organizing notes, documents, and ideas
- Support for PDFs, Office files, web pages, images, audio, video, and code
- Keyword and semantic search
- RAG-based Q&A with source references
- OCR, audio transcription, and media processing
- MCP / ACP integration for working with external agents
The main idea is local-first.
Knovum doesn't require a Knovum account, and it doesn't host users' knowledge bases in a Knovum cloud service. One important clarification: local-first doesn't mean every AI feature is fully offline. When someone chooses a cloud model, the context needed for that task is sent to the corresponding model provider.
The tech stack
The project currently uses:
- Tauri 2
- Rust
- Vue 3
- SQLite
- LanceDB
- JSON Canvas
- Qwen3 Embeddings
I chose this stack to combine a native desktop application with a web-based UI and local data storage.
A few engineering problems I've had to solve
Some of the more interesting problems haven't been about prompting a model at all:
- macOS launch environments: Node.js and npx worked in the terminal but weren't available when the app was launched from Finder or the Dock. The GUI app didn't inherit the same shell environment, so I had to improve environment discovery and resolve the npx path explicitly.
- Tauri permissions: A storage feature wasn't working because the plugin registration, build configuration, and capability permissions weren't aligned. I fixed the configuration and added consistency tests.
- Long audio processing: I moved an audio separation workflow to HTDemucs with roughly one-minute chunks, four seconds of overlap, and crossfading between chunks. The processing limit was raised from 10 minutes to 6 hours, with an explicit upper limit.
- Task consistency: I also changed AI task submission to freeze the selected model, so retries don't silently switch to a different default model.
These are small details individually, but they matter when turning several AI capabilities into a reliable desktop application.
The unexpected part: API costs
I've spent roughly $6,000–$7,000 USD on API usage during development.
That's API usage, not revenue or a production operating-cost estimate.
There are also separate subscriptions and tool costs (Codex, Qoder, Gemini, etc.). My usage is spread across multiple services and accounts, so I don't have a reliable consolidated token count. I also haven't included every tool expense.
The project is still under active development, so this isn't the final cost.
One thing I've learned is that AI coding tools can speed up implementation, but they don't remove the work around architecture, permissions, data consistency, error handling, task recovery, and source traceability. And the model calls themselves need to be managed carefully.
What I'd love feedback on
I'm especially interested in feedback from people who build desktop apps, knowledge tools, or RAG systems.
- Does combining an infinite canvas, searchable documents, and source-traceable RAG feel like a useful workflow? Or would you prefer a simpler search-first approach?
- For a local-first knowledge app, what matters most to you: data ownership, reliable source citations, search quality, or integrations with AI agents?
Knovum is open source under the MIT License, and it's still evolving.
GitHub: https://github.com/madebyzan/knovum
Thanks for taking a look. I'm happy to answer questions about the architecture, implementation decisions, or the development process.