Calculation Accuracy

Last updated Nov 7, 2026 View as Markdown Agent setup

TL;DR

The reference for AstroWay positions is NASA JPL Horizons, the ephemeris service of NASA’s Jet Propulsion Laboratory. Every calculation runs on our own servers, with no upstream API between your request and the answer. Every core calculation endpoint is also covered by our own regression snapshot tests, and the numbers are cross-checked against independent references, plus the NASA 5-Millennium Eclipse Catalog:

Against NASA JPL Horizons, with somebody else’s benchmark (RoxyAPI’s): 231 of 231 within tolerance, median 0.052", maximum 1.1" (Chiron in 1900; 0.47" for the Sun, Moon and planets)
Regression suite: 888 frozen snapshots on every pull request; one regression blocks the release
Planet positions against the swetest reference output from Astrodienst: median 0.0013", maximum 0.561" (measured 2026-07-29 over 130 samples). Per-body breakdown below
Placidus house cusps: 0.000" exact match
Eclipses: < 1 minute vs NASA 5-Millennium Eclipse Catalog
ACG lines: < 1.5 km at the equator vs swetest
Sunrise/sunset: < 10 seconds vs timeanddate.com
Moon VOC, ingresses, planet conjunctions: sub-second precision

Checked against NASA JPL Horizons, with somebody else’s tool

RoxyAPI publish their own benchmark against NASA JPL Horizons DE441: MIT licence, standard library only, 17 domains and 2,701 values since 2026-11-01, of which the western-planets folder holds 21 charts and 231 positions, and a --base-url flag that points it at any other API. Their README says outright that the tolerance bands are deliberately not sized to their own engine, because a benchmark inviting you to test a competitor has to be honest.

We pointed it at ourselves with no number in their code changed. The adapter renames one request field and drops one response envelope.

	AstroWay, 2026-10-19	RoxyAPI, their run of 2026-11-01
Within tolerance	231 of 231	231 of 231
Median deviation	`0.052"`	`0.048"`
Maximum	`1.1"`	`0.32"`

Our run is on the current version of their harness, which added Chiron and two daylight-saving cases and reads the Horizons values to seven decimals; it cost 21 API calls. The medians are 0.004” apart. Our largest deviation is Chiron in 1900, where our asteroid ephemeris and the Horizons small-body integration differ by 1.1”; for the Sun, Moon and planets our maximum is 0.47”. Row by row, all 231: CSV. The 2026-09-09 run on the older version of the harness: CSV.

Against the swetest reference output: how this was measured

These are measured numbers, not estimates. The script takes 10 charts spread from 1900 to 2050, asks the live swetest CGI at Astrodienst for the same instants, and compares all 13 bodies we return. 130 samples in total.

Body	Maximum drift
Sun, Venus, Saturn	`0.001"`
Mercury	`0.002"`
true Node	`0.004"`
Mars	`0.007"`
Jupiter	`0.009"`
Moon	`0.022"`
Uranus	`0.083"`
Pluto	`0.097"`
Neptune	`0.223"`
Chiron	`0.561"`
mean Apogee (Lilith)	`0.000"`

Median across all 130 samples: 0.0013".

This page previously carried a blanket ”< 0.1 arcsec” promise. The 2026-07-29 measurement showed Neptune, Pluto and Chiron do not hold it, so the promise was replaced with the measured figures. Chiron and the outer planets drift further because their positions come from the compressed ephemeris set our build uses.

You can reproduce this: api-calc/scripts/accuracy-vs-swetest.mjs makes exactly these requests and prints the same table.

Check it yourself. The script behind the numbers above is a public MIT repository: astroway/astrology-accuracy-benchmark. It is not ours-only: an adapter for any other API is about thirty lines, so you can run the same 130 samples against a competitor and compare. A sandbox key is enough.

Cross-checks against other references

Besides JPL Horizons and our own snapshots, the numbers are compared with three other public references:

1. swetest CGI

The reference output Astrodienst publishes, the team behind Astro.com. Drift from it is 0.00-0.07 arcsec on the reference charts.

2. Kerykeion (Python)

An independent open-source Python library, run on the same charts.

3. Prokerala API

A remote astrology API (sidereal Lahiri). Systemic drift of 8-17 arcsec comes from different versions of the Lahiri ayanamsa formula, not from position accuracy.

Cross-check results

Chart	vs swetest (Astrodienst)	vs Kerykeion (Python)	vs Prokerala API
Monroe 1926	0.00”	0.19”	16.95” (systemic)
Diana 1961	0.00”	0.69”	8.18” (systemic)
Einstein 1879	0.07”	Kerykeion LMT artifact	14.96” (systemic)

Endpoint-level regression suite

Each of the core calculation endpoints is covered by frozen snapshot tests on 3 reference charts (Monroe / Diana / Einstein) = 888 snapshots.

The snapshot suite catches:

Input-mapping bugs: wrong planet id, UT, house system
Post-processing: rounding, unit conversion, sign loss
Defaults divergence: mean vs true node, geocentric vs topocentric
Schema drift: validation let through a wrong shape
Stale deploy: prod dist out of sync with code

Default tolerance: 5e-5° (≈0.18 arcsec) for all numeric fields.

Detailed benchmarks

Planet positions (tropical, vs swetest)

Chart	Date	Max drift
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

House cusps Placidus (vs swetest)

Chart	ASC drift	MC drift	Max cusp drift
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Eclipses (vs NASA 5-Millennium Catalog)

Event	NASA max	Ours max	Drift
2025-03-14 Lunar Total	06:58 UT	06:58 UT	0.8 min
2025-03-29 Solar Partial	10:47 UT	10:47 UT	0.5 min
2025-09-07 Lunar Total	18:11 UT	18:11 UT	0.8 min
2025-09-21 Solar Partial	19:41 UT	19:42 UT	1.0 min

Astrocartography (vs swetest RA formula)

MC and IC lines are built from the longitude = RA - GMST formula (Kenneth Bowser standard). Drift from authoritative: < 1.5 km at the equator for all planets.

The ASC and DSC horizon lines are solved from the horizon equation in the same equatorial coordinates: cos H = -tan φ · tan δ, where H = (GMST + lng) - RA. The two halves differ by the sign of the hour angle: at H < 0 the body is east of the meridian and therefore rising. The check we run on every pass takes every point of every horizon curve and computes the body’s altitude there. Across 8419 points the largest deviation is 0.0 km, so the body really is on the horizon everywhere we drew the line.

Until 2026-08-12 the horizon curves solved a different equation (“this ecliptic longitude is on the ascendant”) and the two halves were separated by an inverted test, so ASC was drawn where the body sets. MC and IC were never affected.

The second and less visible half of the same bug: the old equation ignored the body’s ecliptic latitude, so the line drifted in proportion to it, roughly 103 km per degree. On Marilyn Monroe’s chart that is 0 km for the Sun and the nodes, 22 km for Mercury, 161 for Pluto, 285 for the Moon and 345 for Lilith. On charts where a body sits high above the ecliptic the error exceeded 1500 km.

What this means for your code. If you were working around the earlier bug by swapping ASC and DSC on your side, remove that workaround. If you read the knownDefect field, it is no longer in the responses. Horizon-line coordinates changed for bodies with appreciable ecliptic latitude, so cached maps are worth rebuilding.

Sunrise/Sunset (vs timeanddate.com)

Location	Date	Parameter	Drift
London	2026-04-15	Sunrise	0.6 sec
London	2026-04-15	Sunset	9 sec

Polar locations (|lat| > 66.5°) automatically return polarState + a warning that regular planetary hours are undefined.

Aspect orbs

AstroWay uses variable per-planet orbs (MIN-of-two-planets rule), as in ZET9 and astro.com. Default orbs (natal chart):

Aspect	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°

Minor aspects (36°, 40°, 45°, 72°, 108°, 135°, 144°) are off by default. Enable explicitly via ALL_ASPECTS.

Polar latitudes

For |lat| > 66.5° the Placidus/Koch/Regiomontanus systems are mathematically undefined. In that case the cusps are computed as Porphyry, and the response says so in a warning field next to "system": "P", naming the substituted system and the latitude.

Continuous verification

Regression is checked on every PR through CI:

api-calc/tests/endpoints/: 888 snapshots against reference charts (Monroe / Diana / Einstein) + synastry / composite / davison
.github/workflows/api-accuracy.yml: auto-run on PR
Cross-check against swetest CGI + Kerykeion: weekly

Known limitations

Extreme dates (before 1800 and after 2399): an analytical ephemeris is used, precision ~0.1” (vs < 0.01” inside 1800-2399)
True Lilith (id=13) vs Mean Lilith (id=12): up to 12° difference: the default is Mean Lilith (stable behavior), True Lilith is available via planetIds: [13]
Topocentric vs geocentric: geocentric by default