IBM Research ventet at GPT-4.1 skulle bli billigere enn Claude Sonnet 4.6. Det motsatte skjedde. Over 417 oppgaver i AppWorld Test Challenge, med samme CodeAct-agent, kostet Sonnet 79 dollar totalt mot GPT-4.1s 155, nesten det dobbelte. På papiret gir det ingen mening: GPT-4.1 har lavere tokenpris på både inn og ut, og Sonnet bruker rundt tre ganger så mange resonneringssteg på de samme oppgavene.
Forklaringen er caching, noe de fleste diskusjoner om routing hopper over. Agent-arbeid gjenbruker store deler av konteksten mellom stegene, og Sonnets lavere pris for cache-lesing slo sterkere ut, nok til å veie opp for både høyere grunnpris og lengre kjøringer.
«Faktisk kostnad avhenger av samspillet mellom modellen, arbeidsmengden og serverinfrastrukturen. En router som bare ser på prislister optimaliserer mot feil tall.» — IBM Research
Poenget deres er at routing ikke egentlig handler om å velge modell, men om å optimalisere systemet. Vanskelighetsgrad er ofte usynlig når ruteren tar valget, og i produksjon må den balansere kostnad, latens, spesialisering og etterlevelse samtidig. IBM sier de sluttet å behandle routing som et klassifiseringsproblem og begynte å se det som et optimaliseringsproblem: én konfigurasjon landet på 84 prosent nøyaktighet for 21 prosent lavere kostnad enn å kjøre Opus alene, med bare 4 prosent lavere treffsikkerhet.
For deg som bygger agenter med flere modeller betyr det at benchmarking må skje på din egen arbeidsmengde med caching på, ikke mot leverandørenes prisark.