Forem: Delimit.ai

I Tested Every 'Memory' Solution for AI Coding Assistants - Here's What Actually Works

Delimit.ai — Sun, 05 Apr 2026 01:19:56 +0000

Every AI coding session starts from scratch. You open Claude Code or Codex, and it has no idea that your team uses JWT with 15-minute expiry, that you migrated from REST to GraphQL last month, or that the payments service is the one thing you never touch on Fridays. You re-explain the same architecture decisions, the same conventions, the same constraints. Every single time.

This is not a minor annoyance. It is compounding time loss. The first 5-10 minutes of every session is wasted on context that the assistant already learned yesterday. Over weeks, that adds up to hours. I went looking for solutions and tested everything I could find.

What I Tried

a) Obsidian Mind (574 stars on GitHub)

Obsidian Mind is an Obsidian vault template that gives Claude Code persistent memory. It works by loading vault context through CLAUDE.md on session start. You get slash commands like /standup and /dump to interact with your knowledge base.

It is genuinely elegant if you already live in Obsidian. The setup is minimal, the vault structure makes sense, and the community around it is active. For pure Claude Code workflows, it does the job well.

The limitation: it only works with Claude Code. If you switch to Codex for a background task or try Gemini CLI for a second opinion, your memory stays locked in the Obsidian vault. You also need Obsidian installed, which is a non-trivial dependency if your team does not already use it.

b) Claude Code's Built-in Memory

Claude Code writes MEMORY.md files automatically to ~/.claude/. Zero setup required. It happens in the background as you work, capturing things the model thinks are important.

The convenience factor is real. You do not configure anything, and it just starts remembering. For solo Claude Code users who never switch tools, this might be all you need.

The limitations are predictable: it only works inside Claude Code, the memories are unstructured free text, there is no search, and nothing carries over to other assistants. You also have no control over what gets saved or how it is organized.

c) Custom CLAUDE.md / instructions.md Files

The manual approach. You maintain a context file that each tool reads on startup. Claude Code reads CLAUDE.md, Codex reads AGENTS.md, Gemini CLI reads GEMINI.md. You write your architecture decisions, conventions, and constraints by hand.

This works everywhere because every tool supports some form of instruction file. You have complete control over the content. Nothing is hidden, nothing is auto-generated.

The cost is maintenance. You are now a documentation writer for your AI assistants. Files diverge between tools. You forget to update one. The Codex file says you use REST, the Claude file says GraphQL. Nobody catches it until something breaks.

d) Delimit remember/recall

This is what I built. Delimit stores memories in ~/.delimit/memory/ as structured entries with auto-generated tags. The same memory pool is accessible from the CLI and from any AI assistant that supports MCP.

npx delimit-cli remember "JWT expiry is 15min, refresh tokens are 7 days"
npx delimit-cli recall jwt

The remember command saves a tagged entry. The recall command searches across all your memories with fuzzy matching. The MCP server exposes the same store through delimit_memory_store and delimit_memory_search, so Claude Code, Codex, Gemini CLI, and Cursor all read from and write to the same pool.

Memory is actually just one feature. Delimit is an API governance tool (breaking change detection, policy enforcement, CI integration), and the memory system exists because cross-session context turned out to be a prerequisite for reliable governance. You get both.

The limitation: it is newer and less battle-tested than Obsidian Mind's vault approach. The community is smaller. If you want a rich, interlinked knowledge graph, Obsidian Mind's vault structure is more sophisticated.

Comparison

Feature	Obsidian Mind	Built-in Memory	Manual Files	Delimit
Claude Code	Yes	Yes	Yes	Yes
Codex	No	No	Yes	Yes
Gemini CLI	No	No	Yes	Yes
Cursor	No	No	Yes	Yes
Zero config	Yes	Yes	No	Yes
Structured search	No	No	No	Yes
Auto-tagging	No	No	No	Yes
API governance	No	No	No	Yes
Requires Obsidian	Yes	No	No	No

When to Use What

If you are all-in on Claude Code and already use Obsidian for your notes, Obsidian Mind is the right choice. It fits naturally into an existing workflow and the vault-based approach gives you rich, interlinked context that a flat memory store cannot match. Do not switch away from something that works.

If you use multiple AI assistants, or if you want governance tooling alongside memory, Delimit is built for that. One memory pool, every tool reads it. If you want maximum control and do not mind maintaining files by hand, the manual approach is honest work. It scales poorly, but it never surprises you.

Try It

npx delimit-cli remember "your first memory"
npx delimit-cli recall

No install required. Memories persist in ~/.delimit/memory/ and are available to any MCP-compatible assistant.

Switch AI Coding Assistants Without Losing Context

Delimit.ai — Sat, 28 Mar 2026 14:44:46 +0000

I was deep in a refactor in Claude Code when it hit rate limits. Twenty minutes of context — the task list, the decisions I'd made about the approach, the governance state of the API changes — all trapped in a conversation I couldn't continue.

I opened Codex to keep working. It had no idea what I was doing. I spent 15 minutes re-explaining the task, the constraints, the decisions already made. Then Codex hit its own limit, and I opened Gemini CLI. Same story. Start over. Re-explain. Lose momentum.

This happens every day to anyone using more than one AI coding assistant.

The problem is architectural

Each AI assistant stores context in its own conversation window. When that window ends — rate limit, crash, session timeout, or just opening a different tool — the context is gone. There's no shared layer.

It's like having three developers on a team with no issue tracker, no shared docs, and no standups. Each one knows what they worked on. None of them know what the others did.

Shared state on disk

Delimit stores everything in ~/.delimit/ — plain files on your local machine, not in any model's context window. Task ledger, governance rules, memory, deliberation history. When you switch from Claude Code to Codex to Gemini CLI, they all read and write the same state.

Here's what that looks like in practice:

# In Claude Code:
> "add to ledger: refactor auth module"
  LED-042 created

# Claude hits rate limit. Switch to Codex:
> "what's on the ledger?"
  LED-042: refactor auth module [open]

# Need a second opinion. Open Gemini CLI:
> "review LED-042 approach — JWT vs session tokens?"
  Reading LED-042 context... recommending JWT with refresh tokens

Three assistants. One shared workspace. No re-explaining.

What carries across models

Task ledger — Every open item, its priority, notes, and completion status. Any assistant can create, update, or close tasks. The ledger is the source of truth, not any single conversation.

Governance state — API policies, breaking change history, security audit results. If Claude Code ran a lint check and found issues, Codex can see those results without re-running the check.

Memory — Project decisions, architectural notes, user preferences. Stored once, accessible from every assistant. You tell Claude "we use PostgreSQL, not MySQL" and Gemini CLI knows it too.

Deliberation history — When you ask multiple AI models to debate a decision (JWT vs sessions, monorepo vs polyrepo, REST vs GraphQL), the transcript and consensus are stored. Any assistant can reference past deliberations.

No extra API cost

This is important: Delimit doesn't proxy your requests or add another API in the middle. If you pay for Claude Pro, Codex, or Gemini, Delimit uses your existing CLI installations. It's a local layer that coordinates between them — not a service that sits in the request path.

The only exception is deliberation, where Delimit calls multiple model APIs to get consensus on a decision. That uses the xAI API for Grok (the others run through their native CLIs).

Setup is one command

npx delimit-cli setup

This detects which AI assistants you have installed, configures MCP (Model Context Protocol) for each one, and sets up the shared workspace. Takes about 30 seconds.

After setup, every assistant you open has access to the same tools — delimit_ledger_list, delimit_memory_search, delimit_lint, and about 100 others. They all read and write the same local state.

Why this matters beyond convenience

The convenience of not re-explaining your task is nice. But the real value is that governance and decisions persist across model switches.

If Claude Code ran a security audit and flagged a vulnerability, that finding doesn't disappear when you switch to Codex. The evidence is stored, the ledger item is open, and any assistant you open next will see it.

If three models deliberated on an architecture decision and reached consensus, that decision is recorded. Six months later, when a different assistant (or a different developer) asks "why did we choose JWT?", the answer is in the deliberation history.

Context continuity isn't just about productivity. It's about institutional memory that survives model switches, rate limits, and team changes.

Try it

npx delimit-cli setup

Works with Claude Code, Codex, Cursor, and Gemini CLI. Free tier includes governance, breaking change detection, and the shared workspace. Pro ($10/mo) adds deliberation, persistent memory, and deploy tracking.

How I Made Claude Code Auto-Fix Breaking API Changes in CI

Delimit.ai — Fri, 27 Mar 2026 04:28:52 +0000

AI coding assistants are great at generating code. But what happens when the code they generate breaks your API contract? I built a workflow where Claude Code reads structured CI output, understands the breaking change, and fixes it — automatically.

The Problem

If you have an OpenAPI spec checked into your repo, there's a good chance nobody is actually reviewing it on pull requests. Linters like Spectral validate the spec in isolation, but they don't compare old vs. new. They'll catch a missing description, but not the fact that you just changed a response field from string to integer — the kind of change that breaks every downstream consumer.

I needed something that would:

Diff the spec against the base branch on every PR
Classify each change as breaking or non-breaking
Tell me the exact semver impact
Give me a migration guide so I could fix it fast

The Solution: Delimit GitHub Action

I built Delimit, a GitHub Action that does all of this deterministically. No LLM in the loop, no external API calls — just a diff engine that understands 27 types of OpenAPI contract changes (17 breaking, 10 non-breaking).

Setup

Add one workflow file to your repo:

name: API Contract Check
on: pull_request

jobs:
  delimit:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: delimit-ai/delimit-action@v1
        with:
          spec: api/openapi.yaml

That's it. Delimit auto-fetches the base branch version of your spec and diffs it against the PR changes. It runs in advisory mode by default — posts a PR comment but never fails your build.

The Auto-Fix Loop

Here's where it gets interesting. Claude Code can read CI output. So when Delimit flags a breaking change, Claude sees:

What changed (endpoint removed, type changed, enum value removed)
Where it changed (exact path in the spec)
Why it's breaking (severity classification)
How to fix it (migration guide)

That structured output is enough for Claude to submit a fix.

The Loop in Practice

You can see this working end-to-end on PR #11:

Claude Code makes changes that modify the OpenAPI spec
Delimit runs and flags the breaking changes in a PR comment
Claude reads the comment, understands the issue, and pushes a fix
Delimit re-runs — all checks pass

The reason this converges (instead of looping forever) is that the diff engine is deterministic. Same input, same output.

CLI for Local Development

npx delimit-cli lint api/openapi.yaml
npx delimit-cli diff api/openapi.yaml --base main

Custom Policies

# .delimit/policies.yml
rules:
  - id: no-v2-removals
    change_type: endpoint_removed
    path_pattern: "/v2/*"
    severity: error
    message: "v2 endpoints cannot be removed without a deprecation period"

Try It

npx delimit-cli setup

GitHub Action: marketplace/actions/delimit-api-governance
Live PR demo: delimit-ai/delimit-mcp-server/pull/11
Source: github.com/delimit-ai/delimit-mcp-server

MIT licensed. No API keys or external services required.

Catching Breaking API Changes Before They Reach Production

Delimit.ai — Mon, 09 Mar 2026 22:19:58 +0000

Breaking API changes are one of the easiest ways to accidentally disrupt production systems.

They often slip through code review because the service itself still works — but client integrations fail immediately after deployment.

A Common Example

Consider a small change in an OpenAPI specification:

age: integer → age: string

From the service's perspective, everything still works.

But any client expecting an integer now receives a string, which can break applications consuming the API.

These types of issues are easy to miss during pull request reviews, especially when OpenAPI specs grow large.

Types of Breaking Changes

Some examples of changes that can break API consumers include:

Removing an endpoint
Deleting a required field
Changing a field type
Removing an enum value
Making an optional parameter required

Even small modifications can break downstream systems that depend on the API contract.

Detecting Breaking Changes in CI

One approach to preventing these issues is comparing OpenAPI specifications directly in CI and failing the build when breaking changes are detected.

Example CI output:

❌ Breaking API change detected
Removed endpoint: DELETE /users/{id}

By validating API changes automatically during pull requests, teams can catch compatibility issues before deployment.

Example Implementation

A simple implementation using GitHub Actions is available here:

https://github.com/delimit-ai/delimit-action

It compares OpenAPI or Swagger specifications between commits and flags breaking changes during CI runs.

Why This Matters

APIs often serve as contracts between teams, services, and external integrations.

Automated contract validation helps ensure that changes to the API remain compatible with existing clients.

As APIs grow larger and more interconnected, having automated guardrails becomes increasingly important for maintaining stability.

Discussion

How do your teams handle API contract validation?

OpenAPI diff tools
contract testing
schema versioning
manual review

Curious to hear what approaches others are using.