Oroimen

Private AI memory on hardware you control, with local RAG and explicitly selected, provider-configurable cloud access.

Comment

Inspiration

Oroimen means memory or recollection in Basque. Personal AI becomes useful when it understands files, conversations, and context—but that same knowledge makes a cloud-first default uncomfortable.

Oroimen starts from a different premise: keep data in an environment the owner controls, then make every escalation of compute an explicit decision.

What it does

Oroimen is a local-first, self-hosted personal AI assistant with a browser chat interface, an OpenAI-compatible API, a SQLite-backed vault, automatic document ingestion, RAG, and prompt-injection defenses around file and tool content.

Its architecture has three compute zones:

  • Local tier: the NAS or Docker host runs the default chat, memory, retrieval, and low-resource embedding path.
  • Edge tier: an optional, operator-configured inference endpoint on a trusted machine in the same local network. It lets a low-power NAS keep the data while a stronger PC handles higher-capacity embedding or OCR work. This is not a cloud fallback; documents remain inside the owner's trusted environment.
  • Cloud tier: optional and explicitly configured. The standard oroimen-agent never silently sends a failed conversation to the cloud. The owner must select oroimen-agent-cloud, choose a compatible endpoint, model, and credential, and thereby opt in for that conversation.

The Build Week cloud-slot configuration targets GPT-5.6. Other OpenAI-compatible providers can be configured by the owner. CPU inference remains supported; compatible GPUs and the edge tier improve latency without making one hardware vendor a requirement.

What changed during Build Week

Oroimen began before Build Week as a private assistant tied to one deployment. During the submission period, Codex with GPT-5.6 was used to make it a public, transferable product:

  • sanitized the public repository and removed personal infrastructure assumptions;
  • traced contracts across ingestion, retrieval, provider routing, API boundaries, lifecycle code, and the local/edge/cloud boundary;
  • implemented and tested the explicit GPT-5.6 cloud-slot route without automatic escalation;
  • built the local Ollama and WebUI evaluator path;
  • added deterministic public CI and credential scanning;
  • created a public prompt-injection benchmark path;
  • used fresh adversarial-review agents to find integration faults that isolated unit tests missed.

The dated commit history, BUILD_PROCESS.md, FINAL_VERIFICATION.md, and the submitted Codex Session ID distinguish this work from the pre-existing project.

How we built it

The runtime uses Python, FastAPI, asyncio, SQLite WAL, Ollama, Docker Compose, and Open WebUI. Codex with GPT-5.6 served as an engineering partner for repository-wide analysis, implementation, tests, documentation, and adversarial review.

One review found a cross-component document-reconciliation conflict: the primary drop directory was also being treated as an overlapping monitored partition. The focused fix preserves strict overlap protection while removing the duplicate root. This is the type of integration fault that file-by-file review can miss.

Challenges

The hard part was not adding another model call. It was making privacy claims precise across every fallback, embedding policy, parser, cache, API boundary, and document-to-prompt transition.

We also had to turn a deployment built for one home server into something other people can configure without inheriting its paths, network assumptions, GPU vendor, or provider choices.

Accomplishments

  • Public AGPL-3.0-or-later repository with reproducible dependency locking.
  • More than 1,700 deterministic unit tests, plus integration, lint, type-check, Compose, and credential-scanning gates.
  • Prompt-injection defenses tested against the public deepset/prompt-injections dataset and measured regression cases.
  • A Compose evaluator path with WebUI, local chat, local embeddings, document ingestion, and RAG.
  • A separate, configurable edge tier for trusted-network compute.
  • Explicit cloud selection without making cloud processing the default.
  • A five-minute evaluator tour in the README.

What we learned

A sovereign assistant is not simply “a model running locally.” Every fallback and data boundary can quietly change where information goes. Codex was especially effective at tracing those contracts across a large repository and coordinating fresh adversarial reviews.

Portability means preserving choice: CPU as a baseline, vendor-specific acceleration as an option, trusted edge compute for heavier local work, and cloud configuration owned by the user.

What's next

After Build Week: broader live-provider evaluation, verified GPU profiles for NVIDIA, AMD, and Intel-capable hosts, pinned multi-architecture images, improved timezone support, and smaller low-resource deployment profiles.

Try it

Clone the public repository and follow the README evaluator tour. The default local path requires Docker but no cloud API key.

Built With

  • codex
  • docker-compose
  • fastapi
  • github-actions
  • gpt-5.6
  • ollama
  • open-webui
  • pytest
  • python
  • sqlite
Share this project:

Updates

posted an update —

Building Deep Research the boring way first Update

Oroimen has been growing a new capability: Deep Research.

But instead of jumping straight into “let an AI search the web repeatedly until it feels done”, I wanted to build the boring parts first — the parts that make the eventual research system measurable, recoverable and trustworthy.

Over the last few milestones, Oroimen gained the foundations for an iterative research loop:

research question → plan → search → evidence → identify what is still missing → search again → stop

The important bit is that the AI doesn't get unlimited control of that loop. Models can propose what to search for next, but deterministic code controls budgets, duplicate searches, cancellation, recovery and when another research wave is actually allowed.

It can now checkpoint its progress, recover safely after interruption, keep provenance between searches and sources, and distinguish between “I found another URL” and “I actually gained new evidence”.

This week I also stopped adding features for a moment and split that research loop into clearer modules: state, evidence/provenance, assessment, orchestration and persistence.

Why bother?

Because the next stage is the part I'm most excited about: experimentation.

Instead of guessing what makes a great Deep Research system, I want Oroimen to have a frozen benchmark where different strategies can compete against the same baseline.

For example:

Does reflecting on evidence after every search wave actually help? Does explicit gap detection improve coverage? When does another search stop adding useful information? Does source diversification matter more than a smarter planner? Does claim verification improve the final answer enough to justify its cost?

There are already excellent Deep Research products from much larger teams. I'm not trying to pretend I can out-invent all of them from scratch.

The approach here is simpler:

study what seems to work, turn those ideas into hypotheses, measure them, and keep only what demonstrably improves Oroimen.

And throughout that process, the original principle stays the same:

Your AI can change. Your memory shouldn't have to.

Next up: build the evaluation laboratory, measure the first real quality baseline, and then start breaking things experimentally.

Log in or sign up for Devpost to join the conversation.

Submission history