Grok 4.7 API-priser på CometAPI: Offisiell grunnlinje, kostnadsanslag og besparelser

xAI beskriver Grok 4.7 som sin spydspissmodell for koding, agent-oppgaver og kunnskapsarbeid, med et kontekstvindu på 500K tokens. Ifølge xAIs gjeldende prisside er direkte API-satser under 200 000 prompt-tokens $2.00 per million input-tokens, $0.50 per million bufrede tokens og $6.00 per million output-tokens. Når en prompt når 200 000 tokens eller mer, oppgir xAI henholdsvis $4.00, $1.00 og $12.00. Dette er xAIs direkte satser, ikke en universell pris på tvers av tredjepartsplattformer.

Faktisk forbruk avhenger av mer enn den oppgitte input-satsen. Ny input, bufret input, output, nye forsøk, verktøykall og antall modellkall i en agent-arbeidsflyt kan alle endre regningen. 200K-grensen for prompt er spesielt viktig fordi både xAI og CometAPI publiserer høyere satser for lang kontekst når denne grensen nås.

Denne veiledningen etablerer først xAI-priser som referanse, og sammenligner deretter den nåværende CometAPI Grok 4.7-oppføringen. Per 28. september 2026 oppgir CometAPI $1.60 / $0.40 / $4.80 per million nye-input-, bufrede-input- og output-tokens i standardnivået, og $3.20 / $0.80 / $9.60 i langkontekst-nivået—20% under de tilsvarende direkte satsene fra xAI. Seksjonene nedenfor forklarer hvordan man beregner arbeidslastkostnader, reduserer sløsing og får tilgang til modellen via CometAPI. Alle priser er daterte øyeblikksbilder og bør sjekkes på nytt før produksjonsbruk.

xAI direkte vs. CometAPI Grok 4.7-priser

xAI direkte satser (USD per 1M tokens)

CometAPI-satser (USD per 1M tokens)

200K-grensen for prompt betyr noe fordi begge plattformer for tiden oppgir langkontekst-satser til det dobbelte av sine standardnivå-satser for Grok 4.7. Dette er en prisregel satt av hver API-plattform, ikke en endring i modellens kapasitet. En forespørsel blir dyrere når en applikasjon gjentatte ganger sender store prompter eller lar agenthistorikken vokse ukontrollert—ikke bare fordi Grok 4.7 støtter et kontekstvindu på 500K.

For budsjettering, behandle enhver forespørsel som forventes å nå grensen som lang kontekst inntil aktiv faktureringsatferd er verifisert. Modelltlgjengelighet og priser kan endre seg, så produksjonskalkulatorer bør sjekke både xAI direkte priser og den gjeldende CometAPI-modellsiden i stedet for å hardkode permanente verdier.

Formelen for å estimere Grok 4.7-kostnad

Estimer én forespørsel ved å prise hver token-kategori separat:

request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000

Konverter deretter forespørselsestimatet til et arbeidslastestimat:

monthly cost = request cost × requests per user × active users × days in billing period

Bruk et realistisk persentil snarere enn ett gjennomsnitt. Et p50-estimat beskriver en normal forespørsel, men p95-inn- og utlengder avdekker den dyre halen som ofte driver regningen. For agent-arbeidsflyter, multipliser med forventet antall modellkall per fullført oppgave. En arbeidsflyt på fem trinn er fem fakturerbare kall, ikke ett.

Regneeksempel 1: En support-copilot

Anta at én supportforespørsel sender 6 000 ferske input-tokens og genererer 800 output-tokens. Den holder seg under 200K-grensen og får ikke cache-rabatt.

• Input: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
• Output: 800 × $4.80 ÷ 1,000,000 = $0.00384
• Total: $0.01344 per forespørsel

Ved 100 000 forespørsler per måned er estimert token-kostnad $1,344. Hvis evaluering viser at et svar på 400 tokens fungerer like bra som et på 800 tokens, faller estimatet til $0.01152 per forespørsel, eller $1,152 per måned. Den ene output-begrensningen sparer omtrent $192 per måned, eller 14,3%, uten å endre modellen.

Dette er grunnen til at output-kontroll fortjener oppmerksomhet. Til den oppgitte CometAPI-satsen koster output-tokens tre ganger så mye som ferske input-tokens i samme nivå.

Regneeksempel 2: Gjenbruk av et stabilt 20K-token-prefiks

Anta at hver forespørsel inneholder en produktmanual på 20 000 tokens, 2 000 tokens ny samtalekontekst og et svar på 600 tokens.

Uten cache-treff blir estimatet:

• 22,000 ferske input-tokens: $0.03520
• 600 output-tokens: $0.00288
• Total: $0.03808 per forespørsel

Hvis det stabile prefikset på 20 000 tokens faktureres som bufret input mens bare 2 000 tokens forblir ferske, blir estimatet:

• 20,000 bufrede input-tokens: $0.00800
• 2,000 ferske input-tokens: $0.00320
• 600 output-tokens: $0.00288
• Total: $0.01408 per forespørsel

Ved 100 000 forespørsler er det $1,408 i stedet for $3,808—en estimert besparelse på $2,400, eller 63,0%. Besparelsen er ikke automatisk: den første forespørselen, et endret prefiks eller en rute som ikke gir cache-treff kan fortsatt bli fakturert med satsen for fersk input. Bekreft antall bufrede tokens i faktiske bruksdata før du behandler estimatet som oppnådde besparelser.

Regneeksempel 3: Kostnaden ved å krysse 200K

Vurder en langvarig agentforespørsel med 210 000 prompt-tokens og 2 000 output-tokens. Bruker man de oppgitte langkontekst-satsene:

• 210,000 ferske input-tokens: $0.67200
• 2,000 output-tokens: $0.01920
• Total: $0.69120 per kjøring

Hvis komprimering av kontekst, filtrering ved gjenfinning og oppsummerings-sjekkpunkter reduserer prompten til 180 000 tokens, samtidig som samme output på 2 000 tokens bevares, er standardnivå-estimatet:

• 180,000 ferske input-tokens: $0.28800
• 2,000 output-tokens: $0.00960
• Total: $0.29760 per kjøring

Forskjellen er $0.39360 per kjøring, eller omtrent 56,9%. Over 10 000 kjøringer er den estimerte besparelsen $3,936. Lærdommen er ikke å slette nyttig kontekst. Det er å beholde bare konteksten som endrer svaret, og å oppsummere eller hente resten før forespørselen krysser en prisgrense.

En Python-kalkulator for estimater før kall

Følgende funksjon bruker CometAPIs nåværende oppgitte satser for Grok 4.7. Den anvender forsiktig langkontekst-nivået når total 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"Estimated upper bound: ${estimate:.5f}")

Dette er en planleggingsbeskyttelse, ikke en faktura. Den endelige kostnaden avhenger av faktisk input, bufret input, output, nye forsøk, verktøykall og aktiv pris ved kjøretid. Etter hvert svar, lagre returverdiene for token-bruk, modell-ID, forespørselsstatus og oppgaveutfall. Avstem disse verdiene med leverandørens faktureringsdata.

Fem kostnadskontroller for Grok 4.7, rangert etter sannsynlig effekt

1. Hold gjentatt kontekst stabil nok til å kunne bufres

Plasser statiske instruksjoner, produktdokumentasjon, skjemaer og gjenbrukbare eksempler før innhold som er spesifikt for forespørselen. Unngå å endre tidsstempler, ID-er, whitespace eller rekkefølge inne i et stort delt prefiks med mindre endringen er nødvendig. xAIs veiledning for Grok 4.7 anbefaler stabile cache-rutingsidentifikatorer for samtaler; når du bruker en mellomliggende rute, verifiser hvilke cache-kontroller og bruksfelt som støttes før du stoler på dem.

Mål cache-treff-tokens og cache-treff-rate etter arbeidslast. En teoretisk cache-rabatt har ingen verdi hvis applikasjonen konstant endrer prefikset.

2. Behandle 200K som et teknisk budsjett, ikke et mål

Sett av margin under terskelen for systeminstruksjoner, hentede avsnitt, verktøyresultater og neste bruker-tur. For en agent, komprimer gamle turer til en validert oppsummering og behold rå transkripsjon utenfor modellkonteksten. For gjenfinning, ranger og dedupliser avsnitt før innsetting i stedet for å sende alle treff.

Spor distributionskurver for prompt-lengde og varsle før p95 nærmer seg terskelen. Under xAIs offisielle prisskjema, når en prompt når 200K tokens, gjelder langkontekst-satser for alle tokens i den forespørselen. CometAPI oppgir på samme måte et eget, høyere langkontekst-nivå for Grok 4.7. Dette er plattformens prisbetingelser, ikke modellens kapasitet.

3. Begrens output og juster resonnementinnsats mot et evalueringssett

Sett en applikasjonsnivå output-grense som matcher produktet. Et klassifiseringsresultat kan trenge titalls tokens; et supportsvar kan trenge noen hundre; en forskningsrapport kan trenge mer. Denne grensen er et budsjett- og brukeropplevelseskontroll, ikke en hard begrensning i Grok 4.7-modellen. xAIs utgivelsesnotater 21. september sier at Grok 4.7 ikke har noen tekstlig output-grense; det hindrer ikke at en applikasjon eller en spesifikk API-rute håndhever sin egen forespørselsgrense. Bekreft enhver rute- eller SDK-pålagt forespørselsgrense med ruten du faktisk bruker.

Grok 4.7 støtter flere nivåer av resonnementinnsats. Bruk det laveste nivået som består et representativt evalueringssett, og reserver høyere innsats for oppgaver der det gir en målbar forbedring. Å redusere resonnement eller output uten kvalitetskontroller kan skape nye forsøk og viske ut besparelsen.

4. Avslå eller omform dyre forespørsler før API-kallet

Estimer en øvre grense ut fra input-størrelse og den konfigurerte output-grensen. Hvis forespørselen overskrider produktbudsjettet, kan applikasjonen be brukeren om å snevre inn oppgaven, oppsummere opplastet materiale, redusere hentet kontekst eller flytte jobben til en godkjent asynkron arbeidsflyt. Dette er mer forutsigbart enn å oppdage kostnaden etter generering.

En grov tegn-til-token-approksimasjon kan være nyttig som en tidlig sikring, men den bør ikke erstatte en tokenizer eller faktiske bruksdata. Språk, kode, JSON og formatering kan gi svært ulik tokentetthet.

5. Optimaliser kostnad per vellykket oppgave, ikke kostnad per kall

Et billigere kall som feiler validering to ganger kan koste mer enn ett vellykket kall. Spor:

• kostnad per akseptert svar;
• kostnad per fullført agentoppgave;
• kostnad for nye forsøk og fallback;
• cache-treff-rate og andel bufrede tokens;
• p50 og p95 prompt- og output-tokens;
• kvalitetsscore, latenstid og rate for menneskelig eskalering.

Hvis rutinetrafikk ikke krever Grok 4.7s kvalitet eller kontektskapasitet, kan CometAPIs samlede modellkatalog gjøre en applikasjonsstyrt modellbytte enklere. Hold rutingsregelen eksplisitt, evaluer hver modell på samme oppgavesett, og send bare de forespørslene som har nytte av Grok 4.7 til denne ruten.

En praktisk månedlig kostnadsgjennomgang

Én gang i uken, grupper trafikk etter funksjon og sammenlign estimert kostnad med faktisk bruk. Start med funksjonene som står for flest output-tokens, de største promptene og den laveste cache-treff-raten. Gå deretter gjennom dyre avvik i stedet for å optimalisere medianforespørselen blindt.

Hvor CometAPI passer inn i kostnadsmodellen for Grok 4.7

CometAPIs rolle i denne arbeidsflyten er på API-plattformnivå: den gir tilgang til Grok 4.7, publiserer egne token-satser og dokumenterer et OpenAI-kompatibelt inngangspunkt. Den endrer ikke Grok 4.7s underliggende modellegenskaper. Team som allerede bruker en OpenAI-lignende klient, kan ofte beholde samme klientmønster mens de endrer API-nøkkel, base-URL og modell-ID, forutsatt endepunktkompatibilitet.

Per 28. september 2026 er CometAPIs oppgitte satser for Grok 4.7 20% under de tilsvarende direkte xAI-satsene i både standard- og langkontekst-nivået. Dette er en plattformpris-sammenligning, ikke et påstand om modellkvalitet. Før produksjonsutrulling bør team også verifisere aktiv modell-ID, endepunktparametre, cache-atferd, raterestriksjoner, pålitelighet, støtte og faktureringsvilkår.

For å teste modellen, se gjennom gjeldende pris- og tilgangsdetaljer på CometAPI Grok 4.7-modellsiden. Hold pristabellen i konfigurasjonen, registrer faktisk bruk etter hvert kall, og kjør arbeidslastestimater på nytt når modellen eller produktatferden endres.

FAQ

Hva er prisen per token for Grok 4.7 på CometAPI?

For prompter under 200K tokens, oppgir CometAPI for tiden $1.60 per million ferske input-tokens, $0.40 per million bufrede input-tokens og $4.80 per million output-tokens. De oppgitte langkontekst-satsene er henholdsvis $3.20, $0.80 og $9.60 per million tokens.

Hvor mye koster én Grok 4.7 API-forespørsel?

Det avhenger av fersk input, bufret input, output og aktiv kontekstsats. Multipliser hver token-mengde med sin sats per million, legg sammen resultatene og del på én million. Ta også med nye forsøk og hvert modellkall i en flertrinns arbeidsflyt.

Hva er den enkleste måten å redusere Grok 4.7 API-kostnader på?

Start med den største målte kostnadsdriveren. Gjentatte lange instruksjoner drar vanligvis nytte av caching; voksende agenthistorikker av komprimering; ordrike svar av en lavere output-grense. Bekreft at kvaliteten forblir akseptabel etter hver endring.

Betyr et 500K kontekstvindu at jeg bør sende 500K tokens?

Nei. Kontekstvinduet er en kapasitetsgrense, ikke en anbefaling. Både xAI direkte priser og CometAPIs nåværende oppføring bruker høyere langkontekst-satser ved 200K prompt-terskelen, så applikasjoner bør sende bare den konteksten som trengs for oppgaven.

Kan jeg estimere kostnad før jeg kaller Grok 4.7?

Ja. Estimer input-tokens, velg riktig kontekstnivå, legg til en realistisk output-grense, og beregn øvre grense. Etter kallet, erstatt estimatet med faktisk bruksdata for rapportering og optimalisering.