Como usar Ollama e SSH no terminal lado a lado

Divida o espaço de trabalho: um painel para o Ollama, outro para o SSH

Abra um espaço de trabalho, divida em dois painéis e rode ollama serve em um deles. Para um chat interativo, use ollama run llama3. Para trazer o SSH ao espaço de trabalho, conecte pelo SSH Manager (⇧⌘H), que abre numa aba própria, e divida essa aba para o Ollama. Ou digite ssh user@host em um painel.

Os dois são PTYs reais, processos independentes do sistema operacional. Redimensionar um, focar nele ou fechá-lo não afeta o outro.

Vale acompanhar a saída do Ollama enquanto você trabalha em um servidor remoto: progresso do carregamento do modelo, logs de requisições, avisos de memória. Você não precisa dar alt-tab para outro app de terminal para ver se o Ollama ainda responde ou se um modelo terminou de carregar. Ele está no painel ao lado.

Como acessar o Ollama local a partir de um servidor remoto

Por padrão, o Ollama escuta em 127.0.0.1:11434, então só aceita conexões da própria máquina em que roda. Digamos que um script no servidor remoto chame a API do Ollama do seu Mac em /api/generate. O localhost desse servidor remoto não é o localhost do seu Mac, então sem um túnel a requisição falha.

Em vez disso, ligar o Ollama a OLLAMA_HOST=0.0.0.0 expõe uma API sem autenticação, então o túnel é a opção mais segura.

A solução é um túnel SSH reverso padrão, nada que o MXterm Pro acrescente por cima: ssh -R 11434:localhost:11434 user@remote-host. Ele encaminha a porta 11434 do servidor remoto de volta para a instância do Ollama no seu Mac. Aí o curl http://localhost:11434/api/generate executado no servidor remoto acessa o seu modelo local.

O sshd remoto precisa permitir encaminhamento TCP, e a porta é ligada apenas ao loopback do host remoto. O gerenciador de túnel SSH do MXterm Pro só adiciona encaminhamentos locais (-L), então digite esse comando ssh você mesmo em um painel local no seu Mac. É port forwarding SSH comum, então funciona a partir de qualquer app de onde você conecte por SSH.

No caso inverso, com o Ollama rodando em uma máquina remota com GPU que você quer consultar do seu Mac, use um túnel local (-L) normal: ssh -L 11434:localhost:11434 user@gpu-host. Aí o curl http://localhost:11434/... executado localmente acessa o modelo remoto.

RAM, GPU e disputa de recursos entre painéis

O ollama ps lista os modelos carregados e quanta memória cada um ocupa, então é uma checagem rápida a partir de outro painel. Um modelo carregado fica na RAM até o Ollama descarregá-lo, por padrão cinco minutos depois da última requisição. Ele também fica na memória da GPU se usar aceleração Metal ou CUDA. OLLAMA_KEEP_ALIVE=10m ollama serve muda essa janela.

A disputa de recursos é onde os painéis podem dar problema. O MXterm Pro não isola nem limita o que o processo de um painel pode usar, então um painel de terminal consome tanto quanto o shell por trás dele.

Adicione um terceiro painel com um agente de código compilando um projeto grande, e os três painéis passam a tirar da mesma RAM, CPU e GPU do seu Mac. Em uma máquina com pouca memória, esse teto compartilhado é o limite prático, e não algo específico de painéis ou de SSH.

Se o ollama serve se recusar a iniciar com o erro "address already in use", algo já está ligado à porta 11434. Muitas vezes é um painel anterior ou o app Ollama da barra de menus, se você o tiver instalado. Rode lsof -i :11434 para ver o que está ocupando a porta antes de encerrar o processo ou simplesmente reaproveitar a instância em execução.

Command Recipes e um agente de código no mesmo espaço de trabalho

O Command Recipes do MXterm Pro (Cmd+J) não tem relação com o modelo que o Ollama estiver servindo. Ele não usa nenhum modelo, só um conjunto fixo de comandos Linux prontos, encontrados por palavra-chave. Não há configuração para apontá-lo para o Ollama.

Aqui ele é útil por um motivo mais restrito, sobretudo no painel conectado por SSH a um servidor Linux. Você chama um comando pronto sem precisar consultar as flags: quais processos usam mais RAM, as últimas 50 linhas do log do sistema, o que está ligado à porta 11434. São comandos Linux, então as receitas de RAM e de log não funcionam como estão em um painel local no macOS. Nenhuma receita cobre memória de GPU.

Se um agente de código (Claude Code, Codex, Cursor) estiver gerando código que chama a API do seu modelo local, rode-o em um terceiro painel. O agente, o modelo e o servidor para onde você faz deploy ficam visíveis em um único espaço de trabalho.

Ativar Isolar funcionalidades em git worktrees no Composer dá a cada painel de agente o próprio checkout em <repo>/.worktrees/<slug>, em uma branch própria, quando a pasta é um repositório git. A opção vem desativada por padrão. Ela reduz a chance de dois agentes colidirem nos mesmos arquivos no meio de uma edição.

Quanto isso custa: Free x Pro

Nada disso exige o plano Pro. Por padrão, o plano Free do MXterm Pro cobre painéis de terminal ilimitados, até 5 hosts SSH salvos e 1 Máquina salva, com gerenciamento completo de arquivos por SFTP em interface gráfica. Um painel do Ollama e um painel SSH são apenas dois painéis, e o popup do Command Recipes não usa nenhum: longe de qualquer limite para este fluxo específico.

O limite passa a importar quando você gerencia mais de 5 hosts remotos ao mesmo tempo. O plano Pro remove o limite de hosts SSH: hosts SSH salvos ilimitados.

iTerm2 + tmux, Warp e clientes só de SSH

O iTerm2 já tem painéis divididos de verdade, e muitos devs rodam ollama serve em um painel do iTerm2 e o SSH em outro. Você também pode manter o Ollama vivo dentro de uma sessão tmux em um servidor remoto, para ele sobreviver a uma desconexão SSH. Essa configuração é sólida se painéis divididos são tudo de que você precisa.

O iTerm2 é maduro, programável e gratuito. O recurso Snippets reenvia textos que você mesmo salva, enquanto o Command Recipes vem como um conjunto pronto de comandos Linux para as checagens em volta dessa sessão. O iTerm2 também não tem um jeito nativo de isolar o diretório de trabalho de um segundo agente de código de IA, se você estiver rodando um no mesmo repositório.

O Warp tem recursos próprios de IA e se organiza em torno de blocos de comando, então é um fluxo diferente, e não uma lacuna. O Termius e o MobaXterm são clientes SSH/SFTP fortes e consolidados, com gerenciamento real de hosts salvos, uma boa escolha se o lado SSH é todo o trabalho.

O MXterm Pro reúne Ollama, SSH e um painel de agente em um espaço de trabalho, com Command Recipes e worktrees por agente.