Claude Code para times: como dar acesso ao time sem cada dev criar a própria chave de API

Fala aí, beleza? Cada dev criando a própria chave de API é o jeito mais rápido de transformar o Claude Code numa linha de custo que ninguém consegue explicar no fim do mês

O cenário é sempre o mesmo: alguém gera uma chave pra "testar", cola no .zshrc, o colega do lado faz igual, e seis meses depois a empresa tem N chaves espalhadas, sem dono, sem teto de gasto e sem nenhuma visão de quem usou o quê

Aqui eu vou por partes: quais são os caminhos oficiais de acesso ao Claude Code em equipe, como o admin liga o controle de gasto, e por que a chave pessoal no ambiente do dev é quase sempre a pior das opções 🙂

Por que chave de API pessoal espalhada vira problema

Duas dores diferentes moram aqui: custo e controle

No custo, a chave de API não é a mesma coisa que a assinatura do time: ela vive no Console, com o próprio consumo, e ainda nasce presa ao workspace onde foi criada, sem poder ser movida pra outro workspace depois

Ou seja, se o time cresceu e reorganizou os workspaces, a chave antiga não acompanha: alguém recria, e a velha continua lá, viva, esquecida

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Agora o pulo do gato, e esse é o que mais pega gente desprevenida

O Claude Code dá precedência para a variável de ambiente ANTHROPIC_API_KEY sobre a assinatura autenticada

Com ela definida no ambiente, o Claude Code pula o prompt de login e pede aprovação da chave, e depois de aprovada é a chave que manda

Traduzindo: o dev pode ter assento pago na organização, achar que está usando o plano da empresa, e estar queimando crédito de API o tempo todo

Ninguém vê, porque o gasto sai por um canal e a licença sai por outro

Os caminhos de acesso ao Claude Code: conta, Team/Enterprise, Console e nuvem

A documentação lista quatro caminhos de autenticação para equipes: conta Claude individual, Claude for Teams ou Enterprise, Claude Console, ou provedor de nuvem (Amazon Bedrock, Google Vertex AI, Microsoft Foundry)

E tem um ponto que a própria documentação faz questão de deixar claro: a escolha do provedor afeta MUITO mais que o preço, ela mexe em billing, autenticação, na postura de compliance herdada e em quais recursos do Claude Code os devs conseguem usar

Sobre uso, o Team tem dois tamanhos de assento: o padrão entrega 1,25x mais uso por sessão que o Pro e o premium entrega 6,25x mais uso por sessão que o Pro

A estrutura de limite semanal também muda: o assento padrão tem um limite semanal que vale pra todos os modelos, e o premium tem dois, um geral pra todos os modelos e outro só pra modelos Sonnet

E se você tá naquela fase de conta de padeiro, tem um post inteiro aqui sobre quantos assentos o time precisa e quando isso passa a fazer mais sentido que cada um pagar o próprio Max

Uma coisa boa de saber: o Claude Code já vem incluído em todo assento do plano Team, padrão e premium

O assento premium não é mais requisito pra acessar o Claude Code, e isso muda bastante a conta pra quem estava segurando o upgrade só por causa disso

No Enterprise, o Claude Code também já vem incluído no assento em planos novos e self-serve, sem compra adicional

Em planos Enterprise antigos ele aparece de outro jeito: em assentos Chat + Claude Code (cobrança por uso) e em assentos Premium (cobrança por assento)

Como adicionar e gerenciar assentos no plano Team

Quem mexe nisso é o Owner ou o Primary Owner, e o caminho é curtinho

1. Entre com a conta Owner ou Primary Owner da organização
2. Vá em Organization settings > Organization and access
3. Em Total seats, clique em Manage
4. Clique em Add or change seats e defina a quantidade
5. Escolha o mix: dá pra ter assentos padrão e premium na MESMA organização Team, e mover usuários entre os dois tipos dentro da alocação que você já tem
6. Confira a cobrança antes de confirmar: assento novo é cobrado de forma proporcional ao ciclo de faturamento e debitado na hora, e o upgrade de padrão pra premium também é proporcional e cobrado na hora pela diferença de preço
7. Se o time passou de 150 assentos, o caminho não é comprar mais no Team: a organização precisa migrar pro Enterprise

O erro comum do passo 4: esquecer que o assento do Primary Owner conta

Cada organização tem um único Primary Owner, e o assento dele consome uma das licenças contratadas

Se você dimensionou a compra pensando só nos devs, vai faltar um 😛

O dev tem assento mas o Claude Code continua cobrando API: como identificar e corrigir

Sintoma: aparece gasto de API mesmo com a assinatura ativa e o dev jurando que nunca configurou nada

Causa: tem uma ANTHROPIC_API_KEY definida no ambiente dele

Com ela lá, o Claude Code pula o prompt de login e pede aprovação da chave, e depois de aprovada a chave passa a ter precedência sobre a assinatura

Solução, e é literalmente meio minuto de terminal

1. Rode o /status dentro do Claude Code pra ver qual método de autenticação está ativo

/status

O painel mostra a linha Login method com a conta de assinatura, e uma linha de API key aparece quando tem chave de API em uso

2. Se a linha de API key estiver lá, tire a variável do ambiente

unset ANTHROPIC_API_KEY

3. Rode o /status de novo pra confirmar que voltou pra assinatura

Erro comum deste passo: rodar o unset só na sessão atual e não olhar de onde a variável vem

Se ela nasce no arquivo de perfil do shell, na próxima aba ela volta inteirinha, e você acha que resolveu

Como prevenir isso na empresa inteira

Aqui entram os managed settings

Server-managed e endpoint-managed settings ocupam o TOPO da hierarquia de configuração do Claude Code: nenhum outro nível sobrescreve, incluindo argumento de linha de comando, salvo exceções documentadas

E as regras de permissão seguem essa MESMA hierarquia (com as mesmas exceções documentadas), com o nível gerenciado no topo: uma regra definida em managed settings não é sobrescrita pelos níveis abaixo, nem por argumento de linha de comando

É a diferença entre pedir por favor no canal do time e resolver de fato

Como controlar gasto e enxergar o uso do time

Acesso de pé é metade do trabalho

A outra metade é enxergar o que está acontecendo antes da fatura contar a história

1. Ligue spend caps: dá pra aplicar teto de gasto em três escopos, na organização inteira, num usuário individual ou num grupo (nesse caso cada membro recebe o limite)
2. Configure os alertas: no nível da organização, os avisos disparam em 75% e em 90% do limite de gasto, antes do bloqueio
3. Exporte o relatório detalhado: tem exportação em CSV com visibilidade por usuário e por modelo, mostrando consumo de tokens e gasto estimado no período selecionado, com atualização diária
4. Acompanhe o dashboard de analytics do Claude Code, disponível para Admins e Owners no Team e no Enterprise, com métricas tipo usuários ativos diários, sessões, linhas de código aceitas e taxa de aceite de sugestões
5. Se você quer isso dentro do seu próprio painel, existe a Claude Code Analytics API documentada na plataforma

No Console a lógica é outra: o recorte do controle não é a organização nem o usuário, é o workspace

Workspaces são ambientes dentro da organização do Console pra separar recursos de API por caso de uso, cada um com limite de gasto e de rate limit próprios

O teto mensal e os alertas ficam na aba Spend limits, por workspace

E dá pra fazer tudo isso de forma programática: a Admin API gerencia membros, workspaces e chaves de API da organização, e exige uma Admin API key que começa com sk-ant-admin, diferente das chaves comuns

Pra limites, tem a Spend Limits API

Duas notas honestas aqui, porque acho zoado empurrar passo que eu não confirmei

A primeira: o caminho de menu exato pra configurar spend cap por usuário ou por grupo eu não vou chutar, o recurso existe, a navegação não confirmei

A segunda: restrição de modelos da organização, modelo padrão da organização e limites de esforço funcionam sem deployar settings, mas os três exigem o plano Claude Enterprise

Qual caminho escolher pelo perfil da empresa

Time pequeno ou médio que só quer parar de sangrar chave

Team, e sem pensar muito

A documentação oficial de setup pra organizações recomenda Team ou Enterprise como a melhor experiência pra maioria das empresas: uma assinatura única cobre o Claude Code e o Claude na web, com billing centralizado e sem precisar montar infraestrutura nenhuma

O assento ainda cobre o Claude Code dentro das IDEs suportadas: VS Code, Cursor e outros forks do VS Code, e IDEs JetBrains como IntelliJ e PyCharm

E não é só o pessoal de engenharia que aproveita, porque dá pra usar o Claude Code sem saber programar no dia a dia de quem toca produto e conteúdo

Organização grande ou com exigência de compliance

Enterprise, mínimo de 20 assentos, tipo único de assento, preço por usuário/mês com cobrança anual

É o caminho obrigatório acima de 150 assentos, e é onde moram SSO e domain capture, provisionamento SCIM e JIT, controle de acesso baseado em papéis (RBAC) e audit logs de ações de usuário, eventos de sistema e acesso a dados

Equipe que precisa manter o tráfego dentro da nuvem já contratada

Aqui entra o Amazon Bedrock

Pra ligar por variável de ambiente:

export CLAUDE_CODE_USE_BEDROCK=1

Se você prefere o assistente interativo: no prompt de login, escolha 3rd-party platform e depois Amazon Bedrock

Já está logado e vendo o prompt de chat? Roda direto:

/setup-bedrock

O assistente salva o resultado no bloco env do arquivo de settings do usuário

E ele aceita quatro formas de autenticação na AWS: perfil AWS detectado no diretório ~/.aws, chave de API do Amazon Bedrock, par de access key e secret, ou credenciais que já estejam presentes no ambiente

Erro comum aqui: achar que basta exportar a variável e esquecer que a credencial da AWS ainda precisa existir de algum desses jeitos

Quem já roda Claude Code no Console e quer consolidar

Existe caminho oficial documentado de migração de Claude Code no Console para o Enterprise, então não precisa recriar tudo na unha

E tem um controle que costuma ser esquecido nessa arrumação da casa: dá pra controlar quais servidores MCP a organização libera pro time no Claude Code, tem documentação própria pra isso

Veredito: assinatura da organização em vez de chave por dev

Pra maioria das empresas, o caminho por assento resolve os dois problemas de uma vez

O dev loga com a conta Claude que pertence à organização, recebe a alocação de uso do plano e simplesmente NÃO precisa de chave de API

O admin vê o uso, aplica teto de gasto e recebe alerta antes do estouro

Ninguém monta infraestrutura pra isso

Console e provedor de nuvem não são "a opção errada", eles existem pra quem precisa de isolamento por workspace com limite próprio de gasto e rate limit, ou de compliance herdada da nuvem que a empresa já contratou

Se esse não é o seu caso, você está pagando complexidade sem receber nada em troca

Agora o limite deste post, e prefiro dizer na cara: aqui não teve teste dos planos

O veredito é sobre o DESENHO de cada caminho, o que cada um cobra, o que cada um controla, o que cada um exige de infra

Conclusão

A decisão cabe numa frase: assinatura da organização (Team ou Enterprise) pro time inteiro, chave de API só onde o Console ou a nuvem realmente forem necessários

O próximo passo é bem concreto e custa nada

Peça pra cada dev do time rodar /status no Claude Code e olhar a linha de Login method e a linha de API key

Quem tiver chave ativa, roda unset ANTHROPIC_API_KEY e confere de novo

Só DEPOIS disso você dimensiona assentos com número real na mão, lembrando que o assento do Primary Owner conta na licença, e que existe caminho oficial de créditos de uso extra pra Team e Enterprise por assento quando o time estoura a alocação

Começa pelo /status, o resto fica muito mais fácil de decidir 😀

até o próximo post!