Compare

Nimbalyst vs Obsidian vs VS Code: extension systems compared

A sourced comparison of how each product handles custom editors, file types, AI agent integration, and control over the model layer.

How the three systems compare

	Nimbalyst	Obsidian	VS Code
Extension model	First-class peers using the same EditorHost contract as built-in editors	Peer views via registerView. The markdown view is one viewType among many.	Host-centric extension API with custom editors, language services, views, tools, and webviews
Custom file types	Register any extension and ship a real editor inside the workspace	registerExtensions lets a plugin own any file type. The Excalidraw plugin owns .excalidraw.	File associations plus custom editors; the UI is typically implemented in a webview
AI agent integration	Heterogeneous agents (Claude Code, Codex, pluggable) talk to extensions through the same structured hooks the built-in editors use	No dedicated host-level AI or agent API. Each AI plugin ships its own provider integration with no shared contract.	Chat participants, agent-mode tools, MCP integration, Language Model API, and language-model provider extensions
Who controls the agent	You. Multiple agents are first-class and the model is pluggable	Whichever plugin you install. No coordination across AI plugins.	Mixed. Extension tools run in your extension host, but the built-in chat and model picker are still centered on Copilot
Distribution	Marketplace plus install-your-own	Community plugins directory, 2,750 plugins in the official index, initial review, full app access on desktop	Visual Studio Marketplace. Marketplace terms limit usage to 'in-scope products', and some Microsoft-published extensions enforce that in forks

VS Code: broad extension APIs, but AI lives on multiple layers

VS Code has one of the broadest extension surfaces here. Custom editors, views, language servers, chat participants, language-model tools, MCP integration, and model-provider extensions are all real extension points. The important nuance is that they do not all sit on the same architectural layer.

Custom editors are powerful, but still host-owned

VS Code's Custom Editor API lets an extension replace the default editor for a file type and build a full read/write experience. That is a serious capability. The tradeoff is architectural: the editor UI is usually a webview talking to the extension host over message passing, not the same editor contract built-in text editing uses.

Agent Mode is open to extension tools

Current AI extensibility docs explicitly position language-model tools and MCP tools as ways to participate in agent mode. That is a meaningful shift from the earlier state where the AI story was mostly chat participants and Copilot-facing surfaces.

Chat participants and Copilot Extensions are not the same thing as agent-mode tools

The current docs still describe chat participants as the way to extend Ask mode with a specialized assistant. Separately, GitHub's own community discussion #157927 says GitHub Copilot Extensions work in Ask mode but are not yet fully integrated with Agent Mode. So the AI surface is broader now, but it is split: some paths reach agent mode, others still stop at chat.

Model-provider extensions exist, but Copilot still anchors the chat surface

VS Code now supports language-model provider extensions and bring-your-own-model flows in chat, including local and third-party providers. At the same time, Microsoft's language-model docs still route parts of the experience through the Copilot service, such as embeddings, repository indexing, query refinement, intent detection, and side queries.

Marketplace policy still favors the official shell

The marketplace terms still say offerings are intended only for 'in-scope products and services', which is why forks and alternative editors continue to run into compatibility and licensing problems with some Microsoft-published extensions.

VS Code is now a real host for custom AI tools, not just Copilot chat. But its AI architecture is still split across extension-host APIs, Copilot chat surfaces, and marketplace policy, which is a different shape from 'every editor and every agent use one shared contract.'

Obsidian: peer views are first-class, the agent layer is up to you

Obsidian gets the view layer right. Plugins register custom views with the same ItemView and WorkspaceLeaf abstractions that core features use, and registerExtensions lets a plugin own any file type. The Excalidraw plugin owning `.excalidraw` is the canonical example. The architectural gap shows up at the agent layer.

Custom views are first-class

Obsidian's official API exposes ItemView, WorkspaceLeaf, registerView, and registerExtensions as normal plugin primitives. That makes custom views and file-type ownership part of the platform, not a hack around it. The official community index currently contains 2,750 plugins.

AI remains plugin-defined

Obsidian exposes a general plugin API, not a dedicated host-level AI or agent contract. If you want AI behavior, the plugin author decides the model provider, key flow, commands, and tool surface. That gives plugin authors freedom, but it does not give the ecosystem one shared agent layer.

Plugins are vetted by hand, not sandboxed

Community plugins go through an initial review before joining the official directory, but Obsidian's own security docs also say the team cannot manually review every new release. On desktop, plugins inherit Obsidian's access levels, which means they can access local files, connect to the internet, and even install additional programs. The trust model is review plus user judgment, not per-plugin permissions.

Obsidian gets first-class views right and has a deep plugin ecosystem. What it does not have is a host-level agent layer that extensions plug into. Every AI plugin reinvents its own model, tools, and conventions in isolation.

Nimbalyst: every editor is an extension

We chose the inverse of the VS Code shape. Every editor in Nimbalyst, built-in and third-party, uses the same EditorHost contract. The markdown editor, the diagram editor, the data model editor, and a third-party 3D object editor all sit on the same foundation.

First-class extension system

Every editor in Nimbalyst uses the same EditorHost contract, whether it ships built-in or comes from a third-party extension. Extensions run on the same plumbing as the markdown editor and the diagram editor. There is no second-class tier.

Real editors, not side panels

Register a file type and ship a full editor inside the workspace, not a side panel or an embedded iframe. Agents talk to your extension through the same structured hooks the built-in editors use, which means an agent that can edit markdown can edit your custom format too.

Heterogeneous agents, no vendor gating

Nimbalyst treats Claude Code and Codex as first-class agents, with other agents pluggable. The agent layer is not licensed through a single vendor's runtime. You can run the agent you want, on your terms.

Built for the long tail

Existing extensions cover an Astro website editor, a visual git log, a mindmap, a slides editor, and a 3D object editor. The extension model is built for the long tail of editors that do not exist yet.

If you want a workspace where agents and editors compose freely, where your custom file format gets the same treatment as markdown, and where the agent layer is not owned by a single vendor, the Nimbalyst extension system is built for that.

Build an editor for your data

Browse extensions in the marketplace, or open the SDK docs and ship your own.

Browse the marketplace Extension SDK docs