Tarski/ docsJoin the waitlist

Installation

Install the tarski CLI, pin versions, keep it updated, and understand what runs locally versus in the cloud.

Supported platforms

The CLI ships for:

Platform Asset key
Linux x86_64 linux-x86_64
Linux arm64 linux-arm64
macOS (Apple silicon), signed and notarized macos-arm64
Windows x86_64 windows-x86_64

Some preview releases ship under a scoped distribution; when a platform is intentionally omitted, the installer reports an explicit availability diagnostic naming the platform, version, and distribution scope — never a broken download.

Installing and updating

Releases publish signed, checksummed platform bundles plus channel metadata. Installs resolve the latest version through the release channel at https://download.getjacqos.com/channels/<channel>.json, and assets verify against the published checksums.txt. That download origin is an explicitly retained legacy transport hostname while release infrastructure moves; installed commands and emitted artifacts use Tarski identity.

  • Pin a version with the TARSKI_VERSION environment variable.
  • Update in place with tarski self-update, which reads the channel’s asset table before constructing a download URL.

Releases are artifact-pinned and immutable: a tag’s assets never change. Defects get a new correction release rather than a mutated old one.

Corporate networks

The CLI uses your host platform’s certificate store plus built-in web roots. For private CAs, add roots additively with the TARSKI_CA_BUNDLE environment variable or the --ca-bundle flag. Standard HTTPS_PROXY, ALL_PROXY, and NO_PROXY variables are honored, with an unconditional loopback bypass. There is no insecure-verification escape hatch.

What runs where

Tarski’s public development path is cloud-first. Your files, editor, and terminal loop stay local — source discovery, manifest parsing, syntax and schema preflight, diff rendering, and evidence inspection all run on your machine. Protected semantic work — package admission, fixed-point evaluation, provenance construction, deterministic provider execution, and signed evidence — runs in Tarski Cloud or another accepted semantic authority (enterprise runtime, BYOC cell, or an entitled full local runtime).

Practically: tarski dev syncs your source bundle to a cloud dev environment by content digest, while tarski test and tarski verify keep local ergonomics and return authority-backed evidence. Output not backed by an authority receipt is labeled non-semantic preflight or cached evidence — it never silently impersonates a current pass.