**The owner's declaration (2026-08-22, chat, near-verbatim): «Я хочу, чтобы идея эффективной токеномики была центральной для всего VibeVM. Мы манипулируем чудовищно огромным объёмом текста промтов — и мы должны сделать всё, чтобы пользователь платил за них меньше.»** VibeVM's whole subject matter is prompt text at scale: boot lanes, spec corpora, materialised dependencies, worker packets, campaign weaves. Every one of those is tokens the user pays for — so their cost is not an operational detail but a first-class design axis of the system.

**Every architectural choice in VibeVM is evaluated against its token cost to the user.** A feature, a format, a process step, a default — each answers: what does this make the user pay, per session and per agent? A cheaper-by-construction design beats a cheaper-by-discipline one (a law the machinery enforces beats a convention a session remembers). This PROP is the roof; the mechanisms of §4 are the rooms already built under it.

**The cost model the law reasons with.** Provider prompt caching keys on the *byte-identical prefix* of the context: a cache hit reads an order of magnitude cheaper than fresh input and cuts latency; a cache write costs slightly more than plain input; and output tokens are the most expensive class of all. Three consequences order the whole design space: *(a)* stable prefixes are worth engineering for — they convert every repeat load into the cheap class; *(b)* what mutates must sit AFTER what does not, because a single changed byte invalidates everything downstream of it in the prefix; *(c)* screen output is spent at the dearest rate, so chatter is the first thing to cut (the subagent quiet clause and the `auto` interaction mode exist for exactly this).

**Everything is layered by mutation frequency — the whole loaded context is one monotone gradient (owner, 2026-08-23, near-verbatim: «всё в приложении устроено слоями; на самой вершине — динамическая загрузка быстрых изменений»).** Reading order equals stability order: the rarest-changing text reads first, because a change at depth N re-prices every byte after it — the earlier a layer sits, the more cache its mutation burns. The concrete gradient: *(0)* the instruction files (`CLAUDE.md` / `AGENTS.md` / `GEMINI.md`) — read first, so an edit there resets the ENTIRE cache; they carry only what must hit every session (the four rules, the standing directives) and change only for large causes, everything else living in specs loaded later; *(1)* the generated STATIC lane — structural-events-only (§3), and INTERNALLY sorted by the same law: contributions of rarer-changing packages belong earlier in the tape; *(2)* the INDEX manifest and the conditional dynamic lane — per-boot variability; *(3)* the live session tail — task text, tool results, fast state, which lives in context and is never compiled into any lane. This is a GLOBAL architectural idea for all of VibeVM, not a spec of any one mechanism (owner, 2026-08-23): whenever a new system is designed or an existing one changed, the design review checks it against this layering — where does each byte it adds sit on the gradient, and does anything fast-changing sneak ahead of anything slow.

**What STATIC is (the owner's definition, refined): the generated static boot lane is a CACHE-STABLE PREFIX in LLM-economy terms.** It is loaded into an agent or subagent once, at the head of its context, and from then on stays byte-for-byte identical across sessions and spawns — so the provider's prompt cache serves it as a hit and the user never pays full price for the prefix twice. It is compiled, anchor-qualified, self-contained (resolution rules ride inside it), and deliberately front-loaded: the highest priority content reads first precisely because first is where cache stability lives.

**Invalidation is structural only.** STATIC may change when the project's structure changes — the dependency list, dependency versions, the snippet structure of the static lane, the materialisation format (PROP-045 ##STATIC-FOLLOWS-THE-TARGET) — and never for small causes: a status flip, a date, a counter, a session artifact. STATIC is a pure function of structural inputs and NOT a function of the mutable (the adoption registry, statuses, timestamps) — PROP-046 ##LAW-STATIC-INVARIANT is this law's registry-side half. Regenerating with unchanged structural inputs MUST emit identical bytes; that identity is measurable and belongs in the gates.

**The multiplier: one prefix, every agent.** When the boss and all its workers load the SAME byte-identical prefix, the cache warmed by any one of them serves every later spawn — each subagent starts cheap. This makes the stability requirement STRICTER than per-session determinism: nothing per-session and nothing per-agent may enter the prefix — no agent names, no session ids, no roles, no timestamps. Per-agent material belongs after the prefix, in the variable tail.

**The prefix is only a prefix if nothing variable precedes it.** Cache keying is positional: every byte BEFORE the static lane in the loaded context must be as stable as the lane itself (the harness system text, the instruction files' stable head), and everything variable — the dynamic lane, session state, task text — reads strictly AFTER it. A boot order that interleaves mutable material ahead of STATIC forfeits the whole economy regardless of how stable STATIC itself is.

**The build this declaration names (a future wave, on the owner's word).** *(i)* Strip the mutable from the compiled lane — statuses are not compiled into STATIC at all; a fact's current status is a point query (the registry, the dynamic lane), not prefix knowledge. *(ii)* A byte-identity gate: regenerate twice over unchanged structural inputs and diff — zero bytes moved, wired into the panel. *(iii)* A cache-friendliness audit of the generated text (no dates, no unstable ordering, no absolute paths that vary per checkout). The static-splice determinism tests are this wave's seed.

Each of these predates this PROP; the roof names what they share:

Open, deliberately unscheduled; each becomes real work only by the owner's word:

The neighbouring canon this roof spans: [PROP-035](../modules/vibe-workspace/PROP-035-spec-compiler.xml) (the compiled static lane and tree-shaking), [PROP-045](PROP-045-xml-spec-sources.xml) (##STATIC-FOLLOWS-THE-TARGET — the lane's materialisation format), [PROP-046](PROP-046-adoption-facts-registry.xml) (##LAW-STATIC-INVARIANT — the registry never touches the prefix), [PROP-009] (the loading model), the delegation-first flow, and `AGENT-MODE.toml`.