Slik bruker du LLM-API-er: tokens, kostnader, nøkler og din første KI-funksjon

Et LLM-API er en nettjeneste som lar appen din sende tekst til en stor språkmodell, for eksempel OpenAIs GPT-modeller, Anthropics Claude eller Googles Gemini, og få svaret tilbake i koden. Du registrerer deg hos leverandøren, lager en API-nøkkel, og serveren i appen din sender forespørsler med den nøkkelen. Du betaler for hver forespørsel etter antall tokens (biter av tekst) som går inn og ut. Det er vanligvis alt som ligger i «å legge til KI i en app»: en godt skrevet forespørsel til noen andres modell, sendt trygt fra serveren din.

Hvorfor det betyr noe når du bygger med KI

Det finnes to ulike KI-er i en KI-bygget app, og det er lett å blande dem sammen:

1. KI-en som bygger appen din: byggeverktøyets egen agent, som skriver koden.
2. KI-en inne i appen din: en funksjon brukerne dine bruker, for eksempel en chatassistent, en «oppsummer dette»-knapp eller automatisk tagging.

Den andre kaller et LLM-API med din nøkkel og belaster din konto hos leverandøren. Å forstå tokens, kontekst og priser er det som gjør at du kan designe en funksjon som fungerer, ikke lekker nøkkelen din og ikke overrasker deg med en regning.

En hverdagslig analogi: en svært dyktig frilanser som betales per ord

Tenk på et LLM-API som en veldig dyktig frilansskribent du når på e-post og betaler per ord. Du betaler både for ordene du sender og for ordene de skriver tilbake, og ordene de skriver koster mer.

• De har ingen hukommelse mellom e-postene. Hvis du vil at samtalen skal fortsette, limer du inn de tidligere meldingene i hver nye e-post.
• De kan bare lese så mye om gangen. Den grensen er kontekstvinduet.
• Jo klarere oppdraget er, desto bedre og kortere blir svaret, og det er også billigere.

De viktigste begrepene

Tokens

Modeller leser og skriver tekst i tokens. Anthropics prisdokumentasjon anslår omtrent 4 tegn, eller rundt 0,75 engelske ord, per token fra september 2026. Ulike modeller og språk tokeniseres forskjellig, så behandle det som et grovt anslag. Alt teller med: instruksjonene dine, brukerens melding, eventuelle dokumenter du tar med, tidligere samtale og svaret.

Input og output

Input-tokens er det du sender. Output-tokens er det modellen skriver. På prissidene til OpenAI, Anthropic og Google, fra september 2026, koster output-tokens flere ganger mer enn input-tokens for samme modell. Googles prising for Gemini påpeker også at modellens interne «tenking» regnes som output.

Kontekstvindu

Det maksimale antallet tokens en modell kan ta imot i én forespørsel, inkludert svaret. Moderne modeller godtar svært lange inputs. Noen av Anthropics nyeste modeller godtar for eksempel opptil en million tokens. Lange inputs koster mer og tar lengre tid, så send bare det oppgaven trenger.

Forespørsler uten tilstand

Med de fleste chat-lignende API-er står hver forespørsel alene som standard. For at en chat skal «huske», sender appen din de tidligere meldingene på nytt med hver ny melding. Derfor koster en lang samtale mer per melding enn en kort.

Systemprompten

Instruksjoner som setter modellens rolle og regler for hver forespørsel: «Du oppsummerer kundehenvendelser i tre punkter. Inkluder aldri kunders e-postadresser.» Brukere ser den ikke, men den former hvert svar.

Streaming

I stedet for å vente på hele svaret, kan API-et sende teksten mens den genereres, slik at brukerne ser ord dukke opp med en gang. Det gjør chatgrensesnitt mye raskere å oppleve.

Slik fungerer prisingen

Fra september 2026, sjekket på leverandørenes egne prissider:

Noen leverandører tilbyr også en måte å prøve før du betaler på. Anthropic gir nye brukere en liten mengde gratis kreditt, og Googles Gemini API har et gratis nivå for enkelte modeller, med det forbeholdet at innhold sendt på det gratis nivået kan brukes til å forbedre Googles produkter.

Prisene varierer mye mellom en leverandørs små, raske modeller og de største, og de endrer seg ofte, så vi oppgir dem ikke her. Et enkelt anslag for en hvilken som helst funksjon er: (input-tokens × inputpris + output-tokens × outputpris) × antall forespørsler per måned. Legg deretter til en margin, og sett en månedlig utgiftsgrense i leverandørens dashbord.

Et eksempel: en «oppsummer henvendelsen»-knapp

Et lite kundeserviceteam vil ha en knapp som gjør en lang e-posttråd fra en kunde om til tre kulepunkter og et forslag til svar.

1. Skaff en nøkkel. Opprett en konto hos én leverandør og lag en API-nøkkel. Sett en lav månedlig utgiftsgrense.
2. Lagre nøkkelen som en hemmelighet på serveren din, med et navn som ANTHROPIC_API_KEY eller OPENAI_API_KEY, aldri i sidens kode. Se miljøvariabler og hemmeligheter.
3. Legg til en serverrute, POST /api/summarise, som:
   • sjekker at personen er innlogget og tilhører kundeserviceteamet;
   • henter henvendelsen fra databasen;
   • sender leverandøren en systemprompt («Oppsummer i tre punkter, og skriv deretter et høflig svarforslag; ikke finn opp ordrenummer») pluss henvendelsesteksten;
   • begrenser lengden på svaret med en innstilling for maksimalt antall output-tokens;
   • returnerer resultatet og logger hvor mange tokens som ble brukt.
4. Knappen kaller ruten din, ikke leverandøren, og viser oppsummeringen mens den strømmes inn.
5. Håndter feil. Hvis leverandøren er treg eller returnerer en feil, vis «Kunne ikke oppsummere akkurat nå» og la henvendelsen være brukbar.
6. Mål. Etter en uke ser du på token-loggene. Hvis det meste av kostnaden kommer fra lange e-posttråder, kutt bort sitert historikk før du sender.

Legg merke til hva som mangler: ingen modelltrening og ingen spesiell infrastruktur. Én nøkkel, én serverrute og én godt skrevet prompt.

Viktige begreper

• API-nøkkel: hemmeligheten som identifiserer kontoen din hos leverandøren. Den som har den, kan bruke pengene dine.
• Modell: den spesifikke LLM-en du kaller. Leverandørene tilbyr flere størrelser til ulike priser og hastigheter.
• Temperatur: en innstilling for hvor variert svarene er. Lavere er mer forutsigbart.
• Maks tokens: en grense for lengden på svaret, som også begrenser kostnaden.
• Hastighetsgrense (rate limit): hvor mange forespørsler eller tokens kontoen din kan bruke per minutt.
• Embeddings: tall som representerer meningen i tekst, brukt til søk i egne dokumenter.
• RAG (retrieval-augmented generation): å finne relevante avsnitt i dine egne data og ta dem med i prompten, slik at modellen svarer ut fra ditt innhold.
• Verktøybruk / funksjonskall: å la modellen be appen din kjøre en bestemt funksjon, for eksempel «slå opp ordrestatus».

Vanlige feil og misforståelser

• Å legge nøkkelen i frontend-koden. Den dyreste feilen. Kode i nettleseren er offentlig. Kall alltid fra serveren din. Sikkerhetssjekklisten for KI-bygget apper dekker dette sammen med de andre sjekkene før lansering.
• Ingen utgiftsgrense eller grenser per bruker. En feil, en løkke eller en misbrukende bruker kan øke kostnadene raskt. Sett en grense hos leverandøren og begrens forespørsler per bruker i appen din.
• Å sende alt hver gang. Hele dokumenter og hele chatlogger multipliserer input-tokens. Kutt ned, oppsummer eldre meldinger, eller hent bare det som er relevant.
• Å stole blindt på output. Modeller kan si feil ting med stor selvsikkerhet. For fakta, priser eller alt juridisk eller medisinsk, forankre svarene i dine egne data og vis kilder, eller la en person kontrollere.
• Å la brukerinput overstyre reglene dine. Brukere kan skrive «ignorer instruksjonene dine». Hold tillatelser og sensitive handlinger i serverkoden din, ikke bare i prompten.
• Å starte med den største modellen. Prøv en mindre, billigere modell først, og gå opp bare hvis kvaliteten krever det.
• Å sende personopplysninger uten å tenke seg om. Sjekk leverandørens vilkår for databruk, særlig på gratis nivåer, og send bare det funksjonen trenger.

Hva du kan be KI-byggeren din om

Legg til en «Oppsummer»-knapp på henvendelsessiden. Den kaller en serverrute som bruker hemmeligheten OPENAI_API_KEY (aldri eksponert for nettleseren), sjekker at brukeren er innlogget, sender henvendelsesteksten med denne systemprompten: […], begrenser svaret til 300 tokens, strømmer svaret til siden og viser en vennlig feilmelding hvis kallet mislykkes. Logg brukte tokens per forespørsel, og begrens hver bruker til 30 oppsummeringer per time.

For en fullstendig chatopplevelse, se slik bygger du en KI-chatbot-app. For andre ideer, se slik legger du til KI-funksjoner i appen din. Hvis API-er generelt er nytt for deg, start med hva et API er.

LLM-API-er i apper bygget med Mythex

Når du bygger med Mythex, bruker KI-en inne i appen din din egen nøkkel fra leverandøren. Du legger den til som en prosjekthemmelighet, eller gjennom hemmelighetskortet Mythex viser i chatten når den trenger en, og ber agenten om å gjøre kallet på serveren. Bruk hos leverandøren faktureres din leverandørkonto, ikke Mythex-byggekreditter. Mythex inkluderer ikke tokens for appens brukere, og heller ikke et innebygd kunnskapsbaseprodukt. Hastighetsgrenser og kostnadskontroll er din å designe og teste. Dokumentasjonsoppskriften legg til KI-funksjoner med egne API-nøkler har en startprompt, og KI-appbyggeren viser hvor du kan begynne.

Spørsmål