GLOOK-37: expose per-developer model and skills usage via MCP

[msogin]

GLOOK-37

The MCP server exposed only two Claude Code fields per developer — cc_total_cost and cc_requests. The per-model and per-product breakdowns that GLOOK-30 ingests were reachable from the REST routes and three UI surfaces, but not over MCP, because the MCP server is a separate query layer that was never extended to read them.

Two new tools, taking the server from 14 to 16:

Tool	Source	Visibility
query_model_usage	cc_model_usage	gated — a hidden developer contributes no rows
query_skills_usage	cc_skills_usage	ungated

Both accept report_id, login, limit, matching the sibling query_* tools.

Why two tools instead of widening query_developer_stats

Callers that don't want breakdowns don't pay for them — query_developer_stats returns up to 500 developers, and per-model rows would multiply that. More importantly it puts the visibility asymmetry at the tool boundary rather than burying two different gating rules inside one response shape.

requests is gated, not just cost

requests isn't currency, but summing a developer's per-model requests reconstructs the gated cc_requests exactly — same window, merely grouped by model. Gating only the dollar figure would reopen what stripDevCost closes. This is the leak the PR #64 whole-branch review caught, and there's a test asserting a hidden developer's requests sum to zero.

Gating reuses stripModelCost, which drops a hidden developer's rows wholesale rather than blanking amounts, so "cannot see this developer's cost" stays indistinguishable from "has no Claude usage".

querySkillsUsage takes no requester parameter

Skills usage is ungated by policy (see CC_FIELDS in cost-visibility.ts — skill counts convert to no currency, so they sum to no gated figure). Omitting the parameter entirely makes that a compile-time fact rather than a convention a later edit can quietly break.

Shared fail-closed helper

Extracted the visibility resolution out of queryDeveloperStats into resolveCostVisibility, so the fail-closed rule has one implementation rather than one per tool. The admin / no-requester short-circuits stay ahead of the reportOrg lookup — mcp-cost-gating.test.ts asserts exact db.execute call counts to prove the fail-closed path performs no team query, so that ordering is load-bearing.

Verification

Unit tests mock db.execute and therefore cannot see the SQL at all, so I went further:

• Ran both queries against a real SQLite database through the translating wrapper. Confirmed the INNER JOIN developer_stats excludes a login with no row for the report, that LOWER() matches carol against Carol (an exact-case join would silently drop it), and that DECIMAL cost returns 12.5 rather than "12.50".
• Ran both against the seeded glooker.db — real rows out, count: 0 with no requester.
• Mutation-checked the requester-forwarding test. Registering the handler as (a) => queryModelUsage(a) makes it fail, which is the point: that bug fails closed and silently returns nothing for everyone, and no test calling the query function directly would notice.

npm test: 104 suites, 934 tests, 9 snapshots — all passing (+8 from this branch).

Notes for review

• LIMIT applies before gating, so a team member can receive fewer rows than their limit when hidden developers occupy some. This mirrors queryDeveloperStats exactly; kept consistent rather than diverging.
• Both queries INNER JOIN developer_stats for the reasons documented above the equivalent queries in report/org.ts — an unjoined read reports a wider population than every other per-report figure.
• No schema, ingestion, or seed changes: scripts/seed.ts already seeds both tables.

🤖 Generated with Claude Code

[msogin]

Review summary

Four independent reviewers: a senior-backend-architect pass (correctness), a security pass (authorization & inference), the standard Smartling fullstack review, and a minimalist scope gate. Findings deduplicated and verified against the code before posting. No fixes were applied — this is comment-only.

Severity	Count
🔴 critical	1
🟡 warning	3
🟣 question	2
🔵 suggestion	8

The one that matters

LIMIT is applied before gating (queries.ts:294, :346). Three reviewers reached this line independently, each seeing a different consequence: entitled rows becoming unreachable, count acting as an inference oracle on hidden developers, and silently partial aggregates. One fix closes all three.

This also refutes the PR description's justification for leaving it as-is. The description says the behavior "mirrors queryDeveloperStats exactly." It doesn't — stripDevCost keeps rows and blanks fields, so the limit is harmless there; stripModelCost returns [], which is what converts a pre-gating limit into a defect. The asymmetry between the two strip functions is the whole story, and it's the reason the consistency argument doesn't transfer.

On the description's other claims

The PR makes a careful case for its design; most of it holds, two parts don't:

• requests is gated, not just cost — holds, and I verified all four returned fields drop wholesale, not just the two discussed. Worth noting this required zero lines in this PR: requests was already in MODEL_COST_FIELDS at base, so queryModelUsage inherits it by calling stripModelCost. The gating is real; the credit belongs to #64.
• Fail-closed with one implementation — holds, and it's the strongest of the four claims. Every input shape was exercised (absent requester, empty/null login, unknown login, no team, missing reports.org, DB error mid-lookup, nonexistent report_id): all yield zero rows or error before any data read. resolveCostVisibility is semantically identical to the inline logic it replaces, and the admin/no-requester short-circuits do stay ahead of the org lookup.
• "Hidden is indistinguishable from no Claude usage" — holds within one response, not across the tool surface. query_developer_stats distinguishes the two in a single call by key presence (stripCostFields deletes the key; cc_total_cost is NOT NULL DEFAULT 0, so genuine zero-usage returns 0). See the comment on mcp-cost-gating.test.ts:88 — the fix is most likely three comments, not a behavior change.
• Two tools rather than widening query_developer_stats — the right call, but not for the stated reason. "Callers that don't want breakdowns don't pay for them" doesn't hold up: MCP callers pay per invocation either way. The split survives on the second reason given — the two datasets have opposite gating, so one tool would have to accept a requester and ignore it for half its output.
• querySkillsUsage taking no requester makes ungated-ness "a compile-time fact" — weak as stated, since McpTool.handler is typed (args, requester?) and nothing would have errored either way; a later edit can add the parameter in one line. It costs nothing, so keep the signature — but it is the sole justification for one removable test.

Cross-cutting

• Units belong in the MCP contract. This surface feeds an LLM that formats numbers for humans. Any money field should be named *_cents/*_usd rather than relying on a convention documented only in spend-tab.tsx. Fix query_developer_stats's cc_total_cost in the same pass so the two tools agree.
• Gate in SQL, not after the fetch. On the fail-closed path the entire result set is fetched and discarded; on the team-scoped path the row budget is spent on rows the caller will never see. Resolving visibility first fixes the critical finding and the wasted work together.
• The tests over-cover what mocks can see and under-cover what matters. db.execute is mocked, so the INNER JOIN developer_stats and LOWER() predicates — which exist to prevent a bug that already shipped once — are pinned by nothing, while several new tests re-assert branches already covered elsewhere in the same file. Reallocating effort from the latter to the former is a net gain in both directions.
• Prose duplication. Four comment blocks in queries.ts restate rationale owned by cost-visibility.ts and report/org.ts. Since the drop policy already changed once, every copy is a place that can silently keep describing the old behavior.

Assessment

Ready to merge? With fixes.

The visibility design is sound and correctly reuses stripModelCost's drop-wholesale semantics — the fail-closed work in particular is careful and verified. The blocker is that a pre-gating LIMIT interacts badly with row-dropping in three separate ways, all fixable locally in the two new functions. The cents-as-dollars exposure is a small change with a large blast radius on reported numbers.

One note on reachability: the critical finding needs a report where more than limit (developer × model) rows sort ahead of the caller's own. The seeded DB is 16 rows across 8 developers, so it won't reproduce locally — worth checking against a real report to calibrate urgency.

_{🤖 Four-reviewer pass via /sl-core-dev:review-loop (1 loop, 2 personas + minimalist gate) and claude-pr-review-local. Findings verified against the code, deduplicated, no fixes applied.}

[msogin]

🔴 critical

LIMIT is applied before gating, and stripModelCost deletes rows — three independent consequences.

Three reviewers reached this line from different angles; it's one root cause.

The PR description says this "mirrors queryDeveloperStats exactly; kept consistent rather than diverging." It doesn't, and that's the crux:

• stripDevCost (cost-visibility.ts:138) — devs.map(...), keeps every row, blanks fields. Row count survives gating, so LIMIT-before-gating costs nothing.
• stripModelCost (cost-visibility.ts:178) — if (canSeeCost(devLogin)) return models; return [], drops rows.

So here the row budget is spent in SQL on rows that are then deleted in JS. What follows:

1. Entitled rows are unreachable. Rows come back ORDER BY github_login ascending, capped at 100 by default. A non-admin whose login sorts after 100 rows' worth of other developers gets {models: [], count: 0} — including their own spend. cost-visibility.ts:116 (if (dev === requesterLogin) return true) makes "own cost is always visible" an explicit guarantee; this breaks it. The calling agent will report "no per-model usage is recorded."

2. count becomes an inference oracle. Varying limit and reading only count recovers the ordinal positions of hidden developers' rows. With ungated order alice×2, bob×1, carol×3, dave×1:

limit :  1 2 3 4 5 6 7
count :  1 2 2 2 2 2 3

Every non-incrementing step is an ordinal holding a hidden row → hidden rows at [3,4,5,6]. Since query_developer_stats already gives the full login list in sort order ungated, a gap between two visible logins is that developer's distinct-model count — precisely the signal this line's own comment at :305 says rows are dropped to conceal ("retaining 'which models' alone still discloses that a non-teammate uses Claude Code and roughly how expensively"). No dollar amount leaks, which is why this is an inference channel rather than direct disclosure.

3. Aggregates are silently partial. Truncation is alphabetical and can cut mid-developer, so summing a visible developer's per-model cost disagrees with their cc_total_cost, with nothing in the payload signalling it.

Fix — resolve visibility first and bound the SQL limit to MAX_ROWS, then gate and slice:

const vis = await resolveCostVisibility(r.id, requester);
// ...SQL with LIMIT bound to String(MAX_ROWS), not args.limit
const truncated = rows.length >= MAX_ROWS;
const visible = models.filter(m => vis.canSeeCost(m.github_login));
const limit = Number(clampLimit(args.limit, 100));
return { models: visible.slice(0, limit), count: Math.min(visible.length, limit), truncated };

Pushing the visible-login set into the WHERE clause is stronger still and makes count honest by construction. Note report/org.ts:302 reads this same table with no LIMIT at all for the UI panel, so an unbounded read is already the established pattern here.

Reachability: needs a report where more than limit (developer × model) rows sort ahead of the caller's own. The seeded DB is only 16 rows / 8 developers, so this won't reproduce locally — worth calibrating against a real report before deciding severity.

⚠️ mcp-cost-gating.test.ts:99's expect(mockExecute).toHaveBeenCalledTimes(2) currently pins the wasted query on the fail-closed path; an early return changes it to 1.

[msogin]

🟡 warning

Same pre-emptive LIMIT on the skills query, with no truncated signal.

No gating is involved here, so none of the visibility issues apply — but ORDER BY github_login … LIMIT 100 still returns an alphabetical prefix and the response has no way to say so. An admin asking "which skills does the org use most" gets a total computed over logins a–j only, reported as the whole org.

For the entity-listing siblings, truncation is meaningful (queryCommits is ORDER BY committed_at DESC → "the most recent N"). "All of a–j and none of k–z" is not a defensible sample of anything. getMetricTimeseries already returns a truncated flag for exactly this hazard, and queryUnmergedWork binds MAX_ROWS rather than 100.

Fix: bind MAX_ROWS in SQL, return truncated: rows.length >= MAX_ROWS, and apply the caller's limit in JS.

[msogin]

🟡 warning

cc_model_usage.cost holds cents; this emits it as an unqualified cost, so agents will report figures 100× too high.

Verified end to end:

• src/lib/db/mysql.ts:191 — cost DECIMAL(10,2)
• src/lib/cc-spend/apply-breakdowns.ts:167 inserts agg.costCents into that column
• Every existing consumer divides by 100: spend-tab.tsx:37, usage-card.tsx:30,74,76, profile-content.tsx:145,180,182, dev-table.tsx:265, team-table.tsx:158

The UI divides at render. An MCP client has nothing to tell it to, and tools.ts:115 says only "cost". Asked "how much did Alice spend on opus?", a model reads cost: 1250 and answers $1250.00 for $12.50.

The fixtures in this PR (cost: '12.50') read as dollars, which suggests the ambiguity is already biting.

Fix — make the unit explicit in the wire shape:

cost_cents: Number(row.cost) || 0,
// or: cost_usd: (Number(row.cost) || 0) / 100,

query_developer_stats has the same latent problem with cc_total_cost. Whichever way you go, change both together — two Claude-cost tools disagreeing on unit would be worse than both being in cents.

[msogin]

🟡 warning

resolveCostVisibility computes canSeeAnyCost and this discards it, so "you may see no costs" is indistinguishable from "this report has no model usage."

The wholesale row-drop deliberately makes a hidden developer indistinguishable from a developer with no usage — that part is right. But this also conflates a property of the requester with a property of the data, and the former discloses nothing.

resolveRequester returns githubLogin: null for an authenticated user with no user_mappings row, and CLAUDE.md documents that as a real population ("Jira Cloud instances with hidden email visibility will cause auto-discovery to fail silently"). That user gets {models: [], count: 0} and the agent states as fact that no usage is recorded. Same for a mapped user on no team.

The org REST route already handles this — it strips cc_period_start/cc_period_end/spendWindow when !canSeeAnyCost so the UI can say "you cannot see costs." The MCP tool says nothing.

Fix:

return { models: gated, count: gated.length, cost_visible: vis.canSeeAnyCost };

Then an agent seeing cost_visible: false with an empty list can say "you don't have visibility into Claude spend" instead of "there is none." Worth a line in the tool description too.

[msogin]

🟣 question

This comment — and the same claim in stripModelCost's doc — overclaims. Within one response it holds; across the MCP surface it doesn't.

The row-drop works, and with a login filter a hidden developer is byte-identical to a nonexistent one. But sibling tools in the same registry answer the question directly:

1. query_developer_stats key presence. stripCostFields (cost-visibility.ts:129) does delete copy[f], while developer_stats.cc_total_cost is NOT NULL DEFAULT 0 (sqlite.ts:34, mysql.ts:276). So a developer with genuinely no usage returns cc_total_cost: 0 — key present; a hidden developer returns no key at all. One call, no probing:

   alice  present=true  value=1000   (visible teammate)
   erin   present=true  value=0      (no usage)
   carol  present=false value=undef  (hidden)
   

2. The count/limit staircase in query_model_usage itself — see the comment on queries.ts:294.
3. query_skills_usage — a hidden developer with product: 'claude_code' and skills_used > 0 near-certainly has cc_model_usage rows. Probabilistic (different endpoint, SKILLS_LAG_DAYS-clamped window), but strong. Worth noting this PR makes per-developer Claude activity reachable via MCP for the first time — no existing MCP query exposes any cc_ activity column.

Route 1 is pre-existing in stripDevCost and out of scope to change here. What's new is the claim that the property holds, which future work may build on.

Two ways to resolve, and the code currently matches documented policy (CLAUDE.md and the CC_FIELDS comment both say skills are deliberately never gated), so this is a question, not a defect:

(a) Accept the residual and soften the wording — the property is "amounts and model mix are withheld," not "hiddenness is unobservable." That means this comment, lines 56–57, and the third paragraph of stripModelCost's doc comment. Cheap and consistent with existing policy.

(b) Make the property hold — needs stripCostFields to blank rather than delete, plus gating skills rows for cost-hidden developers. That contradicts CLAUDE.md and is well beyond this PR.

(a) looks right. Either way the count oracle should be fixed independently — it leaks per-developer model counts, which is a step past mere hiddenness.

[msogin]

🔵 suggestion

This comment and three others restate rationale that lives in cost-visibility.ts and report/org.ts — now two copies to keep in sync.

• :258 — "see the long comment above the equivalent queries in report/org.ts. In short: …" then recaps it for six lines. The pointer was the whole value.
• :270 — restates MODEL_COST_FIELDS' doc comment in substance verbatim.
• :305 (this one) — restates stripModelCost's doc comment, closing with "See its doc comment."
• :323 — "see the policy comment on CC_FIELDS in cost-visibility.ts" then repeats that comment.
• A third pass over the same reasoning at mcp-cost-gating.test.ts:55-57 and :128-129.

The implicit justification is that a reader of queries.ts shouldn't have to jump — i.e. for clarity. That's the trade that produces drift, and cost-visibility.ts is where the policy lives and already says all of this. Keep the one-line pointers, drop the recaps.

Sharper reason to care: the drop policy already changed once (the #64 review moved it from field-stripping to row-dropping). Every prose copy is a place that silently keeps describing the old behavior.

[msogin]

🔵 suggestion

"Shared by every MCP query that returns cost-bearing data" overclaims.

It has two callers (:253 and :309), and querySkillsUsage deliberately doesn't use it — so "every" is already false in this same file by design. As written it reads as an invariant a future edit should maintain, when the actual rule is narrower.

Lines :46-47 also pin the helper's doc to one test file's assertion style, which will age badly if that test is ever restructured.

The extraction itself is well justified — two real callers land in this PR and it's behavior-preserving against the inlined version. Only the doc needs scoping down.

[msogin]

🔵 suggestion

This group-by-login + stripModelCost dance is duplicated byte-for-byte at src/app/api/report/[id]/org/route.ts:19-27.

stripModelCost is a security control, so two copies means a future policy change has to be found twice — and this policy has already changed once (#64 moved it from field-stripping to row-dropping). Worth extracting alongside stripDevCost:

export function gateModelRowsByLogin<T extends ModelBearing & { github_login: string }>(
  rows: T[], canSeeCost: (login: string) => boolean,
) { /* group by login, flatMap stripModelCost */ }

To be explicit about one thing I checked and am not suggesting: replacing this with models.filter(m => vis.canSeeCost(m.github_login)) would be behaviorally identical today and six lines shorter, but routing through stripModelCost is what keeps a single implementation of the drop policy — a local filter is exactly what would have silently diverged when the policy changed. Keep the indirection; extract the wrapper.

[msogin]

🔵 suggestion

Two fixes to this description string.

1. State the unit. cc_model_usage.cost holds cents (see the note on queries.ts:301). Whatever you decide about the wire shape, this string is the cheapest place to say so.

2. "Claude Code cost" understates the feed. CLAUDE.md is explicit that user_cost_report is "a multi-surface feed (claude.ai + Claude Code + API), not Claude Code-only." As written, a model will attribute the whole figure to coding — and this is the only description it ever sees.

Suggested: "Per-developer Claude cost in USD cents (all surfaces: claude.ai + Claude Code + API) and requests broken down by model, for a report. …"

[msogin]

🔵 suggestion

Two fixes here as well.

1. product isn't Claude Code only. Values include chat and cowork — this PR's own fixture uses 'chat'. Calling it "Claude Code skills usage" while returning claude.ai rows will have a model misattribute them.

2. The window differs from the report period. Per CLAUDE.md, the skills pull's end date is clamped back by SKILLS_LAG_DAYS, so these counts cover a narrower window than the report's spend period. A caller comparing skills counts against report-period commits — an obvious thing for an agent to do — draws a wrong conclusion with nothing to warn it.

Suggested: "Per-developer Claude skills usage by product (claude_code, chat, …) — skills invoked and distinct skills, for a report. Activity volume only, no cost; visible for all developers. Covers a window ending a few days before the report period, due to the Analytics endpoint's data lag."

[msogin]

Review addressed — f533023

All 14 findings actioned. CI green: 104 suites / 939 tests. Thanks for this — the critical finding was right, and it was right specifically where I'd argued myself out of it.

🔴 The critical one: LIMIT before gating

Fixed, and the refutation was correct. I justified the pre-gating limit in the PR description by saying it "mirrors queryDeveloperStats exactly." It doesn't, and the asymmetry is the whole defect: stripDevCost does devs.map(...) and keeps every row, so a pre-gating limit costs it nothing; stripModelCost returns []. I reasoned from "same shape of code" instead of from what the two strip functions actually do.

Both queries now bind MAX_ROWS in SQL and apply the caller's limit in JS after gating, and return truncated. That closes all three consequences:

1. Entitled rows reachable — pinned by a test where three hidden carol rows sort ahead of the requester dave; under the old code limit: 2 returned nothing for him, breaking cost-visibility.ts:116's explicit own-cost guarantee.
2. count is no longer an oracle — it's now min(visible, limit), so sweeping limit yields a plain ramp that reveals only the visible count. Test sweeps limit 1→3 and asserts the staircase is gone.
3. Partial aggregates are signalled — truncated: rows.length >= MAX_ROWS.

I also took the "gate in SQL, not after the fetch" point: queryModelUsage resolves visibility first and returns early when !canSeeAnyCost, so that path now performs no table read at all. As you flagged, that changes the fail-closed toHaveBeenCalledTimes(2) → 1; the test asserts 1 now, with a comment saying why.

I did not push the visible-login set into the WHERE clause. It's stronger, and count would be honest by construction, but it needs the team map before the query and turns one predicate into a login list of unbounded size. Fetch-to-cap then gate gets the same observable behaviour; happy to revisit if you'd rather have it in SQL.

🟡 cost in cents

Fixed — cost_cents. Verified your chain independently (mysql.ts:191 → apply-breakdowns.ts:167 writes costCents → six UI consumers all divide by 100). You're also right that my own fixtures (cost: '12.50') read as dollars, which is exactly the ambiguity biting; they're cents now.

On query_developer_stats: I did not rename cc_total_cost. It's a shipped tool's response field and renaming breaks existing callers. Instead its description now states the unit explicitly. Both tools are in cents, so they don't disagree — one just says so in the field name and the other in prose. If you'd rather take the breaking rename, that's a one-liner, but it felt like the wrong call to make silently inside this PR.

🟡 Skills LIMIT / no truncated

Fixed the same way — MAX_ROWS bound in SQL, truncated returned, caller limit applied in JS.

🟡 canSeeAnyCost discarded

Fixed — returns cost_visible. Test covers the unmapped-requester case specifically, since CLAUDE.md documents that population as real.

🟣 "Hidden is indistinguishable from no usage" overclaims

Took option (a). Softened the test comments and rewrote the third paragraph of stripModelCost's doc to state the honest guarantee — "amounts and model mix are withheld", not "hiddenness is unobservable" — and to name the NOT NULL DEFAULT 0 key-presence route so the next reader doesn't rediscover it.

While in there I found the doc's summary line states its condition backwards: "Return this developer's per-model rows unless the requester may see their cost, in which case return none at all" is the inverse of if (canSeeCost) return models. Pre-existing, from #64. Fixed.

🟣 login case-sensitivity asymmetry

Deliberate here (it matches buildCostVisibility), but you're right that it was undiscoverable. Both new tools now say "(case-insensitive)" in the login description, and there's a test asserting the SQL folds both sides. Changing the siblings stays a separate PR.

🔵 SQL invariants unpinned

Fixed, and this was the most valuable of the suggestions — you're right that deleting the INNER JOIN or either LOWER() left the whole suite green. Added text-level assertions mirroring org-model-usage.test.ts, plus the login case-folding and the MAX_ROWS binding. I kept separate copies rather than extracting a shared builder: the two call sites now differ (mine take a login filter and a LIMIT), so a shared builder would need parameters that make it less legible than the assertion.

Beyond the mocks, I also ran both queries against a real SQLite database and confirmed the join actually excludes a login absent from developer_stats and that LOWER() matches carol against Carol.

🔵 Redundant tests

Removed all three — the requests-sum test, the typeof coercion test (the exact-value toEqual covers it), and the skills wiring test, which as you say defends a failure mode that can't exist for an ungated handler.

I kept the admin test (:101). Your reasoning held when it only exercised a resolveCostVisibility branch, but after this change it's also the positive control for the new gate-then-slice path and asserts truncated: false, so it's no longer a duplicate of queryDeveloperStats:47.

🔵 Duplicated group-by-login

Extracted gateModelRowsByLogin into cost-visibility.ts; both the MCP query and the org route call it. Kept the indirection through stripModelCost rather than the shorter filter, for the reason you gave — a local filter is precisely what would have silently kept working when the policy changed.

Worth noting the extraction caught something: report-cost-gating.test.ts and org-route-model-gating.test.ts mock @/lib/cost-visibility with an explicit allowlist, so the new export was undefined and both suites failed until I added it. A reminder that those allowlist mocks silently drop anything new.

🔵 Prose duplication

Trimmed the four recaps to pointers, and scoped resolveCostVisibility's doc to its actual two callers with the "every" claim removed and the test-file reference dropped.

🔵 Tool descriptions

Both rewritten: units stated, cost feed described as all Anthropic surfaces rather than Claude Code alone, skills product values listed including chat/cowork, and the SKILLS_LAG_DAYS window difference called out so an agent doesn't compare skills counts against report-period commits.

On reachability

You were right that the seeded DB can't reproduce the critical finding — 16 rows over 8 developers, well under any limit. The regression test constructs the ordering synthetically instead, so it doesn't depend on real data volume. Worth knowing the shipped dev DB has 70 developers in the latest report, so a real report plausibly exceeds a default limit of 100 (developer × model) rows once most developers have two models each.