Skip to main content

Installation

clockwright is distributed as a compiled artifact — a native binary you run from the command line. There is no public package registry yet and no source checkout to build from: the engine's source stays private while the project is in its pre-1.0 phase.

⚠️ A JVM/Kotlin library surface is planned, not available today. If you consume clockwright from a host application rather than the command line, that integration does not exist yet — ask about its status when you request access rather than assuming it is ready.

Getting an artifact​

  1. Request access at https://clockwright.dev. Access is granted per individual or organisation; there is no self-service download.
  2. You will receive a build identified by three things together: an engine version, the rustc version it was compiled with, and a target triple (its platform and architecture). All three travel with every result clockwright produces — see Determinism for why that matters.
  3. Place the binary (conventionally named cwright) on your PATH.

There is no installer, no daemon to start, and no service to keep running. clockwright is an embedded engine: a run is a process invocation, and its output is a directory of files.

Verifying what you received​

Before trusting a build, check that it identifies itself:

cwright validate --help

A working binary prints its usage text and exits 0. More usefully, every result clockwright writes carries the toolchain that produced it — after running any model, look at the manifest.engine_version, manifest.rustc_version and manifest.build_target fields in the result document (see The results document) and confirm they match what your access confirmation described. A result whose manifest you cannot account for is a result you should not compare against anything else.

Platform support​

clockwright's engine core is written in Rust and its reference development and validation toolchain targets four systems: x86_64-linux, aarch64-linux, x86_64-darwin, and aarch64-darwin. If you need a platform outside that set, ask when you request access — whether it is supported depends on details (available rustc targets, AVX-512 or other platform-specific code paths) that are worth confirming case by case rather than assuming.

⚠️ This describes the platforms the engine is developed and gated against, not a published, versioned release matrix — clockwright does not yet ship one. Treat "is this exact platform supported" as a question to ask at the access-request step, not one this page can answer with certainty for every combination.

⚠️ Determinism is promised on a stated toolchain — nowhere else​

This is the single most important thing to understand before you start comparing results.

clockwright's determinism guarantee — that the same model, seed and replication count always produce the same answer — is proved on one fixed toolchain and instruction set at a time. It is not a claim about the engine in the abstract; it is a claim about one specific compiled artifact. Two builds of the same engine version, produced by different rustc versions or for different target architectures, are two different programs as far as bit-for-bit reproducibility is concerned. Floating-point arithmetic, code generation, and vectorised instruction selection (AVX-512 or its absence, for example) can all legitimately differ between them.

What this means in practice:

  • Never compare results produced on different platforms or different builds and treat a difference between them as a finding about your model. It may only be a finding about the two compilers.
  • Every result you keep should record which build made it. The manifest block in every result document exists for exactly this reason — check it before you set two results side by side.
  • A performance number is only meaningful next to the machine it was measured on. If you are timing runs yourself (wall-clock seconds, events per second), always report which CPU and which build ran them. A number without its machine named next to it is not a number you can act on later.
  • If you need to compare a baseline against a candidate model, run both on the same build, on the same machine, in the same invocation of the tool — which is exactly what cwright compare and cwright propose do for you.

None of this is a limitation you work around; it is the shape of the guarantee. See Determinism for the full contract.

Next​

Continue to Your first model to validate and run a small model.