Skip to main content

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 clikart-cli 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 refuse it the moment you revoke it: a runtime starting afresh is refused at once, and a runtime already running is cut off at its next check-in, which the runtime makes every five minutes. 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.

The runtime-license loop: a project on the Clika Platform issues a credential; you place it with your application; the ClikaRT or Modelverse runtime inside the application presents it. An Online key is confirmed by the platform at start and at intervals; an Offline bundle is verified locally against Clika's signature.

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.

KindWhat it isWhat it needsWhat it gives up
OnlineA CLIKA1-... license key the runtime presents to the platform on each runA route from the runtime to the platformNothing important
OfflineA signed CLIKA1-... license bundle the runtime verifies locallyNothing at run timeReal-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 on a machine with no route to the platform keeps verifying it successfully until the bundle expires, because nothing can tell it otherwise; a runtime that can reach the platform picks the revocation up at its next start (within seconds in our tests), but nothing forces a runtime to reach it. If revocation has to actually stop a running runtime, issue Online credentials.

Rotation and revocation differ by kind for the same reason. Rotating an Online key issues a new key and the platform stops accepting the old one at once, or at the end of a handover grace you choose when rotating (up to seven days), so running SDKs can switch; revoking one stops it on its next call. Rotating or revoking an Offline bundle marks it here and puts its certificate serial on the deployment's revocation list (GET /api/v1/crl), but a runtime already holding the bundle keeps verifying it until that list reaches it or the bundle expires: redeploy the replacement, and deliver the list where revocation has to bite before expiry.

Two rules follow from an offline bundle being signed material:

  • A project holds as many active Offline bundles as it has runtimes or devices; one per node is the node-locked shape, and each bundle has its own leaf certificate and serial, rotated and revoked on its own. The bound is the organization's plan: its Offline-license limit caps the active bundles across the organization's projects, and issuing past it is refused with OFFLINE_LICENSE_LIMIT_REACHED naming the limit. Rotating a bundle replaces it, so a rotation never counts against the limit.
  • 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 no such bound: a project can hold as many as it has runtimes, and revoking one is enforced by the platform at once and reaches a running runtime at its next check-in, within five minutes.

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.

EntitlementGrants
CPUCPU 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 CUDAGPU acceleration on NVIDIA hardware.
VulkanGPU acceleration through Vulkan, which works on AMD, Intel, Qualcomm and NVIDIA GPUs and is the mobile GPU path.
Apple MetalGPU acceleration on Apple silicon.
Qualcomm NPUNPU acceleration on Qualcomm Hexagon.
Google TPUGoogle TPU acceleration.
Intel NPU, AMD NPU, WebGPUReserved 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​

EntitlementGrants
Container allowedRunning inside a container, for example under Docker or Kubernetes.
VM allowedRunning 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​

EntitlementGrants
Compression allowedThe model-compression pipeline. Without it a compression call is refused with COMPRESSION_NOT_LICENSED.
State export allowedExporting 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.
  • Copy on the credential's detail page hands an Online key back to a license manager of the project. The page shows the key's clika_rk_ prefix, and Copy puts a freshly signed CLIKA1- bundle on the clipboard, which is the whole value a runtime takes; each one is recorded in the audit log. An Offline bundle cannot be read back: its private key is never stored, so a lost bundle is replaced by a rotation.
  • 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. A runtime holding the old Online value is refused at its next check as revoked; a runtime holding the old offline bundle keeps working until that bundle expires, so redeploy it. The credential a rotation supersedes shows as rotated out, with the replacement beside it; a runtime still presenting a rotated-out Online key is refused with LICENSE_STATE_BLOCKED: runtime key rotated out; the project issued a replacement.
  • Rename is the one edit an offline bundle accepts, because the name is not signed.
  • Revoke ends a credential. An Online key is refused by the platform from that moment; a running runtime is cut off at its next check-in, within five minutes, and a new start is refused at once. The running runtime reports the cut-off as LICENSE_STATE_BLOCKED. An offline bundle stops being served immediately; a runtime already holding it is refused at its next start if the machine reaches the platform, and keeps verifying it until it expires if it does not.
  • 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. The web form takes a count of 1 or more and starts at 1 on every plan (one license takes one seat unless you type more); on a plan with a seat budget a request past the seats left is refused with 409 HARDWARE_SEAT_BUDGET_EXCEEDED, which names the budget. A credential issued through the API, the CLI or the MCP server with no budget, or with 0, has no seat limit, and the detail page shows it as Unlimited. 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.

What identifies a machine is the runtime's hardware fingerprint, one digest over what the host lets the process read. On Linux, macOS and Windows that is the machine's own identity (the OS install id, the board and disk serials, the network hardware) beside its processor and accelerators. On Android it depends on the process:

  • An app that loads the runtime through ClikaRtAndroid.load identifies the device through the identity Android scopes to the app (Settings.Secure.ANDROID_ID), which survives a reinstall under the same signing key and changes on a factory reset.
  • A command the app launches, such as the runtime's own command line run from a launcher app, cannot read the device's serial (Android hides it from app processes) and has no app state of its own, so the runtime identifies the installation instead: an identity it mints once and keeps in a file under the cache root the launcher sets for the process (XDG_CACHE_HOME, or HOME). Two apps on one phone are two installations; clearing the app's cache or reinstalling it mints a new one, which takes a new seat. A launcher that sets neither variable leaves the process with no place to keep the identity, and the runtime then reports only the device model, which a budgeted credential refuses.
  • A shell on the phone (adb shell) reads the device serial and identifies the unit by it.

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​

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.

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.