Licensing for AI apps

AI apps have a licensing problem that older software did not: the product is partly a piece of software and partly an ongoing stream of inference. Those are two different things to charge for, and the most common mistake is letting them blur into one tangled system. This page is about keeping them separate, and licensing the app cleanly.

Two things, not one

An AI desktop app contains two distinct commercial objects.

The first is the app itself — the interface, the features, the workflow, the thing the customer installs. That is software, and software is licensed: a customer is entitled to run it, on some number of devices, on some plan.

The second is AI usage — tokens through a hosted model, GPU minutes, requests to an inference endpoint. That is consumption, and consumption is metered: it accrues per use and is billed by volume.

These have different shapes. A license is a yes/no entitlement that is cheap to verify and works offline. Metering is a running count that must be tracked server-side because usage happens against your cost. Trying to express both in one mechanism — a “license” that also somehow tracks token balances inline — produces something that is bad at both jobs.

The clean design keeps them apart: a signed license key entitles the customer to run the app, and a separate usage system handles inference. A licensing layer owns the first. The second is yours, or your model provider’s billing, layered on top. This page is about doing the first part well so the second is free to be whatever it needs to be.

Licensing the app

Licensing the app part of an AI product is the same problem as licensing any desktop app, and the same answer applies: a signed key the app verifies locally.

The customer pays through Stripe; a licensing layer mints an Ed25519-signed lease and delivers it. The app ships with the public key and verifies the lease at launch — confirming the customer is entitled to run the app. Whether any given action then costs tokens is a separate question your metering answers; the license question is settled, locally and instantly, before that.

Keeping the license offline-verifiable matters even for a cloud-backed AI app. The app should open and present its UI without waiting on a network round-trip — the network dependency belongs to the inference call the user explicitly triggers, not to the act of launching the app. A signed-key license gives you that: launch is local, inference is online, and the two are not entangled.

On-device and local-model AI

A growing class of AI apps run the model on the device — local LLMs, on-device vision and audio models, privacy-first assistants. The entire selling point is that nothing leaves the machine.

For these apps, online license validation is self-defeating. You have built a product whose value is that it needs no server, and then bolted on a licensing check that does. On an air-gapped or offline machine — exactly where these customers run the app — that check cannot reach the server at all, forcing the same lose-lose: lock out a paying customer, or let the check be skipped entirely.

Offline license validation is the only model that fits. The signed license is verified locally, with no network call, so a fully on-device AI app stays fully on-device. Licensing introduces zero server dependency where the product deliberately has none.

Scaling to a team

AI tools spread fast — one person on a team finds an AI app useful and it is in everyone’s dock within a month. Licensing has to keep up.

A licensing layer handles this through the device activation limit as a seat count. A solo license allows a few activations; a team tier allows more. Each member activates the app on their machine against the shared license, and growing the team means moving up a tier — not rebuilding licensing. The app license scales with seats; your usage metering scales with consumption; the two scale independently, which is exactly what you want.

Doing it with Keylight

Keylight issues the app-license half of an AI product as an Ed25519-signed lease. A Stripe payment mints and delivers it automatically (see Stripe integration); the app verifies it offline. Keylight does not meter your tokens — and that is the point. It cleanly owns the app entitlement, leaving your inference billing to be designed on its own terms.

import KeylightSDK

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:
    enableAppFeatures()       // entitled to run the app
case .trial(let daysLeft):
    showTrialBanner(daysLeft: daysLeft)
case .expired:
    showRenewalPrompt()
case .invalid:
    showActivationSheet()
}
// Token metering / usage limits are a separate system layered on top.

License the app with a signed key; meter the AI usage separately. Keeping the two distinct keeps both simple. See offline license validation for on-device models, license keys for the signed-lease model, and Pricing — from $19/month with a free tier.