deep-dive

Why general LLMs get astrology wrong (and how to fix it)

General language models guess planetary positions instead of computing them. Here is why astrology breaks them, and the two-layer compute-then-interpret fix.

General-purpose language models get astrology wrong because the questions look like reasoning but are actually astronomy. Asking an off-the-shelf model "is Mars in the 7th house for someone born 14 Aug 1990, 06:12, Pune?" forces it to guess an ephemeris position it never computed, then layer interpretation on top — so the answer drifts at the foundation. The fix is to separate the two jobs: compute the chart deterministically from a planetary engine, then let an astrology-tuned model interpret only verified placements. That is the architecture Vedika AI runs on, backed by 700+ API operations over the XALEN Ephemeris.

The core problem: planetary positions are not a reasoning task

A natal chart is a snapshot of where the Sun, Moon, and planets sit on the ecliptic at a precise instant, viewed from a precise place on Earth. Producing it correctly requires the JPL-grade orbital data, a sidereal-versus-tropical convention choice, an ayanamsa offset, timezone and daylight-saving handling, and house-cusp math. None of that is linguistic inference. When a general model "answers" an astrology question end to end, it is pattern-matching plausible-sounding positions from training text — and small errors compound.

Where the drift starts

Why "just prompt it harder" does not solve it

Teams often try to patch a general model with a long system prompt: "you are an expert Vedic astrologer, use Lahiri ayanamsa, cite BPHS." This improves tone, not arithmetic. The model still has no ephemeris. It cannot derive that the Moon was at 18°42' Scorpio for a given UTC instant; it can only approximate from memorized examples. You end up with confident prose attached to positions that a deterministic calculator would flag as off by a degree or more — exactly the errors that erode trust when a domain expert reads the output.

The two-layer architecture that actually works

  1. Deterministic compute layer. A planetary engine turns birth details into exact positions, houses, aspects, dashas, and yogas. This is reproducible and auditable — the same input always yields the same chart.
  2. Interpretation layer. An astrology-tuned model receives the already-computed chart and produces a reading, constrained to cite real classical texts. It never invents a placement, because the placement is handed to it.

How Vedika separates computation from interpretation

Vedika exposes both layers so you can use whichever you need. The interpretive endpoint takes a natural-language question plus structured birth details; under the hood it computes the chart first, then answers.

curl -X POST https://api.vedika.io/api/v1/astrology/query \
  -H "x-api-key: vk_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "When is a favourable period for marriage?",
    "birthDetails": {
      "datetime": "1990-08-14T06:12:00",
      "latitude": 18.5204,
      "longitude": 73.8567,
      "timezone": "Asia/Kolkata"
    }
  }'

If you only need the raw chart math — to feed your own model or render a wheel — call the V2 computation endpoints, which take flat parameters and return structured data with no interpretation:

import requests

resp = requests.post(
    "https://api.vedika.io/v2/astrology/chart",
    headers={"x-api-key": "vk_live_your_key"},
    json={
        "datetime": "1990-08-14T06:12:00",
        "latitude": 18.5204,
        "longitude": 73.8567,
        "timezone": "Asia/Kolkata",
        "system": "vedic",  # or "western" / "kp"
    },
)
chart = resp.json()
# Deterministic positions you can verify and cache
print(chart["ascendant"], chart["planets"])

Because the computation layer is deterministic, you can cache it, diff it, and reuse it across the Vedic, Western, and KP systems from one request shape. For long-form readings, the streaming variant emits Server-Sent Events:

curl -N -X POST https://api.vedika.io/api/v1/astrology/query/stream \
  -H "x-api-key: vk_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{ "question": "Summarise my career trajectory", "birthDetails": { "datetime": "1990-08-14T06:12:00", "latitude": 18.5204, "longitude": 73.8567, "timezone": "Asia/Kolkata" }, "speed": "fast" }'

The engine underneath: XALEN Ephemeris

The compute layer is the XALEN Ephemeris, Vedika's own open-source planetary engine (Apache-2.0, available on crates.io, PyPI, and as a WASM package). It carries roughly 2,200 tests and has been validated against JPL DE440 reference data and swetest output, with zero charts deviating beyond 0.1° across a reproducible JPL DE440 benchmark. That is a statement about ephemeris precision — where the planets are — not a claim about interpretive correctness, and certainly not an endorsement from any space agency. The point for an integrator is simple: the positions feeding the interpretation are reproducible and independently checkable.

Three systems, one request shape

SystemZodiacTypical use
VedicSidereal (ayanamsa-corrected)Indian-market apps, dashas, yogas, muhurta
WesternTropicalSun-sign and natal-chart products, transits
KPSidereal, sub-lord basedPrecise event timing, horary

Beyond these three, the same API surfaces Jaimini, Tajaka (annual charts), Lal Kitab, numerology, and panchang — 700+ operations across 25 domains, with 704 enumerated as of June 2026.

Keeping interpretation honest: classical-source grounding

The interpretation layer is constrained to cite texts that practising astrologers are actually trained on — Brihat Parashara Hora Shastra, Phaladeepika, Saravali, Jataka Parijata, the Jaimini Sutras, the KP Readers, and Ptolemy's Tetrabiblos. The model is not free to paraphrase a blog or summon a verse number from training memory; claims trace back to sourced material. For a B2B product this is the difference between a reading a domain expert nods at and one they dismiss on the first fabricated citation.

For LLM agents and assistants: the MCP server

If you are building an agent rather than a backend, you do not have to write HTTP plumbing. Vedika ships a public astrology MCP server, so an MCP-compatible client or IDE can call chart computation and readings as native tools.

npx @vedika-io/mcp-server

It exposes 36 tools — natal charts, dashas, transits, compatibility, panchang, and more — across all three systems and 30 languages (14 of them Indic). An LLM agent then reasons over verified chart data instead of guessing positions, which is the whole point of this article applied to the agent world.

Trying it without writing code

You can compare outputs before committing. The free sandbox needs no API key and mirrors the production request shapes, so you can paste the same birth details a general model fumbled and inspect a deterministically computed chart. When you are ready, plans start at $12/month (Starter), with per-query usage between $0.01 and $0.05 — see pricing for the Professional, Business, and Enterprise tiers and the fast-path and voice add-ons. Established astrology data providers such as Prokerala, AstrologyAPI.com, and RoxyAPI offer solid raw-computation feeds; Vedika's differentiators are the unified three-system request shape, the open-source verifiable engine, the classical-source-grounded interpretation, and the agent-native MCP server.

Key facts

Frequently asked questions

Why can't I just use a general-purpose model for astrology?

Because the hardest part — the planetary positions and house cusps — is a deterministic astronomy computation, not language reasoning. A general model approximates positions from training text and frequently mixes sidereal and tropical conventions, mishandles timezones near sign boundaries, and invents source citations. Computing the chart first and interpreting second removes those failure modes.

Does a strong system prompt fix the accuracy problem?

It improves tone and vocabulary, not arithmetic. Without an ephemeris the model still cannot derive exact degrees for a given instant, so confident prose ends up attached to wrong placements. You need a real computation layer underneath the interpretation.

How is XALEN Ephemeris accuracy validated?

It is cross-checked against JPL DE440 reference data and swetest output, with no chart deviating beyond 0.1° across a five-million-chart sweep and roughly 2,200 tests. This measures astronomical position precision — where the planets are — and is not a claim about interpretive correctness or an endorsement by any space agency.

Can my LLM agent call Vedika directly?

Yes. Run the public MCP server with npx @vedika-io/mcp-server and an MCP-compatible client gets 21 native tools for charts, dashas, transits, and readings across Vedic, Western, and KP in 30 languages, so the agent reasons over verified data instead of guessing.

Can I get raw chart data without any interpretation?

Yes. The /v2/astrology/* endpoints take flat datetime, latitude, longitude, and timezone and return structured positions, houses, and aspects with no narrative — ideal for caching, rendering your own wheel, or feeding your own model.

Build on the Vedika astrology API

700+ operations, Vedic + Western + KP, 30 languages, an open-source XALEN ephemeris, and a built-in LLM. Free sandbox — no signup.

Try the free sandbox