Klee runs models locally on Apple Silicon, and its web search quietly leaves the device

The tool table contradicts the local-only claim

The opening line is that Klee runs entirely on your Mac, with no cloud, no account and no subscription, and the feature list puts 100% local inference first with the note that your data stays on your Mac. The inference path does match that. Models run through MLX on Apple Silicon, are cached under a hidden models directory in your home folder, and need no API key to chat.

The tool table does not. Seven tools are shipped, and two of them are network calls:

| Tool | Description | |---|---| | `web_search` | Search the web (requires Jina API key) | | `web_fetch` | Fetch and extract webpage content |

Web search is powered by Jina AI with a free key pasted into the sidebar, which means a search sends your query text to a third-party service. The feature list does note the key is free and configurable in the sidebar, but the local-only framing is stated as an absolute and the search tool is listed as a built-in, so the two statements sit in the same document without either qualifying the other.

The same tension applies more quietly to the vision path. Attaching images to a message is described as supported with vision-capable models, and the supported-models table marks a Vision column for only some entries, so a capability that reads as universal is in fact per-model.

Shell and file deletion are in the same table as web search

The tool list is short enough to read in one pass, and it is the place where the security question actually lives. The set is file_write, file_read, file_list, file_delete, web_search, web_fetch and shell_exec.

Two details are worth isolating. file_delete is present, so a model that decides a file is unwanted can remove it, and there is no undo tool in the list to compensate. shell_exec is documented with a 30s timeout, which bounds how long a command can run but says nothing about which commands are permitted or which directories are reachable.

The implementation choice is stated plainly, and it is the reason the list is this short. Tool calling uses the mlx-swift-lm ToolCall API, described as native, with no MCP, no Node.js and no external processes. The application is around 75 MB of SwiftUI, with no Electron runtime, no Docker and no background services, so the tools are in-process calls into the app rather than a bridge to something running elsewhere.

What is not written down anywhere in the file is the permission model. There is no description of a confirmation step before a write, a delete or a shell command, no mention of a sandbox, and no scope restriction for the file tools. Whether the model can act without asking is the first thing worth confirming on your own machine, since the answer determines how much you want to leave within reach of a chat window.

MIT in the readme and no license file in the tree

The license section of the readme is a single word: MIT. The repository root does not contain a license file. The top level holds a claude directory, a gitignore, the Xcode project, the Klee source directory and the readme, and that is the whole list.

So the terms are asserted rather than shipped. Nothing contradicts the word, and the project is not archived, but a reader who needs the actual text, or a scanner that reads the file rather than the prose, has nothing to read.

There is a second licensing question nearby, this one about what the code is derived from. The acknowledgements section credits ShipSwift, stating that Klee was built with components and architecture from it, and the repository's recorded homepage points at that same address rather than at a Klee page. The description also names ShipSwift as the build tooling.

A derived-work notice with no accompanying license text is the awkward combination to watch here. The credit is recorded plainly, which is the right direction, but the project states its own license in one word and credits a source project it does not name a license for, so anyone planning to fork the app has one clear answer and one open question.

One release, and a branch that stopped five months ago

The release record is a single tag. v1.0.0, named Klee v1.0.0, was published on 2026-03-19, and the default branch was last pushed on 2026-03-20, the day after.

That date is the relevant fact for anyone planning to depend on this. The branch tip is the 1.0.0 state, so there is no unreleased work to wait for and no later tag to move to, and there is no scheduled cadence visible in the release history either.

The distribution method is worth understanding before installing. Klee is not on the App Store. It ships as a signed macOS app using a Developer ID signature, distributed as a disk image from the releases page, dragged into the Applications folder. If macOS shows a Gatekeeper warning, the documented path is System Settings, Privacy & Security, then Open Anyway.

That instruction is a real step rather than a formality. A build arriving outside the App Store and requiring an explicit override is exactly the case Gatekeeper exists to make the user decide about, and the readme is direct that this is expected. Whether you are comfortable clicking through it is a reasonable filter before downloading anything.

The model table names DeepSeek R1 but the identifiers are Qwen distills

Every supported model is a 4-bit quantized variant taken from the mlx-community organization on HuggingFace, and the table gives a display name, a download size, a minimum RAM figure, a vision flag and the exact model ID. That is a more useful table than most, because the identifier is copyable.

The details are specific enough to check. The 16 GB row covers Qwen 3.5 9B at about 6 GB, Qwen 3 8B at about 4.3 GB, Gemma 3 12B at about 8 GB and DeepSeek R1 8B at about 4.6 GB. The 32 GB row adds Qwen 3.5 27B at about 16 GB and a mixture-of-experts 35B at about 20 GB. The 64 GB row covers Gemma 3 27B and DeepSeek R1 32B. At 96 GB and above, a 122B mixture-of-experts model at about 70 GB on disk.

The identifiers are where a careful reader will pause. The entry displayed as DeepSeek R1 8B resolves to DeepSeek-R1-0528-Qwen3-8B-4bit, and the 32B entry resolves to DeepSeek-R1-Distill-Qwen-32B-4bit. Both are Qwen-based distills, so what you download is a model named for one family and built on another.

The system floor underneath all of this is macOS 15.0 or later on Apple Silicon from the M1 generation, with 16 GB of RAM as the stated minimum. On first launch the app reads system RAM and shows only the models that fit.

Build from source needs an Xcode project and a resolving package

The source route is three commands, and it goes through Xcode rather than a package manager:

git clone https://github.com/signerlabs/Klee.git
cd Klee
open Klee.xcodeproj

After that you select the Klee scheme and run it, and the SPM dependency on mlx-swift-lm resolves automatically on the first build. The stated prerequisites are Xcode 16 or newer and macOS 15.0 or newer, which matches the runtime floor and means no separate toolchain setup beyond having Xcode installed.

Because the dependency is a Swift package rather than a vendored directory, the first build is also a network operation, and the resolved version is whatever the package manifest points at rather than something pinned in the repository listing. For a project with a single release tag and a branch that has not moved since March, that is the one place where a fresh build can differ from what someone else saw.

The rest of the tree is small in a way that matches the app's scope: the Xcode project, a Klee source directory, a claude directory, and the readme. There is no test target, no continuous integration configuration and no package manifest at the top level, so the quality bar the project sets is the one Xcode enforces when you press Cmd+R.

The feature list includes a module type marked coming soon

One bullet in the feature list is not a feature yet. Platform modules, described as native Swift integrations to extend the AI, are labelled coming soon, while the other nine bullets describe behaviour present in the 1.0.0 build.

It sits in a list where nothing else is time-qualified, which is the only thing that makes it worth pointing out. For a user shopping between local chat apps, the difference between a shipped capability and a planned one matters, and this list does not draw the line for you.

The remaining bullets are concrete and each maps to something specific. One-click model download handles fetching and resumption, with interrupted downloads resuming automatically. Streaming responses show tokens as generated. Inline thinking puts the model's reasoning in a collapsible card, so the reasoning is visible but not cluttering the conversation. Vision support attaches images to messages. Web search goes through Jina with a key from the sidebar.

The usage sequence matches those claims in three steps: open the app so it detects RAM and lists compatible models, download one with the button beside it, then select it and type. Models are cached in a hidden directory in the home folder and persist across restarts, so the download happens once per model rather than once per launch.

Editorial conclusion

Klee suits someone who wants a chat window over a local model, with file tools and shell access, and who is comfortable installing a signed build outside the App Store and telling macOS to open it anyway. The trade you are making is a closed local inference path for a small cloud dependency you can inspect, and the web search tool is where that trade shows: the query text leaves the machine when you paste a Jina key into the sidebar. Two things to check before you rely on it. Confirm the last commit you are building from, since the default branch was last pushed on 2026-03-20 and the only tagged release is v1.0.0 from the day before, so there is no later tag to fall back on. And confirm the license for yourself, because the README says MIT while the repository carries no license file at its root and no license is recorded for the project. Anyone who needs a signed, updateable path from a vendor should use the App Store route instead. Anyone who needs shell and file tools in a model chat should assume the model can act on the machine and read what it is allowed to reach.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. signerlabs/Klee on GitHub