Self-hosted pool worker never reports `isInUse=true`

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

A self-hosted pool worker runs agent turns normally, but the public API never
reports it as busy. During an active agent run on the worker:

  • GET /v0/private-workers returns isInUse=false for that worker.
  • activeBcId stays null (never set to the id of the running agent).
  • GET /v0/private-workers/summary reports inUse=0.
  • The pool listing (GET /v0/private-workers/pools) reports
    inUseWorkerCount=0 while a run is in progress.

Per the current API docs, isInUse is defined as “Whether the worker currently
has an assigned agent”, and activeBcId is “Id of the agent currently running
on the worker, when in use.” Neither reflects reality while the worker is
executing a run.

Because of this, any autoscaling or fleet-sync logic that keys off isInUse
(or inUseWorkerCount, or activeBcId) cannot tell which worker is executing
which agent. Utilization always reads as 0, so scaling and routing decisions are
made on wrong data.

Steps to Reproduce

  1. Start a self-hosted pool worker and confirm it registers:

    curl -s "https://api.cursor.com/v0/private-workers" \
  -u "$CURSOR_API_KEY:"
# worker appears with "isInUse": false  (expected while idle)

  2. Create/dispatch an agent to that pool and confirm a run starts on the worker
    (worker logs show the turn executing; the run advances past CREATING).

  3. While the run is actively executing, poll the API again:

    curl -s "https://api.cursor.com/v0/private-workers" \
  -u "$CURSOR_API_KEY:"

curl -s "https://api.cursor.com/v0/private-workers/summary" \
  -u "$CURSOR_API_KEY:"

  4. Observe that the worker still reports isInUse=false, activeBcId is absent
    or null, and the summary reports inUse=0 — even though a run is executing
    on that exact worker.

Expected Behavior

While a worker is executing an agent run:

  • GET /v0/private-workers should report isInUse=true for that worker.
  • activeBcId should be set to the id of the agent currently running on it.
  • GET /v0/private-workers/summary should count that worker in inUse.
  • GET /v0/private-workers/pools should count it in inUseWorkerCount.

The busy/idle state exposed by the API should match the worker’s real execution
state, so utilization and routing can be derived from the API.

Screenshots / Screen Recordings

(Attach a redacted API response if useful — worker list during an active run
showing isInUse=false next to worker logs proving the run is executing.)

Operating System

Linux

Version Information

  • SDK version ^1.0.26
  • API host: https://api.cursor.com
  • Endpoints used: GET /v0/private-workers, GET /v0/private-workers/summary,
    GET /v0/private-workers/pools

For AI issues: which model did you use?

Composer 2.5

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @Artur_Artsabliuk, thanks for bringing this to our attention!

We’re already aware of this issue and have added your report.

In the meantime, a reliable occupied vs. idle signal is the agent and run status you already poll, keyed by the agent ID.

For scale-up decisions, GET /v0/private-workers/pending-requests still reflects queued demand. We recommend not making scale-down decisions based on isInUse until this is resolved.