Przewodnik po GLM-5.3: myślenie zawsze włączone, trzy poziomy wysiłku i macierz wsparcia API

Tytuł: Przewodnik praktyczny po GLM-5.3: myślenie zawsze włączone, trzy poziomy wysiłku & macierz wsparcia API

Opis: Przewodnik po GLM-5.3 z sierpnia 2026: myślenie zawsze włączone z trzema poziomami reasoning_effort, podsumowania rozumowania, równoległe wywołania narzędzi, ustrukturyzowane wyjście i automatyczne buforowanie, ze sprawdzonymi przykładami dla AIHubMix Chat / Responses / Messages.

Ten artykuł omawia kluczowe zmiany w API i uwagi dotyczące użycia dla GLM-5.3. GLM-5.3 to flagowy model Z.ai wydany 2026-08-14. Używa dokładnie tej samej bazy modelu co GLM-5.2, a wszystkie zyski pochodzą z post-treningu. W AIHubMix ID modelu to coding-glm-5.3 (obecnie trasa podglądowa o ograniczonym czasie), dostępna przez API Chat Completions, Responses oraz kompatybilne z Claude API Messages. Zobacz także: oficjalny wpis na blogu Z.ai o wydaniu.

Wnioski oznaczone jako „Zweryfikowano” i przykładowe odpowiedzi w każdej sekcji pochodzą z rzeczywistych wywołań wykonanych 2026-08-14 przez API AIHubMix (Chat Completions / Responses / Messages).

1. Specyfikacja modelu w skrócie

Zweryfikowano: max_tokens: 999999 zwraca 400 z podanym w treści błędu prawidłowym zakresem. Limit jest rzeczywiście sprawdzany, a nie cicho obcinany.

# max_tokens=999999 -> HTTP 400
"max_tokens parameter invalid: value must be within [1,131072]"

2. GLM-5.3 vs GLM-5.2: myślenie zawsze włączone, intensywność przez reasoning_effort

To dwie najważniejsze zmiany w API GLM-5.3 w porównaniu z GLM-5.2:

1. thinking.type nie obsługuje już disabled: myślenia nie można wyłączyć. Oficjalna rada migracyjna: aplikacje, które wysyłały {"type": "disabled"}, powinny przejść na {"type": "enabled"} i ustawić reasoning_effort na "low".
2. reasoning_effort zawęża się do trzech poziomów: low (lekki) / high (rozszerzony) / max (głęboki, domyślny). Siedmiowartościowe mapowanie zgodności z ery GLM-5.2 już nie obowiązuje; Z.ai zaleca max do zadań kodowania.

Zweryfikowano: wysłanie thinking: {"type": "disabled"} przez AIHubMix zwraca 200, a myślenie nadal występuje (reasoning_content jest zwracane jak zwykle). Wartość jest automatycznie konwertowana zgodnie z oficjalną semantyką kanału, a nie odrzucana. Jeśli Twój klient polegał na „wyłączeniu myślenia, aby oszczędzać tokeny”, przejdź na reasoning_effort: "low".

Zweryfikowano: wartości spoza listy dla reasoning_effort również zwracają 200 bez błędu (przechodząc na domyślne max zgodnie z oficjalną dokumentacją). low vs max pokazuje oczekiwany trend lżejszego myślenia (27 vs 39 tokenów rozumowania przy tym samym pytaniu arytmetycznym).

Chat Completions

Treść myślenia jest zwracana w polu reasoning_content; w streamingu pojawia się jako delta.reasoning_content.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    reasoning_effort="max",          # low / high / max, default max
    extra_body={"thinking": {"type": "enabled"}},
    messages=[
        {"role": "user", "content": "Compute the square root of (17*23-19*11), rounded down. Digits only."}
    ],
)

print(completion.choices[0].message.reasoning_content)
print(completion.choices[0].message.content)   # Observed: "13"

Zweryfikowano: usage.completion_tokens_details.reasoning_tokens pokazuje zużycie myślenia: 27 przy reasoning_effort="low", 39 przy "max" dla tego samego pytania.

Responses

Treść myślenia zwracana jest jako element wyjścia reasoning, a tekst w tablicy summary jako summary_text.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

response = client.responses.create(
    model="coding-glm-5.3",
    input="What is the capital of France? City name only.",
)

# Observed response.output item types: ["reasoning", "message"]
# reasoning item: {"type": "reasoning", "summary": [{"type": "summary_text", "text": "The user is asking..."}]}
# usage.output_tokens_details.reasoning_tokens: 80

Zweryfikowano: domyślne żądanie (bez żadnego parametru reasoning) już zawiera element reasoning z summary_text. Nie trzeba żadnego jawnego włączania.

Messages

Treść myślenia zwracana jest jako natywne bloki treści thinking.

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com"
)

response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "What is the capital of France? City name only."}
    ],
)

# Observed response.content block types: ["thinking", "text"]

Zweryfikowano: bloki thinking są zwracane domyślnie; thinking: {"type": "disabled"} w tym API również zwraca 200, a myślenie nadal trwa (zgodnie z oficjalną semantyką kanału „disabled zamienia się na low, żądanie jest kontynuowane”).

3. Wywoływanie narzędzi i równoległe narzędzia

Wywoływanie funkcji zweryfikowane jako działające we wszystkich trzech API. W API Responses zaobserwowaliśmy także równoległe wywołania narzędzi w obrębie jednej tury (Z.ai wprost deklaruje supports_parallel_tool_calls: true dla GLM-5.3). Limity po stronie dostawcy: do 128 funkcji w tools; tool_choice natywnie obsługuje tylko auto.

Chat Completions

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    messages=[{"role": "user", "content": "What's the weather in Beijing today?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
)

# Observed: finish_reason "tool_calls", with a get_weather call in tool_calls

Zweryfikowano: tool_choice: "none" działa. To samo pytanie o pogodę zwraca zwykły tekst bez wywołania narzędzia.

Responses

response = client.responses.create(
    model="coding-glm-5.3",
    input="Check today's weather in Shanghai and Beijing",
    parallel_tool_calls=True,
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed: a single turn returns 2 parallel function_call output items (one for each city)

Zweryfikowano: 2 równoległe wywołania narzędzi w jednej turze, zgodnie z oficjalną deklaracją supports_parallel_tool_calls: true.

Messages

response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    messages=[{"role": "user", "content": "What's the weather in Beijing today?"}],
)

# Observed: stop_reason "tool_use"; content contains a tool_use block

❗ Zweryfikowano: w tym API model nadal generuje wywołania narzędzi po tool_choice: {"type": "none"}. Aby wyłączyć narzędzia, usuń parametr tools całkowicie lub użyj tool_choice: "none" w API Chat Completions.

4. Ustrukturyzowane wyjście

response_format obsługuje text i json_object; upstream nie wymienia trybu json_schema. Gdy potrzebujesz ścisłej zgodności ze schematem, osadź JSON Schema w prompcie i waliduj po stronie klienta.

Chat Completions

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    messages=[
        {"role": "user", "content": "What is the capital of France? Answer in JSON with the key \"answer\"."}
    ],
    response_format={"type": "json_object"},
)

# Observed response content: {"answer": "Paris"}

Zweryfikowano: wynik jest poprawnym JSON-em zawierającym żądany klucz.

Responses

response = client.responses.create(
    model="coding-glm-5.3",
    input="What is the capital of France? Answer in JSON with the key \"answer\".",
    text={"format": {"type": "json_object"}},
)

# Observed output text: {"answer": "Paris"}

Messages

# Specify the JSON structure in the prompt; observed output is valid JSON
response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "What is the capital of France? Answer in JSON with the key \"answer\"."}
    ],
)

# Observed response text: {"answer": "Paris"}

5. Buforowanie kontekstu jest automatyczne

Domyślnie włączone jest niejawne buforowanie, bez parametrów do przekazania. Powtarzające się długie prefiksy są raportowane jako trafienia w cache w polu usage (nazwa pola zależy od API).

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 960}

Zweryfikowano: druga z dwóch kolejnych wywołań trafiła 960 buforowanych tokenów.

Responses

# usage of the second call with an identical long prefix
"input_tokens_details": {"cached_tokens": 960}

Messages

# hits are reported via usage.cache_read_input_tokens
"cache_read_input_tokens": 0

Zweryfikowano: w tej rundzie nie udało się odtworzyć trafienia w cache w tym API (cache rozgrzewa się per kanał; przełączenie load balancera może spowodować chybienie). Pole rozliczania trafień zgodne jest z semantyką Anthropic.

6. Próbkowanie i walidacja parametrów

Próbkowanie jest zgodne z konwencjami endpointów rodziny GLM: zakres temperature to [0, 1] z domyślną wartością 1.0 (uwaga: węższy niż [0, 2] w protokole OpenAI); zakres top_p to [0.01, 1] z domyślną wartością 0.95. Z.ai zaleca dostrajanie tylko jednego z tych dwóch parametrów.

Zweryfikowano: walidacja parametrów różni się między API. Messages API odrzuca temperature: 3 błędem 400, który podaje prawidłowy zakres [0,1], natomiast Chat Completions / Responses po cichu akceptują tę samą wartość spoza zakresu z kodem 200. Przy migracji między API nie polegaj na tym, że brama wyłapie za Ciebie wartości próbkowania spoza zakresu.

# Messages API with temperature=3 -> HTTP 400
"temperature parameter invalid: value must be within [0,1]"

7. Macierz wsparcia: możliwości × API

Każda komórka poniżej została zweryfikowana prawdziwymi wywołaniami przez żywe API AIHubMix 2026-08-14. Komórki pokazują zapis parametru lub pola dla każdego API.

FAQ

Jaki jest ID modelu GLM-5.3 w AIHubMix? Czy potrzebuję sufiksu [1m]?
ID modelu to coding-glm-5.3, używaj go bez zmian. glm-5.3[1m] to składnia nazwy modelu Z.ai dla klienta Claude Code i nie ma nic wspólnego z wywołaniami AIHubMix. Żadne z trzech API nie wymaga sufiksu.

Czy mogę wyłączyć myślenie?
Nie. Myślenie GLM-5.3 jest zawsze włączone, a thinking.type obsługuje tylko enabled. W naszych testach wysłanie disabled zwraca 200, a myślenie nadal trwa (konwertowane na poziom low zgodnie z oficjalną semantyką). Aby oszczędzać tokeny myślenia, wyślij reasoning_effort: "low".

Jak GLM-5.3 odnosi się do GLM-5.2?
Ta sama baza modelu. Wszystkie zyski pochodzą z post-treningu (oficjalne sformułowanie: "It uses the same base model as GLM-5.2 — every gain comes from post-training"). Dwie twarde zmiany w API: myślenia nie można już wyłączyć, a reasoning_effort zawęża się do trzech poziomów low/high/max (domyślnie max).

Co, jeśli potrzebuję ścisłego ustrukturyzowanego wyjścia json_schema?
Upstream nie wymienia trybu response_format: json_schema. W naszych testach tryb JSON json_object zwracał poprawny JSON we wszystkich trzech API. W przypadku ścisłych schematów osadź JSON Schema w prompcie i waliduj po stronie klienta.

Czy coding-glm-5.3 to wersja produkcyjna?
Obecnie jest to ograniczona w czasie trasa podglądowa (dokumentacja API modelu Z.ai oznacza oficjalne API jako „wkrótce dostępne”); AIHubMix poinformuje o tym, gdy tylko komercyjne API zostanie udostępnione. Aktualne ceny i status znajdziesz na stronie modelu.

Ceny i status w czasie rzeczywistym znajdziesz na stronie modelu GLM-5.3, a więcej modeli przeglądysz w galerii modeli.