@trazum/core 1.81.0 → 1.82.0

package/src/measured-profile.ts

@@ -70,6 +70,10 @@ export interface MeasuredUsage {
    * call is the same size. It is handed over as the better of two
    * approximations — a measured token share beats a typed call share — and
    * named honestly here so no rendering can call it something it is not.
+   *
+   * The denominator is every input token, **writes included**. Leaving writes
+   * out made a constantly-rewritten cache report a high hit rate, which is the
+   * one workload that most needs to be told otherwise.
    */
   cacheReadShare: number;
   /**
@@ -105,6 +109,7 @@ export function measuredUsage(
   const outputTokens = slices.reduce((sum, row) => sum + row.breakdown.outputTokens, 0);
   const inputTokens = slices.reduce((sum, row) => sum + row.breakdown.inputTokens, 0);
   const cacheReadTokens = slices.reduce((sum, row) => sum + row.breakdown.cacheReadTokens, 0);
+  const cacheWriteTokens = slices.reduce((sum, row) => sum + row.breakdown.cacheWriteTokens, 0);
 
   // The model carrying the most spend. Ties break on the larger call count, so
   // the answer is stable rather than dependent on map ordering.
@@ -127,8 +132,27 @@ export function measuredUsage(
       ? { fromDays: spanDays, factor: SCALE_TO_DAYS / spanDays }
       : null;
 
-  const readShare =
-    inputTokens + cacheReadTokens > 0 ? cacheReadTokens / (inputTokens + cacheReadTokens) : 0;
+  /**
+   * Every input token in the denominator, writes included.
+   *
+   * This was `reads / (input + reads)`, which leaves cache *writes* out of the
+   * total it is a share of. A workload that rewrites its prefix on every call
+   * and reads it back rarely then reports a **high** hit rate: with 100 read
+   * tokens, no plain input and 10,000 written, the old expression answers 100%
+   * where the truth is 1%.
+   *
+   * That is the worst direction for this number to be wrong in. It is handed
+   * to `optimize` as `cacheHitRate`, which decides whether caching is paying
+   * off — so the shape that is burning money on writes was the shape most
+   * likely to be told its cache was working perfectly.
+   *
+   * Writes are input tokens: they are billed at the input rate times the write
+   * multiplier, they arrive in the same `usage` block, and any accounting of
+   * "what share of the input came from cache" that omits them is answering a
+   * narrower question than the one it is named for.
+   */
+  const allInputTokens = inputTokens + cacheReadTokens + cacheWriteTokens;
+  const readShare = allInputTokens > 0 ? cacheReadTokens / allInputTokens : 0;
 
   return {
     profile: {

package/src/schemas.ts

@@ -151,6 +151,42 @@ export const CONTRACT_SCHEMAS: Record<ContractName, Record<string, unknown>> = {
     cannotSay: array,
     unpricedRecords: number,
   }),
+  'routing-measurement': doc('routing-measurement', {
+    slice: object,
+    evaluation: object,
+  }),
+  'example-pruning': doc('example-pruning', {
+    provider: string,
+    model: string,
+    selfAgreement: number,
+    recoverableTokens: number,
+    callsMade: number,
+    contributions: array,
+  }),
+  'store-inventory': doc('store-inventory', {
+    providers: array,
+    totalRecords: number,
+    span: objectOrNull,
+    possiblyDouble: number,
+    unknownVersion: number,
+    totalUsd: number,
+    unreadable: array,
+  }),
+  conformance: doc('conformance', {
+    contract: stringOrNull,
+    because: stringOrNull,
+    problems: array,
+    unavailable: array,
+    records: { type: ['number', 'null'] },
+    conforms: boolean,
+  }),
+  'watch-cycle': doc('watch-cycle', {
+    firedAtMs: number,
+    crossings: array,
+    suppressed: array,
+    abstentions: array,
+    gap: objectOrNull,
+  }),
 };
 
 /** The schema for one named contract — the object `trazum schema` prints. */

package/src/tokenizer.ts

@@ -2,20 +2,22 @@
  * Dependency-free token estimator.
  *
  * This is NOT a real tokenizer: it is a heuristic calibrated per character
- * class. It is built to keep the typical error on ordinary text
- * (English/Spanish, markdown, code) inside ±10%, which is plenty for comparing
- * two versions of the same prompt — but do NOT bill anyone from it.
+ * class, built for comparing two versions of the same prompt — but do NOT bill
+ * anyone from it.
  *
- * **That band is a design target that has not been measured.** It is printed on
- * every report and every dollar figure descends from it, and until
- * `scripts/measure-token-band.mjs` has been run against the official counting
- * endpoint, nothing in this repository establishes that it holds. It is stated
- * as one number for all text, which is a further assumption: the branches below
- * treat CJK, digits and punctuation quite differently from words, and there is
- * no reason those should land on the same accuracy.
+ * **Its accuracy is not one number, and the years it was written as one were
+ * the mistake.** The branches below treat CJK, digits and punctuation quite
+ * differently from words, and there was never a reason those should land on the
+ * same accuracy. Measured over 47 samples against the official counting
+ * endpoint they do not: the worst error is 3.2% on CJK, 5.6% on Latin prose,
+ * 25.1% on code and quoting, and 32.5% on a digit-dominant table. `band.ts`
+ * holds the bands those measurements earn and `bandFor(text)` is what a caller
+ * should print; the constant below is only the widest of them, for callers that
+ * have no text in hand.
  *
- * `test/token-band.test.js` asserts the band per text type as soon as the ground
- * truth exists. Until then it says so rather than passing quietly.
+ * `test/token-band.test.js` holds every sample against the band `bandFor` gives
+ * it, and a sample edited since it was measured fails rather than passing
+ * quietly.
  *
  * For exact numbers use `countTokensAnthropic` (the official token-counting
  * endpoint, which is free) or pass your own `TokenCounter`.
@@ -25,53 +27,47 @@ import { detectTextLanguage } from './language.js';
 import { SAFE_FETCH_INIT, checkedEndpoint } from './net.js';
 
 /**
- * The error band this estimator is published under, as a percentage.
+ * The widest band this estimator is published under, as a percentage.
  *
- * **Measured, not chosen, and it has moved three times.** It was `15` for eight
- * releases as a design target nobody had checked; the first measurement found two
- * of eight samples outside it and it went to `25`; fixing the digit divisor and
- * calibrating per language brought it back to `15`. This is the fourth value and
- * the first one that is comfortably above what the corpus actually shows.
+ * **A history worth keeping, because each value was believed at the time.** It
+ * was `15` for eight releases as a design target nobody had checked; the first
+ * measurement found two of eight samples outside it and it went to `25`; fixing
+ * the digit divisor and calibrating per language brought it back to `15`, and
+ * splitting kana from han — Japanese had been +11.2% and Chinese −3.2% under one
+ * rule — brought it to `10`. Four values, each an improvement, and all four
+ * wrong in the same way.
  *
- * ```
- * worst measured error   6.4%   (code-heavy, which nothing is fitted to)
- * published band        10%
- * ```
+ * **The corpus they were measured on was the corpus they were fitted to.**
+ * Twenty-one samples held thirteen files of Latin prose and exactly one each of
+ * code, numeric and punctuation, and those single files were where the constants
+ * came from. The worst error it could show was 6.4%, and 10 looked like a
+ * comfortable margin over it. Neither figure was about the estimator.
  *
- * **The margin is deliberate and it is not slack.** 6.4 rounded up is 7, and
- * publishing 7 would be a tighter claim than twenty-one samples across six text
- * types can support: the corpus has no Korean, no Arabic, no Cyrillic prose, no
- * mixed-script document, and a seventh text type could easily land at eight. A
- * band that becomes false the first time somebody measures something new is the
- * exact fault this whole exercise was fixing. Overstating the uncertainty is the
- * safe direction for a tool that reports money.
+ * **It is no longer one number, and this one is the widest.** A corpus of
+ * thirteen prose files and one each of code, numeric and punctuation put the
+ * band at 10, and those single files were the set the constants had been fitted
+ * to. Measured on forty-seven, the same estimator is 6% out on prose and 33%
+ * out on a CSV ledger. `bandFor` in `band.ts` is what a caller that has the
+ * text should use.
  *
- * What earned the drop from 15 was **splitting kana from han**. Every CJK
- * character was charged one token, which put Japanese at +11.2% — the worst error
- * anywhere in the corpus — while Chinese sat at −3.2% under the same rule. Kana
- * measure 0.75 tokens per character and han 1.05, and that pair takes the two
- * samples to −1.5% and +1.3%. See `KANA_TOKENS_PER_CHAR`.
- *
- * **Which samples the band rests on matters more than the number.** Eight of the
- * twenty-one had a constant fitted to them — seven Latin divisors and the digit
- * divisor — so their residuals are optimistic by construction. The two worst
- * errors in the corpus, `code-heavy` at 6.4% and `punctuation-heavy` at 5.7%, are
- * fitted to nothing at all, and they are what sets this figure.
- *
- * Exported so every report, README and tool description reads the same number. It
- * was a literal in twenty-four files before this, with the only machine-readable
- * copy in a test, and `token-band.test.js` now fails any file that states a
- * different one.
+ * This stays for the callers that do not have it — a figure covering the whole
+ * catalogue of text, which can only be the worst of them. Widening it from 10
+ * to 33 makes every claim that reads it true where it had been false, at the
+ * cost of understating the estimator on prose. That trade is deliberate: a
+ * caller with no text cannot know which it is holding, and there is only one
+ * safe direction to guess in.
  */
-export const ESTIMATE_ERROR_BAND_PCT = 10;
+export const ESTIMATE_ERROR_BAND_PCT = 33;
 
 /**
  * Whose tokenizer that band was measured against.
  *
  * The number above is not a property of the estimator; it is a property of the
- * estimator **against Claude**. Twenty-one samples, one counting endpoint, one
- * family. Trazum prices seven, and until somebody runs the harness against the
- * others nobody knows what the error is on a GPT or a Gemini prompt.
+ * estimator **against Claude**. Forty-seven samples, one counting endpoint, one
+ * family. Trazum prices seven, and the two that have since been run are far
+ * outside anything published here: DeepSeek 94.5% at worst, Mistral 103.1%. On
+ * a GPT or a Gemini prompt nobody has measured it at all, and
+ * `measuredForeignError` answers null rather than the nearest number.
  *
  * Exported as a name rather than left implicit in a comment because the band
  * had already leaked out of its domain in three places: an advisory that told a
@@ -173,6 +169,34 @@ const DIVISOR_BY_LANGUAGE: Readonly<Record<string, number>> = {
 const KANA_TOKENS_PER_CHAR = 0.75;
 const HAN_TOKENS_PER_CHAR = 1.05;
 
+/**
+ * Hangul, measured at last.
+ *
+ * The comment above used to end *"Hangul keeps the old cost of 1, because
+ * nothing here measures Korean. Guessing it from Japanese would be inventing a
+ * figure."* That was right, and it stayed right for exactly as long as nobody
+ * measured Korean. `cjk-korean.txt` now does: at 1 token per character the
+ * estimate came out **20.0% under** — 232 against 290 — and 1.20 takes it to
+ * -10.0%.
+ *
+ * **1.20 was the one-sample answer and it was wrong by ten points.** A second
+ * Korean sample in a different register — a deployment review against support
+ * copy — put both at -10.6% and -10.0% under it, and solving the constant on
+ * the two together lands on 1.35, where both come out at 0.0%.
+ *
+ * Two independent texts agreeing to within four tenths of a point across the
+ * whole search is what makes this a property of Hangul rather than a fit to a
+ * file. Their residuals move in lockstep at every candidate value: -10.6/-10.0
+ * at 1.20, -3.5/-3.1 at 1.30, 3.2/3.4 at 1.40. One sample cannot show that and
+ * two can, which is the entire argument for measuring more of the thin classes
+ * rather than tuning harder on the thin ones.
+ *
+ * Still in-sample: the honest test is a third Korean prompt, and the corpus
+ * grows one at a time.
+ */
+const HANGUL_TOKENS_PER_CHAR = 1.35;
+const HANGUL = /[가-힯]/;
+
 /**
  * What a prompt gets when the language could not be told.
  *
@@ -248,7 +272,11 @@ export function estimateTokens(text: string): number {
        * where the loop happens to break, not of what the text costs.
        */
       while (i < chars.length && CJK.test(chars[i]!)) {
-        cjkTokens += KANA.test(chars[i]!) ? KANA_TOKENS_PER_CHAR : HAN_TOKENS_PER_CHAR;
+        cjkTokens += KANA.test(chars[i]!)
+          ? KANA_TOKENS_PER_CHAR
+          : HANGUL.test(chars[i]!)
+            ? HANGUL_TOKENS_PER_CHAR
+            : HAN_TOKENS_PER_CHAR;
         i++;
       }
       continue;
@@ -315,7 +343,29 @@ export function estimateTokens(text: string): number {
       total += 1;
       i++;
     } else {
-      total += Math.ceil(n / 2);
+      /**
+       * One token per symbol, not one per two.
+       *
+       * Two was the shipped value and every symbol-dense sample in the corpus
+       * undercounted under it, in the same direction, by amounts that grow with
+       * density: punctuation-heavy -5.7%, code-heavy -6.4%,
+       * punctuation-markup -11.4%, code-sql -25.6%, code-shell -29.8%. Five
+       * samples agreeing on a direction is a shape, not a fit — a merge table
+       * covers `, ` and `. ` and covers `${`, `"$`, `--` and `&#8209;` far less
+       * well, and shell and SQL are made of the second kind.
+       *
+       * Searched over the whole corpus rather than the class it helps, so a
+       * value that fixed code by wrecking prose could not look like a win: at
+       * 1.0 the samples outside the published band drop from five to three and
+       * the mean error from 6.6% to 5.1%, with no sample moved more than a
+       * point in the wrong direction.
+       *
+       * The search wanted to go below 1.0 and was not allowed to. Below one is
+       * more than a token per symbol, which may well be true of SQL — code-sql
+       * is still 24.9% under — but it is a claim about a class this corpus has
+       * two samples of, and two samples do not earn a constant.
+       */
+      total += Math.ceil(n / 1);
     }
   }
 

package/src/types.ts

@@ -61,6 +61,7 @@ export type AdvisoryId =
   | 'cache-prefix-reorder'
   | 'batch-api'
   | 'model-downgrade'
+  | 'tier-signals-conflict'
   | 'output-dominated'
   | 'promo-pricing'
   | 'contradictory-instructions'

package/src/verdict-bridge.ts

@@ -0,0 +1,200 @@
+/**
+ * Reading a dropped `route --json` verdict, so quality can stand beside cost.
+ *
+ * The bill is arithmetic: every figure in it comes from records already on
+ * disk, and it can say exactly what a cheaper model would have saved. It can
+ * say nothing at all about whether that model still does the job. That answer
+ * costs provider calls and a credential, which is why `trazum route` exists
+ * and why no surface that only reads a log will ever produce it.
+ *
+ * This is the bridge between the two, and it is deliberately one-directional:
+ * the measurement is made where the credential is, written out as the
+ * `routing-measurement` contract, and read back here by a pure function that
+ * touches no network and holds no key. A reader who has run `route` once can
+ * carry the verdict to any surface that prices the same workload.
+ *
+ * It was not possible to write until the document was worth reading. Before
+ * the JSON-text sweep, `route --json` printed the whole `EvalReport` — every
+ * case input and three model answers per case — so a bridge would have been a
+ * feature for carrying prompt text into a browser. The document carries the
+ * measurement and nothing else now, and `conform` is what says so rather than
+ * this file's own reading: the contract validates, the bridge only maps.
+ */
+
+import { conform } from './conform.js';
+import type { EvalVerdict } from './evaluate.js';
+import { UNLABELLED } from './usage.js';
+
+/** What a dropped routing measurement says, mapped onto what a bill can match. */
+export interface DroppedVerdict {
+  /** The workload the measurement was made on, or null when it was unlabelled. */
+  label: string | null;
+  /**
+   * The model those calls go to today, from the bill's own slice.
+   *
+   * Not the model that answered. `route` builds its baseline provider from
+   * the environment, so the model in the measurement is whatever
+   * `TRAZUM_LLM_MODEL` names, and it is only the log's model when the reader
+   * configured it that way. Pairing on it matched nothing on a real run
+   * against an OpenAI-compatible endpoint — `evaluation.model` said
+   * `stub-strong` while the log said `claude-opus-5` — and the bill would
+   * have shown no verdict at all with no explanation.
+   */
+  model: string;
+  /**
+   * The model that actually answered, when it is not the one the log records.
+   *
+   * Null when they agree, which is the ordinary case. Not null is worth
+   * saying out loud rather than smoothing over: a verdict measured on a
+   * stand-in is a weaker claim about this workload than one measured on the
+   * model the workload actually uses, and only this field can tell the
+   * difference.
+   */
+  measuredOn: string | null;
+  /** The model measured against it. */
+  candidateModel: string;
+  verdict: EvalVerdict;
+  /** The model's agreement with itself. The yardstick the other rate is read against. */
+  selfAgreement: number;
+  /** Agreement between the two models, same prompt on both sides. */
+  crossAgreement: number;
+  /** Cases the measurement covered, so a two-case verdict cannot pose as a hundred. */
+  cases: number;
+  /** Calls it cost to reach. */
+  callsMade: number;
+  /**
+   * What the measurement's own bill priced the route at, when the document
+   * carried it. Null rather than zero when it did not: a saving nobody
+   * measured is not a saving of nothing.
+   */
+  savingUsd: number | null;
+}
+
+/**
+ * What the bridge did with a file.
+ *
+ * `null` is not a failure: it means the file is not a routing measurement at
+ * all, and the caller should go on treating it as whatever else it was. A
+ * refusal is the other case — it looked like one and could not be read — and
+ * it names what is missing, because a refusal with nothing after it is
+ * indistinguishable from a bug.
+ */
+export type BridgeReading =
+  | { kind: 'verdict'; verdict: DroppedVerdict }
+  | { kind: 'refusal'; because: string };
+
+const isObject = (value: unknown): value is Record<string, unknown> =>
+  typeof value === 'object' && value !== null && !Array.isArray(value);
+
+/**
+ * Whether this file is even claiming to be a routing measurement.
+ *
+ * Shape only, and deliberately narrow: an `evaluation` object carrying a
+ * `verdict`. Anything looser would swallow a usage log or a profile and
+ * refuse it in this file's words instead of letting the caller price it.
+ */
+function claimsToBeOne(parsed: unknown): boolean {
+  if (!isObject(parsed)) return false;
+  const evaluation = parsed.evaluation;
+  return isObject(evaluation) && typeof evaluation.verdict === 'string';
+}
+
+/**
+ * Reads a dropped `trazum route --json` document.
+ *
+ * Returns null when the text is something else entirely. Validation is
+ * `conform`'s, against the published `routing-measurement` contract, so this
+ * function cannot drift from the schema a connector author builds against —
+ * and a document that fails carries the contract's own sentences back to the
+ * reader rather than a second opinion written here.
+ */
+export function readDroppedVerdict(text: string): BridgeReading | null {
+  let parsed: unknown;
+  try {
+    parsed = JSON.parse(text);
+  } catch {
+    return null;
+  }
+  if (!claimsToBeOne(parsed)) return null;
+
+  const report = conform(text, { contract: 'routing-measurement' });
+  if (!report.conforms) {
+    const detail =
+      report.problems.length > 0
+        ? report.problems.map((problem) => `${problem.at}: ${problem.detail}`).join('; ')
+        : (report.because ?? 'it does not match the routing-measurement contract');
+    return { kind: 'refusal', because: detail };
+  }
+
+  const document = parsed as { slice?: unknown; evaluation?: unknown };
+  const slice = isObject(document.slice) ? document.slice : {};
+  const evaluation = document.evaluation as Record<string, unknown>;
+
+  /**
+   * Every field below is read defensively even though `conform` has passed,
+   * because the contract requires `slice` and `evaluation` to be objects and
+   * says nothing about what is inside them. A document from a future version
+   * with a thinner slice is a document this reads what it can from, not one
+   * it crashes on.
+   */
+  const answered = typeof evaluation.model === 'string' ? evaluation.model : null;
+  // The slice's model first: that is the fact the bill can be matched against.
+  const model = typeof slice.model === 'string' ? slice.model : answered;
+  const candidateModel =
+    typeof evaluation.candidateModel === 'string' ? evaluation.candidateModel : null;
+  const verdict = typeof evaluation.verdict === 'string' ? (evaluation.verdict as EvalVerdict) : null;
+  if (model === null || candidateModel === null || verdict === null) {
+    return {
+      kind: 'refusal',
+      because:
+        'the evaluation names no model, candidate model or verdict, so there is nothing to set beside a bill',
+    };
+  }
+
+  const number = (value: unknown): number => (typeof value === 'number' ? value : 0);
+  const route = isObject(slice.route) ? slice.route : null;
+  const rawLabel = typeof slice.label === 'string' ? slice.label : null;
+
+  return {
+    kind: 'verdict',
+    verdict: {
+      // `UNLABELLED` is the profile's own sentinel for calls that carry no
+      // label. It travels through the document as that sentinel and comes
+      // back as null here, so the bridge speaks the bill's language rather
+      // than leaking an internal marker into a caption.
+      label: rawLabel === null || rawLabel === UNLABELLED ? null : rawLabel,
+      model,
+      measuredOn: answered !== null && answered !== model ? answered : null,
+      candidateModel,
+      verdict,
+      selfAgreement: number(evaluation.selfAgreement),
+      crossAgreement: number(evaluation.crossAgreement),
+      cases: Array.isArray(evaluation.cases) ? evaluation.cases.length : 0,
+      callsMade: number(evaluation.callsMade),
+      savingUsd: route !== null && typeof route.savingUsd === 'number' ? route.savingUsd : null,
+    },
+  };
+}
+
+/**
+ * Whether a verdict describes the route a given slice of the bill is offering.
+ *
+ * Both halves must agree or the pairing is a lie: the same workload, the same
+ * model it goes to now, and the same candidate. A verdict measured on `chat`
+ * shown against `summarise`'s saving would be the exact fault this repository
+ * keeps finding in itself — a number describing something other than what was
+ * measured — and matching on the model alone would produce it on any log with
+ * two workloads on one model.
+ */
+export function verdictMatchesSlice(
+  verdict: DroppedVerdict,
+  slice: { label: string; model: string; route: { candidate: { id: string } } | null },
+): boolean {
+  if (slice.route === null) return false;
+  const sliceLabel = slice.label === UNLABELLED ? null : slice.label;
+  return (
+    sliceLabel === verdict.label &&
+    slice.model === verdict.model &&
+    slice.route.candidate.id === verdict.candidateModel
+  );
+}