Claudian Review 2026: Claude Desktop, Rebuilt?

What Claudian actually is

Claudian is an Obsidian plugin. That sentence carries more weight than it looks. The repository at github.com/YishenTu/claudian shows 15,795 stars, and the description is blunt: it embeds Claude Code or Codex as an AI collaborator inside your vault. Not a chat sidebar bolted onto a notes app. A wrapper that reaches out to Anthropic's CLI tooling and pulls the result back into the place where your Markdown lives.

That framing matters because most reviews of tools like this end up grading Anthropic's model weights. Wrong target. The weights are the same weights everyone else gets. What you are actually judging is the shell: how it stores your API key, how it manages context across a vault that might hold thousands of files, how many tokens a session burns, and what happens when the process dies mid-edit. Claudian is a shell. Score the shell.

Native vs Electron

Obsidian itself is an Electron app, so Claudian inherits that runtime whether it wants to or not. There is no separate native binary to install. The plugin ships as a bundle loaded by Obsidian's plugin host, which means the memory profile is Obsidian's memory profile plus whatever the plugin adds on top. The repository does not publish a standalone installer, and there is no desktop app of its own. If you were expecting a native macOS or Windows client, that is not what this is.

The practical consequence is that Claudian's footprint is bounded by Obsidian. You are not paying for a second Chromium instance. You are paying for the plugin's own JS bundle and whatever subprocess Claude Code spawns when you invoke it. That subprocess is where the real cost lives, and it is also where the interesting failure modes live.

Local key storage

The plugin needs credentials to talk to Anthropic. The docs describe configuration through Obsidian's plugin settings, which persist to your vault's .obsidian/plugins/claudian/ directory as JSON. That is local storage in the literal sense — the file sits on your disk. It is not a keychain. It is not encrypted at rest by the plugin. If your vault syncs to iCloud, Dropbox, or a git remote, the settings file goes with it unless you exclude it.

This is the single most important thing to understand before you paste a key in. Community threads on Reddit and Hacker News have raised the sync-exposure question repeatedly, and the answer from the repository side has been consistent: the key lives where Obsidian puts plugin data. Whether that is acceptable is a judgment call about your sync setup, not about the plugin's engineering. I would exclude the plugin data directory from any cloud sync before the first launch, not after.

Which endpoints it hits

Claudian does not call the Anthropic API directly with its own HTTP client. It shells out to Claude Code (or Codex, per the description), which means the request path goes through Anthropic's official CLI. That has two consequences worth naming. First, billing flows through whatever account the CLI is authenticated against — API key or subscription, depending on how you set up Claude Code itself. Second, rate limits are Claude Code's rate limits, not a separate quota the plugin negotiates.

The model you get is whatever Claude Code is configured to use. The plugin does not appear to expose a model picker of its own in the documentation. If you want Opus instead of Sonnet, you change that in Claude Code's config, not in Claudian's settings pane.

What it does not do

No local model support. The description names Claude Code and Codex, and there is no mention of Ollama, llama.cpp, or any local inference path. If offline operation is a requirement, this is the wrong tool and the comparison table below will make that plain.

No built-in MCP server management that the docs describe as a first-class feature. Claude Code itself handles MCP; Claudian inherits whatever Claude Code has configured. No usage dashboard, no per-session cost meter, no token counter in the UI. You find out what a session cost by checking Anthropic's console afterward. No mobile support — Obsidian mobile cannot run the CLI subprocess, so the plugin is desktop-only in practice.

Install and first 10 minutes

Installation runs through Obsidian's community plugin browser. Search, install, enable. The repository is the distribution channel; there is no separate download page and no website listed for the project. That is a small signal about maturity — plugins distributed purely through the community registry tend to move at the pace of their maintainer's spare evenings.

Before the plugin does anything useful you need Claude Code installed and authenticated on the same machine. That is the real setup cost, and it is not Claudian's fault, but it is Claudian's problem. If you have never installed Claude Code, budget the time for that first: Node, npm, the CLI itself, then authentication. Only after that does the plugin have something to talk to.

The first prompt is fast once the prerequisites are met. The plugin opens a panel, you type, it dispatches to the CLI, the response streams back. There is no project wizard, no onboarding flow, no default configuration that needs tuning before the first message. The defaults are the defaults Claude Code ships with.

Permission prompts are where the friction shows up. Claude Code asks before it writes files or runs commands. Inside a terminal that is a clean yes/no in your shell. Inside Obsidian it is a modal or an inline prompt, and the docs describe the plugin surfacing those requests in its own UI. The behavior is correct — you should be asked before an agent edits your notes — but the cadence takes getting used to. A vault with a lot of small files means a lot of prompts. I would set Claude Code's permission mode deliberately before pointing it at a real vault, not leave it on the default and click through.

Default project config is whatever Claude Code picks up from the working directory. The plugin runs the CLI against your vault root, which means any CLAUDE.md at the top of the vault gets loaded. That is a useful lever: put your conventions there and the agent follows them. It is also a footgun if you have a stale CLAUDE.md from an old project sitting in the vault root.

Context and memory handling

This is where a wrapper earns or loses its keep. Claude Code has a context window; the question is how much of your vault the plugin lets you push into it and how gracefully it handles the ceiling.

The plugin does not index your vault in the way a code-aware IDE would. There is no embedding store, no symbol graph, no background crawler described in the documentation. Context comes from what you attach or what the agent reads on demand via file tools. That is a deliberate design choice and it has a clear trade-off: no index means no stale index, but it also means the agent has to spend tokens reading files to understand structure. On a small vault that is fine. On a vault with thousands of notes, the agent's exploration cost is real and it shows up on your bill.

File attach limits are governed by the model's context window, not by an arbitrary plugin cap that the docs describe. You can attach what fits. The plugin does not appear to chunk or summarize oversized attachments automatically — if a file is too big, the request fails or truncates at the API layer.

Conversation persistence is the part I would check before committing. The docs describe sessions living in the plugin's data directory. What survives a restart is the session record, not the agent's working memory of your vault. Close Obsidian, reopen it, resume a thread, and the agent has the transcript but not the file reads it did earlier unless those are in the transcript. That is normal for CLI-backed agents and it is worth internalizing: long sessions accumulate transcript, and transcript is tokens.

What does not survive: subprocess state, any in-memory index the CLI built, and permission grants you made in a previous session if Claude Code is configured to re-ask. Plan for a warm-up cost at the start of each working session.

Token burn and cost per session

Here is where I have to be careful about what can and cannot be claimed. I have not run scripted prompts against Claudian and measured token counts. What follows is a cost model built from the pricing data and from how the request path works, not from a benchmark.

The request path is Claude Code. That means every Claudian session pays Claude Code's overhead: the system prompt, the tool definitions, the CLAUDE.md load, and the file reads the agent performs to orient itself. That overhead is identical whether you invoke Claude Code from a terminal or from inside Obsidian. Claudian adds essentially nothing to the token count on top of what Claude Code already spends. The plugin is a UI layer; the tokens are the CLI's.

So the honest comparison is not Claudian vs claude.ai on raw token efficiency. It is Claude Code vs claude.ai, with Claudian as a different front door to the same room. claude.ai's web interface does its own context management and does not expose tool definitions the way the CLI does, so a chat session there tends to be cheaper per exchange for simple questions and more expensive for anything that requires reading your files. Claude Code is the opposite: heavier fixed cost, better at tasks that need filesystem access.

Pricing at current Anthropic rates, from the live snapshot: Claude Opus 4.1 and Claude Opus 4 both list at $15 per million input tokens and $75 per million output tokens. The fast Opus variants — Opus 4.7 Fast and Opus 4.6 Fast — list at $30 per million input and $150 per million output. Sonnet pricing is not in the snapshot I am working from, so I will not quote a number for it.

What that means in practice: a Claude Code session that reads twenty files at a few thousand tokens each, with a system prompt and tool definitions on top, lands in the tens of thousands of input tokens before you have asked a single question. At Opus 4 rates that is cents, not dollars, per session. At Opus 4.7 Fast rates it is roughly double. The output side is where long agent runs get expensive, because every tool call and every file edit is output tokens at $75 to $150 per million.

The lever that matters most is not the model choice. It is how much the agent reads. A vault with a clean structure and a good CLAUDE.md costs a fraction of a vault where the agent has to grep around to find anything. Claudian gives you no visibility into that spend. That is the wrapper's biggest cost-side weakness: no meter, no per-session summary, no warning when a thread has accumulated a large transcript. You find out at the console.

Claudian vs Claude Code vs Cherry Studio

Three tools, three different bets about where AI should live.

The Claudian vs Claude Code question is almost a non-question. Claudian calls Claude Code. If you do not have Claude Code installed and working, Claudian has nothing to wrap. The real decision is whether you want the agent's output landing in your vault with Obsidian's editing surface around it, or in a terminal where you can pipe it, script it, and see the raw transcript. For note-taking and knowledge work, the vault context is worth a lot. For code, the terminal is still better and the Claude Code tool page covers that ground in more detail.

Cherry Studio is the more interesting comparison because it makes the opposite bet. It is a general desktop client that lets you point at many providers, including local models, and it does not care about your vault. If provider flexibility and offline operation matter more than Obsidian integration, Cherry Studio wins on those axes outright. Our Cherry Studio review goes through the trade-offs. If you are routing through an aggregator rather than Anthropic directly, the OpenRouter review is the relevant read.

For developers weighing an editor-integrated agent against a terminal one, the Claude Code vs Cursor comparison covers the IDE side of the same decision.

Limits and failure cases

Rate limits are Claude Code's. When Anthropic throttles the CLI, Claudian throttles with it, and the error surfaces in the plugin's panel. There is no retry queue, no backoff indicator beyond whatever the CLI prints. During a heavy agent run that hits a limit mid-edit, you get a partial result and a message. The plugin does not roll back file writes.

Big-repo lag is the failure mode I would worry about most. Obsidian vaults are not repos, but they can be large — thousands of Markdown files, attachments, PDFs. The plugin does not index, so the agent explores by reading. On a vault that size, exploration is slow and expensive. The docs do not describe a file-count ceiling, but the practical ceiling is the context window and your patience. I would not point this at a 10,000-note vault without a curated CLAUDE.md and a habit of attaching specific files rather than asking open-ended questions.

Platform gaps: Obsidian mobile cannot spawn the CLI subprocess, so the plugin is desktop-only. Between Windows and macOS, the CLI itself behaves slightly differently around paths and shell quoting, and those differences leak through. The repository's issue tracker is where you would check whether a specific platform problem is known; the open-issue count moves week to week and any number I quote would be stale by publication.

Telemetry is the question the community keeps asking. Claude Code sends usage data to Anthropic per its own configuration; Claudian sits on top of that and does not appear to add a separate telemetry channel of its own, based on the repository. The privacy surface is therefore Claude Code's privacy surface plus the local key file. That key file is the thing to secure. Exclude it from sync, do not commit it, and rotate the key if the vault ever leaves your control.

Verdict: who should install it

Install it if you already live in Obsidian, you already have Claude Code working, and you want the agent's edits landing directly in your notes with the editor's undo history around them. That is a real workflow improvement and the 15,795 stars suggest a lot of people agree.

Skip it if you want local models, if you need offline operation, if you are on mobile, if you want a cost meter, or if you have never set up Claude Code and are hoping this plugin saves you that step. It does not. Skip it too if your vault syncs to a cloud service and you are not prepared to exclude the plugin data directory.

Scores across five axes, out of 5:

• Context handling: 3.5. No index is a defensible choice, but the agent's exploration cost is invisible and unbounded.
• Cost transparency: 2.0. No meter, no per-session summary, no warning. You learn cost at the console.
• Key handling: 2.5. Local storage is honest but unencrypted and sync-exposed by default.
• Integration quality: 4.5. The Obsidian fit is the whole point and it delivers.
• Setup friction: 3.0. Fast once Claude Code exists; the prerequisite is the tax.

Weighted, that lands at 3.1 out of 5. A good wrapper around a tool you probably already have, with a cost-visibility gap and a key-storage habit that needs manual correction. Worth installing for the right user. Not worth installing to avoid setting up Claude Code.

Beetlix is our own product, and where it overlaps is the orchestration layer — routing work across models and tracking what each run costs. Claudian does not attempt that, so the comparison is thin: if the missing cost meter is the thing that bothers you, Beetlix is built around that problem, and Claudian is not trying to solve it.

How this review was researched

Sources: the Claudian repository at github.com/YishenTu/claudian (15,795 stars at snapshot), the plugin's documentation as published in the repo, Anthropic's official pricing page and the live model pricing snapshot used across this publication, and community discussion on Reddit and Hacker News regarding key storage and telemetry. No hands-on testing was performed for this review. Cost figures are modeled from the published per-million-token rates and the known request path through Claude Code, not measured from scripted runs.