Sourced Jev pricing

Prompt-first procedure: Describe the outcome you want in your agent conversation. The agent should select and load the appropriate AIWG assets, explain material changes, request any needed approval, and report verification evidence. Exact commands and flags appear only in the CLI reference.

AIWG uses one pricing configuration: `decision.ask.cost.*`. An explicit refresh reads the official TypeSafe model documentation and writes validated, versioned Jev rates through the existing project config writer. There is no independent pricing cache. Ordinary `decision ask` does not fetch pricing documentation; history, stats and plain pricing display are offline.

Use AIWG to complete this documented outcome: AIWG uses one pricing configuration: decision.ask.cost.. An explicit refresh reads the official TypeSafe model documentation and writes validated, versioned Jev rates through the existing project config writer. There is no independent prici
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

The first refresh requires `the model option jev-X.Y.Z`. Unknown versions fail without writing. the dry-run option fetches and validates normally, then shows each changed key's old/new value without creating or changing config. All inputs have flags and the command never prompts, including in headless environments. Invalid flags and missing flag values are usage errors.

A successful refresh sets these keys:

Key under `decision.ask.cost`	Meaning
`jev_input_per_mtok`	USD per million input tokens
`jev_output_per_mtok`	USD per million output tokens, including explicit zero
`source`	`typesafe-docs`, `typesafe-snapshot`, or `manual`
`checked_at`	ISO calendar date, YYYY-MM-DD
`jev_model`	Exact version the rates apply to

`llm_per_mtok`, `jev_per_mtok`, caller assumptions, and unrelated project configuration are preserved. Split rates and blended weights must be finite numbers between zero and 1,000,000. You can set manual rates with the normal the agent-owned config operation command. Mark their source `manual` and provide their date and applicable version.

The fetch accepts at most 256 KiB and has a five-second timeout covering the body read. It uses no credentials, refuses redirects, and never calls a model. The parser requires versioned model IDs, matching billion/million units, finite nonnegative prices, and an explicit free-output statement. Changed formats fail closed and leave config unchanged.

Explicit offline fallback

The bundled snapshot was checked 2026-10-18 and contains Jev 1.13.0 and 1.14.0 at $0.042 per million input tokens and $0 per million output tokens. This is dated reference data, not a claim of current pricing.

Use AIWG to complete this documented outcome: The bundled snapshot was checked 2026-10-18 and contains Jev 1.13.0 and 1.14.0 at $0.042 per million input tokens and $0 per million output tokens. This is dated reference data, not a claim of current pricing.
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Snapshot use always records `source: typesafe-snapshot`, retains `checked_at: 2026-10-18`, and displays the snapshot date. A failed live refresh without the allow-snapshot option leaves config untouched. No implicit fallback occurs. Offline and dry-run flags require the refresh option.

Cost precedence and recorded history

A complete input/output split pair takes precedence over `jev_per_mtok` when recorded usage supplies the required components. Unknown output usage can be priced when its configured rate is zero. Otherwise AIWG uses the existing blended weight and counts missing usage components as zero, preserving previous behavior. An incomplete split pair falls back to blended pricing. Remove both split keys with the agent-owned config operation to restore blended-only estimates.

New ledger records preserve the configured weights, provenance and chosen `jev_rate_basis` in `estimationMethod`. Config changes do not reprice existing v2 records. Stats adds `ratesUsed`, with method and call count, alongside the existing `llm_tokens_avoided`, `jev_tokens`, `cost_weighted_net_usd` and v1 comparison fields. Old v1 records keep their existing in-memory re-estimation behavior and are never rewritten. Old v2 records without provenance remain readable.

Select a pricing version matching the Jev backend you run. `jev_model` describes the rates' applicability; the ledger separately records the actual response model. The net figure still uses heuristic avoided caller tokens and configured LLM weights. Sourced Jev rates improve its cost basis but do not establish exact invoice savings. Missing token usage and cached billing can limit precision. See the quickstart savings section for caller assumptions and legacy reporting.