This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.
What I Built
What happens when you switch AI models after spending hours working with one?
Your context doesn't always follow you.
Your preferences, previous decisions, unfinished tasks, and the reasoning behind your approach can become scattered across different conversations and AI tools. Every switch can feel like starting over.
That's the problem I'm exploring with ContinumAI.
ContinumAI is a multi-model memory and gateway project designed to help AI conversations maintain continuity across different models. It explores how shared, persistent memory can help different models continue working with relevant context instead of treating every interaction as an isolated experience.
The idea behind the project is simple:
The model can change. The memory shouldn't have to start from zero.
I interpreted Ghost in the Machine as the invisible context behind an AI interaction—the accumulated information that gives a conversation continuity, even when the model handling it changes.
ContinumAI aims to make that invisible layer persistent, inspectable, and useful.
Demo
Live Demo: Not deployed yet. Development is still in progress.
Prototype Video: Watch the ContinumAI prototype
Screen Recording 2026-10-29 232911.mp4 - Google Drive
drive.google.com
The prototype showcases the ContinumAI memory graph, where conversation nodes, model providers, and relationships can be explored visually.
The goal is to make memory more than a hidden backend mechanism. By visualizing connections between conversation nodes, the project explores how users might inspect the context carried across their AI workflows.
Code
GitHub Repository: Abhishek-gupta18/ContinumAI
The project explores a modular architecture built around:
- Multi-provider integration: Connect different model providers through dedicated adapters.
- Persistent memory: Store conversation data and maintain session history.
- Gateway orchestration: Manage interactions between the application and model providers.
- Memory visualization: Explore conversation nodes, relationships, and lineage through a graph interface.
- Extensible architecture: Build toward more reliable, secure, and user-controlled memory.
The repository contains the implementation and ongoing development work behind this approach.
How I Built It
ContinumAI is an application-level AI infrastructure project, not a model trained from scratch.
Its architecture separates provider integration, memory persistence, gateway logic, and frontend visualization.
The main technologies include:
- Frontend: React and TypeScript for the interactive memory graph and session interface.
- Backend: Node.js and Express for API routing and provider orchestration.
- Database: PostgreSQL for persistent conversation and memory data.
- Provider integration: Modular adapters that allow different model APIs to work behind a common gateway.
The open-source AI component
I used Nemotron (NVIDIA’s open-weight model), driven through the OpenCode agent harness, for writing, testing and iterating on the ContinumAI codebase: the Express gateway, the provider failover logic, the linked-node memory store with checkpoints, and the contract/failover test suites.
This component fits into the architecture by building it rather than running inside it: it implemented the memory chain (one node per exchange linked by prev_id, checkpoint every 5 turns, latest-checkpoint context handoff) and the failover pipeline. At runtime ContinumAI’s providers are the user’s own OpenAI, Gemini, Claude, NVIDIA NIM and OpenAI-compatible endpoints; Nemotron is not one of the in-app models.
The focus is not simply on sending requests to multiple APIs. It is on the infrastructure surrounding those requests: retaining useful context, managing differences between providers, and making the overall experience more continuous.
Why Does Open Innovation Matter?
A system built around only one provider can inherit that provider's interfaces, assumptions, and limitations.
Open innovation creates room to experiment with different models, inspect implementations, adapt components, and build interoperable systems.
For ContinumAI, this matters in three ways.
1. Freedom to experiment
Different models have different strengths, limitations, and costs. A modular architecture makes it easier to experiment with alternatives rather than tying the entire system to one implementation.
2. More control over memory
Persistent memory should be something users can inspect and manage, with the possibility of moving relevant context between compatible systems.
The long-term goal is to make memory less dependent on a single provider's conversation interface.
3. Community-driven improvement
Memory retrieval, summarization, context preservation, and provider interoperability are challenges that benefit from shared experimentation.
Open-source tools allow developers to build on existing work, inspect how components behave, and improve them collaboratively rather than reinventing every layer.
Open innovation does not automatically make a system secure, private, or provider-independent. Those properties require deliberate engineering. But openness creates more opportunities to inspect, adapt, test, and improve the systems we build.
My Agent Session
AI-assisted development has been part of my journey building ContinumAI. The interesting part isn't just generating code; it's understanding architectural trade-offs, testing assumptions, identifying failure cases, and deciding which changes actually belong in the project.
The Spirit of It
I keep coming back to one question:
If an AI can help you build something over weeks or months, why should changing the model mean rebuilding the context from scratch?
A conversation is more than a sequence of messages. It contains decisions, preferences, mistakes, corrections, and unfinished ideas.
The challenge isn't simply to store every message forever. It's to preserve the right information, retrieve it when needed, and carry it forward without overwhelming the model with unnecessary context.
That's what I want ContinumAI to explore: a future where switching models doesn't automatically mean losing the thread.
The intelligence may come from different models. The continuity should come from the system connecting them.
ContinumAI is an ongoing exploration of persistent AI memory, model interoperability, and user-controlled context. There's still engineering work ahead, but the goal is to make switching models feel less like starting over and more like continuing the same journey.
What's your take? Should AI memory belong to an individual model, or should users be able to carry their context across different models and tools?
I'd love to hear what other developers are building around memory, context engineering, and open AI infrastructure.
Top comments (4)
Keeping the memory store model-agnostic is the right instinct, but the real friction usually hits at prompt compile time. Different model families treat serialized state very differently. Claude tends to respect dense XML tags for previous decisions, while small open weights drop constraints unless they sit in a flat list near the user turn. If ContinumAI normalizes the memory into declarative facts and lets adapter templates format them per provider, you avoid half the context drift when switching back and forth.
This is a really useful insight! The distinction between a model-agnostic memory store and provider-specific prompt compilation makes a lot of sense. I'm considering keeping canonical memories provider-independent while introducing a compiler layer that formats retrieved facts, decisions, and constraints for each adapter. I'd also like to benchmark this against a shared baseline to measure whether it actually reduces context drift across models. Thanks for pointing out this architectural gap!🫂
Looks interesting.... Great work btw👏
thanks mann...