obsidian-local-gpt runs Ollama models inside Obsidian without cloud calls
Local Ollama and OpenAI-like GPT's assistance for maximum privacy and offline access
At a glance
- What is it?
- obsidian-local-gpt is an Obsidian plugin that sends selected text to a local Ollama model or another provider configured through the AI Providers plugin, offering a context menu, an Action Palette and retrieval over links, backlinks and PDFs. It is a front end for a model you already run, and its privacy claim depends on which provider you point it at.
- Who is it for?
- Adopt obsidian-local-gpt if you write in Obsidian, already run a local model, and want a private writing loop that never sends notes to a hosted endpoint, and if you are willing to install a second plugin and configure a provider.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A plugin that is really a front end for a model you already run
The name is slightly misleading if you take it literally. obsidian-local-gpt does not contain a language model. It is a TypeScript Obsidian plugin that talks to a provider, and the provider is configured in a separate plugin called AI Providers, which the README describes as a hub for AI providers and the author's own project.
The interaction model is simple and deliberately casual. You select text in a note, open a context menu on that selection and pick an assistant action, or you open the Action Palette and run a one-time action. The default actions are the ones any writing assistant needs: continue writing, summarize text, fix spelling and grammar, find action items in text, a general help action that uses the selected text as a prompt for any purpose, and a new system prompt action for defining your own.
What the plugin adds on top of a raw API call is keyboard behaviour. The README is specific about it, and the details are the point. Enter submits the prompt when a slash or at-sign search has no results, Escape closes the search menu, and Shift+Enter inserts a newline. Clicking the Creativity chip keeps keyboard selection available with the arrow keys and Enter, and when text is selected a replace icon appears next to the chips, so you can press Alt+R, or the macOS equivalent, to replace the selection with the answer instead of inserting it below. The README notes that this choice is remembered until Obsidian restarts, which tells you the setting is session state rather than persisted configuration.
The privacy framing in the project description is about local Ollama and offline access, and the screenshots are labelled with the hardware they were taken on, a MacBook Pro 13 with an M1 and 16GB running Ollama, with the captions stating no speedup. That is an honest framing: the plugin is fast, but the model is not.
Retrieval over links, backlinks and PDF attachments
The feature the README calls Enhanced Actions pulls context from your vault rather than only from the text you highlighted. The heading puts links, backlinks and even PDF files in the same sentence, which is a meaningful claim: a PDF attachment in a note is not text Obsidian can read natively, so any plugin that retrieves from it is doing extra work.
The mechanism requires an embedding model, and the README gives the setup for Ollama in two steps. First you install an embedding model, and the choice depends on the language of your notes: nomic-embed-text for English, described as the fastest option, or bge-m3 for other languages, described as slower but more accurate. Second, you select the embedding provider in the plugin settings and use the largest model with the largest context window you can.
Each model is pulled with the ollama pull command, so the English path is ollama pull nomic-embed-text and the path for other supported languages is ollama pull bge-m3. Choosing the wrong one is the most likely reason for disappointing retrieval quality, and the README makes the trade-off explicit rather than leaving it to chance.
The plugin also handles images, with a screenshot taken on the same M1 MacBook Pro using Ollama and the bakllava model. Since the plugin is TypeScript with a Svelte interface and depends on the AI Providers SDK, the model interface itself comes from the provider layer, and this plugin is the Obsidian-shaped part of it.
Reasoning modes come from the provider, not from a table in the plugin
The reasoning section is the most carefully worded part of the README, and it describes a deliberate constraint. Local GPT reads the manually declared modes of each model from AI Providers. Its own provider defaults and saved-action overrides apply only inside Local GPT, while actions can inherit the provider setting, select a declared native mode, or choose API default to omit the parameter.
Two clarifications matter. API default does not mean thinking is disabled; it means the parameter is not sent. And the SDK owns the native request serialization, which the README follows with a flat statement that Local GPT has no provider mode table, no JSON parameter editor and no invented thinking budget. Visible provider-supplied thinking text keeps its existing presentation, and mode selection does not create or expose hidden reasoning text.
In practice, you pick a mode per request in the Action Palette with the slash command or by clicking the reasoning badge, and the choice resets when you reopen the palette or change provider or model, so a one-request selection cannot carry across models. The badge previews the selected model's setting, while the status beside the generated response shows the actual model and mode after vision routing, which is a small but useful distinction when an image request lands on a different model than you expected.
Creativity works the same way, offering API default so that temperature is omitted entirely. New or legacy settings without a Creativity value also omit it, and existing explicit choices are preserved, including None, which is numeric zero. Actions inherit an explicitly set global choice unless they specify a number or choose API default themselves, and the palette's API default overrides the global choice for that request. The README also notes that no model name affects sampling and that endpoint incompatibility errors remain visible rather than being swallowed.
There is an explicit disclaimer that no response-time improvement is promised, which is the correct expectation for a plugin that mostly forwards requests.
Community actions, auto-updates and how to freeze one
Actions can be shared. The README describes browsing and installing community actions directly from the plugin settings, and states that community actions are automatically updated to the latest version. That default is convenient until it is not, so the escape hatch is documented precisely: to stick with a specific version or preserve your changes, modify the Prompt or System Prompt of the action, which disables auto-updates for that action. The README adds the detail that changing the Name of the action does not disable auto-updates, which is exactly the kind of gotcha that costs someone an afternoon.
The same paragraph explains what happens to your preferences when an action updates: community updates preserve local action preferences, and sharing an action excludes them. So a preference set on an action you copied from the community survives an update, but anything you send to somebody else arrives without your local settings.
The plugin's own action creation path is the new system prompt action, so a custom action is a prompt and a system prompt, not code. That keeps the model-facing configuration in text, which is also what makes the RAG and reasoning features work, since the model decides what to retrieve and how to reason based on those texts.
The project is MIT licensed, and the repository is TypeScript with an esbuild build, a Svelte interface, and a check script that runs lint, typecheck and tests together. The recent release numbers, 4.3.10, 4.3.9 and 4.3.8, all dated within the last week, show a project shipping frequently.
Installing the plugin is a three-step affair with a second plugin in the middle
Installation is documented as three numbered steps, and step two is the one people miss. Step one is installing the plugin itself, either from the Obsidian community plugin store, which the README marks as recommended, or through BRAT, the plugin that installs from a GitHub repository, in which case you give it the repository name pfrankov/obsidian-local-gpt.
Step two is installing the AI Providers plugin from the plugin store. The README is explicit that you also need it, because that is where providers are configured. Step three is to follow the AI Providers instructions for creating a provider.
Configuring hotkeys comes next, and it is a five-step Obsidian procedure. You open Obsidian Settings, go to Hotkeys, filter for Local, and you should see the Local GPT: Show context menu command. You click the plus icon and press a hotkey, for example Command+M. You filter for Local again, see Local GPT: Action Palette, click the plus icon and press another, for example Command+J. The README includes the macOS symbols in its examples, so the mapping is written for a Mac keyboard but the underlying procedure is the standard one.
Two practical notes for a reviewer. The plugin manifest requires Obsidian 1.12.3 or later according to the devDependencies, so a current Obsidian is needed. And the plugin is not standalone in any sense: without a provider configured in AI Providers, the actions have nothing to call.
Where the local privacy story gets complicated
The security and privacy case for this plugin is real but conditional. The plugin is a client. What leaves your machine depends entirely on which provider you configure in AI Providers, and the README is careful to frame the plugin around local Ollama rather than claiming the plugin itself prevents network calls. Configure a local Ollama instance and the traffic stays on your machine, with the model weights and the inference hardware under your control. Configure a hosted provider and you have an ordinary cloud assistant with an Obsidian interface, which may still be the right choice for a model you cannot run locally, but it is not the privacy story the project name implies.
The retrieval feature widens the exposure question. When a prompt pulls context from links, backlinks and PDF attachments, more of your vault can travel with a request than the text you highlighted. That is the point of the feature, and it is also the place where a privacy-conscious user should be most careful about which provider receives the assembled context.
The other limitation is the one common to every local model workflow: quality is bounded by the model you have, and the hardware you have. The screenshots are labelled with an M1 MacBook Pro with 16GB of memory, and the captions say no speedup, which means the plugin adds no acceleration of its own. Running a large model for the RAG path, with the README's advice to use the largest model with the largest context window, has a hardware cost that the plugin cannot hide.
The alternative to a plugin like this is using the provider's own interface or a general assistant with a vault integration, where the difference is that those tools assume a hosted model and a browser context, while this one assumes a model you have already decided to run and an editor you already use daily. The project is also inspired by Obsidian Ollama, which the README credits, so the plugin-aware approach to local models in this editor has more than one implementation.
Editorial conclusion
Adopt obsidian-local-gpt if you write in Obsidian, already run a local model, and want a private writing loop that never sends notes to a hosted endpoint, and if you are willing to install a second plugin and configure a provider. Do not adopt it if you expect the plugin to run a model for you, since it is a client and the model, its context window and its hardware requirements are yours to provide, and do not treat the privacy claim as unconditional if you configure a remote provider in AI Providers. Verify first that your chosen provider is reachable, that the embedding model you pull for retrieval works in your language, since the README offers a different model per language, and that the version you install matches the 4.3.10 release, whose published cadence shows several releases within the last week.
Frequently asked questions
What does obsidian-local-gpt need before it works?
You need the plugin itself, installed from the Obsidian community plugin store or through BRAT, plus the AI Providers plugin from the store, because providers are configured there rather than inside Local GPT. After that you create a provider following the AI Providers instructions.
Which embedding model should I pull for the RAG features?
For English the README recommends nomic-embed-text, described as the fastest option, and for other languages it recommends bge-m3, which is slower but more accurate. You then select the embedding provider in the plugin settings and use the largest model with the largest context window.
How do I stop a community action from updating automatically?
Modify the Prompt or the System Prompt of that action, which disables auto-updates for it. Changing the Name of the action does not disable auto-updates, and community updates preserve your local action preferences while a shared action excludes them.
What does the reasoning mode setting actually do?
Local GPT reads the manually declared modes of each model from AI Providers, and actions can inherit the provider setting, select a declared native mode, or choose API default to omit the parameter. API default does not mean thinking is disabled, and the SDK owns the native request serialization.
Does obsidian-local-gpt work without Ollama?
The plugin does not contain a model. It sends requests to a provider configured in the AI Providers plugin, which can be a local Ollama instance or another provider you set up, and the project description highlights local Ollama and offline access for privacy.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/pfrankov-obsidian-local-gpt)Was this useful?