What does slorg do differently from a search index?

slorg does not index your documents. On every query it has an LLM draft an answer, extracts a knowledge graph from the draft, derives keywords from the graph, searches the web through SearxNG, fetches the results and has the LLM score each one from 0 to 1.

No. It runs the same six fixed steps on every query. It does not choose tools at runtime and does not loop back to revise its plan if the results score poorly.

Slow by search-engine standards. The project's own estimate is roughly 5–15 seconds wall-clock with the default configuration, because each query makes three LLM round-trips and fetches every candidate page.

Should I replace Algolia or Meilisearch with slorg?

No. Algolia, Meilisearch and Typesense search your own content and return results fast enough for search-as-you-type. slorg answers open-web questions slowly but with its plan visible. They solve different problems.

slorg vs Algolia vs Meilisearch: Plan-First Search

The problem

Traditional search matches the words of a query against an index and ranks what comes back. That works when the user’s words resemble the document’s words. It degrades when the user knows what they want but not what it is called.

slorg tries a different order of operations: it has a language model draft an answer and a plan first, then uses the plan to decide what to search for. Its tagline is “the search engine that thinks before it searches”. The honest reading of that tagline is structural — a planning step before retrieval — not a claim about reasoning, and we have no measurement showing it improves precision over conventional search. What it gives you is plan-conditioned retrieval with every intermediate artefact visible.

This post compares it with Algolia, Meilisearch and Typesense. The most useful thing to say up front is that they mostly do not compete.

What slorg is

slorg is a Node.js package published on npm as slorg, usable as a CLI, a library or a REST service. Every query runs the same six steps:

Draft. The LLM writes a first-pass answer from its training data alone, with no web access.
Knowledge graph. Entities and relationships are extracted from the draft (in practice in the same call as step 1).
Keywords. Search terms are derived from the graph, not from the user’s raw phrasing.
Search. SearxNG queries Google, Bing, Yahoo and DuckDuckGo by default with those keywords.
Fetch. Each candidate URL is fetched and its readable content extracted; failures simply score low later.
Score. The LLM scores each result from 0 to 1 against the original query, and the top results are returned.

The response exposes all of it: the draft answer, the knowledge graph, the keywords, the scored results with extracted content, and the token count.

Three of the six steps call the LLM, so every query costs at least three round-trips plus a content-fetch sweep. The project’s own estimate is roughly 5–15 seconds wall-clock with the default configuration, and there is no streaming. It works with OpenAI or any OpenAI-compatible endpoint, including a local model.

slorg is not an agent. It never decides whether to search, never picks tools, and never loops back to revise its plan if everything scores poorly. That keeps cost and latency predictable and makes failures happen in the same place every time.

What the alternatives are

Algolia is a hosted search-as-a-service. You push your records into its index and get fast, typo-tolerant, faceted search, with relevance tuning and analytics. It is a common default for site and e-commerce search.

Meilisearch is an open-source, self-hostable search engine with a hosted cloud offering. It is easy to deploy, with typo tolerance, filtering and sensible default ranking.

Typesense is an open-source, typo-tolerant search engine built for instant, search-as-you-type experiences, also available self-hosted or as a cloud service.

All three search your content, from an index you maintain, fast enough to update results as the user types. slorg searches the public web, through SearxNG, every time, and maintains no index at all.

The dimensions

Dimension	slorg	Algolia	Meilisearch	Typesense
What it searches	The public web via SearxNG	Your indexed records	Your indexed records	Your indexed records
Architecture	Fixed six-step LLM pipeline	Hosted index	Inverted index	Inverted index
LLM in the loop	Yes, three calls per query	Optional AI features	Optional AI features	Optional AI features
Typical latency	Seconds (5–15 s estimate, default config)	Interactive	Interactive	Interactive
Search-as-you-type	No	Yes	Yes	Yes
Typo tolerance, facets	No (not an index)	Yes	Yes	Yes
Intermediate artefacts	Draft, graph, keywords, per-result scores	No	No	No
Self-hostable	Yes	No	Yes	Yes
Per-query cost	LLM tokens plus fetches	Usage-based pricing	Infrastructure	Infrastructure
License	MIT	Proprietary	MIT (community edition)	GPL-3.0

When to use which

Use slorg when:

The question is exploratory and open-web — the user cannot name the thing they are looking for, and the draft can supply vocabulary they lack.
You need the intermediate artefacts as data: the graph and keywords to feed a downstream pipeline, or per-source scores so an answer ships with its own paper trail.
You want a self-hosted pipeline you can read and change, rather than an opaque hosted answer engine.
Several seconds per query is acceptable.

Use Algolia when:

You need site or product search over your own catalogue with no infrastructure to run, and are willing to pay for it.

Use Meilisearch when:

You want a self-hosted, lightweight default for search over your own content.

Use Typesense when:

Instant, type-as-you-search results over your own data are the priority.

Where slorg loses

Speed. Algolia, Meilisearch and Typesense answer in the time it takes to type a character. slorg takes seconds and does not stream.
Your own documents. slorg has no ingestion step and does not search a private corpus. For an internal knowledge base, use an index (or a retrieval stack built on one).
Anchoring. If the step-1 draft is confidently wrong, the graph and keywords inherit the wrong topic and the retrieved set can score well for the wrong question. Planning first makes the plan visible; it does not remove hallucination.
Engine bias. Anything the upstream engines decline to surface, slorg cannot surface either.
No recovery. If every result scores low, slorg returns low scores; it does not try again. That would be agentic behaviour, and we chose predictable cost over it.
Privacy. The default backends are public search engines.

Trying it

From the published slorg package’s README (note: the npm name lorg belongs to an unrelated package — install slorg):

npm install -g slorg
export OPENAI_API_KEY=sk-...

# CLI
slorg "What causes the northern lights?"

# or as a REST service
slorg server -p 3000
curl -X POST http://localhost:3000/search \
  -H "Content-Type: application/json" \
  -d '{"query": "How does CRISPR work?"}'

Configuration is five environment variables: OPENAI_API_KEY, OPENAI_BASE_URL (any OpenAI-compatible endpoint), LORG_DEFAULT_MODEL (one model for all three LLM steps), LORG_SEARCH_ENGINES and LORG_SEARCH_LIMIT. The search limit is the biggest latency lever.