portfolio-optimiser/docs/2026-09-06-major2-levende-k2.md

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å <resource> / <resource-group> / eastus. Prosjekt-endepunkt https://<resource>.services.ai.azure.com/api/projects/<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:

az cognitiveservices account deployment update \
  -n <resource> -g <resource-group> \
  --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.