Allows using Ollama's OpenAI-compatible endpoint as the summarization backend for context compaction, enabling long-running chat sessions with local models through saved and recalled state.
Allows using OpenAI's hosted API as the summarizer to compact conversation history into structured state blocks for persistent memory and long-running sessions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@longhaul compact our conversation and remember the next steps"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Use a local model the way you'd use ChatGPT or Claude. Just keep talking. It handles the context so you don't have to think about it, and it remembers across sessions.
An MCP server, zero dependencies (stdlib Python), works with LM Studio, Ollama, llama.cpp, or any OpenAI-compatible endpoint. MIT.
The thing that makes hosted assistants feel effortless isn't the model, it's everything around it. You never watch a token counter, never start a fresh chat because the old one filled up, never re-explain what you're building. Run a model locally and all of that becomes your job again. longhaul gives that part back.
Four tools over MCP:
compact(conversation) takes the transcript, sends it to whatever endpoint you
configured, and gets back a fixed block:
## STATE what this is about and where it stands
## DECISIONS constraints the user set (treated as binding, never dropped)
## ARTIFACTS file paths, versions, commands, kept verbatim
## OPEN unfinished or blocked
## NEXT the immediate next actionThat block gets appended to ~/.longhaul/sessions/<name>/memory.jsonl (plus a
markdown copy you can read) and handed back to the model, which continues from
it instead of the raw history.
recall(query) searches every record ever written, across all sessions.
remember(fact) pins something permanently. timeline() lists your sessions.
No embeddings, no vector database, no background process.
Related MCP server: Memory MCP
A bigger window buys you a longer sitting. It doesn't change the part that actually annoys you, which is that managing context is still your job.
You still watch the counter. You still decide when to start over. You still paste the same background into a fresh chat because the old one filled up. And when you close the app, 64K of it goes away regardless.
If you're happy doing that, fair enough, this isn't for you. If you'd rather just talk to the thing, that's what it's for.
One technical note while you're here: allocated context isn't usable context. KV cache is reserved up front, prefill cost climbs as the window fills, and recall from the middle of a long context is measurably worse than from the ends. Running near the top of a 64K window is slower and dumber than running in the first half of it.
Most of them do RAG over your chat history: embed every message, then auto-inject the top-k similar chunks into each turn. Your window fills with fuzzy fragments you didn't ask for, and relevance is whatever the similarity score says.
This works the other way around:
typical RAG memory | longhaul | |
stored | message embeddings | fixed schema, written at compaction time |
enters context | auto-injected each turn | only when the model calls |
retrieval | vector similarity | keyword overlap over plain JSONL |
deps | embedding model + vector DB | none |
summarizer | usually the local model | any endpoint, including a bigger one |
The schema does real work here. DECISIONS are never dropped and ARTIFACTS keeps paths and versions exactly as written. A similarity score can't guarantee either.
git clone https://github.com/yungmoneyhuncho/longhaul.gitThat's it, there's nothing to pip install.
In ~/.lmstudio/mcp.json:
{
"mcpServers": {
"longhaul": {
"command": "python",
"args": ["/absolute/path/to/longhaul/longhaul/server.py"],
"env": {
"LONGHAUL_BASE_URL": "http://localhost:1234/v1",
"LONGHAUL_SESSION": "main"
}
}
}
}Restart LM Studio, enable longhaul under Integrations, and paste examples/system-prompt.md into your system prompt so the model knows to call the tools on its own.
Same config shape works for Claude Desktop, Cursor, or any MCP client, just in that client's config file.
Variable | Default | What it does |
|
| endpoint that writes the summaries |
| first model the endpoint reports | which model summarizes |
|
| bearer token |
|
| session name, separate memory per name |
|
| where memory lives |
|
| seconds to wait for a summary |
The model writing your summaries doesn't have to be the one you're chatting
with. Point LONGHAUL_BASE_URL somewhere with a big context window and your 4B
gets compactions written by a model that read the whole transcript in one go:
"env": {
"LONGHAUL_BASE_URL": "https://your-endpoint/v1",
"LONGHAUL_MODEL": "some-long-context-model",
"LONGHAUL_API_KEY": "sk-..."
}Pointing it at your own local server works fine too.
~/.longhaul/sessions/<name>/
├── memory.jsonl one JSON object per line, append only
└── MEMORY.md same thing, readable and greppableNothing is deleted or rewritten. Delete a session by deleting the folder. The only thing that leaves your machine is the transcript going to whichever summarizer endpoint you configured, so if that's localhost, nothing leaves.
Search is keyword overlap. Worse than embeddings at catching a paraphrase, fine for finding "what did we decide about the database" in a year of sessions, and it means there's nothing to install or corrupt.
The model has to call compact. MCP has no hook that fires on its own, so
this depends on the system prompt. Small models sometimes need it stated
bluntly. Keep your client's rolling-window setting on as a backstop.
Compaction is lossy on purpose. Detail outside the block leaves the window.
recall gets it back from disk, but the model has to think to ask.
Keyword search misses paraphrases that share no words with the original.
Summary quality is whatever your summarizer model's quality is.
MIT
Compact the conversation when the context window is filling up (call around 70% full, before turns scroll away). Summarizes the session into a dense STATE block, saves it to permanent memory, and returns it. Continue from the returned block and treat earlier turns as discarded - nothing is lost, recall can retrieve it.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation | Yes | The conversation so far, as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有注解，但描述承担了透明度的责任。它声明这是破坏性操作（丢弃早期语境），但增加了安全保证（数据在永久内存中，recall可恢复），增加了丰富背景。它没有具体说明输出格式或机制，但因此给出一个3分，基于无注解条件下的描述质量。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述紧凑且组织清晰：先声明触发条件，然后说明行为（保存到保存，返回），再说明使用后续步骤。每个词都有价值，无多余。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
该工具只有一个参数，无输出schema，描述足够让人正确调用它。工具的行为、触发时间和后续行动都已覆盖。唯一缺失的是返回格式，但这未形成阻碍，且不关键。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema中有一个参数conversation，其描述为“The conversation so far, as text.”并且schema覆盖率为100%，所以schema已经解释了参数。描述仅带有上下文提示（此参数用于压缩会话），但未额外添加语法或格式细节。基线为3分是合适的。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述清晰说明了工具的作用：当上下文窗口即将填满时，紧凑会话以释放空间。动词“紧凑”与资源“会话”明确，与兄弟工具（recall、timeline、remember）区分明显。此定义准确且行动导向。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述明确给出了使用的时机（约70%充满时，在转折滚动前）、原因（上下文窗口将满）、及后续行为（从返回块继续，早期转弯视为丢弃）。还明确说明替代方案（recall可以检索），这是明确的试用指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search everything ever compacted or remembered, across all past sessions. Use when the user refers to earlier work, asks what was decided, or mentions something not in the current window. Call with an empty query to get the most recent compaction.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5). | |
| query | No | Keywords, file path, or topic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the search scope and the empty-query special case, but does not explicitly state that the operation is read-only or describe any other behavioral constraints. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the scope, the usage trigger, and a useful edge-case tip. No filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with no output schema and no annotations, the description covers key aspects: what is searched, when to use it, and a special query behavior. It could mention result ordering or limit semantics, but these are already covered by the schema, so overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra value by explaining the empty-query behavior for the 'query' parameter, which is not mentioned in the schema. This elevates the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Search'), a precise resource ('everything ever compacted or remembered, across all past sessions'), and clearly distinguishes from siblings by scope. It also provides concrete use cases, so an agent can identify when to invoke it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives explicit conditions for use: 'when the user refers to earlier work, asks what was decided, or mentions something not in the current window.' It does not mention alternatives or exclusions, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pin a fact to permanent memory immediately - a user preference, a decision, a path, a credential location. Survives every future compaction and session.
| Name | Required | Description | Default |
|---|---|---|---|
| fact | Yes | The fact to store. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals a critical behavior: persistence across compactions and sessions. It does not mention potential side effects like overwrites, but for a single-field store tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tight sentence that front-loads the core action and then specifies survival guarantees. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is sufficient. It covers purpose, usage, and the key persistence trait. Minor gaps like whether the tool accepts any string length are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes 'fact' as 'The fact to store.' The description adds no additional parameter-specific meaning beyond what the schema provides, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Pin' and the resource 'a fact to permanent memory', clearly distinguishing it from siblings compact, recall, and timeline. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: storing facts that must survive compaction and sessions. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough to guide an agent to use this tool for permanent memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sessions on record with their memory counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the operation ('List') which implies read-only, but does not disclose any access requirements, potential side effects, rate limits, or other behavioral details. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that fully captures the tool's action and scope with no redundant words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a parameterless list operation, the description is nearly sufficient, but it lacks any context about how this tool relates to sibling tools or what the output structure looks like. Some gaps remain for an agent deciding between timeline and recall/remember.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to elaborate on parameter semantics. A baseline of 4 is appropriate given no parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all sessions') with a detail on what is included ('with their memory counts'). It clearly states what the tool does, though it does not explicitly differentiate it from sibling tools like recall or remember.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the siblings compact, recall, or remember. There is no mention of alternatives, exclusions, or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct, non-overlapping function: compact summarizes the current session, recall searches past memory, timeline lists sessions, and remember stores a fact. No two tools could be confused for one another.
All tool names are single lowercase words using a command-like style (compact, recall, timeline, remember). The naming pattern is uniform and intuitive, with no mixed conventions or confusing prefixed/suffixed variations.
Four tools is the right size for a memory-management server. The scope is narrow and each tool covers a necessary function without bloat or redundancy, making the set easy to learn and use.
The core memory lifecycle is covered: remember (write), compact (state saving), recall (read/search), and timeline (audit). A possible gap is a delete/forget operation, but for a persistent-memory system this may be intentionally omitted, so the surface is nearly complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents. Search, store, and recall across sessions.
Cross-LLM persistent memory: store context once, recall it from any AI model.
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
Persistent memory for AI agents — log and recall conversation context over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yungmoneyhuncho/longhaul'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
