feat(submit): remove all per-day token/cost size caps - #691
Merged
Conversation
Legitimate power users with deep cache reuse routinely report >10B tokens or >$10k cost per day from a single client (notably Codex). The size caps were rejecting these submissions outright, blocking real usage. Closes #684. Removed: - MAX_DAILY_TOKENS (10B per day) — daily, summary, and per-client checks - MAX_DAILY_COST ($10k per day) — daily, summary, per-client, and maxCostInSingleDay checks - MAX_COST_PER_MILLION_TOKENS ($10k/M) — summary, day, and per-client cost-per-million sanity caps - WARN_DAILY_TOKENS soft-warn band (5B) and its console.warn Kept (these are arithmetic consistency, not size limits): - Day token breakdown sums to day total (TOKEN_RELATIVE_TOLERANCE) - Client tokens/cost sum to day totals - Tokenless-cost detection (cost > 0 with tokens === 0) — still rejects the data-corruption case where someone submits a cost figure without any token data - Cursor legacy carve-out Tests: - 'accepts internally consistent high-volume one-day token totals' kept (now just a smoke test, the cap-boundary comment removed) - 'accepts trillion-token internally consistent payloads (no size cap)' new — confirms a 1T-token submit now validates - 'rejects one-day fabricated token totals above the submission cap' removed (no cap left to enforce) - 'rejects submitted cost that is implausible for the reported tokens' removed (no cost-per-million sanity cap) - 'rejects submitted cost without corresponding tokens' kept (tokenless- cost remains) Confidence: high Scope-risk: moderate Rejected: keep MAX_DAILY_COST at $10k | the user community explicitly hit this wall with legitimate Codex usage (see #684 thread) Directive: If we re-introduce any size cap in the future, gate it on an env var so we can roll it back per-deploy without a code change Not-tested: real Codex submission >10B tokens in production
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Keep cost validation within persisted decimal range
After this daily cost cap is removed, a day with cost >= 1000000 still passes validation as long as it has tokens, but /api/submit later writes each day as dayTotals.cost.toFixed(4) into daily_breakdown.cost, which is declared as decimal("cost", { precision: 10, scale: 4 }) in packages/frontend/src/lib/db/schema.ts and cannot store seven digits before the decimal. In that high-cost-day scenario, validation returns success and the request fails during insert/update with a database numeric overflow instead of a controlled 400 or a migrated wider column.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
4 tasks
junhoyeo
added a commit
that referenced
this pull request
Jun 8, 2026
…rflow (#692) fix(db): widen total_cost and daily cost columns submissions.total_cost was decimal(12, 4) — max ~$100M lifetime. daily_breakdown.cost was decimal(10, 4) — max ~$1M per day. #691 removed the application-layer cost cap ($10k/day), so a single day above ~$1M now overflows the column and Postgres raises numeric_value_out_of_range, rolling back the entire submit transaction with no user-friendly error. Widened: - submissions.total_cost decimal(12, 4) -> decimal(18, 4) (~$100T) - daily_breakdown.cost decimal(10, 4) -> decimal(14, 4) (~$10M / day) These ceilings are far above any plausible single-user usage for the lifetime of this product. ALTER COLUMN TYPE rewrites the table; at this dataset size (~1k submissions, ~100k daily_breakdown rows) the rewrite is sub-second. Migration 0014_widen_cost_columns.sql was hand-written because drizzle-kit generate runs interactively against the existing diff and cannot complete in CI/non-TTY contexts. The corresponding _journal.json entry uses Date.now() = 1780915651573 (UTC 2026-06-08) so the monotonic ordering invariant holds (later than 0013's 1780172800000). This is the second hand-rolled timestamp; the prior one (0010/0011) was the one that caused the 2026-06-08 incident, so flagging the precedent explicitly. Confidence: high Scope-risk: moderate Constraint: Migration must be applied with manual db:migrate against prod after merge (Vercel does not auto-migrate) Rejected: Add app-level overflow validation matching the column ceilings | re-introduces the 'reject legitimate submissions' problem #691 was specifically meant to remove Rejected: drizzle-kit generate to avoid the hand-roll | interactive prompt about provider_breakdown/model_breakdown column renames blocks non-TTY generation Directive: Next time a migration is needed, prefer drizzle-kit generate over hand-rolled SQL; only fall back to hand-rolled if the generator gets confused by historic renames as it did here Not-tested: Postgres-side numeric_value_out_of_range under real submit traffic above the old ceilings
This was referenced Jun 8, 2026
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #684
@xsyetopz, @ramarivera, and @handsupmin all hit the daily-token / daily-cost / cost-per-million sanity caps with legitimate Codex usage (the kind of cache-heavy submission patterns that trip 10B tokens or $10k/day without anything being wrong). The fix per @junhoyeo's reply on the issue is to remove the restrictions.
What this drops
All four size constants and the checks that reference them:
MAX_DAILY_TOKENSMAX_DAILY_COSTmaxCostInSingleDayMAX_COST_PER_MILLION_TOKENSWARN_DAILY_TOKENSconsole.warnbandWhat stays
These are arithmetic consistency, not size limits — they catch corrupted/inconsistent submissions, not large ones:
TOKEN_RELATIVE_TOLERANCE)COST_RELATIVE_TOLERANCE,COST_ABSOLUTE_TOLERANCE)cost > 0withtokens === 0) — still rejects the data-corruption case where someone submits a cost figure without any token dataTest diff
accepts internally consistent high-volume one-day token totals(kept, cap-boundary comment removed)accepts trillion-token internally consistent payloads (no size cap)(new — confirms a 1T-token submit validates)rejects one-day fabricated token totals above the submission cap(deleted — no cap to enforce)rejects submitted cost that is implausible for the reported tokens(deleted — no cost-per-million sanity cap)rejects submitted cost without corresponding tokens(kept — tokenless-cost branch is still gated)bunx tsc --noEmitexit 0. Fullsubmittest suite passes locally.Test plan
bunx tokscale submitagainst the new deploy/api/submitserver logs for unexpected payload shapes now that the upper bound is gone (the arithmetic-consistency checks should still catch anything corrupted)Summary by cubic
Removes all per-day token and cost caps in submission validation to unblock legitimate high-volume usage (e.g., Codex with deep cache). Addresses #684 while keeping arithmetic consistency and tokenless-cost checks.
MAX_DAILY_TOKENS,MAX_DAILY_COST,MAX_COST_PER_MILLION_TOKENS, andWARN_DAILY_TOKENSwith their checks.Written for commit b687d13. Summary will update on new commits.