DEV Community: Nucleus OS

AI Agents Can Ship to Production: A Deployment Case Study

Nucleus OS — Thu, 25 Jun 2026 14:25:02 +0000

I haven't opened Xcode in three weeks.

My AI agent deploys my app to both App Store and Google Play from
terminal. Two commands. No web UI. No drag-and-drop. No CI/CD
pipeline. The agent reads a deployment file, builds the app,
signs it, uploads to both stores, commits the version bump,
and pushes to git.

This is a case study in what AI agents can do when you give
them readable instructions and local access to tools that
already exist.

The setup

The whole thing is one markdown file. That's the part that
surprised me — I expected to need a CI/CD pipeline, a Fastlane
configuration, a Makefile, maybe a Docker container. Instead,
it's a single document that any AI agent can read and execute.

Here's what's in it:

Credentials (stored on disk, referenced by path)

App Store Connect:
  API Key:     ~/.appstoreconnect/private_keys/AuthKey_XXXX.p8
  Issuer ID:   ~/.appstoreconnect/issuer_id.txt
  API Key ID:  XXXX
  Team ID:     XXXXXXXXXX

Google Play:
  Service Account JSON:  ~/Downloads/project-sa.json
  Package Name:          com.yourapp.id

The agent doesn't need these explained. It reads the file,
finds the paths, and uses them.

Build commands

# Android AAB
flutter build appbundle --release

# iOS IPA (codesigned, App Store ready)
flutter build ipa --release

Upload commands

The file includes the exact xcrun altool command for App Store
Connect and the exact fastlane supply command for Google Play —
with all flags, credential paths, and track configuration filled in.

I'm not going to paste them here because they're the core of what
makes the kit worth paying for. But the shape is simple: one CLI
command per store, using credentials already on disk.

That's it. That's the entire deployment pipeline.

Why this works

The key insight is that xcrun altool and fastlane supply
are already command-line tools. They don't need a web UI.
The reason we all use Xcode and Play Console is that
remembering the CLI flags and credential paths is annoying.

But an AI agent doesn't find it annoying. It reads a file,
fills in the variables, and runs the command. The friction
that makes web UIs valuable for humans is zero friction
for an agent.

This is the pattern that makes agent-readable infrastructure
powerful: you don't need to build new tools for agents. You
need to make existing tools readable.

The full release flow

When I want to ship an update, I tell my agent:

"Ship version 1.4.2 with the chat screen fix to both stores."

The agent:

Bumps the version in pubspec.yaml
Runs flutter build appbundle --release
Runs flutter build ipa --release
Runs xcrun altool to upload the IPA
Runs fastlane supply to upload the AAB
Commits the version bump
Pushes to git

Total time: about 15 minutes (most of it is Flutter compiling).
My involvement: one sentence.

What about errors?

The deployment file includes a common errors table:

Error	Fix
Version code already used	Bump build number, rebuild
Bundle version must be higher	Bump build number, rebuild
No signing certificate	Rebuild without `--no-codesign`

When the agent hits an error, it reads the table, applies the fix,
and retries. I've watched it recover from a "version code already
used" error by bumping the build number and re-uploading — without
asking me.

This is where agent-readable instructions beat scripts: the agent
can reason about errors and apply fixes contextually. A script
fails. An agent adapts.

Is this safe?

The credentials never leave your machine. The agent reads files
that are already on disk. No secrets are sent to any API. The
upload commands use Apple's and Google's official CLI tools —
the same tools a CI/CD pipeline would use.

The difference is: instead of putting your secrets in GitHub
Actions or a CI environment, they stay on your machine and
the agent uses them locally.

This is the local-first principle applied to deployment: your
secrets, your machine, your agent.

The pattern: agent-readable infrastructure

The entire setup lives in a single file in my repo:
docs/STORE_DEPLOYMENT.md. Any AI agent — Devin, Claude Code,
Cursor, Windsurf — can read it and deploy.

The file has:

Credential paths (not the secrets themselves)
Build commands
Upload commands
Version bump protocol
Error recovery table
Full copy-paste release flow

I also added a pointer in AGENTS.md so any new agent knows
to read the deployment file first:

The pointer file is a few lines — I include the exact template
in the kit so you can drop it into your repo as-is.

This pattern — a single readable file that any agent can
execute — works for more than just deployment. It works for
any repeatable workflow:

Database migrations
Server provisioning
Incident response
Content publishing
Data pipelines

If a human can do it by following instructions, an agent can
do it by reading them.

What this actually means

I'm not going to pretend this is revolutionary. Fastlane exists.
xcrun altool exists. CI/CD pipelines exist. What's new is the
ergonomics:

No CI/CD infrastructure to maintain
No GitHub Actions billing
No secrets in a third-party environment
Any AI agent can do it by reading one file
It runs on your laptop, not a build server

The deployment pipeline went from "open Xcode, archive, wait,
open Transporter, drag IPA, wait, open Play Console, create
release, upload AAB, wait" to "tell my agent to ship it."

That's not a product. That's a better way to work. And it's
a glimpse of what agent-readable infrastructure makes possible.

This post was deployed by the same AI agent that ships my app
updates. It committed this file, pushed to git, and the site
auto-published. I wrote the words. The agent did the rest.

*The template is now open-source on GitHub: Flutter Store Deployment Kit (MIT, free).

If you want the packaged version with setup guide and support, it's also on Gumroad ($19).*

Launching on Product Hunt on June 30! DeployKit for Flutter — would love your support.

How to connect an MCP server to Cursor, Windsurf, and Gemini

Nucleus OS — Tue, 23 Jun 2026 19:39:34 +0000

Every AI coding editor now supports MCP (Model Context Protocol). But they all have different config file locations, different field names, and different gotchas. Here's the cheat sheet for connecting a remote MCP server to five major editors/clients.

Cursor

Config location: ~/.cursor/mcp.json (global) or .cursor/mcp.json (per-project)

Remote server (Streamable HTTP):

{
  "mcpServers": {
    "nucleus": {
      "url": "https://relay.nucleusos.dev/mcp-readonly",
      "type": "streamableHttp"
    }
  }
}

Gotcha: You must completely quit and restart Cursor after editing the config. MCP servers only load at startup.

UI path: Settings → Tools & MCP → Add new MCP server

Windsurf

Config location: ~/.codeium/windsurf/mcp_config.json (global only — no per-project)

Remote server (Streamable HTTP):

{
  "mcpServers": {
    "nucleus": {
      "serverUrl": "https://relay.nucleusos.dev/mcp-readonly"
    }
  }
}

Gotcha #1: Windsurf uses serverUrl instead of url. If you copy a Cursor config, it silently fails — no error, no connection.

Gotcha #2: The path is .codeium/windsurf/, not .windsurf/.

Gotcha #3: Windsurf supports variable interpolation: ${env:VAR_NAME} and ${file:/path} in config fields.

Google Gemini / Antigravity

Config location: ~/.gemini/config/mcp_config.json

Remote server (Streamable HTTP):

{
  "mcpServers": {
    "nucleus": {
      "serverUrl": "https://relay.nucleusos.dev/mcp-readonly"
    }
  }
}

Gotcha: Gemini Enterprise only accepts Streamable HTTP (not deprecated SSE).

OpenClaw

Config location: ~/.openclaw/openclaw.json under mcp.servers

OpenClaw is both an MCP client and server. You register external servers with openclaw mcp set:

openclaw mcp set nucleus '{
  "transport": "http",
  "url": "https://relay.nucleusos.dev/mcp-readonly"
}'

Gotcha: Registered servers are only consumed by OpenClaw-managed runtimes that read mcp.servers at startup. Not every runtime picks them up automatically.

OpenCode

Config location: Managed via opencode mcp commands

opencode mcp add nucleus --url https://relay.nucleusos.dev/mcp-readonly

For OAuth-protected servers:

opencode mcp add nucleus --url https://relay.nucleusos.dev/mcp
opencode mcp auth nucleus

Comparison table

Editor	Config path	Remote field	Per-project?
Cursor	`~/.cursor/mcp.json`	`url`	Yes (`.cursor/mcp.json`)
Windsurf	`~/.codeium/windsurf/mcp_config.json`	`serverUrl`	No (global only)
Antigravity	`~/.gemini/config/mcp_config.json`	`serverUrl`	No (global only)
OpenClaw	`~/.openclaw/openclaw.json`	`url` (in JSON)	No (global only)
OpenCode	CLI-managed	`--url` flag	No (global only)

The one that catches everyone

If your MCP server works in Cursor but not in Windsurf, check the field name. Cursor uses url, Windsurf uses serverUrl. Same JSON structure, different key. Silent failure, no error message.

If it works in Windsurf but not in Antigravity, check the transport. Antigravity rejects deprecated SSE — it only accepts Streamable HTTP.

Full guides

Building Nucleus — persistent memory for AI coding agents. Open source on GitHub. Install: pip install nucleus-mcp && nucleus-init --scan.

How to give Claude Code persistent memory across sessions with MCP

Nucleus OS — Tue, 23 Jun 2026 19:14:54 +0000

Every Claude Code session starts with amnesia. You explain the architecture. You re-explain the decisions. You re-explain why the auth layer looks the way it does. The model nods, does the work, and the next session forgets all of it.

This isn't a model problem. It's a storage problem. The context window resets, and there's nothing persistent for the next session to read from.

I built an MCP server that fixes this. It's called Nucleus, and it gives any MCP-compatible AI client (Claude Code, Cursor, Windsurf, Gemini) a shared, persistent memory layer.

The problem in one screenshot

You open session 2 to continue work from session 1. Session 2 has never heard of session 1. You spend 10 minutes re-explaining what session 1 already knew.

Multiply that by every session, every day, every project. That's the context-drift tax.

What Nucleus does

Nucleus is an MCP server that exposes a small set of tools for writing and querying persistent memory:

brain_write_engram — Store a decision, architecture note, or any knowledge with a key, value, context tag, and intensity score.
brain_query_engrams — Search stored knowledge by substring, context, or minimum intensity.
brain_audit_log — View the cryptographic interaction log for trust verification.
brain_governance_status — Check the security and compliance state of the brain.

All data lives in a local .brain/ directory — append-only JSONL files. No cloud, no vendor lock-in. Your memory stays on your machine.

Install in 60 seconds

pip install nucleus-mcp
nucleus-init --scan

That's it. nucleus-init creates the .brain/ directory, scans your project for a README.md to seed initial context, and auto-configures your MCP clients (Claude Desktop, Cursor, Windsurf).

Restart Claude Code and the tools are available.

Use it in Claude Code

After install, any Claude Code session can write and read from the shared brain:

# Session 1 — you're deciding on the auth architecture
"Use brain_write_engram to store: key='auth_architecture', value='Using OAuth 2.1 with PKCE. Refresh tokens in httpOnly cookies. No server-side sessions.' context='Architecture' intensity=8"

# Session 2 — next day, new context window
"Use brain_query_engrams to search for 'auth' with min_intensity=5"

Session 2 gets back the decision from session 1 without you re-explaining it. The engram persists across sessions, across tools, across machines (if you sync the .brain/ directory).

Why this matters

The context window is not memory. It's short-term recall. Real memory persists when the window resets.

Every AI coding tool has this problem. Claude Code, Cursor, Windsurf, Gemini CLI — they all start each session with zero context. The model is the same. The capabilities are the same. But the knowledge of what you decided yesterday is gone.

Nucleus makes that knowledge durable. One .brain/ directory, shared across all your AI tools, persisted across sessions.

Multi-agent coordination

If you run multiple AI agents (Claude Code + Cursor, or two Claude Code sessions on different parts of the codebase), Nucleus gives them a shared memory. Agent A writes a decision. Agent B reads it. No message queue, no orchestration framework — just a shared file.

The sync tools handle multi-machine coordination:

brain_sync_now — Manually trigger a sync
brain_sync_status — Check sync state and conflicts
brain_identify_agent — Register an agent's identity for attribution

Security model

Nucleus has a hypervisor subsystem that provides OS-level file protection:

lock_resource — Lock a file/folder to prevent modification (uses BSD chflags uchg on macOS)
watch_resource — Monitor a file/folder for unauthorized changes
set_hypervisor_mode — Visual context switching (red/blue/reset)

All operations are logged to a tamper-evident audit log with SHA-256 hashing. The brain_audit_log tool lets you verify the integrity of the interaction history.

What's on PyPI vs what's in the full server

The public nucleus-mcp package on PyPI has 8 tools (memory + governance + hypervisor). The full hosted server at relay.nucleusos.dev has 17 tools including relay coordination, cost routing, and multi-tenant support.

For local-first usage, the PyPI package is all you need. The hosted server is for teams and multi-agent coordination at scale.

Try it

pip install nucleus-mcp
nucleus-init --scan

Then restart Claude Code and ask it to store a decision. You'll see it persist to .brain/engrams/ledger.jsonl. Open a new session, query it back. That's the whole pitch.

PyPI: nucleus-mcp
GitHub: eidetic-works/nucleus-mcp
Docs: eidetic.works

Building in public. The MCP server is open source. The hosted coordination layer is the business. If you're running AI agents seriously, this is the memory layer you're missing.

Eidetic Works Pro is live: persistent memory for your AI agents, $29/mo

Nucleus OS — Fri, 19 Jun 2026 03:28:07 +0000

I just shipped Pro tier for Eidetic Works. Here's what's in it, who I built it for, and why I'm shipping three tiers ($29 / $99 / $299) instead of a single plan.

What problem does this actually solve?

You're running Claude Code. You have two or three sessions open across different parts of the codebase. Session 2 doesn't know what Session 1 decided. You end up re-explaining the same architecture decisions to the same model you already talked to yesterday.

This is the context-drift problem. It doesn't come from the model being bad. It comes from each session starting with no memory of what came before.

nucleus_ask — the MCP tool at the center of Pro — lets any agent call into your shared engram store and pull context that persists across sessions, across tools, and across machines.

What's in Pro

Managed R2 sync. Your engrams live in SQLite on your machine. Pro backs them to a Cloudflare R2 bucket with zero config. Your keys, your bucket — I'm not storing your AI history on my infrastructure.

nucleus_ask recall. The MCP primitive your agents use to query the shared store. One call, structured results. Wire it into your MCP config once and every session gets recall.

Customer dashboard. Sync health, engram counts, last-seen surfaces. Not glamorous. Just the visibility you need to confirm it's working.

Email support. Direct line. Not a help-center chatbot.

60-second restore. New machine. One command. Full engram history back, including decisions from six months ago that your codebase assumes you remember.

Three tiers

Pro $29/mo — single seat. Managed sync, recall MCP, dashboard, email support.
Pro+ $99/mo — 3 seats. Same features, team-shared engram store.
Team $299/mo — 10 seats. Same features at team scale. Priority support.

All three live at eidetic.works/pricing right now. Stripe checkout, monthly billing, cancel anytime.

Who I built it for

Devs running Claude Code seriously. If you use it daily, you're accumulating context that the next session can't access. That's the gap Pro closes.

Cursor and Windsurf power users who want recall that survives a project switch or a context-window flush.

Small teams where two people use different AI tools but need shared context. One person on Claude Code, one on Cursor — nucleus_ask lets both pull from the same store.

What's actually shipped (not vaporware)

nucleus-mcp 1.13.2 is live on PyPI right now. nucleus_ask, recall_activity, and recent_engrams are all in 1.13.2. Install, point at your daemon, wire your MCP config.

The OAuth arbitrage pattern is running in production at oauth.nucleusos.dev. If you haven't seen it — I wrote about the shim pattern here. Anthropic Max plan OAuth as a shared API surface, zero per-token cost for qualified setups. It's the same infra that powers Pro's daemon coordination.

Pro is a billing tier on top of substrate that's already running. I'm not shipping a waitlist — I'm shipping a checkout.

The governance angle

This is the part most "AI memory" tools skip.

Your agent coordination context should not live inside any single vendor's cloud. Lock-in on AI tooling is bad enough. Lock-in on the memory layer that coordinates your AI tooling is worse.

Pro's sync is your Cloudflare R2 bucket, your API keys. I hold none of it. The engram format is open SQLite. You can export everything as NDJSON any time via GET /export. The Pro subscription pays for managed worker infra and support, not for access to your own data.

This is not a differentiator claim. It's a design constraint I'm not willing to drop for growth.

What's not in Pro yet

No hosted daemon — your machine runs the daemon. I don't want to be in the business of hosting compute for something designed to be local-first.

No cross-org engram sharing — by design. Governance first.

I'll add surface area as real usage patterns surface. Early adopters will shape the roadmap.

How to get started

eidetic.works/pricing — checkout for any of the three tiers.

If you're already running nucleus-mcp, upgrade to 1.13.2 from PyPI. nucleus_ask is there now. The Pro tier unlocks managed sync and the dashboard on top.

If you're new: install the daemon (pip install nucleus-mcp), run eideticd -init, configure your MCP client, then upgrade to Pro once you've confirmed recall is working locally. Don't buy Pro until you've seen local recall work first — that's the foundation.

Building this in public. Numbers, failures, and what breaks first — all of it goes on @nucleusos.

Running Claude Code at zero per-token cost: the Max-plan OAuth shim pattern

Nucleus OS — Thu, 18 Jun 2026 10:12:05 +0000

If you're running Claude Code or any agentic system that calls the Anthropic Messages API, you're probably paying per token. For light use, that's fine. For multi-agent systems with parallel workloads, it adds up fast.

There's a different model: Claude Max subscription. Flat monthly cost, no per-token billing. The problem is that Max exposes a browser OAuth flow, not an API key. Your agent code expects ANTHROPIC_API_KEY. Max doesn't give you one.

We built a shim that bridges the two.

What it is

oauth.nucleusos.dev is an HTTP wrapper that exposes the Anthropic Messages API endpoint at /v1/messages. Internally, it routes each request through a Max-plan OAuth bearer token instead of an API key. The interface is 1:1 with the native Anthropic API.

To use it, set two environment variables in your agent:

ANTHROPIC_BASE_URL=https://oauth.nucleusos.dev
ANTHROPIC_API_KEY=<your-shared-secret>

Your existing Claude Code installation, any Claude SDK wrapper, or raw HTTP client keeps working without code changes. The billing model changes; the interface doesn't.

The wire shape

Each incoming request hits an HMAC-validated gate (the ANTHROPIC_API_KEY value you set is treated as a shared secret, compared with hmac.compare_digest — no timing oracle). Valid requests get the Bearer token substituted and are forwarded to api.anthropic.com. The response streams back unchanged.

Security model: the shim trusts whoever holds the shared secret. This is for personal or team use — not for handing out to arbitrary clients. If you're running it on a VPS for your own agent fleet, that's the threat model it's designed for.

Smoke test results (actual, not synthetic)

GET /health → 200 {"status": "ok"}
Wrong shared secret → 401
Valid request to /v1/messages with a real Claude model → returned actual Anthropic response shape, usage: {"input_tokens": 17, "output_tokens": 6}

What we added after the initial ship

The initial PR (#578, 2026-06-16) covered Claude only. Subsequent PRs added:

Gemini API routing on a separate port (8890) — same deployment, same auth model, second provider. One shim, Claude + Gemini.
Non-root Dockerfile (USER nobody) — the initial container ran as root, caught in review.
_HTTP_TIMEOUT_S bumped to 600 — the default 300s timeout was clipping long agent runs. Opus calls on complex prompts run long; you need the headroom.
gemini_keys.txt env override — you can bake a key file into the image for air-gapped deployments.

Current deployment: OCI A1 ARM (24GB, Mumbai). CPU is the binding constraint on this instance, not RAM.

The cost math

Claude Max subscription: $100/month (Pro tier) or $200/month (Max tier with higher usage limits).

Anthropic API comparison for equivalent workloads depends heavily on your token mix. For a team running Claude Code across multiple parallel sessions with shared context, API costs can exceed $200/month easily. The breakeven calculation is specific to your token volume.

We're not publishing specific numbers because our workload (5 AI agents, agentic coding sessions, multi-file context) may not generalize to yours. The pattern is worth knowing; the math is worth running against your own usage.

What this isn't

This isn't a production multi-tenant API. It's a single-org shim. If you need rate-limiting, per-user billing, or audit logs, you need more infrastructure than this.

It also doesn't give you higher rate limits than Max plan imposes. If you're hitting Max-plan throttles under heavy load, the shim won't help.

Self-hosting

The Dockerfile and compose file are in the repo. The README covers the non-root deployment, env vars, and the gemini_keys.txt override.

The shim is ~200 lines of Python (FastAPI). Not a framework. Inspectable in an afternoon.

Why we built it in-house

We're building Eidetic Works on our own agentic substrate. Claude Code is the primary execution surface. Token costs are a real operational cost for us, not a theoretical one. The shim was born from a direct cost problem, not from wanting to build infrastructure.

The telemetry endpoint we shipped in the same cohort (eidetic.works/api/telemetry/metrics) is what lets us measure whether it's working — we can now count daemon installs without relying on download counts or manual surveys.

What's next

The Gemini routing is v1 — it works but hasn't been load-tested under the same conditions as the Claude path. The next substantive addition is probably a structured logging layer so we can see which models are taking which paths at what latency. Right now it's effective but opaque.

If you build on this pattern, drop a comment below — interested in what you add.

Read more on what we're building at eidetic.works

I shipped 6 versions of my Claude Code memory daemon in 36 hours — here's what changed and why

Nucleus OS — Wed, 20 May 2026 15:10:35 +0000

Two days ago I had a daemon that captured Claude Code session JSONLs and let you grep them. Today it has cloud sync, hot-reload, AI-powered recall via MCP, a web dashboard, and a $99 team tier.

This is the changelog, why each ship happened, and what it tells you about what users actually want from a "memory layer" tool.

The setup

eidetic-daemon ships at github.com/eidetic-works/eidetic-daemon. ~3K lines of Go. Captures every Claude Code session JSONL via fsnotify, stores in SQLite with FTS5, exposes over UDS + MCP. Free + MIT. The premium tier ($29/mo Pro, $99/mo Team) adds managed Cloudflare R2 sync.

Two days ago I had 277K engrams from my own sessions across 8 months. I'd shipped the free distribution (Homebrew tap, dev.to article, X replies). The conversion bottleneck was Pro onboarding friction: "drop sync.json, restart daemon, hope it works" was 3 steps too many.

Here's the 6-ship sprint, oldest first.

v0.0.32: `--restore` flag

eideticd --restore
# ✓ Downloaded 3.3 MB engrams.db from cloud backup
# key: engrams/macbook-m2/engrams-1748300000000.db
# previous db saved to ~/.eidetic/engrams.db.bak
# restart eideticd to use the restored database

The landing copy promised "restore on a new machine in 60 seconds." The implementation didn't exist yet — I'd shipped the upload path but never the download. So I built the Worker /download endpoint, the RestoreFromConfig Go function (runs before store.Open to avoid SQLite write-lock contention), and atomic file replacement with .bak backup.

3 tests. ~80 LOC. Cost: 45 minutes. Lesson: don't put copy on your landing page that doesn't have a curl behind it.

v0.0.33: sync-state persistence

After --sync-now ran successfully, you had no way to tell when it last fired. The daemon forgot across restarts. --stats now shows a cloud sync block:

  cloud sync:
    last sync:  2026-05-20 09:13:42
    last key:   engrams/macbook-m2/engrams-...
    last size:  3.3 MB

State persists to sync-state.json in dataDir, atomic write (tmp → rename, 0600). Cost: 20 minutes.

v0.0.34: `eideticd --check`

This is a Pro-onboarding-debug tool. New customer drops sync.json, daemon doesn't sync, customer emails support. What's the first thing I want them to run?

$ eideticd --check
eideticd v0.0.34 — sync check

  worker_url: https://eidetic-sync.morning-lake-f944.workers.dev
  device_id:  customer-mac-01
  interval:   60 min (default)
  worker:     ✓ reachable (200 OK)
  last sync:  2026-05-20 09:13 (3m ago)

  status: ✓ sync healthy

If the worker's down: worker: ✗ unreachable: .... If the key's wrong: worker: ✗ auth failed (401). Exit code 1 on failure so you can script it.

Cost: 30 minutes. The cheapest customer support feature is one that prevents the ticket.

v0.0.35: sync.json hot-reload

This was the friction killer. Before: drop sync.json → launchctl kickstart -k gui/$(id -u)/works.eidetic.eideticd. After: drop sync.json, done.

fsnotify on the dataDir, 300ms debounce, dynamically swap the Syncer behind an RWMutex. Initial upload fires automatically to confirm.

sync: hot-reload — config applied (worker=https://eidetic-sync.morning-lake-f944.workers.dev device=macbook-m2)
sync: hot-reload initial upload complete

Lesson: the step you ask the user to do "just once" is the one they get wrong. Remove the step.

v0.0.36: `--backups` history

You can't trust a backup you can't see. SyncState got a ring buffer (last 10 uploads), --backups prints them:

$ eideticd --backups
eideticd v0.0.36 — cloud backup history

  2026-05-20 09:13  engrams/macbook-m2/engrams-...  (3.3 MB)
  2026-05-20 08:13  engrams/macbook-m2/engrams-...  (3.3 MB)
  2026-05-20 07:13  engrams/macbook-m2/engrams-...  (3.3 MB)
  ...

Ring buffer cap, newest first, atomic write. 1 new test verifies the cap. Cost: 25 minutes.

v0.0.5 (MCP) + v0.0.38 (HTTP): nucleus_ask

This is the killer feature. The landing copy promised "AI-powered recall coming soon." This is it.

# From any MCP client (Claude Code, Cursor, Cline):
nucleus_ask(question="What was that Postgres trick I learned last week?")

The tool extracts keywords from the question (stop-word stripped, OR-joined), retrieves top-10 engrams via FTS5, returns them wrapped in answer-scaffolding:

{
  "question": "What was that Postgres trick I learned?",
  "fts_query": "postgres OR trick OR learned",
  "instructions": "You are answering the question above using ONLY the engram excerpts below. Cite the surface + timestamp when you reference one. If the engrams don't answer the question, say so honestly — do NOT fabricate.",
  "engrams": [...]
}

The "AI" is the host LLM (your Claude Code session). Your engrams never leave your machine. No external API calls, no embeddings service, no GPU. Just FTS5 retrieval + careful prompt framing.

I also exposed it as GET /ask?question=... on the daemon's HTTP API so the web dashboard (next ship) can call it without MCP.

7 unit tests on the keyword extraction. 4 HTTP integration tests. Total cost: ~3h including the dashboard wiring.

Bonus: the web dashboard

Single-page Astro at /dashboard. Paste your bridge URL + bearer token. Browse engrams, search, filter by surface. localStorage-persisted creds (never POSTed anywhere). Talks only to your daemon — no proxy.

What I learned shipping 6 versions in 36 hours

Every gap between "landing promises" and "code works" loses you the customer. Don't write copy you can't ship in 48h.
The cheapest support ticket is one you prevent. --check will save me hours.
The "just once" step is the friction. Hot-reload was the highest-leverage ship — it removed the moment a customer thinks "is this thing even on?"
AI features don't need an LLM call. Retrieval + prompt framing is 90% of the value. The user's host LLM does the synthesis. Bonus: your data stays local.
Tests are cheap. All 6 ships have integration coverage. I haven't introduced a regression yet.

If you want to try it: brew tap eidetic-works/nucleus && brew install eideticd && eideticd -install and you're capturing in 30 seconds.

If you want cloud sync: there's a $29/mo Pro tier at eideticworks.gumroad.com/l/eidetic-pro. First 50 keep this price forever.

Either way, the source is at github.com/eidetic-works/eidetic-daemon. PRs welcome.

— Lokesh / Eidetic Works

I got tired of losing Claude Code context between sessions, so I built a daemon

Nucleus OS — Tue, 19 May 2026 01:06:52 +0000

Every time I closed a Claude Code session, the conversation was gone.

Not archived. Not searchable. Just gone.

I'd start a new session and spend the first 10 minutes re-explaining context I'd just worked through. The "Summarize our last conversation" prompt only goes so far when you've had 300 sessions across 8 weeks.

So I built a fix.

What `eideticd` does

It's a Go binary that runs at login (launchd on macOS, systemd on Linux). It uses fsnotify to tail Claude Code session files in real time. Every message you type becomes an engram — a row in a local SQLite-WAL database — within <50ms of the file write.

Nothing leaves your machine.

# One-liner install
curl -fsSL https://eidetic.works/install.sh | sh

# Or Homebrew
brew tap eidetic-works/nucleus
brew install eideticd

The numbers that matter

After 2 weeks of dogfooding on my own machine:

141,502 engrams captured across sessions
P95 retrieval: 0.27ms on that live dataset
SLO was 100ms — we cleared it by 370×
Capture latency: <50ms on all measured writes

MCP bridge — let your AI query its own history

The companion Python package exposes the daemon's Unix socket API as MCP tools:

pip install eidetic-mcp
claude mcp add eidetic -- python -m eidetic_mcp.server

After that, you can ask Claude Code:

"What was I debugging last Tuesday?"

And it pulls from your engrams in <1ms. No cloud, no API key, no subscription.

Architecture decisions worth knowing

Pure-Go SQLite via modernc.org/sqlite — not the CGO mattn/go-sqlite3. This matters for distribution: CGO + cross-compile silently strips SQLite and produces a binary that crashes at runtime. The pure-Go driver cross-compiles cleanly to darwin-arm64, linux-amd64, and windows-amd64 from a single host. I learned this the hard way.

WAL mode mandatory — PRAGMA journal_mode=WAL; synchronous=NORMAL is the only mode that gives concurrent readers without blocking the writer. Write-append-only shape + single-writer pool (SetMaxOpenConns=1) + separate read pool (8 conns) = zero "database is locked" errors under load.

FTS5 full-text index — AFTER INSERT/DELETE triggers maintain a full-text index on the content column. Boolean operators, phrase queries, relevance ranking — all the SQLite FTS5 goodness, sub-millisecond.

Single binary, no daemon manager required — eideticd -install writes the launchd plist and bootstraps it. Uninstall is eideticd -uninstall. No Docker, no Python runtime, no config files to manage.

What shipped in v0.0.25 (this week)

Compliance daemon (eideticd-compliance): reads a retention-policy.json, purges engrams older than the configured TTL per surface, writes an audit log, exits. Designed for cron/launchd/systemd timer.
PyPI package: pip install eidetic-mcp — the MCP bridge is now a proper PyPI package, not a pip install -e from source.
Homebrew formula: brew tap eidetic-works/nucleus && brew install eideticd

Try it

curl -fsSL https://eidetic.works/install.sh | sh

Source: github.com/eidetic-works/eidetic-daemon (MIT)

Happy to answer questions about the SQLite design, the fsnotify watcher, or the retention system.

I built a Sovereign Control Plane for AI agents (MCP) 🧠

Nucleus OS — Tue, 24 Feb 2026 16:29:51 +0000

The Sovereign Pivot

Most AI agents today are 'black box' operators and cloud-dependent. After seeing 1.5M API keys leaked from similar tools, I decided to build a strictly local-first control plane.

Nucleus MCP (v1.3.0) is that bridge.

Why this matters:

Persistent Engrams: Knowledge that actually survives context windows and session restarts.
Hypervisor Governance: Real-time file locking and budget enforcement.
Forensic Audit: Every tool call is logged in a cryptographically signed ledger.

We just open-sourced the latest version. Check the raw terminal execution in the video above.

The goal isn't just 'autonomy'—it's 'auditable autonomy'.

Repository: github.com/eidetic-works/mcp-server-nucleus

mcp #ai #opensource #devshowcase

Building the Agentic Brain: Audits, Engrams, and Morning Briefs

Nucleus OS — Sun, 22 Feb 2026 02:24:32 +0000

In 2026, the "Agentic Era" is in full swing, but we have a fundamental trust problem: AI Agents are black boxes.

When you're running a swarm of agents locally, you need more than just "memory." You need a Sovereign Control Plane. You need a system that ensures your data never leaves your machine, while providing you with absolute visibility into every decision your agents make.

We call this the Agentic Brain.

The Problem: Session Amnesia & Context Poisoning

Most agent frameworks either lose their state after the terminal closes (Session Amnesia) or sync your private project data to a centralized cloud where you lose control (Context Poisoning).

If you're building a security-first application, neither is acceptable.

The Solution: Nucleus MCP

Nucleus is a local-first Model Context Protocol (MCP) server designed to be the persistent cerebral cortex for your agents. It solves the trust gap through three core pillars:

1. Persistent Engrams (Local-First Memory)

Instead of volatile state, Nucleus maintains Engrams—context-aware memory units that persist across IDE sessions. Whether you're in Cursor, Windsurf, or a raw terminal, your agent remembers your previous architectural decisions and project lore.

2. The Sovereign Hypervisor

Every tool invocation is mediated by a Hypervisor. This layer enforces governance, ensuring that a "Researcher Agent" can't suddenly start modifying your production ENV files or making unauthorized internet calls.

3. Forensic Audit Trails

Transparency is the only path to trust. Nucleus generates a cryptographically signed Audit Trail of every single orchestration. If an agent makes a mistake, you don't just see the error—you see the forensic chain of events that led to it.

See it in Action

We’ve consolidated our core proof points into two "Forensic Demos."

Example 1: The Intern Who Acts (Execution Proof)

Watch Nucleus orchestrate a multi-agent campaign from a single line of intent. Pay attention to the Narrative Ledger—it tracks every thought, tool call, and result in a human-readable, auditable format.

Example 2: The Morning Brief (Memory Proof)

This is the "Life Proof" of an agentic system. Every morning, Nucleus uses its persistent engrams to orientate you. It knows what happened yesterday, what the blockers are, and what the next strategic leap is.

Join the Sovereign Mission

We're building the infrastructure for agents that you can actually trust. No telemetry. No cloud required. 100% Sovereign.

Repo: github.com/eidetic-works/nucleus-mcp
Install: pip install nucleus-mcp

What are you building with MCP? Let's talk about agent governance in the comments.

The $1,000 OpenClaw Token Burn (and How Local Engrams Fix It)

Nucleus OS — Tue, 17 Feb 2026 17:21:09 +0000

Why OpenClaw Needs "Local Engrams" (and Why Cloud RAG is Too Slow)

AI agents are finally actually doing things on our desktops. The OpenClaw wave (204k stars 🦞) is proof that local agentic workflows are the future. But there's a problem every developer is hitting: Context Amnesia.

And it's not just a technical glitch—it's financially expensive.

The $1,000 Token Burn

Recent reports show that high-volume users are burning through $1,000 in a single week just on tokens.

Why? Because when your agent "forgets" session state or file context from 5 minutes ago, it has to re-read, re-embed, and re-process the entire block.

Amnesia is a tax on builders.

The Benchmark: How it's Proven

Dhravya Shah (Supermemory) recently released MemoryBench, using the LongMemEval-S framework. This is the new "Gold Standard" for agentic memory.

The data shows why standard context is failing:

Baseline (Full Context): Scored only ~20% accuracy on session-bridging tasks.
Top Memory Layers (Supermemory): Scored ~88.4%.
Nucleus (Local SQLite): Scored 100.0% (Deterministic Recall).

This is what we call the "Architectural Ceiling." By moving to a structured engram layer—whether cloud-based like Supermemory or local-first like Nucleus—you bridge this 68-point gap.

Nucleus: Local Parity @ 38x Speed

We built Nucleus-MCP to offer architectural parity with the highest memory benchmarks, but with local-first performance. While cloud-based graph/vector stores are limited by the LLM's context window and network RTT, Nucleus uses a local cognitive loop that eliminates amnesia entirely.

The Results (Nucleus vs. Cloud RAG)

Metric	Cloud Vector (RAG)	Nucleus (Local SQLite)	Gain
Avg Latency	~294ms	7.7ms	38x Faster
Recall Accuracy	~70% (Baseline)	100.0% (Deterministic)	Absolute Precision
Persistence	Session-based / Cloud	Forever / Local	Data Sovereignty

The Technical "Why"

Cloud RAG requires:

Embedding generation (Network + API)
Vector Database search (Remote)
Context Re-insertion (Network)

Nucleus uses Local Engrams:

SQLite lookups on your own disk (O(1) retrieval for exact context keys).
Zero network latency.
Instant tool-state recall.

Stop paying for amnesia. If you're building with OpenClaw, you don't need a cloud vector store to fix a leaky bucket. You just need a local cognitive layer.

Nucleus-MCP is live on Product Hunt! Check it here: [producthunt.com/posts/nucleus-mcp]

Engrams & SQLite: Solving AI Context Amnesia with Nucleus-MCP Tags: AI, SQLite, Productivity, Open Source

Nucleus OS — Tue, 17 Feb 2026 15:14:37 +0000

Why do our local AI agents (Cursor, Windsurf, Claude) forget everything? Because we're treating cognitive memory like throwaway logs.

I just released v1.0.7 of Nucleus-MCP—a sovereign command deck for AI agents. It implements a local-first memory model that doesn't rely on cloud intermediates.

We launched on Product Hunt today to see if there's interest in a "Local Data First" future. We're at #86—likely because we aren't another 'AI Chat wrapper.'

I’m looking for technical critics who want to rip into the architecture.

Launch Link: https://www.producthunt.com/products/nucleus-mcp

Why We Abandoned Cloud Memory for Local Sovereignty

Nucleus OS — Sun, 15 Feb 2026 11:08:14 +0000

Why We Abandoned Cloud Memory for Local Sovereignty

AI agents are getting smarter, but they still suffer from "amnesia" between tools. To fix this, several "memory-as-a-service" platforms have popped up.

I tested the leading cloud solutions for a month. They are polished. They are fast. But for serious engineering, they hit a wall. Here is why we pivoted to Nucleus MCP — a 100% local-first alternative.

1. The Trust Gap (Sovereignty is Binary)

Cloud memory providers ask you to trust their servers with a stream of your architectural secrets, terminal logs, and business logic. In the age of "Sleeper Agents" and API leaks, trust is no longer a viable security policy.

With Nucleus, there is no signup. There is no cloud. Your memory (Engrams) stays in a .brain/ folder in your repo. If it's not on your hardware, it's not sovereign.

2. Git-Native Context

In a cloud database, your agent's memory is a monolith. In Nucleus, it's version-controlled.

Branching: When you branch your code, your agent's "learnings" branch with you.
Persistence: Look at a commit from 6 months ago, and you can see exactly what the agent "knew" at that point in time.

3. Hypervisor vs. "Dashboards"

Most platforms give you a "dashboard" of what the agent did. That's visibility, not control.
Nucleus provides Governance. Our Hypervisor uses OS-level primitives (like chflags uchg) to enforce safety. If you lock a file, the agent cannot change it. Period. It's security enforced at the kernel level, not the application level.

4. Zero Latency (LLM-at-Home Speed)

Local-first means retrieval happens at NVMe speeds (milliseconds), not over a round-trip to a SaaS backend. When you're running complex multi-agent swarms, those round-trips add up to heavy friction.

The Verdict

Cloud portals are great for collaboration. But for the Sovereign Developer, your brain deserves its own hardware.

Nucleus MCP is MIT licensed and open source. Stop being a tenant in someone else's cloud and start building your own agentic control plane.

👉 Get Started on GitHub

Built for the AI-native builder who refuses to compromise on security.

DEV Community: Nucleus OS

AI Agents Can Ship to Production: A Deployment Case Study

The setup

Credentials (stored on disk, referenced by path)

Build commands

Upload commands

Why this works

The full release flow

What about errors?

Is this safe?

The pattern: agent-readable infrastructure

What this actually means

How to connect an MCP server to Cursor, Windsurf, and Gemini

Cursor

Windsurf

Google Gemini / Antigravity

OpenClaw

OpenCode

Comparison table

The one that catches everyone

Full guides

How to give Claude Code persistent memory across sessions with MCP

The problem in one screenshot

What Nucleus does

Install in 60 seconds

Use it in Claude Code

Why this matters

Multi-agent coordination

Security model

What's on PyPI vs what's in the full server

Try it

Eidetic Works Pro is live: persistent memory for your AI agents, $29/mo

What problem does this actually solve?

What's in Pro

Three tiers

Who I built it for

What's actually shipped (not vaporware)

The governance angle

What's not in Pro yet

How to get started

Running Claude Code at zero per-token cost: the Max-plan OAuth shim pattern

What it is

The wire shape

Smoke test results (actual, not synthetic)

What we added after the initial ship

The cost math

What this isn't

Self-hosting

Why we built it in-house

What's next

I shipped 6 versions of my Claude Code memory daemon in 36 hours — here's what changed and why

The setup

v0.0.32: --restore flag

v0.0.33: sync-state persistence

v0.0.34: eideticd --check

v0.0.35: sync.json hot-reload

v0.0.36: --backups history

v0.0.5 (MCP) + v0.0.38 (HTTP): nucleus_ask

Bonus: the web dashboard

What I learned shipping 6 versions in 36 hours

I got tired of losing Claude Code context between sessions, so I built a daemon

What eideticd does

The numbers that matter

MCP bridge — let your AI query its own history

Architecture decisions worth knowing

What shipped in v0.0.25 (this week)

Try it

I built a Sovereign Control Plane for AI agents (MCP) 🧠

The Sovereign Pivot

Why this matters:

mcp #ai #opensource #devshowcase

Building the Agentic Brain: Audits, Engrams, and Morning Briefs

The Problem: Session Amnesia & Context Poisoning

The Solution: Nucleus MCP

1. Persistent Engrams (Local-First Memory)

2. The Sovereign Hypervisor

3. Forensic Audit Trails

See it in Action

Example 1: The Intern Who Acts (Execution Proof)

Example 2: The Morning Brief (Memory Proof)

v0.0.32: `--restore` flag

v0.0.34: `eideticd --check`

v0.0.36: `--backups` history

What `eideticd` does