Locara

Jan.ai

What it is: Open-source desktop AI assistant — “a ChatGPT alternative that runs on your computer.” Apache 2.0, built by janhq (Vietnam-based team). Status: Active. ~42k GitHub stars, 5.5M+ downloads. Backed by community + the team’s commercial work (Cortex.cpp). Most relevant to Locara: A successful OSS desktop runtime + assistant, with a clear plugin/extension model that’s the closest approach to “apps on top of a local runtime” today.

Background

Jan started as an open alternative to ChatGPT/LM Studio with a strong “your AI, your hardware” stance. It packages a desktop chat UI, an embedded model server (Cortex.cpp, Jan’s own llama.cpp wrapper), and an extensions API for adding capabilities. The team is small but ships quickly and prioritizes OSS hygiene (transparent roadmap, governance).

Cortex.cpp is the team’s separate inference engine — a competitor to Ollama written in C++ with a similar daemon model.

Key design decisions

  • Apache 2.0 OSS through and through.
  • Tauri-based desktop app (Mac/Windows/Linux). Rust backend, web frontend.
  • Cortex.cpp as inference layer — their own daemon, not Ollama. Gives them control over the server side.
  • Extensions/plugins API. Apps can add models, providers, UI tabs, tools. Closest analog to Locara’s “apps” concept.
  • Multi-provider support — local models AND BYO-key cloud providers (OpenAI, Anthropic, etc.). They embraced the hybrid reality.
  • Assistants concept — pre-configured personas/agents users can spawn. Closer to ChatGPT GPTs than to standalone apps.
  • Small team, high transparency. Public roadmap, public design discussions on GitHub.

What worked

  • Tauri choice validates Locara’s stack pick. Real-world proof Tauri works for this kind of app.
  • OSS positioning resonates. Real download numbers, real community.
  • Decoupled inference engine — Cortex.cpp can be used independently, which gives them optionality.
  • Pragmatic hybrid stance — supporting cloud providers alongside local lowered adoption friction without betraying the local-first pitch.
  • Extensions API exists — proves the abstraction is feasible.

What failed / criticisms

  • Quality lags polish leaders (LM Studio). UI feels OSS-rough at the edges; reflects small-team reality.
  • Two products in one (Jan + Cortex) dilutes focus. Cortex.cpp competes head-on with Ollama and is losing on mindshare.
  • Extensions/plugins are immature. No real third-party ecosystem; almost all extensions are first-party. Suggests the API isn’t yet ergonomic enough for outside builders.
  • Assistants ≠ apps. The “assistant” frame is a system-prompt + tool config, not a real software primitive. Doesn’t unlock new app shapes the way Locara’s manifest/runtime aims to.
  • Memory features promised but slow to ship.
  • Discoverability of extensions is poor — no real registry/directory.

Specific learnings for Locara

  1. Tauri + Rust + TS is a proven stack for this category. Validates Locara’s stack choice with real evidence.
  2. An “assistant” abstraction is too thin to drive an ecosystem. Locara apps need to be real software with their own UI, storage, and capabilities — not glorified system prompts. Don’t model your supply side on Jan’s assistants.
  3. Decoupling inference engine from app is good. Locara’s locara-core should be usable independently — others should be able to embed it without buying into the rest of the stack.
  4. Hybrid (local + BYO-key cloud) is pragmatic — apps should be able to declare a local-first capability with optional cloud fallback. But the “fully local” badge requires net: false. Both can coexist.
  5. OSS stewardship is achievable as a small team. Jan’s transparency model (public roadmap, public ADRs, GitHub-first) is a template Locara can copy.
  6. Don’t try to compete with Ollama. Cortex.cpp’s struggles show this. Build a layer above Ollama-class runtimes instead of replacing them.
  7. Extensions need a discovery surface or they don’t get adopted. Jan’s lack of a registry/directory is part of why their plugin ecosystem is anemic. Locara’s app store solves this directly.

References