[ananthsub]

What does this PR do?

Defines the opt-in native Resources Server seed, typed verify, and close contracts beside their owning routes. ResourcesVerifyResponse preserves benchmark-specific fields at the Environment Server boundary without changing BaseVerifyResponse behavior for existing verifiers. Existing empty base seed models remain unchanged.

Single-agent interaction flow

This diagram shows the built-in single-agent use case. Other Environment Server protocols may coordinate different participants and use different request, result, and lifecycle flows.

sequenceDiagram
    participant C as Rollout collector
    participant E as Environment Server
    participant R as Task / Resources Server
    participant A as Agent Server
    participant M as Model Server
    participant S as Task sandbox

    C->>E: POST /run
    E->>R: Seed task session
    R-->>E: Tool access and optional SandboxAccess
    E->>A: Seed agent session
    A->>S: Connect as borrower when supplied
    E->>A: Invoke /v1/responses
    A->>M: Model and capture requests
    A-->>E: Agent response
    E->>A: Close agent session
    E->>R: Verify response
    E->>R: Close task session
    E-->>C: Episode result

Loading

The Environment Server coordinates ordering and the final result. Agent and Task/Resources Servers retain ownership of the state and resources they create.

This is part 7 of 13 in the Environment Server stack. Previous: #3485. Next: #3487.

Validation

• uv run pytest tests/unit_tests/test_base_resources_server.py tests/unit_tests/test_resources_sessions.py -q
• uv run --with math-verify==0.8.0 --with datasets pytest resources_servers/math_with_judge/tests/test_app.py::TestApp::test_verify -q

Rollouts

See the final PR for end-to-end rollout evidence.

Compatibility and benchmark impact

Resources Servers migrate incrementally; existing request models remain valid.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[waple0820]

@ananthsub one question on the close contract, since #2609 reads differently.

ResourcesCloseSessionRequest takes resources_session_id, which ResourcesSeedSessionResponse returns. That makes the id reachable only through the seed response. #2609's design says the opposite:

The caller creates a high-entropy _ng_session_id and separate close capability before the first seed transmission ... Provider-created env_session_id is diagnostic metadata, not cleanup identity.

The distinction matters in the case that motivated #2609 for us. Our client gave up on a create at 120s; the server kept going and the session came up at 360s. The response never arrived, so nobody held that id — and the slot stayed occupied until the service expired it. Across steps 61–80 that cost 1172 of 1280 rollouts, with mean reward going from 15.45% to 0.39%.

A caller-generated id closes that case: the id exists before the request is sent, so a lost response still leaves something to close. It also makes seed deduplication possible, since a retry carries the same id rather than allocating a second session.

Is the seed-returned id in #3544 the intended direction, with #2609's caller-created identity dropped? Or is resources_session_id meant to be the caller's value echoed back, in which case the seed request needs to carry it? #2612 implements the #2609 shape and is rebased onto this, so I can move it either way once the direction is clear.