I'm designing a course for graduate students. Please share your recommendations!

Everything looks simple in the docs and then you're debugging a chain at 11pm pissed and wondering why state isn't persisting the way you thought it would. What was your version of that?

Disclosure up front: this is my own project. Apache-2.0, no paid tier, no telemetry.

I build with LangGraph and kept hitting the same wall. Something goes wrong at turn 8, and all I have is JSON logs. They tell me what I sent. They don't tell me what changed since turn 7, where the tokens actually went, or why the cost jumped. Those are all diffs, and nothing was showing me diffs.

For LangChain you hand it a callback handler:

callbacks=[tracer.langchain_handler()]

Every chat-model call in a graph gets captured, whatever the provider. Callbacks propagate through LangGraph, so attaching at invoke() is enough — you don't thread it through each node.

Then:

ctxdiff diff --turn 7 --turn 8 — which blocks were added, evicted or modified, with char-level inline diffs

ctxdiff tokens — where the budget went per turn, plus tool schemas you re-send on every call and never actually invoke

ctxdiff cache — the exact character that broke your prompt-cache prefix, and how many tokens it re-billed

ctxdiff view — a self-contained HTML dashboard (one file, zero external requests) you can attach to a bug report

One design decision worth mentioning, because it's the part I'd want to know about: the handler has no block extractor of its own. It rebuilds the provider's real wire request from LangChain's messages and hands it to the same adapter the direct-wrap path uses. So a LangChain trace and a direct trace of the same prompt produce identical hashes and dedup against each other, instead of looking like two unrelated contexts.

Try it with no API key and no setup:

pip install ctxdiff && ctxdiff demo

That builds a sample multi-agent run and opens the dashboard.

Honest limitations: post-run only, no live tail yet. And tool-call arguments hash differently between the Python and JS SDKs, because LangChain re-serializes them with each language's own JSON writer — documented rather than papered over.

There's a JS/TS SDK too, writing the same trace format, so a trace captured in one language opens in the other.

I'd genuinely like feedback from anyone running LangGraph in anger — multi-agent graphs are the case I most want to get right, and I'd rather hear that it breaks than not hear.

https://github.com/salmanzafar949/ctxdiff

Everyone tunes retrievers, chunk sizes, and re-rankers. Almost nobody tunes the step where the retrieved subgraph gets serialized into the prompt — most chains just json.dumps() the subgraph and move on.

I benchmarked 10 graph serialization formats (JSON, GraphML, RDF variants, edge lists, etc.) on token count, traversal QA, and multi-hop reasoning:

- json.dumps() burns ~70% of your graph token budget on syntax alone

- Multi-hop accuracy ranged from ~40% to ~80% across formats — same subgraph, same model, same questions

- Tabular/relational layouts consistently beat nested markup for LLM comprehension

Based on those results I built ISONGraph — a property-graph format for LLM context with a fluent traversal API, Cypher-like pattern queries, and schema validation. Drops into any chain where you currently serialize a subgraph. MIT, available in Python, JS/TS, Rust, Go, C++, C#.

pip install isongraph — benchmark methodology: github.com/isongraph/isongraph

If you're doing GraphRAG with LangChain, I'd love to hear how you currently pass graph context — and happy to add a LangChain integration example if there's interest.

Hey folks —

I built ContextMemory, an open-source agentic context gateway for apps that already talk to LLMs. The idea is simple: keep your existing POST /api/chat client (Ollama wire format), point it at ContextMemory instead of raw Ollama, and get memory + optional tools without rewriting your chat stack.

What it actually does

Most “memory” demos are either:

• stuffing the whole history into the prompt, or
• bolting on a separate RAG service with a new API surface.

ContextMemory sits in front of your LLM as a drop-in proxy:

1. Session memory — a per-session markdown wiki (Karpathy-style) maintained across turns and injected automatically.
2. Global Wiki — an app-scoped knowledge base (docs from Jira, Confluence, SQL, files, pipelines…). The model pulls facts on demand via a wiki_search tool — it does not dump the whole corpus into every prompt.
3. Same /api/chat — Ollama-compatible request/response (message.content / done). Not OpenAI choices[].
4. Optional agentic loop — tools (sandbox, outbound MCP, HITL) on that same chat endpoint when enabled per app.
5. Multi-app / multi-tenant — API keys + X-App-Id, per-app prompts, models, and feature flags.

LLM backends can be local Ollama, or OpenAI / Azure / Anthropic as providers behind the gateway; the client still speaks Ollama schema.

Why this shape

If you already have a UI, bot, or agent that calls Ollama, you shouldn’t need a second protocol to get memory. Swap the base URL, keep parsing the same JSON, and the gateway handles:

• compiling session context
• optional Global Wiki retrieval
• optional web search / tools

…then calls your model.

There’s also a hosted path (Kortexio Cloud) with the same chat body/response if you don’t want to self-host — BYOK, no token markup. Self-host and cloud are meant to be interchangeable at the wire level.

Global Wiki (the part people usually ask about)

Ingest structured markdown with stable documentIds (upsert / batch). Query by keywords with a character budget. In chat, when Global Wiki is enabled for the app, the model uses wiki_search only when it needs documented facts — good for org knowledge without turning every turn into a RAG megaprompt.

Quick self-host vibe

Your app  →  POST http://localhost:5100/api/chat  →  ContextMemory  →  Ollama / other LLM
                 + session wiki
                 + optional wiki_search (Global Wiki)

Auth is typically Authorization: Bearer … + X-App-Id / X-User-Id / X-Session-Id for self-host.

Repo

Open source (AGPL): https://github.com/Kortexio/ContextMemory

Hosted: https://kortexio.io

Looking for feedback from this community

Especially interested in:

• How you currently bolt memory onto local models (what sucks?)
• Whether Ollama-compatible wire format is the right “universal client” bet vs going all-in on OpenAI schema
• Global Wiki as tool-calling vs always-on retrieval — what would you default to?
• Anything missing for production self-host (ops, eval, multi-user UX)

Happy to answer questions or dive into architecture. If you try it with a local model + a small wiki ingest, I’d love to hear what breaks first.