Building summaries into the Obsidian editor

I built Obsidian AI Summarize because I wanted a summary without moving a note into a separate chat. The plugin sent selected text to OpenAI and placed the response back in Obsidian.

This is an account of that work, revised on 13 October 2026 from the existing project notes. It is not a guide to the plugin's current model support or installation.

Start with the selection

The selection was the input boundary. The plugin worked on the passage the user chose rather than asking them to prepare a separate document.

I added an action to the editor context menu and a command for keyboard use. Both led to the same summary request. The settings held the API key, model choice, prompt, and output limit.

The selected text left Obsidian for the external API. Keeping the interaction inside the editor did not make the processing local.

Output placement changes the feature

Replacing a passage and adding a summary beside it are different editing decisions. One removes the original from that location. The other keeps it available for comparison.

The plugin supported replacing the selection, inserting below it, and storing a summary in the note's YAML properties. For the property update, I used Obsidian's processFrontMatter API rather than editing YAML as raw text.

The placement setting mattered as much as the prompt. It determined whether the result became part of the note body or metadata that other note tools could read.

Show the response while it runs

Streaming made progress visible before the full response arrived. It also introduced editor-state problems. A second run or a cancellation could arrive while the first request was still producing text.

I used run IDs and cancellation controls to keep requests separate. Controlled editor updates avoided redrawing on every small response fragment.

For input that needed several requests, progress indicators showed which part was being processed. They explained the wait without claiming to know exactly when the summary would finish.

Splitting a note has a cost

A long selection could exceed a model's input limit. The plugin estimated its size, split at paragraph boundaries, summarized the pieces, and combined the partial summaries.

That made longer selections possible, but it also introduced another summarization step. A connection between two sections could disappear before the final summary saw it. I would not describe that as support for documents of any size without loss of context.

The output limit controlled the requested summary length. It did not guarantee that every important detail survived.

Keep settings for different kinds of notes

Research notes and meeting notes often need different prompts and output locations. Profiles grouped those settings so users could switch between them without editing each field again.

I also kept the note title in the request context. A title could help frame the selected passage, although it could not replace information missing from the passage itself.

The editor work mattered most

The API request was only one part of the plugin. Selection handling, output placement, progress, and cancellation determined whether the feature fit the way someone wrote notes.

The project account includes more of the interface. The Obsidian AI Summarize repository is the destination for source code and setup instructions.