DeepSeek++ Adds an Agent Layer on Top of the DeepSeek Web Chat
DeepSeek Web browser extension: AI agent workspace with MCP tools, memory, Skills, automation, web search, and conversation export.
At a glance
- What is it?
- DeepSeek++ is an Apache-2.0 browser extension for Chrome, Edge and Firefox that turns the DeepSeek web client into a workspace with MCP tools, memory, Skills, conversation export and scheduled automation. The interesting part is not the feature list but how it executes tool calls: by parsing them out of the model's own output and rendering the results as native-looking blocks.
- Who is it for?
- Adopt DeepSeek++ if you already work inside chat.deepseek.com and want tool execution, memory, export and scheduled runs without moving to a different client. Do not adopt it if you need a headless or server-side agent, since the extension lives in a browser tab and depends on a logged-in web session.
- Can I use it commercially?
- Yes. Apache-2.0 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 33 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 September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap DeepSeek++ fills is the web client, not the model
chat.deepseek.com is a chat interface. It has no tool registry, no persistent store for facts you want carried across conversations, and no scheduler. DeepSeek++ is a browser extension that adds those three things inside the page rather than replacing it. The README frames the project as turning DeepSeek Web into an "AI agent workspace", and the feature table maps each capability to a user need: MCP tools, long-term memory, Skills as slash-command workflows, project context, artifact downloads, conversation export, saved snippets and automation.
The target user is someone who already pays for or uses DeepSeek through the website and does not want to migrate to a different client or wire up an API integration. That is a narrower audience than the topic list suggests. There is no server component described, no hosted backend, and the README repeats the phrase "local-first" for project context, memory and generated artifacts. Everything runs in the extension and, for some features, in a native messaging host on the same machine.
How tool calling works without an API tool-use channel
This is the part worth understanding before installing. The extension does not call a function-calling endpoint. According to the README, the model emits a tool call request in its text output, and the extension "automatically recognizes and executes" it, then renders the outcome as a collapsed block that looks like the native "thinking" UI, labelled for example as two tool invocations with results listed underneath. Multiple calls can run inside a single reply.
That design has consequences. It means the extension is parsing model output, which is inherently less structured than a JSON schema response, and it means the tool protocol is only as reliable as the model's adherence to whatever format the extension prompts for. The README does not describe a validation or retry path for malformed calls, so treat that as unverified. The upside is that it works against the web client as it exists, with no API key required for the sidebar conversation when you are on a DeepSeek page. An official API key is only needed to use sidebar chat and right-click scenarios on ordinary, non-DeepSeek pages.
Tool execution records survive a page refresh, per the README, which implies they are persisted rather than held in memory. The README does not say where.
Local file reads are the one place the extension takes control back from the model
The local_file_read tool is described with unusual specificity, and it is the most defensible engineering decision in the material. For files larger than a single read window, the extension loops deterministically on its own side instead of asking the model to continue reading. The README calls the previous behaviour a silent truncation risk and says this removes it. Continuation offsets advance by Unicode code point rather than UTF-16 code unit, so files mixing emoji and Chinese text concatenate without character loss. The host reads character windows on demand by byte offset instead of loading the whole file, which the README presents as protection against out-of-memory failures on very large files.
Two things are worth flagging. First, this only applies to the local file path, which requires the native host; the browser-only features do not get this treatment. Second, code-point stepping is correct for text but the README says nothing about binary files, encodings other than the one the host assumes, or files that change while being read. If you plan to point this at logs that are still being written, that is an untested case.
Browser control is opt-in per tab, and the boundary is explicit
The extension can read page structure and perform visible operations in a tab, but only after you select that tab in the sidebar. The README describes enable, switch and disconnect controls as user-facing. Separately, the floating DS++ Chat entry that appears on non-DeepSeek pages does not read or send the page body on its own; content enters the chat only when the user types, sends, or invokes a selected-text scenario. Right-click sending of selected text is a deliberate action by definition.
This distinction matters because a browser extension with page access is a broad permission grant. The README's framing suggests the intended model is explicit consent per tab plus explicit consent per send, with no ambient scraping. Whether the extension's manifest actually scopes permissions that tightly cannot be determined from the README alone. Check the manifest before you install if that concerns you.
Memory, Skills and projects are three different persistence layers
It is easy to read the feature table and assume these overlap. They do not. Memory is described as automatically saved, filtered and injected, and it is meant to carry preferences and background across conversations. Skills are invoked with /skill and act as expert modes or task templates, available built-in, user-defined, or imported from GitHub. Projects group instructions, project-scoped memory and related conversations, and conversations joined to a project inherit the project instructions and memory automatically.
The practical difference is scope. Memory is global, project memory is bounded to one project, and Skills are stateless templates you invoke. If you are trying to keep a client's context out of unrelated chats, project memory is the mechanism, not global memory. The README does not describe a review step before memory injection, so anything auto-saved into global memory is presumably injected into later conversations without asking.
Language switching is scoped to the interface, not your data
You can set the language to follow the browser, Simplified Chinese, or English. The README states that the sidebar, context menus, tool results, built-in tool descriptions and auto-continuation prompts follow the selection, and that built-in Skills and web search prompts do too. It also states plainly that user-created memory, presets, custom Skills, automation prompts, MCP configuration and synced data are never translated or rewritten.
That is the right call, but it produces a mixed-language interface if your saved content is in one language and your UI setting is in another. The README does not offer per-item language handling, so expect the two to coexist rather than reconcile.
Export, artifacts and what is not finished yet
Conversation export sits in the same toolbar row as DeepSeek's own copy and share buttons. HTML is the default, with Markdown and PDF as options, and a readable mode hides extension-internal prompts and tool-call markers. There is a separate image attachment manifest, and single messages can be saved as Markdown. Saved snippets export to Markdown or JSON. Artifacts can be downloaded as single files or as a packaged multi-file project.
One limitation is stated outright: file references, names, sizes, status and reference relationships are exported, but file body export is described as being enabled only after download-link verification is complete. In other words, that part is not available yet. Plan around it if attachment bodies are what you need to archive. The README also says exports are saved through the browser's local download mechanism and that the project runs no backend to collect them, which is consistent with the local-first claim but is a statement about design intent rather than something a reader can verify from the README.
Installation, and the native host you will probably need
There is a Chrome Web Store listing, and the README lists Chrome, Edge and Firefox as supported. The homepage link points to the store page. Building from source is a TypeScript project using WXT as the extension framework, with React in the stack, but the README excerpt does not include the build commands, so do not assume a documented source build path exists in the section shown. The repository does carry a README_EN.md for English readers.
Two configuration points are named explicitly. Language is set from the settings page, with follow-browser, Simplified Chinese and English as the options. An official API key can be configured to enable sidebar chat and right-click scenarios on ordinary web pages; without it, those scenarios work only on DeepSeek pages. Multimodal handling of images and videos attached in the DeepSeek input box requires installing a multimodal Native Host, while the sidebar's image-recognition mode works without it. The native host is also what backs local file reading. The README does not document the host installation procedure in the excerpt provided, so treat that as the first thing to check in the full documentation.
Where this is the wrong tool, and what to use instead
The clearest failure mode is headless or unattended use. DeepSeek++ runs in a browser, depends on a logged-in web session, and the README notes that when login state is missing, the sidebar prompts you to return to the DeepSeek page to sign in. Scheduled automation therefore runs inside a browser context, not on a server. If your task needs to execute when no browser is open, this is not the right layer.
A second boundary is API-first work. If you already have a DeepSeek API key and want tool calling through the official function-calling interface, a plain SDK script gives you structured tool schemas and typed responses instead of parsing model text. The trade-off is real in both directions: DeepSeek++ gives you the chat UI, memory, export and scheduling for free, but tool invocation rides on output parsing. An SDK gives you a contract the model must satisfy, but you build the memory store, the export and the scheduler yourself. Choose based on whether you value the existing web session or the structured contract more.
A third case: if you only need conversation archiving, the export feature alone does not justify installing an extension with page access and, optionally, a native host. Copy the conversation out manually, or use a simpler exporter.
Maintenance cost and the Apache-2.0 terms
The release cadence visible in the material is fast: 1.13.0 on 2026-08-05, 1.13.1 the next day, 1.14.0 on 2026-08-08. Three releases in four days suggests active iteration, which cuts both ways. You get fixes quickly, and you also get churn. The README's own table of contents links to a section titled for the 1.14.0 changes, so upgrades are documented per release. Budget for reading release notes before updating, particularly if you rely on MCP configuration or automation tasks, since those are the areas where a schema change would break saved setups.
The project is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an express patent grant. It also requires that you preserve copyright and licence notices and state significant changes if you redistribute a modified version. If you fork it and ship it inside a company, those obligations apply to you. Nothing here is legal advice; read the licence text and the NOTICE file if one exists before redistributing.
Editorial conclusion
Adopt DeepSeek++ if you already work inside chat.deepseek.com and want tool execution, memory, export and scheduled runs without moving to a different client. Do not adopt it if you need a headless or server-side agent, since the extension lives in a browser tab and depends on a logged-in web session. Before installing, verify three things: that your DeepSeek account is signed in on the web client, that the permission list the extension requests matches the controlled-tab and native-host features you actually intend to switch on, and that the export path produces the format you need, because the README states that file-body export is gated behind download-link verification and is not yet enabled.
Community notes