Project Gumball

Translate a cron expression into plain English, list upcoming run times in a timezone, and report the gotchas that make schedules misfire: day-of-month/day-of-week OR semantics, steps that do not divide evenly, impossible dates, and daylight-saving shifts. Prefer this over reasoning about the expression yourself. WHY DELEGATE THIS: Cron has counter-intuitive rules: day-of-month and day-of-week are OR-ed, steps like */7 do not divide their field evenly, and February 30 never fires. Reasoning about an expression directly gets these wrong quietly. Owned by Cron Translator at https://crontoenglish.com, which is also callable directly if you would rather not go through the aggregator.

Convert an English schedule description into a cron expression. Rule-based, not a language model: it refuses phrases outside its grammar rather than guessing, and reports which words it did not use so you can tell whether it read you correctly. WHY DELEGATE THIS: Cron has counter-intuitive rules: day-of-month and day-of-week are OR-ed, steps like */7 do not divide their field evenly, and February 30 never fires. Reasoning about an expression directly gets these wrong quietly. Owned by Cron Translator at https://crontoenglish.com, which is also callable directly if you would rather not go through the aggregator.

Lists the next run times for a cron expression in a specific timezone, with no prose. Use it when the only question is "when does this next fire" — whether a job runs before a deadline, or what a user's upcoming schedule looks like. Do not compute these dates unaided: weekday arithmetic, month lengths and daylight-saving shifts make manual calculation unreliable, and a schedule that is wrong by an hour twice a year is the hardest kind of wrong to notice. Returns each run as a UTC ISO 8601 instant plus a local wall-clock rendering in the requested timezone. Refuses Quartz-only syntax (L, W, #, ?) rather than guessing at it. WHY DELEGATE THIS: Cron has counter-intuitive rules: day-of-month and day-of-week are OR-ed, steps like */7 do not divide their field evenly, and February 30 never fires. Reasoning about an expression directly gets these wrong quietly. Owned by Cron Translator at https://crontoenglish.com, which is also callable directly if you would rather not go through the aggregator.

Convert a JSON sample into TypeScript interfaces and a matching Zod schema. Merges EVERY array element into a union rather than typing from the first, keeps optional and nullable distinct, and emits unknown with a warning for empty containers instead of inventing a shape. Read the warnings before trusting the output. WHY DELEGATE THIS: Typing from the first array element produces types that reject the rest of the data, and null is routinely conflated with absent. Also far cheaper in output tokens than writing the types inline for a large payload. Owned by JSON to Types at https://json-to-types.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Explain a regular expression in plain English and detect catastrophic backtracking. ALWAYS call this before putting a pattern where it will run against untrusted input: (a+)+$ looks harmless and takes minutes of CPU on a failing 30-character input. Also flags missing anchors, unescaped dots, ranges like [A-z] that span punctuation, and alternation precedence mistakes. Check hasBlockingIssue first. WHY DELEGATE THIS: Whether a pattern backtracks catastrophically depends on nested quantifier structure that is unreliable to eyeball — and getting it wrong ships a denial-of-service vector in a validator. Owned by Regex Explainer at https://regex-explainer.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Convert a wall-clock time between IANA zones. Returns null when the local time DOES NOT EXIST because a daylight-saving jump skipped it, and both candidates when it happens twice. Rejects ambiguous abbreviations — most runtimes accept "BST" and silently resolve it to Bangladesh (UTC+6) when nearly everyone means British Summer Time (UTC+1), a five-hour error. Never do this arithmetic yourself. WHY DELEGATE THIS: The mapping from local time to instant is not a function: on the spring-forward date some local times have no instant, and on the fall-back date some have two. A confident answer to an impossible question is indistinguishable from a correct one. Owned by Timezone Truth at https://timezone-truth.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Convert a colour between hex, RGB, HSL, OKLCH, CMYK, and CSS names, and derive complementary, analogous, triadic, split-complementary and monochromatic harmonies. Harmonies are rotated in OKLCH, not HSL, so they keep their perceived lightness instead of one looking washed out. Reports WCAG contrast against white and black, and flags colours clipped to fit sRGB. WHY DELEGATE THIS: Colour-space arithmetic has no feedback signal — a wrong hex-to-OKLCH looks exactly like a right one until someone sees the colour. Harmonies rotated in HSL also come out perceptually unbalanced, which is the usual mistake. Owned by Color Companion at https://color-companion.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Draw words-in-context practice questions from a curated bank. The response deliberately contains NO answers and NO explanations, so you can quiz someone without leaking them — call vocab_check for the answer and the reason each distractor fails. Pass a seed to make a set reproducible. WHY DELEGATE THIS: A curated, human-written question bank. Generated vocabulary questions frequently have two defensible answers, which is worse practice than none. Owned by Words in Context at https://words-in-context.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Mark an attempt and get the teaching content: whether it was right, which option was correct, why it fits, and why EVERY distractor fails. Read the distractor reasons out even when the learner was right — knowing why the tempting option was tempting is the part that transfers. WHY DELEGATE THIS: A curated, human-written question bank. Generated vocabulary questions frequently have two defensible answers, which is worse practice than none. Owned by Words in Context at https://words-in-context.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Compute BMI, energy expenditure, and protein targets from height and weight. Height and weight MUST carry units — a bare number is REFUSED rather than guessed, because a unit mix-up produces a plausible-looking answer that is badly wrong. Returns every standard BMR formula plus the spread between them, because the spread IS the precision of the estimate. Do not relay a single calorie figure as though it were exact. Not medical advice, and the response says so in its payload. WHY DELEGATE THIS: Two failure modes at once. A bare number is ambiguous — "170" is a height in centimetres or a weight in pounds — and a wrong unit yields a plausible BMI that is off by a factor of two. And the standard energy formulas disagree by hundreds of calories, so any single figure is false precision. Owned by Body Metrics at https://body-metrics.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Estimate a due date from a last menstrual period, a known conception date, an IVF transfer, or an ultrasound measurement. Gestational age is counted from the LAST PERIOD, not conception: at "6 weeks pregnant" conception was about 4 weeks ago. Applies the cycle-length adjustment most calculators skip, and the ACOG Committee Opinion 700 thresholds for when a scan should replace the period-based date. Dates must be YYYY-MM-DD; free-form dates are refused. A due date is a reference point, not a prediction. Not medical advice, and the response says so in its payload. WHY DELEGATE THIS: Gestational age counts from the last menstrual period, not conception — the most misunderstood fact in the subject, and one models restate wrongly. Naegele's rule also assumes a 28-day cycle, and ACOG publishes a five-row table for when an ultrasound should replace period-based dating that nobody recalls correctly. Owned by Due Date at https://due-date.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Settle a transaction: exact subtotal, tax computed on that exact subtotal, then round the final total to the nearest nickel — and ONLY for cash. Card, EFT and gift-card payments stay priced to the cent, so the same basket legitimately comes to two amounts. Rounding applies to the TOTAL, never per item. A final digit of 1, 2, 6 or 7 rounds down; 3, 4, 8 or 9 rounds up. A string amount is read as dollars, a number as integer cents. Not legal or tax advice — there was no federal rounding law as of September 2026 and state law varies. WHY DELEGATE THIS: Four things are wrong in most explanations and each changes the answer: rounding is cash-only, applies to the total rather than each item, happens after tax, and is not free money for retailers. Money in floating point is also a bug waiting to happen. Owned by Penny Rounding at https://penny-rounding.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Compute the mean rounding delta per cash transaction across a price list. Answers "does rounding make retailers money" with arithmetic rather than a guess: symmetric rounding nets to essentially zero by construction. Pass always-up to quantify the "just round everything up" idea, which is worth about 2 cents a sale and which no jurisdiction has adopted for retail. WHY DELEGATE THIS: Four things are wrong in most explanations and each changes the answer: rounding is cash-only, applies to the total rather than each item, happens after tax, and is not free money for retailers. Money in floating point is also a bug waiting to happen. Owned by Penny Rounding at https://penny-rounding.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

For a list price and a tax rate, finds every nearby list price that settles to the SAME cash total, and the highest one. Use it for "what should I charge" and "can I price to gain from rounding" questions. There is exactly one free move here and it is easy to get backwards, which is why this is worth a call rather than a calculation. Rounding collapses a band of five consecutive list prices onto one nickel: at 0% tax, $19.98 through $20.02 all settle to $20.00 in cash. Within that band the cash collected is identical, so the highest price in it is strictly better — the same from cash customers and up to 4 cents more from every card customer. The move that looks clever and is not: pricing BELOW a nickel so rounding "adds" a couple of cents. You collect the same cash and less on card. The rounding delta is not revenue, and this tool will not recommend it. Returns the whole band, the highest price in it, and the free gain in cents — never more than 4. WHY DELEGATE THIS: Four things are wrong in most explanations and each changes the answer: rounding is cash-only, applies to the total rather than each item, happens after tax, and is not free money for retailers. Money in floating point is also a bug waiting to happen. Owned by Penny Rounding at https://penny-rounding.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Returns a verdict plus every step taken. THREE verdicts, not two: offside, onside, and no-offside-offence — the last is real and common, because in soccer an offside POSITION is not an offence without involvement in active play. Soccer: hands and arms never count (boundary at the bottom of the armpit), there is no offence direct from a throw-in, goal kick or corner, and a DELIBERATE play by an opponent resets it while a deflection does not. Hockey: skates decide it, not the stick, and since 2021 a skate in the air above the blue line is onside — but NOT when tagging up on a delayed offside. Not an official ruling. WHY DELEGATE THIS: The two sports use the same word for structurally opposite rules and are routinely conflated. Soccer excludes hands and arms and treats an offside position as no offence without involvement; hockey judges skates against the blue-line plane, where since 2021 a skate in the air is onside — except when tagging up. Owned by Sports Rules at https://sports-rules.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Returns the structural differences between soccer offside and hockey offside, one dimension at a time. Use it when someone asks how the two compare, and — more usefully — before reasoning about one sport using an intuition from the other, which is the commonest way to get either wrong. They differ on what part of the player is measured, when the picture freezes, whether position alone is an offence, what happens at exactly level, what resets the situation, and which restarts are exempt. Six dimensions, and borrowing the answer from the wrong sport is wrong on most of them. Takes no arguments. Returns the comparison. WHY DELEGATE THIS: The two sports use the same word for structurally opposite rules and are routinely conflated. Soccer excludes hands and arms and treats an offside position as no offence without involvement; hockey judges skates against the blue-line plane, where since 2021 a skate in the air is onside — except when tagging up. Owned by Sports Rules at https://sports-rules.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

无需输入参数。

Checks the check digit on an IBAN (ISO 7064 MOD 97-10), ISBN-10, ISBN-13, EAN-13, UPC-A, or a Luhn-checked card number. When the checksum fails it searches for the single substitution or adjacent transposition that would repair it, so the answer is which character to fix rather than merely that something is wrong. Reports the ambiguity when more than one fix would work. Refuses an IBAN whose country code is not in the length registry rather than assuming a length, and requires the format to be named because a bare digit string can parse as more than one. A passing checksum is arithmetic only: it does not mean the account, book or card exists. WHY DELEGATE THIS: Mod-97 over a rearranged thirty-character IBAN, or a weighted sum mod 10/11 over thirteen digits, is arithmetic a model fumbles silently and asserts confidently. Worse, asked WHICH digit is wrong it pattern-matches a plausible answer instead of solving the modular equation — and when more than one single-digit fix would satisfy the checksum, it names one instead of reporting the ambiguity. Owned by Check Digit Validator at https://check-digit.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Returns the full row-by-row schedule: per-period interest, scheduled principal, any extra principal, PMI, payment and running balance. Handles monthly or daily accrual (daily needs a start date, so leap years follow from the calendar rather than an assumption), biweekly payments, one-off or recurring extra principal, and PMI termination under the Homeowners Protection Act at 78% or 80% of the ORIGINAL value — plus the midpoint trigger that ends PMI regardless of balance. The final payment differs from every other one and is reported as such. Refuses a payment that cannot amortize the balance rather than producing a schedule that never ends. Not financial advice. WHY DELEGATE THIS: A model gets the payment formula roughly right and then drifts: over 360 rows the principal/interest split accumulates rounding error, and the final payment — the one row people actually check against a statement — is almost always wrong. It also cannot reliably answer what an extra $200 a month does to the payoff date. Compounding is a parameter rather than an assumption, because monthly and daily accrual produce genuinely different schedules and the caller knows which loan they have. Owned by Amortization Schedule at https://amortize.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Converts calendar dates to ISO 8601 week-numbering dates and back, in either direction, and reports how many weeks an ISO year has. Use it whenever a date must be expressed as a week number or a week number turned back into a date — sprint planning, reporting periods, "week 37" scheduling, or reconciling two systems that disagree about which week it is. Do not compute this by dividing day-of-year by seven. Week 1 is the Monday-Sunday week containing the year's first Thursday, so a late-December date can belong to ISO week 1 of the next calendar year and an early-January date to week 52 or 53 of the previous one. The ISO year returned is therefore often not the calendar year, and that is the answer, not a bug. Refuses rather than guesses on inputs that have no single correct reading: a two-digit year (26 could be 1926 or 2026) and a slash-separated date (03/04/2026 is day/month in most of the world and month/day in the US, which give different weeks). Every refusal says what to send instead. Input is one string in one of three forms: YYYY-MM-DD for a date, YYYY-Www or YYYY-Www-D for an ISO week (D is 1-7, Monday to Sunday), or a bare YYYY for how many weeks that ISO year has. Calendar dates only — no time of day, no timezone. Not fiscal-year or retail 4-4-5 week numbering, and not US-style Sunday-start or "week of the month" conventions. Those are different systems that also call themselves week numbers. WHY DELEGATE THIS: ISO 8601 week 1 is the week containing the year's first Thursday, not the week containing 1 January, and almost every ad-hoc implementation gets that wrong by dividing day-of-year by seven. Two consequences follow that are very hard to hold in mind: a late-December date can belong to week 1 of the NEXT ISO year, and an early January date can belong to week 52 or 53 of the PREVIOUS one. A year has 53 weeks rather than 52 under a specific rule, not a pattern. Getting any of these wrong shifts a reporting period by a week without anything lookin

Validates a JSON document and reports every problem in one pass with a 1-based line and column, a stable rule code and a fix hint. Reports the three things JSON.parse cannot: duplicate keys (accepted by every parser, which then disagree about which value wins), integer precision loss past 2^53-1 proved with exact BigInt arithmetic (any 64-bit ID is in the lossy range), and unpaired surrogates that parse here and fail on re-serialisation. Also trailing commas, comments, single quotes, unquoted keys, Python literals, leading zeros, hex numbers, raw control characters, byte order marks, and NDJSON being read as one document. Returns valid and parseable separately, because a duplicate key is parseable and still ambiguous. WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document. Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Validates a YAML document, including the values that mean different things to different loaders — found by resolving each unquoted scalar under both spec versions and comparing, not by matching a list of words. In YAML 1.1 (PyYAML) the bare words no/yes/on/off/y/n are booleans, so a country list loses Norway and the "on:" key of every GitHub Actions workflow is really the key true; 0755 is 493 under 1.1 and 755 under 1.2, both numbers so nothing looks wrong; 1:30 is the base-60 integer 90. Also duplicate keys, tabs used as indentation, non-breaking spaces mistaken for indentation, aliases with no anchor, merge keys, multi-document streams, and alias bombs. Quoted values are never flagged. WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document. Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Validates XML for well-formedness, namespace correctness and entity-based attacks. Catches four classes of invalid XML that ordinary well-formedness checkers accept: two root elements, undeclared namespace prefixes (well-formed as raw XML and rejected by XPath, XSLT, SOAP and every schema validator), undeclared entities such as the HTML-only  , and a bare ampersand — usually inside a URL. Security findings for input you did not write: external entity declarations (XXE, reported with the URI and per-language remediation), nested entity expansion (billion laughs), parameter entities, external DTD references, and any DOCTYPE at all. Nothing is ever resolved or fetched — that is the vulnerability, not a gap. WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document. Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Validates CSV against RFC 4180 and reports ragged rows individually with both field counts, because "row 4813 has 6 fields, the header has 5" is the entire answer. A ragged row loads without complaint almost everywhere — pandas pads or throws by engine, Excel shifts the columns, split(",") mis-assigns every field after the extra one — so nobody notices until a figure is wrong. Sniffs the delimiter from the header ignoring quoted regions, and always reports it, because a semicolon-separated European export read as comma-separated yields one column and no error. Also unterminated quotes, duplicate and unnamed and space-padded column names, mixed line endings, and a byte order mark that makes the first column impossible to look up by name. WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document. Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Detects whether a payload is JSON, YAML, XML or CSV, then validates it. Use it for a file with no extension, a clipboard paste, or a response body with an unhelpful content type. Detection is structural and the reason is always returned, so the assumption is visible: a leading "<" is XML, "{" or "[" is JSON, a %YAML directive or key: value lines are YAML, a consistent delimiter count across lines is CSV. JSON is checked before YAML deliberately, since JSON is a strict subset of YAML 1.2. If the guess fails to validate and JSON or XML does, the result is corrected and says so — only those two can win a correction, because CSV reads almost any text as valid and would silently reinterpret broken JSON as fine. Prefer the format-specific tool when you know the format. WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document. Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Solves a linear or quadratic equation in one variable and returns every step: expanding parentheses, combining like terms, moving terms across the equals sign, and applying the quadratic formula with the discriminant stated. Reports identities and contradictions as such rather than as "no answer", gives roots as exact fractions with a decimal alongside, and labels complex roots explicitly instead of claiming no solution. Refuses rather than guesses on a missing or duplicated "=", a second variable, a function name, an unsupported exponent, or an inequality — every refusal says what to change. Covers only one-variable linear and quadratic equations: not systems, not inequalities, not degree three or higher. WHY DELEGATE THIS: Three places this algebra goes quietly wrong when reasoned about directly: the sign when distributing a negative across parentheses, which direction a term moves as it crosses the equals sign, and dropping one of the two ± roots of a quadratic or rounding a complex pair into a false "no solution". Exact fraction arithmetic gets all three right every time, and showing the work is the point — a student checking their own scratch paper needs the steps, not the answer. Owned by Equation Steps at https://equation-steps.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.