Unit 02.02: Costing a feature before you build it

Do the cost arithmetic before building, not after the first invoice.

Per call, per day, per year - and the retry multiplier

A realistic feature costed at published rates, with two multipliers.

The code computes them.

FEATURE = {"requests_per_day": 400, "input_tokens": 900, "output_tokens": 220}
RATES = {"input_per_1k": 0.0003, "output_per_1k": 0.0015}

per_call = (FEATURE["input_tokens"] / 1000 * RATES["input_per_1k"] +
            FEATURE["output_tokens"] / 1000 * RATES["output_per_1k"])
daily = per_call * FEATURE["requests_per_day"]

print(f"per call    : ${per_call:.5f}")
print(f"per day     : ${daily:.2f}")
print(f"per month   : ${daily * 30:.2f}")
print(f"per year    : ${daily * 365:.2f}")

for label, multiplier in [("10x traffic", 10), ("a retry on 20% of calls", 1.2)]:
    print(f"{label:26} ${daily * 30 * multiplier:.2f}/month")

# Do this arithmetic before building, not after the first invoice. The retry
# row is the one that surprises people: a 20% retry rate is a 20% cost
# increase that appears as a quality problem on the bill.

The retry row is the one that surprises. A 20% retry rate is a 20% cost increase, and it arrives on the invoice looking like traffic growth rather than the validation-failure rate it actually is.

The 10x row is worth computing even when growth seems unlikely - it tells you whether the feature has a ceiling you would hit before the engineering does.

The mistake this prevents

The mistake is budgeting from the per-token price alone. It excludes retries, excludes the infrastructure around the call, and excludes the log and trace storage the calls generate - all of which scale with the same traffic.

Takeaway

Cost the feature at realistic volume before building, and include a retry multiplier. Cost per successful answer is the honest figure.

Mark complete