Gemini CLI "Requests ending with a model turn are not supported" ao ler imagem: como resolver

Você pediu para o Gemini CLI olhar uma imagem, o ReadFile leu o .png com sucesso e, no turno seguinte, veio um 400 INVALID_ARGUMENT com a mensagem Requests ending with a model turn are not supported. Daí em diante, toda chamada na mesma sessão falha igual. Na versão 0.66.0 (a latest no npm em 04/11/2026), a causa confirmada é um teste de nome de modelo que não reconhece IDs com ponto, como gemini-3.8-flash. Saia da sessão com /clear e escolha um dos três contornos abaixo.

Como é o erro "Requests ending with a model turn are not supported"?

É uma sequência de três linhas, nesta ordem, logo depois de ler uma imagem. O relato da issue google-gemini/gemini-cli #30074 mostra exatamente isto:

✓ ReadFile Screenshot (209).png → Read image file: Screenshot (209).png
[System: You successfully executed a tool but returned an empty response. Please analyze the tool output and explain your progress or final answer.]
✕ [API Error: [{
  "error": {
    "code": 400,
    "message": "Requests ending with a model turn are not supported.",
    ...
    "status": "INVALID_ARGUMENT"
  }
}]]

A linha do meio, que começa com [System: You successfully executed a tool but returned an empty response, é o sinal de que o modelo respondeu vazio depois da leitura. Se ela aparece antes do 400, você está neste caso.

Por que o Gemini CLI quebra ao ler imagem?

Porque, na 0.66.0, a imagem não chega ao modelo dentro da resposta da ferramenta. A função supportsMultimodalFunctionResponse, em packages/core/src/config/models.ts, decide isso com model.startsWith('gemini-3-'). IDs com ponto não passam nesse teste, então a imagem vai como parte solta ao lado do functionResponse, em vez de aninhada nele. A descrição do PR #29982, que corrige isso, explica o mecanismo.

Sem a imagem, o modelo devolve resposta vazia, o CLI injeta o aviso de resposta vazia e o histórico enviado à API termina num turno do modelo. A API recusa esse formato com o 400. Esse encadeamento final é a análise dos colaboradores na issue #30074, não uma afirmação oficial do Google.

Como sair da sessão travada?

Rode /clear. Segundo a referência de comandos, ele limpa o contexto da conversa e começa uma sessão nova. Tentar de novo na mesma sessão não adianta: o histórico já termina no turno errado e cada nova chamada repete o 400.

/clear

Antes de pedir a imagem de novo, aplique um dos contornos abaixo. Sem isso, a próxima leitura de imagem trava a sessão nova do mesmo jeito.

Como fazer o read_file com imagem funcionar na 0.66.0?

Ligue a configuração dinâmica de modelos. Com ela ativa, a mesma função ignora o teste de prefixo e consulta a definição do modelo, e na 0.66.0 todos os modelos Gemini 3 da tabela acima vêm com multimodalToolUse: true em defaultModelConfigs.ts. Edite o ~/.gemini/settings.json:

{
  "experimental": {
    "dynamicModelConfiguration": true
  }
}

A doc de configuração marca a chave como Requires restart: Yes, então feche e abra o CLI. É uma opção experimental que também muda como definições e resoluções de modelo são lidas. Se algo estranho aparecer no /model, volte para false.

Dá para mandar a imagem sem passar pela ferramenta?

Sim, com @ no próprio prompt. O @caminho usa o read_many_files por dentro e insere o conteúdo na sua mensagem, não numa resposta de ferramenta, então o problema do functionResponse não acontece.

@docs/tela-login.png o botão de entrar está desalinhado, o que mudou no CSS?

Dois cuidados, os dois no código da 0.66.0. Imagem só entra se você nomear o arquivo ou a extensão: com @docs/ sozinho, ela é pulada com o motivo asset file (image/pdf/audio) was not explicitly requested by name or extension. E espaço no caminho precisa de barra invertida, como em @capturas\ de\ tela/login.png.

Qual versão do Gemini CLI já tem a correção?

Só a nightly, por enquanto. O PR #29982 entrou na main em 28/10/2026, um dia depois da 0.66.0. Conferimos o arquivo em cada canal do npm:

npm install -g @google/gemini-cli@nightly

Nightly é build diária e pode trazer outros problemas. Para voltar à estável, rode npm install -g @google/gemini-cli@latest. A issue #30074 continua aberta: um colaborador apontou um segundo ponto, a ordem entre ensureTerminalUserTurn() e stripToolCallIdPrefixes() em geminiChat.ts, que ainda pode deixar o histórico terminando no turno do modelo. Se o erro voltar mesmo na nightly, o @caminho segue sendo o contorno mais seguro.