Coleção de prompts do Grok 4.7: 5 cenários para copiar e usar

TL;DR: 5 cenários, todos executados de verdade no ambiente de produção do HiAPI com o grok-4.7, com a saída colada na íntegra. Custo por execução de $0.007–0.021; rodar os 5 fica em cerca de $0.06. O link abaixo de cada prompt preenche automaticamente o mesmo prompt na página do modelo; basta enviar para reproduzir. O Grok 4.7 já está disponível no HiAPI, abra a página do modelo para testar direto, e novos usuários ganham 200 créditos ao se cadastrar.

Cenário 1: diagnosticar travamento por concorrência

A causa raiz é que o objeto de resposta não é liberado, e a conexão fica ocupando uma vaga no pool do connector.

O ClientResponse retornado por session.get() só devolve a conexão ao TCPConnector quando ocorre release() / close() (ou quando o gerenciador de contexto assíncrono sai). O código atual não usa async with nem chama release() explicitamente. Ler o body não devolve a conexão; além disso, há referência circular entre a resposta e a connection, então a liberação só acontece no __del__ durante o GC de ciclos.

Por padrão, o limite de conexões de cada ClientSession é 100. Os 20 workers têm cada um sua session e enviam requisições em série, com cerca de 250 URLs por worker. Quando as conexões não são devolvidas:

1. As conexões ocupadas recebem RST por timeout de inatividade do servidor ou por limite de conexões, e o aiohttp emite ConnectionResetError na camada de protocolo (não necessariamente lançado no seu await, então o except não captura nem limpa).
2. A vaga continua ocupada. Ao chegar a 100, o próximo session.get() trava em connector.acquire(), e essa espera geralmente não está sujeita ao timeout.
3. Todos os workers ficam presos no acquire, param de chamar queue.get() e task_done(). O event loop não faz novas alocações, o GC de ciclos também para de rodar, o __del__ não consegue recuperar as conexões e ocorre um deadlock. O queue.join() também nunca retorna.

O except Exception: pass só engole exceções da corrotina do usuário e não libera a conexão, por isso o “erro” e o “travamento” aparecem juntos.

Mudança mínima:

async def fetch(url, session):
    async with session.get(url) as r:
        return await r.json()

O async with percorre __aexit__ → release() tanto no retorno normal quanto na exceção:

• A conexão volta imediatamente para o pool, as vagas não chegam a 100, o session.get() não trava mais permanentemente no acquire e os workers continuam consumindo a fila. Isso resolve o travamento.
• A conexão não fica mais ocupada por muito tempo esperando o RST do servidor, e o ConnectionResetError da camada de protocolo também desaparece; mesmo que a conexão realmente caia durante a leitura do body, o gerenciador de contexto ainda devolve/fecha essa conexão, e uma falha não trava o pool. Isso resolve o erro e garante que a fila continue após o erro.

Prompt completo:

O código Python abaixo, quando a concorrência aumenta um pouco, apresenta ConnectionResetError aleatoriamente e depois todo o worker trava e para de consumir a fila. Encontre a causa raiz, dê a correção com a menor mudança possível e explique por que sua correção resolve ao mesmo tempo os dois problemas: “erro” e “travamento”.

```python
import asyncio, aiohttp

async def fetch(url, session):
    r = await session.get(url)
    return await r.json()

async def worker(queue):
    session = aiohttp.ClientSession()
    while True:
        url = await queue.get()
        try:
            data = await fetch(url, session)
            print(data)
        except Exception:
            pass
        queue.task_done()

async def main():
    queue = asyncio.Queue()
    for i in range(5000):
        queue.put_nowait(f"https://api.example.com/item/{i}")
    workers = [asyncio.create_task(worker(queue)) for _ in range(20)]
    await queue.join()

asyncio.run(main())
```

Gerar com este prompt →

grok-4.7, nível de raciocínio high padrão, max_tokens limitado a 6000, execução real de 107.7s, entrada 3,572 / saída 7,301 tokens, cerca de $0.021.

Entregar de uma vez o sintoma, o código e a restrição de “explicar os dois problemas juntos” faz o modelo localizar a causa raiz na camada de pool de conexões, em vez de parar em um ajuste superficial de try-catch.

Cenário 2: revisão de código em JSON

{"issues":[{"severity":"high","line":8,"problem":"A verificação de saldo e a dedução são separadas, há corrida TOCTOU: requisições concorrentes podem passar ao mesmo tempo na verificação de saldo e deduzir duas vezes, causando saldo negativo ou gasto duplo","fix":"Trocar por uma única atualização condicional (como $inc apenas quando balance>=amount) ou usar lock de linha/lock otimista em transação para fazer a verificação e a dedução de forma atômica"},{"severity":"high","line":9,"problem":"A dedução e o crédito são duas operações de escrita independentes, sem transação; se a primeira tiver sucesso e a segunda falhar, o dinheiro desaparece de from e não pode ser revertido","fix":"Colocar as duas atualizações na mesma transação de banco, revertendo tudo se qualquer uma falhar, e confirmar que a conta to existe antes do commit"}]

,"summary":"Essa API de transferência carece de transação atômica, autenticação e validação de entrada; sob concorrência, causa gasto duplo ou perda de dinheiro, e o caminho de exceção ainda deixa requisições penduradas."}

(Trecho: a saída original é um JSON de uma linha; mantidos os dois primeiros problemas high e o summary, o restante omitido)

Prompt completo:

Revise o código de rota Node.js abaixo e encontre todos os problemas que causariam incidentes em produção (segurança, concorrência e vazamento de recursos contam), ordenando por gravidade. Saída estritamente em JSON, formato: {"issues": [{"severity": "high|medium|low", "line": número da linha, "problem": "problema", "fix": "correção"}], "summary": "resumo em uma frase"}.

```js
const express = require('express');
const db = require('./db');
const router = express.Router();

router.post('/transfer', async (req, res) => {
  const { from, to, amount } = req.body;
  const fromAccount = await db.findOne({ id: from });
  if (fromAccount.balance >= amount) {
    await db.update({ id: from }, { $inc: { balance: -amount } });
    await db.update({ id: to }, { $inc: { balance: amount } });
    res.json({ ok: true });
  } else {
    res.status(400).json({ ok: false });
  }
});

module.exports = router;
```

Gerar com este prompt →

grok-4.7, nível de raciocínio high padrão, max_tokens limitado a 4000, execução real de 40.1s, entrada 3,576 / saída 2,734 tokens, cerca de $0.010.

Ao escrever diretamente no prompt o esqueleto JSON desejado (nomes dos campos, regra de ordenação), o grok-4.7 segue o formato estritamente, e o resultado já entra no pipeline.

Cenário 3: comparação de soluções técnicas

Recomendo usar “heartbeat de atividade + TTL no Redis + polling curto sob demanda”, e não adotar WebSocket/SSE para push de presença em massa. Para ficar cinza após 5 minutos não é necessário push de nível de segundo; com 100k DAU, o polling aguenta bem e combina mais com Next.js.

Comparação de soluções

	Polling	SSE	WebSocket
Direção	Cliente puxa	Servidor empurra unidirecional	Bidirecional
Encaixe com “cinza após 5 minutos sem atividade”	Alto. Atualizar a cada 30–60s basta para o ponto verde	Médio. Push é mais rápido, mas o timeout para ficar cinza ainda precisa ser calculado	Baixo a médio. Conexão online ≠ usuário ativo
Adaptação ao Next.js	Melhor. Route Handler comum	Ruim. Conexões longas são hostis a Serverless/múltiplas instâncias	Pior. Exige processo WS separado, sessão fixa ou terceiros
Custo de conexão	Sem conexões longas	1 por usuário online	1 por usuário online, além de heartbeat para manter vivo
Escala	Sem estado, escala horizontal simples	É preciso gerenciar desconexão, reconexão e fan-out em múltiplas instâncias	O mesmo, e mais pesado
Modo de falha	Uma requisição falha, a próxima puxa de novo	Após desconexão, o estado para de atualizar e é preciso buscar de novo	Idem, com gateway mais complexo
Vale a pena com 100k DAU	Vale, como solução padrão	Só vale se já houver canal de push	Só vale se já houver gateway de chat/colaboração

Estimativa rápida de pico: 100 mil DAU, com online simultâneo entre 5% e 15%, cerca de 5 mil a 15 mil. Heartbeat a cada 45 segundos dá cerca de 100–300 escritas/s; cada pessoa puxa a cada 30 segundos um lote de status dos usuários visíveis, e a leitura também fica na zona confortável do Redis. O gargalo não estará no “ponto verde”.

Recomendação e justificativa

Usar Redis como fonte da verdade da presença online, PostgreSQL apenas para o last_seen frio, e o cliente só faz polling dos usuários visíveis na tela atual.

1. A semântica do produto é “5 minutos sem atividade”, não “TCP ainda conectado”. Uma página parada deve ficar cinza, então mesmo com WS seria necessário um heartbeat de atividade separado. A conexão em si não resolve o requisito.
2. O ponto verde tolera dezenas de segundos de erro. Intervalo de polling de 30–60 segundos é suficiente para a janela de 5 minutos.
3. Next.js (especialmente Vercel / Serverless) não é adequado para conexões longas. WS/SSE arrastam você para um serviço de tempo real separado, roteamento fixo e compensação de desconexão, com pouco ganho.
4. Quem deve ver o status de quem costuma ser local (amigos, lista de conversas, avatares da página atual), não um broadcast global. Consultar o Redis em lote por id é uma ordem de grandeza mais simples do que manter relações de assinatura.
5. A expiração de chave no Redis expressa naturalmente “saiu por timeout”, sem depender de keyspace notification ou varredura completa de tabela.

Presença por usuário como online (solução principal recomendada):

```text
presence:u:{userId}   STRING  valor = unix em milissegundos do servidor
                      TTL = 300 segundos
                      no heartbeat, SET key value EX 300
                      online = chave existe
```

Não use hora do cliente. Não é necessário TTL de 2–3 vezes o intervalo de heartbeat; aqui o heartbeat é de 45–60 segundos e o TTL é de 300 segundos, então perder dois ou três heartbeats ainda conta como online, coerente com “5 minutos sem atividade”.

(Trecho: conclusão da recomendação, os 5 primeiros motivos e a solução principal por usuário no design de chaves Redis)

Prompt completo:

Quero adicionar “status online em tempo real” a uma aplicação Web com 100 mil DAU (ponto verde ao lado do avatar do usuário, fica cinza após 5 minutos sem atividade). A stack é Next.js + PostgreSQL + Redis. Primeiro faça a comparação de soluções (WebSocket / SSE / polling), diga qual você recomenda e por quê, depois liste os passos de implementação e o design das chaves Redis. Não escreva código completo; trechos-chave podem ser colados.

Gerar com este prompt →

grok-4.7, nível de raciocínio high padrão, max_tokens limitado a 6000, execução real de 69.8s, entrada 3,429 / saída 4,247 tokens, cerca de $0.014.

Primeiro limitar a stack e o volume de negócio, depois pedir “comparar antes de recomendar”; a saída já é uma proposta pronta para revisão, e não uma explicação neutra.

Cenário 4: explicação de conceitos

Vamos primeiro deixar o cenário claro. Suponha que você está fazendo um pedido: é preciso gravar o pedido no banco e também enviar uma mensagem para a fila, para que estoque, pontos e notificações trabalhem a jusante. As duas ações não estão na mesma “transação”; se qualquer uma falhar no meio, o sistema fica com uma fenda de “um lado deu certo, o outro não aconteceu”.

Por que gravar primeiro no banco e depois enviar a mensagem pode perder mensagens

O commit no banco deu certo e o pedido já está gravado. Em seguida o processo precisa enviar a mensagem, e aí pode acontecer:

• a rede oscila e não dá para enviar;
• a fila de mensagens está temporariamente indisponível;
• mais comum ainda, o processo quebra entre o commit do banco e o envio da mensagem (reinício da máquina, OOM, deploy em rolagem).

O pedido está no banco, mas a mensagem nunca foi enviada. A jusante não sabe da existência desse pedido, o estoque não é deduzido, a notificação não sai. Tentar de novo depois não resolve — o processo que quebrou já não existe; a menos que você tenha feito uma compensação confiável à parte, essa mensagem se perdeu. Para quem só trabalhou com monólito, é como: você anota “recebido” no livro-caixa, vai ao correio enviar a carta de aviso, a carta se perde no caminho, mas o livro-caixa já foi alterado, e os dois lados não batem.

(Trecho: mecanismo de perda de mensagem em “gravar no banco antes de enviar a mensagem” e a metáfora central)

Prompt completo:

Explique, em linguagem que um engenheiro backend com 3 anos de experiência mas que nunca teve contato com sistemas distribuídos entenda, por que “gravar primeiro no banco e depois enviar para a fila de mensagens” pode causar perda de mensagens, e por que “enviar primeiro para a fila e depois gravar no banco” também não funciona. Mostre para quais cenários servem as duas abordagens corretas comuns do mercado (tabela de mensagens local / mensagem transacional).

Gerar com este prompt →

grok-4.7, nível de raciocínio high padrão, max_tokens limitado a 4000, execução real de 41.3s, entrada 3,410 / saída 2,478 tokens, cerca de $0.009.

Usar “explicar para uma pessoa com um perfil específico” em vez de “explicar bem” faz o modelo escolher a granularidade certa: a metáfora do livro-caixa e do correio veio daí.

Cenário 5: script de análise de dados

```python
import pandas as pd
import numpy as np

# dados de exemplo (substitua pelo seu df real)
np.random.seed(42)
n = 500
df = pd.DataFrame({
    "order_id": range(1, n + 1),
    "user_id": np.random.randint(1, 80, n),
    "amount": np.round(np.random.uniform(20, 500, n), 2),
    "created_at": pd.date_range("2023-01-01", periods=n, freq="D").astype(str),  # datas simuladas como string
    "status": np.random.choice(["paid", "paid", "paid", "cancelled"], n),
})

# ---------- 0. Tratamento de datas: converter string para datetime ----------
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df.dropna(subset=["created_at", "amount", "user_id"])

# Opcional: contar apenas pedidos válidos (ajuste os valores de status conforme o negócio real)
df_valid = df[df["status"] == "paid"].copy()

# ---------- 1. GMV e número de pedidos por mês ----------
df_valid["month"] = df_valid["created_at"].dt.to_period("M")
monthly = (
    df_valid.groupby("month", as_index=False)
    .agg(GMV=("amount", "sum"), order_count=("order_id", "count"))
    .sort_values("month")
)
monthly["month"] = monthly["month"].astype(str)
print("=== GMV e número de pedidos por mês ===")
print(monthly)
```

(Trecho: primeira metade do código (tratamento de datas + GMV mensal); o ranking de usuários e a tendência do primeiro pedido ficaram omitidos)

Prompt completo:

Estou analisando dados de pedidos de e-commerce com pandas; o dataframe df tem as colunas: order_id, user_id, amount, created_at, status. Me dê um código Python completo e executável que calcule: 1) o GMV e o número de pedidos por mês; 2) o ranking de gasto acumulado por usuário (apenas os 20 primeiros); 3) a tendência mensal do valor médio do primeiro pedido de novos usuários. Trate o caso em que created_at é string e comente os passos principais.

Gerar com este prompt →

grok-4.7, nível de raciocínio high padrão, max_tokens limitado a 5000, execução real de 18.5s, entrada 3,440 / saída 1,427 tokens, cerca de $0.007.

Listar os nomes das colunas, as métricas a calcular e os casos de borda (created_at como string) item por item faz o código gerado rodar direto, sem retrabalho.

Como escrever os prompts

1. Cole código real e nomes de coluna reais; não diga “tem um trecho de código”, cole diretamente.
2. Escreva o formato de saída no prompt: se quer JSON, dê o esqueleto JSON; se quer código, diga “completo e executável”.
3. Quanto mais específicas as restrições, melhor: regra de ordenação, apenas os 20 primeiros, não escrever código completo, apenas trechos-chave.

Perguntas frequentes

Esses prompts podem ser usados diretamente? Podem. Os 5 são prompts originais que executamos de verdade no HiAPI, e as saídas são resultados reais. Clique em “Gerar com este prompt” abaixo de cada um; a página do modelo já vem preenchida e basta trocar pelo seu código ou dados para usar.

Como é a capacidade do grok-4.7 para escrever código? A xAI o posiciona para codificação e trabalho de conhecimento; o Terminal-Bench 4.0 divulgado oficialmente subiu de 20,3% no grok-4.6 para 38,0% (dado oficial). O diagnóstico de causa raiz do cenário 1 e a lista de revisão do cenário 2 são resultados que obtivemos na prática; você pode julgar por conta própria.

Quanto custa mais ou menos uma chamada? Pelo preço da plataforma HiAPI (entrada $0.84 / saída $2.52 por 1M tokens), os 5 juntos somam cerca de $0.06. O mais barato, o cenário 5, sai por cerca de $0.007; o mais caro, o cenário 1, cerca de $0.021.

Para que serve o contexto de 500K? Dá para colar os arquivos de um repositório de porte médio ou centenas de páginas de log em uma única requisição para revisão, diagnóstico ou refatoração, sem precisar dividir. Prompts curtos do dia a dia não usam todo o contexto e não cobram a mais; a cobrança é por token real.

Continue lendo

• Quanto custa a API do Grok 4.7? — três níveis de raciocínio, preço para documentos longos e matriz de orçamento mensal
• Grok 4.7 vs Grok 4.6 — mesmo preço, quando usar cada um
• Guia de integração da API do Grok 4.7 — faça a primeira requisição em 5 minutos
• Página do modelo Grok 4.6 — uso completo do flagship da geração anterior
• Página do modelo Grok 4.7 — teste online, parâmetros e preço em tempo real