Um agente de código trabalha a partir do teu repositório e dos teus ficheiros e consegue conduzir um browser real; um agente de browser clica em páginas web, mas guarda pouca memória do teu produto ou do que «feito» significa em cada site; um serviço feito por eles faz o trabalho por ti e envia um relatório. Os três conseguem pôr um SaaS listado em algumas dezenas de diretórios. Costumam ser comparados pelo preço, mas o que decide a escolha é o que cada um precisa de ti, quem fica com as contas e o que é teu quando o lote termina.
Este artigo explica isso com clareza, com um caminho de decisão no fim. É escrito pela equipa por trás da primeira opção, por isso diz-te abertamente onde um serviço é a melhor resposta.
Opção 1: o teu agente de código
Um agente de código — Claude Code, Codex, o agente do Cursor ou uma ferramenta semelhante que lê um repositório e chama ferramentas — torna-se um motor de submissões quando lhe dás três coisas: um browser que consiga operar, os factos do teu produto em ficheiros que consiga ler, e instruções por diretório que digam o que o formulário quer e quando parar.
O que precisa. Git e Python 3.10 ou mais recente para o tracker local e o painel. A versão atual do Chrome, Node.js LTS e npm para a ligação ao browser: o kit usa o Chrome DevTools MCP, que permite a um agente de código “control and inspect a live Chrome browser” (controlar e inspecionar um browser Chrome em execução), ligado a um Chrome onde tens sessão iniciada e que consegues ver. Os factos do teu produto num ficheiro, a tua identidade pública noutro, e uma decisão sobre que dados pessoais podem aparecer nas listagens. Depois, um prompt inicial. O guia de ligação ao Chrome percorre a configuração.
Modelo de custo. Pagas ao teu fornecedor o uso do agente e, com o LaunchRepo, um pagamento único pelo repositório. O teu segundo produto custa tempo de agente, não uma segunda licença, e não há taxa por diretório.
Controlo. Total e visível. O agente trabalha no teu browser com as tuas contas. Quando aparece um CAPTCHA, um pedido de dois fatores ou um e-mail de verificação, regista prepared_needs_human e resolve-lo tu na mesma janela. Nunca paga: um diretório cuja única via custa dinheiro é registado como deferred_paid, e a decisão fica contigo. Cada resultado fica num tracker local com uma data e, quando existe, um URL público.
O que fica teu depois. As contas, as listagens, o tracker com os estados reais, os playbooks e um fluxo que podes repetir no próximo trimestre ou para o próximo produto. Nada vive no servidor de um fornecedor.
Onde pede esforço. Uma configuração única: ligação ao browser, permissões e uma primeira sessão de onboarding. Durante um lote ficas por perto para as passagens de testemunho. Se nunca correste um agente com uma ferramenta de browser, conta com a primeira hora como aprendizagem. As páginas de agentes cobrem cada configuração: Claude Code, Codex, Cursor, OpenClaw, Gemini CLI, Cline, OpenCode, Kiro, GitHub Copilot e Windsurf, cada uma verificada face ao browser e ao modelo de aprovações documentados da ferramenta.
Opção 2: um agente de browser
Os agentes de browser, alojados ou locais, já fazem os cliques. Aponta um a um formulário de submissão, dá-lhe o texto, e ele preenche o formulário. Parece a opção 1, mas difere numa coisa importante: por defeito, um agente de browser não leva o teu produto de site para site e não tem regra para o que conta como concluído num dado diretório.
O que precisa. Os mesmos factos do produto e a mesma identidade, entregues a cada sessão, porque um agente de browser alojado não consegue ler o teu repositório. Um briefing por diretório: o que o formulário pede, o que conta como confirmação, o que recusar. E uma forma de registar resultados, já que o agente normalmente não consegue correr o teu tracker.
Modelo de custo. Faturação por uso do fornecedor do agente, por vezes uma subscrição do próprio produto do agente, mais o que quer que forneça os briefings. A página de agentes de browser explica como os playbooks do kit podem cumprir esse papel quando o agente não consegue ler ficheiros. A OpenAI retirou o modo agente do ChatGPT; o que o substituiu e até onde chega num lançamento tem uma página própria com data.
Controlo. Alto enquanto estás a ver, mais baixo quando desvias o olhar. Sem regras, um agente de browser pode clicar em “Upgrade” (subir de plano) quando o formulário gratuito está por trás, submeter duas vezes depois de uma confirmação pouco clara, ou anotar “launched” (lançado) depois de ver uma página de agradecimento. Essas regras têm de vir de algum lado.
O que fica teu depois. As contas e as listagens, se foste tu a iniciar sessão, e um registo, se o guardaste. Um histórico de sessões não é um tracker de submissões.
Onde brilha. Formulários pesados e visuais e submissões pontuais em que um repositório seria excessivo. É mais fraco em lotes de trinta plataformas com acompanhamento ao longo de várias semanas, porque isso é um trabalho de acompanhamento de estado.
Opção 3: um serviço feito por eles
Pagas, preenches um formulário sobre o teu produto, e uma equipa — humana, automatizada ou ambas — submete-o a um número fixo de diretórios e envia um relatório. É o segmento maior e mais variado, e o serviço de submissão feito por eles certo poupa tempo a sério.
O que precisa. De ti: factos do produto, um logótipo, capturas de ecrã e por vezes acesso a um endereço de e-mail. Do fornecedor: a escolha de um pacote. A gestão das contas varia. Alguns fornecedores criam um novo endereço de e-mail e entregam as credenciais, outros usam o teu, e um que verificámos submete a diretórios que só oferecem início de sessão com Google “using our own Google account” (com a nossa própria conta Google). Lê essa parte antes de pagar; as páginas de comparação citam cada fornecedor.
Modelo de custo. Normalmente uma taxa única por produto ou site, escalonada pelo número de diretórios; por vezes um plano mensal. A 30 de setembro de 2026, os planos de pagamento único dos fornecedores que comparamos iam de $60 a $999 por produto. O teu segundo produto custa o mesmo outra vez.
Controlo. Baixo por conceção, e é precisamente o que estás a pagar. Vês um relatório no fim. Se uma listagem usou a via gratuita, e se «listado» significa online ou em revisão, depende dos relatórios do fornecedor. Alguns entregam links online e capturas de ecrã, outros uma folha de cálculo.
O que fica teu depois. As listagens que ficaram online, e as credenciais das contas se o fornecedor as entregar. O produto seguinte é uma nova encomenda. Alguns serviços prometem um nível de domain rating ou um número de listagens; quem decide o que publica continuam a ser os diretórios.
Onde é a resposta certa. Um produto, nenhum interesse em agentes e um orçamento. Então um serviço é uma escolha sensata, e o hub de alternativas ordena os fornecedores por modelo para que escolhas com base em factos.
As diferenças que decidem
| Agente de código + kit | Agente de browser | Serviço feito por eles | |
|---|---|---|---|
| Quem faz o trabalho | O teu agente, no teu browser | O agente, no browser dele ou no teu | A equipa ou a automação do fornecedor |
| Quem tem as contas | Tu | Tu, se iniciaste sessão | Fornecedor ou tu, conforme o pacote |
| O preço cresce com | Uso do agente | Uso do agente | Número de produtos |
| Segundo produto | Mesmo repositório | Mesma configuração, novos briefings | Nova encomenda |
| Passagens (CAPTCHA, 2FA) | Registadas, resolves tu | Tuas, se reparares | O fornecedor trata ou salta |
| Via gratuita vs paga | Gratuita por defeito, nunca paga | O que ele clicar | Definida pelo pacote |
| Registo do que aconteceu | Tracker local, 11 estados | O que guardaste | Relatório do fornecedor |
| Depois | Playbooks, tracker, contas | Contas | Listagens, relatório |
A linha «segundo produto» é a que separa os compradores. Se lanças um produto por ano, a coluna do serviço ganha em esforço e a diferença de preço é pequena. Se lanças vários, ou relanças depois de mudar de nome, a coluna do repositório ganha em ambos, e a coluna do agente de browser depende do cuidado com que guardas registos.
Um caminho de decisão em cinco perguntas
Responde por ordem e para no primeiro resultado claro:
- Queres sequer mexer no processo? Não: escolhe um serviço e compara os fornecedores na gestão das contas e nos relatórios.
- Vais lançar mais de um produto, ou relançar um? Sim: um agente de código com um repositório compensa a partir da segunda ronda.
- Já usas um agente de código num terminal ou editor? Sim: acrescenta uma ligação ao browser e os playbooks; já tens a maior parte do caminho feito.
- É um formulário único, visual e pontual? Sim: um agente de browser com um briefing claro é o mais rápido.
- Precisas de um registo de entradas agendadas, em revisão e online durante semanas? Sim: usa um tracker, seja qual for a opção que faz os cliques.
O que o LaunchRepo é, neste enquadramento
O LaunchRepo é a opção 1 empacotada: 299 playbooks de plataformas ativas à data de 24 de setembro de 2026, um modelo de produto, um tracker com onze estados de resultado distintos e um painel local, num repositório privado que o teu próprio agente corre. Serve também como o livro de regras que falta à opção 2, e é por isso que existe a página de agentes de browser. Não é a opção 3: não há equipa gerida, só um repositório e um preço para todos os produtos que tens.
Por isso, escolhe pelo que queres que fique teu depois. Se a resposta é «só as listagens», paga a um serviço. Se a resposta é «o processo», compra o repositório e entrega-o ao agente que já tens.
Perguntas frequentes
Qual é a diferença entre um agente de código e um agente de browser?
Um agente de código lê e escreve ficheiros num repositório e chama ferramentas, incluindo um browser através de um servidor MCP. Um agente de browser opera páginas web diretamente, mas normalmente não consegue ler os teus ficheiros nem manter estado entre sessões. Para submissões a diretórios, esse estado — factos do produto, regras e resultados — é o que mais importa.
Um agente de browser consegue submeter a diretórios sozinho?
Consegue preencher e enviar formulários. Precisa de ajuda externa para saber que via é gratuita, o que conta como confirmação e onde registar o resultado. Com briefings por diretório e um tracker funciona bem; sem eles, os resultados dependem de quão de perto estás a acompanhar.
Um serviço de submissão a diretórios feito por eles vale a pena?
Para um produto e sem interesse em agentes, muitas vezes sim. Verifica quem cria e guarda as contas, se o relatório separa listagens online de listagens em revisão, e o que acontece com os upgrades pagos. As páginas de comparação listam estes pontos por fornecedor.
Preciso do Claude Code para usar o LaunchRepo?
Não. O LaunchRepo precisa de um agente que consiga ler ficheiros num repositório e conduzir o Chrome através do Chrome DevTools MCP. As páginas de agentes descrevem o Claude Code, o Codex, o Cursor e os restantes um a um; o kit recomenda um agente CLI num terminal para a execução mais fluida.
Quem é dono das contas nos diretórios?
Com um agente de código ou um agente de browser que usa o teu browser com sessão iniciada, és tu. Com um serviço, depende do pacote: pergunta antes de pagar se as contas são criadas em teu nome e se as credenciais te são entregues.
Fontes: o repositório do LaunchRepo (START.md, BROWSER-SETUP.md, record.py com os seus onze estados) e o instantâneo do catálogo de 24 de setembro de 2026; o README do Chrome DevTools MCP e a documentação de MCP do Claude Code, consultados a 30 de setembro de 2026; páginas dos fornecedores verificadas para as páginas de comparação a 30 de setembro de 2026. Nenhum fornecedor foi contactado para este artigo.