dsh-packycode-api 1.4.1 → 1.4.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +18 -0
- package/README.en.md +15 -10
- package/README.md +15 -10
- package/lib/client.js +1 -0
- package/lib/index.js +47 -6
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,23 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 1.4.3
|
|
4
|
+
|
|
5
|
+
- **GPT tool calls no longer fill DSH's sandbox escalation fields.** On GPT-6.1 Terra users saw tool calls fail with `Error: invalid justification: expected a non-empty sentence`. The plugin sent DSH's tools to GPT without `strict`, and PackyCode's GPT route treats such a tool as strict, so the model filled every optional parameter. DSH's `sandbox_permissions` came back as `workspace-write`, the first value of its enum, with an empty or stock `justification`, next to invented values such as `timeoutMs: 1000`. DSH's edit and write refuse `sandbox_permissions` with an empty justification, and bash does too when the requested mode is not the session's own. All four GPT models did this, also before 1.4.2. DeepSeek Flash and Grok 4.7 leave optional parameters out with or without `strict`.
|
|
6
|
+
- **The GPT models now declare pi-ai's `supportsStrictMode`**, so pi-ai sends `strict: false` on each tool, as the official Codex client does. The parameter schemas are sent as DSH wrote them. No DSH tool asks for strict sampling (only pi-ai itself mentions `constrainedSampling`), so no tool switches to a strict schema.
|
|
7
|
+
- Validation, 2026-10-27:
|
|
8
|
+
- **Offline:** 537 tests (new: through the route every GPT model sends DSH's tools with `strict: false` and unchanged parameters, while DeepSeek and Grok send no `strict`; the test fails without the fix), both rebuilt bundles and the versioned tarball.
|
|
9
|
+
- **Live, the cause:** DSH 0.2.1-rc.3's own bash, read, write and edit specs, compiled with DSH's `parameterSchemaSpecToJsonSchema`, went through the 1.4.2 route. Terra filled `sandbox_permissions: "workspace-write"` with an empty `justification` in 15 of 15 calls, GPT-6.1 Sol in 9 of 9, and DSH's own check refused one Terra `edit` with exactly this message. Sent directly with the same bash tool, every GPT model filled `justification` in every call with `strict` omitted (Terra 4 of 4, the other three 2 of 2 each) and in none with `strict: false`. DeepSeek Flash and Grok 4.7 filled it in none either way.
|
|
10
|
+
- **Live, the fix:** through the built route with the same specs, Terra and GPT-6.1 Sol made 9 calls each, `edit` and `write` included, with no escalation field and none refused. After DSH's sandbox denial and its retry hint, both still retried with `sandbox_permissions: "danger-full-access"` and a reason in the user's language, 3 of 3 rounds each. Terra's `echo` tool call still continued to `ok` at `high` and with reasoning off. In `scripts/live-check.mjs` ten models answered, all four GPT models among them, and key rotation, the rejected-key classification, both auto reviewers and the RPC projections were unchanged. `gemini-4-argon` failed with the gateway's own refusal (`分组 gemini-slb 下模型 gemini-4-argon 无可用渠道`, then `当前令牌未覆盖供应商`): PackyCode's `/api/pricing` stopped listing it that day, between two runs, so this change is not the cause. Not checked in the desktop app.
|
|
11
|
+
|
|
12
|
+
## 1.4.2
|
|
13
|
+
|
|
14
|
+
- **GPT-6.1 Terra joins the catalog.** `gpt-6.1-terra` takes GPT-6.1 Sol's route: `openai-responses` at `https://cf.api.fan/v1`, text and image input, 1,050,000 context and 128,000 output, per OpenAI's [model page](https://developers.openai.com/api/docs/models/gpt-6.1-terra), which also says tool calls need Responses. PackyCode's `/api/pricing` lists it for `codex` and `codex-sale`, not `azure-officially`, at half GPT-6.1 Sol's rate. It sits after GPT-6.1 Sol in the picker, and the settings panel counts it under GPT. Its session titles stay on Terra, which costs less than Sol.
|
|
15
|
+
- **Terra's reasoning can be off.** OpenAI documents `reasoning.effort` `none | low | medium | high | xhigh | max` for it. Through PackyCode, a Terra request at `none` came back as `none`, with no reasoning tokens, so `off` keeps pi-ai's Responses default and sends `reasoning.effort: "none"`. The other five levels are sent as named. GPT-5.6 Sol's documented `none` comes back as `medium`, and GPT-6.1 Sol refuses `none` with a 400, so neither offers `off`. `minimal` is not documented for Terra and is not offered; the gateway answers it as `none`.
|
|
16
|
+
- Validation, 2026-10-27:
|
|
17
|
+
- **Offline:** 536 tests (new: Terra's catalog entry, efforts and resolved metadata; each effort, and `off` as `none`, sent through the route with the cache key the Codex group requires; Terra titling its own sessions), both rebuilt bundles and the versioned tarball.
|
|
18
|
+
- **Live, direct to `/v1/responses` with the test key (`codex` group):** the gateway echoed each documented level back as sent. `none` gave 0 reasoning tokens in 3 of 3 requests, `minimal` came back as `none`, and a request without `reasoning` as `medium`. For comparison, GPT-5.6 Sol's `none` came back as `medium`, and GPT-6.1 Sol answered `none` with 400 `unsupported_value`.
|
|
19
|
+
- **Live, through the built route:** in two runs, `off`, `low`, `medium`, `high`, `xhigh` and `max` each sent its effort (`off` as `none`) and got it echoed, with 0, 0, 20–24, 23–27, 23 and 32–35 reasoning tokens, and every answer was right. `minimal` was refused before any request. An `echo` tool call, continued with its result, answered `ok` at `high` and with reasoning off. `scripts/live-check.mjs --model gpt-6.1-terra --with-vision` answered `ok`, named a red and a blue image, and read the key's groups as reaching Terra. `scripts/live-check.mjs` passed: all eleven models answered, and the key's groups read as reaching each of them. Key rotation, the rejected-key classification, both auto reviewers and the RPC projections were unchanged. Not checked in the desktop app.
|
|
20
|
+
|
|
3
21
|
## 1.4.1
|
|
4
22
|
|
|
5
23
|
- **Session titles on `cc` keys name the conversation again.** From 1.4.0 Claude Code was asked to name an empty conversation, so cc sessions were titled "Untitled Session", "Empty Session", "Greeting" or "空白会话". DSH's title providers put the user's messages, as a JSON array, in one user message whose source is `dsh-session-title-llm`, and the cc route passes Claude Code only the text of messages with the user's own sources (`src/claude-user-text.js`). That message was dropped. The route's own naming instruction has the source `user`, so the request did not count as empty, and Haiku got DSH's title rules and the instruction with nothing between them. A title request now keeps its messages. Nothing of DSH's agent comes with them: DSH builds the input only from `user/message` events whose source is `user`. The input is no longer cut to 2,000 characters per message either. DSH bounds it (`maxInputBytes`, 4,096 bytes by default) and HTTP sends it whole, while the cut dropped the latest prompts from a refresh by DSH's experimental all-prompts provider. HTTP keys and other models were not affected.
|
package/README.en.md
CHANGED
|
@@ -48,10 +48,10 @@ You need **DeepSeek Harness** and a **PackyCode (PackyAPI) API key**. For DSH se
|
|
|
48
48
|
Open the desktop application's **Plugins** page, click **Add plugin**, and enter the package name **with a version** as the **package name or address**:
|
|
49
49
|
|
|
50
50
|
```text
|
|
51
|
-
dsh-packycode-api@1.4.
|
|
51
|
+
dsh-packycode-api@1.4.3
|
|
52
52
|
```
|
|
53
53
|
|
|
54
|
-
Choose the **official** install source, then click **Install**. `1.4.
|
|
54
|
+
Choose the **official** install source, then click **Install**. `1.4.3` was the latest release when this was written; the [npm page](https://www.npmjs.com/package/dsh-packycode-api) shows the current one.
|
|
55
55
|
|
|
56
56
|
> **Always include the version.** With a bare `dsh-packycode-api`, the install prompt shows the newest version on npm, but DSH's bundled pnpm by default installs only versions published at least 24 hours ago, so you can end up several releases behind with no sign of it in the prompt. With an exact version, pnpm installs that version and adds it to the profile's `minimumReleaseAgeExclude` itself. Afterwards, check **Current version** under **Settings → PackyCode → Plugin version**.
|
|
57
57
|
|
|
@@ -65,14 +65,14 @@ Open **Settings → PackyCode**. Paste the API key under **Add a key**. A label
|
|
|
65
65
|
|
|
66
66
|
### 3. Select a model
|
|
67
67
|
|
|
68
|
-
Choose a model from the `PackyCode` group.
|
|
68
|
+
Choose a model from the `PackyCode` group. Of the eleven models, Claude runs through this device's Claude Code CLI on `cc` keys; everything else uses the plugin’s HTTP route. Your key’s groups must cover the selected model.
|
|
69
69
|
|
|
70
70
|
<details>
|
|
71
71
|
<summary>Verify the install / other profiles / a local checkout</summary>
|
|
72
72
|
|
|
73
73
|
The **Plugins** page shows the installed state and version, and is also where you enable, disable, or uninstall.
|
|
74
74
|
|
|
75
|
-
**For non-desktop profiles only:** `dsh plugin --profile <name> add dsh-packycode-api@1.4.
|
|
75
|
+
**For non-desktop profiles only:** `dsh plugin --profile <name> add dsh-packycode-api@1.4.3`. Do not use it for `desktop` — the CLI refuses it (`profile "desktop" is managed exclusively by the Electron application`).
|
|
76
76
|
|
|
77
77
|
For a local checkout, keep the `link:` prefix: `dsh plugin --profile <name> add link:/path/to/dsh-packycode-api`. **Do not pass a bare path or `file:`** — that install copies the whole checkout, `node_modules` included, into the profile, where it then shadows the packages the DSH installation itself provides and the plugin looks uninstalled; see the FAQ. If you already installed that way, uninstall first and reinstall as above.
|
|
78
78
|
|
|
@@ -222,7 +222,8 @@ The card shows whether DSH's plugin is on, how many reviews this plugin answered
|
|
|
222
222
|
| --- | --- | --- | --- |
|
|
223
223
|
| `deepseek-flash` | HTTP, Responses, images allowed | Can be off; `low` / `high` / `max` | `deepseek-officially`, `deepseek-sale` |
|
|
224
224
|
| `gpt-6.1-sol` | HTTP, Responses, images allowed | Cannot be off; `low` / `medium` / `high` / `xhigh` / `max` | `codex`, `codex-sale` |
|
|
225
|
-
| `gpt-6-
|
|
225
|
+
| `gpt-6.1-terra` (GPT-6.1 Terra) | Same | Can be off; `low` / `medium` / `high` / `xhigh` / `max` | Same |
|
|
226
|
+
| `gpt-6-astra` | Same | Cannot be off; `low` / `medium` / `high` / `xhigh` / `max` | Same |
|
|
226
227
|
| `gpt-5.6-sol` | Same | Same | Same |
|
|
227
228
|
| `grok-4.7` (Grok 4.7) | HTTP, Responses, text/image input; 500K context | Cannot be off; `low` / `medium` / `high` / `xhigh` | The Grok coverage read from the gateway in Settings |
|
|
228
229
|
| `gemini-4-argon` (Gemini 4 Argon) | HTTP, native Gemini streaming, text/image input; 1,048,576 context, 65,536 output | Cannot be off; `low` / `medium` / `high` | `gemini-slb` |
|
|
@@ -235,7 +236,7 @@ A model in the list does not mean the current token group allows it. When changi
|
|
|
235
236
|
|
|
236
237
|
`jev-latest` (TypeSafe Jev) is not in the model picker: it is a decision model that answers classification questions and cannot hold a conversation, so it only serves [Auto review](#auto-review). The plugin calls `/v1/systemone` host-side; it needs a key in the `typesafe-officially` group, and each key's Jev entry under Accounts and keys shows whether it can.
|
|
237
238
|
|
|
238
|
-
All
|
|
239
|
+
All eleven models in the current catalog declare text and image input. DeepSeek Flash follows the [official vision guide](https://api-docs.deepseek.com/guides/vision/); images are read through DSH's attachment service and sent with the Responses request.
|
|
239
240
|
|
|
240
241
|
Gemini capabilities and limits follow Google's model pages: [Gemini 4 Argon](https://ai.google.dev/gemini-api/docs/models/gemini-4-argon), [Gemini 3.8 Flash](https://ai.google.dev/gemini-api/docs/models/gemini-3.8-flash). Both models use the native Gemini protocol through `/v1beta/models/{model}:streamGenerateContent`, streaming text, thinking and tool calls; images are read through DSH's attachment service. Thinking levels are sent with `thinkingLevel`. Both routes use the single-stream output limit without automatic continuation beyond 65,536 tokens. Available endpoints and groups follow the [PackyAPI live model catalog](https://www.packyapi.com/api/pricing).
|
|
241
242
|
|
|
@@ -243,7 +244,9 @@ Gemini capabilities and limits follow Google's model pages: [Gemini 4 Argon](htt
|
|
|
243
244
|
|
|
244
245
|
Grok 4.7's context and reasoning levels follow the [official guide](https://docs.x.ai/developers/grok-4-7). There is no separate text-output limit; the plugin uses the context size as its numeric output ceiling, bounded by the remaining context per request.
|
|
245
246
|
|
|
246
|
-
Only GPT Responses requests keep `prompt_cache_key`; other Responses models omit it by default. This gateway's Grok route reports a misleading `Incorrect API key provided` error when the field is present, and DeepSeek Flash hits its prefix cache without it.
|
|
247
|
+
Only GPT Responses requests keep `prompt_cache_key`; other Responses models omit it by default. This gateway's Grok route reports a misleading `Incorrect API key provided` error when the field is present, and DeepSeek Flash hits its prefix cache without it. GPT tool definitions also carry an explicit `strict: false`: PackyCode's GPT route treats a tool without `strict` as strict, which forces the model to fill every optional parameter (see the FAQ).
|
|
248
|
+
|
|
249
|
+
GPT-6.1 Terra's context, output limit and effort levels follow OpenAI's [model page](https://developers.openai.com/api/docs/models/gpt-6.1-terra). It is the only GPT model whose reasoning can be off: with effort off it sends `reasoning.effort: "none"`, which the gateway passes through, and the answer comes back without reasoning. GPT-5.6 Sol's documentation lists `none` too, but through PackyCode it answers at `medium`, so it cannot be off.
|
|
247
250
|
|
|
248
251
|
DeepSeek Flash uses the gateway's Responses endpoint (`/api/pricing` lists `openai-response`). With effort off it sends `reasoning.effort: "none"`, and the gateway answers without reasoning; otherwise reasoning comes back as `reasoning_text` and is sent back with the same turn's tool calls.
|
|
249
252
|
|
|
@@ -268,9 +271,9 @@ DeepSeek Flash uses the gateway's Responses endpoint (`/api/pricing` lists `open
|
|
|
268
271
|
|
|
269
272
|
## Update and uninstall
|
|
270
273
|
|
|
271
|
-
> **Upgrading from 1.3.2 or earlier:** install `dsh-packycode-api@1.4.
|
|
274
|
+
> **Upgrading from 1.3.2 or earlier:** install `dsh-packycode-api@1.4.3` on the Plugins page instead of clicking **Update plugin** in the old settings card. The old button bypasses pnpm's release-age policy: if the version it installs is less than 24 hours old, the profile refuses every other plugin install until that version is 24 hours old. After the install and a restart, the button is the fixed one, and later updates can use it.
|
|
272
275
|
|
|
273
|
-
**Update:** open **Settings → PackyCode** and, when a newer version is listed, click **Update plugin**. It installs that exact version into the owning profile with DSH's bundled pnpm and reads `package.json` back before reporting success. The install keeps pnpm's release-age policy instead of overriding it: by default pnpm installs the version at once and records it in the profile's `minimumReleaseAgeExclude`; under a stricter pnpm policy the button says when the update can run. The newer version is read from npm, while pnpm downloads it from the profile's own install source: right after a release that source (a regional mirror in particular) may not have it yet, and the button asks you to update again in a few minutes; when the source cannot be reached, it asks you to check the network or proxy. A local `link:` checkout does not get the button. Then quit and reopen the desktop application. A page refresh does not reload the Host. Reinstalling from the **Plugins** page works too, again with the version in the package name (for example `dsh-packycode-api@1.4.
|
|
276
|
+
**Update:** open **Settings → PackyCode** and, when a newer version is listed, click **Update plugin**. It installs that exact version into the owning profile with DSH's bundled pnpm and reads `package.json` back before reporting success. The install keeps pnpm's release-age policy instead of overriding it: by default pnpm installs the version at once and records it in the profile's `minimumReleaseAgeExclude`; under a stricter pnpm policy the button says when the update can run. The newer version is read from npm, while pnpm downloads it from the profile's own install source: right after a release that source (a regional mirror in particular) may not have it yet, and the button asks you to update again in a few minutes; when the source cannot be reached, it asks you to check the network or proxy. A local `link:` checkout does not get the button. Then quit and reopen the desktop application. A page refresh does not reload the Host. Reinstalling from the **Plugins** page works too, again with the version in the package name (for example `dsh-packycode-api@1.4.3`); without it you may get a version that is merely the newest one published at least 24 hours ago.
|
|
274
277
|
|
|
275
278
|
**Coming back from a local-path install, uninstall first.** An update is a `pnpm add`: it rewrites the files inside the package directory and leaves a `node_modules` that an earlier local-path install left there. That older tree keeps shadowing the packages the DSH installation provides, so the plugin row fails to load with no visible reason. **Uninstall** runs `pnpm remove`, which deletes the package directory outright — only a reinstall after that is clean. `node scripts/install-check.mjs` reports whether a profile is in that state.
|
|
276
279
|
|
|
@@ -286,7 +289,7 @@ ls ~/.dsh/profiles/desktop/node_modules/dsh-packycode-api/node_modules
|
|
|
286
289
|
|
|
287
290
|
Output means a leftover tree: a registry install ships no `node_modules`, so this one usually comes from an earlier local-path install (`file:`, or a bare path instead of `link:`). It sits inside the profile directory, and DSH resolves a plugin's imports from inside the profile first, so the plugin gets those old copies — for example `@deepseek-ai/schemastery` 3.18.2, which has no `Schema.volatile()`, so the module throws while it is imported. When an import fails the Loader creates no fiber for that row and no client bundle is composed either, so the model route, the RPC channel, and the settings panel all stay absent.
|
|
288
291
|
|
|
289
|
-
Recovery: **uninstall** the plugin on the **Plugins** page, **install** it again with the version in the package name (for example `dsh-packycode-api@1.4.
|
|
292
|
+
Recovery: **uninstall** the plugin on the **Plugins** page, **install** it again with the version in the package name (for example `dsh-packycode-api@1.4.3`), then quit and reopen the desktop application. Uninstall runs `pnpm remove` and deletes the whole package directory; reinstalling or clicking **Update** only rewrites files and keeps the leftover tree. Deleting that `node_modules` by hand and restarting works too.
|
|
290
293
|
|
|
291
294
|
**Right after a first install, every card in Settings shows `transport failure for /packycode-api/…: HTTP 405`?** The installed version is 1.1.6 or earlier, usually because only the bare package name was entered: the install prompt shows the newest version, but pnpm installs the newest one published at least 24 hours ago (see **Install the plugin**). Those older versions can register their settings channel only after DSH restarts and rebuilds its `connection` service. So right after a first install `/packycode-api` does not exist yet, requests fall through to the static page, and it answers 405; the model route and the settings panel itself load normally. From 1.1.7 on, a first install needs no restart. Check which version was installed:
|
|
292
295
|
|
|
@@ -300,6 +303,8 @@ Recovery: quit and reopen the desktop application, and the old version works. Th
|
|
|
300
303
|
|
|
301
304
|
**One model fails, but the key is valid?** Look at that key's groups and ✓ / ✕ under **Accounts and keys**. When its groups do not cover the model, use a key whose groups do, or add the group to the key in the PackyCode console. With such a key stored, the plugin runs that model on it automatically. A group refusal never disables a key.
|
|
302
305
|
|
|
306
|
+
**A GPT model's file edit fails with `invalid justification: expected a non-empty sentence`?** This affected 1.4.2 and earlier; update to 1.4.3. PackyCode's GPT route treats a tool without `strict` as strict, so the model had to fill every optional parameter. It sent DSH's sandbox escalation pair as `sandbox_permissions: "workspace-write"` with an empty `justification`, and DSH's edit and write refused the call. From 1.4.3 GPT tool definitions carry an explicit `strict: false`. The model usually finishes the step another way, and existing sessions need nothing.
|
|
307
|
+
|
|
303
308
|
**Claude reports an official-client-only or client-anomaly refusal?** This is a gateway client-policy refusal, not proof of an invalid key. See whether the key is marked “Claude via HTTP” or “via official CLI”: a `cc` key always uses the CLI, and other groups use HTTP. The cc group judges whether a request comes from Claude Code itself; from 1.4.0 cc sessions are carried out by Claude Code and are normally accepted. If one is still refused, resend it; if it keeps happening, send the gateway's own words from the error (with the request id) to PackyCode support, or use a `cc-sale` / `cc-expensive` / `claude-officially` key. Updating the Claude Code CLI does not help with this refusal. The plugin does not disable the key or switch providers.
|
|
304
309
|
|
|
305
310
|
**“Claude Code CLI is not available”?** The key is in `cc`, which needs the CLI on this device. When the message says the key's groups are not read yet, the group reading failed for now (common on an unstable network or proxy): resend shortly, and a key outside `cc` moves to HTTP once its groups are read. Under **Settings → PackyCode → Claude Code CLI** click Install, or run `npm install -g @anthropic-ai/claude-code --allow-scripts=@anthropic-ai/claude-code` and click Check again; set `claudeCliPath` for an unusual location. Otherwise use a `cc-sale` / `cc-expensive` key.
|
package/README.md
CHANGED
|
@@ -48,10 +48,10 @@
|
|
|
48
48
|
打开桌面应用的**插件**页,点击**添加插件**,在**包名或地址**中填入**带版本号**的包名:
|
|
49
49
|
|
|
50
50
|
```text
|
|
51
|
-
dsh-packycode-api@1.4.
|
|
51
|
+
dsh-packycode-api@1.4.3
|
|
52
52
|
```
|
|
53
53
|
|
|
54
|
-
在**安装源**中选择**官方源**,然后点击**安装**。`1.4.
|
|
54
|
+
在**安装源**中选择**官方源**,然后点击**安装**。`1.4.3` 是写这份说明时的最新版,当前最新版本号以 [npm 页面](https://www.npmjs.com/package/dsh-packycode-api) 为准。
|
|
55
55
|
|
|
56
56
|
> **一定要带版本号。** 只填 `dsh-packycode-api` 时,安装前的提示显示的是 npm 上的最新版,但 DSH 自带的 pnpm 默认只安装发布满 24 小时的版本,实际装上的可能是好几个版本之前的旧版,而安装提示里看不出这一点。填写精确版本时,pnpm 会直接安装这个版本,并自动把它加入 profile 的 `minimumReleaseAgeExclude`。装好后可以在 **设置 → PackyCode → 插件版本** 核对「当前版本」。
|
|
57
57
|
|
|
@@ -65,14 +65,14 @@ dsh-packycode-api@1.4.1
|
|
|
65
65
|
|
|
66
66
|
### 3. 选择模型
|
|
67
67
|
|
|
68
|
-
回到对话,在模型选择器里选 `PackyCode`
|
|
68
|
+
回到对话,在模型选择器里选 `PackyCode` 分组下的模型。十一个模型里,Claude 在 `cc` 分组的 Key 上由本机 Claude Code CLI 执行,其余都通过插件内 HTTP 调用;Key 的分组必须覆盖所选模型。
|
|
69
69
|
|
|
70
70
|
<details>
|
|
71
71
|
<summary>检查安装 / 其它 profile / 本地目录</summary>
|
|
72
72
|
|
|
73
73
|
桌面应用的**插件**页可以看到已安装状态与版本,也可以在那里启用、停用或卸载。
|
|
74
74
|
|
|
75
|
-
**仅用于非 desktop profile:** `dsh plugin --profile <name> add dsh-packycode-api@1.4.
|
|
75
|
+
**仅用于非 desktop profile:** `dsh plugin --profile <name> add dsh-packycode-api@1.4.3`。不要对 `desktop` 使用它 —— CLI 会直接拒绝(`profile "desktop" is managed exclusively by the Electron application`)。
|
|
76
76
|
|
|
77
77
|
本地开发要加 `link:` 前缀:`dsh plugin --profile <name> add link:/path/to/dsh-packycode-api`。**不要直接写路径(或 `file:`)** —— 那样的安装会把整个仓库目录(连同 `node_modules`)复制进 profile,之后它会在 profile 内部挡住 DSH 自带的包,插件看起来像没装,见「常见问题」。已经那样装过的话,先卸载再按上面的方式重装。
|
|
78
78
|
|
|
@@ -222,7 +222,8 @@ DSH 自带一个实验性插件「自动授权审查」,默认关闭。开启
|
|
|
222
222
|
| --- | --- | --- | --- |
|
|
223
223
|
| `deepseek-flash` | HTTP,Responses,可带图 | 可关;`low` / `high` / `max` | `deepseek-officially`、`deepseek-sale` |
|
|
224
224
|
| `gpt-6.1-sol` | HTTP,Responses,可带图 | 不能关;`low` / `medium` / `high` / `xhigh` / `max` | `codex`、`codex-sale` |
|
|
225
|
-
| `gpt-6-
|
|
225
|
+
| `gpt-6.1-terra`(GPT-6.1 Terra) | 同上 | 可关;`low` / `medium` / `high` / `xhigh` / `max` | 同上 |
|
|
226
|
+
| `gpt-6-astra` | 同上 | 不能关;`low` / `medium` / `high` / `xhigh` / `max` | 同上 |
|
|
226
227
|
| `gpt-5.6-sol` | 同上 | 同上 | 同上 |
|
|
227
228
|
| `grok-4.7`(Grok 4.7) | HTTP,Responses,可带图;500k 上下文 | 不能关;`low` / `medium` / `high` / `xhigh` | 以设置页从网关读取的 Grok 分组覆盖为准 |
|
|
228
229
|
| `gemini-4-argon`(Gemini 4 Argon) | HTTP,Gemini 原生流式,可带图;1,048,576 上下文,65,536 输出 | 不能关;`low` / `medium` / `high` | `gemini-slb` |
|
|
@@ -235,7 +236,7 @@ DSH 自带一个实验性插件「自动授权审查」,默认关闭。开启
|
|
|
235
236
|
|
|
236
237
|
`jev-latest`(TypeSafe Jev)不在模型选择器里:它是只回答分类问题的决策模型,不能对话,只用于[自动审查](#自动审查)。插件在宿主侧直接调用 `/v1/systemone`,需要 Key 在 `typesafe-officially` 分组;「账户与 Key」里每个 Key 的「Jev」一项会显示能否使用。
|
|
237
238
|
|
|
238
|
-
当前目录中的
|
|
239
|
+
当前目录中的 11 个模型都声明了文字和图像输入。DeepSeek Flash 的识图能力按 [官方图像理解文档](https://api-docs.deepseek.com/zh-cn/guides/vision/) 配置;图片通过 DSH 附件服务读取,再随 Responses 请求发送。
|
|
239
240
|
|
|
240
241
|
Gemini 的能力与限制来自 Google 官方模型页:[Gemini 4 Argon](https://ai.google.dev/gemini-api/docs/models/gemini-4-argon)、[Gemini 3.8 Flash](https://ai.google.dev/gemini-api/docs/models/gemini-3.8-flash)。两款模型统一使用 Gemini 原生协议,通过 `/v1beta/models/{model}:streamGenerateContent` 流式返回文字、思考和工具调用,图片仍由 DSH 附件服务读取。思考档位通过 `thinkingLevel` 传入。两者均使用单次流式输出上限,不执行超过 65,536 token 的自动续写。可用端点与分组以 [PackyAPI 实时模型目录](https://www.packyapi.com/api/pricing) 为准。
|
|
241
242
|
|
|
@@ -243,7 +244,9 @@ Gemini 的能力与限制来自 Google 官方模型页:[Gemini 4 Argon](https:
|
|
|
243
244
|
|
|
244
245
|
Grok 4.7 的上下文与推理档位来自 [官方文档](https://docs.x.ai/developers/grok-4-7)。官方没有单独限制文字输出长度;插件将输出上限设为上下文大小,并按每次请求的剩余上下文收紧。
|
|
245
246
|
|
|
246
|
-
Responses 请求只有 GPT 模型保留 `prompt_cache_key`,其他 Responses 模型默认省略。当前网关的 Grok 路由会将这个字段误报成 `Incorrect API key provided`;DeepSeek Flash 不带它也能命中前缀缓存。
|
|
247
|
+
Responses 请求只有 GPT 模型保留 `prompt_cache_key`,其他 Responses 模型默认省略。当前网关的 Grok 路由会将这个字段误报成 `Incorrect API key provided`;DeepSeek Flash 不带它也能命中前缀缓存。GPT 的工具定义还会显式带上 `strict: false`:PackyCode 的 GPT 通道把没写 `strict` 的工具当作严格模式,模型会被迫填满所有可选参数(见「常见问题」)。
|
|
248
|
+
|
|
249
|
+
GPT-6.1 Terra 的上下文、输出上限和推理档位来自 [OpenAI 模型页](https://developers.openai.com/api/docs/models/gpt-6.1-terra)。它是唯一可以关闭推理的 GPT 模型:关闭时发送 `reasoning.effort: "none"`,网关原样转发,返回时不带思考。GPT-5.6 Sol 的文档虽然也列出 `none`,经 PackyCode 却按 `medium` 回答,所以不能关。
|
|
247
250
|
|
|
248
251
|
DeepSeek Flash 走网关的 Responses 接口(`/api/pricing` 列出 `openai-response`)。关闭推理时发送 `reasoning.effort: "none"`,网关返回时不带思考;开启时思考内容以 `reasoning_text` 返回,并随同一轮的工具调用一起回传。
|
|
249
252
|
|
|
@@ -268,9 +271,9 @@ DeepSeek Flash 走网关的 Responses 接口(`/api/pricing` 列出 `openai-res
|
|
|
268
271
|
|
|
269
272
|
## 更新与卸载
|
|
270
273
|
|
|
271
|
-
> **从 1.3.2 或更早版本升级:** 请在插件页填写 `dsh-packycode-api@1.4.
|
|
274
|
+
> **从 1.3.2 或更早版本升级:** 请在插件页填写 `dsh-packycode-api@1.4.3` 安装,不要点旧版设置页里的「更新插件」。旧按钮安装时会绕过 pnpm 的发布冷却期:装到的版本如果发布还不满 24 小时,这个 profile 在它满 24 小时之前就装不了其他插件。装好并重启后,按钮就换成了修好的版本,以后直接点即可。
|
|
272
275
|
|
|
273
|
-
**更新:** 打开 **设置 → PackyCode**,有新版本时点「更新插件」。它会在当前 profile 目录里用 DSH 自带的 pnpm 安装精确版本,并读回 `package.json` 确认版本落地。安装遵守 pnpm 的发布冷却策略,不会绕过它:默认情况下 pnpm 会直接装上这个版本,并把它记进 profile 的 `minimumReleaseAgeExclude`;如果你给 pnpm 配了更严格的策略,按钮会提示什么时候可以更新。新版本号是从 npm 读到的,pnpm 却从 profile 配置的安装源下载:刚发布的版本,安装源(尤其是国内镜像)可能还没同步到,这时按钮会提示过几分钟再更新;连不上安装源时,会提示检查网络或代理。本地 `link:` 开发安装不会出现这个按钮。完成后完全退出并重新打开桌面应用。只刷新页面不会重载 Host。也可以在**插件**页重新安装,同样要填写带版本号的包名(例如 `dsh-packycode-api@1.4.
|
|
276
|
+
**更新:** 打开 **设置 → PackyCode**,有新版本时点「更新插件」。它会在当前 profile 目录里用 DSH 自带的 pnpm 安装精确版本,并读回 `package.json` 确认版本落地。安装遵守 pnpm 的发布冷却策略,不会绕过它:默认情况下 pnpm 会直接装上这个版本,并把它记进 profile 的 `minimumReleaseAgeExclude`;如果你给 pnpm 配了更严格的策略,按钮会提示什么时候可以更新。新版本号是从 npm 读到的,pnpm 却从 profile 配置的安装源下载:刚发布的版本,安装源(尤其是国内镜像)可能还没同步到,这时按钮会提示过几分钟再更新;连不上安装源时,会提示检查网络或代理。本地 `link:` 开发安装不会出现这个按钮。完成后完全退出并重新打开桌面应用。只刷新页面不会重载 Host。也可以在**插件**页重新安装,同样要填写带版本号的包名(例如 `dsh-packycode-api@1.4.3`),否则装上的可能是发布满 24 小时的旧版。
|
|
274
277
|
|
|
275
278
|
**从本地路径安装切回官方源时,必须先卸载。** 「更新」是 `pnpm add`,它只重写包目录里的文件,不会删除更早一次本地路径安装留在包目录内的 `node_modules`;那份旧依赖会继续挡住 DSH 自带的包,插件行加载失败且看不出原因。「卸载」执行的是 `pnpm remove`,会删掉整个包目录,重装才是干净的。用 `node scripts/install-check.mjs` 可以确认当前 profile 是否处于这个状态。
|
|
276
279
|
|
|
@@ -286,7 +289,7 @@ ls ~/.dsh/profiles/desktop/node_modules/dsh-packycode-api/node_modules
|
|
|
286
289
|
|
|
287
290
|
有输出就是残留:从 npm 安装的包不会自带 `node_modules`,这一份通常来自更早一次「本地路径」安装(`file:` 或直接写路径,而不是 `link:`)。它位于 profile 目录内部,而 DSH 解析插件导入时优先使用 profile 内的副本,所以插件拿到的仍是那份旧依赖 —— 例如 `@deepseek-ai/schemastery` 3.18.2 没有 `Schema.volatile()`,模块在导入阶段就抛错。导入失败时 Loader 不会为这一行创建 fiber,客户端 bundle 也不会被组合,于是模型路由、RPC 通道和设置页全都不会出现。
|
|
288
291
|
|
|
289
|
-
修复:到**插件**页**卸载**本插件,再用带版本号的包名重新**安装**(例如 `dsh-packycode-api@1.4.
|
|
292
|
+
修复:到**插件**页**卸载**本插件,再用带版本号的包名重新**安装**(例如 `dsh-packycode-api@1.4.3`),然后完全退出并重新打开桌面应用。卸载执行的是 `pnpm remove`,会删掉整个包目录;直接重装或点「更新」只重写文件,不会清掉这份残留。也可以手动删掉上面那个 `node_modules` 再重启。
|
|
290
293
|
|
|
291
294
|
**首次安装后,设置页每张卡片都显示 `transport failure for /packycode-api/…: HTTP 405`?** 实际装上的是 1.1.6 或更早的版本,通常是因为安装时只填了包名:安装提示显示的是最新版,pnpm 实际装的却是发布满 24 小时的旧版(见「安装插件」)。这些旧版要等 DSH 重启、重建它的 `connection` 服务之后,才能注册设置通道。所以首次安装后 `/packycode-api` 通道还不存在,请求落到静态页面,返回 405;模型路由和设置页本身照常加载。1.1.7 起首次安装不需要重启。先确认装上的版本:
|
|
292
295
|
|
|
@@ -298,6 +301,8 @@ grep '"version"' ~/.dsh/profiles/desktop/node_modules/dsh-packycode-api/package.
|
|
|
298
301
|
|
|
299
302
|
**某个模型不可用,但 Key 是有效的?** 看「账户与 Key」里这个 Key 的分组和 ✓ / ✕:分组不覆盖这个模型时,换一个分组合适的 Key,或在 PackyCode 控制台给 Key 加上对应分组。存了分组合适的 Key 时,插件会自动用它跑这个模型。分组拒绝不会停用 Key。
|
|
300
303
|
|
|
304
|
+
**GPT 模型改文件时报 `invalid justification: expected a non-empty sentence`?** 这是 1.4.2 及更早版本的问题,更新到 1.4.3 即可。PackyCode 的 GPT 通道把没写 `strict` 的工具当作严格模式,模型被迫填满所有可选参数,把 DSH 的沙箱提权参数填成 `sandbox_permissions: "workspace-write"` 加空的 `justification`,DSH 的 edit / write 于是拒绝这次调用。1.4.3 起 GPT 的工具定义显式带上 `strict: false`。模型通常会换一种方式完成这一步,已有会话不需要处理。
|
|
305
|
+
|
|
301
306
|
**Claude 报「只接受官方 Claude Code CLI」或「客户端存在异常」?** 这是网关的客户端政策拒绝,不等于 Key 失效。看这个 Key 下方标的是「Claude 经 HTTP」还是「经官方 CLI」:`cc` 分组的 Key 总是走 CLI,其它分组走 HTTP。cc 分组按请求内容判断是不是 Claude Code 自己在工作;1.4.0 起 cc 会话由 Claude Code 自己完成,正常不会被拒。偶尔仍被拒时重发一次;反复出现时,把错误里的网关原文(含 request id)发给 PackyCode 客服,或改用 `cc-sale` / `cc-expensive` / `claude-officially` 分组的 Key。更新 Claude Code CLI 不能解决这个拒绝。插件不会因此禁用 Key 或切换提供商。
|
|
302
307
|
|
|
303
308
|
**提示「本机没有可用的 Claude Code CLI」?** 当前 Key 在 `cc` 分组,需要本机 CLI。提示里写着「插件还没读到当前 Key 的分组」时,是分组读取暂时失败(网络或代理不稳时常见):稍后重发即可,不在 `cc` 分组的 Key 读到分组后会自动改走 HTTP。到 **设置 → PackyCode → Claude Code CLI** 点「安装」,或在终端执行 `npm install -g @anthropic-ai/claude-code --allow-scripts=@anthropic-ai/claude-code` 后点「重新检测」;装在非常规位置时可在配置里填 `claudeCliPath`。不想装的话,换用 `cc-sale` / `cc-expensive` 分组的 Key。
|
package/lib/client.js
CHANGED
package/lib/index.js
CHANGED
|
@@ -1076,9 +1076,9 @@ const DEFAULT_REASONING_LEVEL = "high";
|
|
|
1076
1076
|
*
|
|
1077
1077
|
* Effort levels come from each vendor's documentation, because an effort the
|
|
1078
1078
|
* model does not support is refused before the request is sent: Claude Opus
|
|
1079
|
-
* 5.5 (platform.claude.com effort docs), GPT-6.1 Sol, GPT-6
|
|
1080
|
-
* Sol `reasoning.effort` (developers.openai.com model
|
|
1081
|
-
* thinking mode (`low|high|max` effort, or off), Grok 4.7
|
|
1079
|
+
* 5.5 (platform.claude.com effort docs), GPT-6.1 Sol, GPT-6.1 Terra, GPT-6
|
|
1080
|
+
* Astra and GPT-5.6 Sol `reasoning.effort` (developers.openai.com model
|
|
1081
|
+
* pages), DeepSeek thinking mode (`low|high|max` effort, or off), Grok 4.7
|
|
1082
1082
|
* (docs.x.ai/developers/grok-4-7), and Gemini 4 Argon
|
|
1083
1083
|
* (ai.google.dev/gemini-api/docs/models/gemini-4-argon and docs/openai).
|
|
1084
1084
|
*
|
|
@@ -1095,6 +1095,16 @@ const RESPONSES_BASE = `${DEFAULT_API_HOST}/v1`;
|
|
|
1095
1095
|
const MESSAGES_BASE = DEFAULT_API_HOST;
|
|
1096
1096
|
const GEMINI_BASE = `${DEFAULT_API_HOST}/v1beta`;
|
|
1097
1097
|
/**
|
|
1098
|
+
* PackyCode's GPT route treats a function tool that names no `strict` as
|
|
1099
|
+
* strict, so the model fills every optional parameter. DSH's sandbox
|
|
1100
|
+
* escalation pair then came back as `workspace-write` with an empty
|
|
1101
|
+
* justification, which DSH's edit and write refuse. Declaring strict-mode
|
|
1102
|
+
* support makes pi-ai send `strict: false` on each tool, as the official
|
|
1103
|
+
* Codex client does; the schemas stay as DSH wrote them. DeepSeek and Grok
|
|
1104
|
+
* leave optional parameters out either way.
|
|
1105
|
+
*/
|
|
1106
|
+
const GPT_COMPAT = Object.freeze({ supportsStrictMode: true });
|
|
1107
|
+
/**
|
|
1098
1108
|
* pi-ai thinking-level maps. A level pinned to `null` is unsupported; an
|
|
1099
1109
|
* absent key keeps pi-ai's own default for that level, which is how `off`
|
|
1100
1110
|
* stays available for DeepSeek: pi-ai's Responses API then sends
|
|
@@ -1122,6 +1132,20 @@ const ALWAYS_THINKING_LEVELS = Object.freeze({
|
|
|
1122
1132
|
xhigh: "xhigh",
|
|
1123
1133
|
max: "max"
|
|
1124
1134
|
});
|
|
1135
|
+
/**
|
|
1136
|
+
* GPT-6.1 Terra documents `reasoning.effort` none | low | medium | high |
|
|
1137
|
+
* xhigh | max, and PackyCode passes its `none` through (no reasoning tokens),
|
|
1138
|
+
* so `off` keeps pi-ai's default and sends `none`. `minimal` is not
|
|
1139
|
+
* documented; the gateway answers it as `none`.
|
|
1140
|
+
*/
|
|
1141
|
+
const TERRA_LEVELS = Object.freeze({
|
|
1142
|
+
minimal: null,
|
|
1143
|
+
low: "low",
|
|
1144
|
+
medium: "medium",
|
|
1145
|
+
high: "high",
|
|
1146
|
+
xhigh: "xhigh",
|
|
1147
|
+
max: "max"
|
|
1148
|
+
});
|
|
1125
1149
|
/** Grok 4.7 supports low | medium | high | xhigh, with no off or max. */
|
|
1126
1150
|
const GROK_LEVELS = Object.freeze({
|
|
1127
1151
|
...ALWAYS_THINKING_LEVELS,
|
|
@@ -1158,7 +1182,22 @@ const PACKYCODE_MODELS = Object.freeze([
|
|
|
1158
1182
|
cost: NO_COST,
|
|
1159
1183
|
contextWindow: 105e4,
|
|
1160
1184
|
maxTokens: 128e3,
|
|
1161
|
-
thinkingLevelMap: ALWAYS_THINKING_LEVELS
|
|
1185
|
+
thinkingLevelMap: ALWAYS_THINKING_LEVELS,
|
|
1186
|
+
compat: GPT_COMPAT
|
|
1187
|
+
}),
|
|
1188
|
+
Object.freeze({
|
|
1189
|
+
id: "gpt-6.1-terra",
|
|
1190
|
+
name: "GPT-6.1 Terra",
|
|
1191
|
+
api: "openai-responses",
|
|
1192
|
+
provider: PROVIDER,
|
|
1193
|
+
baseUrl: RESPONSES_BASE,
|
|
1194
|
+
reasoning: true,
|
|
1195
|
+
input: Object.freeze(["text", "image"]),
|
|
1196
|
+
cost: NO_COST,
|
|
1197
|
+
contextWindow: 105e4,
|
|
1198
|
+
maxTokens: 128e3,
|
|
1199
|
+
thinkingLevelMap: TERRA_LEVELS,
|
|
1200
|
+
compat: GPT_COMPAT
|
|
1162
1201
|
}),
|
|
1163
1202
|
Object.freeze({
|
|
1164
1203
|
id: "gpt-6-astra",
|
|
@@ -1171,7 +1210,8 @@ const PACKYCODE_MODELS = Object.freeze([
|
|
|
1171
1210
|
cost: NO_COST,
|
|
1172
1211
|
contextWindow: 105e4,
|
|
1173
1212
|
maxTokens: 128e3,
|
|
1174
|
-
thinkingLevelMap: ALWAYS_THINKING_LEVELS
|
|
1213
|
+
thinkingLevelMap: ALWAYS_THINKING_LEVELS,
|
|
1214
|
+
compat: GPT_COMPAT
|
|
1175
1215
|
}),
|
|
1176
1216
|
Object.freeze({
|
|
1177
1217
|
id: "gpt-5.6-sol",
|
|
@@ -1184,7 +1224,8 @@ const PACKYCODE_MODELS = Object.freeze([
|
|
|
1184
1224
|
cost: NO_COST,
|
|
1185
1225
|
contextWindow: 105e4,
|
|
1186
1226
|
maxTokens: 128e3,
|
|
1187
|
-
thinkingLevelMap: ALWAYS_THINKING_LEVELS
|
|
1227
|
+
thinkingLevelMap: ALWAYS_THINKING_LEVELS,
|
|
1228
|
+
compat: GPT_COMPAT
|
|
1188
1229
|
}),
|
|
1189
1230
|
Object.freeze({
|
|
1190
1231
|
id: "grok-4.7",
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "dsh-packycode-api",
|
|
3
|
-
"version": "1.4.
|
|
3
|
+
"version": "1.4.3",
|
|
4
4
|
"description": "Use PackyCode API keys in DeepSeek Harness with multi-protocol models, image generation and editing, separate key rings, and balance display",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./lib/index.js",
|