From 7f6703b41d61f74b35b9c0cd2580736679291e06 Mon Sep 17 00:00:00 2001 From: Felix Faerber Date: Thu, 28 May 2026 13:04:52 +0300 Subject: [PATCH] =?UTF-8?q?pricing:=20drop=20headroom=20from=201M=20?= =?UTF-8?q?=E2=86=92=2050K=20tokens?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The 1M-token headroom (ported from t4t homelab gateway) makes maxPayment so large that JobEscrow's concurrency cap fires on a fresh provider with ~70 xBZZ stake — postJob reverts with InsufficientStakeForJob. 50k tokens still covers chat-template overhead with room to spare, and brings per-job exposure down ~20x so ~20 concurrent jobs fit comfortably. Co-Authored-By: Claude Opus 4.7 (1M context) --- src/pricing/estimate.ts | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/pricing/estimate.ts b/src/pricing/estimate.ts index 0d03e0a..7bba518 100644 --- a/src/pricing/estimate.ts +++ b/src/pricing/estimate.ts @@ -15,7 +15,14 @@ const TOKENS_PER_MILLION = 1_000_000n; // per-actual-input formula posted a too-low maxPayment and the provider's // claimJob reverted with PaymentTooHigh. const DEFAULT_MAX_TOKENS = 1024n; -const HEADROOM_TOKENS = 1_000_000n; +// Headroom is added to BOTH input and output budgets to cover usage drift +// (chat templates, system prompts the user can't see, etc.). The +// concurrency cap on JobEscrow.postJob is +// needed = (openJobs + 1) * SLASH_MULT_TIMEOUT * maxPayment <= stake +// so headroom directly multiplies how much stake the provider must lock per +// in-flight job. 50k tokens is generous enough that real usage never exceeds +// it but small enough that 20-ish concurrent jobs fit in a 70-xBZZ stake. +const HEADROOM_TOKENS = 50_000n; export interface ChatRequest { model: string;