v0.3.15

CodeZaiku 0.3.15

What's new: the model on this machine runs on AMD and Intel graphics too, and a bug fix.

Added

• codezaiku model serve install works on a Linux machine with an AMD graphics chip (a Radeon, a Ryzen AI or an Instinct) or an
  Intel one, not only an NVIDIA card.

Fixed

• A machine with a stand-in nvidia-smi that only prints a message was taken for an NVIDIA machine.

v0.3.14

CodeZaiku 0.3.14

What's new: a stronger model can check a cheaper model's work, the chat remembers what you decided, and bug fixes.

Added

• --overseer <model>: one model does the work, a stronger one checks it and says what is wrong. Off by default; in our tests
  it did not help much.
• A coding run's plan now lists the files it will change and what needs a test.
• When a fix is finished without a test, the model is asked to add one.
• The chat says what kind of change it is about to make: a quick try, a small change, or a big one.
• The chat remembers your corrections and decisions from earlier turns.
• --effort on|off turns a model's thinking on or off (OpenRouter models).
• --model auto uses a model's free version on OpenRouter when nobody is waiting for the job. codezaiku run --wait 0 says
  nobody is waiting.
• When a run changes a file its plan did not mention, it says so.
• A file read that was cut off tells the model how to read the rest.

Fixed

• A run that finished on its last turn with passing tests was reported as unfinished.
• Files written with shell commands were not seen by the checks.
• A message with the word "only" in it was taken as a correction.
• On hosted models the model's reasoning was sent back with every request, which cost five times as much.
• One instruction made GLM read for sixty turns without writing anything.

v0.3.13

CodeZaiku 0.3.13

You can now keep several models, on your own card or from a service, pick one for each coding job or let
CodeZaiku choose, and see what each job cost. MODELS.md says which models did best in our tests, local ones
first.

Added

• Several models, by name. codezaiku model add <name> … keeps a model with its address, its prices and, if you like, a
  monthly spending limit. codezaiku code <project> "…" --model <name> runs one job on it; the chat, the MCP tools, ACP and
  run take the same choice.
• Let CodeZaiku choose. --model auto picks the model for the job and says why: the cheapest one that is good enough and,
  when you are waiting, quick enough. A free local model wins whenever it qualifies. Once two models are saved, this is what
  happens when you name none. A project marked private is read by local models only.
• What a job cost. Every job reports its model and what it cost. codezaiku spend adds it up by month. A job that would go
  past a model's monthly limit does not start.
• A key per service. codezaiku model key openrouter --file <file> keeps a key for one service, and it goes to that service
  and nowhere else.
• OpenAI directly, and the other services. Type openai in setup with your key. OpenRouter, Gemini, Nebius, Hugging Face
  and DeepSeek work with a key, and a busy service is waited for.
• Which model, measured. MODELS.md lists the models we tried on two sets of coding tasks, with what each passed, how long a
  job took and what it cost, at the prices of 16 and 17 October 2026. "Let CodeZaiku choose" starts from those results.

Fixed

• The check that a run has not faked its core now reads only the files the run wrote. It used to flag the project's own code
  and send the model off to rewrite it.
• A declared pytest check runs the project's own tests even when a package of the same name is installed elsewhere.
• The research pass before a coding task no longer runs for the newest frontier models, which do not need it.
• A percent-escaped path in a task is no longer read as a file the task names.

v0.3.12

CodeZaiku 0.3.12

The Claude Messages API as a drive, research before a coding task, a prepare step for slow checks, and the fixes that let
a long coding run on a local model finish or report. Measured on one brief with a 27B: zero passes in six runs without the research
pass, one pass in two with it; Claude finishes without it. A regression battery (a web API, a maintenance fix, an ML service) passed
on the release build.

Added

• Research before the work. Before a multi-step coding task is planned, the model is asked for two or three questions a search
  engine can answer (which library or method fits, how the quantity the task turns on is defined or measured, what usually goes
  wrong). A short research pass answers them on the web and, where ResearchZosho is installed, in the library. The notes and their
  sources stay in the prompt from the plan onward. Settings: CODEZAIKU_RESEARCH_FIRST (auto by default, always, off),
  CODEZAIKU_RESEARCH_FIRST_TURNS (8).
• Research when stuck. After three failing checks in a row, a second pass researches the symptom (the check's numbers and the
  method from each program's header) and adds a section to the notes. CODEZAIKU_RESEARCH_STUCK_TURNS (6); at most twice a run.
• Prepare step for a check. The plan can name a prepare: command next to the check: a program that does the slow, deterministic
  part once (reading every input, extracting features) and stores the results for the check to read. CodeZaiku runs it before the
  check and again only when that program changes. A check that takes over five minutes and has no prepare step is offered one
  (python evaluate.py is offered python prepare.py); nothing runs until the model writes it.
• Claude Messages API. drive = https://api.anthropic.com (or any /v1/messages endpoint) uses Claude's own API instead of the
  OpenAI-compatible endpoint. CODEZAIKU_REASONING_EFFORT sets Claude's effort. Tools, system prompt and conversation are cached at
  the API; the usage ← log line shows cache reads and writes. The log keeps a summary of the model's thinking. Context window and
  output limit come from the API's model listing; at most 200,000 tokens of the window are used unless CODEZAIKU_CTX is set.
  CODEZAIKU_TEMP=none and CODEZAIKU_TOOL_CHOICE=auto are not needed on this drive. codezaiku doctor shows the API's own
  error when a key or model name is refused.
• CODEZAIKU_REASONING_EFFORT: reasoning effort for thinking models (low, medium, high, xhigh on Qwen3.8), sent per
  request, so a server set up for quick chat can think harder in a coding run.
• CODEZAIKU_THINKING_BUDGET: maximum thinking tokens per reply, for servers that accept the limit (llama.cpp). Unset: no limit.
• CODEZAIKU_DRIVE_CLASS: frontier or small, for when the model's name does not say (see Changed).
• write_file accepts copy_from: the file's content is taken from a file already in the project.

Changed

• Project environments. A run installs packages into a per-project environment under ~/.codezaiku/envs, not into the user's
  Python or global package folders: a Python venv that still sees system packages, plus npm, cargo, go and gem install folders
  pointed at the same place. Every command activates it first. CODEZAIKU_PROJECT_ENV=off disables it. Linux, macOS and WSL;
  native Windows unchanged.
• When the research pass runs. auto (default): when the drive is not a frontier-class model and a search source answers (a Brave
  key, a SearXNG in the settings, or the ResearchZosho library). always: on every drive. off: never. On an existing codebase the
  model's QUESTIONS: none is honoured and the pass gets half the turns; a project built from nothing is always researched.
  Basis: Claude finished the test brief without research; of eight 27B runs, the one that passed had the pass, and a second run with
  it did not.
• Frontier-class is decided by the model's family name, wherever it runs: claude-* (through any gateway), gpt-5*, gpt-4.1*,
  o3*, o4*, gemini-2.5-pro, gemini-3*, grok-4*, deepseek-v3*, deepseek-r1, kimi-k2*, qwen3-max*, glm-5*. A
  family's mini, nano, flash, lite, small, tiny, distill or haiku variant counts as small. The Claude API is frontier
  regardless of name. CODEZAIKU_DRIVE_CLASS overrides the list.
• A run whose declared check passes ends at the first task_done. The older end-of-run steps (verify rounds, project tests, the
  changed-files note) no longer run after a passing check. The shell stays available after the pass; the files that passed are kept,
  and a later change that breaks the check is reverted.
• Project tests at task_done run inside the project's environment. A run that is sent back is told the command and shown the end
  of its output.
• Drives that refuse a forced tool call (Claude Opus 5.5, Fable 5.1, Sonnet 5.5) work: after the first refusal CodeZaiku stops
  forcing for the session (CODEZAIKU_TOOL_CHOICE=auto sets this up front). A text-only reply ends the turn: it is the chat reply,
  the run's report on the last turn, or otherwise answered with a request for the next action.
• A shell command run with timeout N gets N seconds, up to CODEZAIKU_SHELL_HEAVY_TIMEOUT_SEC (20 minutes). Previously every
  command was stopped at five minutes.
• Drive timeouts follow the server's measured speed: each call may wait as long as that speed needs, twice as long after a timeout,
  and never longer than CODEZAIKU_DRIVE_TIMEOUT_MAX (30 minutes by default). CODEZAIKU_DRIVE_TIMEOUT is the minimum.
• A run that stops because the server failed repeatedly reports the reason (too slow, with the last wait and tokens per second; no
  answer; or the server's message) instead of "context overflow". Status failed, as before.

Fixed

Long coding runs on local models could use every turn and end with the work half done and nothing reported. The causes, each fixed:

• Compaction summaries are checked (text, with progress and next steps). An unusable one is requested again; if the second is
  unusable too, CodeZaiku writes the summary from its own record. The request states the task, disables thinking, and asks for a
  bounded summary with progress and next steps first.
• The files a task names are tracked. Each turn shows which exist and which do not; task_done with one missing is bounced once;
  the final summary names any that were never written. Files present at the start are excluded.
• Write-only turns. In runs of 20 turns or more, when a named program is unwritten at the halfway point, or a named program or
  document at the start of the final stretch, write_file is the only tool offered for up to three turns. Files a program produces
  are excluded.
• The last turn of a coding run offers only task_done; its summary is the run's report. Status incomplete, as before.
• The end-game note asks for the named files and a report of where the work stands, whether or not every target was reached. It
  used to say "only when that final run is green".
• Only the latest reply's thinking stays in the conversation; older thinking is dropped first once the conversation passes half
  the window.
• The plan for a multi-step task is requested before the first turn in a call of its own, with no tools offered, and shown every
  turn.
• The research passes CodeZaiku runs itself (before the task, when stuck) get web, literature and library tools only and run in an
  empty folder. Given the project's files, they read code instead of researching. codezaiku research keeps the project as before.
• A research run that ends its last turn with a thin answer (a placeholder, or a pointer to a file that does not exist) gets one
  text-only turn, and that text is the answer. The same turn already existed for an answer that described a table instead of
  containing one.
• Behind llama-swap, a model that is not loaded yet has no upstream /props, and a run starting then read a window of 8,192 until
  the model was loaded. CodeZaiku now sends one request of one token first, which loads the model, and reads the window after it.

v0.3.11

CodeZaiku 0.3.11

This release adds Amazon Bedrock as a model, with your own AWS account. codezaiku update now updates ResearchZosho too, through ResearchZosho's own updater, and programs that keep CodeZaiku up to date get a JSON answer and exit codes to act on. model serve install uses a model server that another program already runs, such as Wyrdsekai's.

Added

• Amazon Bedrock as the model, with your own AWS account. codezaiku bedrock models lists what Bedrock offers your account in a region, codezaiku bedrock test <model> sends one small request with a tool in it to see that you may use the model, and codezaiku bedrock use <model> makes it CodeZaiku's model. Claude, Llama, Nova, Qwen, Mistral and the other chat models go through Bedrock's Converse API, with tools and pictures.
• It uses your own AWS sign-in through the AWS command line (single sign-on, an assumed role, keys), signs each request itself, and saves nothing of that sign-in. What you may use is decided in your AWS account. When AWS refuses, the message says what AWS answered and which of the usual causes it is. docs/BEDROCK.md has the steps, and the policy for whoever manages the AWS account. AWS GovCloud and the China regions work by naming the region.
• codezaiku doctor checks a Bedrock drive by asking the chosen model for one token.
• codezaiku update --json and codezaiku update now --json, for a program that keeps CodeZaiku up to date, such as Wyrdsekai. Each prints one JSON document on stdout, with the same fields as ResearchZosho's updater, and progress goes to stderr. The exit code says what happened: 0 updated or already current, 75 another update is running (ask again later), 3 this install cannot update itself, 1 failed. With --json, only CodeZaiku is updated. docs/DEPLOYING_AS_A_BACKEND.md has the fields.
• One update at a time. An update holds a lock file in ~/.codezaiku from start to end, and checks the version again against the installed files once it has the lock, because another program may have updated them in the meantime. A second update started meanwhile answers "busy" and changes nothing.
• codezaiku model serve install, and doctor when it offers to set up a model, first look for a model server that another program already runs on this machine: Wyrdsekai's on port 8200, llama.cpp, vLLM, Ollama or LM Studio. When it serves one of the models CodeZaiku knows, Qwen3.6-35B-A3B among them, which Wyrdsekai runs as its brain, CodeZaiku uses that server and downloads nothing. model serve install --own installs CodeZaiku's own model instead.

Changed

• codezaiku update now keeps ResearchZosho up to date too. It updates CodeZaiku, then, when ResearchZosho is installed, asks ResearchZosho's own updater to update it and says what came of each. A failure of one does not stop the other. When another program is updating ResearchZosho at that moment, it says so and leaves it alone.
• Each program's own updater replaces its files. Once ResearchZosho is installed, CodeZaiku never downloads or replaces it: codezaiku install researchzosho asks its updater instead, which restarts its own service, so the advice to reinstall the service by hand is gone. A ResearchZosho older than 0.5.0 is asked the same way; its updater answers in words, and "already" there means up to date.
• codezaiku update shows ResearchZosho's installed and latest versions and its update setting below CodeZaiku's.
• Auto mode (CODEZAIKU_UPDATE=auto) updates CodeZaiku only. ResearchZosho's own service updates ResearchZosho, with its own setting. doctor and the chat name codezaiku update now when a newer ResearchZosho is out.
• The README's opening, the npm package's description and keywords, and the MCP Registry entry say what CodeZaiku does and which model servers it works with.
• The source uses imports instead of fully-qualified class names, 616 of them in 68 files. The program works the same.

Fixed

• codezaiku install researchzosho updated an installed ResearchZosho by unpacking the plain tarball over it. On a machine without Java 21, a ResearchZosho that carried its own Java then no longer started. Its own updater now does the update and keeps that kind of build. A first install beside a CodeZaiku that runs on its own Java now takes ResearchZosho's build with its own Java too.
• On Windows, codezaiku update now downloaded the release and then failed, because the running program holds its own files, and its advice to try again from a new terminal could not work. It now says at once to close CodeZaiku and run the installer again, and exits with 3.
• A coding run whose model server went away for a moment, while it restarted or loaded its model, counted each refused request as a failed call, answered it with a note about malformed JSON, and ended after eight of them, within seconds. It now waits for the server, up to 10 minutes, and goes on with the same turn.

Install or update

On Linux and macOS, codezaiku update now on 0.3.1 or later. On Windows, close CodeZaiku and run the installer again. Otherwise:

Linux and macOS: curl -fsSL https://codezaiku.org/install | sh

Windows (PowerShell): irm https://codezaiku.org/install.ps1 | iex

No Java on the machine? The installers take the build that carries its own runtime. Any MCP client: npx -y @wyrdsekai/codezaiku-mcp.

Debian 13 and Ubuntu 24.04 or newer: the .deb below, sudo apt install ./codezaiku_0.3.11_all.deb. It needs Java 21, which Debian 12 does not have; use the one-liner there.

License: Apache 2.0. No model included.

v0.3.10

CodeZaiku 0.3.10

This release is about codezaiku chat. It shows you a plan before it builds, lets you steer a running turn, and no longer loses your answer or stops on a full context window.

Added

• chat: a plan you approve before a build starts. When your message asks for something to be built or changed, the model first writes a short plan: the files, the approach, what it would install, what it will leave out. You say go, type a change, or skip. /plan auto|on|off controls it; auto is the default and applies to build-sized asks only. A question or a small edit gets no plan step.
• chat: yolo still asks before installing a package, starting a server or downloading from the network when the approved plan did not mention it. One "always" covers that kind for the session.
• chat: ctrl-C now pauses rather than only stopping. After the stop, the chat asks what should change. Type it and the work continues with that change; press Enter to leave it stopped.
• chat: a progress line every ten steps on a long turn: steps so far, time, and the files changed.

Fixed

• chat: when a reply is cut off at the output limit in the middle of a tool call, usually a whole file in one write_file, the model is told what happened and to write the file in pieces. It used to be told only "you must act by calling a tool", which invited the same oversized write again. One such call cost 3.5 minutes for nothing.
• chat: a reply that was cut off at the output limit is never acted on. Its tool call has truncated arguments. A cut-off task_done used to end the turn with "(done)" and the answer was lost.
• chat: the project description in the prompt takes a tenth of the context window, measured in the model's own tokens, instead of a fifth at a guessed rate. On a 32k window it took 10,000 tokens and the fixed part of every request was 71%. The previous reply carried into the next turn is sized from the window too.
• chat: the task message is never trimmed to make a request fit. It was treated as an old observation, and after one such trim the model no longer knew what it was building.
• chat: the eighth-of-the-window limit on tool output is per step. Parallel calls in one step share it.
• chat: no single tool result may take more than an eighth of the model's context window. The tools capped their output at sizes meant for a 64k window; on a 32k window three parallel shell results filled 60% of it in one step and the request could not be sent. When a request still does not fit, the newest tool results are now trimmed too, not only the older ones.
• chat: a long turn could stop with "context overflow". The loop counted tokens by dividing characters by 3, which undercounts code and shell output, and it did not count the tool descriptions at all. It now uses the token count the server reports after each reply. If the server still rejects a request as too big, the loop trims old tool output and retries once.
• chat: the next turn now sees the previous question and reply. Before, each turn started with only a short restatement (topic, decisions, files seen), so a follow-up like "do everything but 7" referred to a list the model had never seen, and it started over instead of building.
• chat: the reply you see is now the model's own answer. It used to show the short task_done note instead ("delivered the analysis in my reply"), and the real answer was lost.
• chat: every turn started with an extra model call that planned the work and was then thrown away, because the context the chat adds in front of your words made the request look like a large task. On a 27B that was 30 to 60 seconds of nothing before the first step. The planning call is now skipped in chat.
• chat: the status line is never written while the chat waits for your answer to an approval question. In the first test build it overwrote the question, so the screen showed "… thinking" while the chat was in fact waiting for you.
• chat: while a turn runs you now see a status line: "… thinking · 23 s" between steps, "… running shell · 8 s" during a step. Each step ends with a short result line like "→ 84 lines". The turn ends with "done · 6 steps · 3 min 40 s". Before, the screen showed nothing between steps.
• chat: a research run the library refused at intake was announced at every start until you ran /research read on it, although there was nothing to read. It is now announced once. /research read all marks every finished run read, to clear a backlog of notices.
• chat started in a home directory could take minutes to show its prompt. At startup it walked the whole tree under the current directory to guess the project language, including hidden folders such as a 210 GB .cache. Every project walk now skips hidden folders and snap, stops after 50,000 entries, and the language guess stops after 5,000 files. The chat now starts in under a second there.

Install or update

codezaiku update now on 0.3.1 or later. Otherwise:

Linux and macOS: curl -fsSL https://codezaiku.org/install | sh

Windows (PowerShell): irm https://codezaiku.org/install.ps1 | iex

No Java on the machine? The installers take the build that carries its own runtime. Any MCP client: npx -y @wyrdsekai/codezaiku-mcp.

Debian 13 and Ubuntu 24.04 or newer: the .deb below, sudo apt install ./codezaiku_0.3.10_all.deb. It needs Java 21, which Debian 12 does not have; use the one-liner there.

License: Apache 2.0. No model included.

v0.3.9

CodeZaiku 0.3.9

This release is about codezaiku doctor. Its advice is now easier to follow, and it no longer reports the wrong context window size when the model runs behind llama-swap.

Fixed

• doctor: every "fix:" line now says what to do in plain words, with the command to run. The vulnerability scanner line gives the trivy install command for this operating system. The web search check passes when a Brave Search key is set, and no longer prints a docker run for a folder the download does not contain. The missing-model-server line points at codezaiku setup instead of a docker run with placeholders.
• doctor: the two context window checks now say in plain words what the numbers mean and what to do. The second one used to read "a host's task preamble sits on top of the pinned project block".
• doctor reported the model's context window as 8192 behind llama-swap, with a warning that no server reported one. It asked without the model's name, and llama-swap only answers for a named model. Runs were not affected; they always passed the name and read the real window.

Install or update

codezaiku update now on 0.3.1 or later. Otherwise:

Linux and macOS: curl -fsSL https://codezaiku.org/install | sh

Windows (PowerShell): irm https://codezaiku.org/install.ps1 | iex

No Java on the machine? The installers take the build that carries its own runtime. Any MCP client: npx -y @wyrdsekai/codezaiku-mcp.

Debian 13 and Ubuntu 24.04 or newer: the .deb below, sudo apt install ./codezaiku_0.3.9_all.deb. It needs Java 21, which Debian 12 does not have; use the one-liner there.

License: Apache 2.0. No model included.

v0.3.8

CodeZaiku 0.3.8

This release fixes codezaiku setup choosing a model that cannot chat.

Fixed

• setup: when a model server has more than one model, setup asked "Which model?" with the first name in the server's list as the default. Servers list their models in alphabetical order, so on a server with an embedding model the default was embed. Pressing Enter saved it, the one-word test failed, setup said "Saved anyway", and every command after that failed. Setup now says what the choice is, shows the models numbered, marks the ones that look like embedding or ranking models, and offers the model already in your settings as the default, or else the first chat model.
• setup: a model that does not answer the one-word test is not saved while another model is left to try. Setup says why and asks again. When nothing answers, for example while a model is still loading, the first choice is saved and setup says it is unchecked.
• setup: a server that lists no models asks for the model's name. A server with one model asks nothing.
• setup: an address typed with /v1 on the end, such as https://api.openai.com/v1, is probed correctly. Setup's own checks went to /v1/v1/….
• ACP: the model option no longer offers the drive's embedding models.

Install or update

codezaiku update now on 0.3.1 or later. Otherwise:

Linux and macOS: curl -fsSL https://codezaiku.org/install | sh

Windows (PowerShell): irm https://codezaiku.org/install.ps1 | iex

No Java on the machine? The installers take the build that carries its own runtime. Any MCP client: npx -y @wyrdsekai/codezaiku-mcp.

Debian 13 and Ubuntu 24.04 or newer: the .deb below, sudo apt install ./codezaiku_0.3.8_all.deb. It needs Java 21, which Debian 12 does not have; use the one-liner there.

License: Apache 2.0. No model included.

v0.3.7

CodeZaiku 0.3.7

This release fixes places where CodeZaiku could hang or act on half an answer, and brings the ACP server up to the current schema.

Fixed

• The drive client shares one HTTP client instead of building one per instance. Each client owns a thread or two, so long sessions leaked threads.
• MCP client: a server that logs a lot to stderr no longer blocks. Its stderr was never read, so the pipe filled and the server stopped.
• MCP client: a server that goes silent now fails the call after 60 seconds. The timeout was only checked when a line arrived, so a silent server hung the chat forever. Progress notifications extend the wait. CODEZAIKU_MCP_TIMEOUT_SECONDS changes the limit.
• MCP client: it reads every page of tools/list, answers ping and roots/list from the server, returns structuredContent when a tool sends no text, and leaves out arguments the model set to null. When a server dies at start, the error includes what it wrote to stderr.
• Streaming: a stream that ends without a finish reason or [DONE] is not accepted as a message. A dropped connection used to hand back half a tool call as if it were whole. The turn now falls back to a plain request. A stream that sends nothing for a whole drive timeout is closed.
• fix: the 30-second settle re-check after a failed verify now also runs when rollback is off or the target was not localized. Before, that case recorded verified=false for a service that was still coming back up.
• run and ACP file lists: a file that was already modified and is edited again by the run is now reported. So is a file the run edited and then committed.
• Harness git calls: the 20-second timeout now works. Output was read before the timeout started, so a hung git never timed out. GIT_DIR, GIT_WORK_TREE and related variables inherited from the caller are removed, so the file list comes from the workspace and not from the caller's repository. Git is run with GIT_OPTIONAL_LOCKS=0 and LC_ALL=C.
• The shell tool sets GIT_EDITOR, EDITOR, VISUAL, GIT_SEQUENCE_EDITOR, GIT_ASKPASS and SSH_ASKPASS_REQUIRE, and removes an inherited GIT_DIR. A git commit without -m fails at once instead of waiting for an editor until the timeout.
• Ops and container commands that take stdin: stdin is written while the output drains and the timeout runs. Before, a child that did not read its stdin blocked the write before the timeout had started. Container file operations now have a timeout of 120 seconds; they had none.
• web_fetch: one deadline covers the whole fetch, including the body. The request timeout stops at the response headers, so a server that trickled the body could hold a turn for as long as it liked.
• MCP server: a tool call with a missing required argument now comes back as a tool result marked isError, with the argument's name, so the calling model can read it and call again. It used to be a JSON-RPC error (-32602), which most hosts treat as a failed request and do not show to the model. An unknown tool is still a JSON-RPC error.
• The .deb now requires Java 21. It used to accept default-jre-headless, which is Java 17 on Debian 12, so the package installed there and then failed to start. On a system without Java 21, apt now refuses the install. Use the install one-liner there; it takes the build that carries its own Java runtime.
• The config file holds API keys. It is now kept at mode 600, and ~/.codezaiku at 700. With a umask of 002 both were group-readable. This is applied on every load and every write, so existing files are tightened the next time you run anything.
• A drive address ending in /v1, /v1/chat/completions or /v1/models now works. Requests used to go to /v1/v1/… and fail with 404.

Added

• ACP: tool calls and permission requests carry the tool's name (optional in schema 1.22.0).
• ACP: resource_link blocks in a prompt are used. An attached file is named in the task, relative to the workspace, so the model can read it. They used to be dropped, so "fix the bug in @Main.java" arrived as "fix the bug in".
• ACP: a usage_update after each model call, with the tokens in context and the size of the window.
• ACP: the stdio MCP servers a client passes in session/new are started, and their tools join the session as mcp_<server>_<tool>. Before, session/new failed when the list was not empty, although the protocol says every agent must take stdio servers. Each call to a remote tool asks the client for permission. A server that does not start fails session/new with what it wrote to stderr. At most 40 remote tools are used (CODEZAIKU_ACP_MCP_MAX_TOOLS), and the first prompt says when some were left out. http and sse servers are still refused.
• ACP: session/new returns a model config option with the models the drive lists, and session/set_config_option switches the session to one of them. A host can show a model picker. harbor's --model flag needs it: without it harbor stopped with "ACP agent did not advertise a model-selection mechanism". Two harbor tasks now pass through codezaiku acp with a local 27B, one of them with a stdio MCP server passed by harbor.
• What a remote MCP tool returns is labelled as another program's output and put between markers, in the chat as well as in ACP. The output cannot close its own markers.
• scripts/check-mcp-real-client.sh connects the official MCP Python SDK client to codezaiku mcp. SDK 2.2.0 opens with server/discover, gets "method not found", falls back to initialize, and works. A test pins the error code that fallback depends on.

Install or update

codezaiku update now on 0.3.1 or later. Otherwise:

Linux and macOS: curl -fsSL https://codezaiku.org/install | sh

Windows (PowerShell): irm https://codezaiku.org/install.ps1 | iex

No Java on the machine? The installers take the build that carries its own runtime. Any MCP client: npx -y @wyrdsekai/codezaiku-mcp.

Debian 13 and Ubuntu 24.04 or newer: the .deb below, sudo apt install ./codezaiku_0.3.7_all.deb. It needs Java 21, which Debian 12 does not have; use the one-liner there.

License: Apache 2.0. No model included.

v0.3.6

CodeZaiku 0.3.6

The model server's real context window behind llama-swap, and two verbs the help forgot.

Fixed

• The usage text now lists doctor and update now|status. Both existed, and the release notes told you to run update now, but codezaiku with no arguments never mentioned either.
• Behind llama-swap, which model serve install sets up, the model server's context window was never found: the proxy answers /props with "no model id" because that request names no model, so the harness assumed 8192 and compacted at a quarter of the real window. The window is now read from the proxy's per-model path, /upstream/<model>/props.

Notable changes. This project follows semantic versioning loosely: while at
0.x, minor versions may change behaviour.

Install or update

codezaiku update now on 0.3.1 or later. Otherwise:

Linux and macOS: curl -fsSL https://codezaiku.org/install | sh

Windows (PowerShell): irm https://codezaiku.org/install.ps1 | iex

No Java on the machine? The installers take the build that carries its own runtime. Any MCP client: npx -y @wyrdsekai/codezaiku-mcp.

Debian and Ubuntu: the .deb below, sudo apt install ./codezaiku_0.3.6_all.deb.

License: Apache 2.0. No model included.