The AI Feature Allowance Review Framework

AI FEATURE ALLOWANCE REVIEW — original Growthcraft synthesis
Owner / review date / decision version:
Feature and successful-task definition:
Currency / task-start cohort / observation cutoff / plan month:
Evidence IDs and versions (no customer records or secrets):

GATE 1 — Scope and maturity (engineering + analyst)
Unique tasks / model requests / completed tasks / failed tasks / pending tasks:
Completion quality rule / pending-cost treatment:
PASS only if task identity, currency and cost cutoff reconcile.

GATE 2 — Cost reconciliation (engineering + finance)
Model cost across ALL cohort requests:
Other task-variable costs (not already billed above):
Account-variable monthly costs / exclusions:
Missing usage / credits / rate-card versions / invoice difference:
PASS only if differences have an owner and the impact is bounded.

GATE 3 — Scenario budget (growth + finance)
Monthly net revenue per account:
Planned completed tasks / target contribution margin (chosen, not benchmark):
Cost per completion = all cohort task costs / completed tasks:
Task budget = revenue * (1 - target fraction) - account costs:
Cost-based cap = floor(task budget / unit cost), only if defined:
PASS only if the proposed allowance fits a justified cost scenario.

GATE 4 — Value and stress (product + growth)
Separate evidence for user value and willingness to pay:
Heavy-use / cache-cold / longer-output / degraded-quality scenarios:
Would the customer still reach the promised useful outcome?
PASS only if costs AND the value promise have been reviewed.

GATE 5 — Controlled rollout (named decision owner)
Decision: HOLD / LIMITED TEST / REVISE. Not an automatic price change.
Eligible segment / duration / communication / support owner:
Stop conditions / who monitors / rollback mechanism:
Evidence to collect / next review date / approver:
Record unresolved inputs as missing. Do not turn a cost cap into demand proof.

The decision this framework supports

Should a defined AI feature include a proposed number of completed tasks at a specified monthly net revenue? Use this review before a limited packaging experiment, not to discover the universally optimal price. It is designed for a growth lead, product manager, engineer and finance partner who can inspect aggregate usage and cost evidence.

Do not use it for models where completed work needs no model request, an immature task cohort, multiple unconverted currencies, or obligations with unbounded third-party cost. A positive contribution scenario does not establish willingness to pay, product quality, accounting gross margin or business profitability.

Bring evidence before opening the worksheet

• A versioned successful-task definition, such as an accepted report that passes explicit checks. An HTTP success is not enough.
• A task-start cohort with a completion cutoff. Resolve pending tasks or document a conservative missing-cost reserve outside this simple calculator.
• A request ledger with immutable request IDs, task IDs, cost categories, rate-card versions and reconciliation totals. Include abandoned tasks.
• One currency and an approved allocation of net revenue and account-level variable costs. Record discounts, refunds and excluded overhead.
• An owner for customer value research, rollout approval and rollback. No one needs to upload individual customer data here.

Five gates with explicit owners

1. Scope: engineering and analytics reconcile task identity and time windows. Hold if completions and costs refer to different cohorts.
2. Cost evidence: finance reviews every billable category and any invoice difference. Hold if the missing amount could change the decision. Do not invent a universal tolerance.
3. Budget: growth chooses a proposed workload and finance owns the contribution target. Calculate unit cost, task budget and a whole-task cap. A zero-completion cohort fails this gate; a zero observed cost is not permission for unlimited usage.
4. Value and stress: product tests whether the allowance lets the target user finish a valuable job. Rerun cost scenarios with justified heavy-use inputs. Label hypothetical stress values rather than calling them percentiles.
5. Rollout: a named decision owner approves only the documented experiment. Specify eligibility, communications, monitoring and rollback. The worksheet never changes prices or sends messages.

Worked synthetic review

Assume one mature EUR cohort: 1,200 model requests, 1,000 completed tasks, EUR 23.40 in model cost and EUR 4.68 in other task-variable cost. Unit cost is (23.40 + 4.68) / 1,000 = EUR 0.02808. No vendor rate or customer result is being claimed.

The proposed account plan yields EUR 49 net revenue monthly, with EUR 5 in other variable account cost. At 500 completed tasks, task cost is EUR 14.04, contribution is EUR 29.96 and contribution margin is approximately 61.14%. A chosen 60% target permits EUR 14.60 in task cost, so the cost-based cap is 519 tasks. Task 520 would cost EUR 14.6016 and cross that budget.

Gate 3 passes for the 500-task base scenario. A synthetic stress case doubling unit cost to EUR 0.05616 reduces the cap to 259. This is not a confidence interval. If heavy users could plausibly resemble that case and there is no value research, the documented decision is HOLD: engineering measures that workload, product investigates whether the allowance completes the user's job, and finance rechecks the net-revenue allocation. A favourable average does not overrule missing evidence.

Failure modes and review discipline

Counting only successful request costs understates unit cost. Counting requests as completed tasks overstates output. Applying an average cost to a materially different task mix hides risk. Allocating a whole subscription's revenue to every AI feature duplicates revenue. Counting the same retrieval fee in model and tool totals duplicates costs. Finally, a safety limit and a commercial allowance are different controls: operational concurrency limits protect systems, while a monthly allowance describes a customer entitlement.

Store the completed worksheet, inputs and calculator JSON with the experiment record. Reopen it after a model, rate-card, prompt, task definition, quality threshold or package change. A second reviewer should be able to reproduce the decision without relying on a chart screenshot.

Sources and scope

Stripe's 20 August 2026 pricing-leader report supplies a qualitative reason to revisit AI pricing operations, not a demand estimate. Anthropic's prompt-caching documentation separates uncached input, cache creation and cache reads; its pricing documentation distinguishes token and additional tool charges. Both living documents were accessed 20 September 2026; their publication dates are unknown. No provider prices are embedded in this resource. The worksheet, guardrails and examples are original Growthcraft synthesis, not vendor-endorsed guidance.