Scale recipe from ingredient on hand

This leftover recipe scaler takes every numeric amount on your ingredient list, picks one limiting line (by index or by name), and multiplies the entire list by on_hand divided by that line’s recipe amount. Non-positive amounts and a non-positive on-hand stock are rejected with invalid_input instead of inventing a zeroed dish.

What leftover scaling means and how the factor is built

The solver computes a single shared factor equal to on_hand divided by the recipe amount on the limiting line, then multiplies every amount by that factor so relative ratios stay constant. Units are intentional not converted here—put grams or cups in both the recipe amount and on_hand so the ratio is dimensionless—and sibling cook converters can normalize cups to grams before you scale. Classroom worksheets and coding kata can assert the same rounded JSON because the arithmetic never depends on the clock or on external data.

How to call the API: fields, response shape, and errors

Prefer numbers rather than unit strings inside amounts; put units in the names field so two hundred fifty and flour (g) stay separate and readable in the ingredients array. Send a JSON body with amounts as a required array of finite positive numbers—or a comma-separated string on text forms—plus on_hand as the positive quantity of the limiting ingredient you actually have. Choose the limiting line with limiting_index (zero-based, default zero when omitted) or limiting_name matched case-insensitively against the optional names list; when both are set, the name match wins so scripts can identify flour without hard-coding positions. Names (aliases labels, ingredients) are optional parallel labels padded or truncated to the amount count. Absolute values stay within the published limit of one trillion, and the list length is capped so a Worker finishes quickly. On success the response echoes rounded amounts, scaled, factor, on_hand, limiting_index, limiting_name, recipe_amount on that line, count, names, ingredients rows with an is_limiting flag, formula, message, and ordered steps. Failed validation—empty amounts, non-finite numbers, any non-positive recipe amount, non-positive on_hand, an out-of-range index, or a limiting_name that does not match—returns invalid_input and is never charged. Pricing is a flat $0.002 per successful request with unit item.

Practical tips, related searches, and when to use another tool

Near-zero and negative values are rejected on purpose because a non-positive stock or recipe line cannot define a useful scale. This landing targets people searching for scale recipe by ingredient on hand, leftover limiting ingredient calculator, or recipe scale from pantry stock; it is not a unit converter, not a nutrition estimator, and not the servings-or-multiplier recipe scaler used when you already know the guest count. Prefer the sibling recipe scaler when you want factor two for a double batch, and prefer cups-to-grams tools when the card and the bag use different measures. Always keep on_hand and the limiting recipe amount in the same unit before you submit; mixing cups of flour with grams of stock produces a mathematically valid but kitchen-wrong factor. Prefer limiting_name when your list is stable and limiting_index when you build amounts programmatically without labels. If several ingredients are short, pick the true bottleneck—the line with the smallest on_hand over recipe ratio—or run the calculator once per candidate and take the minimum scaled batch. Failed tasks that return invalid_input do not consume prepaid balance, which keeps exploratory scripts cheap when learners deliberately send zero stock. Round-trip checks are easy: recompute on_hand divided by the limiting recipe amount by hand, multiply each line, and confirm the published scaled entries match within twelve-decimal rounding, including that the limiting line’s scaled value equals on_hand after rounding.