P2 [CRF-2] The inner JOIN groups ON groups.id = tu.effective_group_id silently drops real spend, so this "organization AI spend" CSV can undercount money with no signal. (Mafuuu P2, Knuckle P3)

The raw table is the superset that contains spend the rollup omits... an operator exporting to reconcile or charge back AI cost gets a total that is systematically short by the entire spend of users who resolve to no effective group.

Two classes vanish: token usage with effective_group_id IS NULL (a real, tested state carrying non-zero cost, per ExcludesNullEffectiveGroup), and usage referencing a hard-deleted group (no FK; DeleteGroupByID deletes the row, orphaning historical effective_group_id). "Consistent with the rollup" is the defense and it holds for consistency, but the PR chose the raw table because it is the superset, then filtered it back to the rollup's blind spot. The swagger @description promises org spend with no caveat. Whether ungrouped/orphaned spend belongs here is a product decision: surface it (a sentinel/ungrouped group value) or document the exclusion in swagger. Knov also notes the export keeps cost_micros <= 0 rows the rollup skips, a second divergence from the "consistent" claim. Intentional-but-flagged, proven by test; not a silent accept.

🤖

Ungrouped spend only happens for users with no org membership, and the daily table can't represent it either since effective_group_id is NOT NULL there. Regarding cost_micros, the only advantage I see is that the CSV could distinguish a priced model that resulted in zero cost from an unpriced one. But if the price is updated during the budget period (currently only via a release), usage recorded before and after it would aggregate into the same row, so we would lose that distinction anyway. Let me know what you think.

P2 [CRF-4] The full aggregation is buffered in memory with no row cap, the comment justifies it with a bound that does not exist, and the post-filter runs the full-org query for every caller. (Knov P2, Meruem P2)

The comment claims "The row count is bounded by the 31-day period cap." The 31-day cap bounds the time window, not cardinality. Result rows are one per distinct (initiator_id, effective_group_id, provider, model) tuple... There is no LIMIT, unlike the sibling endpoints in this same file which explicitly cap output (maxOrganizationGroupsAISpendGroupIDs = 100).

Separately, fetchWithPostFilter runs ExportOrganizationAISpend unscoped and materializes every org row into Go (a second copy in rbac.Filter, then the bytes.Buffer), so a plain member exporting "their own" spend still forces the whole-org aggregation and buffer. This compounds with CRF-3 (the full scan) into a low-privilege resource-exhaustion vector. Nearly the whole panel flagged the false comment (Hisoka, Pariston, Leorio, Ryosuke, Razor, Chopper, Kurapika). Fix: bound the row count (cap distinct users like the siblings cap IDs, or paginate/stream), and state the real bound in the comment.

🤖

Members can't hit this endpoint anymore. We still build the whole CSV in memory, which is what the RFC describes (link), and it's also what lets us fail with a clean 500 rather than a truncated file. fetchWithPostFilter already loads every row before the handler runs, so streaming wouldn't avoid that allocation, but we can add it later if this proves problematic. Also worth noting the endpoint is capped at 31 days, which helps bound the result size.

Scoping this endpoint only to organization-level admin permissions as per the RFC.
This is slightly inconsistent with the group members spend endpoint, which for regular members, returns just their spend. But this is a different scope, which seems admin-related.