Long tasks (multi-entity) — disabled

What to do instead

Submit each task as its own POST /api/v1/responses run. For a job that spans several entities ("the bill for each of my accounts"), loop over the entities client-side and create one run per entity — use an idempotency_key per entity so client retries never double-run, and a vault credential (credential_id) for logins. A run whose text looks multi-entity still runs normally as a single run; its envelope carries the informational banana_peel.scale_hint: "multi" flag (nothing is rejected for looking multi-entity on /v1/responses).

curl -s "$BANANA_PEEL_BASE/api/v1/long-tasks" \
  -H "Authorization: Bearer $BANANA_PEEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "input": "Download the latest bill for ALL accounts.", "url": "https://…" }'
# → 403
# { "error": {
#     "code": "feature_disabled",
#     "message": "Multi-entity long-task orchestration is disabled on this
#       deployment. Submit each task as its own run via POST /api/v1/responses …",
#     "remediation": "Submit each task as its own run via POST /api/v1/responses —
#       smart routing treats every task the same. Existing lt_… objects stay
#       readable (GET /api/v1/long-tasks, …/{id}, …/{id}/runs). Nothing was
#       created or billed." } }

History — existing lt_ objects stay readable

Long tasks created before the feature was disabled keep their read surfaces, exactly like their console rows and artifacts:

• GET /api/v1/long-tasks — newest-first list (limit 1–100, default 20).
• GET /api/v1/long-tasks/:id — the full historical ledger: entities[] (per-entity status, attempts, sub-run id, artifact_id when delivered — fetch bytes via GET /api/v1/responses/:run_id/artifacts/:artifact_id within the retention window), counts, the honest gaps[] list, budget.spent_usd, and the audit events[].
• GET /api/v1/long-tasks/:id/runs— the task's child runs, oldest-first, each with role (enumeration | entity_fetch | verification) and entity_id. Sub-run response objects keep banana_peel.parent_id / entity_id / role, and GET /api/v1/runs still excludes historical sub-runs by default (exclude_children=true; reach them via ?parent_id=lt_… or exclude_children=false).
• POST /api/v1/long-tasks/:id/cancel — still accepted; cancelling an already-terminal task is a no-op that returns the object unchanged. (With orchestration disabled, any task that was still moving has been drained to cancelled with its delivered-entity ledger preserved and a cancelled event explaining why.)

# Historical reads keep working for previously created lt_… objects:
curl -s "$BANANA_PEEL_BASE/api/v1/long-tasks?limit=20" \
  -H "Authorization: Bearer $BANANA_PEEL_API_KEY"

curl -s "$BANANA_PEEL_BASE/api/v1/long-tasks/lt_9f2c…" \
  -H "Authorization: Bearer $BANANA_PEEL_API_KEY"
# → { "id": "lt_9f2c…", "object": "long_task", "status": "cancelled",
#     "entities": [ { "entity_id": "ACCT-001", "status": "delivered",
#                     "run_id": "resp_…", "artifact_id": "art_…" }, … ],
#     "counts": { … }, "gaps": [ … ], "events": [ … ] }

curl -s "$BANANA_PEEL_BASE/api/v1/long-tasks/lt_9f2c…/runs" \
  -H "Authorization: Bearer $BANANA_PEEL_API_KEY"

Webhooks

The long_task.* event types (progress, interaction_required, completed, partial, failed) remain valid subscription values so existing webhook configurations keep validating, but they no longer fire — no new long tasks are created and none are in flight. See Webhooks.

Why

Product decision, recorded in the changelog (2026-08-27): multi-entity fan-out added an orchestration layer whose failure modes outweighed its wins — all tasks now run the same single-run path through smart routing. The error code is feature_disabled, and single-run behavior — including uncapped runs and time_budget_ms — is unchanged.