Spawned remote agent harness shows wrong context sizes

rs commented

2026-09-17 10:05:52 +00:00

Owner

A deepseek-flash in a remote spawned pod shows a context maximum of 66k instead of the real 1 million that should be available. Fix context display.

rs commented

2026-09-17 10:44:50 +00:00

Author

Owner

Fixed in commit 6a56d7f.

Root cause: a spawned session pod builds its agent from the agent image's config, so the provider's context_length was the image's built-in default (deepseek 65536 â shown as 66k) rather than the spawning console's setting. The console's provider/model, remote-tools and documented_tools/references settings already travelled with the create request, but the context window did not.

Fix: propagate the console's context window for the selected provider the same way max_iterations is propagated:

harness spawn resolves providers.<name>.context_length and sends it as context_length in the create request.
the controller hands it to both backends (appended to the session's agentd args as --context-length on the process and cluster paths, mirroring --max-iterations).
agentd accepts --context-length and applies it to the active provider before the agent is built, so ContextUsage() reports the console's real limit in the context meter.

A request without the value leaves the session on its own config/default (including 0 â auto-detection for a local provider). The README, the multi-agent/e2e docs, the harness-agent chart (contextLength value) and the unit/e2e tests were updated to match.

Fixed in commit `6a56d7f`. **Root cause:** a spawned session pod builds its agent from the *agent image's* config, so the provider's `context_length` was the image's built-in default (deepseek `65536` â shown as `66k`) rather than the spawning console's setting. The console's `provider`/`model`, `remote-tools` and `documented_tools`/`references` settings already travelled with the create request, but the context window did not. **Fix:** propagate the console's context window for the selected provider the same way `max_iterations` is propagated: - `harness spawn` resolves `providers.<name>.context_length` and sends it as `context_length` in the create request. - the controller hands it to both backends (appended to the session's `agentd` args as `--context-length` on the process and cluster paths, mirroring `--max-iterations`). - `agentd` accepts `--context-length` and applies it to the active provider before the agent is built, so `ContextUsage()` reports the console's real limit in the context meter. A request without the value leaves the session on its own config/default (including `0` â auto-detection for a local provider). The README, the multi-agent/e2e docs, the `harness-agent` chart (`contextLength` value) and the unit/e2e tests were updated to match.

rs commented

2026-09-17 10:52:23 +00:00

Author

Owner

Released as v0.10.0 (tag v0.10.0 at 6a56d7f; CI/release and container images all green).

Released as `v0.10.0` (tag `v0.10.0` at `6a56d7f`; CI/release and container images all green).

rs commented

2026-09-17 11:01:47 +00:00

Author

Owner

Not solved, still shows deepseek-flash ctx 45k/66k (68%)

rs commented

2026-09-17 14:58:55 +00:00

Author

Owner

Reopened investigation: fixed on main in f6dcdab, released as v0.10.3.

Why 6a56d7f did not solve it: the create request only travelled providers.<name>.context_length. But a config that customizes a built-in provider (for example a local deepseek endpoint with a custom base_url/model) replaces the default entry when YAML-decoded, and applyDefaults never restores context_length. The value therefore ends up 0, the console falls back to auto-detection and displays the detected 1M, while spawn forwarded 0 (nothing) and the session fell back to the agent image's default (deepseek 65536, shown as 66k). Hence console 1M vs pod 66k.

Fix: providerContextLength now resolves the effective window for a spawn: the configured value, or, when it is 0 (auto-detect) and the provider is local, the value detected from the endpoint (/props), matching what the console displays. spawn sends that, so the session inherits the same limit.

spawn: providers.deepseek.context_length == 0 + local base_url
  -> detect 1000000 -> send context_length=1000000
  -> agentd --context-length 1000000 -> pod shows ctx .../1.0m

Tests: TestProviderContextLengthDetectsLocal (fake /props returns 1M) plus the existing configured-value cases; gofmt, go vet ./..., go test -count=1 ./... pass. Docs (README.md, docs/multi-agent.md, docs/e2e.md) now say the effective/detected window is inherited.

Note: a non-local provider with context_length unset still sends nothing (unknown), and the pod keeps its own default; set context_length explicitly for a remote endpoint. Leaving open for verification.

Reopened investigation: fixed on `main` in `f6dcdab`, released as `v0.10.3`. **Why `6a56d7f` did not solve it:** the create request only travelled `providers.<name>.context_length`. But a config that customizes a built-in provider (for example a local `deepseek` endpoint with a custom `base_url`/`model`) replaces the default entry when YAML-decoded, and `applyDefaults` never restores `context_length`. The value therefore ends up `0`, the console falls back to auto-detection and displays the detected 1M, while `spawn` forwarded `0` (nothing) and the session fell back to the agent image's default (deepseek 65536, shown as `66k`). Hence console 1M vs pod 66k. **Fix:** `providerContextLength` now resolves the *effective* window for a spawn: the configured value, or, when it is `0` (auto-detect) and the provider is local, the value detected from the endpoint (`/props`), matching what the console displays. `spawn` sends that, so the session inherits the same limit. ``` spawn: providers.deepseek.context_length == 0 + local base_url -> detect 1000000 -> send context_length=1000000 -> agentd --context-length 1000000 -> pod shows ctx .../1.0m ``` **Tests:** `TestProviderContextLengthDetectsLocal` (fake `/props` returns 1M) plus the existing configured-value cases; `gofmt`, `go vet ./...`, `go test -count=1 ./...` pass. Docs (`README.md`, `docs/multi-agent.md`, `docs/e2e.md`) now say the effective/detected window is inherited. Note: a non-local provider with `context_length` unset still sends nothing (unknown), and the pod keeps its own default; set `context_length` explicitly for a remote endpoint. Leaving open for verification.

Rows
Columns

Spawned remote agent harness shows wrong context sizes #2