Skip to main content
O Conversation Hub faz a conversa atravessar canais. Um assunto começado no Telegram continua quando você abre o chatcli no notebook; o que você responde no notebook vira contexto no Telegram/Slack/WhatsApp. Os dois lados se entendem — sem você repetir nada.
O hub é uma ponte do momento, não memória de longo prazo. Ele mantém a conversa atual sincronizada entre canais, com banco limitado (poda automática). Memória persistente entre projetos/sessões continua sendo o sistema de memória (/memory) e o /session save.

​
Como funciona

  • Principal: a identidade compartilhada da conversa. No modo single-user (padrão), o CLI local e o gateway colapsam no mesmo principal (default se você não definir nada), então tudo compartilha sem configuração.
  • hub.db: um log append-only em SQLite (~/.chatcli/hub.db). O CLI e o daemon do gateway abrem o mesmo arquivo — é por isso que se entendem entre processos.
  • Efêmero por sessão: ao abrir o chatcli, começa uma conversa nova e a anterior é podada — o banco não cresce e você não carrega um histórico gigante. Conversas ociosas além do TTL (CHATCLI_HUB_TTL_HOURS, padrão 24h) são varridas.
  • Silencioso: mensagens de outros canais entram no contexto do modelo sem serem impressas no seu prompt (nada de poluição, nada de “apertar Enter pra continuar”).
  • /newsession zera a conversa compartilhada para todos os canais.
Funciona em chat, /agent e /coder: o pedido e a resposta final atravessam os canais (o detalhe de execução das tools fica local em cada máquina).

​
Modos

O caso mais simples — chatcli + gateway no mesmo notebook, zero configuração (basta o principal padrão):
Converse no notebook, depois puxe o assunto no Telegram → tem o contexto. Mande no Telegram com o prompt aberto → entra no contexto do próximo turno do notebook.
Cross-process, o notebook pega o contexto no próximo turno (não há push ao vivo no prompt já aberto). Para tempo real, use o modo co-locado abaixo.

​
Comandos

As settings do hub são mutáveis em runtime e persistem no hub.db (lidas ao vivo pelo gateway, sem restart):
Precedência de resolução: setting (db) > variável de ambiente > default.

​
Identidade compartilhada (single-user vs multi-user)

Com o isolamento ligado, o gateway também dá a cada principal seu próprio conjunto de stores — sessões salvas, memória de longo prazo, contextos de conhecimento, arquivo CCR, snapshots de custo, journal de transcript e a conversa viva — na raiz ~/.chatcli/tenants/<principal>/. O conjunto é instalado para o turno daquele remetente e o compartilhado é restaurado depois, então um /session list num chat nunca mostra as sessões de outro usuário e os fatos de um usuário nunca aparecem no turno de outro. CHATCLI_GATEWAY_MAX_TENANTS (16) limita quantos conjuntos ficam residentes; os menos usados recentemente são liberados e reconstruídos do disco no próximo turno. Execuções parkeadas (/park, /resume) e execuções de task-graph também seguem a raiz do tenant, e CHATCLI_DAILY_BUDGET_USD limita o gasto de cada tenant por dia-calendário separadamente. Tudo que deriva de uma conversa troca junto com o conjunto: o cartão de memória do início de sessão, a pilha de undo do /rewind compact, o último trace de auto-recall, a marca d’água de encaminhamento do provedor de memória externo, imagens recebidas pendentes e a última resposta do agente; o memory worker base continua lendo o histórico base enquanto o turno de um tenant roda, e as chamadas MCP memory_recall / memory_store de um provedor externo carregam um argumento tenant. O que fica global ao processo está listado em “Compartilhado entre tenants” no /config security: hooks, o MCP manager (servidores e OAuth), o reflexion runner, o arquivo de histórico do REPL, o banco do hub e o scheduler — além do board do squad e do cache de vocabulário do tokenizer (dados públicos).

​
Relação com memória e sessões

O hub é um trilho paralelo aditivo: o histórico local, o /session save e a memória continuam funcionando exatamente como antes. Para continuidade durável de uma conversa nomeada entre REPL, IDE, MCP e gateway, veja Continuidade cross-surface — o hub segue sendo a ponte em tempo real do turno atual.

​
Observabilidade — o hub nunca morre em silêncio

A continuidade depende do hub estar de pé, então todo estado dele é explícito no log:
  • Hub ativo: o daemon loga gateway: conversation hub active (principal=…, isolate=…, idle_ttl=…) no boot; o CLI loga local hub mode enabled.
  • Hub desligado: um Warn nomeia a fonte exata da decisão — db setting enabled=false, env CHATCLI_HUB_ENABLED=false ou default — em vez de simplesmente sumir com a continuidade.
  • Daemon servindo sem hub (banco inacessível): um aviso único por execução deixa claro que as respostas estão sem contexto cross-channel.
O daemon herda o ambiente da shell que rodou /gateway start, e o .env não sobrescreve variáveis já exportadas. Um CHATCLI_HUB_ENABLED=false esquecido na shell desliga a continuidade mesmo com o .env correto — o log de proveniência acima existe exatamente para flagrar isso (ps eww <pid> confirma o ambiente real do processo).

​
Veja também