xAI beskriver Grok 4.7 som sin spydspidsmodel til kodning, agentopgaver og vidensarbejde, med et kontekstvindue på 500K tokens. Ifølge xAIs aktuelle prisside er direkte API-satser under 200.000 prompt-tokens $2.00 pr. million input-tokens, $0.50 pr. million cachede tokens og $6.00 pr. million output-tokens. Når en prompt når 200.000 tokens eller mere, angiver xAI henholdsvis $4.00, $1.00 og $12.00. Dette er xAIs direkte satser, ikke en universel pris på tværs af tredjepartsplatforme.
Det faktiske forbrug afhænger af mere end den annoncerede input-sats. Nyt input, cachet input, output, retries, værktøjskald og antallet af modelkald i en agent-arbejdsgang kan alle ændre regningen. 200K-promptgrænsen er især vigtig, fordi både xAI og CometAPI offentliggør højere satser for langkontekst, når den grænse nås.
Denne guide fastlægger først xAI-prisbaselinen og sammenligner derefter den aktuelle CometAPI Grok 4.7-liste. Pr. 28. september 2026 angiver CometAPI $1.60 / $0.40 / $4.80 pr. million nyt input, cachet input og output-tokens i standardniveauet og $3.20 / $0.80 / $9.60 i langkontekstniveauet—20% under de tilsvarende xAI-direkte satser. De følgende afsnit forklarer, hvordan man beregner arbejdsbelastningsomkostninger, reducerer spild og får adgang til modellen via CometAPI. Alle priser er tidsbestemte øjebliksbilleder og bør kontrolleres igen før produktionsbrug.
xAI Direct vs. CometAPI Grok 4.7-priser
xAI direkte satser (USD pr. 1M tokens)
| Token-kategori | Under 200K prompt-tokens | Langkontekst (≥200K) |
|---|---|---|
| Nyt input | $2.00 | $4.00 |
| Cachet input | $0.50 | $1.00 |
| Output | $6.00 | $12.00 |
CometAPI-satser (USD pr. 1M tokens)
| Token-kategori | CometAPI: under 200K prompt-tokens | CometAPI: langkontekstniveau |
|---|---|---|
| Nyt input | $1.60 / 1M tokens | $3.20 / 1M tokens |
| Cachet input | $0.40 / 1M tokens | $0.80 / 1M tokens |
| Output | $4.80 / 1M tokens | $9.60 / 1M tokens |
200K-promptgrænsen betyder noget, fordi begge platforme i øjeblikket angiver langkontekstsatser til det dobbelte af deres standardniveau for Grok 4.7. Dette er en prisregel fastsat af hver API-platform, ikke en ændring i modellens kapacitet. En forespørgsel bliver dyrere, når en applikation gentagne gange sender store prompts eller lader agenthistorik vokse ukontrolleret—ikke blot fordi Grok 4.7 understøtter et kontekstvindue på 500K.
Til budgettering bør enhver forespørgsel, der forventes at nå grænsen, behandles som langkontekst, indtil den aktive faktureringsadfærd er verificeret. Modeltilgængelighed og priser kan ændre sig, så produktionskalkulatorer bør genkontrollere både xAI direkte priser og den aktuelle CometAPI-modelside i stedet for at hardcode permanente værdier.
Formlen til at estimere omkostningen for Grok 4.7
Estimer én forespørgsel ved at prissætte hver token-kategori separat:
request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000
Konverter derefter forespørgselsestimatet til et arbejdslastestimat:
monthly cost = request cost × requests per user × active users × days in billing period
Brug et realistisk percentil frem for ét gennemsnit. Et p50-estimat beskriver en normal forespørgsel, men p95 input- og outputlængder afslører den dyre hale, der ofte driver regningen. For agent-arbejdsgange multipliceres med det forventede antal modelkald pr. fuldført opgave. En arbejdsgang på fem trin er fem fakturerbare kald, ikke ét.
Gennemregnet eksempel 1: En support-copilot
Antag, at én supportforespørgsel sender 6.000 nye input-tokens og genererer 800 output-tokens. Den forbliver under 200K-grænsen og får ikke en cache-rabat.
- Input: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
- Output: 800 × $4.80 ÷ 1,000,000 = $0.00384
- I alt: $0.01344 pr. forespørgsel
Ved 100.000 forespørgsler pr. måned er den anslåede tokenomkostning $1,344. Hvis evaluering viser, at et svar på 400 tokens fungerer lige så godt som et svar på 800 tokens, falder estimatet til $0.01152 pr. forespørgsel eller $1,152 pr. måned. Denne ene outputbegrænsning sparer cirka $192 pr. måned, eller 14,3%, uden at ændre modellen.
Derfor fortjener outputkontrol opmærksomhed. Ved den angivne CometAPI-sats koster output-tokens tre gange så meget som nye input-tokens i samme niveau.
Gennemregnet eksempel 2: Genbrug af et stabilt 20K-token-præfiks
Antag, at hver forespørgsel indeholder en produktmanual på 20.000 tokens, 2.000 tokens af ny samtalekontekst og et svar på 600 tokens.
Uden cache-hit er estimatet:
- 22,000 nye input-tokens: $0.03520
- 600 output-tokens: $0.00288
- I alt: $0.03808 pr. forespørgsel
Hvis det 20.000-token store stabile præfiks faktureres som cachet input, mens kun 2.000 tokens forbliver nye, bliver estimatet:
- 20,000 cachede input-tokens: $0.00800
- 2,000 nye input-tokens: $0.00320
- 600 output-tokens: $0.00288
- I alt: $0.01408 pr. forespørgsel
Ved 100.000 forespørgsler er det $1,408 i stedet for $3,808—en anslået besparelse på $2,400 eller 63,0%. Besparelsen er ikke automatisk: den første forespørgsel, et ændret præfiks eller en rute, der ikke giver et cache-hit, kan stadig blive faktureret til satsen for nyt input. Bekræft antallet af cachede tokens i faktiske brugsdata, før estimatet behandles som realiserede besparelser.
Gennemregnet eksempel 3: Omkostningen ved at krydse 200K
Overvej en langvarig agentforespørgsel med 210.000 prompt-tokens og 2.000 output-tokens. Ved hjælp af de angivne langkontekst-satser:
- 210,000 nye input-tokens: $0.67200
- 2,000 output-tokens: $0.01920
- I alt: $0.69120 pr. kørsel
Hvis kontekstkomprimering, filtrering i retrieval og sammenfatnings-checkpoints reducerer prompten til 180.000 tokens, mens samme output på 2.000 tokens bevares, er standardniveau-estimatet:
- 180,000 nye input-tokens: $0.28800
- 2,000 output-tokens: $0.00960
- I alt: $0.29760 pr. kørsel
Forskellen er $0.39360 pr. kørsel, eller cirka 56,9%. På tværs af 10.000 kørsel er den anslåede besparelse $3,936. Læren er ikke at slette nyttig kontekst. Det er at beholde kun den kontekst, der ændrer svaret, og at sammenfatte eller hente resten, før forespørgslen krydser en prisgrænse.
En Python-beregner til estimering før kald
Følgende funktion bruger CometAPIs aktuelt angivne satser for Grok 4.7. Den anvender langkontekstniveauet konservativt, når den samlede prompt når 200.000 tokens.
from dataclasses import dataclass
@dataclass(frozen=True)
class Rates:
input_per_million: float
cached_input_per_million: float
output_per_million: float
SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)
def estimate_grok_47_cost(
fresh_input_tokens: int,
cached_input_tokens: int,
max_output_tokens: int,
) -> float:
prompt_tokens = fresh_input_tokens + cached_input_tokens
rates = LONG if prompt_tokens >= 200_000 else SHORT
return (
fresh_input_tokens * rates.input_per_million
+ cached_input_tokens * rates.cached_input_per_million
+ max_output_tokens * rates.output_per_million
) / 1_000_000
estimate = estimate_grok_47_cost(
fresh_input_tokens=2_000,
cached_input_tokens=20_000,
max_output_tokens=600,
)
print(f"Estimeret øvre grænse: ${estimate:.5f}")
Dette er en planlægningsvagt, ikke en faktura. Den endelige omkostning afhænger af faktisk input, cachet input, output, retries, værktøjskald og den aktive pris på kørselstidspunktet. Efter hvert svar bør du gemme det returnerede tokenforbrug, model-ID, forespørgselsstatus og task-udfald. Afstem disse værdier med udbyderens faktureringsoptegnelser.
Fem omkostningskontroller for Grok 4.7, rangeret efter sandsynlig effekt
1. Hold gentagen kontekst stabil nok til at blive cachet
Placer statiske instruktioner, produktdokumentation, skemaer og genbrugelige eksempler før den opgavemæssige kontekst. Undgå at ændre tidsstempler, ID’er, whitespace eller rækkefølge inde i et stort delt præfiks, medmindre ændringen er påkrævet. xAIs Grok 4.7-vejledning anbefaler stabile cache-routing-identifikatorer til samtaler; når du bruger en mellemliggende rute, skal du verificere, hvilke cachekontroller og brugsfelter der understøttes, før du stoler på dem.
Mål cache-hit-tokens og cache-hit-rate pr. arbejdsbyrde. En teoretisk cacherabat har ingen værdi, hvis applikationen konstant ændrer præfikset.
2. Behandl 200K som et engineering-budget, ikke et mål
Bevar buffer under grænsen til systeminstruktioner, hentede passager, værktøjsresultater og næste brugertur. For en agent: komprimer gamle ture til en valideret sammenfatning og bevar den rå transkript uden for modelkonteksten. For retrieval: ranger og dedupliker passager, før indsættelse i stedet for at sende hvert match.
Spor promptlængdefordelinger og giv alarm, før p95 nærmer sig grænsen. Under xAIs officielle takstplan gælder langkontekstsatser for alle tokens i en forespørgsel, når en prompt når 200K tokens. CometAPI angiver ligeledes et separat, højere langkontekstniveau for Grok 4.7. Dette er platformens prisvilkår, ikke modelkapaciteter.
3. Begræns output og tilpas reasoning-indsats mod et evalueringssæt
Sæt en applikationsniveau-outputgrænse, der matcher produktet. Et klassifikationsresultat kan kræve få titals tokens; et support-svar kan kræve nogle hundrede; en forskningsrapport kan kræve mere. Denne grænse er en budget- og brugeroplevelseskontrol, ikke en hård begrænsning i Grok 4.7-modellen. xAIs udgivelsesnoter af 21. september angiver, at Grok 4.7 ikke har nogen tekstoutputgrænse; det forhindrer ikke en applikation eller en specifik API-rute i at håndhæve sin egen forespørgselsgrænse. Bekræft enhver rute- eller SDK-håndhævet forespørgselsgrænse med den rute, du faktisk bruger.
Grok 4.7 understøtter flere niveauer af reasoning-indsats. Brug det laveste niveau, der består et repræsentativt evalueringssæt, og reserver højere indsats til opgaver, hvor det giver en målbar forbedring. At reducere reasoning eller output uden kvalitetskontrol kan skabe retries og slette besparelsen.
4. Afvis eller omform dyre forespørgsler før API-kaldet
Estimer en øvre grænse ud fra inputstørrelse og den konfigurerede outputgrænse. Hvis forespørgslen overskrider produktbudgettet, kan applikationen bede brugeren indsnævre opgaven, sammenfatte uploadet materiale, reducere hentet kontekst eller flytte jobbet til en godkendt asynkron arbejdsgang. Dette er mere forudsigeligt end at opdage omkostningen efter generering.
Et groft tegn-til-token-skøn kan være nyttigt som tidlig vagt, men det bør ikke erstatte en tokenizer eller faktiske brugsdata. Sprog, kode, JSON og formatering kan give meget forskellige tokentætheder.
5. Optimer omkostning pr. succesfuld opgave, ikke omkostning pr. kald
Et billigere kald, der fejler validering to gange, kan koste mere end ét succesfuldt kald. Spor:
- omkostning pr. accepteret svar;
- omkostning pr. fuldført agentopgave;
- retry- og fallback-omkostning;
- cache-hit-rate og andel cachede tokens;
- p50 og p95 prompt- og output-tokens;
- kvalitetsscore, latens og rate for menneskelig eskalation.
Hvis rutinetrafik ikke kræver Grok 4.7’s kvalitet eller kontekstkapacitet, kan CometAPIs forenede modelkatalog gøre en applikationsstyret modelskift lettere. Hold routingreglen eksplicit, evaluer hver model på samme opgavesæt, og send kun de forespørgsler, der drager fordel af Grok 4.7, til denne rute.
En praktisk månedlig omkostningsgennemgang
Én gang om ugen: grupper trafikken efter funktion og sammenlign estimeret omkostning med faktisk forbrug. Start med de funktioner, der står for flest output-tokens, de største prompts og den laveste cache-hit-rate. Gennemgå derefter dyre outliers i stedet for blindt at optimere median-forespørgslen.
| Signal | Sandsynligt problem | Første handling |
|---|---|---|
| Lav andel cachede tokens | Delt præfiks ændrer sig for ofte | Stabiliser og versionér genbrugskontekst |
| Prompts klumper sig nær 200K | Historik eller retrieval er ubegrænset | Komprimer, ranger og bevar buffer |
| Output dominerer forbruget | Svarene er længere end produktet behøver | Sænk grænsen og test svartkvalitet |
| Høj retry-omkostning | Validering, timeouts eller ustabile prompts | Ret fejlen i første kald |
| Lav pris men dårlig opgaveafslutning | Optimeringen reducerede nyttig kvalitet | Mål omkostning pr. accepteret resultat |
Hvor CometAPI passer ind i Grok 4.7-omkostningsmodellen
CometAPIs rolle i denne arbejdsgang ligger på API-platformsniveau: den giver adgang til Grok 4.7, offentliggør sine egne tokenrater og dokumenterer et OpenAI-kompatibelt indgangspunkt. Den ændrer ikke Grok 4.7’s underliggende modelkapaciteter. Teams, der allerede bruger en OpenAI-stil klient, kan muligvis beholde samme klientmønster, mens de ændrer API-nøgle, base-URL og model-ID, underlagt endpoint-kompatibilitet.
Pr. 28. september 2026 er CometAPIs angivne Grok 4.7-satser 20% under de tilsvarende xAI-direkte satser i både standard- og langkontekstniveauerne. Dette er en platformsprissammenligning, ikke en påstand om modelkvalitet. Før produktionsudrulning bør teams også verificere aktivt model-ID, endpoint-parametre, cache-adfærd, rate limits, pålidelighed, support og faktureringsvilkår.
For at teste modellen: gennemgå de aktuelle priser og adgangsdetaljer på CometAPI Grok 4.7-modelsiden. Behold pristabellen i konfigurationen, registrér faktisk forbrug efter hvert kald, og kør arbejdslastestimater igen, når modellen eller produktadfærden ændres.
FAQ
Hvad er prisen pr. token for Grok 4.7 på CometAPI?
For prompts under 200K tokens angiver CometAPI i øjeblikket $1.60 pr. million nye input-tokens, $0.40 pr. million cachede input-tokens og $4.80 pr. million output-tokens. De angivne langkontekst-satser er henholdsvis $3.20, $0.80 og $9.60 pr. million tokens.
Hvor meget koster én Grok 4.7 API-forespørgsel?
Det afhænger af nyt input, cachet input, output og det aktive kontekstniveau. Multiplicér hver tokenmængde med dens pr.-million-sats, læg resultaterne sammen og divider med en million. Medtag også retries og hvert modelkald i en multitrins arbejdsgang.
Hvad er den nemmeste måde at reducere Grok 4.7 API-omkostninger på?
Start med den største målte omkostningsdriver. Gentagne lange instruktioner drager normalt fordel af caching; voksende agenthistorikker drager fordel af komprimering; verbose svar drager fordel af en lavere outputgrænse. Bekræft, at kvaliteten forbliver acceptabel efter hver ændring.
Betyder et kontekstvindue på 500K, at jeg bør sende 500K tokens?
Nej. Kontekstvinduet er en kapacitetsgrænse, ikke en anbefaling. Både xAI direkte priser og CometAPIs aktuelle angivelser bruger højere langkontekst-satser ved 200K-promptgrænsen, så applikationer bør kun sende den kontekst, der er nødvendig for opgaven.
Kan jeg estimere omkostning før jeg kalder Grok 4.7?
Ja. Estimér input-tokens, vælg det korrekte kontekstniveau, tilføj en realistisk outputgrænse, og beregn den øvre grænse. Efter kaldet erstattes estimatet med faktisk forbrugsdata til rapportering og optimering.