PYTHIA fuses MiroFish's swarm predictions with Osiris's live world feeds and a local LLM that reads the assembled world-state and forecasts across the 24h, week, month, and year horizons, served as one keyless JSON API plus an MCP server. Most agents are blind to the real world; PYTHIA grounds their decisions in live conflict, market, disaster, and disease data — no cloud, no API keys.
PYTHIA already exposes the relevant knob: the .env LLM_* lines point the oracle at any OpenAI-compatible API, and users swap in bigger brains like llama3.1:70b for deeper reasoning. For people whose hardware cannot run the reasoning model they want, an optional provider offering many chat/reasoning models through one endpoint adds a genuine choice without touching the default local, keyless path.
Proposal: OrcaRouter as an optional provider
I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional provider for PYTHIA's oracle. It would not replace or change the default local/Ollama path, MiroFish, or any existing provider — it is purely an extra base URL for users who already use the documented OpenAI-compatible override.
Concretely, OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication and offers many chat, reasoning, and image models behind a single endpoint. For PYTHIA that looks most relevant in three places:
- Model choice beyond local hardware — the oracle, and individual swarm personas (which already support per-persona model overrides), could use reasoning-class models without juggling separate keys and URLs per model.
- Routing with provider failover — automatic routing keeps the always-on forecast loop, the morning brief, and alert rules running even if one upstream provider degrades.
- Usage tracking with budgets — visibility into what continuous forecasting costs when the brain is a paid endpoint, plus the ability to cap it.
The expected integration point is config-level: point LLM_BASE_URL at OrcaRouter's OpenAI-compatible endpoint and set LLM_API_KEY and LLM_MODEL accordingly. I have not written or tested any code — this is a proposal for your judgment, and it would respect PYTHIA's local-first ethos by leaving the default path untouched.
OrcaRouter is already integrated by open-source projects such as Dify, goose, and OpenCode, and we track them at https://www.orcarouter.ai/built-with. Full disclosure: we run an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a condition for integration, and we are happy to follow PYTHIA's own disclosure and governance expectations.
If you think this fits, or should be scoped differently, I'd welcome your thoughts — and I'm glad to submit an implementation PR once you approve.
PYTHIA fuses MiroFish's swarm predictions with Osiris's live world feeds and a local LLM that reads the assembled world-state and forecasts across the 24h, week, month, and year horizons, served as one keyless JSON API plus an MCP server. Most agents are blind to the real world; PYTHIA grounds their decisions in live conflict, market, disaster, and disease data — no cloud, no API keys.
PYTHIA already exposes the relevant knob: the
.envLLM_*lines point the oracle at any OpenAI-compatible API, and users swap in bigger brains likellama3.1:70bfor deeper reasoning. For people whose hardware cannot run the reasoning model they want, an optional provider offering many chat/reasoning models through one endpoint adds a genuine choice without touching the default local, keyless path.Proposal: OrcaRouter as an optional provider
I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional provider for PYTHIA's oracle. It would not replace or change the default local/Ollama path, MiroFish, or any existing provider — it is purely an extra base URL for users who already use the documented OpenAI-compatible override.
Concretely, OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication and offers many chat, reasoning, and image models behind a single endpoint. For PYTHIA that looks most relevant in three places:
The expected integration point is config-level: point
LLM_BASE_URLat OrcaRouter's OpenAI-compatible endpoint and setLLM_API_KEYandLLM_MODELaccordingly. I have not written or tested any code — this is a proposal for your judgment, and it would respect PYTHIA's local-first ethos by leaving the default path untouched.OrcaRouter is already integrated by open-source projects such as Dify, goose, and OpenCode, and we track them at https://www.orcarouter.ai/built-with. Full disclosure: we run an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a condition for integration, and we are happy to follow PYTHIA's own disclosure and governance expectations.
If you think this fits, or should be scoped differently, I'd welcome your thoughts — and I'm glad to submit an implementation PR once you approve.