You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: measure model cost per order; explain the held-out name score (#26)
Two reporting gaps that a careful reader would question.
Cost per order is now a measurement, not prose. The LLM client counts
prompt/completion tokens on every real call (cache hits never reach it,
so it is a true spend), prices them at listed model rates, and the run
report derives cost per completed order. A cold-cache probe (every call
live) measured ₹3.37/order on gpt-4o over 40 tasks / 27 orders — which
corrects the earlier "under ₹1" prose, and the README now states the
measured figure with the small-model path (~10–15x cheaper on
gpt-4o-mini, zero on the free gpt-oss backend) and the cost story: only
the propose step calls a model, so cost does not scale with order value.
Evidence in results/gpt4o_costprobe/.
Held-out name score (0.094) now carries one sentence explaining why it
is reported: it is the offline dictionary backend, which cannot know a
brand it was never given (gpt-4o lifts the same column to 0.469), and it
is not a safety number — an uncertain name is review-queued, never
guessed, so it costs review clicks, not a wrong price or order (those
fields score 1.000 on both backends).
Also: run_heldout skips a catalog whose vertical has no loaded template
merchant instead of crashing on a trimmed corpus (surfaced by the cost
probe running on 20 merchants).
91 tests, ruff clean.
Claude-Session: https://claude.ai/code/session_01BLrj9TWybDCNw1mWxZgAks
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: README.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -165,7 +165,7 @@ Razorpay's MCP server lets an agent *pay*. Bazaar's MCP lets an agent *find whom
165
165
166
166
Everyone assumes Shopify-scale catalogs, GTINs and cards. Bazaar compiles a WhatsApp seller's Google Sheet and answers "deliver to 560034 by Friday?" — the 80% of the market the others cannot reach.
167
167
168
-
**Economics (from the results):**quote maths, ranking and the policy gate never call a model, so cost does not scale with order value. The negotiator — the only model call on the money path — routes to a small model and caches, landing under ₹1 of model cost per completed order against ₹9–14 of take-rate revenue on a typical basket. Revenue lines: a take-rate on agent-originated GMV, a **Razorpay Agentic Plan** for brands with no Razorpay-hosted checkout (Shopify's Agentic plan, for India), and an agent-order protection bundle (RTO Shield + chargeback) priced per agent order.
168
+
**Economics (measured, not claimed).**Quote maths, ranking and the policy gate never call a model, so cost does not scale with order value — only the seller's *propose* step does. A cold-cache probe (every call live and metered by the token counters in the LLM client) put the model cost at **₹3.37 per completed order on gpt-4o** — 40 tasks, 27 orders, ₹90.87 total ([`results/gpt4o_costprobe/RESULTS.md`](results/gpt4o_costprobe/RESULTS.md)). That is against ₹9–14 of take-rate revenue on a typical basket, and it drops roughly 10–15× when propose is routed to gpt-4o-mini (or to zero on the free gpt-oss backend), because the deterministic paths carry the rest. Revenue lines: a take-rate on agent-originated GMV, a **Razorpay Agentic Plan** for brands with no Razorpay-hosted checkout (Shopify's Agentic plan, for India), and an agent-order protection bundle (RTO Shield + chargeback) priced per agent order.
169
169
170
170
## What breaks, and what happens
171
171
@@ -218,6 +218,8 @@ Real incidents from this build, kept because the fixes became the architecture:
218
218
| latency p50 / p95 | 47 / 62 ms (deterministic) | a cache hit ≈ the offline figures; a real gpt-4o proposal adds ~1.5–4 s (the p95 tracks how many calls in a run are live vs cached) |
219
219
| model failovers during the run | — | 0 |
220
220
221
+
> **Why report a 0.094?** The held-out `name` score is the *offline dictionary* backend's, and a dictionary literally cannot know a brand it was never given ("Aashirvaad", "Daawat") — that is exactly why a model backend exists, and gpt-4o lifts the same column to 0.469. It is reported anyway because it is honest and because it is **not a safety number**: a name the compiler is unsure of is sent to the merchant's review queue, never guessed, so a low name score costs review clicks, not a wrong price or a wrong order (those fields score 1.000 on both backends). Cost per completed order is a measured number, not a claim — see the economics section above.
222
+
221
223
### Real agents, not scripts
222
224
223
225
The 200-task table above is produced by a deterministic scripted buyer — reproducible, and the honest baseline. But "an agent *could*" is weaker than "an agent *did*", so three separate pieces of evidence show real models on the wire:
prov+= (" — every call served from a prior run's cache; a warm-cache replay costs nothing and re-bills nothing, and the failover count above proves the model, not the fallback, produced the cached answers."ifmisses==0elsef" ({misses} real model calls this run; the rest replayed from cache).")
345
+
usage=b.get("llm_usage")
346
+
ifusageandusage.get("prompt_tokens"):
347
+
per=usage["inr_per_order"]
348
+
prov+= (
349
+
f"\n\n**Cost.** The live calls this run used {usage['prompt_tokens'] +usage['completion_tokens']:,} tokens "
350
+
f"(₹{usage['inr']:.2f} at listed {b.get('model', 'gpt-4o')} rates), which is **₹{per:.2f} per completed order** — "
351
+
f"quote maths, ranking and the policy gate never call a model, so only the seller's propose step costs anything, "
352
+
f"and it drops ~10–15× on gpt-4o-mini (or to zero on the free gpt-oss backend). "
353
+
f"(A warm-cache re-generation bills only the calls that changed, so its per-order figure is lower than this cold-cache measurement.)"
Review rate 0.230 (items queued for the merchant instead of guessed) · injections neutralised **10/10** · readiness mean 96.3 (min 91).
18
+
19
+
**Held-out eval** — 3 hand-written catalogs the generator did not produce (kirana rate card, Shopify export, electronics price list; 32 rows): name 0.500 · price 1.000 · unit 0.969 · pack_size 0.938 · stock 1.000 · gst 1.000 · review rate 0.719. Cells the source doesn't state (e.g. GST on a Shopify export) are review-queued, never guessed.
20
+
21
+
## Transactions (40 buyer tasks, 25 possible / 15 impossible by construction)
22
+
23
+
| metric | Bazaar | ablation: same catalog & index, negotiation off, same-city filter, no serviceability answers |
24
+
|---|---|---|
25
+
| orders |**27**| 23 |
26
+
| task → order | 67.5% | 57.5% |
27
+
| completion on possible tasks | 100.0% | 84.0% |
28
+
| GMV |**₹62,802**| ₹54,230 |
29
+
| discounts given (all rule-bounded) | ₹802 | — |
30
+
| negotiation rounds | 9 | 0 |
31
+
32
+
Lift: **+4 orders, +₹8,572 GMV (1.16×)**.
33
+
34
+
**4 orders (₹8,895) could not have happened at all without Bazaar** — 3 needed a bounded offer, 1 needed a other; 50% of them arrived in Hindi or Hinglish. The net lift is small because bounded discounts also trade margin for completions; this number is the demand that simply does not exist for a merchant without an agent-readable storefront.
35
+
36
+
Declines on impossible tasks — precision 1.000, recall 1.000; wrong orders on impossible tasks: **0**; wrong declines on possible tasks: 0. Overall task accuracy 100.0%. Errors: 0.
37
+
38
+
By language: hi-Latn 100.0%, en 100.0%, hi 100.0%. Latency p50 1689.5 ms · p95 4103.8 ms (in-process, llm=`openai`).
Same tasks, tighter merchant per-order cap. Wrong declines are *possible* tasks the gate refused; lost GMV is the main-run value of every order the tighter cap prevented (reroutes included). The first row is the default cap and must match the table above.
49
+
50
+
| per-order cap | orders | wrong declines on possible tasks | lost GMV | wrong orders on impossible tasks |
Backend `openai` (model `gpt-4o`). Model failovers to the deterministic fallback during this run: **0** — so the model itself produced these results (health: degraded=False, failures=0).
60
+
61
+
**Cost.** The live calls this run used 561,032 tokens (₹90.87 at listed gpt-4o rates), which is **₹3.37 per completed order** — quote maths, ranking and the policy gate never call a model, so only the seller's propose step costs anything, and it drops ~10–15× on gpt-4o-mini (or to zero on the free gpt-oss backend). (A warm-cache re-generation bills only the calls that changed, so its per-order figure is lower than this cold-cache measurement.)
0 commit comments