Precisão dos cálculos

TL;DR

AstroWay API utiliza Swiss Ephemeris (código C oficial da Astrodienst, criadores do astro.com) - o mesmo motor usado por astrólogos profissionais há mais de 30 anos em Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mês) e Janus. Executamos ele em nossos servidores e oferecemos uma camada de API REST, sem acréscimo de intermediários. Cada um dos endpoints de cálculo básicos é coberto por testes de snapshot de regressão; a precisão do motor é verificada por triangulação com três fontes independentes + contra o NASA 5-Millennium Eclipse Catalog:

Posições planetárias: mediana 0.0013", máximo 0.561" vs swetest CGI oficial da Astrodienst (medido em 2026-07-29 em 130 medições). Divisão por corpos abaixo
Teste independente com benchmark externo (RoxyAPI, contra NASA JPL Horizons DE441): 210 de 210 dentro da tolerância, mediana 0.11", máximo 0.60"
Cuspides das casas Placidus: 0.000" exato
Eclipses: < 1 minuto vs NASA Eclipse Catalog
Linhas ACG: < 1.5 km no equador vs swetest
Nascer/pôr do sol: < 10 segundos vs timeanddate.com
VOC da Lua, ingressos, conjunções planetárias: precisão de fração de segundo

Metodologia: como foi medido

Estes números não são uma estimativa, mas o resultado de uma execução. O script pega 10 cartas, distribuídas entre 1900 e 2050, solicita os mesmos momentos no swetest CGI ao vivo da Astrodienst e compara todos os 13 corpos que fornecemos. No total, 130 medições.

Corpo	Desvio máximo
Sol, Vênus, Saturno	`0.001"`
Mercúrio	`0.002"`
Nó Verdadeiro	`0.004"`
Marte	`0.007"`
Júpiter	`0.009"`
Lua	`0.022"`
Urano	`0.083"`
Plutão	`0.097"`
Netuno	`0.223"`
Quíron	`0.561"`
Apogee médio (Lilith)	`0.000"`

Mediana de todas as 130 medições: 0.0013".

Anteriormente nesta página havia uma promessa geral de ”< 0,1 arcsec”. As medições de 2026-07-29 mostraram que Netuno, Plutão e Quíron não a mantêm, portanto a promessa foi substituída pelos números reais. Quíron e os planetas externos têm maior desvio porque suas posições são retiradas de um conjunto comprimido de efemérides usado pela nossa compilação.

Pode reproduzir isso por conta própria: api-calc/scripts/accuracy-vs-swetest.mjs faz exatamente essas solicitações e imprime a mesma tabela.

Verifique por conta própria. O script usado para medir os números acima está no repositório público sob licença MIT: astroway/astrology-accuracy-benchmark. Funciona não apenas conosco: um adaptador para qualquer outra API são trinta linhas, então as mesmas 130 medições podem ser executadas contra um concorrente e comparadas. A chave da sandbox é suficiente.

Motor

Componente	Valor
Biblioteca	Swiss Ephemeris C code (aloistr/swisseph)
Versão	upstream Astrodienst C code
Ephemeris	DE431 JPL ephemeris (via .se1 files)
Fallback	Moshier analytical (para datas fora de 1800-2399)
Compartilhamento de código	Shared `@/core` de app.astroway.info - um motor, dois transportes

Metodologia

A precisão é verificada por triangulação - comparação com três fontes independentes:

1. swetest CGI (referência)

A implementação de referência oficial do Swiss Ephemeris da Astrodienst - as equipes que criaram Astro.com e atendem milhões de astrólogos em todo o mundo. A fonte pública mais autoritativa. Nosso motor é idêntico (0,00–0,07 segundos de arco de desvio).

2. Kerykeion (Python)

Biblioteca Python independente usa bindings pyswisseph, independentes da nossa compilação. Confirma que nossa camada de wrapper não distorce os dados.

3. Prokerala API

API remoto do Swiss Ephemeris (sidereal Lahiri). Desvio sistêmico de 8–17 segundos de arco está relacionado com diferentes versões da fórmula de ayanamsa Lahiri, e não com a precisão do motor.

Resultados da triangulação

Carta	contra swetest (Astrodienst)	contra Kerykeion (Python)	contra Prokerala API
Monroe 1926	0.00”	0.19”	16.95” (sistêmico)
Diana 1961	0.00”	0.69”	8.18” (sistêmico)
Einstein 1879	0.07”	artefato LMT Kerykeion	14.96” (sistêmico)

Verificação independente com outra ferramenta

RoxyAPI publica seu próprio benchmark contra NASA JPL Horizons DE441: licença MIT, apenas biblioteca padrão, 21 cartas e 210 posições, e a bandeira --base-url, para direcioná-lo para qualquer outra API. Em seu README fica claramente dito que os limites foram intencionalmente não ajustados ao seu próprio motor, pois o benchmark que oferece para verificar um concorrente deve ser justo.

Nós o direcionamos para nós mesmos, sem alterar nenhum número em seu código. O adaptador renomeia um campo de solicitação e remove uma camada de resposta.

	AstroWay	RoxyAPI, seu benchmark 2026-09-29
Dentro da tolerância	210 z 210	210 z 210
Mediana do desvio	`0.11"`	`0.05"`
Máximo	`0.60"`	`0.78"`

Nossa medição de 2026-09-09, custou 21 requisições à API. RoxyAPI, em setembro, mudou para leitura direta do DE440, e sua mediana agora é menor que a nossa; nosso máximo é menor que o deles. A saída ordenada de todas as 210 linhas: CSV.

Conjunto de regressão no nível dos endpoints

Cada um dos endpoints de cálculo básicos é coberto por testes de snapshot congelados em 3 cartas de referência (Monroe / Diana / Einstein) = 873 snapshots.

O conjunto de snapshots captura:

Erros de mapeamento de dados de entrada: ID incorreto do planeta, UT, sistema de casas
Pós-processamento: arredondamento, conversão de unidades, perda de sinal
Desvio de padrões: nó médio vs nó verdadeiro, geocêntrico vs topocêntrico
Desvio de esquema: validação perdeu forma incorreta
Implantação obsoleta: dist de prod não corresponde ao código

Tolerância: 5e-5° (≈0,18 segundos de arco) por padrão para todos os campos numéricos.

Benchmarks detalhados

Posições dos planetas (trópico, contra swetest)

Carta	Data	Desvio máximo
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

Cuspides das casas Placidus (contra swetest)

Carta	desvio ASC	desvio MC	Desvio máximo da cuspide
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Eclipse (contra NASA 5-Millennium Catalog)

Evento	Máximo NASA	Nosso máximo	Desvio
2025-03-14 Total Lunar	06:58 UT	06:58 UT	0.8 min
2025-03-29 Parcial Solar	10:47 UT	10:47 UT	0.5 min
2025-09-07 Total Lunar	18:11 UT	18:11 UT	0.8 min
2025-09-21 Parcial Solar	19:41 UT	19:42 UT	1.0 min

Astrocartografia (contra fórmulas RA do swetest)

Antes de 2026-08-12, as curvas horizontais resolviam uma equação diferente (“a longitude eclíptica no ascendente”), e as duas metades diferiam por um teste invertido, portanto o ASC estava onde o corpo se põe. MC e IC nunca foram afetados.

A outra metade, menos perceptível, desse mesmo erro: a equação antiga ignorava a latitude eclíptica do corpo, portanto a linha se desviava proporcionalmente a ela, aproximadamente 103 km por grau de latitude. No mapa de Marilyn Monroe, isso resulta em 0 km para o Sol e os nós, 22 km para Mercúrio, 161 para Plutão, 285 para a Lua, 345 para Lilith. Em mapas onde o corpo está alto acima da eclíptica, o desvio chegava a mais de 1500 km.

O que isso significa para o seu código. Se você contornou o erro anterior, trocando ASC e DSC nos seus próprios códigos, remova esse contorno. Se você leu o campo knownDefect, ele não existe mais nas respostas. As coordenadas das linhas horizontais para corpos com eclíptica latitude significativa mudaram, portanto os mapas em cache devem ser reconstruídos.

Nascer / Pôr do Sol (contra timeanddate.com)

Localização	Data	Parâmetro	Desvio
London	2026-04-15	Sunrise	0.6 s
London	2026-04-15	Sunset	9 s

Localizações polares (|lat| > 66,5°) retornam automaticamente polarState + aviso de que as horas planetárias usuais não estão definidas.

Orbes dos aspectos

AstroWay usa orbes variáveis por planeta (regra MÍNIMO de dois planetas), como no ZET9 e astro.com. Orbes padrão (para carta natal):

Aspecto	Sun	Moon	Inner	Jupiter	Outer
Conjunction	12°	10°	5°	8°	5°
Sextile	6.5°	6°	5°	5°	5°
Square	10°	8°	5°	7°	5°
Trine	12°	8°	5°	5°	5°
Opposition	12°	10°	5°	8°	5°

Aspectos menores (36°, 40°, 45°, 72°, 108°, 135°, 144°) estão desativados por padrão. Eles são ativados explicitamente através de ALL_ASPECTS.

Latitudes polares

Para |lat| > 66,5°, os sistemas Placidus / Koch / Regiomontanus não são matematicamente definidos. Nesses casos, o Swiss Ephemeris retorna automaticamente Porphyry, e nosso API adiciona um aviso:

{
  "system": "P",
  "warning": "Placidus system is undefined for lat=68.96° (> 66.5°). Swiss Ephemeris fell back to Porphyry..."
}

Verificação contínua

A regressão é verificada em cada PR via CI:

api-calc/tests/endpoints/: 873 snapshots contra as cartas de referência (Monroe / Diana / Einstein) + sinastria / composto / davison
.github/workflows/api-accuracy.yml: disparo automático em PR
Triangulação contra swetest CGI + Kerykeion: semanal
Monitoramento do upstream Swiss Ephemeris via Dependabot

Confiabilidade do MCP: saída tipificada

A precisão do motor é metade da confiança. A outra metade é o contrato de saída, que um agente (Claude, ChatGPT, Cursor) pode validar. Nosso servidor MCP não retorna “texto bruto, descubra por conta própria”:

structuredContent tipificado. Mais de 600 ferramentas MCP, e a grande maioria delas publica um outputSchema rigoroso - o cliente MCP recebe uma estrutura validada, e não uma string que precisa ser adivinhada.
Proteção contra deriva de esquema. O teste CI openapi-example-drift valida cada regression-snapshot contra o esquema gerado a partir do seu próprio exemplo: se a saída real do endpoint divergir do esquema publicado, a build falha. Essa classe de divergências causa o erro MCP -32602 Output validation error.
Erros: são erros. A falha de uma ferramenta sempre retorna com a bandeira isError e um código tipificado (UPPER_SNAKE). Nós nunca enviamos ao modelo o stack trace bruto ou caminhos internos do servidor como “dados”.

Ou seja, a integração via MCP é tão previsível quanto uma chamada REST direta: o que está descrito em /openapi.json é o que o instrumento retorna.

Limitações conhecidas

Datas fora do intervalo (antes de 1800 e depois de 2399): é usado o analítico Moshier, precisão ~0,1” (contra < 0,01” para SWIEPH com arquivos DE431)
True Lilith (id=13) vs Mean Lilith (id=12): diferença até 12° - por padrão Mean Lilith (comportamento estável), True Lilith disponível através de planetIds: [13]
Topocêntrico vs geocêntrico: por padrão geocêntrico