Audit of github.com/pewdiepie-archdaemon/odysseus — a privacy-first, self-hosted AI workspace — against IKA Concierge needs (Operations + Builder + Token stack). Compiled 2026-06-01. Companion to /ika-pro-architecture, /karpathy, /gstack, /hermes, /secondbrain.
ADOPT (pattern + reference code): Deep Research loop. Odysseus ports Alibaba DeepResearch — multi-step research with plan → search → synthesize → reflect cycles. Core IKA Concierge capability — Pro and Enterprise both (per Mats 2026-06-01; no free tier). Plugs straight into our Conversation Surface as a high-stakes "long-thinking" mode, sitting above the per-turn classifier gate. Pairs with v25.9's pre-query dedup: cheap RRF first, council second, deep-research third when stakes warrant it. Estimated ~½ day to lift the loop skeleton.
ADOPT (pattern only): Cookbook hardware fitter. Odysseus scans local VRAM and recommends models (GGUF/FP8/AWQ) by stake. We don't self-host model weights, but the shape — "constraint-aware capability picker" — maps onto our Token Stack Layer 3 / LiteLLM routing: stake estimate + per-IKA budget remaining + latency SLO → pick Haiku vs Sonnet vs Opus + council fan-out accordingly. Lift the decision-table pattern, not the GPU detection.
WATCH: Memory System (ChromaDB + fastembed). They evolve "skills" via persistent vector + keyword retrieval. We already have RRF (gbrain lift #2) + compiled-truth assessments (lift #4) on Postgres + pgvector — same shape, different storage. Worth a code-walk to lift their skill-evolution loop (how skills mutate over use). Not the ChromaDB layer.
WATCH: OpenCode agent loop. Odysseus's tool-based autonomous agent runtime. We use Paperclip + Hermes-adapter (per /hermes H1). Worth comparing OpenCode's tool-loop ergonomics — if cleaner than Hermes-adapter, possible alt-runtime in v1.
IGNORE: vLLM / llama.cpp / Ollama serving, ChromaDB storage, SearXNG web search, IMAP/SMTP email client, CalDAV calendar, multi-tab markdown editor, blind model comparison, hardware GPU passthrough, native install paths, 2FA layer. Reason: all of these either duplicate decisions we've already made (Anthropic as model layer, Postgres as data layer, per-neuron integrations as user-facing surfaces) or are out-of-posture (self-hosting model weights, running our own search index).
Posture: Self-hosted, privacy-first ChatGPT/Claude alternative. Runs entirely on the user's hardware with no external dependencies for core functionality. License: MIT. Stack: Python + FastAPI backend, vanilla JS frontend, SQLite/Postgres data, ChromaDB + fastembed for retrieval, Docker Compose for deploy.
Model layer: Pluggable across vLLM, llama.cpp, Ollama, OpenRouter, OpenAI APIs. Cookbook scans local hardware and recommends model formats (GGUF / FP8 / AWQ) per VRAM budget.
Scope: Chat + agents (OpenCode runtime) + Deep Research + Memory + productivity surfaces (email, calendar, documents, notes, tasks) + utilities (model comparison, image editing, file upload with vision, web search via SearXNG).
Architecture:
app.py — FastAPI entrycore/ — auth, database, middlewaresrc/ — LLM core, agent loop, tools, chat processorroutes/ — chat, session, document, memory, model endpointsservices/ — docs, memory, search, hardware fittingstatic/ — vanilla JS frontendPosture gap vs IKA: Odysseus says "run everything on your laptop." IKA says "Anthropic for the model layer, managed Postgres for state, Firecracker for skill isolation." Most of Odysseus's surface area is solving problems we've explicitly decided not to solve (model serving, embedding storage, web-search infrastructure). The shape of a few subsystems still maps onto our needs even though the implementation doesn't.
| Odysseus component | IKA counterpart | Verdict |
|---|---|---|
| Deep Research (multi-step research loop, ported from Alibaba DeepResearch) | Conversation Surface "long-thinking" mode — does not exist today; closest is the classifier-gate query exit | ADOPT pattern + code-walk — sits above the gate as a stakes-triggered escalation |
| Cookbook (VRAM-aware model picker by stake) | Token Stack Layer 3 (LiteLLM smart routing) — Haiku/Sonnet/Opus selector | ADOPT pattern — same decision shape, different inputs (tier + budget + SLO instead of VRAM) |
| Memory System (ChromaDB + fastembed; persistent vector + keyword retrieval; skill evolution) | Postgres + pgvector + tsvector RRF (gbrain lift #2); skills = first-class entity per /per-neuron Skills | WATCH — storage layer different; skill-evolution loop worth code-walking |
| OpenCode agent runtime | Paperclip + hermes-paperclip-adapter (Hermes H1) | WATCH — comparison vs Hermes adapter for v1 runtime choice |
| vLLM / llama.cpp / Ollama serving | Anthropic API (Claude Haiku / Sonnet / Opus) | Skip — explicit posture decision |
| ChromaDB vector store | pgvector (managed Postgres, schema-per-IKA + RLS) | Skip — already on Postgres |
| SearXNG web search | Per-neuron Skill / Integration (Tavily, Brave, or Exa via skill catalog) | Skip — surfaced as skill, not infra |
| Email (IMAP/SMTP) with AI triage | Per-neuron Gmail / Outlook integration → agent tool calls | Skip — integration model, not built-in client |
| Calendar (CalDAV) | Per-neuron Google Calendar / Microsoft 365 integration | Skip — same as above |
| Documents (markdown/HTML editor) | Document = first-class entity per architecture | Skip — entity exists; editor is a v1+ build |
| Notes & Tasks | Notes + Tasks already first-class entities | Skip — covered |
| Blind model comparison | Karpathy llm-council second-opinion middleware (different goal — council = consensus, blind = evaluation) | Skip — out of scope; we trust the threshold table |
| Image editing | Per-neuron skill (Adobe MCP or similar) — surfaced as tool, not built-in | Skip |
| File upload (vision/PDF) | Document entity + Anthropic native vision + Files API per architecture | Skip — covered |
| 2FA | Auth layer per architecture (managed via platform; TOTP at minimum on managed deploy) | Skip — covered |
| MCP server integration | MCP / API integrations section in architecture — already first-class | Skip — already adopted |
| Docker Compose + GPU overlays | Managed deploy + Firecracker for skill isolation | Skip — out of posture |
What it is: Odysseus ports Alibaba's DeepResearch loop into a self-hosted runtime. The pattern is a multi-step research synthesizer:
| IKA need | How Deep Research answers it |
|---|---|
| Conversation Surface — high-stakes "research this for me" requests (e.g., "should we sign this contract?", "compare these three vendors") need more than a single Sonnet turn | Wraps multiple turns into a single user-facing operation with cost / step caps. Output is a Document or Artifact entity, not a chat reply. |
| Pairs with v25.9's pre-query dedup + classifier gate | Pre-query dedup runs first (free). If miss, classifier gate routes query for cheap retrieval. If user explicitly invokes "deep mode" OR classifier flags high-stakes, escalate into Deep Research loop. |
| Token economics — adds a fourth budget tier above interactive / batch / council | Deep Research has its own per-IKA budget cap (separate from interactive). Governed by the existing per-IKA cost cap primitive. No per-plan toggle (IKA Concierge = Pro + Enterprise; no free tier). |
Gbrain integration — research outputs are high-signal candidates for the assessments table | Each completed Deep Research run produces a curated assessment with citations. Pipes into compiled-truth schema (lift #4) automatically. |
platform.conversation_* tables/vendored/odysseus-deep-research/What it is: Odysseus scans the local machine — VRAM, CPU cores, RAM, GPU vendor — and recommends quantized model formats (GGUF / FP8 / AWQ) with serving runtime (vLLM / llama.cpp). Stake-aware: bigger model for harder questions, smaller for routine.
The lift is the shape, not the substance. We never scan GPUs. But the same decision shape solves a real IKA problem:
| Cookbook input | IKA equivalent input |
|---|---|
| Available VRAM | Per-IKA monthly budget remaining |
| Question stakes (curiosity vs critical) | Classifier-gate stake estimate + v17 threshold table category |
| Latency tolerance | User-facing vs background (batch-eligible) |
| Model formats available (GGUF/FP8/AWQ) | Anthropic tier matrix (Haiku/Sonnet/Opus × interactive/batch/cached/council) |
Output: a single routing decision — model tier + caching mode + batch vs interactive + council on/off. Today that logic is spread across the v17 threshold table, the gstack #3 second-opinion gate, and the token economics 6-layer stack as separate decisions. Cookbook collapses them into one decision table.
Effort: pure refactor of existing logic into the Cookbook shape; ~½ day. Sits inside Paperclip's request-dispatch path as cookbook.pick(request).
Why it's worth doing: today each layer of the token stack has its own threshold logic; adding a new model tier (e.g., when Sonnet 4.7 ships, or when Haiku 5 is cheaper) requires touching multiple files. Cookbook gives us one place to edit when Anthropic's pricing/capability matrix changes — which it has 6× in the past 18 months.
Persistent vector + keyword retrieval via ChromaDB. Skills "evolve over time" — Odysseus tracks skill invocations, edits skill content based on outcome.
Storage layer: skip. ChromaDB is a different bet than pgvector, and we've already paid the integration cost on Postgres (gbrain lifts 1–6, RRF, dream-cycle, assessments).
Skill-evolution loop: worth a code-walk. We have skill catalog (Hermes H4, agentskills.io standard) but no formalized auto-revision loop. The question is: when a skill is invoked 100× and 12 of those produce a downstream user correction, does the skill get a self-rewrite pass? Odysseus has machinery for this; we have a stub. ~1 hour code-walk before specing v1 skill-evolution.
Effort: 1-hour code-walk; defer adoption decision to v1 (post-launch — we don't have enough skill-invocation data yet to drive evolution).
Odysseus's tool-based autonomous agent loop uses the OpenCode framework. Per Hermes adoption (H1), our v0 plan is hermes-paperclip-adapter as the agent class. OpenCode is an alternative shape — different tool-call ergonomics, different planning loop.
Decision (Mats 2026-06-01): Hermes-paperclip-adapter is the agent runtime. No v1 bench. OpenCode dropped.
Email client, calendar, documents, notes, image editing, file upload, 2FA, web search, model serving, GPU passthrough, native install. All of these solve real problems — for a self-hosted local-first product. IKA is the opposite posture: managed deployment, Anthropic model layer, per-neuron integrations as the surface for external services.
The pattern: where Odysseus builds the thing, IKA integrates the thing at the per-neuron level. Email is a Gmail integration on the Comms neuron, not a built-in IMAP client. Calendar is a Google Calendar integration, not a CalDAV sync engine. Documents are entities, not an editor app.
What this means for the user: Odysseus is one app that does many things. IKA is many neurons each doing one thing well, connected through the conversation surface + the entity graph. Different DNA. Lifting Odysseus's email client would mean abandoning the per-neuron model.
/vendored/odysseus-deep-research/; pin commit. ~½ day skeleton + ~1 day assessments wiring + ~½ day budget governance + UX. Output lands as Artifact with a "convert to Document" affordance for further editing.cookbook.pick(request) entrypoint replacing dispersed threshold logic across v17 gate, gstack #3, and the 6-layer stack. ~½ day.Per Mats 2026-06-01: Deep Research is core IKA Concierge capability for both Pro and Enterprise — no free tier exists, no per-plan toggle. The prior tier-policy "open question" was invalid: I invented the free/pro/enterprise framing from generic SaaS patterns; the architecture page never claimed a free tier. Corrected.