Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

chore: add managed_agent_limit licensing feature#18876

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
deansheather merged 4 commits intomainfromdean/usage-licensing
Jul 17, 2025

Conversation

deansheather
Copy link
Member

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:

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 amap[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 asmanaged_agent_limit will now be primarily compared by theiat (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 resultingmanaged_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 betweennbf (not before) andexp (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 withfeature_set set topremium 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.

Closescoder/internal#760

// Temporary: If the license doesn't have a managed agent limit,
// we add a default of 800 managed agents per user.
// This only applies to "Premium" licenses.
ifclaims.FeatureSet==codersdk.FeatureSetPremium {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

shouldn't there be some sort of validation of whether the license was issued before that July 1st cutoff?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The cut off date isn't very accurate intentionally to give some buffer.

I don't think we need to check the license issuance date here, because any licenses generated by the new license generator form will always have the correct entitlements included, and will always trump the default limit as they were issued later.

@deansheatherGraphite App
Copy link
MemberAuthor

This stack of pull requests is managed byGraphite. Learn more aboutstacking.

Copy link
Contributor

@dannykoppingdannykopping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Really appreciate the detailed description and explanatory comments throughout. Solid PR 👍 I don't have enough context around our licensing, so I'd suggest getting another review before merging.

// Unfortunately, managed agent count is not a simple count of the current
// state of the world, but a count between two points in time determined by
// the licenses.
ManagedAgentCountFnfunc(ctx context.Context,from time.Time,to time.Time) (int64,error)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

IMO we should be always using interfaces for callbacks like these, that way your LSP can list you all the implementations. (A typealias doesn't work either, I couldn't use the LSP to find all the instances of thereportConnectionFunc when I was working on the connection log 😕)

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

There's only ever gonna be one implementation in the non-test codebase so I don't think this is worth changing all the tests over.

ethanndickson reacted with thumbs up emoji
Comment on lines +215 to +234
if_,ok:=featureGrouping[featureName];ok {
// These features need very special handling due to merging
// multiple feature values into a single SDK feature.
continue
}
iffeatureName==codersdk.FeatureUserLimit||featureName.UsesUsagePeriod() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Anything thatUsesUsagePeriod would already be skipped by having a featureGrouping (above)

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I think I might keep this for defense in depth.

ethanndickson reacted with thumbs up emoji
Note that enforcement and checking usage will come in a future PR.This feature is implemented differently than existing features in a fewways.Firstly, the feature is represented as a single feature in the codersdkworld, 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 allcustomers to upgrade to use new licenses, the decision was made to justuse two features and merge them into one. Older Coder deployments willparse this feature (from new licenses) as two separate features, butit's not a problem because they don't get used anywhere obviously.The reason we want to differentiate between a "soft" and "hard" limit isso we can show admins how much of the usage is "included" vs. how muchthey can use before they get hard cut-off.The second major difference to other features is that "usage period"features such as `managed_agent_limit` will now be primarily compared bythe `iat` (issued at) claim of the license they come from. This differsfrom previous features. The reason this was done was so we could reducelimits with newer licenses, which the current comparison code does notallow 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`: 100Then the resulting `managed_agent_limit` entitlement will come from thesecond license, even though the values are smaller than another validlicense. The existing comparison code would prefer the first licenseeven though it was issued earlier.Existing limit features, like the user limit, just measure the currentusage value of the feature. The active user count is a gauge that goesup and down, whereas agent usage can only be incremented, so it doesn'tmake sense to use a continually incrementing counter forever and everfor 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 thesecond license as this date range.This essentially means, when you get a new license, the usage resets tozero.The actual usage counting code will be implemented in a follow-up PR.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 entitledto use the feature.Unlicensed customers (e.g. OSS) will be permitted to use the feature asmuch as they want without limits. This will be implemented when thecounting code is implemented in a follow-up PR.
@deansheatherdeansheather merged commit183a6eb intomainJul 17, 2025
29 of 31 checks passed
@deansheatherdeansheather deleted the dean/usage-licensing branchJuly 17, 2025 10:19
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsJul 17, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@ibetitsmikeibetitsmikeibetitsmike left review comments

@dannykoppingdannykoppingdannykopping approved these changes

@ethanndicksonethanndicksonethanndickson approved these changes

@EmyrkEmyrkAwaiting requested review from Emyrk

@aslilacaslilacAwaiting requested review from aslilac

Assignees

@deansheatherdeansheather

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Implement license enforcement for AI agents
4 participants
@deansheather@dannykopping@ethanndickson@ibetitsmike

[8]ページ先頭

©2009-2025 Movatter.jp