# Erfaring: Modell-benchmark (mars 2026)

## Testoppsett

**Oppgave:** Kodegjennomgang av `synops-transcribe` (441 linjer Rust).
Prompt: "Hva gjør verktøyet? Er det bugs? Hva kan forbedres? Maks 300 ord."

**Modeller:** Haiku 4.5, Sonnet 4.6, Opus 4.6
**Effort:** Medium (default) for alle tre
**Kontekst:** Alle modeller fikk CLAUDE.md (~200 linjer prosjektinstruksjoner)

## Resultater

| Modell | Tid | Ord | Bugs funnet | Kvalitet |
|--------|-----|-----|-------------|----------|
| **Haiku 4.5** | 16s | ~230 | 3 | God. Fant batch-insert, hardkodet timeout, resource logging. Én feil-positiv (metadata NULL). |
| **Sonnet 4.6** | 28s | ~250 | 3 | Bedre. Fant transaksjonsgap (DELETE utenfor tx), i32 overflow, manglende retry. |
| **Opus 4.6** | 24s | ~240 | 3 | Best. Fant transaksjonsgap + hele-filen-i-minne + content-overskriving. Mest presise vurdering. |

## Analyse

### Haiku
- **Styrke:** Rask. Finner overfladiske problemer pålitelig.
- **Svakhet:** Finner ikke transaksjonsgapet (den viktigste buggen).
  Foreslår forbedringer som er riktige men åpenbare.
- **Egnet for:** Triage, enkel kodesjekk, "er dette åpenbart feil?"

### Sonnet
- **Styrke:** Finner transaksjonsgapet. God balanse mellom dybde og fart.
- **Svakhet:** Noe lengre enn nødvendig. Nevner ting som er
  "uproblematisk i CLI-bruk" (reqwest::Client) — korrekt men
  ikke actionable.
- **Egnet for:** Daglig bruk. Kodegjennomgang, chat-svar, oppsummering.

### Opus
- **Styrke:** Finner alt Sonnet finner + hele-filen-i-minne-problemet
  (streaming vs buffer). Mest presist prioritert — viktigste bug først.
  Nevner content-overskriving som et designspørsmål, ikke bare en bug.
- **Svakhet:** Tar omtrent like lang tid som Sonnet for dette omfanget.
  Marginalgevinsten er reell men liten for enkel kode.
- **Egnet for:** Validering, arkitekturgjennomgang, kompleks analyse.

## Effort-observasjoner

Full 3×3-matrise (model × effort) ble forsøkt men feilet pga
ressurskonkurranse (6+ samtidige Claude-instanser på 16GB server).

Fra den initielle testen uten effort-prefix (medium):
- Haiku med "vær ekstremt grundig"-prefix fant ikke flere bugs
  enn uten — modellens kapasitet er begrensningen, ikke effort.
- Opus med "svar kort"-prefix ville sannsynligvis fortsatt funnet
  transaksjonsgapet — modellens innsikt er ikke avhengig av ordmengde.

**Hypotese:** Effort-nivå påvirker *ordmengde og grundighet* mer enn
*funnkvalitet*. Modellvalg er den avgjørende faktoren for
dybde. Effort styrer overflaten.

## Anbefaling for Synops

| Oppgave | Modell | Effort | Begrunnelse |
|---------|--------|--------|-------------|
| @bot chat-svar | Sonnet | medium | God nok for daglig bruk |
| Orkestrering (standardsteg) | Haiku | low | Mekanisk dispatch, trenger ikke dybde |
| Orkestrering (feilhåndtering) | Sonnet | medium | Resonnering om uventet situasjon |
| Kodegjennomgang (PR) | Sonnet | high | Grundig men ikke overkill |
| Validering (fase 23) | Opus | high | Må finne subtile bugs |
| Arkitekturanalyse | Opus | high | Designspørsmål krever dybde |
| Triage / klassifisering | Haiku | low | Rask, billig, god nok |
| Work item fra chat | Haiku | low | Bare fang opp og kategoriser |

## Kostnadsimplikasjon

Haiku er ~20× billigere enn Opus per token. For et system med
100 daglige @bot-interaksjoner:

| Strategi | Estimert dagskostnad |
|----------|---------------------|
| Alt med Opus | ~$15-25/dag |
| Alt med Sonnet | ~$3-5/dag |
| Smart routing (anbefalt) | ~$1-2/dag |

Smart routing: Haiku for 70% (triage, enkel chat), Sonnet for
25% (normal chat, orkestrering), Opus for 5% (validering,
arkitektur). Auto-eskalering med ↑-knappen for resten.

## Merk

- Alle modeller fikk full CLAUDE.md som kontekst (~200 linjer).
  For Haiku er dette en relativt stor andel av vinduet.
- Testen ble kjørt med task runner (23.1) aktiv — noe ressurs-
  konkurranse kan ha påvirket timingen.
- Én test per modell er ikke statistisk signifikant. Resultatene
  er indikasjoner, ikke fasit.