Licensing AI and ML models

Software vendors licensing AI (artificial intelligence) or ML (machine learning) capabilities typically deliver them in one of two ways: as integrated features within their own application, used by end users who log in, or as direct API access to underlying AI and ML models. This article focuses on two core goals: controlling who can use which AI capabilities and enforcing consumption limits. 10Duke Enterprise allows you to control access to AI features and models while tracking consumption using count-based metered licensing.

For most AI use cases, 10Duke Enterprise recommends combining seat-based allocation—verifying that an authorized user or client holds a seat—with metered tracking of AI usage, such as credits, inference volume, or compute time, using two separate product packages.

10Duke Enterprise licensing solutions for AI and ML models

AI features in your application

If end users log in to your desktop, mobile, or web application and use AI features in its interface, a seat-based license typically controls access to those features, while a use-count license meters their usage with credits. For example, you can include AI features in a subscription, provide a monthly credit allowance with each paid seat, and sell extra credit packs.

If the AI features ship as part of your application, the same license users consume to access the application can also grant access to the AI features. In this setup, you only need an additional license to deliver the credits.

Use one licensed item for granting access and a separate licensed item for credits. The access item uses a seat-based license to control which users can access the AI features. The credit item uses a use-count license to measure and limit how much those features are used. Features that are free to use only require the seat check, while features that cost credits also deduct from the credit balance.

API access to AI models

If you sell API access to your AI models, your customers can call your models from your own application, or from their own applications, or backend services.

In either case, the calling application authenticates with 10Duke Enterprise and obtains an OAuth 2.0 access token, which it uses to call the 10Duke License Consumption API. The caller can be a user who logs into the application, or an application or backend service acting on its own behalf with no user involved. See the available authentication flows for client applications.

The application first consumes the access license—for example, a seat—to verify that it is authorized to use your model API. As requests are made to the API, your application consumes credits from a separate use-count license for each call. Defining each model as a separate licensed item lets you authorize access on a per-model basis. In 10Duke Enterprise, each license grants one credit type—seat count, use count, or use time—as defined for the licensed item in the product package. For AI models, choose the credit type that matches your billing structure.

Count-based metered licensing

Choose count-based metered licensing when billing based on AI credits or output volume, for example, per prediction, per generated image, or per 1,000 tokens processed. This model allows you to restrict and track the exact number of inferences or transactions. A single consumption request can consume several units at once using the consumeCount parameter, allowing actions to carry different costs, such as 10 credits for a standard render and 30 credits for a generated 3D object.

Seat-based licensing

Use a seat-based license to control which users or applications are authorized to use an AI feature or call a model.

Combine seat access with consumption metering

Both AI features in your application and API access to AI models use the same setup: one seat-based licensed item for access and one use-count licensed item for metered usage. Deliver them as two separate product packages, each with its own licensed item and license model. For more information, see combining seat access with usage consumption.

Using two separate packages is required because all licensed items in a product package must share the same credit type. Additionally, because product package quantity applies to all items within a package, separate packages allow you to configure the number of seats and metered units independently.

Credit allowances and pools

Credits can be granted as use-count licenses either to an organization, where all authorized users share the pool, or to an individual user as a personal license. Each grant is a separate license with its own balance and validity period.

To provide a monthly allowance that does not carry over, grant a new use-count license for each period with a validity date ending at the end of that period. Unused credits expire automatically when the license expires.

The total number of credits in a license equals the use count of the credit licensed item multiplied by the product package quantity specified when granting the license.

Credits are managed independently from seats: a seat controls access to an AI tool, while credits are deducted when the tool is used. If your pricing ties credits to the number of seats sold, calculate the credit amount when you grant the license. For example, if you sell 10 seats with 50 credits each, grant a credit product package with a use count of 50 and a quantity of 10. This gives the organization a license with 500 credits.

Grant each purchased credit pack as an additional use-count license for the same credit item with its own validity (for example, valid for 12 months from purchase).

License consumption priority

10Duke Enterprise selects which license to consume based on its license consumption prioritization rules. For use-count licenses, it prioritizes:

Licenses the user is already consuming
Personal licenses over organization licenses
Licenses that expire soonest

If the selected license does not have enough remaining credits for the requested consumeCount, 10Duke Enterprise evaluates the next available license in priority order.

A consumption request draws from a single license only. A request fails if no single license has enough remaining credits, even if the total balance across all licenses would cover the credits. To avoid splitting the credit pool into fragmented small balances, grant each period’s allowance as one license per organization rather than one license per tier.

Managing consumption failures and over-usage

Because license consumption cannot be reversed, follow these best practices:

To charge credits only for successful operations, first check credit availability with doConsume=false, run the AI action, and consume the credits with consumeCount only after the action succeeds.
Because users can share a credit pool, another user can consume the remaining credits between the availability check and the consumption request. Make sure your application knows how to handle a consumption that fails after a successful run.
To prevent user work from being abruptly interrupted when credits run out, allow over-usage with the useCountExt setting of the UtilizationConstraint in the license model. You can configure over-usage either as a fixed number of extra credits or as a percentage of the license’s use count. Note that over-usage acts as a fixed safety buffer per license, not as open-ended metered billing.

Implement AI and ML licensing

To implement AI and ML licensing in 10Duke Enterprise, add the 10Duke Enterprise validation checks to your application’s AI features, or directly into your inference service, model gateway, or API layer. You can use the 10Duke SDKs to handle token management, or build a direct REST API integration to communicate usage from a custom serving stack.

If a consumption request exceeds the configured limits, the License Consumption API returns a specific error code (for example, licenseQuotaExceeded or maxUseCountExceed, depending on the constraint applied). See error codes for the full list your application should handle.

For detailed instructions on configuring custom rules and tracking modes in 10Duke SysAdmin, see defining settings for custom license models. For GPU nodes running in virtualized or containerized infrastructure, see managing licensing in virtualized environments.