Mini Me `v1.0.6` is out: Kronk support and custom ACP extensions

A new release of Mini Me is available: v1.0.6. It is small in number of features (two), but I like it a lot, because both new features open quite a few doors:

• Mini Me can now run on Kronk, the Go inference server from Ardan Labs;
• in ACP mode, the ACP client program that drives Mini Me (a code editor, an application, a script...) can now "lend" its own functions to the agent, which will use them as tools.

Today I'll give you a quick tour, and I'll dedicate a blog post to each of the two features in the coming days.

A new provider: Kronk

Kronk is an inference server written in Go that embeds llama.cpp... with no llama-server process on the side, thanks to the Yzma project. It exposes an OpenAI-compatible API (on http://127.0.0.1:11435/v1), so Mini Me could already more or less talk to it. But "more or less" is not good enough for a small model, so it now has its own provider:

provider: kronk
model: unsloth/Qwen3.5-2B-Q4_K_M

And here is what it brings:

• The context window is known from the start: Mini Me asks Kronk for it (whether the model is loaded or not), and the banner shows for example ctx: 131072 (/v1/kronk/models). History compaction is based on it.
• autoPull: true downloads the model if Kronk doesn't have it yet.
• /unload (and the unload_model tool) frees the model's memory.
• mm init --provider kronk lists Kronk's models and reads from it the window, the GGUF's sampling settings and the chat template's reasoning switch, to write a suitable agent.yaml for you.
• Kronk profiles (ids of the form provider/modelID/PROFILE, for example …/Qwopus3.5-4B-Coder.Q8_0/AGENT) are recognized: mm init explains what they are and copies their sampling settings into the file.

If you use Mini Me in a Docker sandbox (sbx), start Kronk on your machine with kronk server start --api-host 0.0.0.0:11435: by default it only listens on 127.0.0.1. Mini Me will fall back on its own to http://host.docker.internal:11435/v1.

Tools "lent" by the ACP client, thanks to custom extensions

If you have read ACP from scratch, you know that an ACP client (a code editor, for example) launches the agent as a subprocess and talks to it in JSON-RPC over stdin/stdout. The client already provides services to the agent (asking for a permission, reading a file, ...), but it could not tell it: "here, this is one of my functions, use it as a tool".

Now it can. The ACP client describes its tools (a name, a description, a JSON schema of the arguments, the MCP way), the model sees them under the name client_<name>, and when it calls one, Mini Me forwards the call to the client, which runs its function and sends back the result. An editor's open buffers, an application's data, a device plugged into the client's machine... everything the client can do becomes a tool for the agent.

On the Mini Me side, the settings fit in a small block of agent.yaml:

acp:
  clientTools:
    enabled: true
    # meta: the client lists its tools in initialize
    # request: mm asks for the list each time a session opens
    discovery: meta
    # auto: ask the client only when yolo is false; ask: before every call
    permissions: auto
    timeout: 30s

I'll write a post that explains all of this in detail, with diagrams, and a Node.js demo (with zero dependencies) that you can run at home.

The demos

• demos/kronk/: a coding agent on Kronk with mradermacher/Qwopus3.5-4B-Coder.Q8_0, and the line to change for Qwen3.5 2B.
• demo.acp.sdk/client-tools-nodejs/: a Node.js ACP client that lends the agent a host_info tool (the machine's OS, CPU, memory, uptime). The agent has no shell: this tool is its only way to know anything about the machine.

Upgrading

Your agent.yaml files don't change: just replace the mm binary. The installation guides are here: macOS, Linux and Windows.

All the release notes are here: release-notes/v1.0.6.en.md.

That's all for today. Soon, we'll get to know Kronk.