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 valid credential the runtime does not serve the application, 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, and by default not to a machine either; a hardware seat budget (below) can cap how many machines hold one. 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:

1. 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 Offline bundle is shown once, at creation, so copy it then; an Online key can be read back later.
2. Hand it to your code. The artifact you distribute is the CLIKA1-... text the platform shows as the license's license key, for both kinds. Put it where your ClikaRT or Modelverse installation reads it, exactly as you would any other secret your application needs at start-up: License the runtime describes the places for each language binding and packaging, the clika-modelverse command and an Android app included; the credential itself is the same for both products, because both are the same runtime.
3. 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	A CLIKA1-... license key the runtime presents to the platform on each run	A route from the runtime to the platform	Nothing important
Offline	A signed CLIKA1-... license bundle the runtime verifies locally	Nothing at run time	Real-time revocation

Both kinds arrive as the same CLIKA1-... text, and that text is the whole artifact you hand the runtime; a bare clika_rk_... API key is not a credential and is refused.

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, telemetry_level or a requests-per-second field on an old credential, those are retired names the current format does not carry. max_hardware is not an entitlement either: it is the platform's own seat budget, described below, and the runtime never receives it.

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 Offline bundle's signed material appears in the issue response and nowhere else, so a lost one is replaced by rotating. An Online key can be read back after issue, which is recorded in the audit log. Treat both 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.
• Expiry ends a credential on its end date, with no grace period after it. A call made from then on is refused with the code name LICENSE_EXPIRED, where a call made with no credential at all, or an invalid one, is refused with LICENSE_FAILED. Re-issue before the date rather than after it.
• Last seen is recorded per credential, which is the fastest way to find one nothing is using any more.

Hardware seats

A credential can carry a hardware seat budget: how many distinct machines may hold it. You set it when you issue or rotate a credential and change it in place on the credential's detail page; 0 means unlimited, which is the default. The platform enforces it at every runtime check-in, for Online keys and Offline bundles alike: the first machines to present the credential take the seats, a machine beyond the budget is refused with a reason that says so, and a credential with a budget refuses a runtime that does not identify its hardware at all. The detail page lists every machine holding a seat with when it was first and last seen and a Release action per row, and the credential list shows seats as used / max. The budget is platform-side only: it is never part of the entitlements the runtime receives, so changing it does not re-issue anything.

The credentials the platform mints for its own benchmark runs are single-machine and are never counted as your organization's license usage.

Where you see it

Web UI

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.

CLI

clika-cli projects licenses <project>

The CLI lists a project's credentials. See Using the CLI for the issue, rotate and revoke commands.

Claude

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.
• License the runtime: where a ClikaRT or Modelverse runtime reads the credential, per language and packaging, and what a refused call looks like.