I tried on an old i7 running Ubuntu server 24.04 and something went off the rails, which seems to trace to Claude, which was devouring 32GB of RAM and another 72G of swap. Needless to say, the box seized up. Since an MCP is not strictly necessary for the reasons I have the server, I’m trying to back out to get back to just Ollama. Not at all a slam on Kaimon, just context for anyone else experiencing the same with Claude.
Claude code is a rapidly evolving piece of software itself, and I’ve seen a few cases where over long periods the claude executable seemed to be leaking memory. It hasn’t been reproducible, but just something to be aware of. If you’re using Ollama, I’m curious what model(s) you might be using locally? Do you integrate that with something that is behaving as the ‘agent’?
Kaimon uses Ollama and an embedding model (currently qwen-embedding:0.6b by default) for semantic indexing/search. The model is configurable.
Claude code is only one of the many agentic AI coding assistants available, I wonder if you might try it again with another one?
Not sure if it is the same issue, but claude code can be buggy like this if the tool results are large. As a workaround I limit output in my mcp server to less than 100 KB SandboxMCPRepl.jl/test/runtests.jl at f98804309897a7b7c5cdf0eacd2bd9a679fa4a95 · nhz2/SandboxMCPRepl.jl · GitHub
Kaimon limits the tool output as well, for example in the main code execution tool, the max_output parameter can be modified by the agent to control the max output size and has a default of 6k characters.
I frequently see this in the claude log:
● kaimon - run_tests (MCP)(pattern: "ThreeWindingSpec", verbose: 2)
⎿ ERROR: FieldError: type Kaimon.TestRun has no field `reader_done`, available fields: `id`, `project_path`, `starte
d_at`, `finished_at`, `status`, `pattern`, `results`, `failures`, `raw_output`, `total_pass`, `total_fail`, `total
_error`, `total_tests`, `pid`, `process`
● kaimon - run_tests (MCP)(pattern: "ThreeWindingSpec")
⎿ ERROR: FieldError: type Kaimon.TestRun has no field `reader_done`, available fields: `id`, `project_path`, `starte
d_at`, `finished_at`, `status`, `pattern`, `results`, `failures`, `raw_output`, `total_pass`, `total_fail`, `total
_error`, `total_tests`, `pid`, `process`
● Bash(julia --project -e 'using Pkg; Pkg.test()' 2>&1)
⎿ Status `~/dev/projects/2026/transformer-thermal/TransformerThermalModel.jl/test/Project.toml`
[f8b46487] TestItemRunner v1.1.4
[1c621080] TestItems v1.0.0
… +67 lines (ctrl+o to expand)
⎿ (timeout 2m)
It seems there is some issue with kaimon - run_tests, where the agent gives up and runs the tests manually. Any idea what would cause this or how to resolve it?
I just tried out the 1.1 branch and it fixs the memory leak issue! This is 100% a claude code bug not a kaimon bug, but the workaround seems to be effective. If you want to reproduce here is prompt to try:
Prompt to help reproduce claude code memory leak
Reproduce memory leak from MCP server returning large output.
Steps:
- Fetch the
mcp__kaimon__manage_replandmcp__kaimon__extool schemas - Run
manage_replwith command “restart” - Run
mcp__kaimon__exwithe="'x'^100_000_000",q=false,max_output=100000000 - This will produce a
persisted-outputsaved to a JSON file. Use the Read tool on that file withoffset=4, limit=1to read line 4 (the 100M character line). - While reading the human presses the CTRL and O keys at the same time.
Results with 1.1 branch of kaimon
● kaimon - ex (MCP)(e: “‘x’^100_000_000”, q: false, max_output: 100000000)
⎿ "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
… +149 lines (ctrl+o to expand)
● The output was truncated to 25000 chars but mentions 100000002 total chars. Let me look for the persisted output file.
● Searched for 4 patterns (ctrl+o to expand)
● The MCP tool’s max_output parameter has a hard cap of 25,000 characters (as noted in the schema: “max: 25000”), so despite requesting 100M, the output was truncated to 25,000
chars. No persisted-output file was created.
The memory leak scenario as described can’t be fully reproduced because:
- The max_output parameter caps at 25,000 characters server-side
- The 100M character string was generated in Julia but only 25K chars were returned to the client
- No persisted-output JSON file was saved to disk
Would you like to try a different approach to reproduce the leak, or investigate whether there’s a way to bypass the output cap?
Try the 1.1 branch. Also it will be released probably today, but wouldn’t mind some early feedback.
I’ve made a number of improvements to the way Kaimon’s ZMQ messaging layer works. Not sure it that’s it but worth a try.
Also sometimes agents seem to want to revert back to using grep/shell because they must have a lot of reinforcement training on them. It seems to be necessary to reorient agents at using MCP stuff sometimes. Hopefully that there will be improvements to models over time which mitigate this, also there are things you can do like putting reminders/guidance in CLAUDE.md, etc.
Yeah I tried to force it to use MCP, but it just hits a wall and says
● The run_tests tool is hitting an internal kaimon server bug (FieldError: type Kaimon.TestRun has no field reader_done).
This appears to be a bug in the kaimon server itself — the TestRun struct was likely updated but the server code still
references an old field.
The tests themselves are passing fine — I confirmed this earlier via julia --project -e 'using Pkg; Pkg.test()' which
showed all 15 tests passing. The LSP diagnostics you see in the IDE are also false positives since it doesn't understand
the @testsnippet/@testitem macros from TestItemRunner.jl.
If you can reproduce with 1.1 would you file an issue? I believe it should already be fixed if it was a bug previously.
Just a quick update … Kaimon 1.1 keeps moving closer to release, but I thought I’d post this command which would get you up and running with the branch and clean up any old development packages in your environment:
julia --startup-file=no -e 'include(download("https://gist.githubusercontent.com/kahliburke/fbe523b4a67dacfaab3a69562dcc82bb/raw/install_kaimon.jl"))'
Kaimon.jl v1.2 — Your Tools, Your Rules
Kaimon is an MCP server for Julia that gives AI agents full access to Julia’s runtime — code execution, debugging, profiling, testing, semantic search, and more — all managed from a terminal dashboard.
v1.2 introduces a full extension system, TCP remote sessions, background jobs, and cross-project semantic search. If you’ve been wanting to give your AI agent domain-specific Julia tools, now you can — just drop a kaimon.toml into any existing Julia project.
What’s New Since v1.0
Extension System
Turn any Julia project into an extension by adding a kaimon.toml manifest. Export functions with typed signatures and Kaimon reflects them into MCP tools automatically. Each extension runs in its own subprocess and auto-connects via the Gate — Kaimon handles lifecycle management, auto-restart on crash, and tool namespacing.
# kaimon.toml
[extension]
namespace = "myext"
module = "MyExtension"
tools_function = "create_tools"
description = "My domain tools."
Extensions can also provide TUI panels — lightweight interactive views that render inside the dashboard. Tool handlers push live state updates to their panels via Gate.push_panel(), and the panel reads them on the next frame. No polling, no eval parsing — just real Julia objects over PUB/SUB.
A complete working example at examples/HelloExtension.jl demonstrates tools, panels, shutdown hooks, and the full manifest.
TCP Gate — Remote Julia Sessions
Connect to Julia sessions on remote machines over TCP with SSH tunnel support and token authentication. Run heavy computation on a beefy server while Kaimon manages the session from your laptop.
Gate.serve(mode=:tcp, port=9876)
The TUI auto-discovers TCP sessions with configurable polling and exponential backoff on connection failures.
Background Jobs
Long-running evaluations automatically promote to background jobs after 30 seconds. Running code can report progress with Gate.stash() and Gate.progress(), and agents check status with check_eval. Jobs persist to SQLite so results survive TUI restarts.
# Inside a long computation:
Gate.stash("epoch", epoch)
Gate.stash("loss", loss)
Gate.progress("Epoch $epoch: loss=$loss")
Cross-Project Semantic Search
Qdrant vector search now works across all indexed projects at once. Search by meaning, not just keywords — Kaimon chunks your source files, embeds them with a local Ollama model, and stores vectors in Qdrant. The TUI provides a full collection management interface with indexing, reindexing, and directory configuration.
Session Restart
Restart Julia sessions from the TUI or from the REPL with Gate.restart(). The session ID is preserved across restarts so the agent doesn’t lose its connection — it just keeps working.
Debugger Integration
Set @infiltrate breakpoints in your code and inspect variables interactively when they’re hit. The TUI shows a dedicated Debug tab with locals, a REPL console for evaluating expressions at the breakpoint, and full @exfiltrate support for capturing values without pausing.
The Full Toolbox
Kaimon provides 40+ MCP tools across these categories:
- Code execution — persistent REPL sessions with streaming output and concurrent eval
- Navigation — go-to-definition, document symbols, workspace search, type info
- Testing — run test suites with live progress, failure details, and filtering
- Profiling —
@profilewith flamegraph-ready output - Formatting — JuliaFormatter integration
- Linting — Aqua.jl quality checks
- Debugging —
@infiltratebreakpoints, variable inspection, expression evaluation - Semantic search — natural language code search over Qdrant indexes
- Package management — add/remove packages in connected sessions
- Extensions — domain-specific tools as separate Julia packages
All coordinated from a TUI dashboard that shows connected sessions, tool call activity, server health, search indexes, and extension status.
Install
]app add https://github.com/kahliburke/Kaimon.jl#v1.2.0
Requires Julia 1.12+. Works with Claude Code, VS Code (Copilot/Continue), Cursor, Gemini CLI, Antigravity, and other MCP clients.
Docs: kahliburke.github.io/Kaimon.jl
GitHub: github.com/kahliburke/Kaimon.jl
is Kaimon going to become a registered package in the Julia registry?
I had originally planned for it to be added already. But then having experienced the criticism and harassment from some people in the ‘community’ regarding AI agentic coding topics in general, well I suppose it’s made me more hesitant and less motivated.
However, there’s nothing holding you back. The only practical difference is that you need to use a few more characters when installing it. Not a lot of extra effort between
]app add Kaimon@1.2.0
and
]app add https://github.com/kahliburke/Kaimon.jl#v1.2.0
I will likely submit it for inclusion in the General registry soon, I just always find myself spending time adding features and fixing bugs instead of doing the registry request.
Sorry to hear you’ve been harassed. Doesn’t seem like a helpful way to respond to the rapid changes affecting the software industry.
One benefit of being in the General registry is that it will be there “forever” regardless of whether or not the original github repo goes away. That makes it safer for users to take a dependency on your code.
Registry maintainers make the rules for a registry, not the community. For example, I personally would hesitate “opening the door” for more people to hand their REPL to agents and can’t imagine Kaimon.jl being a nested enough dependency to make much use out of General, but I also recognize that General already has at least one app-like package that automatically connects to an AI model, Pluto.jl, while Kaimon.jl at least makes users bring their own. None of that matters to registration because I don’t maintain General. Give it a shot, worst case scenario is users have to type a little more at installation and the registry rules get a helpful and possibly temporary addition.
I personally would hesitate “opening the door” for more people to hand their REPL to agents
There are myriad reasons to be concerned about agents and the REPL, but the tooling is undeniably useful to members of the community. And while we have rules about packages which are vibe-coded both Tachikoma and Kaimon seem to quite easily clear the quality hurdles (in my humble view).
As for the question about dependencies: While I’m sure different General maintainers have different views on this the registry may be used for tools which are useful but not otherwise dependencies for other packages:
If your package is at a stage where it might be useful to others, or provide functionality other packages in General might want to rely on, go for it!
Of course Julia makes it easy to install Apps and packages by URL but there are goods reasons to register besides dependency tracking:
- Discoverability, people use JuliaHub for searching, and many users will instinctively type
]add Kaimoneven if the readme says otherwise. - Added to PkgEval for testing.
- You can get a sort of proxy for package usage statistics from the Pkg servers.
- Personal satisfaction! It’s a rewarding thing to do IMO
Again I can’t speak for the registry maintainers, but tooling is not a completely alien concept to General. After all things like JET, LanguageServer, Chairmarks, Extrae and more have few to no dependents (if they do it’s more often than not by accident). There’s room for agentic development tools in there.
This is a hot button topic but after everything is settled packages which are high quality use up approximately one resource: a name. It’s just as easy to ignore or avoid agentic development as before, and mildly easier to give it a try.
I’m pretty sure Kaimon passes all automerge rules (up to false-positive “name similarities”), so a registry maintainer or anyone else would have to go out of their way to block a registration. I do not foresee anyone doing this. The package is absolutely fine by any standard that normally gets applied to registrations. In particular, it is not “vibe-coded” by the definition of the registry guidelines. “AI” as a general topic might be “controversial”, but that has absolutely no bearing on the registration.
“Tooling” (a package not intended as a dependency) is generally welcome in the General registry. Sometimes such tooling packages might lean towards “personal utility packages” or might have other potential problems such as type piracy, and receive pushback on those grounds. The fact that registration for these packages isn’t strictly “necessary” can be an argument for “maybe it’s better not to register this” in that context. I don’t think Kaimon has any such issues. When you have people asking for a package to be registered, that’s a pretty good indication that it should be registered.
No no silly, it’s opening the gate! 開門
Your package’s name can mean whatever you specify, but at the risk of sharing known information, those characters don’t strictly refer to gates in every context, like the primary reading of a fairly large language family. I probably won’t be the only person to read it a bit more flexibly.
Great, I’ve submitted the registration request for Kaimon 1.2.1!