Get ClikaRT

ClikaRT is a set of downloads on the CLIKA platform: one release archive per platform, the Python wheels, the Kotlin artifact and the examples archive, every file with its SHA-256 shown beside it. Take every one you use from the same release. The release the dialog offers is the deployment's own pin, which may differ from the release these pages are written for (0.6.4); a download's own README.md is the authority for the release it came from, its commands and file names included. Your platform deployment's Download ClikaRT dialog (your name in the top bar, or a project's Overview), the platform CLI (clika-cli runtime-sdk download) and the MCP tools all hand out the same files; Download the ClikaRT SDK is the walk through each surface.

Pick the platform you are deploying to and copy the commands. Each platform has its own archive, named ClikaRT_<os>_<arch>-<version>.tar.xz (.zip on Windows); the tree inside is that platform's complete bundle, the runtime and the Modelverse model library together. The dialog shows the archive's SHA-256 as text with a Copy control; paste it in place of <sha256> below.

OS

Architecture

Accelerator

# ClikaRT_linux_x86_64-0.6.4.tar.xz: from the platform's Download ClikaRT dialog, with the SHA-256 it shows.
echo "<sha256>  ClikaRT_linux_x86_64-0.6.4.tar.xz" | sha256sum -c
tar -xf ClikaRT_linux_x86_64-0.6.4.tar.xz
export CLIKART_BUNDLE_DIR="$PWD/ClikaRT_linux_x86_64-0.6.4"
# Verify:
"$CLIKART_BUNDLE_DIR"/examples/bin/version_00_hello_world

No driver needed.

Then continue with Quick install, which picks up at the extracted bundle. Complete installation has per-platform depth.

License credential

ClikaRT runs compute under a license, so every process that runs an operator or a model needs the credential CLIKA issued for your deployment. The credential is the CLIKA1-... text your project's license shows as its license key, the same text for an online license key and an offline license bundle; an API key (clika_rk_...) is not a credential. Runtime licenses is where a credential comes from, and the download dialog shows your project's key beside the archives.

Put it in the environment variable CLIKA_RT_LICENSE, as the credential text or as the path of a file holding it, before the program starts:

export CLIKA_RT_LICENSE=CLIKA1-...                  # the credential text
export CLIKA_RT_LICENSE=/etc/clika/clikart.license  # or the path of a file holding it

Or store it once per user account with clikart-license-init, which ships in every archive's bin/ (clikart-license-init.exe on Windows) and as a console script of the clika-runtime wheel; every later process under that account reads the file when the variable is not set, and the variable wins when both are present:

"$CLIKART_BUNDLE_DIR"/bin/clikart-license-init CLIKA1-...

Without a valid credential a call is refused with the code name LICENSE_FAILED, or LICENSE_EXPIRED for a license past its end date. License the runtime is the whole contract: where each language and packaging puts the credential, and how a program reads a refusal's code name.

All combinations

The pattern is the same for every platform; only the archive name and the checksum command change. The dialog shows the SHA-256 beside the download button, with the one line that checks the file on your platform:

echo "<sha256>  ClikaRT_linux_x86_64-0.6.4.tar.xz" | sha256sum -c
tar -xf ClikaRT_linux_x86_64-0.6.4.tar.xz
export CLIKART_BUNDLE_DIR="$PWD/ClikaRT_linux_x86_64-0.6.4"

On macOS the check is shasum -a 256 -c over the same line. On Windows, in PowerShell: (Get-FileHash <archive>).Hash -eq "<sha256>", then tar -xf <archive> and $env:CLIKART_BUNDLE_DIR = "$PWD\<extracted dir>". The platform CLI runs the check itself and refuses a file that does not match.

Per platform, the archive and the driver requirements:

OS	Architecture	Archive	Accelerators and drivers
Linux	x86_64	ClikaRT_linux_x86_64-<version>.tar.xz	CPU (no driver) · CUDA (NVIDIA driver only) · Vulkan (Vulkan 1.2 or newer)
Linux	arm64	ClikaRT_linux_arm64-<version>.tar.xz	CPU · CUDA · Vulkan, as above
Windows	x86_64	ClikaRT_windows_x86_64-<version>.zip	CPU · Vulkan
Windows	arm64	ClikaRT_windows_arm64-<version>.zip	CPU · Vulkan
macOS	Apple silicon	ClikaRT_macos_arm64-<version>.tar.xz	CPU · Metal (ships with macOS)
Android	arm64-v8a	ClikaRT_android_arm64-<version>.tar.xz, then Deploy to mobile	CPU · Vulkan

The two Linux archives carry both CUDA images, lib/libClikaRT_cuda13x.so and lib/libClikaRT_cuda12x.so, and each image is self-contained: the CUDA runtime and cuBLASLt are inside it. A CUDA machine needs its NVIDIA driver and nothing else, no CUDA toolkit install and no LD_LIBRARY_PATH; the runtime loads the image the driver serves (a driver of major version 580 or newer serves the CUDA 13 image, an older driver the CUDA 12 image).

Every desktop archive verifies the same way after extraction: run examples/bin/version_00_hello_world (.exe on Windows) from the extracted root; it prints the ClikaRT version.

Python wheels

The clika-runtime wheel is the dialog's Python build: pick the platform, the CUDA image (Linux) and the CPython version (3.10 to 3.14), and the download is a zip holding the wheel for that selection, with its SHA-256 shown like the archives'. The wheel carries the runtime and its backends inside the package, and the Modelverse model library as clika_runtime.modelverse, so the Python path needs no archive and no library paths to set. On Linux (x86_64 and aarch64) the wheel comes in three flavors, told apart by the local version tag; the NVIDIA driver picks the flavor (nvidia-smi prints the driver version in its header):

Version	Contents	Pick it when
0.6.4	every non-CUDA backend, no CUDA image	the machine has no NVIDIA GPU
0.6.4+cu13x	the non-CUDA backends plus the CUDA 13 image	the NVIDIA driver is major version 580 or newer
0.6.4+cu12x	the non-CUDA backends plus the CUDA 12 image	the NVIDIA driver is older than 580

A CUDA flavor's image is self-contained, as in the archives: the driver is the one requirement, no CUDA toolkit and no LD_LIBRARY_PATH. macOS (Apple silicon) and Windows x64 carry no CUDA and ship one unsuffixed wheel each for CPython 3.10 to 3.14; Windows arm64 ships one for CPython 3.11 to 3.14. No wheel declares a requirement on an NVIDIA package. Check the downloaded zip against the SHA-256 the dialog shows, unzip it, and install the wheel inside from the file; numpy is the array bridge the tutorial uses, installed separately.

echo "<sha256>  <the downloaded zip>" | sha256sum -c
unzip <the downloaded zip>
pip install ./clika_runtime-0.6.4+cu13x-cp313-cp313-manylinux_2_28_x86_64.whl
pip install numpy
python -c "import clika_runtime as crt; print(crt.version())"

The last line prints 0.6.4. The platform CLI's clika-cli runtime-sdk pip-command prints one pip install line against the deployment's own package index instead, which picks the wheel for the interpreter it runs under. Use ClikaRT from Python is the guide to the wheel's surface.

Install these wheels with pip. Every wheel is an LZMA-compressed zip, the one compression method that fits the +cu12x flavor's CUDA image under the release asset size limit. pip reads LZMA on any CPython 3.10 or newer whose build carries the lzma module, which the python.org, manylinux, conda and distribution builds do. uv pip install does not read LZMA-compressed wheels.

Modelverse from Python

The same wheel carries Modelverse, the model library, as the clika_runtime.modelverse subpackage: model resolution, generation, pipelines and the serving API. There is no second wheel.

python -c "import clika_runtime.modelverse as mv; print(mv.__version__)"

The line prints 0.6.4. Importing the subpackage loads the runtime first, then the Modelverse extension, which finds the runtime library the same wheel installed; a runtime and a model library from different releases refuse to import, naming both versions. The clikart-cli command-line program is a console script of the same wheel.

The Kotlin artifact and the examples

Three more downloads sit beside the archives and the wheels in the dialog's listing, taken from the same release:

• clika-runtime-maven-<version>.zip, the Kotlin artifact: a Maven repository directory holding io.clika:clika-runtime as an Android AAR and a desktop JVM jar under one coordinate. Extract it anywhere and name the directory to gradle; on Android the AAR is the whole runtime, and on the desktop JVM the jar runs beside the release archive of the same platform (its lib/ on java.library.path); Language bindings says what it carries and Package ClikaRT in an Android app how an app ships it.
• release_manifest.json, the release manifest: one entry per published file with the platform, build type and language it serves, the backends inside it, the files it needs beside it, its digest and size, and the pieces of a split archive in join order; a download page or a script reads the release from it instead of from file names. Its .sha256 sits beside it like every other file.
• ClikaRT-<version>-examples.tar.xz, the examples archive: complete programs in C++, Python and Kotlin with their recorded output, under one examples/ directory whose README.md and AGENTS.md index them. Additional examples is the catalog.

System requirements is the authority on platforms, drivers and hardware.