Grok 4.7 no Cursor e na API da xAI: Cálculo de Preços, Modos de Effort, Modo Fast e Cache de Contexto

A integração do Grok 4.7 (identificador do modelo: grok-4.7) ao Cursor despertou grande interesse entre os desenvolvedores. A interface do editor introduziu novos controles: profundidade de raciocínio (reasoning_effort) e um seletor para o modo Fast. Desde o lançamento, no entanto, surgiram dúvidas em torno dessas configurações: como elas afetam o consumo do limite da assinatura (allowance) e quantas requisições são deduzidas em tarefas típicas de desenvolvimento?

A principal armadilha metodológica é tentar deduzir as regras de cobrança do Cursor diretamente das tarifas públicas da API da xAI. Para tomar decisões embasadas, é essencial separar dois níveis distintos: os preços oficiais da xAI (incluindo o cache de contexto e o limite de contexto longo) e as regras internas de cota do Cursor, que só podem ser confirmadas por meio da observação direta na conta.

---

Discussão na Comunidade: Incerteza Sobre o Allowance e Falta de Benchmarks

A discussão sobre o novo modelo teve início em 23 de setembro na comunidade r/cursor, após uma publicação do usuário IACROS, destacando o menu de seleção de modelos atualizado.

Na discussão, o usuário diymuppet apontou a indefinição em relação aos custos de uso:

“…não há uma ideia clara sobre o custo do allowance… High / Extra High — o que isso significa para mim pessoalmente?”

O membro da comunidade abjectchain96 desaconselhou o uso do modo Fast, supondo que ele acarretaria custo em dobro, e sugeriu mapear os níveis de esforço de raciocínio de acordo com a complexidade da tarefa.

Apesar de parecer lógica, a discussão não apresentou nenhum benchmark controlado ou extrato verificado do saldo no Cursor. Os participantes compartilharam suposições sem medir o consumo real de cotas. Concluir como os limites de allowance são consumidos com base apenas em especulações de fórum não é confiável: as regras de cobrança são definidas pelos termos da assinatura do Cursor, e não por estimativas da comunidade.

---

Preços Oficiais da API da xAI: Contexto Curto vs. Longo

Na API pública da xAI, o grok-4.7 conta com uma janela de contexto de 500.000 tokens e corte de conhecimento (knowledge cutoff) em maio de 2026. As tarifas-base estão publicadas na página oficial de preços da xAI.

Contexto Padrão (< 200k Tokens)

Para requisições em que o tamanho total de entrada permaneça abaixo de 200.000 tokens, aplicam-se as tarifas padrão:

• Entrada Não Em Cache (Uncached Input): $2.00 por 1M tokens
• Entrada Em Cache (Cached Input): $0.50 por 1M tokens
• Tokens de Saída (Output Tokens, incluindo raciocínio): $6.00 por 1M tokens

Exemplo de Cálculo de Consulta a $0.27

Considere uma requisição isolada à API com os seguintes parâmetros:

• Entrada não em cache: 100.000 tokens (contexto base, instruções do sistema, código da tarefa)
• Entrada em cache: 20.000 tokens (histórico inalterado da sessão)
• Tokens de saída: 10.000 tokens (tokens de raciocínio mais a resposta gerada)

Detalhamento passo a passo:

1. Entrada não em cache: $100,000 \times \frac{$2.00}{1,000,000} = $0.20$
2. Entrada em cache: $20,000 \times \frac{$0.50}{1,000,000} = $0.01$
3. Saída: $10,000 \times \frac{$6.00}{1,000,000} = $0.06$
4. Custo total da consulta: $$0.20 + $0.01 + $0.06 = \mathbf{$0.27}$

Limite de Contexto Longo (≥ 200k Tokens)

A API da xAI utiliza uma cobrança escalonada: assim que a entrada total do prompt atinge ou ultrapassa 200.000 tokens, as tarifas elevadas passam a incidir sobre todos os tokens daquela requisição, e não apenas sobre o excedente marginal.

Tarifas para contexto ≥ 200k:

• Entrada não em cache: $4.00 por 1M tokens
• Entrada em cache: $1.00 por 1M tokens
• Tokens de saída: $12.00 por 1M tokens

Exemplo Consistente para uma Requisição ≥ 200k

Considere uma consulta em uma base de código extensa na qual o contexto total de entrada ultrapassa o limite de 200k:

• Entrada não em cache: 180.000 tokens
• Entrada em cache: 40.000 tokens (entrada total: $180,000 + 40,000 = 220,000$ tokens ≥ 200k)
• Tokens de saída: 10.000 tokens

Cálculo:

1. Entrada não em cache: $180,000 \times \frac{$4.00}{1,000,000} = $0.72$
2. Entrada em cache: $40,000 \times \frac{$1.00}{1,000,000} = $0.04$
3. Saída: $10,000 \times \frac{$12.00}{1,000,000} = $0.12$
4. Custo total da consulta: $$0.72 + $0.04 + $0.12 = \mathbf{$0.88}$

Esse limite se aplica estritamente às chamadas diretas da API da xAI. Não é possível projetar o limite de 200k sobre as deduções internas do Cursor: o Cursor gerencia janelas de contexto e limites de planos por meio de mecanismos próprios.

---

Modo Fast: Posicionamento e Especificidades de Preço

O modo Fast é frequentemente confundido com uma versão destilada e leve. De acordo com as especificações da xAI:

1. Arquitetura: É o modelo completo grok-4.7 hospedado em uma infraestrutura otimizada de alta taxa de transferência (throughput) para minimizar a latência de resposta.
2. Disponibilidade: O modo foi projetado para integrações de parceiros (como o Cursor e a plataforma Grok Build) e não é oferecido nos endpoints públicos padrão da xAI.
3. Preços para Parceiros: A xAI define o preço do Fast para parceiros em $4.00 / $1.00 / $12.00 para contexto < 200k (exatamente 2x o padrão) e $6.00 / $1.50 / $18.00 para contexto ≥ 200k (1.5x as tarifas padrão de contexto longo).

Deduções do Modo Fast no Cursor

A estrutura tarifária para parceiros da xAI não significa que o Cursor deduza exatamente duas requisições ou dobre o consumo de allowance. O sistema de cobrança do Cursor opera com base em métricas próprias de uso (fast requests e níveis de assinatura). As deduções reais dependem dos termos do seu plano e só podem ser validadas por meio do acompanhamento direto da conta.

---

Gerenciando o Reasoning Effort e o Prompt Caching

No Grok 4.7, o raciocínio é integrado nativamente à arquitetura do modelo e não pode ser desativado. Os parâmetros presencePenalty, frequencyPenalty e stop não são suportados e causam erros na requisição.

O parâmetro reasoning_effort define a profundidade de análise:

• low: Tempo mínimo de deliberação e menor latência; ideal para edições simples e execuções pontuais de ferramentas.
• medium: Equilíbrio entre velocidade de geração e profundidade na síntese de código.
• high (padrão): Análise arquitetural aprofundada, dependências complexas e algoritmos.
• xhigh: Profundidade máxima de busca de soluções, acompanhada por um aumento perceptível na latência.

A contagem exata de tokens internos de raciocínio não é fixada na documentação pública, e eles são cobrados às tarifas normais de tokens de saída. Não se deve presumir que o nível high seja inútil para tarefas simples nem que o xhigh seja obrigatório para código complexo. A única referência confiável é avaliar a qualidade do código, a latência de resposta e o consumo de allowance diretamente na sua base de código específica.

Como Funciona o Prompt Caching

O mecanismo de Prompt Caching reduz a cobrança sobre contexto invariante repetido:

• Roteamento e Localidade: O fornecimento do parâmetro prompt_cache_key na Responses API ou do cabeçalho x-grok-conv-id em Chat Completions direciona as requisições a nós com cache já aquecido. Isso eleva a probabilidade de cache hit, embora não seja estritamente obrigatório: omitir as chaves não garante que cada chamada subsequente será fria.
• Cache Probabilístico: Os acertos de cache não são garantidos devido a possíveis reinicializações de nós ou descarte de dados. O volume real de cache reconhecido pelo modelo é retornado em usage.prompt_tokens_details.cached_tokens.
• Contexto de Múltiplos Turnos (Multi-Turn): Em sessões de múltiplos turnos, a Responses API retorna um bloco criptografado reasoning.encrypted_content (ou referências via previous_response_id). O envio desse bloco em chamadas subsequentes mantém a continuidade do raciocínio sob a especificação suportada. Contudo, não se deve afirmar que, em outros cenários, o cache certamente será descartado ou o contexto será perdido de forma permanente.
• Invariância de Prefixo: Editar turnos anteriores da conversa, alterar prompts do sistema ou reordenar fragmentos de contexto quebra o prefixo de cache, reduzindo significativamente as taxas de acerto.

---

Protocolo de Benchmark Pareado: Medindo o Allowance no Cursor

Como o consumo de allowance no Cursor não tem uma relação de 1:1 com os valores em dólares da API da xAI ou com o limite de 200k, a única maneira de avaliar o custo real é realizar um benchmark isolado comparando duas tarefas equivalentes.

1. Preparação (Setup)

• Prepare duas tarefas de escopo e complexidade equivalentes no mesmo repositório (por exemplo, Tarefa A e Tarefa B: escrita de suítes de testes para módulos comparáveis).
• Abra o painel de uso da conta do Cursor (configurações de Assinatura / Uso — Subscription / Usage settings).
• Registre as métricas iniciais utilizando o seguinte esquema:

Campo	Exemplo de Registro
Identificador da tarefa	Tarefa A (Standard) / Tarefa B (Fast)
Interface do editor	Chat / Composer
Modelo e modo	Grok 4.7 Standard / Grok 4.7 Fast
Nível de reasoning_effort	medium (idêntico para ambos os testes)
Saldo inicial de allowance	Registrado antes do início
Tempo de geração (Latência)	Tempo decorrido medido (s)
Saldo final de allowance	Registrado após a resposta
Delta de dedução real	Diferença (unidades deduzidas / requisições)
Qualidade da solução	Correção do código, testes aprovados

2. Execução (Execution)

1. Teste 1 (Standard): Inicie uma sessão limpa, selecione Grok 4.7 no modo padrão com esforço medium. Envie a Tarefa A. Registre a duração da geração e anote as deduções de allowance no perfil da sua conta.
2. Teste 2 (Fast): Inicie uma nova sessão limpa com os mesmos arquivos do espaço de trabalho, selecione Grok 4.7 Fast com esforço medium. Envie a Tarefa B. Registre a latência de execução e o novo valor de consumo de cota.

3. Árvore de Decisão (Decision Path)

• Se a dedução do modo Fast for equivalente à do Standard ou a diferença for insignificante, com um ganho perceptível de velocidade: o modo Fast é ideal para chat interativo e depuração rápida.
• Se a dedução do modo Fast for substancialmente maior, e a economia de latência for secundária (por exemplo, em gerações em segundo plano no Composer): mantenha o modo padrão como seu padrão de uso.
• Se a qualidade do código em medium for insuficiente: teste high no mesmo tipo de tarefa, monitorando o aumento da latência e o consumo de cota. Reserve o nível high para lógicas complexas.

4. Solução de Problemas (Troubleshooting)

• O limite de allowance está se esgotando mais rápido do que o esperado:
  • Verifique o detalhamento de uso (usage breakdown) no painel da sua conta no Cursor.
  • Confira o contexto da sessão ativa: conversas longas com dezenas de arquivos anexados expandem o tamanho do prompt, independentemente do modelo escolhido.
  • Consulte as regras atuais do seu plano no Cursor. Evite presumir que o limite de 200k da API da xAI determine a cobrança no editor.
• Latência de resposta excessiva ou sensação de travamento:
  • Reduza o reasoning_effort para medium ou low.
  • Inicie uma nova conversa para evitar o processamento de histórico antigo e redundante.
• Erros de disponibilidade do modelo:
  • Verifique as configurações de provedores e o status de autenticação no Cursor.
  • Ao utilizar uma chave de API própria, confira os saldos e as permissões da conta no console de desenvolvedor da xAI.

---

Referências

1. xAI Docs — Grok 4.7
2. xAI Docs — Reasoning
3. xAI Docs — Prompt Caching in Multi-turn
4. xAI Docs — Pricing
5. Reddit r/cursor — Discussion on Grok 4.7