dsh-ptc-moejs

dsh-ptc-moejs

A PTC runtime for the DeepSeek Harness that runs the model's programs in moejs, a JavaScript engine written in Go.

简体中文 |

English

In the PTC mode of the [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (dsh), the model answers with a TypeScript program that calls tools. This runtime runs each program in a fresh [moejs](https://github.com/Calcium-Ion/moejs) runtime inside a sidecar process that stays up between programs. A program with three tool calls takes 0.4 ms here, and 110 ms on dsh's Node runtime, which starts a Node process for every program.

Programs can wait on timers, import helper modules from the working directory and use node:path, node:util and node:timers, and dsh's workflow tool runs its scripts here too.

Everything a program does to the machine is a tool call, which dsh runs with that tool's own policy, approvals and sandbox. The sidecar itself only reads the code files a program imports, and it gets the confinement dsh's Node runtime gives a program: the file sandbox of the Session's policy and the same short environment. A run stops at its deadline, even in an endless loop, and when it goes past its memory budget.

Performance

Both runtimes ran the same program through dsh's PtcRuntime service API, mounted on dsh's own services: three tool calls, each answered at once by its binding, and a returned object.

| Runtime | Per call | Load to first result |

|---|--:|--:|

| dsh-ptc-moejs, workspace-write | 0.42 ms | 16.4 ms |

| dsh-ptc-moejs, danger-full-access | 0.42 ms | 6.8 ms |

| dsh-ptc-runtime-node, workspace-write | 110.4 ms | 164.4 ms |

| dsh-ptc-runtime-node, danger-full-access | 103.0 ms | 149.2 ms |

A call is one resolve and run, from the program text to the result. Workspace-write is the default file policy of a dsh Session, under which both runtimes start their process inside bubblewrap: the Node runtime one process per program, moejs one sidecar for many programs. Danger-full-access starts the process directly. Load to first result runs from mounting the plugin to the end of its first run, and for moejs it includes starting the sidecar.

Every round started each runtime in a fresh Node process. The 5 rounds alternated the order of the runtimes on an Intel Core i5-13500H, with Linux 6.18, Node 24.22.1, Go 1.26.6, dsh 0.2.1-rc.2 and moejs v0.1.0-alpha.9. The table gives the median of the round medians, which stayed within 0.37 to 0.46 ms for moejs and within 100 to 114 ms for Node.

A long agent conversation

bench/agent.mjs runs one conversation in a headless dsh on each runtime. A scripted model makes 40 run_code calls over a copy of five dsh packages, and the programs make 90 calls to dsh's tools: glob, read, grep and bash. Both runtimes ran under workspace-write on the same machine. The table gives the average of 3 conversations on each runtime.

| | dsh-ptc-runtime-node | dsh-ptc-moejs |

|---|--:|--:|

| run_code time | 8.6 s | 3.6 s |

| of which the nested tool calls | 3.5 s | 3.3 s |

| Wall time of the conversation | 10.1 s | 5.0 s |

| CPU time of dsh and its child processes | 8.4 s | 5.2 s |

| Peak memory (PSS) of dsh and its child processes | 440 MiB | 437 MiB |

| Peak memory (PSS) of the PTC runtime's processes | 34.0 MiB | 18.5 MiB |

| Processes of the PTC runtime, bubblewrap's included | 120 | 3 |

Each program took 125 ms less on moejs, between 89 and 159 ms depending on the program, and used 82 ms less CPU time. No program was slower. The tool calls take about as long on both runtimes. The difference is the Node process that the Node runtime starts inside bubblewrap for every program. Memory peaks at about the same level on both runtimes, and the dsh process itself makes up about 385 MiB of that peak. The Node runtime's process for each program reaches 34 MiB and exits with the program. The moejs sidecar and its bubblewrap processes stay up for the whole conversation and peak at 18.5 MiB.

A day of agent work

The saving grows with the number of programs. The scripted model answers at once, and a real model's time per step adds the same on both runtimes, so the saving is the time an agent spends waiting for its programs. The table multiplies the measured 125 ms and 82 ms of CPU time per program by the programs of a day. The examples assume one program every 10 seconds.

| Programs a day | For example | Waiting saved | CPU time saved |

|--:|---|--:|--:|

| 200 | half an hour of agent work | 25 s | 16 s |

| 1,000 | about 3 hours | 2.1 min | 1.4 min |

| 2,880 | one agent busy for 8 hours | 6.0 min | 3.9 min |

| 11,520 | four such agents in parallel | 24 min | 16 min |

The busy agent spends 10.3 minutes of its 8 hours in run_code on the Node runtime and 4.3 minutes on moejs. For your own estimate, multiply the programs your agents run in a day by 125 ms.

Features

Every effect is a tool call

A program can call the tools dsh gives it and write to console. To read a file, run a command or fetch a page, it calls a tool, and dsh runs that call through its tool pipeline with the tool's own policy, approvals and sandbox, as it does for the Node runtime. dsh's session log records each call. The one thing the sidecar reads itself is a code file that the program imports, under the sandbox of the run's policy.

The Node runtime's sandbox

The sidecar runs under the same confinement as the Node runtime's program process:

• The policy is the one dsh resolves for the run: the Session's file mode and its workspace root, or the deployment's default for a run without a Session.
• dsh's sandbox service confines the sidecar with its runner for the host: bubblewrap or Landlock on Linux, Seatbelt on macOS, the restricted-token runner on Windows. Danger-full-access starts the sidecar without one.
• A restricted mode fails closed. When no runner can confine the sidecar, the run fails with sandbox-unavailable, as it does on the Node runtime, so a container where neither bubblewrap no