P3 [CRF-1] Effective-budget resolution is re-implemented inline here and hardcodes the highest policy, with nothing coupling it to the canonical budget.ResolveUserAIBudget. (Meruem P3, Zoro P3, Knuckle P3, Razor P3, Pariston P3, Luffy P3; Hisoka Note, Mafuuu Note)

Enforcement resolves the effective budget through budget.ResolveUserAIBudget (coderd/aibridge/budget/budget.go:40), which takes AIBudgetPolicy as a parameter, switches on it, and returns an error for any unsupported policy. This user_highest_group CTE bakes ORDER BY spend_limit_micros DESC, group_name ASC, group_id ASC (a copy of GetHighestGroupAIBudgetByUser) and never reads AI.BridgeConfig.BudgetPolicy.

Today this is correct because AIBudgetPolicyHighest is the only policy, so I am rating latent divergence, not a live bug. Meruem named the unstated assumption: "the effective group / limit_source shown by this endpoint equals the budget that actually enforces spend. Nothing enforces that." When a second policy is added (or the tie-break in GetHighestGroupAIBudgetByUser changes), enforcement follows the switch while this endpoint keeps reporting highest, so the admin cost-control UI shows an effective_group_id/spend_limit_micros/limit_source the system does not enforce, and this SQL cannot fail closed the way the Go resolver does.

Keep the batch SQL (resolving 100 users through Go would be an N+1). Close the drift mechanically: thread the policy in, or add a test that pins this endpoint's per-user resolution against ResolveUserAIBudget for the same fixtures (Zoro: "a test that fails when codersdk.AIBudgetPolicies grows beyond one entry"). A comment alone will rot; the enum has no compiler tie to this string.

🤖

This is a good point, and I thought about it too, not just for new policies (phase 1 ships only the Highest policy) but also in the context of AIGOV-509, which adds a fallback to the Everyone group when a user has no budgeted group. As a result, I think we should aim for a single piece of logic that handles user effective group resolution, unified for both single-user and batch.

A possible approach would be to convert ResolveUserAIBudget into a ResolveEffectiveGroup that receives a set of users, with the flow:

1. get the user(s) overrides
2. for user(s) without an override, resolve the effective group by policy (highest/lowest, ...)
3. for user(s) with no budgeted group, fall back to the Everyone group (AIGOV-509)

This keeps user effective group resolution in a single function. It probably makes sense to address as part of AIGOV-509.

Yeah I think that would be a good call here.

I think we should aim for a single piece of logic that handles user effective group resolution, unified for both single-user and batch.

Does it imply removing this query in the future?

A possible approach would be to convert ResolveUserAIBudget into a ResolveEffectiveGroup that receives a set of users, with the flow:

1. get the user(s) overrides
2. for user(s) without an override, resolve the effective group by policy (highest/lowest, ...)
3. for user(s) with no budgeted group, fall back to the Everyone group (AIGOV-509)

Will this flow be implemented in Go (similar to ResolveUserAIBudget function) or at the SQL level (similar to the GetGroupMembersAISpend query)?

Will this flow be implemented in Go (similar to ResolveUserAIBudget function) or at the SQL level (similar to the GetGroupMembersAISpend query)?

The initial idea was in Go similar to ResolveUserAIBudget, more precisely: a set of SQL queries that narrow the users at each step (users with an override, then users with an effective group, and so on). I started drafting this as part of AIGOV-509, but it turned out to be less trivial than I expected, mainly because GetGroupMembersAISpend also does filtering of its own (restricting to users that belong to the group, plus org scoping). Unifying resolution would mean moving that logic to an upper layer, above resolution, which makes it a bigger change.

Other alternatives could be a view that applies the highest policy (though that needs one view per policy), or a SQL function that takes the policy as a parameter. I created AIGOV-527 to track this as a follow-up and added TODO comments linking it in the relevant code.

Note [CRF-5] GroupMemberAISpend re-declares the four fields that already live embeddable in UserAIBudgetSummary. (Robin Note)

UserAIBudgetSummary (codersdk/aibridge.go:29) already carries UserID, EffectiveGroupID, SpendLimitMicros, and LimitSource with identical json tags and was built to be embedded. This struct copies all four inline and adds only GroupSpendMicros, so it could be struct { UserAIBudgetSummary; GroupSpendMicros int64 }. The one honest reason to keep them apart is that the null semantics diverge (see CRF-2). If that divergence is intentional the copy is defensible; if not, embed. Worth a decision rather than a reflexive copy.

🤖

The fields are kept inline on purpose since the null semantics differ from UserAIBudgetSummary. Here effective_group_id can be set while spend_limit_micros and limit_source are null (the effective group is a different same-org group), whereas in UserAIBudgetSummary they are all set or all null. I considered having the same logic, but since this endpoint is for a specific group, it does not make sense to give user's budget information about a different group. cc @EhabY

After discussing this with @EhabY we came to the conclusion that a cleaner approach would be to have a new group_budget object (including spend_limit_micros and limit_source), that is only returned when effective_group_id == the queried group.

Addressed in d7c03aa

Note [CRF-6] GroupSpendMicros/group_spend_micros diverges from the two sibling types that name the same concept CurrentSpendMicros/current_spend_micros. (Gon Note)

UserAISpendStatus.CurrentSpendMicros and OrganizationGroupAISpend.CurrentSpendMicros both use CurrentSpendMicros for period spend. There is a real semantic reason to differ here (this is spend attributed to the queried group, which may not be the member's effective group) and the doc comment states it, so this is not clearly wrong. But the Group prefix on a per-member field reads like an aggregate group total, and group_spend_micros is now permanent public API surface. Worth a maintainer confirming the JSON key is the one to ship.

🤖

group_spend_micros is the spend attributed to the queried group, which can differ from the user's current effective group. The user spend endpoints use current_spend_micros for the user's current effective group. Not sure what would be a better name. Happy to hear other suggestions.

Just a note regarding RBAC: effective_group_id is returned only when the member's effective group is in the same org as the queried group. Since orgs should be seen as tenant-specific, an effective group in a different org is treated the same as no effective group (null).
When plain members call this endpoint, they only receive their own row, and since a user is always a member of their own effective group, it is fine to return it to them.

As for admin roles, IIUC every admin role that can read members' rows also has read access to all groups in the org, so if an admin can read group A it can also read group B in the same org. If we ever introduce group-scoped access roles, we will need to reevaluate this.

Let me know if you see any issues.

I think that makes sense.

Another alternative considered was an endpoint that returns a user's spend in a group even if they are not currently a member of that group: /api/v2/organizations/{organization}/groups/{groupName}/ai/spend.
The only difference would be the case where the queried group was previously the user's effective group and they have spend attributed to it, but they were later removed from the group. That would be a more generic endpoint, but since this is currently only used for the group members page in the UI, I thought it was better to keep it consistent with the existing group members endpoint that feeds it.

In this case, the spend remains attributed to the group correct? It doesn't just vanish?

Correct, the spend is always attributed to a group, and it is always immutable. So spend that is attributed to group A will always be attributed to group A. It always depends on the user's effective group at the interception time.

In this specific example, even if the user is no longer a member of the group, the spend is still attributed to it. There is an edge case, though: if the user is again added to the group, it will keep the spend (if still within the budget period), but I think that is ok...otherwise, users could use this hack to get unlimited spend 😅 (even though they already have this unlimited possibility from the Everyone group)