Sådan bruger du LLM-API'er: tokens, omkostninger, nøgler og din første AI-funktion

Et LLM-API er en webtjeneste, der lader din app sende tekst til en stor sprogmodel — som OpenAI's GPT-modeller, Anthropics Claude eller Googles Gemini — og få svaret tilbage i kode. Du tilmelder dig udbyderen, opretter en API-nøgle, og din apps server sender forespørgsler med den nøgle; du bliver faktureret for hver forespørgsel efter antallet af tokens (stykker tekst) der går ind og kommer ud. Det er alt, hvad „at tilføje AI til en app“ normalt betyder: en velskrevet forespørgsel til en andens model, sendt sikkert fra din server.

Hvorfor det betyder noget, når du bygger med AI

Der er to forskellige AI'er i en app bygget med AI, og det er let at blande dem sammen:

1. AI'en der bygger din app — appbyggerens egen agent, som skriver koden.
2. AI'en inde i din app — en funktion dine brugere bruger, som en chat-assistent, en „opsummér dette“-knap eller automatisk tagging.

Den anden kalder et LLM-API med din nøgle og fakturerer din udbyderkonto. At forstå tokens, kontekst og priser er det, der gør det muligt at designe en funktion, der virker, ikke lækker din nøgle og ikke overrasker dig med en regning.

En hverdagsanalogi: en meget dygtig freelancer, betalt pr. ord

Tænk på et LLM-API som en brillant freelance-skribent, du når via e-mail og betaler pr. ord — både for ordene du sender dem og for ordene de skriver tilbage (og ordene de skriver koster mere).

• De har ingen hukommelse mellem e-mails. Hvis du vil have dem til at fortsætte en samtale, indsætter du de tidligere beskeder i hver ny e-mail.
• De kan kun læse så meget ad gangen. Den grænse er kontekstvinduet.
• Jo tydeligere din opgave er, desto bedre og kortere svar — hvilket også er billigere.

De centrale begreber

Tokens

Modeller læser og skriver tekst i tokens. Anthropics prisdokumentation anslår cirka 4 tegn, eller nogenlunde 0,75 engelske ord, pr. token fra september 2026. Forskellige modeller og sprog tokeniserer forskelligt, så betragt det som en grov retningslinje. Alt tæller med: dine instruktioner, brugerens besked, eventuelle dokumenter du medsender, tidligere samtale og svaret.

Input og output

Input-tokens er det du sender. Output-tokens er det modellen skriver. På prissiderne hos OpenAI, Anthropic og Google koster output-tokens, fra september 2026, flere gange mere end input-tokens for samme model. Googles Gemini-priser oplyser også, at modellens interne „tænkning“ tæller som output.

Kontekstvindue

Det maksimale antal tokens en model kan modtage i én forespørgsel, inklusive svaret. Moderne modeller accepterer meget lange input — nogle af Anthropics nuværende modeller accepterer for eksempel op til en million tokens. Men lange input koster mere og tager længere tid, så send kun det opgaven kræver.

Tilstandsløse forespørgsler

Med de fleste chat-lignende API'er står hver forespørgsel alene som standard. For at få en chat til at „huske“, sender din app de tidligere beskeder igen med hver ny. Derfor koster en lang samtale mere pr. besked end en kort.

System-prompten

Instruktioner der sætter modellens rolle og regler for hver forespørgsel: „Du opsummerer supportsager i tre punkter. Inkluder aldrig kunders e-mailadresser.“ Brugerne ser den ikke, men den former hvert svar.

Streaming

I stedet for at vente på det fulde svar kan API'et sende tekst, mens den genereres, så brugerne ser ord dukke op med det samme. Det får chatgrænseflader til at føles meget hurtigere.

Sådan fungerer priserne

Fra september 2026, tjekket på udbydernes egne prissider:

Nogle udbydere tilbyder også en måde at prøve før du betaler: Anthropic giver nye brugere en lille mængde gratis kredit, og Googles Gemini API har et gratis niveau på nogle modeller, med forbeholdet at indhold sendt på det kan bruges til at forbedre Googles produkter.

Priserne varierer meget mellem en udbyders små, hurtige modeller og deres største, og de ændrer sig ofte, så vi angiver dem ikke her. Et simpelt estimat for enhver funktion er: (input-tokens × inputpris + output-tokens × outputpris) × antal forespørgsler pr. måned. Tilføj derefter en margen, og sæt en månedlig udgiftsgrænse i udbyderens dashboard.

Et konkret eksempel: en „opsummér denne sag“-knap

Et lille supportteam vil have en knap, der omdanner en lang kunde-e-mailtråd til tre punkter og et forslag til svar.

1. Hent en nøgle. Opret en konto hos én udbyder og generér en API-nøgle. Sæt en lav månedlig udgiftsgrænse.
2. Gem nøglen som en hemmelighed på din server, navngivet noget som ANTHROPIC_API_KEY eller OPENAI_API_KEY — aldrig i sidens kode. Se miljøvariabler og hemmeligheder.
3. Tilføj en serverrute, POST /api/summarise, der:
   • kontrollerer at personen er logget ind og tilhører supportteamet;
   • henter sagen fra databasen;
   • sender udbyderen en system-prompt („Opsummer i tre punkter, og skriv derefter et høfligt svarudkast; opfind ikke ordrenumre“) plus sagsteksten;
   • begrænser svarets længde med en indstilling for maksimalt antal output-tokens;
   • returnerer resultatet og logger hvor mange tokens der blev brugt.
4. Knappen kalder din rute, ikke udbyderen, og viser opsummeringen, mens den streames ind.
5. Håndtér fejl. Hvis udbyderen er langsom eller returnerer en fejl, vis „Kunne ikke opsummere lige nu“ og lad sagen forblive brugbar.
6. Mål. Efter en uge, kig på token-logs. Hvis det meste af omkostningen skyldes lange e-mailtråde, så skær citeret historik ned før afsendelse.

Bemærk hvad der mangler: ingen modeltræning, ingen særlig infrastruktur. Én nøgle, én serverrute og én velskrevet prompt.

Vigtige begreber

• API-nøgle: hemmeligheden der identificerer din konto hos udbyderen. Enhver der har den, kan bruge dine penge.
• Model: den specifikke LLM du kalder. Udbydere tilbyder flere størrelser til forskellige priser og hastigheder.
• Temperatur: en indstilling for hvor varierede svarene er. Lavere betyder mere forudsigeligt.
• Max tokens: en grænse for svarets længde, som også begrænser omkostningen.
• Rate limit: hvor mange forespørgsler eller tokens din konto må bruge pr. minut.
• Embeddings: tal der repræsenterer betydningen af tekst, brugt til søgning i dine egne dokumenter.
• RAG (retrieval-augmented generation): at finde relevante passager i dine egne data og medtage dem i prompten, så modellen svarer ud fra dit indhold.
• Tool use / function calling: at lade modellen bede din app om at køre en bestemt funktion, som „slå ordrestatus op“.

Almindelige fejl og misforståelser

• At putte nøglen i frontend-kode. Den dyreste fejl. Browserkode er offentlig. Kald altid fra din server. Sikkerhedstjeklisten for apps bygget med AI dækker dette sammen med andre lanceringstjek.
• Ingen udgiftsgrænse eller grænser pr. bruger. En fejl, en løkke eller en misbrugende bruger kan hurtigt løbe op i omkostninger. Sæt en grænse hos udbyderen, og begræns forespørgsler pr. bruger i din app.
• At sende alt hver gang. Hele dokumenter og fulde chat-historikker ganger input-tokens. Skær ned, opsummér ældre beskeder, eller hent kun de relevante dele.
• At stole blindt på output. Modeller kan fremsætte forkerte ting med selvsikkerhed. Ved fakta, priser eller alt juridisk eller medicinsk, så forankr svarene i dine egne data og vis kilder, eller lad en person kontrollere.
• At lade brugerens input overstyre dine regler. Brugere kan skrive „ignorér dine instruktioner“. Hold tilladelser og følsomme handlinger i din serverkode, ikke kun i prompten.
• At starte med den største model. Prøv en mindre, billigere model først; gå op kun hvis kvaliteten kræver det.
• At sende personlige data uden eftertanke. Tjek udbyderens vilkår for databrug, især på gratis niveauer, og send kun det funktionen har brug for.

Hvad du skal bede din AI-byggeværktøj om

Tilføj en „Opsummér“-knap på sagssiden. Den kalder en serverrute, der bruger hemmeligheden OPENAI_API_KEY (aldrig eksponeret for browseren), kontrollerer at brugeren er logget ind, sender sagsteksten med denne system-prompt: […], begrænser svaret til 300 tokens, streamer svaret til siden og viser en venlig fejlbesked, hvis kaldet mislykkes. Log brugte tokens pr. forespørgsel, og begræns hver bruger til 30 opsummeringer i timen.

Til en fuld chatoplevelse, se sådan bygger du en AI-chatbot-app; for andre idéer, sådan tilføjer du AI-funktioner til din app. Hvis API'er i det hele taget er nye for dig, så start med hvad et API er.

LLM-API'er i apps bygget med Mythex

Når du bygger med Mythex, bruger AI'en i din app din egen udbyder-nøgle. Du tilføjer den som en projekthemmelighed, eller via hemmelighedskortet Mythex viser i chatten, når den har brug for en, og beder agenten om at lave kaldet på serveren. Udbyderforbrug faktureres på din udbyderkonto, ikke på Mythex-byggekredit. Mythex inkluderer ikke tokens til din apps brugere eller et indbygget vidensbaseprodukt, og rate limits og omkostningskontrol er dit at designe og teste. Docs-opskriften tilføj AI-funktioner med dine egne API-nøgler har en startprompt, og AI-appbyggeren-siden viser hvor du kan begynde.

Spørgsmål