# Jan's Windows build fails on MAX_PATH, and Linux Arm64 has no binary

> A local-first ChatGPT alternative whose build-from-source path is four prerequisites and a Make target, wrapped around a bundled llama.cpp engine you select with a make variable. The documentation is unusually honest about failure modes, including an nvcc error that is really a path length limit, while one download row points at an issue comment instead of a file.

**janhq/jan** — GitHub describes it as Jan is an open source alternative to ChatGPT that runs 100% offline on your computer.. The repository metadata lists TypeScript as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/janhq/jan
- Website: https://jan.ai/
- Stars: 44,719 · Forks: 3,062
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/janhq-jan

## The Linux Arm64 row links to an issue comment, not to a file

The download table has five rows and four files. Windows gets jan.exe, macOS gets a universal jan.dmg, and Linux gets a deb package and an AppImage, each from a versioned path under app.jan.ai/download/latest. The fifth row is Linux Arm64, and its link is not a download at all. It points at a comment on a GitHub issue. So on an ARM Linux machine the documented install route is a forum post, pinned to one comment rather than to a release, and the Microsoft Store and Flathub badges at the top of the section cover the desktop platforms only. Two consequences follow. An Arm64 user is reading instructions that can be edited by anyone with a GitHub account, and the file that describes the install is not versioned with the release. If you are on ARM Linux, read the issue comment first, then verify the checksum of whatever it tells you to fetch against the releases page.

## JAN_ENGINE_VARIANT is joined by a hyphen, so cpu-cuda13 is a legal value

The engine is not a single binary. The bundled llama.cpp build is selected at make time with JAN_ENGINE_VARIANT, whose tokens are cpu, vulkan, metal, cuda12, cuda13 and hip/rocm, and the documentation states they are joined by a hyphen, so more than one can be combined. The example given is:

```bash
make dev JAN_ENGINE_VARIANT=cuda13
```

Most contributors never touch it and get a default build, which is why the CUDA line in the Windows prerequisites is qualified: the CUDA Toolkit is only needed for JAN_ENGINE_VARIANT=cuda12 or cuda13 builds. The consequence is that two checkouts of the same commit can produce different binaries, and a bug that reproduces on a CUDA build may not reproduce on a CPU build. If you file an engine bug, the variant is the first thing worth stating, and if you pin a build in CI, record the variable alongside the commit, because the commit alone does not identify the artifact.

## The nvcc error is a path length limit, and the fix is a short directory

One failure mode is documented in detail because it is confusing. If the build reports nvcc fatal : Could not open output file with a name ending in cu.obj.d, the explanation is not a missing compiler: the build path crossed the Windows 260-character MAX_PATH limit, and nvcc does not honour the long-path opt-in. The build script now detects the condition and relocates the llama.cpp build tree to a short directory under the LOCALAPPDATA folder in a jan-engine subdirectory. If path-length errors still appear, the documented escapes are to set JAN_ENGINE_BUILD_DIR to a short path such as C:\jb, or to move the checkout closer to the drive root. The practical lesson for a contributor is that the error names a CUDA tool and a temporary object file, neither of which points at the real cause, and the first thing to check is how deep your clone path is.

## The Makefile header still says Electron while the build runs through Tauri

The first line of the Makefile reads Makefile for Jan Electron App, and the file is not current on that point. The actual build chain is Yarn and Tauri: the install-and-build target runs yarn install, then yarn build:tauri:plugin:api, yarn build:core and yarn build:extensions, and the package scripts route dev through yarn dev:tauri with tauri dev. The JavaScript package is named jan-app, it is marked private, and its workspaces are core, web-app, extensions/* and packages/*. A contributor who searches the repository for electron build instructions finds a stale comment and nothing else, and the Tauri shell lives in src-tauri/ where the recipes chmod it on Linux. The same target skips that step on Windows, where there is nothing to make executable. Trust the package scripts over the Makefile comment when you are working out what a change actually rebuilds.

## make dispatches recipes through sh, so Windows needs Git Bash and the file branches on it

Running make on Windows is the documented special case, and the reason is stated plainly: make dispatches its recipes through sh, so a plain cmd.exe will not work, and you should run make dev from Git Bash. You also do not need a Native Tools Command Prompt for VS 2022, because the bundled llama.cpp engine builds with Ninja and clang-cl, and clang-cl locates the MSVC toolchain and Windows SDK by itself. What must be on PATH is Visual Studio 2022 Build Tools with the MSVC x64 workload and Windows SDK, LLVM for clang-cl, Ninja and CMake. The Makefile encodes the shell problem rather than assuming it: it inspects whether an sh.exe is on PATH, which covers Git Bash, MSYS and CI, and defines MKDIR as if not exist for cmd.exe and as mkdir -p otherwise. The consequence is that the same make invocation is written twice, and a Windows-only recipe bug is a shell-dialect bug.

## yarn lint only reaches the web-app workspace, while make test runs everything

The lint script in package.json is a single line that delegates to one workspace: it runs lint inside @janhq/web-app. Core, the extensions and everything under packages/ are not covered by that command, and the Rust side behind Tauri is not covered by anything in the JavaScript toolchain. Tests are broader. The test script chains three vitest projects, @janhq/core, @janhq/web-app and a glob for @janhq/*-extension, and each invocation is prefixed with cross-env setting NODE_OPTIONS to a 4096 megabyte old space size, which tells you the core suite is memory hungry enough to need a ceiling raised. A green lint run therefore says less than it appears to, and make test, which runs tests and linting together, is the command that exercises more of the tree than yarn lint does. Judge a change by what make test touched, not by the exit code of the lint script alone.

## GitHub reports NOASSERTION for the licence while the README says Apache 2.0

The licence is stated in the README as Apache 2.0, with a LICENSE file at the repository root, and the repository metadata reports the licence field as NOASSERTION rather than recognising the file. That is the same mismatch that automated scanners see, and the practical effect is concrete: a licence allowlist or a compliance scan that reads repository metadata records nothing, and a human has to open the LICENSE file to learn the terms. The README credits the work as built on the shoulders of giants, naming Llama.cpp, Tauri and Scalar, which matters more than the label because a desktop app that bundles a llama.cpp engine ships a large third-party binary inside its own licence boundary. If you redistribute Jan or build on it, read the LICENSE file at the root and check what the bundled engine carries with it.

## The last release is v0.8.4 from 2026-07-23, and the tree has moved since

The repository is not archived and the last push was on 2026-09-29, while the recent releases are v0.8.4 on 2026-07-23, v0.8.3 on 2026-06-24 and v0.8.2 on 2026-06-01. So the source tree is roughly two months ahead of the newest tagged build, and the version line is still pre-1.0 at 0.8.x. Nothing in the repository explains a release policy, and the changelog lives off the repository at jan.ai/changelog, described in the links section as what we broke and fixed. For a user installing a binary, that gap is the cost of a pre-1.0 desktop project shipping from a web app with four language trees. For a contributor, it means the master tree is the interesting branch and the last release tag is a lagging marker. Check the changelog before assuming a bug you hit was fixed.

## Conclusion

Install Jan from the Microsoft Store, Flathub or the download table if you want a working desktop client, and reserve the source build for contributors, since it drags in Node, Yarn, Make, Rust and, on macOS, a Metal toolchain download. Before you start, check whether your platform has a published binary at all, because Linux Arm64 does not, and pick your engine token deliberately: JAN_ENGINE_VARIANT changes which llama.cpp build you get.

## FAQ

### Is Jan AI free to use?

The project is open source, described as an open source alternative to ChatGPT that runs fully offline, with the README stating the licence as Apache 2.0. It offers downloads for Windows, macOS and Linux, Microsoft Store and Flathub listings, and a build from source; connecting to hosted models from OpenAI, Anthropic, Mistral, Groq or MiniMax is a separate optional cost on top of running models locally.

### Is Jan an open-source alternative to ChatGPT?

That is how the repository describes itself: an open source alternative to ChatGPT that runs 100% offline on your computer. The README adds that it runs local models from HuggingFace such as Llama, Gemma, Qwen and GPT-oss, offers custom assistants, exposes an OpenAI-compatible API at localhost:1337, and can also reach cloud models through OpenAI and Anthropic.

### Who created Jan AI?

The README does not name an individual, and the contact section lists roles rather than people: hello@jan.ai for business, hr@jan.ai for jobs, GitHub Issues for bugs and Discord for general discussion. The project is developed under the janhq GitHub organisation, which is where the code, the releases and the issue tracker live.

## Sources

- [Official documentation](https://jan.ai/)
- [Official README](https://github.com/janhq/jan#readme)
- [Project repository](https://github.com/janhq/jan)
- [Release notes](https://github.com/janhq/jan/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/janhq-jan