Arquiteturas comparadas: dois diagramas interativos (Archify), gerados a partir do código e da documentação reais de cada sistema. Arraste, dê zoom e explore os nós — cada um aponta os arquivos-fonte da afirmação.
Open Dotsbackend FastAPI · bot Telegram · sandboxes Boat
Multiusuário em sandbox vs single-user dono da máquina. O Open Dots isola cada aluno num sandbox Boat separado, com motor de permissões (hook + token) aprovando cada ação. A Naia Kimi roda como uma única orquestradora na máquina do Chefe, protegida por zonas confiáveis (trusted-folders) em vez de sandboxes por usuário.
Custo por segundo de sandbox vs custo marginal zero. Cada sandbox Boat é infra provisionada que cobra enquanto existe. A Naia Kimi roda na assinatura Kimi Code (modelo K3): subagente e worker headless não adicionam custo de API por tarefa.
Memória por aluno vs memória profunda compartilhada. O Open Dots guarda credenciais e tarefas por usuário no PostgreSQL (cifradas com Fernet). A Naia Kimi mantém um banco único naia_memory com identidade própria (agent_id='naia-kimi'), consultado a cada prompt pelo hook de grounding.
Backend de produto vs organismo vivo. O Open Dots é um backend FastAPI clássico com 3 loops de agendamento. A Naia Kimi é um conjunto de daemons launchd (KeepAlive, consolidador, watchdog, checkpoint) em volta de uma sessão tmux permanente que nunca morre.
Permissão por hook de sandbox vs permissão por hook de pasta. No Open Dots, o sandbox pergunta "posso?" ao backend antes de agir (PermissionRequest). Na Naia Kimi, o hook PreToolUse bloqueia escrita fora das zonas confiáveis antes da ação acontecer.
Autenticação por aluno vs cofre único. OAuth Claude e GitHub device-flow individuais no Open Dots. Na Naia Kimi, todo segredo sai do mesmo cofre 1Password, lido em runtime, nunca em arquivo.
Execução isolada vs delegação para um time. O Open Dots executa a tarefa dentro do sandbox do aluno. A Naia Kimi não executa tarefa longa: planeja e delega para subagentes especialistas e workers headless com progresso rastreado.