**Your workspace is understood where it lives.**

Pathrule Intelligence runs a model on your own machine. That model is what reads your memories, rules, corrections and decisions and works out what they mean, which is the step that would otherwise require sending your team's internal reasoning to someone else's inference service.

## What gets installed

Two pieces, provisioned in that order on purpose.

1. **The inference runtime.** A dedicated Python environment under your Pathrule home, with `mlx-lm` installed at a pinned version. It is provisioned first because it is cheap to retry, and failing here before a large download avoids wasting one.
2. **The model bundle.** Weights and config, resolved through a signed manifest, downloaded into a staging directory, verified, extracted, and only then activated.

Both live under `PATHRULE_HOME`, which defaults to `~/.pathrule`. The model sits in `intelligence/versions/<version>`, with a `current` pointer naming the active one.

**Studio and Pathrule CLI share one install.** They read the same directory and drive the same resident server, so "install the model" means the same thing on both surfaces and you never end up with two copies.

## Size and platform

| | |
| --- | --- |
| Model | A quantized 4B model, purpose-built for understanding knowledge rather than writing code |
| Download | Roughly 2.5 GB |
| Inference runtime | `mlx`, at a pinned version matching the measured production stack |
| Platform | Apple Silicon |

The runtime requirement is real and it is checked up front: on a platform mlx does not support, provisioning refuses immediately with that reason rather than downloading gigabytes and failing at the end.

## Lifecycle and updates

The install goes through an explicit state machine that Studio and the CLI both render: not installed, downloading, verifying, ready, loading, loaded, update available, error.

Three safety properties hold throughout:

- **A bundle is activated only after its bytes match the manifest checksum.** Verification is fail-closed.
- **A failed or corrupt download never touches the active version.** Download, verification and extraction all happen in a staging path, and activation is the last, atomic step.
- **Nothing hardcodes a version-specific URL.** Everything resolves through the manifest, so an update is a manifest change rather than a client release.

## Load and unload

The model is not resident all the time. It is spawned on demand as a local server bound to loopback, proven to be genuinely answering before anything is handed a URL, and unloaded again after an idle window. A cold load of a 4B model takes tens of seconds; after that it answers immediately until it goes idle.

Readiness is a real completion, not a metadata route. A server that is up but broken answers a status endpoint perfectly well, so that check would pass while nothing worked.

## Offline

Once the runtime and the model are installed, understanding your knowledge does not need a network. Downloading or updating the model does, and so do Pathrule's cloud services, which are a separate thing (see below).

## When the model is not there

It fails **closed and visibly**, which is the whole point of the design.

- **Model absent**: nothing is spawned, and delivery falls back to source knowledge.
- **Runtime absent**: the same, with a distinct reason so the interface can tell you Python could not be set up rather than that a download failed.
- **Server up but not ready**: killed, and treated as absent.

Pathrule never silently delivers something degraded and calls it compiled knowledge. See [safety and fallback](/docs/intelligence/safety).

## What "local" does and does not mean

This is the sentence that has to stay precise.

**True:** Pathrule Intelligence inference runs on your device. Your repository is not indexed, scanned or uploaded, and understanding your knowledge does not require Pathrule-hosted AI inference.

**Also true, and separate:** Pathrule has cloud services for accounts, teams, billing, workspace sync of the knowledge you choose to share, and distribution of the model bundle itself. And when you run Claude, Codex or any other coding agent, that agent's own provider boundaries apply to whatever you send it.

Three boundaries, not one. [Security and privacy](/security) describes each.

## How this was built

The inference was the straightforward half. What decided the architecture was everything around it: a frozen evaluation with veto power over a release, an 8B diagnostic control that showed the hard failures were not a capacity problem, a training round that shipped nothing, and a deterministic compiler that has the final say over what the model produces. That work is written up in [Running the model locally was the easy part](/writing/local-llm-for-coding-agents).