Zhipu Developer Plan: não queime sua cota

O problema

Assinei o Developer (Coding) Plan da Zhipu AI exatamente pela previsibilidade: eu preferia ter um limite (uma cota) fixo por mês em vez de pagar pelo modelo pay-as-you-go — aquele sistema estilo conta de luz, onde você paga exatamente por cada pergunta ou comando enviado. Assim, eu sabia exatamente quanto iria gastar e podia usar o Claude Code (uma ferramenta de inteligência artificial que ajuda a escrever códigos) sem ficar medindo o peso de cada requisição (ou seja, de cada pedido feito à IA).

Funcionou por uns dias. Aí, numa manhã, eu acordei e a cota diária tinha acabado — e eu mal tinha usado o sistema!

A minha primeira reação foi achar que “a Zhipu me roubou”. A segunda, bem mais útil, foi investigar. Foi aí que descobri uma pegadinha silenciosa que não estava em nenhuma documentação: modelos de IA diferentes consomem a cota em pesos diferentes. Para piorar, o mapeamento que eu tinha feito no LiteLLM (uma ferramenta que funciona como uma “ponte” ou central de atendimento, direcionando nossos pedidos para os modelos de IA corretos) estava mandando as chamadas mais frequentes justamente para os modelos mais “pesados” e caros.

Este artigo é o que eu gostaria de ter lido antes de queimar uma cota inteira de madrugada. Não é teoria — é o comportamento real que observei direto no painel de uso da minha conta.

O multiplicador que ninguém documenta

Durante o uso, notei um padrão que não fazia sentido: quando eu direcionava os modelos de “subagente” (que são como pequenos assistentes secundários de IA, como o claude-haiku e o claude-fable, especializados em tarefas simples) para rodar no GLM-Turbo ou GLM-5.2 (Fable), a minha cota subia muito mais rápido do que a contagem de tokens justificava.

(Caso você não saiba, tokens são as “moedinhas” do mundo da IA: pequenas pedaços de palavras ou caracteres que o sistema usa para medir o tamanho de um texto).

Por outro lado, os modelos realmente pesados (GLM-5.1 Opus, GLM-5.0 Sonnet) não multiplicavam o consumo da mesma forma — eles cobravam exatamente pelo que processavam, e ponto final.

Eu não tenho o multiplicador exato, porque a Zhipu não divulga a fórmula matemática e eu não fiz um teste de laboratório super controlado para medir os números. Mas o que posso afirmar, porque medi na prática no meu painel, é que a taxa de consumo varia dependendo do modelo, e colocar esses subagentes auxiliares para rodar nos modelos de maior peso vai esgotar sua cota diária numa fração do tempo que você esperava.

Calibração honesta: tudo isso foi observado na minha conta pessoal, no plano Developer, em julho de 2026. A Zhipu pode alterar a política de cobrança a qualquer momento. Por isso, pense nisso como um sinal de alerta (“vale a pena checar a sua conta”), e não como uma regra esculpida em pedra.

Por que isso quebra com o Claude Code

O Claude Code não faz apenas uma pergunta por vez. Ele trabalha disparando várias chamadas ao mesmo tempo (em paralelo) através de subagentes — que são tarefas divididas como: ler arquivos, fazer grep (buscar textos ou palavras específicas no seu projeto de código) ou pesquisar coisas na web. Cada subagente desses conta como uma chamada (inferência) separada para a IA.

Se você configurou todos os modelos da sua ponte (o LiteLLM) para apontar para o GLM-5.2 ou GLM-Turbo (só porque eles pareciam “rápidos e modernos”), esses pequenos subagentes vão devorar toda a sua cota antes mesmo de o modelo principal ter a chance de fazer o trabalho pesado de verdade. O resultado é ver a cota sumindo, o seu projeto não avançando e você sem entender nada.

A solução no arquivo de configuração (config.yaml) é definir uma hierarquia (uma ordem de importância) bem clara:

model_list:
  # Modelo principal: o que faz o trabalho pesado. Pode ser o mais caro.
  - model_name: claude-sonnet-4-5
    litellm_params:
      model: openai/glm-4-plus

  # Subagentes: o que faz tarefas mecânicas em paralelo. Precisa ser leve.
  - model_name: claude-haiku-4-5
    litellm_params:
      model: openai/glm-4-airx   # sem Deep Thinking, limite paralelo alto

A lógica por trás disso é simples: na maioria das vezes, os subagentes só precisam fazer coisas básicas, como “leia este arquivo e me devolva o texto”. Eles não precisam “raciocinar” profundamente — só precisam ser rápidos e baratos. Deixar o modelo caro apenas para a tarefa principal (inference principal) muda completamente o tempo que a sua cota vai durar.

Um monitor de cota no terminal

Não há nada mais chato do que ter que abrir o site da Zhipu toda hora só para ver quanto do seu limite você já gastou. Para resolver isso, criei um pequeno comando para o terminal (a famosa “tela preta” de comandos) dentro do arquivo de configurações .bashrc. Ele mostra o consumo direto na tela usando um gráfico de barras simples:

claude-glm-usage() {
    # Chamada pra API de quota da Zhipu (plano Developer)
    local RESPONSE
    RESPONSE=$(curl -s -X GET "https://open.bigmodel.cn/api/paas/v4/user/quota" \
      -H "Authorization: Bearer ${ZHIPU_API_KEY}")

    # Extrai os valores com jq (sudo apt install jq se não tiver)
    local DAILY_LIMIT DAILY_USED
    DAILY_LIMIT=$(echo "$RESPONSE" | jq -r '.data.daily_limit')
    DAILY_USED=$(echo "$RESPONSE"  | jq -r '.data.daily_used')

    # Percentual inteiro
    local PERCENT=$(( 100 * DAILY_USED / DAILY_LIMIT ))

    echo "📊 Zhipu AI - Consumo diário"
    echo "============================="
    echo "Tokens usados: $DAILY_USED / $DAILY_LIMIT"

    # Barra de progresso ASCII
    local BAR_SIZE=40
    local FILLED=$(( BAR_SIZE * PERCENT / 100 ))
    local EMPTY=$(( BAR_SIZE - FILLED ))
    printf "Uso: ["
    printf "%${FILLED}s" | tr ' ' '#'
    printf "%${EMPTY}s"  | tr ' ' '-'
    printf "] %d%%\n" "$PERCENT"

    if [ "$PERCENT" -ge 90 ]; then
        echo "⚠️  ALERTA: cota diária quase no fim."
    fi
}

O comando usa o curl (uma ferramenta que busca dados da internet pelo terminal) e o jq (um leitor que organiza esses dados) para montar uma barra em texto (ASCII).

Depois de salvar o arquivo e rodar o comando source ~/.bashrc para atualizar o terminal, basta digitar claude-glm-usage para ver exatamente quanto da sua cota resta antes de iniciar uma tarefa pesada.

Aviso honesto: o endereço de consulta da cota (/user/quota) e os nomes dos campos de dados (daily_limit, daily_used) foram os que funcionaram para mim no momento em que escrevi o texto. A Zhipu já alterou essa estrutura no passado; se o comando retornar em branco, vale dar uma olhada na documentação atualizada deles. O esqueleto do código (curl + jq + barra em texto) serve para qualquer serviço que te devolva dois números de consumo.

O que aprendi

A grande lição que fica para além deste caso é: previsibilidade de plano não é a mesma coisa que previsibilidade de consumo. Assinar um plano com limite fixo te diz o quanto você pode gastar, mas não diz o quão rápido você vai gastar.

Quando o seu uso sair do controle, a primeira coisa a se perguntar não deve ser “será que é um bug?”, mas sim “quem, nas minhas configurações, está gastando mais do que eu imagino?”. Em sistemas onde vários assistentes de IA trabalham juntos ao mesmo tempo, o consumo total é a soma de pequenos processos que você nem vê acontecer.

Ter um monitor no terminal não é capricho: é o único jeito de garantir que aquilo que você acha que está gastando seja exatamente o que está saindo da sua conta.

Leia também

• Rclone com Google Drive: resolvi o erro 400 invalid_scope
• Como a IA construiu a ponte claude-oc (DeepSeek no Claude Code) sem eu programar nada
• LiteLLM: o tradutor invisível entre Claude Code e qualquer API