--- title: Get ClikaRT description: Pick your OS, architecture and accelerator, and get the download, verify and extract commands for the archive the CLIKA platform hands out. --- import GetClikaRT from '@site/src/components/GetClikaRT'; 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](/platform/how-to/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__-.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 `` below. Then continue with [Quick install](installation.md), which picks up at the extracted bundle. [Complete installation](complete-installation.md) 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](/platform/concepts/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: ```bash 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: ```bash "$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](../how-to/license-the-runtime.mdx) 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: ```bash echo " 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 ).Hash -eq ""`, then `tar -xf ` and `$env:CLIKART_BUNDLE_DIR = "$PWD\"`. 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-.tar.xz` | CPU (no driver) · CUDA (NVIDIA driver only) · Vulkan (Vulkan 1.2 or newer) | | Linux | arm64 | `ClikaRT_linux_arm64-.tar.xz` | CPU · CUDA · Vulkan, as above | | Windows | x86_64 | `ClikaRT_windows_x86_64-.zip` | CPU · Vulkan | | Windows | arm64 | `ClikaRT_windows_arm64-.zip` | CPU · Vulkan | | macOS | Apple silicon | `ClikaRT_macos_arm64-.tar.xz` | CPU · Metal (ships with macOS) | | Android | arm64-v8a | `ClikaRT_android_arm64-.tar.xz`, then [Deploy to mobile](first-program/06-deploy-to-mobile.mdx) | 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](/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. ```bash echo " " | sha256sum -c unzip 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](../how-to/use-clikart-from-python.mdx) 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](/modelverse), the model library, as the `clika_runtime.modelverse` subpackage: model resolution, generation, pipelines and the serving API. There is no second wheel. ```bash 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-.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](../bindings.md) says what it carries and [Package ClikaRT in an Android app](../how-to/package-clikart-in-an-android-app.mdx) 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--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](../examples.md) is the catalog. [System requirements](/system-requirements.md) is the authority on platforms, drivers and hardware.