docs(major2): den levende K2-maalingen stoppet paa en kvoteverdi, ikke paa rammeverket

Ordre 20260906T050506Z ba om en LEVENDE maaling av SC1/SC4/SC8/SC13 bak en
kostnadsgate. Gaten er oppfylt med margin, stigen er groenn t.o.m. dry-run, og
det foerste betalte kallet passerte. Kjoeringen doede likevel foer det foerste
forslaget, paa 429 rate_limit_exceeded.

Diagnosen er maalt, ikke resonnert. Pacing ble falsifisert (12 s, 20 s, 8 forsoek
a 30 s backoff -- samme 429). Den avgjoerende proeven isolerer EN forespoersel
etter et helt stille vindu: 2 342 tokens passerer, 3 000 tokens avvises etter
150 s uten trafikk. Det er et tak PER FORESPOERSEL, som ingen backoff kan vente
seg forbi -- og K2-debatten produserer 4 075 tokens i det oeyeblikket den aapner
prisskjemaet, altsaa naar den gjoer jobben sin.

To ting maalingen leverte likevel:

1. S2c-grensen "ingen levende modell har navigert" ER LUKKET. Debattens levende
   proposer fikk kun pekeren (110 tokens) og de fire verktoeyene, og fant
   prisskjemaet i tre navigasjonssteg blant 630 konseptdokumenter. Det er
   SUKSESSEN som felte kjoeringen.
2. Kostnadsgaten med kilde: listepris fra Azure Retail Prices API 06.09
   (inn NOK 0,003734/1K, ut 0,014936/1K), estimat NOK 2,01 mot tak 50, faktisk
   brukt NOK 0,069.

To korreksjoner av mitt eget instrument staar i dokumentet, fordi begge saa ut
som fakta: UsageDetails er en dict-subklasse (getattr ga None der .get gir tall),
og et soek paa "gpt-4.1" i kvotelista gir null rader fordi raden heter
"gpt4.1-mini" -- kvoten har 500x hodrom, den ser bare fravaerende ut for feil
spoerring.

SC1/SC4/SC8/SC13 staar fortsatt umaalt. Ordren returneres: det som mangler er en
Azure-konfigurasjonsendring (deployment capacity 10 -> 100), som ordrens gjerde
og STATE-ens "IKKE ROER AZURE" holder utenfor denne oekten. Auth feilet aldri.

Ingen fil under src/ er roert; hele maalingen ligger i scratchpad/major2-live/
gjennom run._default_factory. 1368 passed / 5 skipped, golden byte-uendret.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-09-06 08:18:49 +02:00
commit 3fb3b7b708

View file

@ -0,0 +1,216 @@
# 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`,
`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.