Chakor: Your AI, on Your Hardware

Overview

Chakor is an open-source AI workspace that runs entirely on hardware you control. Point it at a local model or your own API keys, then chat, search the web, talk to your documents, compare models side by side, and run real research. Conversations live in a SQLite database on your disk, not in someone else's data center. It is a lighter, friendlier alternative to Open WebUI and an open-source answer to LM Studio that also runs on a server and on your phone.

Three things set it apart: it reads your RAM and GPU and tags every model FITS, TIGHT, or TOO BIG so you never load one that crashes; it downloads GGUF models from Hugging Face in the background straight into your models folder; and it switches between llama.cpp, Ollama, and LM Studio in one tap, freeing the previous model first so two never fight for the same VRAM.

Architecture Overview

One file, no database server: better-sqlite3 keeps the whole workspace in a single SQLite file, which makes backup and migration trivial. The tradeoff is write serialization, so WAL mode and short transactions matter once multiple users write concurrently; read-heavy single-node use is where this design shines.

Quick Start

Pick whichever fits you. All three end with the app on http://localhost:3001. The first account you register becomes the admin. The default registration mode is invite; the default invite code is change-me, so change INVITE_CODE in your .env before exposing the app. For a solo setup, you can set REGISTRATION_MODE=open instead.

Get a Model

Chakor needs something to talk to. The simplest route is Ollama; Chakor auto-discovers its installed models.

• llama.cpp: point LLAMA_SERVER_BIN at your llama-server and Chakor supervises it. No model yet? Use Settings → Models → Download from Hugging Face, with a fit tag per quant.
• Cloud keys: set OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_AI_API_KEY, or one OPENROUTER_API_KEY for hundreds of models.
• Hardware-aware: Settings → Models shows detected RAM/GPU and marks each model FITS, TIGHT, or TOO BIG with a RECOMMENDED pick.

How Model Switching Works

Switch model per message from the chat header, flip engines (llama.cpp / Ollama / LM Studio) in one tap, and download in the background so you can close the tab. On a roomy GPU, enable "keep multiple models loaded" for instant switching; on a modest machine it stays safely one-at-a-time so two models never OOM.

Key Features

• Models, your way: local (Ollama/LM Studio/llama.cpp, GPU or CPU) and cloud (OpenAI, Anthropic, Google, OpenRouter), switchable per message.
• Knowledge + web: built-in web search (SearXNG → Brave → DuckDuckGo fallback), document chat (PDF/text/markdown), and a cited research mode.
• More than a chat box: blind A/B Compare with a leaderboard, cross-conversation Memory, a Keep-style Notes panel, folders/tags/archive, vision input, and shareable links.
• Private + yours: no telemetry, local SQLite storage, multi-user with an admin panel, a live theme editor, and full rebrand from one config file. Installable as a PWA on phone and desktop.

Testing & Validation

After startup, open http://localhost:3001 and register the first (admin) account, then confirm a model responds:

You should see 200, the model picker should list your Ollama/LM Studio models or cloud providers, and a test prompt should stream a reply. If all three hold, your private AI workspace is live.

Key Results

• Delivered a self-hosted AI workspace with local conversation storage and no telemetry. Note: enabling cloud providers or web search sends message content and derived queries outside your machine.
• Unified 3 local engines plus 4+ cloud providers behind one UI, switchable per message.
• Added hardware-aware model fit tagging that prevents out-of-memory crashes on load.
• Shipped a hands-off installer that provisions every dependency in one command.

How I built it

Chakor started as my answer to a privacy problem: I wanted a modern AI workspace, but I did not want my prompts, documents, or notes leaving my own hardware. The design keeps every byte local by default while still supporting cloud models for the moments a local GPU is not enough.

1. Phase 1, application skeleton: Built the Next.js and TypeScript frontend with server-side API routes, backed by SQLite so the whole app runs from a single file database with no external services.
2. Phase 2, model backends: Integrated local runtimes (Ollama, llama.cpp, LM Studio) alongside optional cloud providers, with a unified interface so switching models never changes the workflow.
3. Phase 3, knowledge features: Added document chat with retrieval, live web search, and a model comparison view so answers can be checked side by side.
4. Phase 4, personal workspace: Added notes and long-term memory so the assistant builds context across sessions instead of starting cold every time.
5. Phase 5, packaging and release: Containerized the stack with Docker and published it as open source under the MIT license so anyone can self-host it.

What you need

Challenges and lessons learned

• Model switching state: each backend has its own quirks for streaming and context limits, so a clean abstraction layer was needed. Lesson: hide provider differences behind one interface early, before the UI depends on any of them.
• Streaming reliability: server-sent event streams can drop on flaky networks, leaving half-rendered answers. Lesson: add client-side reconnection and treat every stream as resumable.
• Memory without bloat: storing everything forever makes retrieval noisy. Lesson: keep memory summaries compact and let the user inspect and delete what the assistant remembers.

What is next

• Deeper document intelligence: multi-document comparison and cited answers with source highlighting.
• Voice input and output for hands-free sessions.
• A plugin system so community integrations do not require forking the codebase.
• Mobile-friendly UI refinements for the workspace on phones and tablets.