# Answer Pricing

> 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.

- Skill: `warpdotdev/answer-pricing` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add warpdotdev/answer-pricing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/warpdotdev/answer-pricing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: warpdotdev (https://skillmd.com/u/warpdotdev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/warpdotdev/answer-pricing

---


# 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:
1. **Pricing model** — seat-based, usage-based, or hybrid. Confirm from
   the pricing sheet or contract if not stated. *(Required.)*
2. **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.)*
3. **Rate constants** — set via env vars (see `knowledge/platform_credits.md`).
   No defaults ship in the repo. *(Required.)*
4. **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.)*
5. **Seats** — POC seat count + target seat count, for scaling projections. *(Optional.)*
6. 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.

```bash
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:

```bash
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.