Grok 4.7 API-prijzen op CometAPI: officiële baseline, kostenramingen en besparingen

xAI beschrijft Grok 4.7 als zijn toonaangevende model voor coderen, agentgestuurde taken en kenniswerk, met een contextvenster van 500.000 tokens. Volgens xAI’s huidige prijspagina zijn directe API-tarieven onder 200.000 prompttokens $2,00 per miljoen invoertokens, $0,50 per miljoen gecachete tokens en $6,00 per miljoen uitvoertokens. Zodra een prompt 200.000 tokens of meer bereikt, vermeldt xAI respectievelijk $4,00, $1,00 en $12,00. Dit zijn xAI-directe tarieven, geen universele prijs op platforms van derden.

De werkelijke uitgaven hangen van meer af dan alleen het hoofdtarief voor invoer. Nieuwe invoer, gecachete invoer, uitvoer, retries, tool-calls en het aantal modelaanroepen in een agent-workflow kunnen allemaal de rekening beïnvloeden. De drempel van 200K is vooral belangrijk, omdat zowel xAI als CometAPI hogere lang-contexttarieven publiceren zodra die grens wordt bereikt.

Deze gids legt eerst de xAI-prijsbasis vast en vergelijkt vervolgens de huidige CometAPI Grok 4.7-vermelding. Per 28 september 2026 vermeldt CometAPI $1,60 / $0,40 / $4,80 per miljoen nieuwe-invoer-, geacachte-invoer- en uitvoertokens in de standaardlaag, en $3,20 / $0,80 / $9,60 in de lang-contextlaag—20% lager dan de overeenkomstige xAI-directe tarieven. De volgende secties leggen uit hoe je werklastkosten berekent, verspilling vermindert en het model via CometAPI gebruikt. Alle prijzen zijn momentopnames en moeten vóór productiegebruik opnieuw worden gecontroleerd.

xAI Direct vs. CometAPI Grok 4.7-prijzen

xAI-directe tarieven (USD per 1M tokens)

CometAPI-tarieven (USD per 1M tokens)

De 200K-promptgrens is relevant omdat beide platforms momenteel lang-contexttarieven op het dubbele van hun standaardtarieven vermelden voor Grok 4.7. Dit is een prijsregel per API-platform, geen wijziging in de mogelijkheden van het model. Een verzoek wordt duurder wanneer een applicatie herhaaldelijk grote prompts verstuurt of agentgeschiedenis ongeremd laat groeien—niet simpelweg omdat Grok 4.7 een contextvenster van 500K ondersteunt.

Voor budgettering: behandel elk verzoek dat naar verwachting de grens zal bereiken als lang-context totdat het actieve factureringsgedrag is geverifieerd. Modelbeschikbaarheid en prijzen kunnen veranderen, dus productiecalculators moeten zowel de xAI directe prijzen als de huidige CometAPI-modelpagina opnieuw controleren in plaats van permanente waarden hard te coderen.

De formule voor het schatten van Grok 4.7-kosten

Schat één verzoek door elke tokencategorie apart te prijzen:

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

Zet de verzoekschatting vervolgens om in een werklastschatting:

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

Gebruik een realistische percentielwaarde in plaats van één gemiddelde. Een p50-schatting beschrijft een normale aanvraag, maar p95-invoer- en uitvoerlengtes laten de dure staart zien die vaak de rekening bepaalt. Voor agent-workflows vermenigvuldig je met het verwachte aantal modelaanroepen per voltooid taak. Een workflow van vijf stappen is vijf factureerbare aanroepen, niet één.

Voorbeeld 1: een support-copilot

Neem aan dat één supportverzoek 6.000 nieuwe invoertokens verstuurt en 800 uitvoertokens genereert. Het blijft onder de drempel van 200K en ontvangt geen cachediscount.

• Invoer: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
• Uitvoer: 800 × $4.80 ÷ 1,000,000 = $0.00384
• Totaal: $0.01344 per verzoek

Bij 100.000 verzoeken per maand zijn de geschatte tokenkosten $1.344. Als evaluatie uitwijst dat een antwoord van 400 tokens net zo goed presteert als een antwoord van 800 tokens, daalt de schatting naar $0.01152 per verzoek, of $1.152 per maand. Die enkele uitvoercap bespaart ongeveer $192 per maand, of 14,3%, zonder het model te wijzigen.

Dit is waarom uitvoercontrole aandacht verdient. Tegen het vermelde CometAPI-tarief kosten uitvoertokens driemaal zoveel als nieuwe invoertokens in dezelfde laag.

Voorbeeld 2: een stabiel 20K-tokenprefix hergebruiken

Stel dat elk verzoek een producthandleiding van 20.000 tokens bevat, 2.000 tokens aan nieuwe conversatiecontext en een respons van 600 tokens.

Zonder cache-hit is de schatting:

• 22.000 nieuwe invoertokens: $0.03520
• 600 uitvoertokens: $0.00288
• Totaal: $0.03808 per verzoek

Als het stabiele prefix van 20.000 tokens als invoer uit cache wordt gefactureerd terwijl slechts 2.000 tokens nieuw blijven, wordt de schatting:

• 20.000 invoertokens uit cache: $0.00800
• 2.000 nieuwe invoertokens: $0.00320
• 600 uitvoertokens: $0.00288
• Totaal: $0.01408 per verzoek

Bij 100.000 verzoeken is dat $1.408 in plaats van $3.808—een geschatte besparing van $2.400, of 63,0%. De besparing is niet automatisch: het eerste verzoek, een gewijzigd prefix of een route die geen cache-hit oplevert, kan nog steeds tegen het tarief voor nieuwe invoer worden gefactureerd. Controleer het aantal gecachete tokens in daadwerkelijke gebruiksdata voordat je de schatting als gerealiseerde besparing beschouwt.

Voorbeeld 3: de kosten van het overschrijden van 200K

Beschouw een langlopende agentaanvraag met 210.000 prompttokens en 2.000 uitvoertokens. Met de vermelde lang-contexttarieven:

• 210.000 nieuwe invoertokens: $0.67200
• 2.000 uitvoertokens: $0.01920
• Totaal: $0.69120 per run

Als contextcompactie, retrieval-filtering en samenvattings-checkpoints de prompt terugbrengen tot 180.000 tokens terwijl dezelfde uitvoer van 2.000 tokens behouden blijft, is de schatting in de standaardlaag:

• 180.000 nieuwe invoertokens: $0.28800
• 2.000 uitvoertokens: $0.00960
• Totaal: $0.29760 per run

Het verschil is $0.39360 per run, of circa 56,9%. Over 10.000 runs is de geschatte besparing $3.936. De les is niet om nuttige context te verwijderen. Het is om alleen de context te behouden die het antwoord verandert en de rest te samenvatten of via retrieval toe te voegen voordat het verzoek een prijsgrens overschrijdt.

Een Python-calculator voor schattingen vóór de call

De volgende functie gebruikt CometAPI’s momenteel vermelde Grok 4.7-tarieven. Hij past de lang-contextlaag conservatief toe wanneer de totale prompt 200.000 tokens bereikt.

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}")

Dit is een planningsguard, geen factuur. De uiteindelijke kosten hangen af van de werkelijke invoer, gecachete invoer, uitvoer, retries, tool-calls en de actieve prijs op het moment van uitvoering. Sla na elke respons het geretourneerde tokengebruik, het model-ID, de verzoekstatus en de taakuitkomst op. Stem die waarden af op de factureringsgegevens van de provider.

Vijf Grok 4.7-kostenmaatregelen, gerangschikt op waarschijnlijk effect

1. Houd herhaalde context stabiel genoeg voor caching

Plaats statische instructies, productdocumentatie, schema’s en herbruikbare voorbeelden vóór verzoekspecifieke inhoud. Vermijd het wijzigen van tijdstempels, ID’s, witruimte of ordening in een grote gedeelde prefix, tenzij de wijziging nodig is. xAI’s Grok 4.7-richtlijnen bevelen stabiele cache-routeringsidentifiers voor conversaties aan; verifieer bij gebruik van een tussenliggende route welke cachebesturingen en gebruiksvelden worden ondersteund voordat je erop vertrouwt.

Meet cache-hit-tokens en het cache-hit-percentage per werklast. Een theoretische cachediscount heeft geen waarde als de applicatie het prefix voortdurend muteert.

2. Behandel 200K als een engineeringbudget, niet als een doel

Reserveer marge onder de drempel voor systeeminstructies, opgehaalde passages, toolresultaten en de volgende gebruikersbeurt. Voor een agent: compacteer oude beurten tot een gevalideerde samenvatting en bewaar het ruwe transcript buiten de modelcontext. Voor retrieval: rankeer en dedupliceer passages vóór invoeging in plaats van elke match te verzenden.

Volg verdelingen van promptlengtes en waarschuw voordat p95 de drempel nadert. Volgens xAI’s officiële tariefschema geldt, zodra een prompt 200K tokens bereikt, het lang-contexttarief voor alle tokens in dat verzoek. CometAPI vermeldt eveneens een aparte, hogere lang-contextlaag voor Grok 4.7. Dit zijn platformprijsvoorwaarden, geen modelmogelijkheden.

3. Beperk de uitvoer en stem de redeneerinspanning af op een evaluatieset

Stel een applicatieniveau- uitvoercap in die bij het product past. Een classificatieresultaat kan tientallen tokens nodig hebben; een supportantwoord enkele honderden; een onderzoeksrapport mogelijk meer. Deze cap is een budget- en gebruikerservaringscontrole, geen harde limiet van het Grok 4.7-model. xAI’s release notes van 21 september stellen dat Grok 4.7 geen tekstuitvoerlimiet heeft; dat verhindert niet dat een applicatie of een specifieke API-route een eigen verzoeklimiet afdwingt. Bevestig elke endpoint- of SDK-afgedwongen verzoeklimiet bij de route die je daadwerkelijk gebruikt.

Grok 4.7 ondersteunt meerdere niveaus van redeneerinspanning. Gebruik het laagste niveau dat een representatieve evaluatieset doorstaat en reserveer hogere inspanning voor taken waarbij dit een meetbare verbetering oplevert. Het verminderen van redeneren of uitvoer zonder kwaliteitschecks kan retries veroorzaken en de besparing tenietdoen.

4. Wijs dure verzoeken af of vorm ze om vóór de API-aanroep

Schat een bovengrens op basis van invoergrootte en de geconfigureerde uitvoercap. Als het verzoek het productbudget overschrijdt, kan de applicatie de gebruiker vragen de taak te versmallen, geüploade materie te samenvatten, opgehaalde context te verminderen of de klus te verplaatsen naar een goedgekeurde asynchrone workflow. Dit is voorspelbaarder dan de kosten ontdekken na de generatie.

Een ruwe benadering van tekens-naar-tokens kan nuttig zijn als vroege guard, maar mag een tokenizer of daadwerkelijke gebruiksdata niet vervangen. Talen, code, JSON en opmaak kunnen zeer verschillende tokendichtheden opleveren.

5. Optimaliseer kosten per succesvolle taak, niet kosten per call

Een goedkopere call die twee keer faalt in validatie kan duurder zijn dan één succesvolle call. Volg:

• kosten per geaccepteerd antwoord;
• kosten per voltooide agenttaak;
• retry- en fallback-kosten;
• cache-hit-percentage en aandeel gecachete tokens;
• p50- en p95-prompt- en uitvoertokens;
• kwaliteitscore, latentie en percentage menselijke escalaties.

Als routineverkeer de kwaliteit of contextcapaciteit van Grok 4.7 niet vereist, kan CometAPI’s geïntegreerde modelcatalogus het eenvoudiger maken om een modelwisseling door de applicatie te beheren. Houd de routeringsregel expliciet, evalueer elk model op dezelfde taakset en stuur alleen de verzoeken die baat hebben bij Grok 4.7 naar deze route.

Een praktische maandelijkse kostenanalyse

Groepeer eenmaal per week verkeer per feature en vergelijk geschatte kosten met daadwerkelijk gebruik. Begin met de features die verantwoordelijk zijn voor de meeste uitvoertokens, de grootste prompts en het laagste cache-hit-percentage. Bekijk vervolgens dure uitschieters in plaats van de mediane aanvraag blind te optimaliseren.

De rol van CometAPI in het Grok 4.7-kostenmodel

De rol van CometAPI in deze workflow ligt op het API-platformniveau: het biedt toegang tot Grok 4.7, publiceert eigen tokentarieven en documenteert een OpenAI-compatibel eindpunt. Het verandert de onderliggende modelmogelijkheden van Grok 4.7 niet. Teams die al een OpenAI-stijlclient gebruiken, kunnen mogelijk hetzelfde clientpatroon behouden terwijl ze de API-sleutel, basis-URL en model-ID wijzigen, afhankelijk van endpoint-compatibiliteit.

Per 28 september 2026 liggen CometAPI’s vermelde Grok 4.7-tarieven 20% onder de overeenkomstige xAI-directe tarieven in zowel de standaard- als de lang-contextlaag. Dit is een platformprijsvergelijking, geen uitspraak over modelkwaliteit. Controleer vóór productierol-out ook het actieve model-ID, eindpuntparameters, cachegedrag, snelheidslimieten, betrouwbaarheid, support en factureringsvoorwaarden.

Om het model te testen, bekijk de actuele prijzen en toegangsdetails op de CometAPI Grok 4.7-modelpagina. Houd de prijstabel in configuratie, registreer daadwerkelijk gebruik na elke call en voer werklastschattingen opnieuw uit wanneer het model of het productgedrag verandert.

FAQ

Wat is de prijs per token van Grok 4.7 op CometAPI?

Voor prompts onder 200K tokens vermeldt CometAPI momenteel $1,60 per miljoen nieuwe invoertokens, $0,40 per miljoen geacachte invoertokens en $4,80 per miljoen uitvoertokens. De vermelde lang-contexttarieven zijn respectievelijk $3,20, $0,80 en $9,60 per miljoen tokens.

Wat kost één Grok 4.7 API-verzoek?

Dat hangt af van nieuwe invoer, geacachte invoer, uitvoer en de actieve contextlaag. Vermenigvuldig elke tokenhoeveelheid met het tarief per miljoen, tel de resultaten op en deel door een miljoen. Neem ook retries en elke modelaanroep in een meerstapsworkflow mee.

Wat is de eenvoudigste manier om Grok 4.7 API-kosten te verlagen?

Begin met de grootste gemeten kostendriver. Herhaalde lange instructies profiteren doorgaans van caching; groeiende agentgeschiedenissen van compactie; breedsprakige antwoorden van een lagere uitvoercap. Bevestig dat de kwaliteit acceptabel blijft na elke wijziging.

Betekent een contextvenster van 500K dat ik 500K tokens moet versturen?

Nee. Het contextvenster is een capaciteitslimiet, geen aanbeveling. Zowel xAI directe prijzen als CometAPI’s huidige vermelding hanteren hogere lang-contexttarieven bij de 200K-promptdrempel, dus applicaties zouden alleen de context moeten sturen die nodig is voor de taak.

Kan ik de kosten schatten vóór het aanroepen van Grok 4.7?

Ja. Schat invoertokens, kies de juiste contextlaag, voeg een realistische uitvoercap toe en bereken de bovengrens. Vervang na de call de schatting door daadwerkelijk gebruiksdata voor rapportage en optimalisatie.