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)

​
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