| name | answer_pricing |
| description | Projects a customer's cost from prior usage data across seat-based, usage-based, and hybrid SaaS pricing models. Use when asked to "project cost", "estimate BYO cost", "estimate spend", "how much will this cost", "size a deal", or to build an enterprise-style usage/cost projection. |
Answer Pricing Skill
Setup required: Before using this skill, update knowledge/platform_credits.md with your product's pricing model (seat-based, usage-based, or hybrid), your rate constants, and any tier-specific details. The scripts ship with no hardcoded values — you supply them via environment variables or CLI flags.
Use this skill to project a prospect or customer's cost from their prior usage data. It standardizes the projection math across seat-based, usage-based, and hybrid pricing models.
Always read knowledge/platform_credits.md first — it holds the pricing
model taxonomy, rate configuration, conversion options, and projection
formulas. Cite it in your answer.
Prerequisites
METABASE_API_KEY in the environment — only needed for Step 0 (pulling a
customer's usage from a data warehouse). If you already have usage numbers, skip it.- Rate config — set the relevant env vars from
knowledge/platform_credits.md
for your pricing model (e.g. SEAT_PRICE, USAGE_UNIT_PRICE,
INCLUDED_UNITS_PER_SEAT). No rates ship in the repo.
- Python 3 (the scripts are stdlib-only; no
pip install needed).
Inputs
The user typically provides:
- Pricing model — seat-based, usage-based, or hybrid. Confirm from
the pricing sheet or contract if not stated. (Required.)
- Current usage or spend and the window it covers (e.g. "10,000 API
calls over 7 days", "$3,000 inference spend last month"). If given a
team/account ID instead, pull it with Step 0. (Required.)
- Rate constants — set via env vars (see
knowledge/platform_credits.md).
No defaults ship in the repo. (Required.)
- Conversion assumption — if you need to convert from one metric to the
billable unit (e.g. inference spend → compute hours), state the ratio and
its source explicitly. (Required if applicable.)
- Seats — POC seat count + target seat count, for scaling projections. (Optional.)
- Whether they self-host / BYOC — if so, billed compute = $0; optionally
quantify the avoided infrastructure cost.
If an optional input is missing, use the documented approach and state the
assumption. Rate inputs have no built-in defaults — set them via env vars
or CLI flags before running.
Workflow
Step 0 (optional): Pull usage by account/team ID
If you only have a customer name or account ID, fetch their usage from the
data warehouse first. This gives you observed usage numbers — the best anchor
for any conversion assumption.
python3 .warp/skills/answer_pricing/scripts/fetch_usage.py --account-id <id> --days <n>
Always scope by account/team ID, not email domain — domain filters miss
service accounts and bots that still consume usage.
Requires METABASE_API_KEY.
Step 1: Confirm the pricing model and gather rate constants
Read knowledge/platform_credits.md to identify the applicable model
(seat-based, usage-based, or hybrid). Set the relevant env vars for the
customer's tier — no rates are committed to the repo. If the user references
older figures, confirm which rate was in effect so the numbers reconcile.
Step 2: Identify and state any conversion assumptions
If you need to convert from an observed metric to the billable unit (e.g.
inference tokens → compute hours, API calls → seats), this is the biggest
uncertainty lever (±30–50% typical error). Prefer the customer's own observed
ratio from Step 0. Otherwise choose and state an assumption explicitly —
pass it via CLI flag or env var. Note the direction of the lever.
Step 3: Run the projector
Don't do the math by hand. Set rate env vars first (or pass flags); the script
ships with no hardcoded values:
python3 .warp/skills/answer_pricing/scripts/project_credits.py \
--pricing-model <seat|usage|hybrid> \
--usage <value> --window-days <days> \
[--seat-price <price>] [--seats <n>] [--target-seats <n>] \
[--unit-price <price>] [--included-per-seat <n>] [--overage-price <price>] \
[--conversion-ratio <ratio>] [--json]
It prints a one-line headline and a compact monthly/annual grid across the
configured scenarios. Set PRICE_GRID / USAGE_GRID to compare several
price/volume points. Use --json for full multi-horizon detail, or
--self-test to confirm model arithmetic after any edit.
Step 4: Write the answer
Use the output format below. Lead with the pricing model used, the key numbers,
and any savings vs. an alternative (e.g. current spend vs. projected, or
self-hosted vs. managed). State the conversion assumption in one line.
Keep it short — don't dump every horizon or sanity-check row.
Output Format
Keep the reply short and scannable: one headline (pricing model + key inputs),
the projection result, a savings/comparison line if applicable, and one basis
line. Default to the monthly horizon (annual in parens). Offer other horizons
or price points only if asked.
---BEGIN FORMAT---
[Customer] — Cost Projection ([Pricing Model])
[Usage] / [W] days → monthly run-rate: $[mo]/mo ($[yr]/yr)[ Self-hosted, so compute = $0.]
Scenario comparison:
- [Scenario A, e.g. "10 seats @ $X/seat"] → ~$[mo]/mo
- [Scenario B, e.g. "20 seats @ $X/seat"] → ~$[mo]/mo
- [Alternative, e.g. "usage-based @ $Y/unit"] → ~$[mo]/mo
→ [Scenario A] is ~[S]% [cheaper/more expensive] than [alternative].
Basis: [conversion ratio and source]; directional (±~30–50% without full history).
---END FORMAT---
Guidelines
- Keep the reply presentable. Short headline, neutral scenario options, one
comparison line, one basis line. Don't dump every horizon or sanity-check row.
- Show scenarios plainly. When comparing multiple price points or models,
present them neutrally without labeling any as preferred.
- Never quote a single point estimate for usage-derived costs — show a
range or multiple scenarios so uncertainty is visible.
- Use account/team ID, not email domain, when sourcing usage data (service
accounts hide behind non-customer domains).
- Be evidence-driven. Base rates on
knowledge/platform_credits.md; keep
facts (configured rates) vs. assumptions (conversion ratios) clearly separated.
After Completing
For a one-off answer, reply inline. For a deliverable, save a markdown brief to
reports/pricing/pricing_<customer>_<YYYY-MM-DD>.md and create a PR. For a
formatted deck/xlsx, the skill produces the numbers and brief —
deck formatting is out of scope.
