Pitch: llamport — servindo modelos Codex pelas APIs da OpenAI e da Anthropic (e por que o cache de prompt decide o custo) · llamport

O llamport é uma API de LLM pay-as-you-go focada nos modelos Codex. Você compra crédito, cria uma chave e usa no Codex CLI, no Claude Code ou nos SDKs da OpenAI e da Anthropic. Abaixo conto as decisões técnicas que mais pesaram até aqui.

Uma chave, três formatos de API

Cada ferramenta fala um dialeto diferente: o Codex CLI usa a OpenAI Responses, o Claude Code usa a Anthropic Messages, e muito código legado ainda usa Chat Completions. Em vez de manter três caminhos separados, cada requisição é convertida para um formato interno único e só depois enviada ao upstream. Para quem usa, muda só a base URL e a chave:

export OPENAI_BASE_URL=https://api.llamport.com/v1
export OPENAI_API_KEY=lp-...

Um detalhe que custou um bug: chamadas de ferramenta sem argumentos (vazios ou null) chegavam ao Codex sem o campo arguments, e o upstream respondia 400 missing_required_parameter. Hoje o campo é sempre enviado, como {} quando não há argumentos.

O cache de prompt é o que mais pesa no custo

Num agente de código, a maior parte do input se repete a cada turno: o mesmo system prompt, os mesmos arquivos, o histórico. No nosso perfil típico, cerca de 94% dos tokens de input são input em cache. Só que o upstream só reaproveita o cache se os turnos da mesma conversa chegarem com a mesma chave de cache.

O que fazemos:

No edge, cada requisição recebe uma chave estável por conversa: um UUIDv5 da chave do cliente, do modelo e da primeira fonte disponível entre os headers de sessão, o prompt_cache_key do corpo, a sessão do Claude Code ou os primeiros textos de system e de usuário.
Essa chave segue para o Codex como prompt_cache_key e no header Session-Id, do mesmo jeito que o Codex CLI faz.
Com afinidade de sessão, os turnos da mesma conversa vão para o mesmo upstream, então o cache continua quente.

Failover

Cada requisição vai para um upstream saudável e, se ele falhar, para o próximo.

Regras de cobrança

O saldo vai exatamente até zero e nunca fica negativo: não existe dívida.
Não armazenamos prompts; só horário, modelo e quantidade de tokens para o faturamento.
Só modelos reais: o modelo que você escolhe é o que responde.

Preço

Cada modelo custa cerca de 90% menos que o preço oficial da API, em input, input em cache e output. Com US$ 5, num uso típico de código, dá até 2,66 bilhões de tokens no gpt-6-luna ou 175 milhões no gpt-6.1-sol. Pagamento por cartão ou USDT, sem assinatura. Contas novas ganham US$ 2 com o código WELCOME2.

Site: llamport.com (em inglês por enquanto). Perguntas sobre a arquitetura e críticas são bem-vindas nos comentários.

Muito boa a análise sobre cache de prompt e afinidade de sessão no edge — na prática de produção, o que mais destrói margem e latência em aplicações com IA é justamente reenviar contexto repetido sem chave estável.

No SecretárioExecutivo, onde processamos transcrições longas de chamadas (Google Meet, Microsoft Teams e Zoom) para extrair atas diarizadas e tarefas para Trello/Jira, esbarramos num problema correlato: picos ocasionais de latência das APIs de LLM que seguravam buffers de requisição e estouravam o limite de RAM do container Fastify (~30 MB em VPS de 2GB).

Resolvemos com duas abordagens pragmáticas:

Normalização Canônica de Diarização: O payload de qualquer plataforma (Meet/Teams/Zoom) é compactado antes do prompt em blocos sintéticos (speaker, time, action), reduzindo em ~65% os tokens de input.
Fast-Break com Fallback Determinístico (Promise.race): Timeout de 4s na chamada de IA; se estourar, um parser determinístico via regex estrutural entra em cena e gera a ata e os cards sem travar a experiência do usuário.

Essa combinação de cache/resumo no upstream com fallback determinístico local é o que permite manter o serviço de pé com custo e memória quase nulos.