The D601 provider-gateway egress proxy (127.0.0.1:18789) is a
WebSocket-tunneled CONNECT proxy to backend-core. Long npm downloads
(playwright tarball ~3MB, plus tarball streaming) trigger ECONNRESET
mid-install, which then compounds into ENOTEMPTY on the next npm
retry because the partial global install is not cleaned up. The
in-dockerfile retry loop (5 attempts) exhausts and the image build
fails at Step 12/37.
The build's --build-arg NO_PROXY only listed localhost / 127.0.0.1 /
::1 / host.docker.internal, so every npm fetch went through the
proxy. Direct curl tests from D601 to registry.npmjs.org succeed at
HTTP 200 with ~280 KB/s, well above what the WS tunnel can sustain
for multi-MB downloads.
Persist the fix in both D601 and G14 pipeline manifests by adding
registry.npmjs.org and .registry.npmjs.org to NO_PROXY so docker
build's npm install goes direct. The proxy is still used for apt-get
and any other traffic that doesn't match the expanded NO_PROXY list,
so unrelated egress continues through the provider-gateway.
Refs: #189
M2.7 and M3 are two parallel configs, not a primary/fallback pair.
Per user feedback, drop the language and any code that framed M2.7 as
a rollback target for M3.
- code-queue-supervision.md, microservices.md, windows-passthrough.md:
remove 'default/fallback' labels; spell out that M2.7 and M3 are
parallel, no auto-fallback, switching provider model is an explicit
ops action.
- scripts/src/code-queue.ts: modelTiers entries for M3 and M2.7 share
the same 'simple-low-risk' risk; rename
minimaxM2FallbackCandidate -> minimaxM27Candidate so the dry-run
command string no longer implies fallback semantics.
- scripts/code-queue-submit-routing-contract-test.ts: drop 'fallback'
wording in assertions and the 'model registry fallback' check label.
Refs: #189
Add minimax-m3 as a sibling model on the same path as the existing
minimax-m2.7 support. M3 is the new PROD default; M2.7 remains available
as a one-line rollback target via MINIMAX_MODEL.
Changes:
- code-agent/common.ts: add minimaxM3Model constant, include in
defaultCodeModels, normalize aliases (minimax-m3 / m3), route to
opencode port, sibling entry in codeModelProviderSourceContract.
- code-agent/opencode.ts: add M3 branch in openCodeModelId, register
both M2.7 and M3 in openCodeConfigContent, inject MINIMAX_M3_MODEL
in local/remote env, M3 branch in missingOpenCodeCredentialMessage.
- index.ts + types.ts: add minimaxM3Model to RuntimeConfig, read
MINIMAX_M3_MODEL env, propagate to remoteCodexEnvKeys.
- queue-api.ts: include minimaxM3Model in Pick for
codeModelProviderSourceContract callers.
- scripts/src/code-queue.ts: add minimaxM3SubmitModel, normalize/port
routing, default route recommendation now points to M3, M2.7 kept
as minimaxM2FallbackCandidate.
- scripts/src/docker.ts: default UNIDESK_CODE_QUEUE_MINIMAX_M3_MODEL
to MiniMax-M3.
- k8s yaml (D601 + G14): CODE_QUEUE_MODELS gains minimax-m3, three
deployments each set MINIMAX_MODEL=MiniMax-M3 and
MINIMAX_M3_MODEL=MiniMax-M3.
- docker-compose.d601.yml: same env defaults for local compose.
- docs/reference/{code-queue-supervision,microservices,
windows-passthrough}.md: update model contracts to M3 default +
M2.7 fallback.
- scripts/code-queue-submit-routing-contract-test.ts: low-risk
recommendation now asserts minimax-m3; registry asserts both M3
and M2.7 fallback in modelPorts/opencodeModels; provider source
contract test passes minimaxM3Model.
Refs: #189
Codex