macOS 15.5 and Apple Silicon, and a sandbox that needs macOS 26

Two disk images per release, and updates always take the small one

Installation is one Homebrew cask:

brew install --cask osaurus

or a download of the latest .dmg from Releases. What you download is the decision that matters, because two builds ship per release.

Osaurus-<version>.dmg
Osaurus-<version>-full.dmg

The standard one is around 70 MB and asks you to pick and download a model during onboarding. That is the build Homebrew and in-app updates use. The full one is around 4 GB, is linked from each release's notes, is hosted on Hugging Face rather than on the releases page, and contains the same app with Raptor 0.6 bundled. On first launch that model is installed into ~/MLXModels and onboarding skips the download step, so you can chat offline immediately.

The asymmetry is worth planning around. You may choose the 4 GB build once, and then every subsequent update is the 70 MB build. The convenience is a one-off cost of several gigabytes.

The app needs macOS 15.5, and the Linux agent sandbox needs macOS 26

There are two operating system floors in this project and they are not the same line.

The first is the application. The install section ends with a requirement of macOS 15.5 or later and Apple Silicon. Everything in the README, the app, the CLI and the chat interface, sits above that line. Native Swift on Apple Silicon is stated as the build target, with no Electron and no cross platform story.

The second is the agent sandbox, and it is considerably higher. Agents execute code in an isolated Linux VM powered by Apple's Containerization framework, and that VM requires macOS 26, named Tahoe. The stated consequence for earlier systems is a fallback: a native macOS Seatbelt sandbox where commands run on your Mac under sandbox-exec confinement, with writes limited to the sandbox workspace.

So the headline feature, running real code safely, is the feature that changes shape with your OS version. A machine on macOS 15.5 gets a different execution environment, not a degraded one, and the Sandbox Guide covers configuration, built-in tools and plugin authoring.

The Seatbelt fallback has no apk and no per-domain network rules

The fallback's limits are specific and worth reading before you plan an agent around it.

Three things change. First, package installation is pip and npm only, with no apk, because there is no Linux distribution inside a Seatbelt profile. An agent whose task involves a system package is out of luck on macOS below 26. Second, writes are limited to the sandbox workspace, which is the containment you would expect from confinement but is narrower than a real VM's filesystem. Third, and most restrictively, network access is all or nothing instead of per-domain allowlists. An agent that can reach the network at all can reach everything; an agent that cannot reach it cannot fetch a dependency.

On macOS 26 and later the Linux VM path applies instead, and there each agent gets its own Linux user and its own home directory inside an Alpine image. That VM reaches back to the harness for inference, memory and secrets over a vsock bridge, described as sandboxed but not disconnected, with the workspace mounted through VirtioFS.

Plugins extend the sandbox with JSON recipes, and they need no Xcode or code signing.

Memory injects at most one compact slice per request, and often nothing

The memory design is a budget, not a buffer. There are three layers, identity, pinned facts and per-session episodes, plus a transcript fallback.

The rules that make it fit in a context window are the interesting part. Agents distill conversations once at session end rather than on every turn, so the extraction cost is not paid per message. What matters is scored by salience. At most one compact slice is surfaced per request, chosen by what you are actually asking. And a background consolidator decays, merges and evicts, so memory is meant to stay sharp instead of bloating.

The stated result is that most turns inject about 800 tokens or less, and many inject zero. A memory system that often contributes nothing is the opposite of the usual trade, and it only works because the distillation happens once and the eviction happens in the background rather than on the critical path.

Agents can also opt into a private local database and a single self scheduled next run, which is the mechanism behind the self scheduling half of the agent design.

A 2.8 GB local classifier stands between you and a cloud model

The privacy filter only does anything when you send to a cloud model, and when it does, it is not a regex list.

An on device classifier runs first. It is OpenAI's privacy filter, Apache 2.0 licensed, with 1.5B parameters and 50M active in a sparse mixture of experts, served through the MLX conversion mlx-community/openai-privacy-filter-bf16 at about 2.8 GB. That model detects names, emails, phone numbers, URLs, addresses, dates, account numbers and free form secrets.

Alongside it sit deterministic rules for SSN, credit cards, IBAN, AWS keys and GitHub tokens, plus your own custom patterns. So the filter is two systems: a learned one for the things a regex cannot enumerate, and a literal one for the things that have a fixed shape.

Every detection is shown in a review sheet with a scrubbed preview before anything is sent, and approved entities are swapped for stable placeholder tokens. The cost is a 2.8 GB model download and the review step itself, which means the filter is a decision the user makes each time rather than a setting they make once.

Local storage is plaintext, and FileVault is the protection

This is the one sentence in the README worth reading twice. Agents can opt into a private local database, and local storage is plaintext by default, protected by FileVault, with opt in SQLCipher encryption available. The detail sits in a separate storage document.

What that means in practice is that local storage is readable by anything running as your user, and the only default protection is the full disk encryption macOS ships with. SQLCipher is there and is opt in, so a machine without FileVault enabled, or a team that needs the database itself encrypted, has a setting to flip.

That matters more here than in most applications, because the memory layer is the asset. The project's own argument is that the layer around the model is the irreplaceable part, since models are getting cheaper and more interchangeable, and that layer is stored in plaintext unless you turn on SQLCipher.

If your agents read files you care about, read docs/STORAGE.md before the first run rather than after.

An Xcode workspace with a benchmark and an eval suite bolted onto it

The top level of the repository is a Swift application rather than a package, and the Makefile is an xcodebuild wrapper around it:

SCHEME_CLI := osaurus-cli
SCHEME_APP := osaurus
CONFIG := Release

Two schemes, and the app target embeds the CLI, which explains why there is an osaurus command alongside the chat window. The targets follow in the help output:

  cli            Build CLI ($(SCHEME_CLI)) into $(DERIVED)
  app            Build app ($(SCHEME_APP)) and embed CLI

There is an install-cli target that installs or updates a /usr/local/bin/osaurus symlink, and a serve target that builds the CLI and starts the server with PORT and EXPOSE variables.

The rest is measurement rather than packaging. A bench group targets the EasyLocomo benchmark: bench-setup clones it and applies patches and installs dependencies, bench-ingest runs full LOCOMO ingestion with LLM extraction and chunks, bench-ingest-chunks is a chunk only backfill with no LLM, and bench-run executes the benchmark while skipping ingestion. Then there are eighteen evals targets, from a single OsaurusEvals suite driven by MODEL, FILTER and EVALS_SUITE through matrix, diff, capture-screen and scoreboard variants. The .swift-format and .swiftlint.yml are the style configs, and lefthook.yml runs the git hooks.

Editorial conclusion

Take Osaurus if you are on Apple Silicon, you want a harness that keeps agents, memory, tools and identity on your own machine, and you are willing to accept a macOS-only, Swift-only surface with no cross platform path. Leave it if your agents need to install Linux packages, because below macOS 26 the fallback is a Seatbelt sandbox with no apk and all or nothing network rather than per-domain allowlists. Verify three things. Run osaurus status after installing so you know whether the server actually came up, since this ships a CLI and not only a window. Decide which disk image you want, because the 4 GB build bundles Raptor 0.6 and installs it into ~/MLXModels on first launch while every later update is the 70 MB build. And read docs/STORAGE.md before you point an agent at anything sensitive, because local storage is plaintext by default with FileVault as the only thing between it and the disk.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes