Frequently asked
Questions teams ask before they pilot .
Positioning, security, pricing, and what's on the roadmap. If your question isn't here, ask us directly — we'll add the answer to this page.
What is it
Positioning, audience, and how Oracus.ai is different from things you already have.
What is Oracus.ai?
A self-hosted Q&A layer over your engineering reality — code, deployments, tickets, specs, ownership. You ask anything; it answers with citations to the sources it used. Lives in Slack or chat, so non-engineers can use it as easily as engineers.
Who is it for?
Engineering organizations large enough that no one person remembers everything anymore. The daily users are PMs, product owners, customer-success leads, and engineers asking questions about parts of the product they didn't build.
How is it different from Backstage?
Backstage is declarative — you maintain a catalog-info.yaml per repo, and at 100+ repos that maintenance burden is what kills adoption. Oracus.ai is derived: it reads what's actually deployed and rebuilds the catalog every ingest. Backstage is a directory you keep up to date; Oracus.ai is a search engine for your product.
How is it different from Cursor, Copilot, or chatting with Claude?
Those answer per-file, inside the editor. Oracus.ai answers across repos, across systems (code + Jira + specs + ownership), in Slack or chat — and cites every claim. Different question shape, different answer shape, different audience.
Do we still need Confluence or a wiki?
Yes, for things only humans can write down — architecture decisions, runbooks, the why-we-built-it stories. But Oracus.ai replaces the parts that rot the fastest: service catalogs, ownership pages, who-owns-what docs. If a wiki page hasn't been touched in six months, Oracus.ai is reading newer truth.
Trust & accuracy
Citations, hallucinations, and how fresh the answers are.
How does it avoid hallucinations?
The prompt enforces citations and the response schema requires them. Every claim is bound to a source id — a ticket, a file, a service, a commit. Wrong answers are traceable, not invented. Bad sources produce visibly-wrong answers, not silent ones.
What happens when it's wrong?
You see the citation that led to the wrong answer, fix the source, and the next ingest produces the right answer. The fix is always grounded in something you can change — a stale ticket, an outdated comment, a missing CODEOWNER.
How fresh is the data?
Daily ingest by default. Repos, Jira, specs, and ownership data on cron. Every Slack or chat query reads the latest snapshot. CI can also push fresh test results after every build.
Security & self-hosting
Where the data lives, what crosses your network, which model you use.
Where does our data live?
On infrastructure you control. Oracus.ai is self-hosted — one Docker container plus Postgres, on your servers. Code, embeddings, chat history, and tickets never leave your network.
Does our source code leave our network?
No. Source stays in your Postgres. The only thing that crosses your network boundary is the prompt plus retrieved excerpts sent to your LLM provider — and you choose the provider, including self-hosted Ollama if you want zero outbound calls.
Which LLM does it use?
Your choice. OpenAI, Anthropic, Google, or self-hosted via Ollama. Provider-agnostic, built on Vercel AI SDK. You can swap providers per task — a small model for routing, a bigger one for synthesis.
Do we have to send our data to a third-party LLM?
No. Ollama running on your own GPU box is supported as a first-class option. Slower and less capable than the hosted frontier models, but zero outbound calls.
Pricing & licensing
Why per-repo, what's open, and where model costs land.
Why per-repo pricing instead of per-seat?
Repos track the size of an engineering organization more honestly than seats. And Oracus.ai lives in Slack — seat metering would discourage adoption. Bigger orgs have more services; bigger orgs pay more. We don't gate questions on user counts.
Is Oracus.ai open-source?
No — Oracus.ai is a proprietary, self-hosted product. You run it as a container entirely inside your own network, so your data, keys, and model calls never leave your infrastructure, but the source isn't distributed. The Community tier is free for tinkerers and tiny teams (access by request while we onboard early users); paid tiers add multi-team isolation, connectors, and SLA-backed support. See pricing for details.
What about model costs?
Token spend lands on your provider bill, not ours — no markup, full transparency. Bring your own keys for OpenAI, Anthropic, Google, or run Ollama for zero token cost.
Getting started
Install, pilot scope, and what's on the roadmap.
What does install look like?
One Docker container plus Postgres plus your model keys. A platform engineer can stand it up in an afternoon. Self-hosting docs walk through it step by step.
How do we pilot it?
Pick 10–15 of your most-trafficked repos, connect them, point Oracus.ai at the Jira project that covers them, and put the Slack bot in two channels with mixed PM and engineer membership. Track quality of answers against a fixed list of questions over four weeks. We can help scope the pilot.
What's on the roadmap?
Three near-term focus areas. (1) Incident context — connecting alert events to the graph, recent commits, and in-flight tickets, so a question like 'what's happening with tiktok-sync right now?' pulls the latest signal alongside the static map. (2) Richer business-view overlays — capability domain, customer-flow tagging, and team-criticality scoring. (3) More out-of-the-box connectors — pager, design docs, incident retrospectives. Live log ingestion is roadmap, not MVP: the wedge today is the static graph plus tickets plus specs, and we want the runtime layer to enrich that — not replace what observability tools already do well.
Didn't see your question?
Send it over. We'll answer directly, and if it comes up again we'll add it here.