Novidades

16 de outubro de 2026

• Um nome para cada job: o job recebe o nome do cenário ao ser enviado, e um membro o renomeia no app. O app passa a mostrar o nome no lugar do id: no título da página do job, na lista do projeto, no extrato de créditos e na barra lateral. Pela API e pelo MCP, o nome vem em nome (GET /v1/jobs/{id}, get_job, list_jobs).
• A barra lateral em árvore: a seta ao lado de Projetos lista todos os projetos da organização, e a seta de cada projeto lista os jobs mais recentes dele, pelo nome.
• Os achados com o nome do município: as tabelas de achados do app mostram o nome de cada município, e não o código. Na série da base de clientes, os municípios que ficam de fora pelo piso vêm com o nome (nomes_municipios).
• O chat mais explícito na proposta: o assistente parte da data de hoje para o início da campanha, propõe 2 réplicas e sempre diz quantas, põe a mídia só na cidade que você nomeou e dá um nome ao job. O cartão da proposta mostra esses pontos antes de rodar. No extrato de créditos, o que o chat gastou aparece como “Reserva do chat” e “Cobrança do chat”, separado dos jobs.
• A pergunta quando: a página diz que a parte é do público publicado, e não de quem vai aderir, e onde ler “quando metade dos que vão aderir terá aderido”.
• A chuva do município: a chuva de cada mês desde janeiro de 1981 nos 5.570 municípios, com a normal de 1991–2020 e a anomalia de cada ano, de uma estimativa de satélite calibrada com pluviômetros (CHIRPS v3). Conferida contra 150 estações automáticas do INMET, ela erra 5,9% no total anual, na mediana; o erro de cada região está na página.
  • No console: o cartão da chuva mostra a normal mês a mês e a série anual com a anomalia.
  • Pela API: GET /v1/municipios/{codigo}/chuva.
  • Pelo MCP e no chat: get_city_rainfall, com a série mensal só com meses=true.

15 de outubro de 2026

• A referência da API em português: os nomes das operações, as descrições, os grupos e os rótulos da referência passam a vir em português, como o resto da documentação, e o /openapi.json também. As rotas, os nomes dos campos e os códigos de recusa não mudam.
• A release v2.0.0 nas simulações: a Nova simulação passa a usar a v2.0.0 por padrão, a população em que cada domicílio está no setor censitário do seu endereço. Os setores com 20 moradores ou mais e nenhuma pessoa sintética caem de 47.312 para 730. O caso Pix da biblioteca e o rótulo calibrado valem nela: 20 UFs passam no teste fora da amostra, e 7 têm uma reprovação declarada (O que medimos). Os públicos de 5 anos abrem nas 27 UFs, o Piauí incluído. As releases v1.0.0 e v1.2.0 continuam oferecidas, com os números delas; o preço de um pedido muda menos de 0,01% entre as releases.
• O diagnóstico na população v2.0.0: a cidade aberta agora usa a população sintética v2.0.0, em que cada domicílio está no setor censitário do seu endereço. O número modelado por setor (renda, escolaridade e trabalho) passa a aparecer em 71% dos setores com moradores, onde vivem 84% das pessoas, contra 60% e 71% antes. Uma cidade que o projeto já abriu continua na versão anterior até você abrir a nova: o console mostra um aviso com o botão, a cotação traz release_aberta, e o resumo, cada variável e o crescimento dizem a versão servida (release) e a mais nova (release_mais_nova).
• A conta só com e-mail: criar a conta pede só nome, e-mail e senha, sem CNPJ; o nome da organização é opcional e, em branco, vira o seu. A conta já vem com um primeiro projeto, então um agente conectado pelo MCP logo depois do cadastro já tem onde receber o acesso. O CNPJ da empresa e o endereço da nota fiscal passam a ser pedidos na primeira compra de créditos, e o CNPJ depois aparece só mascarado. A compra continua só pelo CNPJ de uma empresa.
• Os textos legais: os Termos de uso, a Política de privacidade, o Acordo de tratamento de dados e Quem somos estão publicados, em Legal, com a empresa que presta o serviço. Criar a conta passa a pedir o aceite dos termos, e quem já tem conta aceita na próxima entrada no app. Antes da primeira base de clientes, um dono ou admin da organização aceita o acordo de tratamento no app; até lá, uma base não é aceita.

14 de outubro de 2026

• Mais setores com nome de lugar: os nomes passam a vir também da própria malha do IBGE (o aglomerado rural, com as aldeias indígenas, as comunidades quilombolas e as agrovilas, e o núcleo urbano) e dos limites de bairro do OpenStreetMap. No país, 60,7% dos setores levam o nome do lugar em que estão, contra 52,8% antes, e nenhum estado perde. As origens novas, ibge_aglomerado, ibge_nucleo e osm_limite, estão em Fontes.
• Os nomes em mais ferramentas: get_city_tracts e get_answers trazem o nome de cada setor que listam (nomes), com o crédito dos nomes em creditos_dos_nomes.
• O crescimento cita as fontes: a resposta do cenário de crescimento passa a trazer fontes, os créditos dos números, e aviso, o texto que a licença do Copernicus pede onde a declividade aparece.
• Um nome para cada setor: onde o IBGE não tem o bairro, o setor passa a levar o nome do lugar do OpenStreetMap dentro dele, como uma vila, um povoado ou um bairro que a cidade conhece, ou “perto de” o lugar mais próximo, a até 1 km do centro do setor; o distrito fica para o resto. No país, 52,8% dos setores passam a ter um nome próprio, contra 35,9% só com o bairro do IBGE. Um nome do OpenStreetMap vem sempre com o crédito “© colaboradores do OpenStreetMap”. O recorte, a licença e o método estão em Fontes.
  • No console: o inspetor mostra o nome novo e, ao lado, o crédito; a busca acha um setor pelo nome do lugar.
  • Pela API: GET /v1/municipios/{codigo}/setores/nomes passa a trazer lugar, origem, credito e distancia_m de cada setor, e o crédito de cada fonte em fontes.
  • Pelo MCP e no chat: get_city_diagnosis e estimate_growth trazem o nome de cada setor que listam (nomes). O assistente do chat chama um setor só por esse nome, nunca de memória, e a resposta que usa um nome do OpenStreetMap termina com o crédito.
• Públicos de 5 anos em 26 UFs: a grade etária abriu em todas as UFs menos o Piauí, nas releases v1.0.0 e v1.2.0. Um público como “25 a 34 anos” passa a ser cotado nelas, com o resultado por município, faixa de 5 anos e sexo. No Piauí, a cotação continua a recusar com age_grid_not_open, e a recusa passa a dizer as UFs fechadas (ufs, na API); o assistente do chat propõe ali os grupos de 10 anos mais próximos.

13 de outubro de 2026

• A biblioteca de campanhas: seis modelos por setor para começar uma campanha (varejo, imobiliário, telecom, saúde pública, educação e serviços públicos), cada um com as premissas escritas e as perguntas que o job vai responder, e o primeiro caso público, a adoção do Pix, com o veredito fora da amostra e o erro de cada UF e a fonte. Um modelo traz premissas, não resultado.
  • No app: Biblioteca, no menu, abre a Nova simulação já preenchida para o lugar que você escolher.
  • No chat: o assistente oferece um modelo quando você não sabe por onde começar.
  • Pela API e pelo MCP: GET /v1/biblioteca e GET /v1/biblioteca/{modelo}, com uf ou municipio para receber o pedido daquele lugar; list_campaign_templates e get_campaign_template. Qualquer chave do projeto lê a biblioteca, sem custo.
• O chat em toda organização: o chat do app passa a valer para toda organização, sem pedido ao suporte. Cada mensagem continua cobrada pelo uso, dentro do limite mensal de gasto da organização.
• Os achados dizem o nome e o sentido de cada número: get_findings passa a trazer o nome de cada município (municipios) e o que cada coluna quer dizer (descricao). Por exemplo, o alcance conta cada pessoa uma vez, dentro ou fora do público, e a penetração é sobre o município inteiro. compare_jobs e get_answers trazem os nomes também, e a frase de cada resposta passa a nomear o município em vez do código. Um agente não precisa mais adivinhar o nome de um município pelo código.
• Apagar um projeto, a organização ou a conta: um admin ou dono apaga um projeto, e um dono apaga a organização, com 7 dias para desfazer; depois, a plataforma apaga para sempre o que eles guardam, menos o registro de cada job, só com os hashes, e o que a lei fiscal manda guardar. Cada pessoa apaga a própria conta no perfil. Nenhum agente conectado apaga.
• A taxa de serviço do estorno: o estorno de uma compra devolve a parte ainda livre menos R$ 2,00, a pedido pelo suporte. Não há taxa quando o estorno corrige um erro nosso, nem quando a lei garante o arrependimento.
• A tabela por setor conta só quem os achados contam: as pessoas das células retidas pela regra dos 5 ficam de fora também da tabela de eventos por setor e das respostas por setor, como já ficavam dos achados, para que a diferença entre as duas tabelas não as revele. As contagens por setor de um job novo podem sair um pouco menores que as de antes.
• As respostas por setor passam pelo corte do diagnóstico: uma resposta por setor (uma lista de setores, ou os setores no raio de um ponto) sai sem número, com o motivo, quando algum desses setores não passa no corte de erro do diagnóstico, como já acontecia na tabela de eventos por setor. Cada resposta por setor passa a listar em base.setores os setores em que foi calculada. E a descrição dessa tabela (GET /v1/jobs/{id}/setores) passa a dizer o que ela serve: a média das réplicas, arredondada, que pode ficar entre 1 e 4, embora cada réplica publique zero ou ao menos 5.
• Comparar dois jobs: duas simulações concluídas da mesma release, lado a lado: o cenário de cada uma e os números principais de cada tabela dos achados (a saturação, o alcance e o efeito de cada canal), linha a linha, com a diferença. A comparação lê só o que os achados servem, com a mesma regra de privacidade. Pela API, GET /v1/jobs/compare?a={id}&b={id}; pelo MCP, compare_jobs, que o assistente do chat também usa.
• O schema do pedido de calibração: o JSON Schema do pedido de calibração é público em GET /v1/schemas/pedido-calibracao, como o do cenário, e tipa o pedido na referência da API e nas ferramentas de calibração do MCP. O hash da série continua fora do pedido: a plataforma o calcula das linhas.
• A guarda de 365 dias se cumpre sozinha: no dia seguinte a registro.retencao_ate, a plataforma apaga os dados de um job terminado como num pedido seu. O job passa a mostrar apagamento_pedido_em e registro.apagado_em, e o registro fica, com os hashes. Um job na fila ou rodando nunca é tocado.
• O município inteiro e as ruas no relevo: com o relevo ligado, o console mostra também o resto do município e uma margem dos vizinhos, numa grade mais espaçada sob a da área urbana, e as ruas do mapa de fundo passam a acompanhar o terreno. Pela API, GET /v1/municipios/{codigo}/relevo?quadro=municipio traz a grade do município inteiro.
• O cenário de crescimento: diga onde fica um loteamento novo e quantos domicílios ele terá, e a plataforma responde o que ele pede da cidade. São os moradores e as crianças por faixa de idade, com a faixa que a medição sustenta; a escola mais próxima de cada etapa, com as matrículas; a unidade de saúde mais próxima de cada grupo; e o saneamento e a declividade dos setores vizinhos. No console, Novo loteamento passa a perguntar ao servidor e marca no mapa os setores de referência, as escolas e as unidades. Pela API, POST /v1/diagnosticos/{codigo}/crescimento; pelo MCP, estimate_growth; no chat, o assistente monta o pedido com você e mostra as frases do servidor.

12 de outubro de 2026

• A distância à saúde: o diagnóstico da cidade passa a trazer, para cada setor, a distância à unidade de saúde mais próxima de cada grupo (atenção básica, pronto atendimento e hospital), pelo cadastro do Ministério da Saúde (CNES), com o código da unidade e a cobertura do município. Conta toda unidade ativa, pública ou privada. No console, um grupo de camadas novo, a unidade mais próxima no inspetor, duas listas nos achados e Nova unidade de saúde para simular uma unidade a mais. Pela API e pelo MCP, variavel=saude; as unidades, em GET /v1/municipios/{codigo}/saude.

• O saneamento por setor: o diagnóstico da cidade passa a trazer, setor a setor, o abastecimento de água, o esgotamento sanitário, o destino do lixo e o banheiro de uso exclusivo dos domicílios, como o IBGE contou no Censo 2022, com o sigilo do IBGE dito como tal. No console, um grupo de camadas novo, o saneamento do setor no inspetor e três listas nos achados. Pela API e pelo MCP, variavel=abastecimento_agua, esgotamento, destino_lixo ou banheiro.

• Os setores pelo nome: o console chama cada setor pelo bairro, ou pelo distrito, com os quatro últimos dígitos do código, e a busca acha um setor pelo nome do bairro. GET /v1/municipios/{codigo}/setores/nomes traz os nomes.

• O contrato de resposta: combine antes de rodar as perguntas que a simulação deve responder (quantos, quando, onde, comparar), e o job devolve uma resposta por pergunta, com o número e uma frase, calculados a partir do que a simulação publicou. No chat, o assistente escreve as perguntas e você confirma. Pela API, GET /v1/jobs/{id}/respostas; pelo MCP, get_answers. Com saida_por_setor, a simulação publica também os eventos por setor e semana (GET /v1/jobs/{id}/setores), com a regra dos 5.

• A cidade em pontos: o console da cidade ganha o relevo da área urbana em 3D, com o uso do solo, as edificações como blocos, as escolas e por onde a chuva escoa; e três ferramentas: o novo loteamento, o público de uma política e o replay de uma simulação por setor.

• O diagnóstico por setor é gratuito: abrir uma cidade deixa de custar R$ 0,01 por setor com o mínimo de R$ 5,50. A cotação passa a mostrar zero, a abertura não toca nos créditos, e quem abriu uma cidade antes guarda no recibo o que pagou.

• O resultado de um job são os achados e o veredito: o link para baixar o arquivo bruto da simulação (GET /v1/jobs/{id}/result, get_result no MCP e o botão na página do job) foi retirado. O que a plataforma devolve é inteligência em palavras e tabelas: GET /v1/jobs/{id}/findings, get_findings e a aba Achados, com a validação de cada UF. O registro do job continua guardando o hash do que a máquina produziu, e os dados seguem apagáveis a pedido.

• O console da cidade: o diagnóstico por setor, no app, passa a ser um console: as camadas na coluna da esquerda (o observado, o modelado, a distância às escolas e agora o território, com a declividade e as edificações de cada setor), um inspetor do setor clicado ou achado pelo código, os números da cidade e uma lista de achados, como os dez setores mais longe de uma creche ou os dez com mais crianças de 0 a 4 anos, cada um levando ao setor no mapa. E a primeira obra para simular: Nova escola, que recalcula no navegador a distância de cada setor à escola mais próxima com uma escola colocada no mapa, e diz quantos setores ficam mais perto e quantos estudantes da etapa moram neles.

• A maior cidade no seu próprio porte: o ajuste do nível por porte passa a ter quatro valores — a maior cidade do estado, as grandes, as médias e as pequenas —, e a busca e o motor leem os mesmos portes, pela população sintética. Um ensaio em dado público mostrou que a maior cidade adota diferente até das cidades grandes ao lado dela, e que portes lidos de dois jeitos deixavam a busca acertar os totais errando município a município. O resultado passa a trazer a razão entre o simulado e o observado de cada município no fim do holdout. Calibrações já guardadas não mudam.

11 de outubro de 2026

• Entre a capital e o interior: a calibração ganha deslocamento_porte, um ajuste do nível por porte de município (cidades grandes, médias e pequenas, pela população do estado), que vale também onde a sua base não tem ninguém. O valor de cada porte aparece nos parâmetros escolhidos; com a série num só porte, o pedido é recusado.
• O veredito em municípios que a busca não viu: com 31 municípios ou mais na série, a calibração separa um terço deles antes da busca e julga o escolhido neles, em todos os períodos. O resultado (transfere ou nao_transfere) vem no veredito e na tela do job, e não muda a aprovação. Você pode escolher os municípios separados (holdout_espacial). O pedido passa à versão 3; um pedido na versão 2 continua aceito, sem holdout espacial, e o id dele muda, porque a versão entra na identidade; um reenvio com a mesma Idempotency-Key devolve o mesmo job.
• Calibrar com a sua base de clientes, pelo chat: guarde a base de interação dos seus clientes em Contexto do projeto → Bases de clientes (CSV ou Parquet, até 100 MB e 1,5 milhão de linhas). O assistente lê as colunas, propõe como ler a base, monta a série por código e cota a calibração; você confirma cada passo e roda com o botão Rodar a calibração.
  • A privacidade: o assistente nunca vê a linha de uma pessoa, e cada leitura da base fica registrada. A base fica guardada até você apagar. Os detalhes estão em Privacidade.
  • Pela API: uma calibração aceita serie_sha256, a série que o projeto montou a partir de uma base, no lugar das linhas.
• Documentos do chat: uma planilha que parece uma base de clientes (com coluna de CPF, e-mail, telefone ou nome, ou com mais de 5.000 linhas) é recusada e vai para Bases de clientes. Planilhas XLS passam a ir salvas como XLSX.
• A calibração na sua base: mande a série de adoção do seu produto, por período e município, e a calibração procura os parâmetros que melhor a reproduzem numa janela e testa o escolhido num holdout que a busca nunca viu.
  • O que volta: o veredito, os parâmetros escolhidos (com o aviso quando um deles fica na borda da faixa pedida) e o que a série não conseguiu distinguir.
  • Onde: POST /v1/calibracoes e GET /v1/calibracoes/{id}; no MCP, estimate_calibration, submit_calibration e get_calibration; o resultado também aparece na página do job.
  • O preço: a mesma tarifa da simulação, por todas as rodadas que a calibração faz.
  • De quem é: o cenário calibrado é só do seu projeto.
• Simular a partir da calibração: um cenário de adoção do mesmo projeto pode partir do cenário que a calibração escolheu, com cenario_base: "calibracao" e o id do job em lancamento.calibracao. As saídas levam o veredito da calibração.
• O cenário passa à versão 3, que só acrescenta essa base. Um pedido na versão 2 continua aceito e é lido como versão 3; o cenario_id dele muda, porque a versão entra na identidade. Um reenvio com a mesma Idempotency-Key de um pedido feito antes da mudança devolve o mesmo job.

10 de outubro de 2026

• A distância às escolas no diagnóstico por setor: para cada setor, a escola mais próxima de cada etapa, da creche ao médio, pela coordenada que a escola declara ao INEP, com a cobertura do município ao lado. Quem já abriu a cidade recebe sem cobrança nova. No app, escolha Distância à escola mais próxima no mapa do diagnóstico; pela API e pelo MCP, variavel=escolas.
• O diagnóstico por setor de qualquer cidade, no app, pela API e pelo MCP. Para cada setor, ele traz o que o IBGE contou no Censo 2022 e o que a população sintética modela (renda, escolaridade, trabalho e estudantes por etapa), com o erro do setor ao lado e o número escondido onde o erro passa de 0,50. Custa R$ 0,01 por setor, mínimo de R$ 5,50, uma vez por cidade, projeto e release. No app, ele abre em Nova simulação → Planejamento urbano: os setores aparecem no mapa da cidade, coloridos pela variável escolhida, com o número e o erro de cada um ao passar o mouse.
• Contexto do projeto: na página de cada projeto, um texto com o negócio, o plano e o que importa, e os documentos que o acompanham (planos, briefings, planilhas). Quem abre o projeto vê os dois; o chat os lê antes de responder.
• Nova simulação:
  • as UFs se escolhem clicando no mapa do Brasil;
  • um tipo novo, Planejamento urbano, para uma cidade só, com a cidade num mapa detalhado (ruas, quadras, prédios, rios e nomes) e o perfil dela. Ali mesmo se abre o diagnóstico por setor;
  • sem saldo para o preço, a compra de créditos abre por cima do formulário, e o que já foi preenchido continua lá.

9 de outubro de 2026

• Nova simulação no app: monte, cote e envie uma campanha de recepção por um formulário, com o preço ao lado; Duplicar reabre o pedido de um job para ajustar e enviar de novo.
• O palco na página do job: enquanto o job roda, o mapa da UF, a população sintética, o público do pedido e as cinco camadas por onde a mensagem viaja; depois que ele conclui, a campanha dia a dia, município por município, pelos achados de saturação.
• O perfil da cidade: a área urbanizada e o uso do solo de cada município e, por setor censitário, as edificações e a declividade, com a área de 30% ou mais. Em GET /v1/municipios/{codigo}/perfil e /setores, em get_city_profile e get_city_tracts no MCP, e no cartão da cidade da Nova simulação. É contexto e não muda a simulação.
• A grade etária: uma faixa de idade que corta os grupos de 10 anos sai numa grade própria, por município, faixa de 5 anos e sexo, nas UFs em que ela está aberta; fora delas, o pedido é recusado com age_grid_not_open. GET /releases e list_releases dizem quais UFs estão abertas (grade_etaria).
• E-mail quando o job termina, para quem enviou pelo app. Desliga no Perfil.
• Perfil: nome, senha e e-mail, que muda só depois de confirmado.
• Status: a página de status no app mostra a API, a execução de jobs e a compra de créditos.

8 de outubro de 2026

• Compra de créditos no app, por Pix ou boleto, a partir de R$ 20,00, com a nota fiscal de serviço em nome de quem paga.
• Tudo em reais. Um crédito passa a ser um real: preço, saldo, limites de gasto, alerta de saldo e extrato. Os campos da API não mudam de nome (preco_micros e os demais *_micros), só a unidade: milionésimos de real. A tabela é R$ 0,00172 por milhão de pessoa-dias e R$ 3,95 por job, com mínimo de R$ 5,50, fixa e revista a cada trimestre.
• Saldos convertidos uma vez, na virada, pela PTAX de venda de 08/10/2026 (R$ 5,0119 por dólar, Banco Central). O extrato e os jobs antigos aparecem em reais pela mesma cotação.
• Release v1.2.0 disponível: as mesmas pessoas da v1.0.0, com a camada de trabalho do grafo refeita, e a release em que a validação foi medida. Os exemplos desta documentação passam a usá-la.
• O rótulo calibracao segue a release: a adoção sai calibrado só na release em que o ajuste foi testado (hoje, a v1.2.0).
• Município e área conferidos na cotação: um código fora da malha da release é recusado antes de reservar (municipality_not_in_release, ap_not_in_release).
• Achados na página do job: saturação, efeito dos canais, primeiras exposições e alcance potencial, sem baixar o resultado.
• O que medimos: o método, a tabela das 27 UFs e as seis reprovações declaradas do teste fora da amostra.
• Metodologia: como a população, o grafo social e o motor são construídos.
• Webhooks: um aviso assinado quando um job termina, em vez de consultar o estado.
• Achados sem baixar o resultado: GET /v1/jobs/{id}/findings e get_findings no MCP (O resultado).
• Idade conferida na cotação: uma faixa que corta a grade de publicação é recusada antes de reservar (target_finer_than_grid).
• Apagar os dados de um job: POST /v1/jobs/{id}/erase e erase_job_data no MCP.
• Chaves com validade de 7, 30, 90 ou 365 dias, e troca com prazo para a chave antiga parar (na hora, em 1 dia ou em 7 dias).
• Limite de gasto mensal e alerta de saldo por organização, e o uso por dia e por projeto.
• Membros e convites por e-mail, com papéis, no app.
• O cenário diz o que a recepção compara (canais, calendário, intensidade e público) e o que ainda não compara (o texto da mensagem).
• Os totais erram para baixo onde há células retidas: o resultado explica por quê.

7 de outubro de 2026

• Documentação pública em docs.brasilsintetico.com, com llms.txt e a referência OpenAPI.
• O schema do cenário é público em GET /v1/schemas/cenario-campanha e tipa o pedido na API e nas ferramentas do MCP.
• Resultado pela API e pelo MCP: GET /v1/jobs/{id}/result e get_result devolvem um link de 15 minutos com o sha256.
• Limite de chamadas: 1.000 por hora por chave ou agente e 5.000 por organização, com 429 query_budget_exceeded e Retry-After.
• Servidor MCP em https://mcp.brasilsintetico.com/mcp, com login OAuth para Claude, ChatGPT, Cursor e VS Code, e chave de projeto para agentes sem navegador.
• API v1: cotação, envio idempotente, consulta e cancelamento de jobs sobre a release v1.0.0, com as 27 UFs.