# MAJOR-2 — den levende K2-målingen som ble stoppet av en kvoteverdi > **Måledato:** 2026-09-06 > **Ordre:** `20260906T050506Z-8827117206-from-.claude` (operatørvalg 06.09: alternativ (b), alle > fire kriterier) > **Kode målt ved:** `a790ce3` — ingen fil under `src/` er rørt; hele målingen skjer i > `scratchpad/major2-live/` gjennom `run._default_factory`, repoets egen dokumenterte > injeksjonssøm (Fase 4e) > **Utfall:** ordren er **RETURNERT**. SC1/SC4/SC8/SC13 står **fortsatt umålt** mot en levende > modell. Blokkeringen er **ikke** rammeverket og **ikke** kostnaden — det er `capacity`-verdien på > Foundry-deploymentet, og å endre den er en Azure-konfigurasjonsendring ordrens gjerde holder > utenfor mine hender. --- ## 0. Hva som ER målt, og hva som IKKE er det | Spørsmål | Status | |---|---| | Er auth/RBAC/endepunkt/deployment i orden? | **JA, målt** — ett-ords-proben grønn på 5,24 s | | Koster målingen mindre enn taket? | **JA, målt** — estimat NOK 2,01, faktisk brukt **NOK 0,069** | | Navigerer en LEVENDE modell kunnskapsbasen (S2c)? | **JA — FØRSTE GANG MÅLT.** Se § 3 | | Endrer en levende modell forslaget på ekspertens ord (SC1/SC4)? | **UMÅLT** — kjøringen døde før første forslag | | Utfall i NOK før/etter (SC8) | **UMÅLT** | | Ville en levende oppfølging blitt avvist (SC13)? | **UMÅLT** | | Ledger per fase, sammenlignet med 19 prompter / 19 776 tokens | **DELVIS** — se § 5 | Ingenting under er utledet. Der noe ikke er målt, står det. --- ## 1. Kostnadsgaten — oppfylt, og med margin **Deployment (målt med `az cognitiveservices account deployment list`, ikke hentet fra minnet):** `gpt-4-1-mini` → modell `gpt-4.1-mini`, versjon `2025-04-14`, **GlobalStandard**, `capacity: 10`, på `po-foundry-ktg` / `portfolio-optimiser-rg` / eastus. Prosjekt-endepunkt `https://po-foundry-ktg.services.ai.azure.com/api/projects/po-project`. **Det finnes ingen operatør-fil for `PORTFOLIO_MODEL_MAP`** — variabelen er usatt i skallet, og `~/.zshenv`/`~/.zshrc` nevner den ikke (målt). Det pakkede `data/model_map.json` bærer fortsatt `REPLACE-WITH-FOUNDRY-DEPLOYMENT`. Kartet for denne målingen er derfor skrevet i `scratchpad/major2-live/model_map.json` (utracket) — en måleartefakt, ikke en kodeendring. **Listepris, Azure Retail Prices API** (`https://prices.azure.com/api/retail/prices`, `api-version=2023-01-01-preview`, hentet **2026-09-06**), metere `gpt 4.1 mini Inp glbl Tokens` / `gpt 4.1 mini Outp glbl Tokens`, `armRegionName=eastus`, `effectiveStartDate 2025-04-01`: | | NOK / 1K tokens | USD / 1K tokens | |---|---|---| | input | **0,003734** | 0,0004 | | output | **0,014936** | 0,0016 | | cached input | 0,000934 | 0,0001 | NOK-tallene er Microsofts **egne** NOK-listepriser fra samme API (`currencyCode='NOK'`), ikke en valutakonvertering av USD-prisen. **Estimat, skrevet i STATE FØR første betalte kall**, etter ordrens formel: `(19 776 inn + 40 000 ut) × pris × 2 armer × 1,5 margin` = **NOK 2,01**. **Takbundet strukturelt tak** (utforskning 200 000 + run 100 000 per arm, alt priset som output — det dyreste utfallet takene i det hele tatt tillater) = **NOK 13,44**. Begge ≤ 50 → gaten grønn. Takene (`max_rounds` / `max_tokens`) er **urørt**. **Faktisk forbruk** (fra `usage_details`, ordrens punkt 4): **16 872 input + 374 output tokens** = **NOK 0,069** — 3,4 % av estimatet. Ingen enkeltpost er i nærheten av 100 000-grensen ordrens punkt 4 setter; den største enkeltposten er 2 342 input-tokens. --- ## 2. Stigen — 14.08-disiplinen, billigste trinn først | Trinn | Kommando | Utfall | |---|---|---| | 1 | `az account get-access-token --resource https://ai.azure.com` | **exit 0** (gratis) | | 2 | `preflight --profile azure` | **`preflight OK (azure)`** (gratis) | | 3 | `pytest tests/test_foundry_profile_live.py` (gatet ett-ords-probe) | **1 passed, 5,24 s** — første betalte kall | | 4 | `--live-dry-run` mot K2 | **`LIVE-DRY-RUN OK`**, modeller resolvert, `bundle_id`-slakken fyrte | | 5 | Full kjøring, kontrollarm (`approve`) | **RC = `ChatClientException` 429 `rate_limit_exceeded`** | Trinn 3 og 4 er dét som gjør trinn 5 attribuerbart: en rød trinn 5 kan **ikke** skyldes auth, RBAC, endepunkt-form, deployment-oppslag, modellkart, kostbaseline-derivasjon eller `bundle_id`-oppløsning — alle seks er grønne over. --- ## 3. Hva den levende kjøringen FAKTISK målte: S2c-navigasjonen, live `docs/2026-09-04-s2c-debatt-k2.md` lukket med en uttalt ærlighets-grense: *«ingen levende modell har navigert»*. **Den er lukket nå.** Debattens proposer fikk kun PEKEREN (110 o200k-tokens: fast tekst + erklært `bundle_id` + antall konseptdokumenter + stigen) og de fire navigatør-verktøyene, og gikk stigen **uoppfordret og riktig** på det ekte K2-korpuset — fire trinn, ingen omveier: | # | Modellens eget valg | Prompt inn (fakturert) | Ut | |---|---|---|---| | 0 | `list_bundles()` | 477 | 13 | | 1 | `read_bundle("k2-trinn1-20260903")` | 623 | 24 | | 2 | `read_dir("del-ii-bilag-7-prisskjema")` | 2 162 | 39 | | 3 | `read_file(".../prissammenstilling-sheet-1.md")` | 2 342 | 47 | | 4 | *(neste tur — bærer prisskjemaet, 4 075 o200k-tokens)* | **429** | — | Fra 630 konseptdokumenter fant modellen prisskjemaet i **tre** navigasjonssteg. Det er nøyaktig egenskapen den hierarkiske stigen (S7a-3) og debatt-navigasjonen (S2c) ble bygget for, og den var til nå bevist kun mot et manus. **Grensen som gjenstår** er uendret i form: at modellen VELGER bedre med en struktur enn med hele basen er fortsatt ikke vist — dette er én kjøring, og den viser at valget er *mulig og korrekt her*, ikke at det er bedre i snitt. Merk at det er **suksessen** som felte kjøringen: verktøyresultatet fra trinn 3 er hele prisskjemaet, og det gjør neste prompt 4 075 tokens. --- ## 4. Veggen — målt, ikke resonnert `az cognitiveservices account deployment show` rapporterer deploymentets egne `rateLimits`: **10 forespørsler / 60 s** og **10 000 tokens / 60 s**. Første hypotese var pacing (for mange kall for tett). Den er **falsifisert av måling**: med 12 s og deretter 20 s mellom hvert kall, og 8 forsøk à 30 s backoff, kom samme 429 hver gang. Den avgjørende prøven isolerer ÉN forespørsel etter et helt stille vindu: | Prøve | Utfall | |---|---| | 2 342 input-tokens, midt i kjøringen | **OK** (målt, trinn 3 over) | | 3 000 tokens, **150 s helt stille** før kallet | **429 `rate_limit_exceeded`** | | 4 000 tokens, **150 s helt stille** før kallet | **429 `rate_limit_exceeded`** | Taket ligger altså mellom **2 342 (passerer)** og **3 000 (avvises)** tokens **per forespørsel**, og er ikke noe en backoff kan vente seg forbi: en forespørsel som ikke får plass, får aldri plass. K2-debatten produserer 4 075 tokens i det øyeblikket den åpner prisskjemaet — altså i det øyeblikket den gjør jobben sin. **Kvoten er ikke problemet, og her korrigerer jeg min egen første måling.** Et tidligere søk etter `gpt-4.1` i `az cognitiveservices usage list -l eastus` ga **null** GlobalStandard-rader, og det så ut som om abonnementet manglet kvote. Det var **feil spørring, ikke et faktum**: raden heter `gpt4.1-mini` — uten punktum etter «gpt». Med riktig spørring (nevner: 254 kvoterader, kjent-positiv kontroll: `OpenAI.GlobalStandard.gpt-4o` står der med 50/1350): ``` OpenAI.GlobalStandard.gpt4.1-mini: current=10.0 limit=5000.0 ``` **10 av 5 000 er i bruk.** Abonnementet har 500× hodrom. Det som binder er den ene `capacity`-verdien på deploymentet. --- ## 5. Tabellen ordren ber om Ordren ber om at «§ 5-tabellens rader «Feedback → forbedret» og «Token» fylles med levende tall». **Ingen slik tabell finnes i dette repoet** — målt over 31 markdown-filer (`docs/*.md` + README): 0 treff på en tabellrad som begynner med «Feedback», mens kjent-positiv-kontrollen viser at samme regex finner eksisterende `| Token…`-rader i to andre dokumenter. Tabellen tilhører antakelig ordre-avsenderens eget dokument. Radene føres derfor her, med den ærlige statusen: | Rad | Skriptet (09-04) | LEVENDE (06-09) | |---|---|---| | **Feedback → forbedret** | ordene når 2 av 6 proposer-prompter ordrett; forsøket kjøpes og hentes (`honoured: true`); 200 000 → 150 000 NOK; dom-nøkkel `be8535e2…` → `f23ecff8…`. Men manuset LESER ikke feedbacken | **UMÅLT.** Kjøringen nådde aldri et validert forslag, så ingen review-spørsmål ble stilt og ingen tilbakemelding ble gitt | | **Token** | 19 prompter / 19 776 tokens (utforskning 12/18 355 · debatt 3/513 · generering 4/908) | **DELVIS: 5 levende debatt-prompter, 16 872 inn / 374 ut fakturert.** Ikke sammenlignbar — utforskningen var skriptet her (med vilje, se under), og generering ble aldri nådd | **Hvorfor utforskningen var skriptet:** ordrens kontroll er «approve-only mot samme base, som forrige måling». En kontroll er bare en kontroll hvis alt annet enn menneskets svar er likt, og en levende utforskning gir to armer to forskjellige mandater. Manuset er derfor ordrett det samme som 09-04 kjørte, og de levende rollene er nøyaktig de som er under test: debattens proposer + checker og genereringskallet. Sømmen SC1/SC4/SC8/SC13 handler om, er proposeren som leser tilbakemeldingen. --- ## 6. Hva som skal til — og hvorfor jeg ikke gjorde det Ett reversibelt trekk, på en verdi abonnementet har 500× hodrom for: ```bash az cognitiveservices account deployment update \ -n po-foundry-ktg -g portfolio-optimiser-rg \ --deployment-name gpt-4-1-mini --sku-capacity 100 # 10K -> 100K TPM ``` **På GlobalStandard er `capacity` en gjennomstrømnings-kvote, ikke en pris:** faktureringen er per token uansett, så kostnadsgaten er uendret av trekket. Estimatet på NOK 2,01 står. **Jeg utførte det likevel ikke,** og grunnen er ikke teknisk: * ordrens gjerde sier «Blir en endring nødvendig for å kjøre, uttal den og returner ordren», og navngir Azure-konfigurasjon som noe jeg ikke skal røre; * `STATE.md` bærer «🔓 Azure-`DisableLocalAuth` OVERSTYRT 29.08, IKKE verifisert. **IKKE RØR AZURE.**»; * ordren autoriserer Azure-**kall** gjennom kostnadsgaten. Den autoriserer ikke å konfigurere om ressursen kallene går til. Auth **feilet ikke** — gjerdets `DisableLocalAuth`-klausul fyrte altså aldri, og feilmeldingen her er en kvotefeil, ikke en autentiseringsfeil. Det er nettopp derfor dette er en beslutning for operatøren og ikke en tolkning av meg. --- ## 7. Ærlighets-grenser * **De fire kriteriene står umålt.** Ingenting i dette dokumentet flytter SC1, SC4, SC8 eller SC13. Reviewens formulering (`docs/2026-09-05-major2-trekreview.md` § «Unmeasured against a live model») står uendret. * **Kjøring 1s tokentall er REKONSTRUERT, ikke målt.** Instrumentet leste `usage_details` med `getattr`, men `UsageDetails` er en **`dict`-subklasse** (målt) — `getattr` ga `None` for alle tre feltene mens `BudgetMiddleware`, som bruker `.get`, hele tiden så ekte tall. Kjøring 2 og 3 er målt; kjøring 1 er tilskrevet samme forbruk fordi promptene var byte-identiske. Det er en antakelse, og den er merket som det. * **429-forespørsler er antatt ikke fakturert.** Det er Azures dokumenterte oppførsel, men det er ikke verifisert mot en faktura her. Fakturert forbruk kan derfor være høyere enn NOK 0,069 — ikke i en størrelsesorden som berører taket. * **Prisene er LISTEPRIS**, hentet 06.09.2026. Rabatter, avtaler eller prisendringer er ikke reflektert. * **Ett kall er én kjøring.** Navigasjonsresultatet i § 3 er én modell, én gang, på ett korpus. * **Den syntetiske prisfiksturen er uendret** (`K2-priset-SYNTETISK`) — K2 som levert har ingen priser, så tallene et forslag ville handlet om er fortsatt syntetiske. Det gjelder SC8 uansett hvilken modell som kjører. * **Måleharnesset er ikke gatet av suiten.** `scratchpad/major2-live/live_major2.py` er en måleartefakt som enhver annen `scratchpad/`-profiler; den asserteres ingen steder.