KatmerCode: four AI CLIs behind one Obsidian sidebar, and what the inline diff costs

Three releases in fifty-three minutes, then months of pushes with no tag

All three GitHub releases were published on the same afternoon. `0.5.0` carrying multi-provider support went out at 11:01 on 2026-05-26, `0.5.1` with community plugin compliance at 11:32, and `0.5.2` with review hygiene and a refreshed screenshot at 11:54. That is a fifty-three minute window for the whole version history.

The last push to the default branch is dated 2026-09-15, roughly three and a half months after that afternoon, and no fourth tag exists. `package.json` still declares `version = 0.5.2`, so the packaged version number and the newest release agree with each other and both sit behind the source tree. The practical consequence is that anyone following a tag gets May code, and anyone building from a clone gets code the release notes never described. `CHANGELOG.md` and a `versions.json` file are both in the tree, so there may be a record of what changed since, but the tags themselves stop at 0.5.2.

The npm package is still named obsidian-claude-native

The repository is `katmer-code`, the plugin is presented as KatmerCode, and the package name inside `package.json` is `obsidian-claude-native`. The manifest description has been updated to four providers, and the package name has not. That matters if you resolve the plugin through a registry or cache: the identifier that predates Gemini, Codex and Antigravity is still the one in the metadata.

The dependency list shows the same mix of care. Four devDependencies are pinned to exact versions, including `esbuild` at `0.20.0` and `typescript` at `5.3.3`, while `obsidian` is set to `latest` with no version at all. A build on a different day can therefore pull a different Obsidian type surface than the one the pinned toolchain was written against. Runtime dependencies are tighter: `diff-match-patch` at `1.0.5` is the word-level diff engine behind inline editing, with `@codemirror/state` and `@codemirror/view` supplying the editor integration and the Claude Agent SDK pinned exactly.

Installation means copying three files into the vault yourself

There is no plugin marketplace entry in the flow. You install provider CLIs, build the plugin, then copy the output into the vault:

npm install -g @anthropic-ai/claude-code && claude
npm install -g @google/gemini-cli && gemini
npm install -g @openai/codex && codex login
curl -fsSL https://antigravity.google/cli/install.sh | bash && agy
git clone https://github.com/hkcanan/katmer-code.git && cd katmer-code && npm install && npm run build

Then `main.js`, `manifest.json` and `styles.css` go into `<your-vault>/.obsidian/plugins/katmer-code/`, and the plugin is switched on under Obsidian settings for community plugins. The build script runs `tsc -noEmit -skipLibCheck` before esbuild, so type errors stop the bundle rather than shipping. This is desktop only, and it needs the CLI for whichever provider you intend to use, not all four. An optional toggle auto-mirrors `CLAUDE.md` to the other providers, and the academic skills additionally need Obsidian's Allow Web Requests turned on.

Codex edits in place because its CLI never exposes old and new text

Inline diff editing is not uniform across providers, and the plugin says so rather than pretending. Claude and Gemini get word-level track changes rendered in the editor, with removed text struck through, additions underlined, and accept or undo controls. Gemini reaches that state because its `replace` tool is aliased to Edit.

Codex is the exception. Its CLI applies edits directly and does not expose old and new text, so there is nothing for the editor to diff against and the change simply lands. A reader comparing the two experiences should know that the inline diff is a capability of two backends, not a property of the sidebar.

The same asymmetry shows up elsewhere. Claude is the only provider listed with the full feature set, including streaming, tools, thinking blocks and MCP. Reasoning effort is wired for Claude through the SDK's `effort` and for Codex through `model_reasoning_effort`, while Gemini's `thinking_level` is API-only until the CLI exposes it, so the effort control hides itself where it would do nothing.

One skill file, four backends, two very different execution paths

Seven academic research skills install as slash commands, and they resolve through different mechanisms depending on the provider. On Claude they run natively, reading from `~/.claude/commands/`. On Gemini, Codex and Antigravity the same markdown is injected as a prompt. The claim is one markdown file and one output shape across four backends, and the mechanism behind that claim is two different kinds of execution.

The skills query real academic databases, named as Semantic Scholar, CrossRef, OpenAlex, Unpaywall, arXiv and PubMed, then produce an HTML report with tables and charts that opens inside Obsidian or a browser. `/peer-review` scores eight criteria and draws a radar chart; `/cite-verify` works claim by claim and can flag a valid reference as unverified when a database lacks coverage. The documentation is direct about the ceiling: these are research aids rather than oracles, a peer review report will not replace a human reviewer, and the output is a map rather than the territory.

Context windows come from a per-model catalog, not a single fallback number

The context strip reports real input tokens against the window of whichever model is answering, and the numbers differ by provider. Gemini 2.5 and the 3.x family are listed at 1M, Codex on GPT-5.x at 400K, and Claude across a 200K to 1M range. The catalog is described as the source rather than a generic 200K default, which means the figure depends on the plugin recognizing the model in front of it.

Two other provider facts ride along in the same catalog-driven approach. MCP servers need no extra setup because each provider reads its own configuration, `~/.claude.json`, `~/.gemini/` and `~/.codex/`, so enabling a server is a provider-side edit rather than a plugin setting. And mid-thread provider changes are marked with a horizontal divider plus a warning that previous context is not carried across CLIs, which is the honest counterpart to the per-tab routing that makes switching convenient in the first place.

Auto-mirroring writes GEMINI.md and AGENTS.md in two scopes

The optional shared-instructions toggle mirrors `CLAUDE.md` into `GEMINI.md` and `AGENTS.md`, at global scope and at vault scope, and the files are watched and re-synced on edit. The reasoning is that each CLI reads a different instruction filename, so a vault written for Claude Code would otherwise reach only one of the four backends. Watched files mean the mirror also repairs drift when one of the files is edited outside the plugin.

What the toggle does not say is how conflicts resolve. If `GEMINI.md` already holds hand-written rules and `CLAUDE.md` is mirrored over it, the documentation gives no precedence rule and no merge step. Treat the mirror as one-directional and check the destination files before switching it on in a vault where those names are already in use.

Antigravity is the fourth backend and the narrowest one. It shares the Google login with Gemini through `agy` browser auth, is chat only because `agy` v1.0.2 does not expose structured output, and is described as a migration path ahead of the Gemini CLI sunset on June 18 2026 for Google AI Pro accounts. That date has passed, so the framing in the README now describes a window that has already closed.

Editorial conclusion

KatmerCode is for people who already have two or more provider CLIs authenticated and want to compare takes without leaving Obsidian. Its honest core is the ProviderAdapter seam and the admission that the backends differ: Codex cannot render a word-level diff, Gemini has no effort control until its CLI exposes one, and the same skill file runs natively on Claude but as prompt injection on the other three. Check which provider CLIs you actually have before anything else, since the plugin is desktop only and the install step copies three built files into your vault by hand. And build from the current tree rather than expecting the 0.5.2 tag to match it, because the tag was published in May 2026 while pushes have continued since.

Frequently asked questions

Official sources

1. hkcanan/katmer-code on GitHub
2. Issues
3. License: MIT
4. README
5. Releases