Note that enforcement and checking usage will come in a future PR.

This feature is implemented differently than existing features in a few ways.

It's highly recommended that reviewers read:

• This document which outlines the methods we could've used for license enforcement: https://www.notion.so/coderhq/AI-Agent-License-Enforcement-21ed579be59280c088b9c1dc5e364ee8
• Phase 0 of the actual RFC document: https://www.notion.so/coderhq/Usage-based-Billing-AI-b-210d579be592800eb257de7eecd2d26d

Multiple features in the license, a single feature in codersdk

Firstly, the feature is represented as a single feature in the codersdk world, but is represented with multiple features in the license.

E.g. in the license you may have:

{
  "features": {
    "managed_agent_limit_soft": 100,
    "managed_agent_limit_hard": 200
  }
}

But the entitlements endpoint will return a single feature:

{
  "features": {
    "managed_agent_limit": {
      "limit": 200,
      "soft_limit": 100
    }
  }
}

This is required because of our rigid parsing that uses a map[string]int64 for features in the license. To avoid requiring all customers to upgrade to use new licenses, the decision was made to just use two features and merge them into one. Older Coder deployments will parse this feature (from new licenses) as two separate features, but it's not a problem because they don't get used anywhere obviously.

The reason we want to differentiate between a "soft" and "hard" limit is so we can show admins how much of the usage is "included" vs. how much they can use before they get hard cut-off.

Usage period features will be compared and trump based on license issuance time

The second major difference to other features is that "usage period" features such as managed_agent_limit will now be primarily compared by the iat (issued at) claim of the license they come from. This differs from previous features. The reason this was done was so we could reduce limits with newer licenses, which the current comparison code does not allow for.

This effectively means if you have two active licenses:

• iat: 2025-07-14, managed_agent_limit_soft: 100, managed_agent_limit_hard: 200
• iat: 2025-07-15, managed_agent_limit_soft: 50, managed_agent_limit_hard: 100

Then the resulting managed_agent_limit entitlement will come from the second license, even though the values are smaller than another valid license. The existing comparison code would prefer the first license even though it was issued earlier.

Usage period features will count usage between the start and end dates of the license

Existing limit features, like the user limit, just measure the current usage value of the feature. The active user count is a gauge that goes up and down, whereas agent usage can only be incremented, so it doesn't make sense to use a continually incrementing counter forever and ever for managed agents.

For managed agent limit, we count the usage between nbf (not before) and exp (expires at) of the license that the entitlement comes from. In the example above, we'd use the issued at date and expiry of the second license as this date range.

This essentially means, when you get a new license, the usage resets to zero.

The actual usage counting code will be implemented in a follow-up PR.

Managed agent limit has a default entitlement value

Temporarily (until further notice), we will be providing licenses with feature_set set to premium a default limit.

• Soft limit: 800 * user_limit
• Hard limit: 1000 * user_limit

"Enterprise" licenses do not get any default limit and are not entitled to use the feature.

Unlicensed customers (e.g. OSS) will be permitted to use the feature as much as they want without limits. This will be implemented when the counting code is implemented in a follow-up PR.

Closes coder/internal#760