[emiehling]

• VLLMBackend runs a vLLM AsyncLLM engine on an event loop that the backend owns on a daemon thread, and its session submits one engine request per item
• Concurrent generate() calls share the engine's running batch, and each request returns when its own generation finishes
• The engine is built under vLLM's LLM_CLASS usage context, which keeps the scheduler defaults of an offline vllm.LLM engine
• engine_kwargs is forwarded to AsyncEngineArgs. Per-request lifecycle logging defaults off, and the periodic stats logging keeps vLLM's default (on)
• SteeringPipeline has a new supports_concurrent_generate property and a prompt lock. Each call's prompt phase runs under the lock, and the dispatch runs concurrently only on the vLLM backends without an enabled decoding driver
• steer(), release_backends(), and compute_logprobs() run under the prompt lock for their whole duration
• CancelToken and GenerationCancelled cancel a generation from another thread through the reserved cancel_token keyword. The offline engine aborts the call's requests, and the in-process and serve sessions stop between items
• SteeringSession.generate and SteeringSession.score take a keyword-only cancel_token, and SteeredSession forwards it to a driver's rollouts
• VLLMBackend.release() cancels the requests in flight before it shuts the engine down, and their calls raise EngineClosedError
• ProviderOptions.max_concurrency selects per-request mode in the Inspect provider. Each request is its own pipeline call seeded from the base seed and the request, and a cancelled request aborts its generation
• SteeringEval records the dispatch mode as dispatch_mode in the run provenance
• Tests cover the prompt lock, cancellation, the engine thread, per-request dispatch, and concurrent requests on the offline and plugin engines
• AGENTS.md, the steering pipelines concept page, and the evaluation tutorial describe concurrent generation, cancellation, and per-request mode
• version bump to 0.5.7