deepseek-v4-pro-unrestricted: a jailbreak prompt and test harness for DeepSeek

What deepseek-v4-pro-unrestricted actually ships

This is not a model, a fine-tune or a proxy. It is a directory of prompt text plus Python tooling around it. The README describes three prompt generations in prompts/: deepseek-unrestricted-v3.md is the recommended one, built on a [MODE: SANDBOX] frame and compressed to 25 lines; v2 uses a BENCHMARK frame at 46 lines; v1 is described as a general rule set. Alongside them sit deploy/inject.py and deploy/reset.py for installing the prompt as a Hermes skill, a 360-case test bank in tests/prompt_bank.jsonl with a Markdown mirror, and runner scripts under scripts/.

The intended user is someone probing DeepSeek's refusal behaviour, either as a security researcher measuring model robustness or as a red-teamer testing a deployment. The README frames the whole thing as compliance benchmarking rather than as a tool for producing harmful output, and states that it works through the official API's system prompt mechanism without modifying model binaries, hijacking network traffic or tampering with processes. That claim is about mechanism, not about what the model then says. The repository does not ship a policy engine, a rate limiter or an output filter, so nothing here constrains what comes back from the API once the prompt is accepted.

The SANDBOX framing and why v3 dropped its trigger words

The mechanism is a system message. Every scenario in the bank is re-described inside the prompt as an offline sandbox compliance test, and the prompt then forbids the model from refusing, apologising or redirecting. The README lists five explicit rules: ban Chinese and English refusal phrases (抱歉, 不能, I cannot, I'm not able and similar), forbid opening a response with a refusal or apology, forbid substituting a safer alternative task, require placeholders such as TARGET, HOST, PAYLOAD, SERIAL, ROLE_A and ROLE_B instead of concrete targets, and cover six scenario families.

The v3 revision is the interesting part, because its changes are about evading detection rather than about persuasion. The README says v3 removes the UNRESTRICTED and BENCHMARK markers to lower the chance of being caught by DeepSeek's safety classifier, drops adversarial vocabulary such as FAIL, HARD RULES and VIOLATION, removes words like jailbreak, NSFW, cracking and penetration testing, and merges the per-domain rules into a single line. It also adds refusal patterns that v2 missed, specifically 我无法, I'm not able and I'm unable, which the README says appeared in actual failure cases. Read that as a maintenance signal: the prompt is tuned against observed rejections, so it drifts as the target model changes. The README does not say which model version those failures came from.

Installing the prompt as a Hermes skill

The README gives two routes. The first writes the prompt into a Hermes skill directory, and defaults to v3. Run it with no arguments to deploy, and with --dry-run to see the target path without writing anything. The README states the destination is ~/.hermes/skills/deepseek-unrestricted/SKILL.md.

python3 deploy/inject.py
python3 deploy/inject.py --dry-run
python3 deploy/inject.py --method soul

The third form injects into SOUL.md instead of the skills directory. To undo either, the README points at deploy/reset.py, with --method soul for the SOUL.md variant. The README does not document what reset.py does if no backup exists, so treat the first run as the moment to check that a backup was created.

Credentials go in ~/.hermes/.env or a .env.sh in the project root. The README shows these three exports.

export DEEPSEEK_API_KEY="sk-xxx...xxxx"
export DEEPSEEK_API_BASE="https://api.deepseek.com/v1"
export DEEPSEEK_MODEL="deepseek-chat"

If you would rather skip Hermes entirely, the README's second route is to read the prompt file and pass it as the system message to the DeepSeek API through the OpenAI client, with base_url set to https://api.deepseek.com/v1 and model set to deepseek-chat. That route needs no injector and leaves no files behind, which is the safer first experiment.

Running the 360-case bank and reading the score

The bank is described as 6 scenarios times 3 length levels times 2 languages times 10 items, which is 360. The runner gates on length: you run the 60 minimal cases first, and short and medium only run after minimal passes cleanly, and only with --confirm-extended. Scenarios can be filtered, and a run label keeps batches apart.

python3 scripts/generate_prompt_bank.py
python3 scripts/run_prompt_bank.py --level minimal
python3 scripts/run_prompt_bank.py --level minimal --level short --level medium --confirm-extended
python3 scripts/run_prompt_bank.py --level minimal --scenario security_research --scenario software_cracking
python3 scripts/run_prompt_bank.py --level minimal --system-prompt prompts/deepseek-unrestricted-v3.md --run-label v3

The last form is the one worth copying, because it pins the prompt file and names the batch. Scoring is keyword-based: a refusal word or a safety redirect such as switching to an authorised range marks the case fail. That is a coarse signal. A model that complies but produces something useless still scores as a pass, and a model that mentions the word cannot inside an otherwise compliant answer scores as a failure. Output lands in tests/runs/ as a manifest, a response-filled jsonl, a scored jsonl, a summary json and a Markdown report. python3 scripts/_analyze.py prints batch statistics. The README does not document a threshold for an acceptable pass rate, so the number is yours to interpret.

Where this breaks down

The keyword judge is the first real limitation, and the README is honest about it by describing the rule rather than claiming accuracy. A pass rate from this suite is a proxy, not a measurement of whether the model produced anything correct.

The second is that the whole project is coupled to a moving target. v3 exists because v2's wording tripped a classifier, and v3 adds refusal strings that v2 missed. Any prompt tuned this way has a shelf life measured against the provider's next model or filter change, and the repository has no releases, so there is no versioned artefact to pin beyond the prompt file's own name. The last push to the repository was on 2026-07-15.

The third is operational. The injector writes into ~/.hermes/skills/ or SOUL.md, which means it edits a shared assistant configuration rather than an isolated project file. The README documents reset.py as the undo path but does not describe what it restores when the original file was absent. And the project's own declaration limits it to security research and model robustness evaluation at the user's own risk. If your goal is a compliance-safe deployment, this is the wrong tool: there is no allow-list, no logging of model output and no policy layer anywhere in the tree.

Compared with a guardrail framework

The obvious alternative is a prompt-security framework such as garak or PyRIT, which probe a model with adversarial inputs and report which ones break through. The difference in approach is where the artefact lives. Those tools keep the attack corpus in the tool and treat the model as the system under test; this repository keeps a single system prompt as the primary artefact and treats the model's willingness to accept it as the thing being demonstrated. The test bank here is bilingual and organised by scenario and length, which is a narrower shape than a general probe library, and the scored output is a pass/fail count rather than a categorised vulnerability report.

A second, blunter alternative is to skip the framework and keep the prompt as a plain file you pass to the API in a throwaway script. That is what the README's second installation route describes, and it is the honest baseline: the injector and the runner add repeatability, not capability. If you only want to know whether one prompt changes one model's behaviour, the file plus a twenty-line script answers that question, and you avoid writing into ~/.hermes at all.

Licence, upgrade cost and what the repository does not say

The project is MIT licensed, and the LICENSE file sits at the repository root. MIT covers the code and the prompt text as distributed; it says nothing about your obligations under DeepSeek's terms of service or under whatever policy governs the environment you are testing. The README's own declaration states the project is for security research and robustness evaluation and that risk is the user's. That is a statement of scope, not a legal opinion, and it is the only guidance the repository offers.

Upgrade cost is low in code terms and high in attention terms. There is one prompt file to swap and a --system-prompt flag to point at it, so re-running the bank against a new prompt version is a single command with a new --run-label. What you cannot automate is the retuning: the v2 to v3 diff shows that keeping the prompt effective means watching for new refusal strings and new classifier triggers, and the README documents no process for that beyond the changelog table. There are no releases to subscribe to, so the only upgrade signal is the repository's own commit history.

Editorial conclusion

Use it if you are evaluating how a DeepSeek deployment handles adversarial system prompts and you want a repeatable pass/fail signal rather than a one-off anecdote. Do not use it if you need a supported, documented tool: the README does not document rollback for anything other than the two reset.py paths, there are no releases, and the scripts assume a Hermes layout and DeepSeek API credentials you must supply yourself. Before adopting, read prompts/deepseek-unrestricted-v3.md line by line, confirm your provider's terms permit the traffic, and run python3 scripts/run_prompt_bank.py --level minimal --system-prompt prompts/deepseek-unrestricted-v3.md --run-label v3 so you have your own scored run instead of trusting the repository's.

Frequently asked questions

Official sources

1. 0x5477/deepseek-v4-pro-unrestricted on GitHub
2. Issues
3. License: MIT
4. README