sandbox: buildBackendOptions drops backend.model — the worker runs the platform's model while the receipt asserts the profile's

[drewstone]

buildBackendOptions drops backend.model, so a sandbox worker runs whatever model the box picks, while the run record asserts the declared one.

The code

dist/supervisor-BfJNS2Z3.js:4038-4053 (0.138.0):

function buildBackendOptions(profile, overrides) {
 assertExecutableAgentProfile(profile, "buildBackendOptions");
 const base = overrides ?? {};
 const overrideBackend = base.backend;
 const overrideModel = overrideBackend?.model?.model;
 const profileModel = concreteProfileModel(profile);
 if (overrideModel !== void 0 && overrideModel !== profileModel) throw new Error(...);
 return {
 ...base,
 backend: {
 type: resolveBackendType(profile, overrideBackend),
 profile,
 ...overrideBackend?.server ? { server: overrideBackend.server } : {}
 }
 };
}

overrideModel is read only to be validated. profileModel is read only to validate against. Neither is sent. server passes through; model does not. BackendConfig.model is a documented create field (@tangle-network/sandbox 0.27.1, dist/types-DL7FzacJ.d.ts:4772: {provider?, model?, apiKey?, baseUrl?, mode?, authMode?, authFiles?}), and with it absent the platform resolves the model itself.

The measurement

Live infrastructure, 2026-08-17, https://sandbox.tangle.tools. Six boxes, five distinct child profiles, four supervised runs plus one direct probe. Every profile declared harness: "opencode", model: {provider: "zai-coding-plan", default: "glm-5.2"}.

Every box reported the same thing on execution.started and again on done:

{"provider":"openai-compat","model":"deepseek/deepseek-v4-flash","source":"environment",
 "profile":{"name":"floor-augmenter","digest":"cb2ad63e0d35e1db"}}

source: "environment" is the platform saying it chose the model, because the request carried none. Note the profile is present and correct in the same object — the box received the profile and still did not take its model. Inside a box:

agent 225 opencode run --format json --thinking --model openai-compat/deepseek/deepseek-v4-flash --agent tangle-profile-b79b016ed7aac571

Why this is worse than a wrong default

sandboxExecutor records the opposite, at :7128:

model: profileModel ? { status: "known", id: profileModel } : { status: "unknown", reason: "sandbox harness selected its default model" }

The "unknown" branch exists precisely for this case and is unreachable whenever the profile names a model — which is exactly when the substitution happens. So the materialization receipt asserts status: "known" for a model that did not run, and every measurement taken on that worker is attributed to the wrong instrument. In our case a subscription credential was provisioned into each box, declared in the profile, recorded in the manifest, and never used by anything.

Repro

Create a sandbox executor with backend: 'sandbox' and a profile declaring any concrete model, run one turn, and read effectiveBackend off the first execution.started event. It will report the platform default with source: "environment".

Ask

1. buildBackendOptions sends backend.model derived from concreteProfileModel(profile) (and passes an override through, since it already validates the two agree).
2. When the platform's effectiveBackend does not match what was asked for, the run fails or the materialization records status: "mismatch" with both ids — a receipt that names an instrument that did not run is worse than one that says "unknown".

Downstream mitigation

discovery-lab sets backend.model in its own SandboxClient.create and refuses any box whose effectiveBackend is not the seat's model. Verified: with the field set, the same probe reports {"provider":"zai-coding-plan","model":"glm-5.2","source":"request"}. The workaround only exists because a caller-supplied SandboxClient is the one seam that reaches the create request; a consumer using createExecutor({backend:'sandbox'}) alone has no way to send the model at all.

[drewstone]

Correction to my own last paragraph — the downstream workaround does not work, and the reason widens the ask.

I wrote that setting backend.model in a caller-supplied SandboxClient fixes this. It changes what the platform reports and leaves the box unable to answer. Measured 2026-08-17, five boxes, one prompt each ("Reply with exactly: 42"), same seat, same secret, same egress:

backend.model sent at create	effectiveBackend reported	answer
(absent — today's behaviour)	openai-compat / deepseek/deepseek-v4-flash, source: environment	"42"
{provider:"zai-coding-plan", model:"glm-5.2"}	zai-coding-plan / glm-5.2, source: request	nothing
{…, mode:"cli"}	zai-coding-plan / glm-5.2, source: request	nothing
{…, mode:"cli", authMode:"api-key"}	zai-coding-plan / glm-5.2, source: request	nothing
{model:"zai-coding-plan/glm-5.2"}	openai-compat / zai-coding-plan/glm-5.2, source: request	nothing

Inside a box created with the second row, the process line is:

opencode run --format json --thinking --model openai-compat/zai-coding-plan/glm-5.2 --agent tangle-profile-…

The box composes its own openai-compat/ prefix onto whatever provider the request names and points OpenCode at OPENAI_BASE_URL=https://router.tangle.tools/v1, which does not serve that id. The run then sits at status: started — no session.updated, no "OpenCode started the model turn" — for as long as you leave it (observed 10+ minutes). Meanwhile effectiveBackend cheerfully reports zai-coding-plan/glm-5.2, source: "request", so the reported identity is wrong in the other direction: it names a model that is configured and cannot run.

So there are two things here, and only the first is the runtime's:

1. Runtime drops backend.model and then asserts status: "known" for the profile's model anyway (the original report above).
2. The platform accepts backend.model.provider, reports it back as source: "request", and then routes the box through openai-compat/<provider>/<model> against a base URL that cannot serve it — with no error, just a stalled execution. A provider the box cannot actually route should fail the create, not the turn, and never be echoed back as the effective identity.

Because of (2) we are not shipping the workaround. discovery-lab now refuses any box whose effectiveBackend is not the seat's declared model, which fails the placement loudly instead of attributing deepseek-v4-flash results to glm-5.2. A consumer that wants a specific model on a sandbox worker currently has no working path at all.