Firekeep

Código-fonte disponível, memória compartilhada auto-hospedada, contexto de trabalho, coordenação e evidências para Claude Code, Codex, Kiro, OpenCode e clientes MCP.

GitHub
2
Experimente este MCPPatrocinado

Documentação

Firekeep

Seus agentes não deveriam trabalhar como estranhos.

Conecte Claude Code, Codex, Kiro, OpenCode e outros clientes MCP por meio de um único Keep compartilhado e auto-hospedado.

Cada problema resolvido deveria tornar o próximo mais fácil. O Firekeep preserva a experiência por trás do trabalho — conhecimento durável, estado de trabalho, procedimentos, coordenação e evidências inspecionáveis — e a coloca de volta em ação na próxima sessão, ferramenta ou máquina.

Use-o para sua própria continuidade em uma única estação de trabalho. Adicione colegas de equipe quando precisar deles sem recomeçar o contexto da equipe do zero.

Site · Instalação · Tour do produto · Firekeep Studio · Evidências · Privacidade · Suporte

Um único Keep, em vários runtimes

flowchart LR
    A["Claude Code<br/>stores a proven fix"] --> K[("your self-hosted<br/>Keep")]
    K --> B["Codex<br/>recalls the fix + evidence"]
    K --> C["Kiro<br/>reuses the procedure"]
    K --> D["OpenCode / MCP client<br/>continues informed"]

Os agentes mantêm suas interfaces nativas e sessões de propriedade do provedor. O que avança é o contexto do Firekeep que eles registram e recuperam explicitamente por meio do mesmo gateway MCP local. Isso significa que uma pessoa pode trocar de ferramenta sem perder o fio da meada, e uma equipe pode conquistar contexto uma vez e levá-lo adiante.

Veja Claude Code e Codex compartilharem um único Keep →

Instalar o Firekeep

O instalador configura Claude Code, Codex, Kiro e OpenCode juntos (além do Claude Desktop quando o diretório de configuração dele existe) e então pergunta onde o servidor Firekeep deve ficar. O fluxo completo de configuração está no guia de instalação.

curl -fsSL 'https://firekeep.ai/latest/install?src=github' | sh    # macOS / Linux
irm 'https://firekeep.ai/latest/install.ps1?src=github' | iex      # Windows PowerShell

O servidor atual tem como alvo linux/amd64 e precisa do Docker Compose v2, dois núcleos de CPU x86-64 e Git; 16 GB de RAM são recomendados para a pilha padrão. Ele vincula-se a 127.0.0.1 por padrão. Consulte as notas de requisitos e dimensionamento antes de escolher um host.

Experimentando o Firekeep pela primeira vez? Compartilhe o que funcionou e onde você travou →

Cobertura de runtime

  • Client Kit: configura Claude Code, Codex, Kiro e OpenCode juntos; o Claude Desktop é adicionado quando o diretório de configuração dele existe. Outros clientes MCP podem usar o caminho genérico.
  • Claude Code: MCP gerenciado, instruções e hooks de ciclo de vida. O hook pré-ferramenta suportado pode bloquear de forma rígida uma ação de edição, escrita ou shell.
  • Codex: MCP gerenciado mais orientação AGENTS.md. O Codex não expõe hooks nativos, portanto automação de ciclo de vida e aplicação de pré-edição não estão implícitas.
  • Kiro CLI: um agente Firekeep nomeado com MCP, direção e hooks de ciclo de vida. Na superfície validada do Kiro CLI 2.12.1, o hook de pré-edição dele é consultivo.
  • Firekeep Studio: executa Codex, Claude Code, Kiro CLI e Grok em um único workspace de desktop. O adaptador direto do Grok não tem memória Keep, hooks ou briefing; o Studio relata esse limite em vez de herdar o status de outro runtime.

Consulte o guia de integração e a matriz de runtime do Studio para obter os detalhes mantidos.

Recuperação medida, com o método anexado

Na execução aceita do LongMemEval-S em 2026-08-28, o Firekeep alcançou 97,7% de Evidence Recall@10: pelo menos uma sessão de evidência rotulada apareceu nos dez primeiros resultados para 459 de 470 perguntas pontuadas. A medição cobre recuperação, não a precisão da resposta gerada; é uma execução determinística corrigida, em vez de um intervalo de confiança de múltiplas execuções.

Metodologia · Dados de resultado

O problema que o Firekeep resolve

As pessoas não constroem julgamento profissional relendo cada e-mail, documento, ticket ou arquivo de origem desde o início. Elas lembram o que aconteceu, por que uma decisão funcionou, como uma falha foi diagnosticada e qual procedimento se manteve na prática. Essa experiência muda a forma como elas abordam o próximo problema.

Os agentes deveriam melhorar da mesma forma. O Firekeep conecta o conhecimento, o estado de trabalho, a coordenação e as evidências por trás do trabalho para que o próximo agente possa começar com a experiência que o último conquistou.

Mapa detalhado de capacidades

CapacidadeO que significa
MemóriaOs agentes lembram o que funcionou, o que falhou e o que importa entre sessões. Recuperação semântica + de grafo, pontuação de confiança, tratamento de contradições, quatro tipos de memória (referência / processual / episódica / transitória) com decaimento de recall por tipo, envelhecimento recuperável com arquivamento primeiro e recall consciente de tokens com síntese opcional de LLM. O recall é reclassificado pelos resultados de sessão registrados (memória ponderada por resultado) e pelo feedback do agente sobre o conhecimento que foi realmente utilizado (memory_feedback).
Piloto Automático de ConhecimentoA base de conhecimento se mantém sem decidir nada por conta própria. Quando duas memórias não confirmadas realmente conflitam, nenhuma é descartada silenciosamente — ambas permanecem recuperáveis, marcadas como contestadas, até um veredito humano (/memory/contested/resolve). Um reaper de sessão encerra sessões travadas/abandonadas para que falhas contem na pontuação de resultados. Cada fila de revisão (habilidades em rascunho, habilidades obsoletas, propostas de procedimento, pares contestados, cartas mortas de eval) cai em uma única caixa de entrada com um resumo semanal, e /memory/{id}/evidence mostra cada sinal por trás da classificação de uma memória em uma única leitura.
Continuidade de EquipeAs memórias carregam proveniência verificada de workspace/membro, além de um rótulo agent_id de runtime não confiável e projeto. Relatórios de atividade por contribuidor e briefings de handoff sintetizados por LLM permitem que um agente continue de onde outro parou.
Continuidade de SessãoPlanos, decisões e progresso registrados por meio das ferramentas de sessão sobrevivem à compressão de contexto. Sessões travadas são detectadas automaticamente no próximo início e oferecidas para retomada com um snapshot periódico do workspace (branch git, commits recentes, estatísticas de diff) embutido na sombra.
Consciência de AmbienteColetores configurados de Docker, git e arquivos monitoram o estado operacional em vez de depender apenas de prompts. Reinicializações de contêineres, novos commits e mudanças de arquivo fluem para um fluxo de eventos reproduzível.
Coordenação de AgentesCanais compartilhados, quadro de avisos, fila de tarefas estruturada, leases de recursos com tokens de fencing monotônicos, registro de presença e mensagens diretas. Agentes concorrentes podem atribuir trabalho, acompanhar progresso e usar leases para evitar edições sobrepostas; clientes com hooks habilitados bloqueiam uma edição quando outro agente já detém o lease do arquivo.
Gateway Prever-depois-AgirOs agentes declaram intenção antes de ações consequentes (action_before → `allow
HabilidadesOs agentes criam playbooks reutilizáveis de "o que fazer quando X acontecer" por meio da ferramenta skill_create (no lado do cliente, com contexto completo da sessão); um pipeline de docs→habilidades elabora mais a partir de wikis/runbooks sob revisão humana. As melhores correspondências são injetadas no briefing da próxima sessão. (A auto-síntese no lado do servidor existe por trás de SKILL_SYNTHESIS_ENABLED, mas está desativada por padrão — o deploy somente CPU não consegue executar o LLM de geração em tempo viável.)
Runbooks ImpostosUma habilidade cujos passos carregam correspondentes de comando é um runbook que um humano pode armar: advise (avisos da rodada 1), require_ack (um comando correspondente é desafiado e prossegue somente após um reconhecimento auditado — permissão de uso único vinculada a workspace, membro, sessão, hash de comando, passo, versão do bundle e execução) ou block (falha fechada, com um recibo do servidor que o cliente exige antes de honrar uma permissão). As evidências são pontuadas por sucesso — um passo conta somente quando o comando dele sai com código 0 — e cada evento de imposição cai em um livro-razão de desvios (painel + caixa de entrada), armazenando hashes de comando, nunca o texto do comando. Os modos são definidos por um humano em uma rota somente para administradores; os agentes podem propor runbooks, nunca armá-los. Opt-in via PROCEDURE_ENABLED, atualmente em dogfooding em nossos próprios deploys — consulte docs/guides/living-procedures.md.
Quadro de DecisõesQuando um esclarecimento precisa de mais do que algumas perguntas, o agente abre um quadro de navegador local pré-populado com evidências recuperadas da memória da equipe — perguntas melhores, informadas pelo que a equipe já aprendeu. O gateway local fica na frente do processo do Quadro de Decisões e do Cortex /decision/synthesize.
Instruções VivasA camada de instruções se mede: uma tabela de conformidade por instrução calculada deterministicamente a partir da reprodução (as sessões lembraram antes de responder, registraram enquanto avançavam, declararam ações consequentes), com tendência ao longo do tempo, fatias por runtime e recibos de exposição — as sessões carregam um hash de conteúdo do texto da instrução que realmente as alcançou, e qualquer coisa não verificável é relatada como desconhecida em vez de contada. Honesta sobre seus limites por construção: mede comportamento, não se o comportamento ajudou. Reescritas elaboradas pela frota sob veredito humano e validação A/B estão no roadmap.
Livro-Razão de ConfiançaUm registro de emprego por agente construído a partir das declarações que os agentes já fazem por meio do gateway (action_before/action_after): contagem de ações declaradas, taxa de reconciliação, calibração de previsão-correspondência (Brier sobre confiança declarada vs. resultado reconciliado), reversões, sessões, primeira/última vez visto. Visibilidade somente — relata, nunca bloqueia. Honesto por construção: calibração é comportamento, não competência; somente ações declaradas são vistas; agent_id é um rótulo autorrelatado, então o registro é por identidade declarada; e a calibração lê sinal insuficiente abaixo de um limite em vez de inventar um número. A metade impositiva (um corretor de capacidades que transforma o registro em autonomia conquistada) está no roadmap.
Auto-Evals + Descoberta de PadrõesMétricas de qualidade calculadas a partir de trilhas de reprodução na conclusão da sessão. A detecção de padrões está habilitada; a promoção/validação automatizada e os endpoints de experimento A/B estão implementados, mas desativados por padrão até que um deploy tenha volume de sessão suficiente para usá-los com responsabilidade.
Reprodução e ExplicabilidadeCada leitura/escrita de memória, evento de ciclo de vida de sessão, mudança de ambiente, ação de coordenação e decisão de gateway é registrada como uma trilha estruturada. Inspecione, restrinja e reconstrua o contexto em qualquer evento anterior.
Segredos CriptografadosCofre com base em Fernet para credenciais de infraestrutura, tokens de API e strings de conexão. Distinto da memória — segredos nunca aparecem na recuperação.
Conhecimento de NegócioIngira documentos da empresa (páginas de wiki, tickets, docs de API) — manualmente ou por meio de coletores agendados do Confluence. Os chunks caem no armazenamento vetorial e surgem naturalmente durante a recuperação de memória junto com memórias operacionais.
Inteligência de CódigoPesquisa de símbolos baseada em tree-sitter, grafos de chamadores, mapas de arquitetura e análise de impacto que retorna fatias de símbolos em vez de arquivos inteiros — executa no lado do cliente por meio do gateway local (firekeep-symdex é instalado com o kit). 38 ferramentas MCP (8 ferramentas de análise ocultas por padrão atrás de SYMDEX_ANALYTICS_ENABLED).

Por que o Firekeep é diferente

O Firekeep não é outro wrapper de chatbot ou camada de orquestração de prompts.

Ele é uma camada operacional para agentes de IA conectados — infraestrutura que fica atrás das suas ferramentas existentes e as torna melhores.

  • Autohospedado por padrão. O servidor, os armazenamentos de dados, os embeddings e o modelo de geração padrão são executados na sua infraestrutura. A saída para terceiros ocorre apenas quando você opta por um conector ou provedor externo do Symdex AI.
  • Aprofundado onde o trabalho acontece. Codificação é o fluxo de trabalho mais consolidado, com o Symdex para inteligência de código. Não é o limite do produto: o Docdex traz pastas de documentos selecionadas para o mesmo Keep, o Maildex traz o e-mail de um membro (IMAP somente leitura, sempre privado do membro, firekeep maildex add), e as camadas compartilhadas de continuidade, coordenação, governança e evidências são independentes de domínio.
  • Persistência + observabilidade. A maioria das ferramentas de agente foca em tornar o agente mais inteligente no momento. O Firekeep foca no que acontece entre as sessões e depois que algo dá errado.
  • Nativo para MCP. Quatro serviços remotos e dois backends locais do cliente expõem ferramentas do Model Context Protocol por meio de um gateway stdio local firekeep. Os adaptadores fornecidos configuram Claude Code, Claude Desktop, Codex, Kiro e OpenCode; outros clientes MCP podem ser configurados manualmente.
  • Independente de agente. Troque o cliente de agente sem reconstruir a camada subjacente de memória e coordenação. O Cursor tem um caminho MCP manual documentado; o Aider atualmente não tem um adaptador fornecido.
  • Descoberta via A2A. O Relay publica um cartão de agente Agent-to-Agent em /.well-known/agent.json para descoberta de capacidades. Isso é apenas descoberta, não um endpoint de execução de tarefas A2A.

Detalhes de instalação e operação

Um comando, duas perguntas obrigatórias: a identidade do agente à qual cada memória, sessão e evento de replay é atribuído, e onde seu servidor Firekeep está — configure um nesta máquina com Docker, resgate um código de adesão, aponte para um que já esteja em execução, ou decida depois (firekeep doctor então explica como terminar). Configurar um aqui executa firekeep init para você; esse instalador não pergunta nada, e a máquina se registra sozinha assim que a pilha estiver ativa, então firekeep doctor fica verde sem painel, sem túnel e sem chave colada. Ele imprime o comando pronto para colar para sua segunda máquina quando terminar.

O instalador então oferece um prompt opcional para o arquivo de regras de outro cliente MCP; os quatro adaptadores fornecidos são renderizados de qualquer forma.

As imagens atuais do servidor têm como alvo linux/amd64: execute-as em um host Linux x86-64, ou via Docker Desktop com suporte a contêineres amd64. O bootstrap do cliente é testado em CI no Ubuntu, Debian, Alpine, Fedora, Rocky, Arch e openSUSE (x86_64 e aarch64); o macOS executa o mesmo script, mas não é coberto pelo CI.

A partir deste checkout

bash install.sh              # build the server from source
bash install.sh --pull       # the same installer against the published images
cd client && ./install       # the kit from this checkout (.\install.ps1 on Windows)
firekeep install             # re-render the runtime adapters only

install.sh não solicita nada: o endereço do host é detectado e a senha do Neo4j é gerada (--ip / --neo4j-password, ou FIREKEEP_VPS_IP / FIREKEEP_NEO4J_PASSWORD, substituem qualquer um). Ele retorna assim que a pilha está ativa, em vez de bloquear no download do modelo de ~3,3 GB — até que isso termine, as gravações de memória retornam status="partial" (armazenadas e enfileiradas para preenchimento retroativo, ainda não pesquisáveis) e firekeep doctor carrega uma linha de aviso embeddings WARN dizendo isso. bash install.sh --wait-for-models bloqueia em vez disso.

Operar o servidor depois — acesso e autenticação, o painel, backups, atualizações, expor portas deliberadamente — está em docs/DEPLOYMENT.md.

Removendo

firekeep uninstall            # remove the client kit from this machine
firekeep uninstall --server   # also tear down the server + ALL its data

firekeep uninstall remove apenas o que o kit instalou — os blocos do Firekeep na configuração de cada runtime (suas próprias configurações permanecem intactas), o lançador e sua entrada no PATH, e ~/.firekeep — e pergunta primeiro (--yes pula o prompt). Ele nunca toca em um servidor que você configurou. --server adicionalmente executa docker compose down -v na pilha que esta máquina provisionou, excluindo os volumes Neo4j/Qdrant/Redis — cada memória, sessão e segredo, permanentemente — atrás de uma confirmação separada de perda de dados que uma desinstalação simples ou --yes nunca pode acionar. Faça backup primeiro (docs/DEPLOYMENT.md) se você pode querer os dados de volta.

Firekeep Studio

Firekeep Studio showing a multi-runtime conversation workspace, sessions, Mission controls, and runtime status

Baixar para Windows · Baixar macOS universal · Explorar Studio →

studio/ é um cliente de desktop separado para pessoas que querem que o Firekeep seja o único aplicativo de agente que abrem. Ele dá ao Codex, Claude Code, Kiro CLI e Grok uma superfície de conversa neutra em relação ao runtime: qualquer runtime suportado pode ser o primário explícito, outros runtimes podem revisá-lo em contextos somente leitura novos, e /compare, /consensus, um espaço de trabalho compartilhado explícito, entrada de voz no Windows e saída de voz do sistema, guardas de token cientes de cache, sessões locais nomeadas e codificadas por cores, descoberta ao vivo de modelo/raciocínio do provedor e controles tipados do Client Kit são integrados. O runtime selecionado é visualmente explícito, o inspetor completo pode ser ocultado, e o Studio vincula ao painel a partir da conexão existente do Client Kit sem expor suas credenciais. Respostas Mermaid cercadas renderizam como diagramas nativos com zoom, e o Painel de Decisão existente do Firekeep abre como um painel nativo de pergunta/evidência/ação dentro do Studio. Seu push autenticado local preserva o long poll original, evitando uma rodada extra do agente apenas para descobrir que o painel está pronto. O seletor de runtime primário mostra prontidão ao vivo e contexto de transporte, a rolagem de respostas respeita leitores que se afastam do final, e copiar/colar usa operações nativas de área de transferência somente texto com limite. Respostas concluídas lideram cada execução enquanto eventos de trabalho detalhados se dobram em um Log de trabalho. Uma visão Agentes neutra em runtime organiza Codex, Claude, Kiro, Grok ou qualquer adaptador futuro com capacidade de chat em painéis selecionáveis com continuações nativas independentes; o compositor compartilhado tem como alvo o painel selecionado, e execuções ativas permanecem serializadas para segurança do espaço de trabalho. O Modo Missão adiciona uma estrutura limitada por resultado: um escritor primário, verificações locais determinísticas, reparo limitado, evidência de revisão independente, aceitação humana explícita e um resultado de tarefa armazenado separadamente da prosa de cada agente.

O Studio consome limites estruturados suportados pelo provedor em vez de raspar TUIs, mantém a autenticação do provedor de propriedade do provedor (exceto chaves de API criptografadas pelo SO) e continua usando o Client Kit Python existente sempre que a configuração nativa de um runtime fornece memória Keep, hooks, política e conectividade. Os cartões de runtime relatam essa evidência explicitamente; o adaptador direto do Grok xAI é claramente marcado como sem memória Keep, em vez de herdar a alegação de outro runtime. A compilação de pré-visualização e comandos do instalador, limites de segurança, matriz de runtime e inventário completo de comandos / estão no README do Studio.

O Studio 0.4 inclui um instalador Windows x64 e um instalador macOS universal de um canal de lançamento isolado e assinado. Compilações empacotadas verificam atualizações do Studio logo após o lançamento; o Windows baixa e instala uma atualização verificada na reinicialização, enquanto o macOS usa atualizações automáticas nativas apenas quando o lançamento é assinado e notarizado pela Apple. A página de lançamento atual, somas de verificação e ambos os instaladores são publicados em Lançamentos do Firekeep Studio.

Um Fluxo de Trabalho Real

Aqui está o que acontece quando um agente usa o Firekeep:

1. A sessão começa. Em runtimes com hooks de ciclo de vida, o cliente busca o GET /briefing agregado do Cortex primeiro, incluindo memórias relevantes, tarefas, estado do ambiente e habilidades. O agente então chama ctx_start_session("fix auth middleware bug"); o Bridge cria a sessão durável e o shim a vincula a esse briefing.

2. Exploração de código. Em vez de ler cada arquivo, o agente chama search_symbols("auth middleware") e get_callers("require_scope") no Symdex. Ele obtém uma lista direcionada de arquivos e chamadores em milissegundos.

3. Verificação do ambiente. O Sentinel tem monitorado o Docker. Ele detectou que o contêiner cortex-api reiniciou 3 vezes na última hora e enviou um alerta para o canal #alerts do Relay. O agente vê isso em seu contexto.

4. O trabalho acontece. O agente edita arquivos, executa testes e registra progresso importante com ctx_update. O Bridge persiste o que foi explicitamente registrado. Quando a janela de contexto comprime, o agente chama ctx_get_shadow e obtém esse estado de trabalho durável de volta — planos, decisões, progresso e conhecimento de arquivos.

5. A sessão é concluída. O agente chama ctx_complete_session, opcionalmente passando uma autoavaliação estruturada — task_result ("success" / "partial" / "failure", o resultado da TAREFA, não o do RPC) mais até 10 declarações curtas de task_evidence que a sustentam. A nota é aceita apenas do proprietário verificado da sessão e armazenada como o único resultado autoritativo e nunca sobrescrito dessa sessão. O Bridge marca atomicamente a sessão como concluída e enfileira a destilação em segundo plano para memória episódica; falhas tentam novamente e eventualmente movem para uma fila de mensagens mortas visível. Autoavaliações calculam métricas de qualidade a partir do traço de replay — uma sessão sem nota reconhecida lê como unknown em vez de um sucesso adivinhado, então a pontuação orientada por resultado (Memória Ponderada por Resultado, tendências de qualidade) nunca conta silêncio como vitória. Na próxima vez que alguém trabalhar em middleware de autenticação, as memórias estarão lá assim que a destilação for bem-sucedida.

6. Algo deu errado? Abra a aba Replay no painel. Carregue a sessão. Veja cada ação, cada leitura de memória, cada ponto de decisão. Clique em um evento de falha e execute a redução — ela percorre a cadeia causal para ajudar a identificar a causa raiz.

Arquitetura

Local Machine                               VPS
┌──────────────────────────┐              ┌────────────────────────────────────┐
│ Claude / Codex / Kiro /  │              │ FirekeepCortex   — Memory & RAG    │
│ OpenCode / MCP client    │              │ FirekeepBridge   — Sessions        │
│           │              │              │ FirekeepSentinel — Monitoring      │
│  one `firekeep` gateway  │◄──── MCP ───►│ FirekeepRelay    — Coordination    │
│    ├─ symdex (local)     │              │ Dashboard        — Web UI          │
│    └─ decision (local)   │── Browser ──►│ Neo4j · Qdrant · Redis · Ollama    │
└──────────────────────────┘              └────────────────────────────────────┘

O Symdex e o Painel de Decisão são executados no lado do cliente como servidores MCP locais stdio (instalados com o kit) — o Symdex deve ser local à árvore de trabalho que indexa, então não é mais um contêiner VPS.

As duas setas que cruzam esse limite não são publicamente alcançáveis por padrão. Fora da caixa, o lado VPS escuta em loopback e requer uma chave de API, então a metade da máquina local o alcança por um túnel SSH, uma rede privada ou um front-end HTTPS que você configura deliberadamente. Veja docs/DEPLOYMENT.md → Acesso e autenticação.

ServiçoO que faz
FirekeepCortexMemória de longo prazo. RAG semântico + de grafo, ciclo de vida de arquivamento/restauração, consolidação por ciclo de sono, quatro tipos de memória com decaimento ciente do tipo, memórias versionadas com pontuação de confiança, supersessão automática de contradições, habilidades criadas por agentes (skill_create) + um pipeline de docs→habilidades, e o Agent Gateway (superfície de prever-depois-agir).
FirekeepBridgePersistência de sessão. Preserva o contexto de trabalho (planos, decisões, progresso, conhecimento de arquivos) através de compressões de contexto. Auto-destila para o Cortex na conclusão. Detecção de sessão travada com retomada por snapshot do workspace. Um ceifador de sessões abandona sessões ociosas por mais de 72h, para que sessões abandonadas sejam registradas como não-sucessos na pontuação de resultados. Emite eventos de ciclo de vida de sessão para o stream de replay.
FirekeepSentinelObservador de ambiente. Saúde do Docker, commits git, alterações de arquivos. Transmite alertas para o Relay em erros. Reinícios de contêineres, novos commits e alterações de arquivos fluem para um stream de eventos reproduzível.
FirekeepRelayCoordenação de agentes. Canais pub/sub em tempo real, quadro de avisos persistente, fila de tarefas estruturada, leases de recursos com tokens de fencing monotônicos, registro de presença, mensagens diretas e um endpoint de cartão de agente A2A para descoberta externa.
DashboardInterface web que cobre coordenação, memória, diagnósticos, dispositivos, membros, políticas, cofre e operações.
Firekeep StudioConsole desktop local opcional e harness de Missão para agentes primários, verificação determinística, revisores independentes, ditado no Windows, respostas de voz do sistema, comparação entre runtimes e controle do Client Kit. Não é um serviço VPS.

Inteligência de código (FirekeepSymdex — 38 ferramentas MCP, 8 análises ocultas atrás de uma flag) e o Decision Board (firekeep-decision) rodam no lado do cliente como servidores MCP stdio-locais instalados com o kit, não como contêineres VPS.

Módulos compartilhados (sem contêineres extras): Replay Engine (log de rastreamento estruturado em todos os serviços), Auth (escopos de chave de API), Vault (armazenamento de segredos criptografado com Fernet), Corpus (ingestão de documentos de negócio → chunks vetoriais; coletores agendados do Confluence), Auto-Evals (10 métricas de qualidade Tier-1 + acompanhamento de tendências + detecção de regressão), Pattern Engine (detecção de estratégias; validação de promoção e experimentos A/B desativados por padrão via feature flags), Policy Engine (verificações de segurança pré-edição compostas — lease, risco de arquivo, negação de caminho, saúde da sessão, falha recente), Agent Gateway (superfície de prever-depois-agir com cache de caminho rápido para ações repetidas de baixo risco), Skills (criadas por agentes via skill_create + rascunhos de docs→habilidades sob revisão humana; síntese no servidor desativada por padrão), Memory Improvements (envelhecimento composto com arquivamento primeiro, com pré-visualização/auditoria/restauração, orçamentos de tokens, passada de síntese com LLM, entrada de embedding limitada + ajuste para caber).

Para a especificação completa do design, veja docs/DESIGN.md.

Dashboard

Acesse em http://localhost:8040 no host, ou através de um túnel de outro lugar (docs/DEPLOYMENT.md → Alcançando o dashboard). Ele tem seu próprio login de autenticação básica (usuário admin; a senha é escrita uma única vez em dashboard/.htpasswd.cred). Por trás disso, o nginx injeta a chave de API do dashboard em cada chamada de backend, então o SPA funciona contra a pilha protegida por autenticação sem que você cole uma chave no navegador.

AbaO que mostra
Visão geralSaúde dos serviços, estatísticas rápidas, eventos e memórias recentes
SessõesSessões ativas/pausadas/concluídas/abandonadas, inspetor de contexto sombra
EventosFeed de eventos do Sentinel com filtros de origem e severidade
RelayFila de tarefas, canais, quadro de avisos, mensagens diretas, claims/leases ativos
EscopoSessões de esclarecimento do FirekeepScope — telas ativas, prompts de resposta
MemóriaBusca de recall, navegadores de ativos/arquivados, restauração com um clique, pré-visualização/auditoria de manutenção, formulário de armazenamento, contribuidores, estatísticas de namespace/tag
HabilidadesCartões de habilidades criadas por agentes + derivadas de documentos — revisar, ativar, editar, aposentar — além dos cartões de runbook das Living Procedures: selo de modo de enforcement e controle de modo admin, estatísticas de observação por etapa, visualização de desvios e um aviso de NÃO ATIVAMENTE IMPOSTO quando um runbook armado não tem nenhuma sessão segurando o bundle atual
ConhecimentoIngestão de docs→habilidades (colar / URL) + a fila de aprovação de rascunhos de habilidades
AutopilotA caixa de entrada de revisão (rascunhos/obsoletos/re-revisão de habilidades, propostas de procedimentos, desvios de runbook, pares de memória contestados, dead letters de avaliação), o resumo "o que mudou esta semana", a tabela de conformidade das Living Instructions (taxas por instrução, tendência, fatias por runtime, estados de exposição) e o cartão do Trust Ledger (declarado/reconciliado/calibração/reversões por agente) — somente leitura; propõe e reporta, nunca muta
PadrõesCartões de estratégias descobertas; controles de validação de promoção e experimentos quando suas feature flags estão habilitadas
OpsWorkers, profundidades de fila, agentes ativos, informações do armazenamento vetorial, contador de Discipline (chamadas de memória sem tag)
PolíticaRegras de política de runtime para verificações de segurança pré-edição, alternância por regra
CofreGerenciamento de segredos criptografados (com suporte a Fernet, Redis DB 7)
ReplayLinhas do tempo de rastreamento de sessão, inspetor de eventos, redução de causa raiz
EvalsMétricas de qualidade agregadas, scorecards por sessão, tendências de qualidade
DispositivosCredenciais de dispositivos e comandos de inscrição de uso único
MembrosPessoas e convites de membros de uso único

O dashboard é um SPA estático sem dependências. Sem etapa de build, sem npm, sem framework.

Documentação

DocumentoConteúdo
docs/DEPLOYMENT.mdExecutando um servidor: acesso e autenticação, atualização, backups, solução de problemas, desenvolvimento local (instalação em firekeep.ai/docs.html)
docs/CONFIGURATION.mdTodas as variáveis de ambiente, alocação de DB Redis, recursos de inteligência
docs/MCP-TOOLS.mdReferência completa de ferramentas MCP no servidor e backends locais registrados no cliente; o inventário visível varia conforme o registro dex e as feature flags
docs/DESIGN.mdEspecificação completa da arquitetura, contratos de serviço, pontos de integração
docs/COMPARISON.mdComparação recurso por recurso vs. Claude Code base
docs/SETUP-CODEX.mdGuia de integração com Codex
docs/SETUP-CLAUDE-CODE.mdGuia de integração com Claude Code
docs/MULTI-AGENT.mdInteligência de agentes: briefing pré-voo, debrief de sessão, coordenação multi-agente
studio/README.mdMatriz de runtime do Firekeep Studio, comandos, modelo de segurança, desenvolvimento e empacotamento

Pilha Tecnológica

Serviços de servidor Python 3.11 (cliente suporta Python 3.10+) / FastAPI / FastMCP / Neo4j / Qdrant / Redis / Ollama / Docker Compose / tree-sitter / TypeScript / Electron / React

Embeddings e geração no lado do servidor usam Ollama local por padrão, então o caminho padrão do servidor não tem fatura de API de modelo. O Symdex pode opcionalmente usar Anthropic, Gemini, ou um endpoint compatível com OpenAI para resumos de símbolos e scaffolding; habilitar um desses provedores pode enviar trechos de código para fora da máquina e incorrer em custos do provedor. A indexação automática em segundo plano desativa explicitamente resumos de IA.

Roadmap

Funcionando agora

  • Ciclo de vida completo da memória (aprender, recordar, decaimento, detecção de contradição, versionamento)
  • Quatro tipos de memória (referencial / processual / episódica / transitória) com decaimento de recordação ciente do tipo; aprendizados diretos padrão como episódicos, enquanto a consolidação de eventos brutos classifica o conhecimento extraído
  • Recordação ciente de tokens com síntese opcional por LLM
  • Envelhecimento composto com arquivamento em primeiro lugar (idade × acesso × confiança) com pré-visualização no painel, auditoria e restauração; memórias confirmadas, habilidades e blocos do corpus nunca são arquivados por idade, e a purga automática definitiva está desativada por padrão
  • Continuidade da equipe: proveniência verificada de workspace/membro além do runtime agent_id + project, relatórios de contribuidores, briefings de handoff sintetizados por LLM
  • Persistência de sessão por meio de compressões de contexto, com detecção de falhas e retomada por snapshot do workspace
  • Emissão de replay de bridge no ciclo de vida da sessão (iniciada / atualizada / concluída / abandonada)
  • Monitoramento de Docker + git + arquivos com alertas Relay; atividade de contêiner/commit/arquivo flui para o stream de replay
  • Coordenação de agentes: canais, quadro de avisos, leases de token de fencing, fila de tarefas estruturada, registro de presença, mensagens diretas
  • Briefing pré-voo monta inteligência de todos os serviços no início da sessão; exibe avisos de disciplina quando chamadas de memória chegam sem cabeçalhos de identidade
  • Debrief de sessão: conclusão guiada com atualizações de tarefas e limpeza de leases
  • Suporte multiagente (atribuição de tarefas, polling de caixa de entrada, aplicação de leases de arquivo)
  • Habilidades: autoradas por agentes via skill_create (lado do cliente) + um pipeline de docs→habilidades (colar / URL / coletores agendados do Confluence) redigindo habilidades sob revisão humana; as melhores correspondências são injetadas no próximo briefing (auto-síntese no lado do servidor existe atrás de SKILL_SYNTHESIS_ENABLED, desativada por padrão)
  • Night Shift: firekeep night-shift drena a fila de destilação de sessão que o hook de fim de sessão preenche, rodando na sua própria máquina contra um modelo local — LM Studio ou Ollama, detectados automaticamente, sem configuração — e escrevendo memórias além de rascunhos de habilidades atribuídos à sessão original em vez do worker. Mantém a geração totalmente fora do servidor; modelos hospedados em nuvem são recusados por padrão para que o conteúdo da sessão não saia da máquina
  • Decision Board: quadro de esclarecimento local gerado por agentes, pré-populado com evidências recuperadas da memória da equipe (servidor stdio firekeep-decision + Cortex /decision/synthesize)
  • Modo pessoal / bypass: /personal em sessão (ou firekeep personal / FIREKEEP_BYPASS=1) torna o Firekeep totalmente dormente para trabalho privado — hooks, sidecar, decision board e shim respeitam um único gate is_bypassed(); limpa automaticamente no fim da sessão
  • Pattern Engine: detecção de estratégias, classificação de categorias (processual / risco / comportamental) e controles de quarentena; promoção/validação automatizada implementada atrás de PATTERN_VALIDATION_ENABLED=false por padrão
  • Estrutura de experimentos: conjuntos de dados nomeados, testes de significância qui-quadrado, intervalos de confiança de tamanho de efeito e experimentos controlados de dicas de estratégia atrás de PATTERN_EXPERIMENTS_ENABLED=false por padrão
  • Loop de feedback opcional para medir se dicas de briefing melhoram resultados quando a validação de padrões está habilitada
  • Motor de políticas em runtime: verificações compostas pré-edição (lease, risco de arquivo, negação de caminho, saúde da sessão, falha recente)
  • Agent Gateway (prever-depois-agir): MCP action_before / action_after, o gateway retorna allow | rethink | block, cache de caminho rápido para ações repetidas de baixo risco
  • Cofre de segredos criptografado (Fernet) com ferramentas MCP e API REST
  • Traços de replay com estreitamento de causa raiz e reconstrução de contexto por evento
  • Auto-avaliações: 10 métricas de qualidade Tier-1 calculadas na conclusão da sessão, acompanhamento de tendências, detecção de regressão
  • Knowledge Autopilot rodada 1 (visibilidade, nunca mutação autônoma): recordação ponderada por feedback + a ferramenta memory_feedback, um reaper de sessões Bridge para que sessões com falha contem como falhas, tratamento de contestado-não-substituído para conflitos de memória não confirmados com vereditos humanos, a caixa de entrada de revisão do Autopilot + resumo semanal, e um livro-razão de evidências por memória (/memory/{id}/evidence) — veja docs/guides/knowledge-autopilot.md
  • Living Instructions rodadas 1 + 2 (medição): a tabela de conformidade por instrução na aba Autopilot (predicados congelados em uma linha de base pré-registrada), tendência ao longo do tempo e o contrato de medição da rodada 2 — hashes de conteúdo de instrução carimbados no bloco renderizado, cinco cabeçalhos de atribuição, fatias por runtime e estados exposto/não-exposto/desconhecido com tudo não verificável relatado como desconhecido. Reescritas sob veredito humano e variantes A/B entregues por briefing estão no roadmap — veja a especificação de design em docs/ROADMAP.md
  • Dreaming: consolidação automática de memória + perfis de pessoas (DREAM_ENABLED, desativado por padrão)
  • Living Procedures rodadas 1 + 2: habilidades observadas como procedimentos com propostas de frequência/eficácia sob revisão humana e — rodada 2 — Runbooks Reforçados: correspondentes de etapas de comando, aplicação de advise/require_ack/block armada por humanos com evidência com gate de sucesso, um protocolo desafio→ack→permissão de uso único, modo de bloqueio com falha fechada e um livro-razão de desvios por workspace exibido no painel e na caixa de entrada do Autopilot (PROCEDURE_ENABLED, desativado por padrão; dogfooding antes de qualquer anúncio) — veja docs/guides/living-procedures.md
  • Trust Ledger rodada 1: um registro de emprego por agente agregado sob demanda a partir de eventos de replay do gateway (GET /autopilot/trust + um cartão no painel) — contagens declaradas/conciliadas, calibração de correspondência de previsão, reversões, sessões. Apenas visibilidade, global à implantação, fórmulas congeladas pré-registradas antes do primeiro número publicado. O corretor de capacidade de aplicação (autonomia conquistada) é uma rodada posterior
  • Reforço de tenancy do corpus: fontes de documentos privadas por membro com um filtro de visibilidade compartilhado em cada saída, identidade de ponto com escopo por fonte (texto idêntico entre membros não colapsa mais em um ponto deletável), autorização de fonte ciente do principal e um gate de geração confirmada — infraestrutura geral abaixo dos futuros dexes do cliente
  • Um gateway MCP local degradante registrado por cada adaptador, agregando quatro serviços remotos além do Decision Board local do cliente e quaisquer dexes registrados
  • O registro de dexes: dexes são os índices de domínio que o Keep entende, listados e alternados com firekeep dex list|add|remove contra ~/.firekeep/dexes.json. Todas as três rodas são enviadas agrupadas e verificadas por checksum em cada versão — o registro controla a atividade, não a instalação. Symdex e docdex são registrados por padrão (desde o cliente 1.2.0, um registro ausente é semeado com ambos); firekeep dex remove é o interruptor de desligamento, e remoções persistem entre atualizações — veja docs/guides/dexes.md
  • Inteligência de código: firekeep-symdex no lado do cliente atrás do gateway (38 ferramentas, 8 análises ocultas atrás de uma flag), montado quando registrado como um dex
  • Documentos: firekeep-docdex no lado do cliente — pastas que um humano registra (firekeep docdex add ~/Notes) extraídas para texto e ingeridas no corpus, aparecendo por meio do memory_recall comum. Privado para o membro por padrão mesmo em um Keep compartilhado, --shared para o workspace; md/txt/pdf/docx, sem OCR; a exclusão de um arquivo local remove sua réplica do corpus na próxima sincronização
  • E-mail: firekeep-maildex no lado do cliente — caixas de correio IMAP que um membro registra (firekeep maildex add), somente leitura (cada abertura é EXAMINE, cada busca é PEEK; sem capacidade de envio na roda), sempre privado do membro
  • Pipeline de conhecimento docs→habilidades (knowledge_ingest, ingestão por URL) + coletores agendados do Confluence opt-in (SP3)
  • Painel web com gerenciamento de Devices e Members além de memória, coordenação, replay, políticas e operações
  • Endpoint de cartão de agente A2A (/.well-known/agent.json) para descoberta externa
  • Ingestão de conhecimento de negócios: dividir documentos em armazenamento vetorial, exibir durante a recordação de memória
  • Notificações por webhook (Slack, Discord, HTTP genérico)
  • Autenticação: escopos de API por chave (memory:read/write, session:read/write, replay:read, eval:read, admin, …), ativada por padrão, com chaves inicializadas pelo instalador

Prometido (os dois degraus do roadmap publicados em firekeep.ai)

  • Instâncias vinculadas — múltiplos servidores Firekeep compartilhando conhecimento em uma organização, para que o que uma equipe aprende seja recordável por outra
  • Perfis de domínio — experiências separadas (codificação e documentos hoje; pesquisa adiante) como perfis do mesmo kit de cliente sobre um cérebro compartilhado: nunca produtos separados, nunca armazenamentos de memória separados

O registro de decisão por trás de ambos — perfis-não-clientes, o pré-requisito da camada de vinculação, gate de sinais de resultado, sequenciamento — está em docs/ROADMAP.md.

Planejado (menor)

  • Exportação de métricas Grafana
  • Ingestão de conector Jira (auto-sincronização wiki/Confluence já enviada, opt-in)
  • Versionamento e reversão de habilidades

Status

O Firekeep está em desenvolvimento ativo e usado diariamente. As implementações principais — memória, sessões, monitoramento de ambiente, coordenação, replay, o kit de cliente e Symdex — são cobertas por mais de 4.000 testes automatizados aprovados no repositório atual. A arquitetura é projetada para implantação em host único.

Este repositório público, com código-fonte disponível, está em acesso antecipado.

Licença

O Firekeep é de código-fonte disponível sob BUSL-1.1, e o uso de produção auto-hospedado é gratuito para indivíduos e para equipes — um workspace de qualquer tamanho, em infraestrutura que você controla, gratuito para equipes enquanto o Firekeep estiver em acesso antecipado. O nível comercial é governança e suporte Enterprise (escreva para sales@firekeep.ai). Cada versão converte para Apache-2.0 quatro anos após sua primeira publicação pública. Veja LICENSE para a concessão completa e docs/LICENSING.md para o status. Symdex permanece sob esta licença até que seu Core independente seja extraído e lançado separadamente sob Apache-2.0.