Wprowadzenie
Czat zgodny z OpenAI dla Grok 4.5, modelu kodowego z linii Grok od xAI. Jedna tura niesie części text i image_url, wysiłek rozumowania sięga xhigh, a pojedyncza odpowiedź dochodzi do 450 000 tokenów.
xAI publikuje Grok 4.5 do agentowej pracy nad oprogramowaniem, zadań inżynierskich i workflow, wytrenowała go na dodatkowych danych z nauk ścisłych, inżynierii i matematyki, a serwuje także pod aliasami grok-4.5-latest oraz grok-build-latest. Tutaj jest to jeden endpoint pod /v1/chat/completions, który czyta do 500 000 tokenów w najwyżej 256 uporządkowanych wiadomościach i oddaje do 450 000 w jednej odpowiedzi. Wejście, wejście z pamięci podręcznej i wyjście są mierzone osobno od siebie — i to jest ta część, za którą naprawdę płaci pętla agentowa odtwarzająca długi prefiks.
Najważniejsze funkcje
Prefiks, który wysyłasz ponownie, ma własny licznik
Pętla agentowa na każdym kroku wysyła ten sam prompt systemowy, te same definicje narzędzi i tę samą mapę plików; nowy bywa tylko ogon rozmowy. Wejście podane z pamięci podręcznej wraca policzone osobno w bloku usage i mierzone po własnej, tańszej stawce. Niczego nie trzeba włączać. Utrzymanie pierwszych wiadomości bez zmian między krokami to cała technika, a ile prefiksu naprawdę trafiło do pamięci podręcznej, powie ci sama odpowiedź, zamiast zostawiać to twojemu domysłowi.
Tekst i obrazy na wejściu, tekst na wyjściu
Treść może być zwykłym łańcuchem znaków albo tablicą części, a ten model deklaruje dwie z nich: {"type": "text", "text": "..."} i {"type": "image_url", "image_url": {"url": "...", "detail": "auto|low|high"}}. Zrzut ekranu i pytanie o niego przychodzą w tej samej turze, a treść obrazów liczy się wewnątrz okna 500 000 tokenów, a nie ponad nim. Na tym endpoincie nie ma części plikowych ani PDF, więc specyfikacja, log albo diff musi przyjść jako wklejony tekst. Wysiłek rozumowania przyjmuje low, medium, high albo xhigh i startuje na high; jest opłacany tokenami wyjściowymi, więc obciąża zarówno limit odpowiedzi, jak i rachunek.
Parametry żądania
| Parametr | Wymagane | Uwaga |
|---|---|---|
messages | Tak | Najwyżej 256 tur. Treść może mieszać części text i |
reasoning_effort | Nie | low, medium, high albo xhigh. High jest domyślny; wysiłek rozumowania zużywa tokeny wyjściowe, więc xhigh podnosi rachunek nawet przy krótkiej odpowiedzi. |
max_tokens | Nie | Ogranicza widoczną odpowiedź do 450 000; domyślne 4096 po cichu obcina długą odpowiedź. |
temperature | Nie | Od 0 do 2, domyślnie 0,7. Ustaw 0, gdy porównujesz dwie łatki albo dwa przebiegi tego samego zadania. |
top_p | Nie | Od 0,01 do 1. Ruszaj ten parametr albo temperature, a nie oba naraz. |
tools | Nie | Do 128 definicji funkcji na żądanie. Stała kolejność między krokami pomaga utrzymać prefiks w pamięci podręcznej. do 128 elementów |
parallel_tool_calls | Nie | true lub false, domyślnie true: model może w jednej turze zażądać kilku wywołań narzędzi. Domyślnie: |
tool_choice | Nie | auto, none, required albo obiekt wskazujący funkcję do wywołania. |
response_format | Nie | Poproś o obiekt JSON, gdy odpowiedź parsuje kolejny krok agenta, a nie czyta człowiek. |
Cennik
Wejście $2 / Wyjście $6 za 1 mln tokenów; Prompty od 200K tokenów wzwyż: Wejście $4 / Wyjście $12
Łączne wejście obejmuje tokeny z pamięci podręcznej. Od 200 000 tokenów wejściowych wzwyż stawki długiego kontekstu obowiązują dla całego wejścia, wejścia z pamięci podręcznej i wyjścia danego żądania; mniejsze wejścia idą po stawkach standardowych. Wejście z pamięci podręcznej jest mierzone osobno od świeżego wejścia i wyceniane niżej. Wyjście obejmuje tokeny rozumowania, więc wyższy wysiłek rozumowania kosztuje więcej nawet przy tak samo długiej widocznej odpowiedzi. Sprawdź budżet żądania przed wysłaniem. Wstępna rezerwacja nie zakłada oszczędności z pamięci podręcznej, a po rozliczeniu według zmierzonego zużycia nadwyżka zostaje zwrócona.
Zastosowania
Utrzymaj całą pętlę w kontekście
Agent kodowy na każdym kroku wysyła ponownie swoje instrukcje, definicje narzędzi i mapę plików, a za każdym razem dokłada kilkaset nowych tokenów. Wszystko to mieści się w oknie 500 000 tokenów, powtarzana część liczona jest jako wejście z pamięci podręcznej, a na stawkę długiego kontekstu żądanie przechodzi dopiero przy 200 000 łącznych tokenów wejścia i wejścia z pamięci podręcznej — o czym szacunkowy koszt widoczny przed wysłaniem uprzedzi cię, zanim za to zapłacisz.
Refaktoryzuj z modułem, testami i błędem w jednej turze
Wklej razem moduł, plik testów i nieudane wyjście, a potem poproś o łatkę wraz z uzasadnieniem. Podnieś reasoning_effort do xhigh, gdy zmianę trzeba przemyśleć, zanim się ją napisze: model zużyje więcej tokenów wyjściowych, zanim pojawi się pierwsza linijka kodu, a przy zmianie, którą przejrzysz linijka po linijce, to się opłaca.
Daj przeczytać zrzut ekranu razem ze stack trace'em
Dołącz nieudany dashboard jako część image_url z detail high, wklej stack trace jako tekst w tej samej wiadomości, a potem poproś o przyczyny w kolejności prawdopodobieństwa. Obraz i log przychodzą w jednej turze, więc model czyta sam panel, a nie twój jego opis.
Odbierz dokumentację migracji w jednej odpowiedzi
450 000 tokenów wyjściowych wystarcza na pełny plan migracji, przepisany moduł albo przetłumaczony podręcznik w jednej odpowiedzi zamiast pętli po rozdziałach. Podnieś max_tokens wprost: domyślne 4096 ucina długie generowanie bez zgłaszania błędu, a ucięcie to awaria najbardziej podobna do skończonej odpowiedzi.
Wskazówki
Wybieraj poziom wysiłku pod zadanie, nie pod projekt
reasoning_effort startuje na high, więc pomijając to pole, już płacisz za staranną pracę i tokeny wyjściowe, które do niej należą. Decyduj przy każdym wywołaniu: xhigh przy migracji albo dowodzie, high przy zwykłym przeglądzie, low przy mechanicznej turze w rodzaju klasyfikacji linii logu. Ponieważ wysiłek rozumowania jest opłacany tokenami wyjściowymi, krótka odpowiedź na xhigh potrafi kosztować więcej niż długa na low.
Poproś o artefakt i wyślij treść, którą da się wkleić
Ustal kształt wyjścia w wiadomości systemowej, a turze użytkownika zostaw materiał dowodowy — plik, log, zrzut ekranu — żeby model nie zgadywał formatu, kiedy pracuje nad problemem.
curl https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "xai/grok-4.5",
"messages": [
{"role": "system", "content": "Return the patched file in full. No diffs, no commentary, no omitted regions."},
{"role": "user", "content": [
{"type": "text", "text": "Both panels are the same service before and after the deploy. Which one regressed, and what in the diff explains it?"},
{"type": "image_url", "image_url": {"url": "https://cdn.spicyapi.ai/models/examples/inputs/c681580c3c6a0b63.jpeg", "detail": "high"}}
]}
],
"reasoning_effort": "high",
"max_tokens": 32000
}'
Najpierw przeczytaj blok usage, potem cokolwiek zmieniaj
Odpowiedź raportuje osobno tokeny wejścia, wejścia z pamięci podręcznej i wyjścia, i to jedyna uczciwa odpowiedź na pytanie, czy twój prefiks trafił do pamięci podręcznej. Strojenie prowadź stamtąd, a nie z kształtu rozmowy: jeśli udział pamięci podręcznej zostaje na zerze krok po kroku, coś zmienia się w pierwszych wiadomościach — znacznik czasu w prompcie systemowym, przestawiona lista narzędzi — a przeniesienie tego fragmentu na koniec żądania zwykle załatwia całą sprawę. Długie odpowiedzi czytaj strumieniowo przez stream: true, które zwraca zdarzenia chat.completion.chunk aż do data: [DONE].
Szybki start z API
curl --fail-with-body -sN https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"model": "xai/grok-4.5/chat",
"messages": [
{
"role": "user",
"content": "Summarise the following release notes into three bullet points."
}
],
"stream": true
}' \
| jq --unbuffered -Rrj 'select(startswith("data: ")) | .[6:] | select(. != "[DONE]") | fromjson | if .error then "\n[error] \(.error.message)\n" else (.choices[0].delta.content? // empty) end'
Uwierzytelnianie, pełny schemat, odpytywanie i obsługę błędów opisuje dokumentacja API.
