Den 11 augusti 2026 öppnade Mistral AI sin plattform för modeller som företaget inte har byggt själv. Första gästen är Z.ai:s GLM-5.2, en öppen textmodell med ett kontextfönster på en miljon tokens som nu körs på Mistrals europeiska infrastruktur. För dig som utvecklare betyder det att du kan anropa en kinesisk toppmodell genom samma API-nyckel, samma faktura och samma regionval som du redan använder för Mistral Large 3 eller Medium 3.5. I den här guiden bygger vi en fungerande AI-agent med GLM-5.2 via Mistrals Chat Completions-API, steg för steg: från konto och första anrop till function calling, strukturerad utdata, en agent-loop och ett driftsatt FastAPI-API. Du behöver ingen egen GPU och inget separat konto hos Z.ai. Allt sker genom Mistral.
Vad är nytt: Mistral öppnar plattformen för tredjepartsmodeller
Mistral AI har hittills byggt sin plattform kring egna modeller: Mistral Large 3, Mistral Medium 3.5, Ministral och specialmodeller som Shieldstral. I augusti 2026 ändrades det. Mistral formulerade det själv i tillkännagivandet: “To that end, we’re expanding our platform to third-party open models, starting with Z.ai’s GLM-5.2.” Med andra ord öppnar Mistral nu plattformen för modeller bolaget inte byggt, med GLM-5.2 som första exempel.
I praktiken innebär draget att GLM-5.2 dyker upp som en vanlig modell i Mistrals API-dokumentation, anropbar via samma /v1/chat/completions-slutpunkt som resten av utbudet. Modellsträngen du skickar i fältet model är zai-glm-5-2. Enligt Mistrals modellsida, senast uppdaterad 22 september 2026, beskrivs den som en tredjepartsmodell med öppna vikter, byggd av Z.ai och hostad av Mistral för lång kontext, kodning och agent-flöden.
Det som gör nyheten relevant för en svensk publik är regionvalet. Mistral har länge marknadsfört europeisk datahantering som ett skäl att välja bolaget framför amerikanska eller kinesiska alternativ. Genom att hosta GLM-5.2 på samma infrastruktur, med samma regionkontroller som Mistrals egna modeller, kan ett svenskt företag testa en öppen kinesisk modell utan att skicka data till Kina eller USA. Priset för GLM-5.2 på Mistral ligger på 1,40 dollar per miljon indata-tokens och 4,40 dollar per miljon utdata-tokens, enligt Mistrals prisdokumentation, uppdaterad samma dag som modellsidan.
Draget säger också något om var branschen är på väg. OpenAI och Google bygger sina plattformar kring egna, stängda modeller. Mistral gör tvärtom och lutar sig mot att GLM-5.2 har öppna vikter, det som Mistrals dokumentation kallar en “open weight text model”. I praktiken betyder öppna vikter att modellen i teorin går att ladda ner och köra på egen infrastruktur också, men för de allra flesta svenska team är den vägen orealistisk. Att köra en modell i den storleksklassen kräver flera kraftfulla GPU-kluster och ett drifteam som sköter uppdateringar och säkerhetspatchar dygnet runt. Att i stället anropa samma modell genom Mistrals API, med Mistrals regionkontroller, fakturering och sammanslagna gränssnitt, är det praktiska valet för alla utom de största bolagen.
Varför bygga en AI-agent med GLM-5.2 just nu
Det korta svaret är kombinationen av kontextstorlek, verktygsstöd och pris. Mistrals egen dokumentation beskriver modellen kort och tydligt: “A third-party open weight text model from Z.ai, hosted by Mistral for long-context coding and agentic workflows.” Det är precis den kombinationen, lång kontext plus agentuppgifter, som gör modellen intressant för en tutorial som denna.
Kontextfönstret ligger på 1 000 000 tokens och maxutdata på 128 000 tokens per svar, enligt samma modellsida. Det räcker för att skicka in ett helt kontrakt, en kodbas eller en lång supportlogg i ett enda anrop, utan att chunka texten manuellt. Modellen stöder dessutom function calling och strukturerad utdata direkt via Chat Completions, vilket gör den lämplig som motor i en agent som ska slå upp priser, boka möten eller granska kod.
Prismässigt hamnar GLM-5.2 mellan Mistrals egna modeller. Mistral Large 3 kostar 0,50 dollar per miljon indata-tokens och 1,50 dollar per miljon utdata-tokens. Medium 3.5 kostar 1,50 dollar in och 7,50 dollar ut. GLM-5.2 landar på 1,40 dollar in och 4,40 dollar ut, med en cachad indata-rabatt ner till 0,14 dollar per miljon. Det gör modellen dyrare än Large 3 men klart billigare än Medium 3.5 på utdata, samtidigt som kontextfönstret är avsevärt större än båda. Vi går igenom hela kostnadsbilden i tabellen längre ner i artikeln.
En rimlig fråga är varför inte bara anropa GLM-5.2 direkt hos Z.ai i stället för att gå via Mistral. Z.ai:s egen prissida listar samma modell till samma pris, 1,40 dollar in och 4,40 dollar ut per miljon tokens, så själva token-kostnaden skiljer sig inte. Skillnaden ligger i infrastrukturen runt omkring. Går du via Mistral får du en enda faktura för alla modeller du använder, samma nyckelhantering, samma regionval mellan Europa och USA, och samma rate-limit-system som resten av kontot. Går du direkt till Z.ai får du ett separat konto, en separat faktura och egna villkor för dataskydd att sätta dig in i. För ett svenskt team som redan står med ett Mistral-konto för Large 3 eller Medium 3.5 är det sällan värt besväret att hantera ännu en leverantör bara för att komma åt GLM-5.2.
Förkunskaper och verktyg du behöver
Du behöver inte vara AI-expert för att följa guiden, men grundläggande Python-vana underlättar. Här är vad som krävs innan du börjar.
| Verktyg | Version eller krav | Varför du behöver det |
|---|---|---|
| Python | 3.11 eller senare | Kör exemplen och den officiella SDK:n |
| pip | Senaste versionen | Installerar mistralai och fastapi |
| Mistral-konto | Gratis, Studio-läge | Krävs för API-nyckel, inget kort behövs för att komma igång |
| Terminal / skal | bash, zsh eller PowerShell | Köra curl-anrop och skript |
| Editor | VS Code eller motsvarande | Skriva och läsa Python-kod |
| Docker | senaste stabila versionen | Bygga och köra agenten som container i steg 12 |
| curl | ingår i de flesta system | Snabb test av API:et utan kod |
Räkna med cirka 90 minuter totalt om du följer stegen i ordning, inklusive tid för att läsa igenom output och felsöka enstaka anrop. De första fem stegen går snabbt. Agent-loopen och driftsättningen mot slutet tar mest tid.
Kör en snabb kontroll innan du går vidare: python3 --version ska visa 3.11 eller högre, och pip show mistralai ska visa ett installerat paket utan felmeddelande. På Windows är det vanligaste problemet att python pekar mot en gammal systeminstallation snarare än den virtuella miljön, kontrollera det med where python innan du fortsätter. På macOS med Apple Silicon fungerar samma kommandon rakt av, eftersom SDK:t bara pratar HTTP och inte kräver någon lokal GPU eller native-kompilering.
Steg 1 och 2: Skapa konto, API-nyckel och installera SDK
Gå till Mistral Studio och skapa ett konto om du inte redan har ett. Studio startar i gratisläge utan krav på kreditkort, enligt Mistrals egen quickstart-dokumentation. När du är inloggad, gå till fliken API keys och klicka på Create new key. Namnge nyckeln, till exempel glm-agent-tutorial, och kopiera den direkt. Nyckeln visas bara en gång.
Spara nyckeln som en miljövariabel i stället för att klistra den direkt i koden. Installera därefter det officiella Python-biblioteket och sätt upp en projektmapp.
mkdir glm-mistral-agent && cd glm-mistral-agent
python3 -m venv venv
source venv/bin/activate
pip install mistralai fastapi uvicorn
export MISTRAL_API_KEY="din-api-nyckel-här"
På Windows i PowerShell byter du sista raden till $env:MISTRAL_API_KEY="din-api-nyckel-här". Basadressen för Mistrals API är https://api.mistral.ai/v1, men om du använder det officiella SDK:t behöver du aldrig skriva ut den själv.
Steg 3: Skicka din första förfrågan till zai-glm-5-2
Skapa en fil som heter first_call.py och skriv följande. Modellnamnet du ska använda i fältet model är exakt zai-glm-5-2, det namnet Mistral har registrerat modellen under.
import os
from mistralai import Mistral
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
response = client.chat.complete(
model="zai-glm-5-2",
messages=[
{
"role": "user",
"content": "Förklara på svenska, i tre meningar, vad "
"function calling innebär för en AI-agent."
}
],
)
print(response.choices[0].message.content)
print("Tokens använda:", response.usage.total_tokens)
Kör filen med python first_call.py. Ett typiskt svar ser ut ungefär så här, med undantag för att den exakta formuleringen varierar mellan körningar:
Function calling gör att en AI-agent kan begära att ett externt
verktyg körs, till exempel en prisuppslagning eller en kalender,
i stället för att bara generera text. Modellen returnerar ett
strukturerat anrop med funktionsnamn och argument som ditt program
tolkar och kör. Resultatet skickas sedan tillbaka till modellen,
som formulerar ett svar baserat på den nya informationen.
Tokens använda: 187
Om anropet fungerar har du bekräftat att kontot, nyckeln och SDK:n är korrekt konfigurerade. Går det inte, se felsökningsavsnittet längre ner innan du fortsätter.
Steg 4: Bygg en konversation med minne
En riktig agent behöver komma ihåg tidigare turer i samtalet. Chat Completions-API:et är statslöst, vilket betyder att du själv måste skicka in hela meddelandehistoriken vid varje anrop. Så länge du håller dig inom kontextfönstret på en miljon tokens är det sällan ett problem för GLM-5.2.
import os
from mistralai import Mistral
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
history = [
{"role": "system", "content": "Du är en hjälpsam svensk assistent."}
]
def ask(user_text: str) -> str:
history.append({"role": "user", "content": user_text})
response = client.chat.complete(model="zai-glm-5-2", messages=history)
reply = response.choices[0].message.content
history.append({"role": "assistant", "content": reply})
return reply
print(ask("Jag heter Sam och bygger en supportbot."))
print(ask("Vad var det jag sa att jag bygger?"))
Andra anropet ska korrekt svara “en supportbot” eftersom hela historiken, inklusive systemmeddelandet, skickas med varje gång. Spara historiken i en databas eller session-store om agenten ska köras i produktion med flera samtidiga användare.
Steg 5: Aktivera function calling för verktygsanrop
Function calling är det som gör en språkmodell till en agent i praktiken. Du beskriver ett eller flera verktyg som funktioner med namn, beskrivning och parametrar. Modellen väljer själv om och när den vill anropa dem.
tools = [
{
"type": "function",
"function": {
"name": "hamta_lagerstatus",
"description": "Hämtar lagerstatus för en produkt i svenskt lager",
"parameters": {
"type": "object",
"properties": {
"artikelnummer": {"type": "string"}
},
"required": ["artikelnummer"]
}
}
}
]
response = client.chat.complete(
model="zai-glm-5-2",
messages=[{"role": "user", "content": "Finns artikel SE-2291 i lager?"}],
tools=tools,
tool_choice="auto",
)
call = response.choices[0].message.tool_calls[0]
print(call.function.name, call.function.arguments)
Körningen ger normalt ett svar i stil med hamta_lagerstatus {"artikelnummer": "SE-2291"}. Ditt program tolkar det, kör den riktiga funktionen mot lagersystemet och skickar tillbaka resultatet till modellen som ett meddelande med rollen tool, så att den kan formulera ett slutgiltigt svar till användaren. Enligt Mistrals dokumentation om function calling stöds mönstret rakt av på hela plattformen, inklusive tredjepartsmodeller som GLM-5.2.
Steg 6: Strukturerad utdata med JSON-schema
Ibland vill du inte ha ett verktygsanrop, bara ett garanterat JSON-svar som passar din datamodell rakt av, till exempel för att fylla ett formulär eller spara i en databas. GLM-5.2 stöder strukturerad utdata via parametern response_format.
schema = {
"type": "json_schema",
"json_schema": {
"name": "supportarende",
"schema": {
"type": "object",
"properties": {
"kategori": {"type": "string"},
"prioritet": {"type": "string", "enum": ["låg", "medel", "hög"]},
"sammanfattning": {"type": "string"}
},
"required": ["kategori", "prioritet", "sammanfattning"]
}
}
}
response = client.chat.complete(
model="zai-glm-5-2",
messages=[{"role": "user", "content":
"Kunden skriver: fakturan kom aldrig fram och betalningen är försenad."}],
response_format=schema,
)
print(response.choices[0].message.content)
Svaret blir giltig JSON som matchar schemat rakt av, till exempel {"kategori": "fakturering", "prioritet": "hög", "sammanfattning": "Kund har inte fått faktura, betalning försenad"}. Det gör det säkert att koppla modellen direkt till en databas eller ett ärendehanteringssystem utan fragil textparsning.
Validera ändå svaret på riktigt innan du sparar det, till exempel med Pydantic i Python. Ett schema som skickas till modellen är en instruktion, inte en absolut garanti, och en extra valideringsrunda i din egen kod kostar nästan ingenting jämfört med att en felaktig post når produktionsdatabasen. Om valideringen misslyckas, logga hela svaret och skicka en enklare uppföljningsfråga i stället för att låta hela flödet krascha för slutanvändaren.
Steg 7: Utnyttja miljontokens-kontextfönstret för dokumentanalys
Den stora fördelen med GLM-5.2 jämfört med många konkurrenter är kontextfönstret på 1 000 000 tokens. Det motsvarar grovt räknat flera hundra sidor text i ett och samma anrop, beroende på hur tätt innehållet är skrivet. I praktiken kan du skicka in en hel kravspecifikation, en längre kodbas eller ett års supportloggar utan att dela upp texten i mindre bitar.
with open("kravspecifikation.txt", "r", encoding="utf-8") as f:
dokument = f.read()
response = client.chat.complete(
model="zai-glm-5-2",
messages=[
{"role": "system", "content": "Du analyserar tekniska dokument på svenska."},
{"role": "user", "content": f"Här är dokumentet:\n\n{dokument}\n\n"
"Lista alla krav som rör datalagring i Sverige."}
],
)
print(response.choices[0].message.content)
Tänk på två saker innan du skickar in stora dokument rakt av. Först: du betalar per token, så ett anrop med 500 000 tokens indata kostar ungefär 0,70 dollar redan innan modellen svarat. För det andra: maxutdata är satt till 128 000 tokens, vilket räcker för de flesta sammanfattningar men inte för att modellen ska skriva tillbaka hela dokumentet ordagrant plus kommentarer.
Har du dokument som ändå överstiger en miljon tokens, till exempel en hel kodbas med flera hundra tusen rader, behöver du fortfarande dela upp arbetet. En vanlig lösning är att först låta modellen indexera dokumentet i mindre bitar och skriva en kort sammanfattning av varje del, och sedan skicka in enbart de sammanfattningarna tillsammans med den specifika delen som frågan handlar om. Det är mer arbete att bygga, men det håller kostnaden nere jämfört med att försöka pressa in allt i ett enda jättelikt anrop varje gång.
Steg 8: Bygg en enkel agent-loop med verktyg och resonemang
En riktig agent anropar ofta flera verktyg i följd innan den ger ett slutgiltigt svar. Mönstret kallas ibland ReAct: modellen resonerar, väljer ett verktyg, får resultatet, resonerar igen, och fortsätter till den har ett svar den är säker på.
import json
def kor_agent(fraga: str, tools: list, funktioner: dict, max_varv: int = 5) -> str:
messages = [{"role": "user", "content": fraga}]
for _ in range(max_varv):
response = client.chat.complete(
model="zai-glm-5-2",
messages=messages,
tools=tools,
tool_choice="auto",
)
meddelande = response.choices[0].message
messages.append(meddelande)
if not meddelande.tool_calls:
return meddelande.content
for call in meddelande.tool_calls:
namn = call.function.name
argument = json.loads(call.function.arguments)
resultat = funktioner[namn](**argument)
messages.append({
"role": "tool",
"tool_call_id": call.id,
"name": namn,
"content": json.dumps(resultat),
})
return "Nådde maxantal varv utan slutgiltigt svar."
Funktionen tar en fråga, en verktygslista och en ordbok som mappar funktionsnamn till riktiga Python-funktioner. Så länge modellen fortsätter be om verktyg fortsätter loopen. Gränsen på fem varv finns för att undvika en agent som fastnar i en oändlig cykel av verktygsanrop, vilket annars snabbt blir kostsamt.
Exempel: en svensk supportagent från fråga till svar
För att se hela flödet i praktiken, säg att du bygger en supportagent för ett svenskt e-handelsbolag. Agenten ska kunna svara på frågor om leveransstatus och samtidigt eskalera ärenden som handlar om pengar. Du definierar två verktyg: ett som slår upp en order i ordersystemet och ett som skapar ett prioriterat ärende i ärendehanteringssystemet. Funktionerna kopplas till kor_agent från steg 8 via ordboken funktioner.
En kund skriver: “Var är order 88213? Jag betalade för express och det har gått fem dagar.” Modellen resonerar i sitt första varv och bestämmer att den behöver slå upp ordern innan den kan svara. Den anropar hamta_orderstatus med argumentet {"ordernummer": "88213"}. Ditt program kör den riktiga uppslagningen mot databasen och skickar tillbaka resultatet, till exempel att paketet ligger kvar i lager på grund av ett lagerfel. I nästa varv ser modellen att förseningen bryter mot det utlovade leveransvillkoret för express, och den anropar det andra verktyget, skapa_arende, med prioritet satt till “hög” och en sammanfattning av problemet. Först i det tredje varvet, när båda verktygen har svarat, formulerar modellen ett slutgiltigt svar till kunden och loopen avslutas eftersom tool_calls då är tom.
Ett typiskt slutsvar till kunden kan se ut ungefär så här: “Jag ser att din order 88213 är försenad på grund av ett lagerfel. Jag har skapat ett prioriterat ärende (referens SE-4471) så att en kollega kontaktar dig inom kort med kompensation för den uteblivna expressleveransen.” Hela resonemanget, uppslagningen och eskaleringen skedde inom ett enda anrop till kor_agent, utan att någon människa behövde koppla ihop stegen manuellt.
Steg 9 och 10: Felhantering, rate limits och kostnadsbudget
Mistral tillämpar rate limits per organisation, med separata gränser för antal förfrågningar per sekund och antal tokens per minut. Gränserna varierar beroende på prenumerationsnivå och modell. Överskrider du dem får du ett svar med statuskod 429. Svarshuvudet X-RateLimit-Remaining visar hur mycket kapacitet som är kvar innan nästa gräns nås.
import time
from mistralai.models import SDKError
kostnad_hittills = 0.0
PRIS_IN = 1.40 / 1_000_000
PRIS_UT = 4.40 / 1_000_000
BUDGET = 5.00
def sakert_anrop(messages, forsok: int = 3):
global kostnad_hittills
if kostnad_hittills >= BUDGET:
raise RuntimeError("Sessionens budget är slut")
for i in range(forsok):
try:
response = client.chat.complete(model="zai-glm-5-2", messages=messages)
kostnad_hittills += response.usage.prompt_tokens * PRIS_IN
kostnad_hittills += response.usage.completion_tokens * PRIS_UT
return response
except SDKError as e:
if "429" in str(e) and i < forsok - 1:
time.sleep(2 ** i)
continue
raise
Funktionen räknar ihop den faktiska kostnaden efter varje anrop baserat på GLM-5.2:s pris och stoppar agenten innan den spränger en satt budget. Exponentiell backoff, där väntetiden dubblas för varje nytt försök, är den vanligaste metoden för att hantera tillfälliga 429-svar utan att ge upp direkt.
Om du märker att gratisnivån i Mistral Studio börjar bli en begränsning, till exempel för en agent med många samtidiga användare, finns högre prenumerationsnivåer med egna gränser för förfrågningar per sekund och tokens per minut. Mistral beskriver även en Priority Tier med anpassade rate limits och en egen upptidsgaranti för team som behöver garanterad kapacitet snarare än bästa förmåga. Innan du uppgraderar är det värt att först se om orsaken till 429-svaren går att lösa i koden, till exempel genom att köa anrop eller sprida ut dem över tid, i stället för att direkt betala för en högre nivå.
Steg 11 och 12: Paketera som FastAPI-tjänst och driftsätt med Docker
Sista biten är att göra agenten anropbar från en webbapp eller ett annat system. FastAPI passar bra eftersom den är lätt och redan installerad från steg 2.
# main.py
import os
from fastapi import FastAPI
from pydantic import BaseModel
from mistralai import Mistral
app = FastAPI()
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
class Fraga(BaseModel):
text: str
@app.post("/fraga")
def fraga_agenten(inmatning: Fraga):
response = client.chat.complete(
model="zai-glm-5-2",
messages=[{"role": "user", "content": inmatning.text}],
)
return {
"svar": response.choices[0].message.content,
"tokens": response.usage.total_tokens,
}
Lägg till en Dockerfile för att göra tjänsten portabel:
FROM python:3.11-slim
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir mistralai fastapi uvicorn
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
Bygg och kör med docker build -t glm-agent . följt av docker run -e MISTRAL_API_KEY=din-nyckel -p 8000:8000 glm-agent. Testa med curl -X POST localhost:8000/fraga -d '{"text":"Hej, funkar detta?"}' -H "Content-Type: application/json". Nu har du en komplett, driftbar AI-agent byggd på GLM-5.2 via Mistral, från konto till container. Vill du köra den bakom en riktig domän räcker det att sätta en omvänd proxy, till exempel Caddy eller Nginx, framför containern och peka en subdomän mot port 8000.
Säkerhet: skydda nyckeln och begränsa vad agenten får göra
En AI-agent med function calling kan i praktiken utföra handlingar, inte bara svara på frågor. Det höjer kraven på hur du hanterar både API-nyckeln och verktygen du kopplar in. Lägg aldrig nyckeln i kod som checkas in i ett gitförråd. Använd miljövariabler lokalt och en riktig hemlighetshantering, till exempel en secrets manager hos din molnleverantör, i produktion.
Begränsa dessutom vad varje verktyg faktiskt får göra på backend-sidan, oberoende av vad modellen ber om. Om skapa_arende anropas med en prioritet som inte finns i din enum, avvisa anropet i din egen kod innan det når databasen, lita inte på att modellen alltid skickar giltiga värden bara för att schemat säger det. Samma logik gäller för verktyg som rör pengar eller personuppgifter: sätt hårda gränser i backend-koden, som ett maxbelopp för automatiska återbetalningar, så att ett felaktigt eller manipulerat modellsvar aldrig kan orsaka en verklig ekonomisk skada. Det är samma princip som gäller för alla system som tar emot indata från en extern part, agenten är i grunden ett gränssnitt som kan luras precis som ett formulär på en webbsida kan det.
Mät kvalitet: bygg ett litet testdataset innan lansering
Innan agenten går live bör du mäta hur den faktiskt beter sig, inte bara testa den manuellt med ett par exempelfrågor. Ett litet testdataset med 20 till 50 verkliga eller verklighetstrogna frågor, tillsammans med det svar eller den verktygsanrop du förväntar dig, räcker långt för att fånga uppenbara regressioner innan de når kund.
testfall = [
{"fraga": "Var är order 88213?", "forvantat_verktyg": "hamta_orderstatus"},
{"fraga": "Jag vill avboka mitt konto", "forvantat_verktyg": "skapa_arende"},
{"fraga": "Vad är era öppettider?", "forvantat_verktyg": None},
]
trafftrat = 0
for fall in testfall:
svar = kor_agent(fall["fraga"], tools, funktioner)
anropat_verktyg = None # läs ut från loggen i en riktig implementation
if anropat_verktyg == fall["forvantat_verktyg"]:
trafftrat += 1
print(f"Träffsäkerhet: {trafftrat}/{len(testfall)}")
Kör samma testdataset varje gång du ändrar en systemprompt, ett verktygsschema eller byter modellversion. Om träffsäkerheten sjunker efter en ändring vet du direkt, i stället för att upptäcka det via kundklagomål några dagar senare. Mät också svarstiden per anrop, eftersom en agent som tar 30 sekunder att svara känns trasig för en användare även om svaret i sig är korrekt.
Vanliga fallgropar när du bygger med GLM-5.2 på Mistral
- Att glömma att modellnamnet är exakt zai-glm-5-2. Ett vanligt misstag är att skriva glm-5.2 eller GLM-5.2 rakt av. API:et kräver den exakta strängen med bindestreck och gemener.
- Att skicka hela historiken i onödan. Chat Completions är statslöst, men det betyder inte att du ska skicka tio tusen tidigare meddelanden vid varje anrop. Klipp historiken när samtalet växer, annars ökar kostnaden linjärt.
- Att blanda ihop cachad och icke-cachad indata i kostnadsberäkningen. Den låga cachepriset på 0,14 dollar per miljon gäller bara upprepad, identisk kontext. Ny text debiteras alltid till full indata-taxa.
- Att lita på strukturerad utdata utan att validera den. Modeller kan i sällsynta fall returnera JSON som tekniskt bryter mot schemat om prompten är otydlig. Validera alltid svaret med ett riktigt bibliotek innan du sparar det.
- Att köra agent-loopen utan tak på antal varv. Utan en gräns kan en agent fastna i att anropa samma verktyg om och om igen, vilket i värsta fall kan generera en oväntat hög faktura över natten.
- Att anta att regional inferens är gratis. Att välja en specifik region för bearbetning innebär enligt Mistrals prissida ett påslag på 10 procent jämfört med standardpriset.
- Att hårdkoda modellnamnet på för många ställen. Lägg modellsträngen i en konfigurationsfil eller miljövariabel i stället för att sprida ut
zai-glm-5-2i tio olika filer. Den dagen Mistral lanserar en efterföljare vill du bara behöva ändra på ett ställe.
Felsökning: vanliga problem och lösningar
| Problem | Trolig orsak | Lösning |
|---|---|---|
| 401 Unauthorized | Fel eller saknad API-nyckel | Kontrollera att MISTRAL_API_KEY är satt i samma skal som du kör skriptet från |
| 404 model not found | Felstavat modellnamn | Använd exakt zai-glm-5-2, kontrollera mot Mistrals modellsida |
| 429 Too Many Requests | Rate limit nådd för din nivå | Läs X-RateLimit-Remaining och lägg in exponentiell backoff |
| Tom respons från tool_calls | Verktyget beskrevs otydligt i schemat | Gör funktionsbeskrivningen och parameternamnen mer explicita |
| Ogiltig JSON i strukturerad utdata | Schema för löst definierat eller prompten motsägelsefull | Lägg till required-fält och tydligare enum-värden i schemat |
| Anropet tar mycket lång tid | Väldigt stor indata nära miljontokensgränsen | Dela upp dokumentet eller sänk hur mycket kontext som skickas per anrop |
| Oväntat hög faktura | Agent-loop utan gräns på antal varv | Sätt max_varv och en hård kostnadsbudget per session, som i steg 9 |
| SDK-fel vid import | Fel pip-paket eller gammal Python-version | Kör pip install --upgrade mistralai och kontrollera att Python är 3.11 eller senare |
| Modellen ignorerar function calling | tool_choice satt till "none" av misstag | Sätt tool_choice till "auto" eller tvinga anrop med "required" |
| Svaret saknar historik från tidigare turer | Meddelandelistan skapas på nytt vid varje anrop i stället för att återanvändas | Spara och skicka med hela messages-listan mellan varje anrop, som i steg 4 |
Kostnad i praktiken: GLM-5.2 mot Mistral Large 3 och Medium 3.5
Innan du väljer modell för produktion är det värt att se siffrorna sida vid sida. Priserna nedan är hämtade från Mistrals officiella prisdokumentation, uppdaterad 22 september 2026.
| Modell | Indata per miljon | Cachad indata per miljon | Utdata per miljon | Kontextfönster | Maxutdata |
|---|---|---|---|---|---|
| Mistral Large 3 | 0,50 dollar | 0,05 dollar | 1,50 dollar | ej specificerat här | ej specificerat här |
| Mistral Medium 3.5 | 1,50 dollar | 0,15 dollar | 7,50 dollar | ej specificerat här | ej specificerat här |
| GLM-5.2 (Z.ai, hostad på Mistral) | 1,40 dollar | 0,14 dollar | 4,40 dollar | 1 000 000 tokens | 128 000 tokens |
Slutsatsen för en svensk utvecklingsbudget är rak: om du bygger något som kräver att stora dokument matas in i ett svep, kontrakt, kodbaser, långa transkript, är GLM-5.2 det tydligaste valet av de tre, tack vare kontextfönstret. För korta, frekventa anrop där kontext sällan överstiger några tusen tokens är Mistral Large 3 fortsatt billigast. Medium 3.5 motiveras främst när du behöver Mistrals egna, mest kapabla modell för uppgifter där leverantören själv står bakom hela stacken.
Ett konkret räkneexempel gör skillnaden tydligare. Säg att supportagenten från exemplet ovan hanterar 500 samtal per dag, och att varje samtal i genomsnitt skickar 3 000 tokens indata (historik plus dokument) och får tillbaka 400 tokens utdata. Med GLM-5.2 blir dagskostnaden ungefär 500 × (3 000 × 0,0000014 + 400 × 0,0000044), det landar strax under 3 dollar per dag eller omkring 90 dollar i månaden. Byter du till Mistral Large 3 för samma volym hamnar du i stället runt 30 dollar i månaden, men bara om historiken sällan behöver de riktigt stora kontextfönster som GLM-5.2 är byggd för. Räkna alltid på din egen faktiska tokenvolym snarare än att lita på tumregler, kostnaden skiljer sig snabbt beroende på hur mycket historik och dokumentinnehåll varje anrop bär med sig.
Mistral Studio visar dagens och månadens faktiska förbrukning per API-nyckel i sitt eget gränssnitt, så du behöver inte bara lita på egna kalkyler. Kontrollera den sidan under de första veckorna efter lansering och jämför den med din egen loggade kostnad från steg 9, avvikelser mellan de två siffrorna brukar avslöja anrop du glömt räkna med, till exempel misslyckade förfrågningar som fortfarande debiterar indata-tokens innan de fallerar.
Avancerade tips för produktion
När agenten fungerar lokalt finns några justeringar som gör skillnad i skarpt drift. Sätt alltid ett explicit max_tokens-tak på svaren, även om du litar på modellen, för att undvika enstaka svar som drar iväg mot 128 000 tokens och kostar mer än väntat.
Logga response.usage för varje anrop i en egen tabell, separat från applikationsloggarna. Det gör det möjligt att i efterhand se exakt vilken kund, session eller funktion som drar mest kostnad, vilket är ovärderligt den dagen fakturan är högre än förväntat.
Om du hanterar känsliga svenska persondata, välj ett europeiskt regionalt slutmål i stället för standardendpointen, trots det extra påslaget på 10 procent. Mistral beskriver regional inferens som ett sätt att hålla data och bearbetning inom en vald region, vilket underlättar efterlevnad av GDPR och interna dataskyddspolicyer.
Testa slutligen agenten mot både korta och extremt långa indata innan lansering. En agent som fungerar perfekt på en tio raders fråga kan bete sig annorlunda när den matas med 300 000 tokens kontext, särskilt om verktygsanropen bygger på information som ligger begravd långt in i dokumentet.
Sätt slutligen upp en enkel varning i övervakningen som slår till om andelen anrop med tool_calls plötsligt sjunker eller stiger kraftigt jämfört med normalläget. Ett sådant hopp brukar betyda att en systemprompt eller ett verktygsschema har ändrats på ett sätt som ingen avsåg, till exempel efter en till synes oskyldig omskrivning av en beskrivningstext.
Versionshantera systemprompten och verktygsschemana i samma gitförråd som resten av koden, inte i en separat wiki eller ett textfält i ett admingränssnitt utan historik. Den dagen agenten börjar svara konstigt vill du snabbt kunna se exakt vilken rad som ändrades, av vem och när, på samma sätt som du redan gör för applikationskod.
Vanliga frågor
Vad är GLM-5.2 och vem har byggt den?
GLM-5.2 är en öppen textmodell byggd av det kinesiska AI-bolaget Z.ai. Sedan augusti 2026 hostas den även på Mistrals plattform som den första tredjepartsmodellen i Mistrals utbud.
Behöver jag ett konto hos Z.ai för att använda modellen?
Nej. Så länge du anropar modellen via Mistrals API räcker ett Mistral-konto och en API-nyckel från Mistral Studio. Fakturering, regionval och rate limits sköts av Mistral.
Hur stort är kontextfönstret i praktiken?
Modellen stöder upp till 1 000 000 tokens indata och upp till 128 000 tokens utdata per anrop, enligt Mistrals officiella modellsida. Det räcker för de flesta dokument, kodbaser och loggar utan att dela upp texten.
Stöder GLM-5.2 function calling och strukturerad JSON-utdata?
Ja, båda funktionerna är dokumenterade som stödda via Chat Completions-API:et, vilket är precis vad som gör modellen användbar för agentbyggande snarare än bara chattbotar.
Är GLM-5.2 billigare än Mistrals egna modeller?
Det beror på uppgiften. GLM-5.2 är dyrare än Mistral Large 3 men billigare än Medium 3.5 på utdata. Dess styrka är kontextfönstret, inte lägst pris per token rakt av.
Kan jag köra agenten helt inom EU av GDPR-skäl?
Ja. Mistral erbjuder regional inferens där du kan välja att data och bearbetning stannar inom Europa, mot ett påslag på 10 procent jämfört med standardpriset.
Vad händer om jag skickar för många förfrågningar för snabbt?
Du får ett 429-svar och bör läsa svarshuvudet X-RateLimit-Remaining. Bygg alltid in exponentiell backoff i produktionskod, som visas i steg 9, snarare än att bara skicka om anropet direkt.
Kommer fler tredjepartsmodeller till Mistrals plattform?
Mistral har beskrivit GLM-5.2 som startpunkten för en bredare satsning på att hosta öppna modeller från andra utvecklare. Exakt vilka modeller som följer härnäst har bolaget inte specificerat i sitt ursprungliga tillkännagivande.
Skiljer sig svarskvaliteten mellan Mistrals egna modeller och GLM-5.2?
De två modellfamiljerna är tränade av olika bolag med olika data och olika mål, så svaren kan skilja sig i ton och detaljnivå även på identiska frågor. Bygg alltid det lilla testdatasetet från avsnittet ovan innan du bestämmer vilken modell som passar din specifika uppgift bäst.




