Local chat and cloud chat share one desktop, with different privacy
Jan downloads models such as Llama, Gemma, and Qwen for local inference, then wraps them in a desktop chat interface with custom assistants. It can also connect to OpenAI, Anthropic, Mistral, Groq, MiniMax, and OpenAI-compatible endpoints. Local use can keep prompts and model execution on the computer. Selecting a cloud provider changes that boundary because requests leave the machine under that provider's terms and credential controls.
The second useful surface is a local OpenAI-compatible server at localhost:1337. Other programs can call Jan without learning its desktop internals. MCP support adds tools to chat, while built-in web search and retrieval extend what a model can reach. Those pieces make Jan more than a model downloader. They also mean a successful plain chat does not prove that function calling, retrieval, streaming, or a custom endpoint will behave correctly with the same model.
A 2,201 MB source install did not produce a build
Our Yarn install succeeded in 169 seconds, adding 4,020 packages and consuming 2,201 MB. The repository checkout was already 273.8 MB, with 2,300 files and about 191,466 source lines. This is a large monorepo with workspaces and 35 CI workflow files. Our scan found a tests directory and no Dockerfile. A contributor should budget disk, package resolution time, and native tooling before reaching the desktop code.
The build exited with code 2 after 35 seconds. Its final lines showed TypeScript unable to find @janhq/core or its type declarations in provider, retrieval, thread, upload, and utility modules. Other lines flagged callback parameters with implicit any types. The log does not show whether workspace ordering, generated types, or the checked-out commit caused those failures. We can only say the supplied build command did not compile in our clean Node 22 container.
What happened when we ran it
Our test command exited with code 1 after 120 seconds. One Vitest sub-summary captured by the harness reported 171 passed and 0 failed. The final log covered a wider result: 50 test files failed, 205 passed, and the test totals were 18 failed and 2,285 passed out of 2,303. The tail also showed 3 failures in @janhq/web-app's main.test.tsx, alongside repeated intentional Test error messages.
Those results describe commit 95e96d0 on 3 CPUs and 8 GB of RAM. We did not launch the graphical application, download a model, test tokens per second, or connect a cloud account. The failed source checks matter to contributors and anyone producing an internal build. They do not establish that the signed v0.8.4 desktop package fails to open, because that published artifact followed a different release process that our run did not reproduce.
Model memory rises from 3B to 13B choices
The README recommends 8 GB of RAM for 3B models on macOS, 16 GB for 7B models, and 32 GB for 13B models. Windows 10 or newer can use NVIDIA, AMD, or Intel Arc GPU support, while Linux compatibility varies by distribution and acceleration path. These are starting points from the project, not performance measurements from our sandbox. Model quantization, context size, and concurrent work can change the memory requirement.
Jan offers Windows, macOS, Debian, AppImage, and Flathub installation routes. Building from source asks for Node.js 20 or newer, Yarn 4.5.3 or newer, Make, Rust for Tauri, and a Metal toolchain step on Apple Silicon. The packaged route is clearly easier for end users. Teams distributing their own build need a reproducible monorepo build first, which commit 95e96d0 did not give us.
Custom providers can lose tools or fail CORS checks
Issue 8743 reports that Jan v0.8.4 omitted the tools array when sending chat requests to a self-added OpenAI-compatible provider, even though an MCP server was connected and the model's tool capability was enabled. The reporter's manual request worked when the array was present. Issue 8777 describes a separate name collision in which an MCP web_search tool was processed as Jan's built-in web search. Both reports concern agent behavior, where a silent routing error is worse than an ordinary chat failure.
Issue 8792 documents a v0.8.4 custom Ollama setup behind Nginx returning 403 because requests carried Origin: http://tauri.localhost. The same endpoint worked in the report without that header. These are specific configurations, and maintainers may fix them quickly. They justify an acceptance test for every provider: verify streaming, tool schema transmission, one real tool result, cancellation, and error display before giving an assistant access to files or external services.
Release 0.8.4 improved credential storage without deleting the old copy
Jan v0.8.4 moved provider settings into a backend-managed store and secrets into the operating system keyring. During migration, it copies existing settings and keys from webview localStorage. The release notes say the old localStorage data remains as a downgrade snapshot. That eases rollback, but security-conscious users should know a previous credential copy is intentionally retained and decide when it is safe to remove after confirming the new release.
GitHub showed 44,189 stars, 486 combined open issues and pull requests, and a last push on August 26, 2026. Release v0.8.4 arrived on July 23. That is a large, active project rather than an abandoned desktop wrapper. Our failed build and 18 failed tests still make the current source experience the deciding caution. Try the packaged app for personal local chat; require a green build, provider tests, and controlled MCP permissions before standardizing it for a team.