@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -8,0 +21,4 @@
+      "5h": {},
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 8, "of": "5h" }

@@ -32,1 +32,3 @@
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a cross-meter ratio (its total is that fraction of a sibling meter's total; for example, the fable meter is half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`); the script propagates estimates through it in both directions automatically.
+
+The Claude ratio calibrations are empirical cross-meter facts: long, monotonically increasing Prometheus ramps support approximately `weekly = 6 × 5h` for the regular Max accounts and `weekly = 8 × 5h` for the Team Premium/VC account. Aggregating the whole ramps makes the two endpoint rounding errors small relative to the movement, so these relative ratios are better constrained than the absolute API-dollar totals. When an absolute dollar estimate conflicts with one of these calibrated ratios, retain the ratio and revise the weaker dollar estimate; the capacity contract and `plans.json` should stay consistent.

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -8,0 +10,4 @@
+      },
+      "weekly-fable": {
+        "periodHours": 168,
+        "worth": { "fraction": 0.5, "of": "weekly" }

@@ -30,3 +30,3 @@
 One spending window usually moves several meters at once; record a separate line per meter, sharing `usd`, `at`, and `session`. `note` stays free-text for provenance only — anything the estimate depends on belongs in the typed fields.
 
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a cross-meter ratio (its total is that fraction of a sibling meter's total; for example, the fable meter is half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`); the script propagates estimates through it in both directions automatically.

@@ -32,1 +32,3 @@
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a cross-meter ratio (its total is that fraction of a sibling meter's total; for example, the fable meter is half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`); the script propagates estimates through it in both directions automatically.
+
+The Claude ratio calibrations are empirical cross-meter facts: long, monotonically increasing Prometheus ramps support approximately `weekly = 6 × 5h` for Claude Max 20x accounts (not Max 5x) and `weekly = 8 × 5h` for the Team Premium/VC account. Aggregating the whole ramps makes the two endpoint rounding errors small relative to the movement, so these relative ratios are better constrained than the absolute API-dollar totals. When an absolute dollar estimate conflicts with one of these calibrated ratios, retain the ratio and revise the weaker dollar estimate; the capacity contract and `plans.json` should stay consistent.

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -8,0 +8,4 @@
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }
+      },
+      "weekly-fable": {

@@ -8,0 +21,4 @@
+      "5h": {},
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 8, "of": "5h" }

@@ -360,0 +380,4 @@
+const relationText = (def: RelationDef) => `${def.meter} = ${def.fraction} × ${def.of}`;
+const scaled = (iv: Interval, factor: number): Interval => ({ lo: iv.lo * factor, hi: iv.hi * factor });
+
+for (let iteration = 0; iteration < relationDefs.length * 10 + 1; iteration++) {

@@ -377,0 +421,4 @@
+    if (!other) continue;
+    const text = relationText(def);
+    const implied = scaled(other, factor);
+    const conflict = conflictEdges.has(text) || conflictNodes.has(ownKey);

@@ -379,0 +427,4 @@
+  if (constraints.length === 0) return undefined;
+  const conflict = constraints.some((constraint) => constraint.conflict);
+  const combined = conflict ? null : relationBounds.get(ownKey) ?? own;
+  if (!conflict && !tightens(combined, own)) return undefined;

@@ -30,3 +30,3 @@
 One spending window usually moves several meters at once; record a separate line per meter, sharing `usd`, `at`, and `session`. `note` stays free-text for provenance only — anything the estimate depends on belongs in the typed fields.
 
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without `periodHours` — like `5h` — has no monthly equivalent in this estimator; it may still participate in a `worth` relation, so don't add a made-up period. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a cross-meter ratio (its total is that fraction of a sibling meter's total; for example, the fable meter is half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`). The estimator treats every `worth` entry as a bidirectional interval constraint, intersects all connected relations to a fixed point, and reports `CONFLICT` rather than choosing a relation based on JSON key order. A relation with no measured meters is reported as unvalidated instead of silently affecting an estimate.

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -364,0 +397,4 @@
+    const nextOf = intersect(of, impliedOf);
+    if (!nextMeter || !nextOf) {
+      conflictEdges.add(edgeKey(def));
+      conflictNodes.add(meterKey);

@@ -364,0 +410,4 @@
+    break;
+  }
+}
+if (!converged) fail("worth relations did not reach a fixed point — check plans.json for a contradictory relation cycle");

@@ -377,0 +425,4 @@
+    const other = relationBounds.get(otherKey);
+    if (!other) continue;
+    const text = relationText(def);
+    const implied = scaled(other, factor);

@@ -30,3 +30,3 @@
 One spending window usually moves several meters at once; record a separate line per meter, sharing `usd`, `at`, and `session`. `note` stays free-text for provenance only — anything the estimate depends on belongs in the typed fields.
 
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without `periodHours` — like `5h` — has no monthly equivalent in this estimator; it may still participate in a `worth` relation, so don't add a made-up period. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a cross-meter ratio (its total is that fraction of a sibling meter's total; for example, the fable meter is half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`). The estimator treats every `worth` entry as a bidirectional interval constraint, intersects all connected relations to a fixed point, and reports `CONFLICT` rather than choosing a relation based on JSON key order. A relation with no measured meters is reported as unvalidated instead of silently affecting an estimate.

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -364,0 +395,4 @@
+    const impliedOf = scaled(meter, 1 / def.fraction);
+    const nextMeter = intersect(meter, impliedMeter);
+    const nextOf = intersect(of, impliedOf);
+    if (!nextMeter || !nextOf) {

@@ -364,0 +410,4 @@
+    break;
+  }
+}
+if (!converged) fail("worth relations did not reach a fixed point — check plans.json for a contradictory relation cycle");

@@ -375,2 +424,2 @@
-      return { text: `${def.meter} = ${def.fraction} × ${def.of}`, implied, combined };
-    }
+    const otherKey = nodeKey(plan, def.meter === limit ? def.of : def.meter);
+    const other = relationBounds.get(otherKey);

@@ -377,0 +426,4 @@
+    if (!other) continue;
+    const text = relationText(def);
+    const implied = scaled(other, factor);
+    const conflict = conflictEdges.has(edgeKey(def)) || conflictNodes.has(ownKey);

@@ -54,3 +56,3 @@
 
 - The headline per meter is the estimate under the assumption that the display uses one rounding mode consistently; a 1-point delta yields only a lower bound ("at least $X"). The `mode-agnostic bound` line is the wider interval the data proves without that assumption, and `per-mode` shows each rounding mode's interval (∅ = that mode cannot explain the data), making near-miss eliminations visible. A "Display rounding: data rules out …" header reports which modes the exact-start readings eliminated; the warning that no mode fits means a `startExact` claim is suspect — check with the user whether that window truly began at a reset.
-- `combined with relation` means a declared `worth` relation tightened the estimate beyond the series' own measurements; `measured alone` preserves the unassisted bound. A relation CONFLICT means the relation and the measurements cannot both be right — surface it rather than smoothing over it.
+- `combined with relation` means the fixed-point intersection of all applicable `worth` relations tightened the estimate beyond the series' own measurements; `measured alone` preserves the unassisted bound. When a relation component conflicts or fails to converge, the affected meters fall back to measured bounds. `CONFLICTS` marks an edge whose own measured intervals are disjoint; `SUPPRESSED` means another edge in the same component conflicts, so this edge is not blamed individually. `Unvalidated declared relations` means one or both meters have no measurements, so the ratio is recorded but not yet checked by this tool.

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -377,0 +484,4 @@
+    const other = measuredBounds.get(otherKey);
+    if (!other) continue;
+    const text = relationText(def);
+    const implied = scaled(other, factor);

@@ -455,0 +588,4 @@
+            : constraint.suppressed
+              ? " SUPPRESSED: connected relation component conflicts"
+              : "";
+          const reason = constraint.suppressed ? "another relation in this component conflicts" : "limit change or wrong relation";

@@ -54,3 +56,3 @@
 
 - The headline per meter is the estimate under the assumption that the display uses one rounding mode consistently; a 1-point delta yields only a lower bound ("at least $X"). The `mode-agnostic bound` line is the wider interval the data proves without that assumption, and `per-mode` shows each rounding mode's interval (∅ = that mode cannot explain the data), making near-miss eliminations visible. A "Display rounding: data rules out …" header reports which modes the exact-start readings eliminated; the warning that no mode fits means a `startExact` claim is suspect — check with the user whether that window truly began at a reset.
-- `combined with relation` means a declared `worth` relation tightened the estimate beyond the series' own measurements; `measured alone` preserves the unassisted bound. A relation CONFLICT means the relation and the measurements cannot both be right — surface it rather than smoothing over it.
+- `combined with relation` means the fixed-point intersection of all applicable `worth` relations tightened the estimate beyond the series' own measurements; `measured alone` preserves the unassisted bound. When a relation component conflicts or fails to converge, the affected meters fall back to measured bounds. `CONFLICTS` marks an edge whose own measured intervals are disjoint; `SUPPRESSED` means another edge in the same component conflicts, so this edge is not blamed individually. `Unvalidated declared relations` means one or both meters have no measurements, so the ratio is recorded but not yet checked by this tool.

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -8,0 +16,4 @@
+  },
+  {
+    "plan": "claude-team-premium",
+    "monthlyCostUsd": 125,

@@ -455,0 +586,4 @@
+          const suffix = constraint.conflict
+            ? " CONFLICTS"
+            : constraint.suppressed
+              ? " SUPPRESSED: connected relation component conflicts"

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -8,0 +15,4 @@
+    }
+  },
+  {
+    "plan": "claude-team-premium",

@@ -8,0 +16,4 @@
+  },
+  {
+    "plan": "claude-team-premium",
+    "monthlyCostUsd": 125,

@@ -455,0 +607,4 @@
+              ? `relation component {${meters}} DID NOT CONVERGE; using measured bounds`
+              : relation.componentConflict.reason === "joint"
+                ? `relation component {${meters}} CONFLICTS jointly: no single edge is pairwise disjoint; using measured bounds`
+                : `relation component {${meters}} CONFLICTS: direct edge contradictions are marked below; using measured bounds`;

@@ -32,1 +32,3 @@
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). `monthlyCostUsd` is the monthly-equivalent denominator used for the `× the $X/mo price` output; record whether it is a month-to-month price or an annual-billing per-seat equivalent before comparing plans. The current Team Premium value is a working estimate whose billing basis has not been independently verified. A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without `periodHours` — like `5h` — has no monthly equivalent in this estimator; it may still participate in a `worth` relation, so don't add a made-up period. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a cross-meter ratio (its total is that fraction of a sibling meter's total; for example, the fable meter is half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`). The estimator treats every `worth` entry as a bidirectional interval constraint and intersects each connected component to a fixed point. If a component conflicts or fails to converge, every measured meter in that component falls back to its measured bound. Direct pairwise contradictions are marked `CONFLICTS`; a joint contradiction is reported at the component level and its edges are `SUPPRESSED`, while a non-convergent component is named explicitly. This keeps the result independent of JSON key order. A relation with one or both meters unmeasured is reported as unvalidated instead of silently affecting an estimate.
+
+The Claude ratio calibrations are empirical cross-meter facts: long, monotonically increasing Prometheus ramps from the `j4k/cluster` usage dashboards support approximately `weekly = 6 × 5h` for Claude Max 20x accounts (not Max 5x) and `weekly = 8 × 5h` for the Team Premium/VC account. A ramp is a contiguous reset-free sequence of whole-percent snapshots; aggregating its endpoints makes the two rounding errors small relative to the movement, so these relative ratios are better constrained than the absolute API-dollar totals. The cluster's capacity contract is `group_vars/all/ax_capacity.yml` and its mirrored regression fixture in `tests/test-axcredrouter-capacity-plan-values.py`. The raw Prometheus ramp snapshots are external evidence and are not currently copied into this estimator repository. The bundled Max 20x measurements currently expose a joint conflict: the 6× ramp, the 0.5× fable relation, and the fable readings cannot all be true. Do not edit measurements to force the calibration; preserve the component-level conflict until those three inputs are reconciled, then revise the weaker absolute estimate.

@@ -54,3 +56,3 @@
 
 - The headline per meter is the estimate under the assumption that the display uses one rounding mode consistently; a 1-point delta yields only a lower bound ("at least $X"). The `mode-agnostic bound` line is the wider interval the data proves without that assumption, and `per-mode` shows each rounding mode's interval (∅ = that mode cannot explain the data), making near-miss eliminations visible. A "Display rounding: data rules out …" header reports which modes the exact-start readings eliminated; the warning that no mode fits means a `startExact` claim is suspect — check with the user whether that window truly began at a reset.
-- `combined with relation` means a declared `worth` relation tightened the estimate beyond the series' own measurements; `measured alone` preserves the unassisted bound. A relation CONFLICT means the relation and the measurements cannot both be right — surface it rather than smoothing over it.
+- `combined with relation` means the fixed-point intersection of all applicable `worth` relations tightened the estimate beyond the series' own measurements; `measured alone` preserves the unassisted bound. When a relation component conflicts or fails to converge, the affected meters fall back to measured bounds. `CONFLICTS` marks an edge whose own measured intervals are disjoint; the component headline names those direct edges. `SUPPRESSED` means the edge belongs to a component that is jointly unsatisfiable or did not converge, with no individual edge blamed. `Unvalidated declared relations` means one or both meters have no measurements, so the ratio is recorded but not yet checked by this tool.

@@ -12,1 +15,4 @@
     }
+  },
+  {
+    "plan": "claude-team-premium",

@@ -360,0 +386,4 @@
+
+type RelationComponent = { id: number; defs: RelationDef[]; nodes: Set<string> };
+const relationAdjacency = new Map<string, number[]>();
+for (let index = 0; index < relationDefs.length; index++) {

@@ -447,3 +600,3 @@
     const measured = `${segmentsText(era.refined)}, ${counted(era.measurementCount, "measurement")} in ${counted(era.sessionCount, "session")}, ${span}${suspicion}`;
     if (i === 0 && relation?.combined) {
-      console.log(`  ${label}: ${rangeText(relation.combined)} — combined with relation ${relation.text}`);
+      const relationText = relation.constraints.map((constraint) => constraint.text).join("; ");

@@ -7,1 +7,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -13,0 +16,4 @@
+  },
+  {
+    "plan": "claude-team-premium",
+    "monthlyCostUsd": 125,

@@ -364,0 +434,4 @@
+for (const component of relationComponents) {
+  let componentConflict = false;
+  let converged = false;
+  for (let iteration = 0; iteration < component.defs.length * 10 + 1; iteration++) {

@@ -447,3 +603,3 @@
     const measured = `${segmentsText(era.refined)}, ${counted(era.measurementCount, "measurement")} in ${counted(era.sessionCount, "session")}, ${span}${suspicion}`;
     if (i === 0 && relation?.combined) {
-      console.log(`  ${label}: ${rangeText(relation.combined)} — combined with relation ${relation.text}`);
+      const relationsText = relation.constraints.map((constraint) => constraint.text).join("; ");

@@ -7,1 +8,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -13,0 +18,4 @@
+  {
+    "plan": "claude-team-premium",
+    "monthlyCostUsd": 125,
+    "costBasis": "unverified working estimate",

@@ -447,3 +617,3 @@
     const measured = `${segmentsText(era.refined)}, ${counted(era.measurementCount, "measurement")} in ${counted(era.sessionCount, "session")}, ${span}${suspicion}`;
     if (i === 0 && relation?.combined) {
-      console.log(`  ${label}: ${rangeText(relation.combined)} — combined with relation ${relation.text}`);
+      console.log(`  ${label}: ${rangeText(relation.combined)} — combined with relation component`);

@@ -7,1 +8,3 @@
-      "weekly": { "periodHours": 168 },
+      "weekly": {
+        "periodHours": 168,
+        "worth": { "fraction": 6, "of": "5h" }

@@ -364,0 +444,4 @@
+for (const component of relationComponents) {
+  let componentConflict = false;
+  let converged = false;
+  for (let iteration = 0; iteration < component.defs.length * 10 + 1; iteration++) {

@@ -32,1 +32,3 @@
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd`, optional `costBasis`, and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). `monthlyCostUsd` is the monthly-equivalent denominator used for the `× the $X/mo price` output; `costBasis` travels with that number so comparisons distinguish month-to-month from annual-billing per-seat equivalents. The current Team Premium value is a working estimate whose billing basis has not been independently verified. A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without `periodHours` — like `5h` — has no monthly equivalent in this estimator; it may still participate in a `worth` relation, so don't add a made-up period. A meter's `worth: {"fraction": 0.5, "of": "weekly", "tolerance": 0.02}` declares an approximate cross-meter ratio (the target is within ±2% of that fraction of a sibling meter's total; for example, the fable meter is approximately half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`). The estimator treats every `worth` entry as a bidirectional interval constraint and intersects each connected component to a fixed point. If a component conflicts or fails to converge, every measured meter in that component falls back to its measured bound. Direct pairwise contradictions are marked `CONFLICTS`; a joint contradiction is reported at the component level and its edges are `SUPPRESSED`, while iteration-cap exhaustion is classified as a contradiction with an explicit non-convergence note. This keeps the result independent of JSON key order. A relation with one or both meters unmeasured is reported as unvalidated instead of silently affecting an estimate.
+
+The Claude ratio calibrations are empirical cross-meter facts: long, monotonically increasing Prometheus ramps from the `j4k/cluster` usage dashboards support approximately `weekly = 6 × 5h` for Claude Max 20x accounts (not Max 5x) and `weekly = 8 × 5h` for the Team Premium/VC account. A ramp is a contiguous reset-free sequence of whole-percent snapshots; aggregating its endpoints makes the two rounding errors small relative to the movement, so these relative ratios are better constrained than the absolute API-dollar totals. The cluster's capacity contract is `group_vars/all/ax_capacity.yml` and its mirrored regression fixture in `tests/test-axcredrouter-capacity-plan-values.py`. The raw Prometheus ramp snapshots are external evidence and are not currently copied into this estimator repository. The bundled Max 20x measurements currently expose a joint conflict: the 6× ramp, the 0.5× fable relation, and the fable readings cannot all be true. The bundled 5h lines are annotated `fable-only usage`, while the 6× calibration came from general cluster ramps; if those meters weight fable spend differently, reconcile that provenance before treating the conflict as evidence that a numeric input is wrong. Do not edit measurements to force the calibration; preserve the component-level conflict until those inputs are reconciled, then revise the weaker absolute estimate.

@@ -148,3 +151,4 @@
     if (typeof p.monthlyCostUsd !== "number" || !(p.monthlyCostUsd > 0)) {
       fail(`plans entry ${i}: "monthlyCostUsd" must be a positive number`);
     }
+    if (p.costBasis !== undefined && typeof p.costBasis !== "string") {

@@ -360,0 +388,4 @@
+
+const nodeKey = (plan: string, limit: string) => JSON.stringify([plan, limit]);
+const measuredBounds = new Map<string, Interval>();
+for (const core of cores) measuredBounds.set(nodeKey(core.plan, core.limit), hull(core.eras[0].refined));

@@ -448,2 +638,3 @@
     if (i === 0 && relation?.combined) {
-      console.log(`  ${label}: ${rangeText(relation.combined)} — combined with relation ${relation.text}`);
+      const component = relation.componentMeters ? ` {${relation.componentMeters.join(", ")}}` : "";
+      console.log(`  ${label}: ${rangeText(relation.combined)} — combined with relation component${component}`);

@@ -32,1 +32,3 @@
-`plans.json` describes each plan: its `monthlyCostUsd` and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without one — like `5h`, a throttle whose rate cap is independent of the weekly quotas — deliberately gets no monthly line; don't add a period to one. A meter's `worth: {"fraction": 0.5, "of": "weekly"}` declares a known cross-meter fact (its total is that fraction of a sibling meter's total, e.g. the fable meter is worth half the general weekly limit); the script propagates estimates through it in both directions automatically.
+`plans.json` describes each plan: its `monthlyCostUsd`, optional `costBasis`, and a `meters` registry naming every meter the measurements may reference (an unregistered meter name is a validation error, so typos fail loudly). `monthlyCostUsd` is the monthly-equivalent denominator used for the `× the $X/mo price` output; `costBasis` travels with that number so comparisons distinguish month-to-month from annual-billing per-seat equivalents. The current Team Premium value is a working estimate whose billing basis has not been independently verified. A meter with `periodHours` is a fuel gauge: the script annualizes its value to a monthly equivalent (`value × (365.25/12 × 24) / periodHours`) reported as a multiple of the subscription price. A meter without `periodHours` — like `5h` — has no monthly equivalent in this estimator; it may still participate in a `worth` relation, so don't add a made-up period. A meter's `worth: {"fraction": 0.5, "of": "weekly", "tolerance": 0.02}` declares an approximate cross-meter ratio (the target is within ±2% of that fraction of a sibling meter's total; for example, the fable meter is approximately half the general weekly limit, while a plan can express `weekly = 6 × 5h` with `fraction: 6`). The estimator treats every `worth` entry as a bidirectional interval constraint and intersects each connected component to a fixed point. If a component conflicts or fails to converge, every measured meter in that component falls back to its measured bound. Direct pairwise contradictions are marked `CONFLICTS`; a joint contradiction is reported at the component level and its edges are `SUPPRESSED`, while iteration-cap exhaustion is classified as a contradiction with an explicit non-convergence note. This keeps the result independent of JSON key order. A relation with one or both meters unmeasured is reported as unvalidated instead of silently affecting an estimate.
+
+The Claude ratio calibrations are empirical cross-meter facts: long, monotonically increasing Prometheus ramps from the `j4k/cluster` usage dashboards support approximately `weekly = 6 × 5h` for Claude Max 20x accounts (not Max 5x) and `weekly = 8 × 5h` for the Team Premium/VC account. A ramp is a contiguous reset-free sequence of whole-percent snapshots; aggregating its endpoints makes the two rounding errors small relative to the movement, so these relative ratios are better constrained than the absolute API-dollar totals. The cluster's capacity contract is `group_vars/all/ax_capacity.yml` and its mirrored regression fixture in `tests/test-axcredrouter-capacity-plan-values.py`. The raw Prometheus ramp snapshots are external evidence and are not currently copied into this estimator repository. The bundled Max 20x measurements currently expose a joint conflict: the 6× ramp, the 0.5× fable relation, and the fable readings cannot all be true at the default tolerance. That conflict is sensitivity-tested: it holds through roughly `--usd-tolerance 0.35` but disappears around 0.4% and above, where the relation may tighten the headline; treat that near-consistent result as tolerance-dependent, not as stronger evidence. The bundled 5h lines are annotated `fable-only usage`, while the 6× calibration came from general cluster ramps; if those meters weight fable spend differently, reconcile that provenance before treating the conflict as evidence that a numeric input is wrong. Do not edit measurements to force the calibration; preserve the component-level conflict until those inputs are reconciled, then revise the weaker absolute estimate.

@@ -364,0 +493,4 @@
+  for (const key of component.nodes) {
+    const bound = relationBounds.get(key);
+    const segments = measuredSegments.get(key);
+    if (bound && segments && !segments.some((segment) => intersect(segment, bound))) componentConflict = true;

@@ -375,2 +538,2 @@
-      return { text: `${def.meter} = ${def.fraction} × ${def.of}`, implied, combined };
-    }
+    const otherKey = nodeKey(plan, def.meter === limit ? def.of : def.meter);
+    const other = relationBounds.get(otherKey) ?? measuredBounds.get(otherKey);