The Digital Jyotiṣa Landscape

What astrology software calculates, what it conceals, and what happened when the same inputs were tested under different conventions

By Vamsikrishna Sankarayogi · 2026-08-05

Survey date: 5 August 2026

Disclosure: This article is published on the website of an early-stage astrology software initiative with which the author is involved. The initiative has no publicly available product and is not included, compared or recommended anywhere in this survey.

Corrections: Vendors and readers are invited to submit documented factual corrections. Corrections will be recorded with the date and nature of the change. Editorial conclusions will not be altered merely because a vendor disagrees with the assessment.

The phrase astrology software covers several products that have very little in common. A location-sensitive pañcāṅga, a Windows program used by a professional jyotiṣin, a downloadable report, a consultation marketplace, an astronomical library and an AI chatbot may all appear in the same search results. They should not be assessed by the same standard.

This survey separates the digital Jyotiṣa market into its functional layers and examines a representative set of public websites, practitioner workstations, mobile applications, marketplaces, APIs and open-source projects. The desk review was supplemented by four controlled calculation exercises. I compared published pañcāṅga boundaries with an independent Swiss Ephemeris calculation; held one instant constant while changing ayanāṃśa; compared true and mean lunar nodes at a sign boundary; and tested how a disputed wartime time-zone entry changes a synthetic Kolkata chart. The scripts and raw CSV outputs accompany the publication.

The tests changed my emphasis. I expected the public pañcāṅga sites to disagree more than they did. On the main tithi and nakṣatra boundaries they converged to the displayed minute. The larger discrepancies appeared when a setting was changed without changing the birth data. At 9:18 p.m. IST on 5 August 2026, the Moon remained in Aśvinī under Lahiri and Fagan–Bradley, but fell in Bharaṇī under Raman, Krishnamurti and Yukteswar. In a separate case, true and mean Rāhu occupied different rāśis. A one-hour historical-time conversion changed a synthetic chart’s Lahiri ascendant from Taurus to Gemini.

These are not demonstrations of astrological validity. They establish something narrower and immediately useful: a digital Jyotiṣa result is inseparable from its calculation conventions, time data, version and interpretive chain. The astronomical layer of the market is generally mature. Interpretive provenance, reproducibility, privacy, AI accountability and commercial governance remain much less consistent.

1. The comparison problem begins before the products are opened

Search for the “best astrology app” and the resulting lists often place Drik Panchang beside AstroTalk, Jagannatha Hora beside AstroSage, and Swiss Ephemeris beside a report generator. This is the equivalent of comparing a calendar, a laboratory instrument, a publishing service and a professional directory because all four happen to concern time.

The category mistake matters because it transfers trust from one layer to another. A product may calculate the Moon’s longitude correctly and still generate a careless interpretation. A marketplace may make an experienced astrologer easy to reach while contributing almost nothing to the astrologer’s method. A polished 200-page report may be assembled from fixed fragments whose rule hierarchy is invisible. An open-source project may expose every line of code but still contain an untested formula.

I found it more useful to separate six layers:

Astronomical and geospatial data — ephemerides, coordinates, time zones, daylight-saving history, local horizon and rise/set calculations.
Jyotiṣa computation — ayanāṃśa, lagna, tithi, nakṣatra, yoga, karaṇa, rāśi, bhāva, varga, bala, daśā and transit procedures.
Interpretive rules — propositions drawn from a school, text, teacher or modern synthesis.
Narrative production — fixed report fragments, rule-assembled prose, human writing or language-model output.
Consultation — questioning, judgment, contradiction management, ethical restraint and adaptation to the person.
Commercial delivery — subscriptions, report sales, wallet credits, per-minute sessions, remedies, developer quotas and advertising.

A specialized product can be excellent without covering all six. Swiss Ephemeris is valuable precisely because it does not pretend to be an astrologer. Drik Panchang is strongest when read as a calendrical reference. AstroTalk is primarily an access and transaction layer. Jagannatha Hora is a configurable calculation environment whose usefulness rises or falls with the operator’s knowledge.

For this reason, the article does not award an overall winner. A composite score would favour feature accumulation and obscure the fact that different users are buying different things.

2. “Accuracy” needs an object

During the review I repeatedly encountered the word accurate without a clear statement of what had been measured. In digital Jyotiṣa, at least four different claims are often compressed into that one word.

Astronomical accuracy

This concerns the conversion of a recorded date, time and place into celestial and local quantities. It includes the treatment of UTC, historical time zones, latitude and longitude, precession, nutation, local sidereal time, sunrise and the local horizon. Planetary longitudes and boundary crossings can be compared with a documented ephemeris under fixed settings. Swiss Ephemeris is widely used for this layer and publishes programmer documentation, test utilities and its licensing model.[1]

Conventional consistency

Jyotiṣa contains multiple operational conventions. Two competent programs can disagree because one uses Lahiri and another Raman ayanāṃśa; one uses mean nodes and another true nodes; one begins the day at upper-limb sunrise and another uses a different definition; one treats houses as whole signs and another computes cusps; one uses a civil year for daśā conversion and another a 360-day convention.

Such a difference is not automatically a defect. The defect may be that the convention was hidden, changed silently after an update or omitted from the saved report. A result that cannot be reconstructed is weak evidence even when the original calculation was correct.

Interpretive fidelity

A statement may follow a recognizable Jyotiṣa school without possessing demonstrated predictive validity. Here the questions are textual and procedural. Which rule was selected? Were its necessary conditions present? Were exceptions checked? Did the system consider dignity, lordship, strength, aspects, varga, daśā and contradictory indications? Was the source classical, commentarial or modern?

The sentence “Saturn in the seventh causes an unhappy marriage” can be attached to a correctly calculated placement and still be poor Jyotiṣa. It ignores most of the chart and converts one factor into a verdict.

Predictive validity

This is the strongest claim: that the method predicts traits or events beyond relevant alternatives under a defined test. Testimonials, app ratings, confident prose and the number of pages in a report do not establish it. Agreement among websites is also weaker than it appears when those websites share an ephemeris, report vendor or interpretation feed.

The market often borrows authority across these levels. Numerical precision at the bottom of a chart gives a psychological prediction above it the appearance of equal precision. The evaluator has to resist that transfer.

3. How I examined the market

The product sample is purposive rather than exhaustive. I selected tools that represent distinct architectures or occupy a visible position in the Indian digital astrology ecosystem. The review drew on official product pages, calculation-setting documentation, API references, public code repositories, app-store disclosures, privacy policies and terms of service available on 5 August 2026.

I did not create concealed accounts to test paid astrologers, purchase every premium report, or run a complete regression suite through every closed desktop product. Where I could verify only a vendor claim, I say so. Where a setting or formula was not publicly visible, I do not infer it from the appearance of the output.

The controlled portion of the work had a narrower purpose. It tested whether apparently small configuration choices can materially change a displayed Jyotiṣa result. The environment was Python 3.13 with PySwisseph 20230604 and Swiss Ephemeris 2.10.03. The calculation script, source inputs and CSV outputs are included in the research appendix.[38]

Representative sample

Product or service	Primary class	Principal use examined
Drik Panchang	Calendrical reference	Location-sensitive pañcāṅga, festivals and muhūrta
Prokerala	Web utilities and API	Public charts, pañcāṅga and developer integration
Astro.com / Swiss Ephemeris	Technical benchmark and infrastructure	Ephemerides, chart options and astronomical calculation
Jagannatha Hora	Professional desktop workstation	Configurable Jyotiṣa calculation and research use
Parashara’s Light	Commercial practitioner suite	Client workflow, reports and teaching aids
LeoStar	Multilingual professional suite	Multi-system Indian astrology and practice management
Maitreya	Open-source desktop application	Local cross-platform calculation
Cosmic Insights	Advanced mobile Jyotiṣa tool	Portable charts, vargas, daśās and reference material
AstroSage	Consumer portal and AI interface	Kundli, reports, content, AI and consultation
ClickAstro	Report-oriented portal	Regional-language automated reports
AstroTalk	Consultation marketplace	Immediate paid access to practitioners
Astroyogi	Portal and consultation marketplace	Consumer content, charts and practitioner access
VedAstro	Open-source API and AI platform	Inspectable code, developer access and automation
AstrologyAPI / Vedic Rishi	Commercial API	White-label calculations, reports and AI services

Astro.com is included as a technical reference, not as an authority on Indian interpretation.

4. What happened when I fixed the data and changed one thing

This was the most useful part of the review. Product pages can reveal capabilities, but boundary cases reveal assumptions.

4.1 Two public pañcāṅgas and an independent calculation

I chose 5 August 2026 because several pañcāṅga elements changed during the civil day. Drik Panchang’s Bengaluru page showed Kṛṣṇa Saptamī ending at 8:42 p.m. and Aśvinī ending at 9:18 p.m. Prokerala’s page for Ujjain displayed the same two ending times. The sunrise values differed, as they should: 6:06 a.m. for Bengaluru and 6:03 a.m. for Ujjain.[39][40]

I then calculated the relevant angular crossings independently with Lahiri ayanāṃśa. The exact results were:

Boundary	Independent result, IST	Drik display	Prokerala display
Viṣṭi → Bava karaṇa	09:26:59.9	09:26	09:27
Śūla → Gaṇḍa nitya-yoga	17:29:02.7	17:29	17:28
Kṛṣṇa Saptamī → Aṣṭamī	20:42:50.3	20:42	20:42
Aśvinī → Bharaṇī	21:18:22.3	21:18	21:18

I had expected a broader difference. Instead, the main lunar boundaries converged to the displayed minute. The two one-minute variations are more instructive than alarming. At second-level precision, one public display aligns more closely on karaṇa and the other on yoga. A user who sees 9:26 on one page and 9:27 on another may be looking at rounding, truncation, a minor implementation difference or a slightly different underlying procedure—not necessarily a different astronomical event.

A second lesson came from the phrase “up to 9:18 p.m.” At exactly 9:18:00 under Lahiri, the Moon had not yet crossed into Bharaṇī; the crossing occurred roughly 22 seconds later. The website label is a human-readable minute display, not a claim that the boundary occurred at the first second of that minute. For ordinary observance this distinction is negligible. For software testing it is decisive.

4.2 The same instant under five ayanāṃśas

Next I held the instant fixed at 5 August 2026, 9:18 p.m. IST and changed only the ayanāṃśa. The result did not merely alter a decimal longitude. It changed the named nakṣatra.

Ayanāṃśa	Moon’s sidereal longitude at 21:18	Nakṣatra and pāda	Aśvinī → Bharaṇī transition
Lahiri	13.329762533°	Aśvinī 4	21:18:22
Raman	14.776063817°	Bharaṇī 1	18:47:29
Krishnamurti	13.426614817°	Bharaṇī 1	21:08:16
Yukteswar	14.708051829°	Bharaṇī 1	18:54:35
Fagan–Bradley	12.446554888°	Aśvinī 4	22:50:20

This is why the statement “the app gave the wrong nakṣatra” cannot be evaluated until the ayanāṃśa is known. The difference between the earliest and latest transition in this small test was slightly more than four hours. For a person born in that interval, janma-nakṣatra, pāda and the starting daśā balance may all depend on the convention.

The test also exposed a practical documentation problem. Many consumer interfaces display “Vedic” or “sidereal” without making the default prominent. VedAstro’s current developer documentation, for example, identifies Raman as its canonical default while supporting Lahiri, Krishnamurti and Yukteswar.[31] A developer who assumes Lahiri because it is common in another product can build an internally consistent application that nevertheless surprises every user who compares it with a Lahiri-based site.

4.3 True node, mean node—and a different rāśi

The lunar nodes are another setting that users often treat as cosmetic. I searched for a boundary case and used 25 May 2025, 12:00 noon IST, with Lahiri ayanāṃśa.

Node setting	Rāhu longitude	Rāśi
True node	330.711044765°	Pisces 0°42′39.76″
Mean node	329.645783760°	Aquarius 29°38′44.82″

The two values differ by a little over one degree, but because they straddle 0° Pisces, the sign changes. Any yoga, house occupancy or transit rule triggered by the sign can therefore change with the node setting.

This is not an argument for one node convention over the other. It is an argument against unnamed defaults. A report that says “Rāhu is in Pisces” should preserve whether the node was true or mean. Otherwise the sentence cannot be audited.

4.4 A historical time-zone record changed the lagna

The fourth test used a synthetic chart: 15 August 1944, 1:00 a.m. local time, Kolkata. The current IANA time-zone database represents the relevant wartime period as UTC+06:30. The same source explicitly warns that its 1941–45 India data rests on a single “dubious” source.[41] I retained that warning because historical uncertainty is part of the data, not an inconvenience to be hidden.

Using the IANA offset and Lahiri ayanāṃśa, the ascendant was Taurus 17°07′14″. If the same clock time is naively treated as modern IST, UTC+05:30, the ascendant becomes Gemini 1°40′38″.

The example was selected because it crosses a sign boundary; it is not offered as a claim about a real person. Its value is methodological. A program can calculate the ecliptic and horizon flawlessly and still produce the wrong chart if the civil-time conversion is wrong. Conversely, software may disagree because the historical time record itself is uncertain. In such a case, a serious report should preserve both the adopted source and the uncertainty rather than print one lagna as incontestable fact.

4.5 What these exercises do—and do not—show

The four tests do not rank the platforms, prove Jyotiṣa or assess long-form prediction. They establish three more modest points.

First, the public calculation layer can be quite good. Drik Panchang, Prokerala and the independent ephemeris calculation converged closely on the chosen day.

Second, settings are part of the result. Ayanāṃśa and node type can change named Jyotiṣa categories even when the input time is fixed.

Third, uncertainty needs a place in the output. Historical time data, minute-display policy and interpretive conventions should be recorded, not silently resolved by the interface.

These observations informed the product assessments that follow.

5. Calendrical and reference platforms

Drik Panchang: a working almanac rather than a simple date list

Drik Panchang is the strongest public reference in this sample for daily pañcāṅga, festival observance and location-sensitive muhūrta. Its pages do more than label the day. They show ending times, sunrise and moonrise, regional calendars, vrata and festival rules, rāhu-kāla and other operative intervals. The settings expose several distinctions that less technical services bury, including sunrise choices and regional calculation conventions.[2][3]

The controlled test increased my confidence in its core boundary calculation, but it also clarified the product’s limits. The page is built for lived calendrical use, not for laboratory reproducibility. It does not place a software build number, ephemeris version and machine-readable settings bundle beside every result. A researcher who cites an ending time should therefore archive the page, location, date, selected calendar and settings.

The interface can be daunting. Calculation, ritual instruction, regional convention and interpretive categories are presented in one dense field. Experienced users appreciate the depth; beginners may assume that every displayed rule has the same status or universal applicability. Drik Panchang is at its best when treated as a sophisticated almanac whose locality and rule context matter.

Prokerala: accessible utility with a developer-facing second life

Prokerala’s public pañcāṅga and chart tools are easier to enter than most professional software. Its developer platform is equally important: the API covers Vedic charts, KP, traditional calendars, compatibility, reports and related utilities, with demos and documentation intended for product teams.[4][5]

In the public boundary test, its tithi and nakṣatra values matched Drik Panchang to the minute. The one-minute yoga and karaṇa differences are a reminder that downstream developers should store raw values and endpoint versions rather than copy only the displayed label.

Prokerala’s principal trade-off is ownership. A team can ship a conventional astrology feature quickly, but the interpretation endpoints remain proprietary. The API response can be reproduced; the source hierarchy that generated a paragraph often cannot. This is acceptable for many consumer applications, provided the limitation is disclosed and a local regression suite guards against vendor changes.

Astro.com and Swiss Ephemeris: the invisible foundation

Astro.com provides extensive chart selection and ephemeris utilities. More consequential for software builders, Astrodienst develops Swiss Ephemeris, a documented astronomical library based on JPL data and offered under a dual licence.[6][7]

Swiss Ephemeris does not settle ayanāṃśa, daśā, varga, festival precedence or interpretation. That is precisely why it is useful as a reference layer. In the controlled tests I used it to calculate angular crossings and isolate what changed when a convention changed. A downstream application can still misuse it, select the wrong time-zone offset, implement a varga incorrectly or attach a poor prediction to a precise longitude.

The library’s role should be described accurately: it can make the astronomical substrate reproducible when the version, flags and files are preserved. It cannot confer validity on everything built above it.

6. Practitioner workstations

Jagannatha Hora: a laboratory that requires a lab notebook

Jagannatha Hora remains one of the most important free Jyotiṣa workstations. Its feature documentation covers custom ayanāṃśas, true and mean nodes, multiple sunrise definitions, bhāva methods, vargas, bala, aṣṭakavarga, Jaimini calculations and a large collection of daśās.[8][9]

What distinguishes the program is not simply quantity. It reveals how many choices are usually hidden. That makes it valuable for testing the kind of setting sensitivity demonstrated above. It also makes undocumented use hazardous. Two researchers can open the same birth data, select different defaults and leave with different charts while both believe they used “Jagannatha Hora.”

The interface reflects a long-lived specialist tool rather than a contemporary consumer application. The learning curve is steep, and some users will generate more output than they can interpret. Nevertheless, for a technically serious student it remains an unusually capable no-cost environment. I would not cite a Jagannatha Hora screenshot without also recording the program version, ayanāṃśa, node choice, bhāva scheme, sunrise definition, divisional-chart rule and daśā-year convention. The software needs a lab notebook beside it.

Parashara’s Light: practitioner workflow and polished output

Parashara’s Light takes a different approach. The commercial suite emphasizes client files, configurable worksheets, print layouts, reports, classical references, daśās, transits, muhūrta and teaching aids.[11] It is easier to imagine using it through a full consultation day than using it as a batch research engine.

The polish is a genuine strength. Practitioners need to store charts, retrieve histories, compare views and communicate results. Yet polished prose can conceal the boundary between a calculated fact and a report fragment. A scholarly user needs to know whether a sentence came from a documented rule, how contradictions were weighted and whether the report changed when a setting changed. Those details are less visible in a proprietary interpretive environment than in an inspectable code base.

This is not a reason to reject the product. It is a reason to distinguish practitioner usability from research transparency.

LeoStar: breadth adapted to Indian professional practice

LeoStar’s modules span Parāśari, Jaimini, KP, Lal Kitab, horary, varṣaphala, numerology, muhūrta, pañcāṅga and multilingual reporting.[12][13] Its design reflects the commercial realities of Indian practice: client records, regional languages, printable output and multiple traditions within one vendor ecosystem.

That breadth solves real workflow problems, especially for practitioners who work across systems. It also creates a provenance challenge. When a product supports several schools, the governing rule behind a specific conclusion should be more visible, not less. The public marketing makes broad claims about accuracy, but I did not find a public independent validation report covering the full module set.

For research use, I would require a settings export and a reference-chart suite before treating outputs as stable evidence. For client practice, the product’s language and workflow support may be more important than source-level inspectability.

Maitreya: openness without the marketing halo

Maitreya is GPL-licensed, cross-platform and capable of local calculation for Vedic and non-Vedic astrology.[14] It avoids mandatory cloud storage and allows technically competent users to inspect or modify the code.

Open source deserves neither automatic praise nor suspicion. It changes what can be checked. A smaller project may have less polished documentation, fewer regression tests and a thinner support community than a commercial suite. The advantage is that a disputed formula can, in principle, be traced rather than inferred from screenshots.

Maitreya is valuable for teaching, experimentation and privacy-conscious local use. It still needs the same boundary tests as a closed product. Visibility of code is the beginning of an audit, not the result of one.

7. Consumer portals and advanced mobile tools

Cosmic Insights: substantial Jyotiṣa depth on a small screen

Cosmic Insights is one of the more technically ambitious mobile products in the sample. Its current listings describe vargas, ṣaḍbala, aṣṭakavarga, avasthās, argalā, bhāva bala, Jaimini factors, several daśā systems, pañcāṅga, muhūrta and nakṣatra tools.[15] The configurable canvas is particularly useful because it lets a practitioner place selected charts and tables together rather than swipe through a fixed report.[16]

Its best use is as a portable professional or advanced-study companion. Mobile convenience does not make it a research archive. Subscription boundaries, app updates and limited batch export complicate reproducibility. The app-store privacy disclosure also states that identifiers may be used for tracking and that some purchases, contact information and device identifiers may be linked to the user.[17]

The product demonstrates that technical Jyotiṣa need not be confined to legacy desktop interfaces. The next step would be stronger per-chart export of settings, source rules and software version.

AstroSage: scale, convenience and a blurred evidentiary boundary

AstroSage combines kundli, pañcāṅga, matching, reports, educational content, consultations and AI chat in a single consumer ecosystem.[18] Its reach and low barrier to entry are significant achievements. A user can generate a chart, read an explanation and contact a practitioner without leaving the platform.

The same integration creates its central weakness. Calculation, editorial content, automated prediction, generative AI and commercial offers are densely interwoven. A reader may not know whether a paragraph was selected from a fixed rule, retrieved from an article, assembled from templates or generated by a language model. Public AI pages emphasize personalization and immediacy but do not supply the kind of model card a researcher would want: model version, source corpus, contradiction tests, fabricated-placement rate and safety evaluation.

AstroSage’s privacy policy describes collection of identity, contact and birth information, says personally identifiable information is not sold or rented, and provides an account-deletion route.[19] Those statements are useful; the user still needs a clearer boundary between chart data, conversation data and model-improvement use.

ClickAstro: report culture in digital form

ClickAstro is built around automated reports, including regional-language products, compatibility, transit material and consultations.[20] It serves users who prefer a narrative document to a screen of technical tables.

Long reports are not necessarily shallow, but length can hide repetition. The usual weakness of the format is that a user receives a polished paragraph without seeing the exact trigger, exceptions or contradictory factors. A report can therefore feel personal while being substantially templated. ClickAstro’s disclaimer appropriately limits the status of its material, but the commercial funnel still places interpretation, premium upgrades and consultation close together.[21]

The platform is useful when the customer understands what is being purchased: a structured automated reading, not a transparent reconstruction of the full judgment process.

8. Consultation marketplaces

AstroTalk and Astroyogi should not be evaluated as calculation programs. Their principal achievement is access. They allow a user in one city to reach practitioners across languages and methods within minutes.

AstroTalk’s app presents a very large range of practices, including Jyotiṣa, KP, tarot, numerology, palmistry and Vastu.[22] Its terms state that practitioners operate in their personal capacity, that the platform does not warrant the effectiveness of their advice and that it does not control professional judgment in the manner of a regulating body.[23] The privacy policy discusses retention, audio and information shared during practitioner interactions.[24]

Astroyogi similarly combines public charts and content with a practitioner marketplace. Its privacy policy states that birth details and interests may be shared with astrologers for consultation and that consultation communications may be retained for service purposes.[25][26]

These platforms solve the search problem but cannot erase heterogeneity. Ratings may reflect warmth, reassurance, availability or confirmation of what the client hoped to hear. They do not isolate textual knowledge or predictive skill. Per-minute charging can also reward duration. Remedy sales introduce an additional conflict when the consultant benefits from the recommended purchase.

A marketplace can improve this environment by verifying identity and claimed training, making total price visible, banning fear-based sales, recording informed consent, providing complaint review and separating remedy commissions from advice. It cannot make thousands of independent methods uniform.

The user should therefore assess the individual practitioner. I would ask four questions before paying: Which tradition and calculation settings are being used? How is an uncertain birth time handled? What factors would weaken the conclusion? Is the astrologer financially connected to any remedy being recommended?

9. APIs and open infrastructure

Many apparently independent astrology products are front ends to the same underlying API. The user sees a branded chart, but the calculation or report may have been returned as JSON by another company.

Prokerala’s API covers Vedic charts, KP, pañcāṅga, calendars, compatibility and generated reports.[27] It is well documented and suitable for teams that value time-to-market. The consuming company should store the endpoint version, request parameters, ayanāṃśa, time-zone input and raw response. Without that record, a vendor update can alter historical reports invisibly.

AstrologyAPI / Vedic Rishi offers an even broader commercial surface, including kundli, divisional charts, daśā, ṣaḍbala, aṣṭakavarga, KP, Lal Kitab, varṣaphala, PDFs and AI-oriented services.[28][29] Breadth reduces development time but increases the number of endpoints that must be independently tested. White-label delivery can also make the true source of the interpretation invisible to the end user.

VedAstro is the most ambitious open API-oriented project in this sample. It publishes MIT-licensed code, a REST interface, Python wrapper and MCP access.[30] Its current documentation is unusually candid about response-envelope variation and identifies Raman as the canonical default while supporting other ayanāṃśas.[31] That documentation prevented a common mistake in my own test design: assuming Lahiri because another platform used it.

The project’s openness makes source inspection and experimentation possible. It does not eliminate validation work. The Python package is a cloud API wrapper rather than a local ephemeris installation, payload shapes vary by endpoint, and hundreds of methods create a large test surface. The method index also contains highly consequential predictive endpoints, including health, longevity and death-related methods; such endpoints require much stronger safety and provenance controls than ordinary planet-position calls.[42]

A developer choosing between an API and an owned engine is choosing a governance model as much as a price. An API is convenient. An owned engine offers control. Neither is responsible unless versions, settings and tests are preserved.

10. AI astrologers: fluent explanation is not a calculation method

Large language models are useful at dialogue, explanation, summarization and adapting technical language to the reader. They are unreliable substitutes for an ephemeris. A defensible architecture keeps the stages separate:

a versioned astronomical engine calculates the chart;
a rule layer identifies applicable factors;
source passages or documented rules are retrieved;
supporting and contradictory indications are recorded;
the language model explains the synthesis;
the response preserves settings, sources and uncertainty.

Most public AI astrology pages emphasize personalization and speed. Few publish an astrology-specific evaluation: model version, corpus, rule-selection procedure, fabricated-placement rate, contradiction benchmark, medical and financial safety cases, or the frequency with which the model invents a classical citation.

The simplest audit is to ask the system to show its work. Which placements were used? Which rule was applied? What school or text supports it? What weakens the conclusion? Would another ayanāṃśa or a five-minute time shift change the answer? Was the prose generated by AI or selected from a fixed report library?

A model that cannot answer may still sound persuasive. In fact, its fluency can make the problem worse. Jyotiṣa often contains unresolved tensions. Language models tend to smooth them into one coherent story. The output feels insightful partly because the conflict has disappeared.

The boundary test offers a simple safety check. An AI asked about a person born at 9:18 p.m. on 5 August 2026 should not invent one universal nakṣatra. It should retrieve the selected ayanāṃśa, compute the exact longitude, state the boundary proximity and explain that another convention may label the moment differently.

11. Privacy and the economics of vulnerability

An astrology account may contain exact birth time and place, present location, family charts, relationship history, fertility questions, health fears, financial anxiety, voice recordings, consultation transcripts and purchase records. Even when no individual field is legally classified as medical data, the combined profile is deeply sensitive.

The reviewed policies differ. AstroSage describes collection of identity, contact and birth data, states that personally identifiable information is not sold or rented and offers deletion through support.[33] AstroTalk describes deletion and retention but also discusses recorded audio and information shared directly with practitioners.[34] Astroyogi’s policy covers birth details, practitioner sharing, wallet activity and consultation records.[35] App-store disclosures for mobile products add another layer because device identifiers and tracking can sit beside the chart profile.[36]

Users should be able to delete a single chart without deleting an entire account, export their data, see who accessed a consultation and understand whether conversations are used for model training. Product teams should minimize retention, encrypt birth records, segregate analytics from chart content and prevent practitioners from downloading personal data without a clear need.

Commercial design also shapes interpretation. Report sales reward volume. Subscription apps reward habitual return. Per-minute consultation rewards time spent. Remedy commissions can reward escalation from concern to purchase. API credits reward repeated automated calls.

None of these models is inherently unethical. The risk appears when the incentive is hidden or paired with fear. A user told that a severe doṣa requires an urgent paid remedy is not in a normal purchasing state. Responsible platforms should ban guaranteed cures, death countdowns, medical replacement claims and threats involving family harm. Pricing, commissions and refund rules should be visible before the emotionally charged part of the interaction begins.

12. Where the market is mature—and where it is not

Digital Jyotiṣa has accomplished several things well. Complex calculations are accessible in seconds. Regional calendars and languages have been preserved at scale. Practitioners can carry vargas, daśās and reference tables on a phone. Open-source alternatives exist. APIs allow small teams to build useful tools without recreating every astronomical routine. Consultation is available beyond the user’s city and language network.

The unresolved problems are less visible because they occur between layers:

Area	Present strength	Persistent weakness
Astronomical calculation	Mature libraries and close agreement on standard cases	Historical time data, hidden flags and inconsistent boundary display
Jyotiṣa conventions	Many programs support multiple schools and settings	Defaults are often poorly exposed or not preserved with reports
Interpretation	Large libraries of rules and automated reports	Weak source traceability and contradiction management
Professional workflow	Mature chart storage, printing and consultation support	Limited structured export and audit trail
Consumer access	Fast, inexpensive and multilingual	Calculation, prose, AI and commerce blur together
Open source	Inspectable code and extensibility	Uneven testing, maintenance and documentation
Consultation marketplaces	Immediate practitioner access	Variable competence, per-minute incentives and sensitive-data handling
AI	Natural-language explanation and interactive learning	Hallucination, overconfidence and concealed rule selection

The market has largely solved availability. It has not solved accountable judgment.

13. Choosing by purpose rather than reputation

A useful recommendation starts with the task.

User or task	Sensible starting point	What to verify
Family checking a vrata or festival	Drik Panchang; cross-check with the family’s regional almanac	Location, sunrise rule, regional tradition and tithi prevalence
Beginner learning Jyotiṣa	A readable calculator plus a teacher or primary text	Do not infer meaning from one placement; record settings from the beginning
Serious student or researcher	Jagannatha Hora, Maitreya, Swiss Ephemeris or an inspectable API	Version, ayanāṃśa, nodes, bhāva, daśā year, exports and test cases
Professional astrologer	Parashara’s Light, LeoStar, Jagannatha Hora or Cosmic Insights according to workflow	Client-data policy, backups, calculation settings and report provenance
Developer	Owned Swiss Ephemeris stack, VedAstro, Prokerala API or AstrologyAPI	Licence, vendor versioning, raw responses, historical time and regression tests
Consultation seeker	A named practitioner rather than a platform brand	Training, method, price ceiling, remedy conflict and handling of uncertainty
Quick second opinion	Two calculation tools with identical settings, followed by human review	Compare reasoning, not just conclusions

No product removes the need to understand what is being asked of it.

14. A benchmark that another researcher can actually rerun

The four exercises in this revision are a beginning, not a comprehensive benchmark. A stronger public suite should include contemporary, historical, boundary and geographic cases.

Core calculation cases

a contemporary Indian birth with an unambiguous time zone;
a birth within two minutes of a lagna boundary;
a nakṣatra-pāda boundary;
a tithi and karaṇa boundary;
a historical Indian time-zone case;
a southern-hemisphere birth;
a high-latitude sunrise case;
a chart near midnight;
multiple ayanāṃśas;
true and mean node variants;
whole-sign and computed-bhāva variants;
a date outside the usual modern range.

For each case, the archive should retain UTC conversion, geographical coordinates, planetary longitudes, lagna, bhāva cusps, pañcāṅga boundaries, sunrise definition, daśā balance, varga placements, ayanāṃśa value, node type, software version, raw export and screenshot.

Interpretation cases

A fixed set of questions should require each report or AI system to return:

calculated placements used;
selected interpretive rules;
source references;
supporting conditions;
contradictory conditions;
uncertainty;
final prose.

This would test faithfulness and traceability, not the truth of astrology as a whole. Predictive validity requires a separate preregistered study with independently defined outcomes.

Minimum product disclosure

A research-grade tool should expose:

ephemeris and version;
time-zone database and historical policy;
ayanāṃśa, node type and geocentric/topocentric choice;
bhāva and sunrise definitions;
daśā-year and divisional-chart conventions;
boundary rounding policy;
interpretive school, rule identifier and source;
contradiction handling;
whether prose is fixed, human or AI-generated;
model and retrieval versions for AI;
retention, deletion, practitioner access and commercial commissions.

Disclosure does not guarantee correctness. It makes correction possible.

15. Limits of this survey

There are several things I could not establish from public material.

I did not verify every proprietary formula in Parashara’s Light, LeoStar, AstroSage, ClickAstro or the commercial APIs. I did not compare paid reports line by line for duplicated text. I did not conduct covert consultations, so I cannot infer the average competence of a marketplace from selected reviews. App-store privacy labels are self-reported and do not substitute for a technical audit. Product pages and prices can change after the survey date.

The controlled calculations used Swiss Ephemeris as a reference implementation, not as an infallible authority. They tested a small set of boundary conditions. A program could pass them and fail elsewhere. The historical Kolkata case is especially important in this respect: the IANA database itself warns that the relevant wartime source is uncertain. The correct scholarly response is to preserve the uncertainty, not convert the database entry into a fact beyond dispute.

Finally, the survey evaluates software architecture, disclosure and reproducibility. It does not establish the empirical validity of natal prediction, muhūrta, compatibility or remedial claims.

Conclusion: the scarce resource is a traceable judgment

Early astrology software removed a large amount of manual labour: ephemeris lookup, logarithms, atlas search and repeated arithmetic. The present market has extended that achievement into regional-language almanacs, mobile workstations, APIs, report libraries, consultation networks and conversational AI.

The four calculation exercises altered my assessment in a useful way. The public pañcāṅga layer performed better than a casual critic might expect. At the same time, a single undocumented setting changed a nakṣatra, a node sign or a lagna. The calculation was not “the chart” until its conventions and time source were known.

That leads to a practical standard for digital Jyotiṣa. A trustworthy system should let another informed person reconstruct the result. It should preserve the input, version, ephemeris, ayanāṃśa, node, house and time conventions; show the rules used in interpretation; retain contradictory evidence; disclose whether AI wrote the prose; and keep commercial incentives visible.

No brand satisfies every purpose. The appropriate tool depends on whether the task is calendrical reference, professional calculation, research, software development or consultation. The user’s responsibility also changes with the task.

My final recommendation is therefore procedural rather than promotional: fix the input, record the settings, reproduce the calculation, ask for the rule, protect the data and treat fluent certainty as a claim to be examined—not as evidence in itself.

Notes and sources

[1] Astrodienst, Swiss Ephemeris documentation and test utilities. The public material describes the library, its JPL-based planetary data and dual licensing. Accessed 5 August 2026.

[2] Drik Panchang, homepage and calculation statements concerning Drik Gaṇita and location-sensitive observance. Accessed 5 August 2026.

[3] Drik Panchang, settings pages, including sunrise and regional calendar options. Accessed 5 August 2026.

[4] Prokerala, public astrology utilities and Astrology API homepage. Accessed 5 August 2026.

[5] Prokerala API V2 documentation, demos and terms. Accessed 5 August 2026.

[6] Astrodienst, Extended Chart Selection and Free Charts and Data. Accessed 5 August 2026.

[7] Astrodienst, Swiss Ephemeris programmer documentation and licensing pages. Accessed 5 August 2026.

[8] P. V. R. Narasimha Rao, “Features of Jagannatha Hora Software,” VedicAstrologer.org. Accessed 5 August 2026.

[9] VedicAstrologer.org, “Jagannatha Hora: Free Vedic Astrology Software.” Accessed 5 August 2026.

[10] VedicAstrologer.org, Jagannatha Hora release pages. The public site identifies version 8.0. Accessed 5 August 2026.

[11] Parashara Software, current Parashara’s Light product pages, including worksheets, reports, file management, yogas, texts, daśās, transits and muhūrta. Accessed 5 August 2026.

[12] LeoStar Astrology, official product and feature pages. Accessed 5 August 2026.

[13] LeoStar Astrology, multilingual edition pages and user-manual index. Accessed 5 August 2026.

[14] Maitreya project, GitHub and Saravali project pages. The project describes Maitreya as GPL-licensed, open source and cross-platform. Accessed 5 August 2026.

[15] Cosmic Insights, Apple App Store and Google Play feature listings. Accessed 5 August 2026.

[16] Cosmic Insights, “Top 10 Most Used Features of the Cosmic Insights App.” Accessed 5 August 2026.

[17] Apple App Store privacy disclosure for Cosmic Insights Astrology. Accessed 5 August 2026.

[18] AstroSage, homepage, Kundli app listing and AI astrology pages. Accessed 5 August 2026.

[19] AstroSage, privacy policy. Accessed 5 August 2026.

[20] ClickAstro, official horoscope, chart, report and app pages. Accessed 5 August 2026.

[21] ClickAstro, disclaimer and privacy material. Accessed 5 August 2026.

[22] AstroTalk, current app listing. Accessed 5 August 2026.

[23] AstroTalk, terms and conditions concerning service providers, warranties and professional advice. Accessed 5 August 2026.

[24] AstroTalk, privacy policy concerning retention, audio and practitioner interactions. Accessed 5 August 2026.

[25] Astroyogi, current app and service listings. Accessed 5 August 2026.

[26] Astroyogi, privacy policy concerning birth details, practitioner sharing, communications and deletion. Accessed 5 August 2026.

[27] Prokerala Astrology API, feature list, documentation and report endpoints. Accessed 5 August 2026.

[28] AstrologyAPI / Vedic Rishi, Vedic Astrology API feature pages. Accessed 5 August 2026.

[29] AstrologyAPI, developer documentation and API references. Accessed 5 August 2026.

[30] VedAstro, official repositories and project pages. Accessed 5 August 2026.

[31] VedAstro, “Getting Started,” including response envelopes, time format, authentication and ayanāṃśa defaults. Accessed 5 August 2026.

[32] AstroSage AI pages and VedAstro API/AI documentation. Accessed 5 August 2026.

[33] AstroSage, privacy policy. Accessed 5 August 2026.

[34] AstroTalk, privacy policy and terms. Accessed 5 August 2026.

[35] Astroyogi, privacy policy. Accessed 5 August 2026.

[36] Apple App Store privacy disclosure for Cosmic Insights Astrology. Accessed 5 August 2026.

[37] ClickAstro, website and app privacy policies. Accessed 5 August 2026.

[38] Author’s controlled calculation notebook and CSV outputs, supplied with this publication. Environment: Python 3.13, PySwisseph 20230604, Swiss Ephemeris 2.10.03. Calculations executed 5 August 2026.

[39] Drik Panchang, “August 05, 2026 Panchang for Bengaluru,” showing sunrise at 6:06 a.m., Saptamī to 8:42 p.m., Aśvinī to 9:18 p.m., Śūla to 5:29 p.m., Viṣṭi to 9:26 a.m. and Lahiri ayanāṃśa 24.235295. Accessed 5 August 2026.

[40] Prokerala, “Panchang for August 5, 2026,” Ujjain, showing sunrise at 6:03 a.m., Saptamī to 8:42 p.m., Aśvinī to 9:18 p.m., Śūla to 5:28 p.m., Viṣṭi to 9:27 a.m. and Lahiri ayanāṃśa. Accessed 5 August 2026.

[41] IANA Time Zone Database, asia source file, Asia/Kolkata entries for 1941–45. The file represents a wartime +06:30 offset and explicitly describes the sole source for the 1941–45 data as “dubious.” Accessed 5 August 2026.

[42] VedAstro, live method index and API material. The index exposes hundreds of calculation and prediction methods, including high-consequence health, longevity and death-related endpoints. Accessed 5 August 2026.