Billige kinesiske AI-API’er kan blive dyre ved tung kodeudvikling

En model kan være billig pr. token og samtidig dyr pr. udvikler. Det er ikke en selvmodsigelse, men et spørgsmål om to forskellige produkter: Et API afregnes løbende for hver token, mens et kodeabonnement giver brugeren en mere afgrænset udgift, så længe brugen holder sig inden for abonnementets regler.

For en autonom kodeagent, der igen og igen gennemgår et repository, tager meget kontekst med og genererer omfattende svar, er det afgørende spørgsmål derfor ikke kun: Hvilken model har den laveste tokenpris? Det er også: Hvornår stopper den marginale udgift for brugeren, og kan planen reelt håndtere arbejdsbelastningen?

En lav tokenpris har stadig ingen udgiftsgrænse

GLM-5.2 er opført til 1,40 dollar pr. mio. inputtokens, 0,26 dollar pr. mio. cachede inputtokens og 4,40 dollar pr. mio. outputtokens. 1 Priserne kan være attraktive ved almindelig API-brug, men ved meget store mængder bliver regnestykket hurtigt et andet:

• 1 mia. ikke-cachede inputtokens: 1.400 dollar
• 1 mia. cachede inputtokens: 260 dollar
• 1 mia. outputtokens: 4.400 dollar

Det sidste tal er særligt vigtigt for kodeagenter. Agenten læser ikke bare kode og dokumentation; den producerer også planer, ændringer, test, forklaringer, værktøjskald og nye iterationer. En arbejdsgang med et stort output kan derfor blive langt dyrere, end en overskrift med lav inputpris antyder.

Cache kan ændre resultatet betydeligt. Genbrugt kontekst afregnes til den lavere pris for cachede input, men slutregningen afhænger fortsat af den konkrete fordeling mellem ikke-cachet input, cachet input og output. 1

Hvorfor den virale sammenligning af dagspriser kræver flere oplysninger

En omtalt sammenligning har sat GLM-5.2 API-brug til omkring 7.800 yuan om dagen mod en langt lavere fast ugentlig udgift for et Codex-abonnement. Sammenligningen peger på en reel forskel mellem forbrugsafregning og en abonnementsbaseret kvote, men påstanden om tokenvolumen kræver forbehold.

Ved GLM-5.2’s offentliggjorte priser ville titals milliarder ikke-cachede inputtokens alene koste titusinder af dollar om dagen. Output i den størrelsesorden ville koste væsentligt mere. 1 En regning på 7.800 yuan pr. dag kan derfor i stedet afspejle en lavere effektiv afregningsmængde, en høj andel cachede input, en bestemt input/output-fordeling, rabatpriser eller et andet prisgrundlag.

Den praktiske konklusion er enkel: Samlede tokenantal er ikke nok. Ved sammenligning af en kodearbejdsgang bør man måle:

1. ikke-cachede inputtokens,
2. cachede inputtokens,
3. outputtokens,
4. abonnementets nulstillingsvinduer og grænser samt
5. om overskridelse udløser betalt forbrug.

Abonnementer lægger loft over udgiften – ikke nødvendigvis over forbruget

Et abonnement gør ikke inferens gratis. Det flytter derimod en del af variationen i omkostningerne fra brugeren til udbyderen.

På en fast månedlig kodeplan kan en bruger med høj, men tilladt, belastning få API-ækvivalent brug, der overstiger, hvad abonnementsprisen isoleret set ville købe via et afregnet endpoint. Brugeren får et mere forudsigeligt budget, mens udbyderen håndterer risikoen med rullende tidsvinduer, hastighedsgrænser, prioritetsregler, credits og andre fair-use-kontroller.

Derfor kan et dyrere API eksistere side om side med et forholdsvis attraktivt kodeabonnement. API-prisen er den direkte marginalpris på beregning. Abonnementet er et samlet tilbud med begrænsninger, der kan være acceptable for mange, men som ikke er en garanti for ubegrænset kapacitet.

Kodeplaner kan fortsat være stærkt målerstyrede

Den afgørende skelnen går ikke mellem kinesiske og udenlandske modeller. Den går mellem et åbent tokenmeter, en creditpung og en tilstrækkeligt rummelig kvote med nulstillinger.

GLM Coding Plan har udtrykkeligt to begrænsninger: en rullende pointkvote over fem timer og en ugentlig pointkvote. De offentliggjorte grænser er blandt andet 12.000 point pr. fem timer og 60.000 point ugentligt for Pro samt 28.000 og 140.000 for Max. Forbruget beregnes ud fra input-, cachede input- og outputtokens med modelspecifikke koefficienter. 2

Qoder er endnu tydeligere om sin creditstruktur. De betalte niveauer omfatter 2.000, 6.000 eller 20.000 månedlige credits til premiummodeller. Når credits er opbrugt, skifter Qoder brugeren til en basismodel med et begrænset antal beskeder. Qoder oplyser også, at de inkluderede premiummodelressourcer svarer til abonnementsværdien plus eventuelle bonusressourcer. 17

For en udvikler, der kører hyppige og langvarige agentopgaver, kan sådanne ordninger derfor føles mindre som et abonnement med fri brug og mere som forudbetalt forbrug pakket ind i en månedlig betaling.

Spidsbelastningsmultiplikatorer gør kapacitetsgrænsen synlig

Kvotegrænser er ikke den eneste begrænsning. Udbydere kan også ændre, hvor hurtigt en abonnements kvote bruges i travle perioder.

Z.ai’s nuværende dokumentation angiver, at GLM-5.3 bruger kvote med multiplikatoren 1× uden for spidsbelastning og 3× i spidsbelastning. GLM-5.3-Flash er angivet til henholdsvis 0,4× og 1,2×. 4 GLM Coding Plans oversigt angiver desuden et spidsbelastet hverdagsvindue kl. 14.00–18.00, UTC+8. 2

Det er en mekanisme til kapacitetsstyring: Den månedlige abonnementspris ændres ikke, men mængden af arbejde, som kvoten dækker, kan falde i travle timer. Reglen bør ikke automatisk overføres til alle GLM-5.2-planer eller perioder; kontrollér altid vilkårene for den konkrete plan.

Hvad dokumentationen viser – og ikke viser – om adgangsproblemer

Beretninger om udsolgte dagskvoter, mindre GLM-5.2-adgang, kort cacheopbevaring, svag batching på tværs af brugere og udbyderspecifikke inferensflaskehalse kan være plausible, men de er ikke alle dokumenteret i materialet her.

Den tilgængelige primære dokumentation underbygger klart kvoteloft, tokenvægtet pointafregning og tidsbestemte multiplikatorer. 24 Den bekræfter derimod ikke i sig selv en bestemt udbyderforklaring på hvert påstået adgangsproblem. Ved indkøb bør udviklere derfor se uformelle rapporter som signaler, der skal afprøves, ikke som fastslåede kendsgerninger.

En praktisk evaluering bør tage udgangspunkt i teamets egen arbejdsgang – og foregå på de tidspunkter, hvor teamet arbejder. Repositoriets størrelse, cacheadfærd, outputlængde, samtidige agenter, køtid og planens fallback-adfærd betyder mere end én markedsført tokenpris.

Købsreglen for teams med tung AI-kodning

Billige kinesiske API’er er fortsat attraktive til let eller forudsigelig inferens, især når arbejdsgangen kan genbruge cachet kontekst. 1 De kan være et stærkt valg for teams, der ønsker direkte API-kontrol og kan styre tokenbudgettet tæt.

Men intensiv AI-kodning er et andet indkøbsproblem. Hvis en agent bruger store, vedvarende mængder kapacitet, er den bedste løsning ofte den, der kombinerer:

• et forudsigeligt månedligt udgiftsloft,
• en kvote, der holder til almindelige arbejdsdage,
• klare regler for nulstilling og overforbrug,
• stabil adgang i travle perioder og
• nok kapacitet til parallelle opgaver.

Kort sagt: Sammenlign effektivt brugbart arbejde pr. måned – ikke kun API’ets listepris. En billig, afregnet model vinder, når forbruget er under kontrol. Et abonnement vinder kun, hvis begrænsningerne er gennemsigtige og store nok til udviklerens reelle agentarbejde.