cost_velocity.

A real-world example: a $500-per-month proof-of-concept becomes $847,000 per month once it ships, because the production agent re-sends the entire conversation history on every retry and amplifies tool-loop bugs into rapid-fire LLM calls. The first symptom is not a crash, not a tool failure, and not a quality regression. It is the bill at the end of the month. cost_velocity fires within seconds of that pattern starting.

Cost is computed server-side at execution close from the per-event input + output token counts the SDK ships, multiplied by a backend-maintained pricing table. Pricing changes ship with a backend deploy — no SDK release wait. The table version is exposed at GET /me/pricing-info so you can verify which prices Mesedi is using.

At execution close, if execution.estimated_cost_usdis at or above the project's cost_velocity_threshold_usd, the detector fires under signature cost_$<tier>+where the tier is the cost's order of magnitude (cost_$0.001+, cost_$0.01+, cost_$0.10+, cost_$1+, cost_$10+). Tiered signatures so a $0.50 alarm stays visually distinct from a $50 alarm on the same dashboard.

Default threshold is $1.00. Tune lower (down to a $0.01 floor) for cost-sensitive workloads; tune higher (up to a $10,000 ceiling) for batch-tolerant workloads. See How to tune below.

At execution close, Mesedi sums the cost of every recent execution in the same project within a rolling window (default 5 minutes). If sum / window_minutesis at or above the project's cost_velocity_rate_threshold_usd_per_min, the rate detector fires under signature rate_$<tier>+_per_min (e.g. rate_$5+_per_min, rate_$100+_per_min). The tiered signature lets a sustained-but-modest burn stay visually distinct from a runaway-train burn.

Default rate threshold is $5/minute over a 5-minute window. The floor is $0.10/minute (prevents fires-on-every-minute storage abuse) and the ceiling is $10,000/minute (overflow safety). Window ranges from 1 to 60 minutes.

The rate detector and the absolute detector are independent. A single $50 execution that took 5 minutes trips both: absolute because $50 ≥ default $1.00, rate because $50 over 5 minutes is $10/minute. You will see two failure_group rows for that one execution — one per signature — pointing at the same underlying event.

Both thresholds are stored per-project and editable via simple PUT requests against your project's API key.

# Read the current absolute threshold.
curl -H "Authorization: Bearer $MESEDI_API_KEY" \
  https://api.mesedi.ai/me/cost-velocity-config

# Lower it to 50 cents — fire on any execution above $0.50.
curl -X PUT -H "Authorization: Bearer $MESEDI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"threshold_usd": 0.50}' \
  https://api.mesedi.ai/me/cost-velocity-config

# Read the current rate config.
curl -H "Authorization: Bearer $MESEDI_API_KEY" \
  https://api.mesedi.ai/me/cost-velocity-rate-config

# Tighten rate detection: alarm at $2/min over a 1-minute window.
curl -X PUT -H "Authorization: Bearer $MESEDI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"threshold_usd_per_min": 2.00, "window_minutes": 1}' \
  https://api.mesedi.ai/me/cost-velocity-rate-config

Bounds enforced by the backend:

• threshold_usd ∈ [$0.01, $10,000.00]
• threshold_usd_per_min ∈ [$0.10, $10,000.00]
• window_minutes ∈ [1, 60]

Out-of-range values return 400 with a human-readable reason. Both thresholds are NOT tier-capped — alarm sensitivity is your choice regardless of plan.

Why is cost_velocity firing on every execution? Your threshold_usd is set too low for your workload. Pull the current value via GET /me/cost-velocity-config and raise it to a value above your typical execution cost.

Why is rate firing during routine traffic? The window_minutes might be too short relative to your traffic pattern. A 1-minute window treats a 10-second burst as a sustained spike; a 5-minute window smooths it out. Try widening the window before lowering the threshold.

Why is the absolute detector silent on what looks like an expensive run? Either the execution's computed cost is below your threshold, OR the model used isn't in the backend pricing table (see "What we don't catch yet" below) AND the SDK didn't ship a per-event cost number. Check GET /me/pricing-info for the supported model list.

Why are absolute AND rate both firing on the same execution? Working as intended. A single expensive call AND sustained burn are two distinct signals; the dashboard shows both so you can see which lens of the same event caught the problem.

Three coverage extensions shipped after the initial cost_velocity launch:

• Ollama tag-style identifiers (llama3.2:3b, qwen2.5-coder:32b, and similar) resolve to the canonical Ollama prefix in the backend pricing table at $0 (self-hosted = no API cost). Customers using Ollama see accurate $0 cost attribution without having to maintain their own override.
• Per-project pricing overrides for custom or fine-tuned models that don't match any canonical pricing-table entry. Set via the per-project custom_model_pricing knob: a JSON map of model identifier → {input_usd_per_token, output_usd_per_token}. When set, the override wins over the canonical table; when unset, Mesedi falls back to the canonical lookup and (for unknown models) to the SDK-shipped per-event estimated_cost_usd, recording a pricing_unknown_model system event for dashboard visibility.
• Provider tier pricing — Gemini Pro and similar models that tier their input pricing by context size (e.g. ≤200K vs >200K input tokens) are now priced tier-aware in the canonical table. The break point is encoded in the pricing entry; cost attribution switches automatically based on the per-call input-token count.

Two cost_velocity behaviors are deliberate product decisions, not gaps to close:

• Rate-detector floor at $0.10/minute is a storage-abuse guardrail. A customer setting it to $0.0001 would create a failure_group on every minute of every project. Workloads spending less than $0.10/minute in total cannot trip the rate detector by design — if you need finer-grained cost alarms, use the absolute detector instead.
• No historical recompute — when a pricing change ships, only NEW executions use the new prices. Existing executions retain the cost they were assigned at the time. This is deliberate: historical cost numbers stay stable for audit and billing purposes. If you need to reprice history, export and reprice client-side.