Gemini Scribe: four AI providers behind one Obsidian plugin

One plugin, four backends, and the routing table between them

Gemini Scribe is an Obsidian plugin that integrates Google's Gemini AI models, providing AI-driven assistance for note-taking, writing and knowledge management directly within Obsidian. The stated mechanism is simple: it uses your notes as context for AI interactions, making it a highly personalized and integrated experience.

What has changed over the 4.x line is the number of backends. The plugin settings now hold a Providers page, and you connect a provider there, then route each feature to a provider on a separate Features page. A provider capability matrix at `docs/reference/provider-capabilities.md` records what is supported on each.

The four provider cards are worth reading individually, because they differ in more than the vendor name.

Google Gemini (cloud) requires a Gemini API key, and a free tier is available at Google AI Studio. Ollama runs on your machine with no API key at all, which is the only option where nothing leaves the host, though cloud models in the Ollama picker, marked as cloud in the UI, are forwarded to ollama.com. OpenAI (cloud) takes your own OpenAI API key, or you can point it at an OpenAI-compatible server such as LM Studio or MLX with any placeholder key. Anthropic (cloud) takes your own Anthropic API key and runs Claude models, with adaptive thinking and image and PDF input.

The routing model is the part that makes this more than a single-provider plugin. Chat, summaries, completions, rewrite, web search, deep research, RAG and image generation each route to their own provider and model. A feature routed to a provider that is not set up stays off, and does not silently fall back to another provider. That last property matters more than it sounds, because a silent fallback is how a note about a client's name ends up in a request to a provider you did not choose for that feature.

What the 4.12 and 4.13 releases changed, and the speed of the churn

The release notes are unusually detailed, which makes them the best available description of what the plugin actually does.

Version 4.12 was the multi-provider release. It added the Anthropic and OpenAI-compatible providers, each with streaming and tool calling, added per-feature routing, and rebuilt the settings page with provider connection cards and a Features routing table, built on Obsidian 1.13's settings API. Obsolete toggles were removed, including streaming, the Interactions API, temperature and top-p, retry, loop detection, MCP enable, and a system-prompt override described as ineffective, and existing settings migrate automatically.

Version 4.13.0, released 2026-10-18, added a searchable model picker so the dropdowns are a fuzzy-search picker and you can find a model by typing part of its name or id, and the release notes motivate it with long lists like OpenRouter's 458 models. It also added a skill button, a wand button in the send bar that opens the skill picker, multi-line paste that keeps line breaks, and selectable responses so you can copy part of an answer.

Two fixes in 4.13.0 are worth singling out because they are about safety rather than convenience. Anthropic context compaction no longer fails with a 400, removing a limitation the 4.12 notes had listed. And output paths are validated so scheduled tasks and hooks cannot write into `.obsidian` or the plugin's own state folders, with the Open result link now pointing to the note that was actually written.

The 4.12.1 patch was about Obsidian's own audit rather than features. The 4.12.0 build was flagged by Obsidian's plugin audit, and the code now passes it without suppressing any checks: destructive buttons use Obsidian's own destructive styling, agent progress and thinking indicators render with Obsidian's DOM helpers, the OAuth callback server only loads on desktop, and the mobile layout fix no longer relies on inline or `!important` styles.

The cadence is the thing to note. Versions 4.12.0 and 4.12.1 landed within days of each other in late September 2026, and 4.13.0 followed on 2026-10-18, with the last push to the tree on 2026-10-20. This is a project shipping roughly monthly with patch releases in between, and the release notes read like a work log rather than a marketing page.

Building the plugin from source, and the checks the project runs on itself

The plugin is a TypeScript project built with esbuild and tested with vitest, and the package manifest documents the whole workflow.

The build script regenerates the help references, type checks without emitting, and then runs esbuild in production mode.

		"build": "npm run generate-refs && tsc -noEmit -skipLibCheck && node esbuild.config.mjs production",

The test script follows the same pattern, regenerating references first and then running vitest.

		"test": "npm run generate-refs && vitest run",

The rest of the script list shows how seriously the project treats its own quality gates. There is a separate type check for the test project, a `lint:cycles` script that runs madge with `--circular` over the TypeScript sources, a `check:fields` script for unread fields, a `knip` script for unused code, a `lint:actions` script that checks action pins, and an `install:test-vault` script that installs a test vault for integration work.

The eval scripts are the most interesting part of the list. There is `eval`, `eval:compare`, `eval:bless`, and two calibration scripts, `eval:calibrate-extract` and `eval:calibrate-judge`, all under an `evals/` directory. The naming suggests a two-stage evaluation with an extraction pass and a judging pass, each separately calibrated, and a bless step that records a known-good result. For a plugin whose output is generated prose, that is the only way to test the parts that are not deterministic.

The documentation has its own toolchain, with VitePress for the dev server, the build and a preview command.

		"docs:dev": "vitepress dev docs",

The repository also carries an `AGENTS.md`, a `CLAUDE.md`, a `GEMINI.md`, an `AI_POLICY.md`, a `SKILL_SOURCES.md`, an `esbuild.config.mjs`, an `eslint.config.mjs`, a `knip.json`, a `vitest.config.ts` and a `styles.css`, plus `.husky/` and a `prepare` script of `husky` for commit hooks, and a `version-bump.mjs` that stamps the manifest and `versions.json` and pushes on the postversion hook.

The agent view: tools, sessions, and what the release notes reveal about failure

The plugin's agent surface is where the engineering shows, and the 4.12 release notes describe it in enough detail to be worth reading as a specification.

The stated principle is that tool results always stay paired with their calls in replayed turns, tool-call ids survive into function responses, a failed tool ends the turn by default again with that behaviour configurable, the loop detector shows a notice on its first fire, retry backoff yields to cancellation, Stop aborts the underlying stream, and the token readout now shows reasoning tokens.

Each of those is a specific failure mode being closed. A tool result that gets separated from its call breaks the message history the model sees. A tool call id that does not survive into the function response breaks provider APIs that require the pairing. A failed tool that does not end the turn leaves the agent looping. A loop detector that fires silently is indistinguishable from a hang. Retry backoff that ignores cancellation means a cancelled request keeps retrying. These are the details that decide whether an agent feels reliable or feels haunted.

The `generate_image` tool registration rule in 4.12.1 is a nice piece of design. The tool is registered only when image generation is routed to a provider that is actually connected, so it no longer appears and then fails with a missing key. Registering the tool conditionally makes the available tool list an accurate description of what the agent can do, which matters for a model that plans based on the tools it is given.

Prompts are also a first-class concept. The 4.13.0 notes describe a distinction between session prompts and selection prompts, with the latter tagged `gemini-scribe/selection-prompt`, and the Apply prompt action now explains that tag when you have untagged prompts, with new prompts shipping instructions for adding it. The distinction exists because a prompt meant for the current selection is a different thing from a prompt meant for the session, and mixing them in one list made both harder to use.

The repository also carries a `prompts/` directory, a `skills/` mechanism with a `skills-lock.json`, a `planning/` directory, and a `SKILL_SOURCES.md`.

Where the plugin is the wrong choice

Three limitations are visible in the release notes, and none of them is a bug.

The first is churn. The plugin is at 4.13.0 and the settings page was rebuilt in 4.12 with a migration path, and the release notes call out an ineffective system-prompt override that was removed along with temperature, top-p, retry and MCP toggles. If you are building an automation on top of this plugin, the surface moves. The plugin's own design answers that concern partly, with the settings migration and the removal of ineffective toggles, but a weekly release cadence means your integration has to be checked regularly rather than pinned and forgotten.

The second is that the feature set is unevenly supported across providers, and the plugin is honest about it rather than hiding it. The provider capability matrix exists precisely because the answer is not uniform. The Interactions API transport is on by default for Gemini requests and thought signatures are carried correctly through streaming and non-streaming tool calls, but that is a Gemini path. An Anthropic route with adaptive thinking behaves differently, and an OpenAI-compatible server such as LM Studio may not implement everything the OpenAI API does. The practical consequence is that you choose a provider per feature based on what that provider supports, not on preference.

The third is the Ollama nuance that is easy to misread. Ollama runs on your machine with no API key, but Ollama cloud models, marked as cloud in the picker, are forwarded to ollama.com. If your requirement is that nothing leaves the machine, you need to check the model you pick, not just the provider card.

The alternative approach is to keep the AI outside the editor. A separate assistant that reads exported notes, or a plugin that calls a script you control, gives you a narrow, stable interface: your own code, your own provider key handling, your own context assembly. The difference in approach is that Gemini Scribe ships a whole agent surface, with tools, sessions, hooks, scheduled tasks, prompts and skills, and the cost of that is a large moving target. A separate script is less capable and far more predictable, and for a note taker who wants their vault to be AI context without adopting an agent framework, that is often the better trade.

Editorial conclusion

Adopt Gemini Scribe if you write in Obsidian and want your notes used as AI context with the provider chosen per feature, particularly if you want a local Ollama model for some of that and a cloud model for the rest. Do not adopt it if you need a stable plugin API to build against, since the release notes describe an API that keeps evolving and a settings page that was rebuilt in 4.12. Before you connect a provider, read the provider capability matrix at `docs/reference/provider-capabilities.md` so you know which features each backend actually supports, and route a feature only to a provider you have already configured, since the plugin deliberately leaves an unconfigured feature off instead of falling back silently.

Frequently asked questions

Official sources

1. allenhutchison/obsidian-gemini on GitHub
2. License: MIT
3. Project website
4. README
5. Releases