Primeiro de tudo, parabéns pelo projeto. A proposta é bem interessante, principalmente por atacar dores reais: quando o uso começa virar infra de verdade, custo, segurança e auditoria.
Dito isso, eu teria algumas sugestões e ressalvas. Nada impeditivo, mas acho que valem atenção.
Semantic Cache
Esse é o ponto onde eu teria mais cuidado com a promessa geral.
Semantic cache funciona muito bem em alguns cenários: FAQ, perguntas repetitivas, classificação, respostas com contexto bem estável, RAG mais controlado, etc.
Mas no fluxo atual de chats e agents, ele tende a ser bem mais dificil do que parece. O motivo é simples: a mesma pergunta quase nunca é a mesma pergunta.
Agents normalmente enviam junto:
- histórico da conversa
- system prompt
- tool calls anteriores
- arquivos/diffs
- contexto de RAG
- estado da task
- memória da sessão
A própria doc da Microsoft sobre semantic cache comenta que LLMs não mantêm contexto entre requests e que, para o cache funcionar corretamente, ele precisa considerar tbm parte do chat history/context window, não só o prompt isolado.
Link: https://learn.microsoft.com/en-us/azure/cosmos-db/gen-ai/semantic-cache
Então eu trataria semantic cache como uma feat best-effort e configurável, não como economia garantida para qualquer agent.
Sugestão: deixar isso bem explícito e talvez permitir cache por rota/agente, com namespace por organização/usuário/sessão, TTL, threshold configurável e opção de desligar em fluxos agentic mais sensíveis.
Strict Budget Cap
Esse é provavelmente um dos pontos mais fortes do projeto, principalmente para quem usa API/BYOK e está literalmente com o taxímetro ligado a cada request.
Hoje estamos vendo muita gente migrando para planos mensais/anuais, como Copilot, Claude, ChatGPT Team/Pro, etc. Isso é mais previsível para usuário final, mas não elimina restrições. Na prática, essas plataformas estão indo cada vez mais para quotas, créditos, rate limits e janelas de uso.
O próprio GitHub Copilot já está caminhando para billing por créditos de IA, calculando consumo por tokens de input, output e cache.
Então o budget cap faz muito sentido, mas talvez precise de nuances para empresa:
- hard cap para ambientes não críticos
- soft cap com alerta para produção
- fallback automático para modelo mais barato
- burn rate por departamento/projeto/usuário
- reserva transacional antes da request e ajuste depois pelo uso real
- modo grace para não derrubar um fluxo crítico por poucos centavos
Simplesmente bloquear tudo ao bater o limite pode ser perfeito em alguns cenários, mas perigoso em outros.
Pense em avisos por e-mail, push e coisas do tipo..
Compatibilidade
Eu adicionaria suporte nativo ao padrão da Anthropic tbm, principalmente /v1/messages.
Muita coisa no ecossistema de agents está indo para semânticas mais próximas do Anthropic: system separado, content blocks, tool_use, tool_result, streaming próprio, prompt caching com cache_control, etc. Pense nisso..
No geral, o projeto tem uma direção muito boa. Eu só tomaria cuidado para vender semantic cache como solução universal, deixaria budget cap mais flexível para cenários enterprise e adicionaria compatibilidade Anthropic como prioridade.
Fecha o repo do github, e comece a trabalhar offline trazendo conceito de produto para o seu app. Tem futuro.
Open Source não vai te ajudar, a não ser que seja somente para portfólio.