Run DeepSeek Harness with OpenRouter

Build a local agent harness that uses a free OpenRouter model and local tools.

Introduction

30 Second Summary

Coding assistants can be useful on an older Mac. Large local models can demand more hardware than you want to spare.

In this project, you will build a source-run DeepSeek Harness workspace that opens in Firefox. You will connect it to a free external model through OpenRouter before using real tool calls to create a runnable TypeScript deliverable.

What You'll Build

Picture watching an external model create two workspace files in Harness before its TypeScript deliverable prints a clear provider record in Terminal.

By the end of this project, you'll have:

  • A working Web UI you can open at http://127.0.0.1:3080 in Firefox to chat from the pinned Harness source.
  • A live external model connection that returns CLOUD MODEL READY from openai/gpt-oss-120b:free without a local model runtime.
  • Two agent-created deliverables you can preview in Harness. Running artifacts/provider-check.ts prints a JSON record that names the provider, model, and inference location.
  • Secret Mission: Add openrouter/free as a second model to test capability-aware free routing.

Are there any prerequisites?

You need an Intel Mac with Firefox, Node.js, pnpm, and a GitHub account.

You also need an internet connection plus permission to create an OpenRouter API key. No local model runtime is required.

Before We Start

A clear proof target keeps this project focused on the smallest useful end-to-end result. Before any setup begins, you will commit to what your local DeepSeek Harness interface must prove with OpenRouter and a generated TypeScript deliverable.

Set Up the Pinned Source

A moving developer-preview branch can change while you work. That drift can make later provider instructions stop matching the interface.

The immutable dsh-v0.2.1-alpha.2 tag keeps your DeepSeek Harness checkout on the release used throughout this project. You will confirm your local tools before downloading that source.

In this step, get ready to:
  • Verify your Node.js, pnpm, and Git versions.
  • Clone the immutable DeepSeek Harness release tag.
  • Confirm the version pins in package.json.
Check the local tools

Node.js runs the source workspace. pnpm manages its dependencies.

Git retrieves the pinned release. Corepack can expose the repository-selected pnpm version when the command is unavailable.

  • Press Cmd+Space to open macOS search.
  • Type Terminal in the search bar.
  • Press Enter to open Terminal.
  • Check the three installed tools by running these commands:
node --version
pnpm --version
git --version

What Do These Checks Prove?

  • The Node.js result must satisfy ^22.19.0 || >=24.0.0 so the Harness source can run.
  • The pnpm result confirms that the command is currently available. The repository selects pnpm@11.28.5 after you enter its directory.
  • The Git result must be 2.26 or newer so the source workflow meets the repository requirement.

✔️ Node.js and Git meet the requirements

Good, your local toolchain can support the tagged checkout. A printed pnpm version also confirms that the command is available.

ⓧ Node.js or Git is too old

An older runtime or Git release can break the pinned source workflow. Update only the tool whose result falls below the requirement.

  • Visit the official Node.js download page if your Node.js result does not satisfy ^22.19.0 || >=24.0.0.
  • Install a supported macOS package from the Node.js download page.
  • Visit the official Git installation page for macOS if your Git result is below 2.26.
  • Follow one listed macOS method to update Git.
  • Repeat the affected version check from the command block above.

ⓧ A command is unavailable

A missing Node.js or Git command must be resolved before cloning. A missing pnpm command can be enabled through Corepack after you enter the repository.

  • Install Node.js from the official Node.js download page if the Node.js command is unavailable.
  • Install Git from the official Git installation page for macOS if the Git command is unavailable.
  • Continue to the clone instructions if only the pnpm command is unavailable.
  • Repeat each Node.js or Git check after installing its missing tool.

Unsure About Your Version Results?

Version output can include extra prefixes or patch numbers. Compare the numeric parts with the stated requirements.

Share only the non-sensitive version output when asking for help. Help me interpret my Node.js, pnpm, and Git version checks.

Clone the release tag

A tag names a fixed source snapshot. The dsh-v0.2.1-alpha.2 tag keeps the rest of the project reproducible.

  • Move to your Desktop in the Terminal from earlier by running this command:
cd ~/Desktop

Why Start on the Desktop?

This location puts the new deepseek-harness directory somewhere easy to find. Later commands can use the same predictable path.

  • Clone the tagged source and enter its directory by running these commands:
git clone --branch dsh-v0.2.1-alpha.2 --single-branch https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness

What Does This Clone Command Do?

  • The --branch dsh-v0.2.1-alpha.2 option selects the immutable release tag.
  • The --single-branch option restricts the clone to that release history.
  • The final command moves Terminal into the new deepseek-harness directory.

You will see Git download the tagged source into a new deepseek-harness directory. The Terminal prompt then returns from inside that repository.

Before you check, what pnpm version do you expect the repository to select? Keep your answer in mind.

  • Confirm the repository-selected pnpm version by running:
pnpm --version

What Does This Check Use?

The repository declares pnpm@11.28.5 in its package metadata. Running the check inside deepseek-harness lets the repository pin control the expected version.

✔️ I see version 11.28.5

That is the exact pnpm release selected by this source checkout. Your repository is ready for its dependency installation in the next step.

ⓧ I see another version

A different result means your current pnpm command has not picked up the repository pin. Corepack can enable the required package-manager selection.

  • Enable Corepack and repeat the version check by running:
corepack enable
pnpm --version

What Does Corepack Change?

Corepack enables the package-manager command used by the repository. The repeated check should now read the version declared in package.json.

You should now see 11.28.5 in Terminal.

ⓧ The pnpm command is unavailable

Your supported Node.js installation includes the Corepack recovery path used by this repository. Enable it from inside deepseek-harness.

  • Enable Corepack and repeat the pnpm check by running:
corepack enable
pnpm --version

What Does Corepack Enable?

Corepack makes the pnpm command available for the repository. The second command immediately tests whether the recovery worked.

You should now see 11.28.5 in Terminal.

Still Missing the Pinned pnpm Version?

  • Return to the same Terminal window where the clone command finished.
  • Confirm that you have not moved out of the deepseek-harness directory.
  • Repeat the Corepack recovery from the matching outcome tab.
  • Help me make the repository select pnpm 11.28.5.
Confirm the source pin

The root package.json records the release version and tool requirements. Inspecting those fields proves that your local checkout matches this project's instructions.

  • Open the repository's root package.json in your Mac's default app by running:
open package.json

What Does This Command Open?

The macOS open command opens package.json with the default app associated with that file type. The file comes from the repository root currently selected in Terminal.

  • Find these three values in the opened package.json file:
"version": "0.2.1-alpha.2"
"packageManager": "pnpm@11.28.5"
"node": "^22.19.0 || >=24.0.0"

Why Do These Values Matter?

  • The version value confirms that you cloned DeepSeek Harness release 0.2.1-alpha.2.
  • The packageManager value locks repository commands to pnpm@11.28.5.
  • The engines.node value defines the supported Node.js range as ^22.19.0 || >=24.0.0.

Before the final check, do you expect every command to meet the requirements now? Compare your prediction with the results.

  • Run the three version checks once more from the repository directory:
node --version
pnpm --version
git --version

What Should You See?

Your Node.js result should satisfy ^22.19.0 || >=24.0.0. Your pnpm result should show 11.28.5.

Your Git result should show 2.26 or newer. Together with the three package.json values, these results confirm the pinned source setup.

Did One Check Drift?

A mismatched pnpm result usually means the check ran outside deepseek-harness. A mismatched Node.js or Git result means the older installation still controls your Terminal session.

Help me resolve a final tool-version mismatch.

Your source checkout is pinned to the required release. Next, you will install its dependencies and bring the Web UI to life.

Build and Open the Web UI

Your pinned DeepSeek Harness checkout is ready. However, source files alone cannot serve the interface.

This step builds the checkout into a runnable Web UI. You will open that interface in Firefox through a foreground server process.

In this step, get ready to:
  • Install the pinned workspace dependencies.
  • Build the source checkout into runnable artifacts.
  • Open the Web UI with the local workspace selected.
Install the pinned dependencies

The tagged repository lists the packages needed across its workspace. The pnpm package manager installs those exact dependencies for the upcoming build.

On an older Intel Mac, this first install can take several minutes. Ongoing package activity in the Terminal means it is still working.

  • Install the workspace dependencies from the repository Terminal by running:
pnpm install

What does this command do?

  • The installer reads the package declarations from the tagged repository.
  • The installed workspace provides the tools required by the source build.
  • Wait for the installation command to finish.

The Terminal should return to its command prompt without an installation failure. That is a substantial setup task complete: the pinned workspace now has its required dependencies.

Dependency installation not finishing?

  • Confirm your Mac still has an active internet connection.
  • Return to the Corepack recovery from Step 1 if pnpm stops resolving.
  • Repeat the installation command after resolving the connection or package manager issue.
  • Help me diagnose my DeepSeek Harness dependency installation.
Build the source artifacts

The installed packages provide the build tools for the source checkout. The build prepares the repository artifacts used by the Web launcher.

  • Build the repository artifacts by running:
pnpm run build

What does this command do?

  • The build transforms the source checkout into prepared repository artifacts.
  • The Web launcher uses those artifacts when it starts the interface.
  • Wait for the build command to finish.

The Terminal should return to its command prompt without a build failure. Your pinned source checkout is now ready to launch.

Build command failing?

  • Confirm the dependency installation completed before you started the build.
  • Read the first failure shown in the Terminal because later failures may be follow-on effects.
  • Help me diagnose my DeepSeek Harness source build.
Launch the Web UI in Firefox

The Web UI needs a live server process. This launcher stays attached to the original Terminal while the interface runs.

  • Start the foreground Web server without opening the default browser by running:
pnpm dsh web --no-open

What does this command do?

  • The dsh launcher starts the built Web interface.
  • The --no-open flag leaves the browser choice under your control.
  • The foreground process keeps the original Terminal occupied while the server is running.
  • Leave the original Terminal open with the foreground process running.
  • Press Cmd+Space on macOS or the Windows key on Windows to open system search.
  • Type Firefox into the search bar.
  • Press Enter to open Firefox.
  • Enter http://127.0.0.1:3080 in the Firefox address bar.
  • Press Enter to load the local Web UI.

You should see the Harness workspace chooser in Firefox. This confirms that the foreground server is responding.

  • Click Choose workspace in the Web UI.
  • Add the local deepseek-harness directory where the server started.
  • Select deepseek-harness from the workspace list.

Before you inspect the composer, decide whether you expect it to complete a useful request with its current model state.

  • Check the composer for its current model selection state.

You will see the running Harness interface with the local workspace selected. The composer requires a model selection because no usable external model route exists yet.

This shortfall is intentional. You have proved the source build works before adding external inference.

Web UI not loading?

  • Confirm the original Terminal still shows the running foreground process.
  • Repeat the launch command if the Terminal command prompt has returned.
  • Check that the Firefox address bar contains http://127.0.0.1:3080.
  • Confirm the selected workspace is the local deepseek-harness checkout.
  • Help me troubleshoot the local Harness Web UI.

Your pinned checkout now serves the Harness interface in Firefox. Next, you will connect an external model so the composer can answer.

Connect the External Model

Your pinned DeepSeek Harness Web UI is running in Firefox. The composer still has no usable model route.

This step connects the interface to OpenRouter through a credentialed custom provider. The model runs externally. Your Mac needs no local model runtime.

In this step, get ready to:
  • Create an OpenRouter API key.
  • Configure a custom provider for the fixed free model.
  • Prove external inference with an exact streamed response.
Create an OpenRouter key

An API key authorizes requests against your OpenRouter account. You will move it into Harness without placing it in the deepseek-harness repository.

  • Open a new tab in Firefox.
  • Go to the OpenRouter dashboard.
  • Complete the OpenRouter sign-in flow.
  • Create an API key from the dashboard's API key area.
  • Copy the new API key once.

Your OpenRouter credential is ready for its single handoff into Harness. Keep it out of the repository, shell scripts, and Git-tracked files.

Can't create a key?

  • Confirm that the OpenRouter sign-in flow has finished before returning to the API key area.
  • Use the dashboard's key creation control again if no new credential was generated.
  • Help me create an OpenRouter API key safely.
Configure the custom provider

A custom provider tells Harness which endpoint receives model requests. The provider catalog then exposes the model in the session picker.

Why use a custom provider?

OpenRouter exposes an OpenAI-compatible API base URL. Harness accepts that route through its Custom model API form.

This approach lets you enter the fixed model ID directly. The selected route stays visible during every test.

  • Switch back to the existing Harness tab in Firefox.
  • Click Settings in the Harness interface.
  • Select Models.
  • Choose Add model provider.
  • Switch to Custom model API.

The form now needs the route identity, protocol, and credential. Each value connects the provider entry to the external model.

  • Enter openrouterfree in the Provider ID field.
  • Enter OpenRouter Free in the Display name field.
  • Enter https://openrouter.ai/api/v1 in the Base URL field.
  • Select OpenAI Chat Completions for API protocol.
  • Paste the OpenRouter key into the API key field.
  • Add openai/gpt-oss-120b:free under Model catalog.
  • Leave the default text input type selected for the new model.
  • Save the provider.

That is the credential handoff complete. Harness can use the new provider on its next request without a server restart.

Where is the key stored?

Harness treats model keys as write-only in the page. It stores the credential in $DSH_HOME/.credentials.yaml.

The settings keep a credential reference. Your repository remains free of the secret.

Prove external inference

The provider exists, but a successful request is the real proof. A narrow response test gives you a clear pass condition.

  • Start a new session in Harness.
  • Open the model picker in the new session.
  • Select openai/gpt-oss-120b:free.
  • Prepare the inference check by entering this exact prompt in the composer:
Reply with exactly: CLOUD MODEL READY

What does this prompt test?

This prompt creates one exact success condition. A matching streamed response confirms that the selected model route can answer through Harness.

  • Predict whether the response will stay exact or include extra text.
  • Submit the prompt from the composer.

You should see CLOUD MODEL READY stream into the conversation.

You've crossed the key integration point. The streamed response proves the selected OpenRouter route is handling inference outside your Mac.

Seeing a 429 or no response?

  • If the conversation shows 429, wait for the interval supplied by Retry-After before resubmitting.
  • Confirm that the model picker shows openai/gpt-oss-120b:free.
  • Confirm that the provider form uses https://openrouter.ai/api/v1.
  • Resubmit the exact prompt shown above.
  • Help me troubleshoot my OpenRouter model response in DeepSeek Harness.

Your external model route is live. Next, you will ask the model to use Harness tools and produce runnable deliverables.

Create a Runnable Deliverable

Your selected external model can already answer inside DeepSeek Harness. A chat response alone does not prove that the model can act on the local workspace.

In this step, you will make the model create two exact workspace files through tool calls. The final terminal run turns the TypeScript artifact into visible proof.

In this step, get ready to:
  • Ask the external model to create the two specified workspace files.
  • Inspect the workspace tool trail for both deliverable cards.
  • Run the generated TypeScript to verify its JSON record.
Ask the agent to create both files

The agent needs a precise scope before it can safely touch your workspace. A limited request keeps its file changes focused on two named paths.

A workspace approval can feel risky because it authorizes a local file change. You stay in control by checking every requested path before allowing it.

  • Switch back to the working Harness session in Firefox.
  • Confirm openai/gpt-oss-120b:free remains selected in the model picker.
  • Send the exact tool-use task by pasting this prompt:
Create the two files shown in this project's Complete Code section: artifacts/provider-check.ts and RUNBOOK.md. Match their contents exactly. Do not modify any other file. After writing both files, use the present tool to deliver both of them.

What Does This Prompt Control?

  • The two file paths limit the requested changes to the intended deliverables.
  • The exact-match instruction keeps the generated contents aligned with the project.
  • The present instruction asks Harness to declare the existing workspace files as final deliverables.
  • Watch the turn for workspace file activity.
  • Review any workspace write approval request before allowing it.
  • Confirm the request names only artifacts/provider-check.ts plus RUNBOOK.md.
  • Allow that single request.
  • Wait for the agent turn to finish.

You should see file mutation activity for both paths. The completed turn should also include two deliverable cards.

Agent Skipped the File Tools?

  • Resend the exact prompt in the session where openai/gpt-oss-120b:free is selected if the model replies with prose only.
  • Deny the approval if it lists a path outside the two requested files.
  • Resend the prompt after a denied approval.
  • Help me understand why my Harness agent replied without creating the requested files.
Inspect the tool trail and deliverables

A deliverable card points to the current file in your selected workspace. Selecting the card previews that file in the right sidebar.

  • Confirm the tool trail shows file mutation activity for artifacts/provider-check.ts.
  • Confirm the tool trail shows file mutation activity for RUNBOOK.md.
  • Confirm the turn ends with a deliverable card for artifacts/provider-check.ts.
  • Confirm the turn ends with a deliverable card for RUNBOOK.md.
  • Select the artifacts/provider-check.ts card.
  • Confirm its current contents appear in the right sidebar.
  • Select the RUNBOOK.md card.
  • Confirm its preview contains no API key value.

You now have the agentic proof: the model changed the two permitted workspace files before presenting those same files as deliverables.

✔️ Awesome, I've got everything!

Both deliverable cards point to the completed files in your workspace.

ⓧ I'd like to double check the full code

  • Compare artifacts/provider-check.ts with this complete file:
type ProviderCheck = {
  provider: "OpenRouter";
  model: "openai/gpt-oss-120b:free";
  inference: "external";
};

const check: ProviderCheck = {
  provider: "OpenRouter",
  model: "openai/gpt-oss-120b:free",
  inference: "external",
};

console.log(JSON.stringify(check, null, 2));

What Should This File Contain?

The ProviderCheck type limits the record to three exact string values. The final console.log() prints that record as formatted JSON.

  • Compare RUNBOOK.md with this complete file:
# DeepSeek Harness Cloud Runbook

## Requirements

- Node.js `^22.19.0 || >=24.0.0`
- pnpm `11.28.5`
- Git `2.26` or newer
- Firefox
- An OpenRouter API key

## Build and start

From the repository root:

```sh
pnpm install
pnpm run build
pnpm dsh web --no-open
```

Open `http://127.0.0.1:3080` in Firefox and select this repository as the workspace.

## Provider values

- Provider ID: `openrouterfree`
- Display name: `OpenRouter Free`
- Base URL: `https://openrouter.ai/api/v1`
- API protocol: `OpenAI Chat Completions`
- Model ID: `openai/gpt-oss-120b:free`

Paste your own key in `Settings → Models`. Do not share a key with this folder.

## Stop

Return to the Terminal running DeepSeek Harness and press Control-C. Reloading `http://127.0.0.1:3080` should then fail until you start the server again.

What Should This Runbook Contain?

The runbook records the repeatable build steps plus the provider values. It keeps the private API key outside the shared workspace file.

Run the generated TypeScript

A deliverable card proves that Harness can expose the file. A successful terminal run proves that the generated TypeScript is executable.

  • Create a second window in the macOS Terminal app from earlier.
  • Change the new window to the deepseek-harness repository root you cloned earlier.

Before you run this, picture the three values you expect the JSON record to contain.

  • Run the generated TypeScript from the repository root by running:
pnpm exec tsx artifacts/provider-check.ts

What Does This Command Do?

The project dependency runner exposes the installed tsx executable. That executable runs artifacts/provider-check.ts directly from the repository.

You should see this formatted JSON record in the second Terminal window.

{
  "provider": "OpenRouter",
  "model": "openai/gpt-oss-120b:free",
  "inference": "external"
}

What Does This Output Prove?

The output names the external provider used by this project. It also preserves the fixed model route plus the external inference location.

You have closed the loop: an external model used local Harness tools to create a deliverable that now runs successfully.

Script Not Running?

  • Return the second Terminal window to the deepseek-harness repository root if the command cannot find the project dependency.
  • Return to the working Harness session if the generated file is missing.
  • Confirm the agent turn completed its file mutation activity.
  • Compare both generated files with the full-code tab if the output differs.
  • Help me troubleshoot why the generated provider-check TypeScript file does not print the expected JSON.

Your source-run Harness now produces a visible file deliverable with verified output. Next, you will make its foreground server lifecycle just as repeatable.

Prove a Clean Stop and Restart

Your DeepSeek Harness agent created both deliverables. The TypeScript check also proved that the generated artifact runs successfully.

Closing Firefox removes only the browser client. It leaves the server process running in its owning macOS Terminal.

In this step, get ready to:
  • Confirm that closing the browser leaves the foreground server running.
  • Prove that Control-C removes access to the local Web UI.
  • Restart the server before completing a clean final stop.
Test the browser and server separation

The Web UI displays the client side of your running Harness process. The original Terminal owns the foreground server.

  • Predict whether closing the Firefox tab also stops the original server process.
  • Close the DeepSeek Harness tab in Firefox.
  • Return to the original Terminal from earlier.

You'll see that the Harness command still occupies the Terminal. That distinction is now proven: the browser can close while its server keeps running.

Stop the server from its owning Terminal

This stop is safe because it only ends local web access. The source checkout plus stored provider configuration remain available.

  • Press Control-C once in the original Terminal.
  • Wait for the Terminal command prompt to return.

The returned command prompt proves that the foreground server process has exited.

  • Predict whether the local Web UI can still accept a connection.
  • Return to Firefox.
  • Type http://127.0.0.1:3080 into the address bar.
  • Press Enter.

You'll see that Firefox cannot connect to the local address. This failed connection confirms that Control-C stopped the server.

Firefox still connects?

  • Confirm that the original Terminal shows a command prompt instead of an active Harness process.
  • Check your other Terminal windows for another Harness server process.
  • Stop any additional Harness server from its owning Terminal with Control-C.
  • Help me identify why the Harness Web UI still loads after I stopped the foreground process.
Verify the restart cycle

The same foreground command restores the Web UI without rebuilding the repository. Your stored workspace state remains on disk between launches.

  • Restart the existing build from the repository root by running this command:
pnpm dsh web --no-open

What does this command do?

The command starts the built Harness Web server as a foreground process. The --no-open flag leaves browser navigation to you.

  • Wait until the Terminal shows that the local Web server is listening.
  • Predict whether the existing workspace plus provider configuration survived the stop.
  • Return to the failed connection page in Firefox.
  • Reload the page.

You'll see the Web UI load again at the same address. Your existing workspace plus OpenRouter Free provider configuration remain available.

That clean return proves your Harness installation is restartable without rebuilding the source or recreating the deliverables.

Web UI still unavailable?

  • Confirm that the restarted server still occupies the original Terminal.
  • Check that Firefox is loading http://127.0.0.1:3080.
  • Wait for the server startup activity to finish before reloading the page again.
  • Help me troubleshoot why the DeepSeek Harness Web UI does not load after restarting the foreground server.

A repeatable lifecycle includes returning the foreground process to a known state. Finish with the local server stopped.

  • Return to the Terminal running the restarted server.
  • Predict what Firefox will show after the second server stop.
  • Press Control-C once.
  • Wait for the Terminal command prompt to return.
  • Return to Firefox.
  • Reload the page at http://127.0.0.1:3080.

You'll see that Firefox cannot connect again. The repository build plus provider configuration remain preserved.

You now have a reliable lifecycle: start the foreground server when needed. Stop it cleanly when your Harness work is complete.

Secret mission

Secret Mission: Add a Free-Model Router Fallback

Keep your fixed free model available while adding a capability-aware route that can choose another current free model. Test the router against the existing TypeScript deliverable to compare its response and tool behavior.

Clean Up Your Resources

Clean Up Your Resources

This project stays free while you use only OpenRouter's free model routes within their request limits. Decide whether to keep the workspace active, pause its foreground server, or delete the local and provider resources.

Resources you used:

  • A foreground DeepSeek Harness Web server running in macOS Terminal.
  • A local deepseek-harness source checkout pinned to dsh-v0.2.1-alpha.2 with installed dependencies and built repository artifacts.
  • The artifacts/provider-check.ts and RUNBOOK.md deliverables inside the checkout.
  • The OpenRouter Free provider configuration with openai/gpt-oss-120b:free and openrouter/free in its model catalog.
  • The OpenRouter API key created for this project.

Keep everything running

No action is needed. Choose this option if you want to keep testing tool calls or comparing the two free model routes.

  • Keep the foreground server running in macOS Terminal.
  • Keep Firefox connected to http://127.0.0.1:3080.
  • Retain the local deepseek-harness checkout with its dependencies and build artifacts.
  • Retain the OpenRouter Free provider configuration with both free model routes.
  • Continue using free routes only unless you intend to spend OpenRouter account credits.

Free model requests continue counting toward your OpenRouter request limits.

Pause - I'll come back to this later

Pause the local server while preserving the source checkout and provider configuration. Your files remain ready for the next launch.

  • Return to the original macOS Terminal running the Harness server.
  • Press Control-C once to stop the foreground process.
  • Reload http://127.0.0.1:3080 in Firefox.

That is the pause complete. Firefox cannot connect to the local Web UI because the server has stopped.

  • Use RUNBOOK.md when you are ready to start the server again.

Delete - I don't want to use this again

Deleting the checkout permanently removes its dependencies, build artifacts, and deliverables. Your OpenRouter account and installed development tools remain available.

  • In the Harness Web UI, select Settings.
  • Select Models.
  • Remove the OpenRouter Free provider from Harness.
  • Return to the OpenRouter dashboard from earlier.
  • Revoke the API key created for this project.

That closes the online side of cleanup. The revoked key can no longer authorize requests.

  • Return to the original macOS Terminal running the Harness server.
  • Press Control-C once to stop the foreground process.
  • Remove the local deepseek-harness checkout from its parent folder by running these commands from the repository root:
cd ..
rm -rf deepseek-harness
ls

What Do These Commands Do?

  • The first line moves Terminal to the folder containing the repository.
  • The second line permanently removes the source checkout with its dependencies and deliverables.
  • The final line lists the remaining items in the parent folder.

You should no longer see deepseek-harness in the directory listing. This confirms that the local project files are gone.

Still See the Checkout?

Check that you started the cleanup from inside the deepseek-harness repository. Confirm that the server process returned to the command prompt before retrying.

Help me verify the cleanup location before I remove the folder.

Cleanup complete. The server, provider route, active API key, and local checkout are removed.

Nice Work!

Nice Work!

You did it! Your pinned DeepSeek Harness workspace now sends inference through OpenRouter. It can create local deliverables through agent tool calls.

You've learned how to:

  • Build DeepSeek Harness from a pinned source release at dsh-v0.2.1-alpha.2. Launch its Web UI in Firefox from a repeatable local workspace.
  • Connect a custom provider through an OpenAI-compatible API. Route requests to openai/gpt-oss-120b:free through OpenRouter to prove external inference.
  • Complete a file tool workflow with Harness tools plus the present tool. Run artifacts/provider-check.ts to verify its external-provider JSON. Follow RUNBOOK.md to control the foreground server with a clean stop plus restart cycle.
  • Complete the optional Secret Mission by adding openrouter/free as a capability-aware fallback route. Compare its response style plus tool behavior with the fixed model.

Ready to quiz yourself?