One static binary. Twenty commands, --json on every one, errors that come
back as JSON too — it is built to be driven by a script or an agent as readily as by a
person. It is a separate download from the app and is not inside the
installer.
Five builds on the v1.0.10 release, each with its own Sigstore bundle alongside it:
| Asset | Platform | Size |
|---|---|---|
| armore-darwin-arm64 | macOS · Apple silicon | 21,851,504 B |
| armore-darwin-x86_64 | macOS · Intel | 24,235,104 B |
| armore-linux-arm64 | Linux · arm64 | 20,154,384 B |
| armore-linux-x86_64 | Linux · x86_64 | 27,797,880 B |
| armore.exe | Windows | 26,466,816 B |
.dmg,
.exe installer, .deb and AppImage do not contain the
armore binary — it is a separate asset you fetch yourself. If you are
looking for it inside the application bundle, you will not find it there.
This is a binary you are about to execute, so check it. The verification runs against a public transparency log rather than anything we control, which is what makes it worth doing:
# fetch the binary and its bundle from the release, then: cosign verify-blob \ --bundle armore-darwin-arm64.sigstore.json \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ --certificate-identity-regexp '^https://github.com/uniQ-Ventures/' \ armore-darwin-arm64 Verified OK
That output is from running the command as an ordinary downloader, against the same
binary that produced every other output on this page —
sha256 1d14d00d74648c6e95f4e14c30c0ced163f3cf99dc2023e7144023a2003bff4a.
gh attestation verify returns 404 on these files. Use the cosign
form above. Full detail is on verify what you downloaded.
There is no installer and no install step. The asset arrives
non-executable — mode 0644 — so one chmod
stands between you and a working tool:
$ ./armore-darwin-arm64 --version zsh: permission denied: ./armore-darwin-arm64 # exit 126 $ chmod +x armore-darwin-arm64 && ./armore-darwin-arm64 --version armore 1.0.10
Put it on your PATH as armore if you want the examples below
to work as written. Fetched with curl on macOS it carried no
com.apple.quarantine attribute and needed no Gatekeeper dance; a browser
download may differ.
This table is armore --help, lightly trimmed. Every one of them takes
--help itself, and you should use it — several require flags the command
name does not hint at.
| Command | What it does |
|---|---|
| ask | One on-device LLM chat completion |
| extract | On-device structured extraction, with an optional signed receipt |
| files | Content-addressed, BLAKE3-verified file store (hash/put/get/ls/share) |
| audit | Offline verification of evidence bundles and receipts |
| mesh | Device mesh: pairing halves and local status |
| msg | Encrypted messaging: seal + record, and decrypt the thread |
| call | Sovereign P2P calls — the live session runs in the app |
| fleet | Validate an org fleet-policy TOML and evaluate decisions |
| auth | Local identity: the NodeId this CLI acts as; enrol and accept |
| backup | Portable identity backup: seal/verify workspace keys under your phrase |
| recovery | BIP39 recovery-phrase encode/decode |
| serve | Host a service to granted peers, dial one, manage the registry |
| site | Mint a signed published-site record for the HTTP gateway |
| rag | On-device retrieval over your docs: embed + cosine-rank |
| models | This binary's backends, models, and inference capability |
| memory | On-device semantic memory: add/search/list/forget |
| mcp | MCP client — external tools, ACT-gated and receipted |
| privacy | See, export, or erase everything this CLI stores here |
| completion | Print a shell-completion script |
| help | Print help for a command |
memory add and
memory search need the embedding backend and exit non-zero with install
instructions without it, while memory list and forget run on
any build. The help calls this “the build contract, not a broken store.” Check what
yours has with armore models capabilities.
Shell completion is one command and a redirect — it prints a real script, the
#compdef armore kind, for bash, zsh, fish, elvish or powershell:
$ armore completion zsh | head -3
#compdef armore
autoload -U is-at-least
--json is documented on all twenty commands — you can check that claim in
one loop over armore <cmd> --help rather than taking it from this
page. Successes come back as one object:
$ armore files put notes.txt --json
{
"chunks": 1,
"command": "files.put",
"file_id": "notes.txt",
"name": "notes.txt",
"ok": true,
"plaintext_blake3": "69879e7f90b4913dbccabbc84495ca835494b02798e36c05bac386e8801f58b9",
"store": "/Users/you/.config/armore/file-store",
"total_size": 45
}
So do failures. There is no mode where you have to scrape prose to find out what went wrong:
$ armore files get nope --json {"error":"no stored file with id \"nope\": … No such file or directory (os error 2)","ok":false} # exit 1
$ armore ask "hello" --json {"error":"error: the following required arguments were not provided:\n --model <MODEL>\n\nUsage: armore ask --model <MODEL> --json <PROMPT>\n…","ok":false} # exit 2 — distinct from the exit 1 above
--json is also treated as a declaration that you are not a human,
and a few paths get stricter because of it. armore mcp call --json
additionally demands --allow-unpinned-cmd, on the grounds that a
non-human caller launching a caller-chosen server deserves an explicit flag. See
install a connector.
ask runs one completion. It needs --model pointed at a GGUF
file on your disk — there is no default, and no model is bundled with the binary:
$ armore ask "In one sentence: what is a content-addressed file store?" \
--model ~/models/llama-3.1-8b-q8.gguf --json
{
"command": "ask",
"model": "/Users/you/models/llama-3.1-8b-q8.gguf",
"ok": true,
"reply": "A content-addressed file store is a data storage system where files are
identified and retrieved by their hash values, which serve as unique
identifiers based on the contents of each file."
}
“No network egress” is in the help text, but you do not have to believe help text. Deny the process network access at the kernel and run it again:
$ cat nonet.sb (version 1) (allow default) (deny network*) $ sandbox-exec -f nonet.sb armore ask "Reply with exactly: offline" \ --model ~/models/llama-3.1-8b-q8.gguf --json {"command":"ask","ok":true,"reply":"…"} # exit 0 — completed with every socket denied
For reference, on the machine these were run on — an Apple-silicon laptop, 8.5 GB q8
Llama 3.1 8B — /usr/bin/time -p reported 22.07 s for the
first run and 12.45 s once the model file was in the page cache. Those
are two data points from one machine, not a specification; yours will differ with your
hardware and model size.
1 sentence(s) replaced — the model stated a false claim about
which model it is. The weights are third-party open weights Armore packages, not
something Armore trained, and the model does not reliably know which file it was loaded
from. armore models list --dir <dir> answers that properly, with a
BLAKE3 hash per file.
Related commands worth knowing: armore models capabilities reports which
backends are compiled in and whether ask/extract/rag
will run at all; ask --rag <dir> --embed-model <gguf> grounds
an answer on local files; and ask --receipt-key-file <path> signs a
provenance receipt over the run, hashing the prompt and answer into it rather than
storing either. Receipts are verified offline with armore audit receipt.
--receipt-key-file does not mean the same thing on every command, so
read the help rather than pattern-matching. On ask and
mcp call it is where the signing key is read from. On
extract it is where the extraction output gets sealed, and it is
required whenever you pass --receipt-key — deliberately, so that
extract can never quietly mint an encryption key and leave ciphertext in
your config directory as a side effect.
By default under ~/.config/armore (%APPDATA%\armore on
Windows), never in your working directory — the file store's key is one of the things
kept there, and the help notes that staying out of cwd is deliberate.
Point any command at a different home with --config-dir, or set
$ARMORE_CONFIG_DIR.