Get ClikaRT
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) with a .sha256 checksum beside it; the tree inside is that platform's complete bundle. The two Linux archives arrive as two numbered pieces, .00.part and .01.part, that concatenate in order into the archive; the checksum covers the joined file. The public download page is to be available soon; until then your delivery contact provides the pieces and the checksum with your evaluation, and the commands start from those files.
# ClikaRT_linux_x86_64-0.5.1.tar.xz.00.part, ClikaRT_linux_x86_64-0.5.1.tar.xz.01.part and ClikaRT_linux_x86_64-0.5.1.tar.xz.sha256: the archive you received and the checksum beside it.
cat ClikaRT_linux_x86_64-0.5.1.tar.xz.00.part ClikaRT_linux_x86_64-0.5.1.tar.xz.01.part > ClikaRT_linux_x86_64-0.5.1.tar.xz
sha256sum -c ClikaRT_linux_x86_64-0.5.1.tar.xz.sha256
tar -xf ClikaRT_linux_x86_64-0.5.1.tar.xz
export CLIKART_BUNDLE_DIR="$PWD/ClikaRT_linux_x86_64-0.5.1"
# Verify:
"$CLIKART_BUNDLE_DIR"/examples/bin/version_00_hello_worldNo 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 and an offline one; an API key (clika_rk_...) is not a credential. Runtime licenses is where a credential comes from.
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 changes, and on Linux the two pieces are joined first. The files come from your delivery contact (the public download page is to be available soon):
cat ClikaRT_linux_x86_64-0.5.1.tar.xz.00.part \
ClikaRT_linux_x86_64-0.5.1.tar.xz.01.part > ClikaRT_linux_x86_64-0.5.1.tar.xz
sha256sum -c ClikaRT_linux_x86_64-0.5.1.tar.xz.sha256
tar -xf ClikaRT_linux_x86_64-0.5.1.tar.xz
export CLIKART_BUNDLE_DIR="$PWD/ClikaRT_linux_x86_64-0.5.1"
The order matters: cat in piece order, then check the joined file against the sidecar. The Windows, macOS and Android archives are each one file, so they skip the cat step.
(Windows, in PowerShell: compare (Get-FileHash <archive>).Hash against the .sha256 sidecar, tar -xf <archive>, $env:CLIKART_BUNDLE_DIR = "$PWD\<extracted dir>".)
Per platform, the archive and the driver requirements:
| OS | Architecture | Archive | Accelerators and drivers |
|---|---|---|---|
| Linux | x86_64 | ClikaRT_linux_x86_64-<version>.tar.xz, delivered as .00.part + .01.part | CPU (no driver) · CUDA (NVIDIA driver only) · Vulkan (Vulkan 1.2 or newer) |
| Linux | arm64 | ClikaRT_linux_arm64-<version>.tar.xz, delivered as .00.part + .01.part | CPU · CUDA · Vulkan, as above |
| Windows | x86_64 | ClikaRT_windows_x86_64-<version>.zip | CPU · Vulkan · CUDA on request |
| 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 ships beside the archives, one per CPython version (3.10 to 3.14) and platform, from the same delivery contact until the public download page is available. It carries the runtime and its backends inside the package, 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.5.1 | every non-CUDA backend, no CUDA image | the machine has no NVIDIA GPU |
0.5.1+cu13x | the non-CUDA backends plus the CUDA 13 image | the NVIDIA driver is major version 580 or newer |
0.5.1+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. Take the wheel whose CPython tag, platform tag and flavor match the machine, verify it against its .sha256 sidecar, and install it from the file; numpy is the array bridge the tutorial uses, installed separately.
sha256sum -c clika_runtime-0.5.1+cu13x-cp313-cp313-manylinux_2_28_x86_64.whl.sha256
pip install ./clika_runtime-0.5.1+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.5.1. 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.
The Modelverse wheel
Modelverse ships its Python binding as its own wheel, clika_modelverse, for the same five platforms and the same CPython versions. It carries the Python package alone (model resolution, generation, pipelines, the serving API) and declares one requirement, clika-runtime at the matching version, which pip resolves from the runtime wheel you installed:
sha256sum -c clika_modelverse-0.5.1-cp313-cp313-manylinux_2_28_x86_64.whl.sha256
pip install ./clika_modelverse-0.5.1-cp313-cp313-manylinux_2_28_x86_64.whl
python -c "import clika_modelverse; print(clika_modelverse.__name__)"
The clika-modelverse command-line program comes from the clika-runtime wheel, which installs it as a console script, so the Modelverse wheel is only needed for the Python API.
System requirements is the authority on platforms, drivers and hardware.