Runtime licenses
A runtime license is the credential a ClikaRT runtime presents to prove it is allowed to run. Your platform issues it, per project, and you hand it to the code you ship. Creating, updating and revoking these credentials is one of the reasons the platform exists.
Why you need one, and how you use it
ClikaRT and Modelverse do not run unlicensed. When the runtime starts inside your application, it looks for a credential and checks that the credential is valid and that it grants what the application is about to do: which inference backends it may load, which operating systems it may run on, whether it may run in a container or a virtual machine, and whether it may compress models or export their state. Without a credential the runtime refuses to start, and with a credential that lacks a grant the corresponding call is refused with a typed error.
The credential is not tied to a person or a machine. It is tied to a project on your platform: the project is the thing you license, and every runtime that ships under that project presents the project's credential. That is why issuing one is done from inside a project, and why revoking a credential stops every runtime that presents it.
Using one is a three-step loop, and the diagram below is that loop:
- Issue it on the platform. Open the project, go to Licenses, and issue a credential. You choose the kind (see the two kinds) and the entitlements it grants, or start from an entitlement profile. An Online key is shown once, at creation, so copy it then.
- Hand it to your code. Place the credential where your ClikaRT or Modelverse installation reads it, exactly as you would any other secret your application needs at start-up. Each product's own pages describe where that is for its language bindings and packaging; the credential itself is the same for both, because both are the same runtime.
- Let the runtime prove itself. An Online key is presented to the platform when the runtime starts and again at intervals, so the platform can confirm it, record when it was last seen, and stop it the moment you revoke it. An Offline bundle is verified locally against Clika's signature, which is what lets a runtime work with no route to the platform at all.
Rotate when a credential may have leaked or when its entitlements have to change; revoke when a project is retired. Both are covered under Lifecycle.
The two kinds
The choice is about how the runtime authenticates, not about how strong the credential is.
| Kind | What it is | What it needs | What it gives up |
|---|---|---|---|
| Online | An opaque clika_rk_... key the runtime presents to the platform on each run | A route from the runtime to the platform | Nothing important |
| Offline | A signed CLIKA1-... bundle the runtime verifies locally | Nothing at run time | Real-time revocation |
Most people arrive expecting the offline bundle to be the safer artifact. It is not. A runtime holding one keeps verifying it successfully until the bundle expires, because there is no channel that can tell it otherwise. If revocation has to actually stop a running runtime, issue Online credentials.
Two rules follow from an offline bundle being signed material:
- A project holds at most one active offline bundle. Issuing a second is refused; rotating the existing one replaces it atomically, so the project is never without one.
- An offline bundle's entitlements cannot be edited in place, because they sit inside a signature. Rotating re-signs them, which is the only honest way to change them. The credential's name is the one field you can edit, precisely because it is not signed.
Online credentials have neither restriction: a project can hold as many as it has runtimes, and revoking one takes effect on that runtime's next call.
Entitlements
An entitlement is a permission carried inside the credential. A runtime credential carries a flat set of grants and no quotas: every entitlement is on or off, and off is the default for anything not granted. All of them are always present in the credential, so "not granted" is explicit rather than an absence somebody has to interpret.
Backends
Which inference backend the runtime may load. A backend the credential does not grant will not load, whatever the hardware offers.
| Entitlement | Grants |
|---|---|
| CPU | CPU inference. Always granted: ClikaRT cannot execute without it, so the platform pins it on even when your organization's ceiling would have removed it. |
| NVIDIA CUDA | GPU acceleration on NVIDIA hardware. |
| Vulkan | GPU acceleration through Vulkan, which works on AMD, Intel, Qualcomm and NVIDIA GPUs and is the mobile GPU path. |
| Apple Metal | GPU acceleration on Apple silicon. |
| Qualcomm NPU | NPU acceleration on Qualcomm Hexagon. |
| Google TPU | Google TPU acceleration. |
| Intel NPU, AMD NPU, WebGPU | Reserved for backends the runtime does not ship yet. They exist in the format so a credential issued today stays readable when they do. |
Operating systems
Which platforms the runtime may run on. The allowed set is exactly the entitlements set to true, and at least one has to be granted, so a credential that permits no operating system is refused at issue rather than shipped as an unusable artifact.
Linux, Windows, macOS, iOS, Android, and Web (reserved for the WebAssembly target).
A device whose operating system is not granted is refused with PLATFORM_NOT_ALLOWED.
Execution environment
| Entitlement | Grants |
|---|---|
| Container allowed | Running inside a container, for example under Docker or Kubernetes. |
| VM allowed | Running inside a virtual machine. |
Both are granted by default when a credential is issued. Turning one off is how a license that is meant for physical hardware stays on physical hardware.
Capabilities
| Entitlement | Grants |
|---|---|
| Compression allowed | The model-compression pipeline. Without it a compression call is refused with COMPRESSION_NOT_LICENSED. |
| State export allowed | Exporting optimized state to a third-party format such as ONNX or LiteRT. Off unless granted, and a refusal reads EXPORT_NOT_LICENSED. |
What is not an entitlement
Whether a runtime can work air-gapped is not a grant. It follows from which kind of credential it holds: an Online key needs the platform, an Offline bundle does not. If you see is_airgap, max_hardware, telemetry_level or a requests-per-second field on an old credential, those are retired names the current format does not carry.
Entitlement profiles
A profile is a reusable template for the grants above, scoped to your organization: a name, a description, the entitlement set, and a token lifetime in days (14 when you do not set one). It exists so a team issuing many credentials does not re-enter the same grant set each time, and so "what a lab device gets" is a thing with a name rather than a habit.
The property that matters: a profile is a prefill, not a live link. An issued credential owns its own copy of the grants, so editing the profile afterwards never retroactively changes a credential already in the field. That is deliberate, because the alternative would mean a signed artifact whose meaning changes behind the holder's back.
Profiles feed the enrollment path, where a device activates against a code that names one. Issuing a project credential directly takes its entitlements from the request instead, which is why the issue dialog shows the grants rather than only a profile name.
What you ask for is capped by your organization's ceiling: a grant your organization does not hold cannot be issued to a project, and the issue response names any entitlement it had to narrow. The credential's lifetime is clamped the same way, to the shortest of what you asked for and what the issuing certificate itself outlives.
Lifecycle
- Issue mints a credential for a project. An Online key is shown once, at creation; treat it the way you treat any secret.
- Rotate replaces a credential with a fresh one. For an Online key an acceptance grace can keep the old one working briefly; for an offline bundle it revokes and re-issues in one step.
- Rename is the one edit an offline bundle accepts, because the name is not signed.
- Revoke ends a credential. An Online key stops working on its runtime's next call. An offline bundle stops being served immediately, but a runtime already holding it keeps verifying it until it expires.
- Last seen is recorded per credential, which is the fastest way to find one nothing is using any more.
Where you see it
- Web UI
- CLI
- Claude
Licenses in the sidebar, inside a project. The Licenses tab lists the credentials with their kind, status, issue and expiry dates, key prefix and last-seen time; Issue License mints one; the Profiles tab holds the entitlement templates.
clika-rt licenses entitlement-options
clika-rt projects licenses <project>
The CLI reads the entitlement catalogue and a project's credentials. See the CLI reference for the issue, rotate and revoke commands.
Ask Claude:
List the runtime licenses in this project and tell me which ones have never been used.
That reaches get_projects_id_licenses. Minting a credential is deliberately outside every served toolset, so issuing one stays a human action in the web application or the CLI.
Platform licensing
Everything on this page is about the runtime license, the credential a ClikaRT or Modelverse runtime presents when it starts inside your application. The platform that issues it is licensed separately, as a deployment, and that license is not something you issue from the web application.
The platform itself can run where you need it. Clika operates it as a hosted service, and the same installation is available on-premise, either connected to the internet or fully air-gapped. An on-premise platform issues runtime licenses to your projects exactly as the hosted one does, and the runtime credential it produces is the same artifact described above.
To ask about an on-premise installation of the platform, contact Clika.
Related pages
- Organization and project: what a credential is issued against.
- ClikaRT and Modelverse: the runtimes that present the credential.