eve 0.50.0 → 0.51.1

package/dist/src/tools/framework/task-cancel.d.ts

@@ -8,13 +8,9 @@ export declare const taskCancel: import("#tools/native-definition.js").NativeToo
             type: "error" | "result";
         } | undefined;
         metadata: {
-            agentId: string;
-            kind: "subagent";
-            mode: "local" | "remote";
-            name: string;
-        } | {
-            data?: Record<string, unknown> | undefined;
+            agentId?: string | undefined;
             kind: string;
+            mode?: "local" | "remote" | undefined;
             name: string;
         };
         status: "cancelled" | "completed" | "failed" | "input_required" | "working";

package/dist/src/tools/framework/task-contract.d.ts

@@ -1,6 +1,8 @@
 import { z } from "#compiled/zod/index.js";
 export declare const TASK_CANCEL_TOOL_NAME = "task_cancel";
 export declare const TASK_UPDATE_TOOL_NAME = "task_update";
+/** Framework task-control tool names lowered by the runtime. */
+export declare const TASK_TOOL_NAMES: ReadonlySet<string>;
 export declare const TASK_CANCEL_INPUT_SCHEMA: z.ZodObject<{
     taskIds: z.ZodArray<z.ZodString>;
 }, z.core.$strict>;
@@ -9,49 +11,40 @@ export declare const TASK_UPDATE_INPUT_SCHEMA: z.ZodObject<{
 }, z.core.$strict>;
 /** Strict model-visible task projection. */
 export declare const TASK_VIEW_JSON_SCHEMA: z.ZodDiscriminatedUnion<[z.ZodObject<{
-    metadata: z.ZodUnion<readonly [z.ZodObject<{
-        agentId: z.ZodString;
-        kind: z.ZodLiteral<"subagent">;
-        mode: z.ZodEnum<{
+    metadata: z.ZodObject<{
+        agentId: z.ZodOptional<z.ZodString>;
+        kind: z.ZodString;
+        mode: z.ZodOptional<z.ZodEnum<{
             local: "local";
             remote: "remote";
-        }>;
+        }>>;
         name: z.ZodString;
-    }, z.core.$strip>, z.ZodObject<{
-        kind: z.ZodString;
-        name: z.ZodString;
-    }, z.core.$strip>]>;
+    }, z.core.$strip>;
     taskId: z.ZodString;
     status: z.ZodLiteral<"working">;
 }, z.core.$strip>, z.ZodObject<{
-    metadata: z.ZodUnion<readonly [z.ZodObject<{
-        agentId: z.ZodString;
-        kind: z.ZodLiteral<"subagent">;
-        mode: z.ZodEnum<{
+    metadata: z.ZodObject<{
+        agentId: z.ZodOptional<z.ZodString>;
+        kind: z.ZodString;
+        mode: z.ZodOptional<z.ZodEnum<{
             local: "local";
             remote: "remote";
-        }>;
-        name: z.ZodString;
-    }, z.core.$strip>, z.ZodObject<{
-        kind: z.ZodString;
+        }>>;
         name: z.ZodString;
-    }, z.core.$strip>]>;
+    }, z.core.$strip>;
     taskId: z.ZodString;
     inputRequests: z.ZodReadonly<z.ZodArray<z.ZodType<import("../../shared/json.ts").JsonValue, unknown, z.core.$ZodTypeInternals<import("../../shared/json.ts").JsonValue, unknown>>>>;
     status: z.ZodLiteral<"input_required">;
 }, z.core.$strip>, z.ZodObject<{
-    metadata: z.ZodUnion<readonly [z.ZodObject<{
-        agentId: z.ZodString;
-        kind: z.ZodLiteral<"subagent">;
-        mode: z.ZodEnum<{
+    metadata: z.ZodObject<{
+        agentId: z.ZodOptional<z.ZodString>;
+        kind: z.ZodString;
+        mode: z.ZodOptional<z.ZodEnum<{
             local: "local";
             remote: "remote";
-        }>;
-        name: z.ZodString;
-    }, z.core.$strip>, z.ZodObject<{
-        kind: z.ZodString;
+        }>>;
         name: z.ZodString;
-    }, z.core.$strip>]>;
+    }, z.core.$strip>;
     taskId: z.ZodString;
     lastOutput: z.ZodObject<{
         data: z.ZodType<import("../../shared/json.ts").JsonValue, unknown, z.core.$ZodTypeInternals<import("../../shared/json.ts").JsonValue, unknown>>;
@@ -59,18 +52,15 @@ export declare const TASK_VIEW_JSON_SCHEMA: z.ZodDiscriminatedUnion<[z.ZodObject
     }, z.core.$strip>;
     status: z.ZodLiteral<"completed">;
 }, z.core.$strip>, z.ZodObject<{
-    metadata: z.ZodUnion<readonly [z.ZodObject<{
-        agentId: z.ZodString;
-        kind: z.ZodLiteral<"subagent">;
-        mode: z.ZodEnum<{
+    metadata: z.ZodObject<{
+        agentId: z.ZodOptional<z.ZodString>;
+        kind: z.ZodString;
+        mode: z.ZodOptional<z.ZodEnum<{
             local: "local";
             remote: "remote";
-        }>;
+        }>>;
         name: z.ZodString;
-    }, z.core.$strip>, z.ZodObject<{
-        kind: z.ZodString;
-        name: z.ZodString;
-    }, z.core.$strip>]>;
+    }, z.core.$strip>;
     taskId: z.ZodString;
     lastOutput: z.ZodObject<{
         data: z.ZodType<import("../../shared/json.ts").JsonValue, unknown, z.core.$ZodTypeInternals<import("../../shared/json.ts").JsonValue, unknown>>;
@@ -78,18 +68,15 @@ export declare const TASK_VIEW_JSON_SCHEMA: z.ZodDiscriminatedUnion<[z.ZodObject
     }, z.core.$strip>;
     status: z.ZodLiteral<"failed">;
 }, z.core.$strip>, z.ZodObject<{
-    metadata: z.ZodUnion<readonly [z.ZodObject<{
-        agentId: z.ZodString;
-        kind: z.ZodLiteral<"subagent">;
-        mode: z.ZodEnum<{
+    metadata: z.ZodObject<{
+        agentId: z.ZodOptional<z.ZodString>;
+        kind: z.ZodString;
+        mode: z.ZodOptional<z.ZodEnum<{
             local: "local";
             remote: "remote";
-        }>;
+        }>>;
         name: z.ZodString;
-    }, z.core.$strip>, z.ZodObject<{
-        kind: z.ZodString;
-        name: z.ZodString;
-    }, z.core.$strip>]>;
+    }, z.core.$strip>;
     taskId: z.ZodString;
     status: z.ZodLiteral<"cancelled">;
 }, z.core.$strip>], "status">;
@@ -103,19 +90,15 @@ export declare const TASK_VIEW_OUTPUT_SCHEMA: z.ZodObject<{
             result: "result";
         }>;
     }, z.core.$strip>>;
-    metadata: z.ZodUnion<readonly [z.ZodObject<{
-        agentId: z.ZodString;
-        kind: z.ZodLiteral<"subagent">;
-        mode: z.ZodEnum<{
+    metadata: z.ZodObject<{
+        agentId: z.ZodOptional<z.ZodString>;
+        kind: z.ZodString;
+        mode: z.ZodOptional<z.ZodEnum<{
             local: "local";
             remote: "remote";
-        }>;
-        name: z.ZodString;
-    }, z.core.$strip>, z.ZodObject<{
-        data: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-        kind: z.ZodString;
+        }>>;
         name: z.ZodString;
-    }, z.core.$strip>]>;
+    }, z.core.$strip>;
     status: z.ZodEnum<{
         cancelled: "cancelled";
         completed: "completed";
@@ -135,19 +118,15 @@ export declare const TASK_VIEWS_OUTPUT_SCHEMA: z.ZodObject<{
                 result: "result";
             }>;
         }, z.core.$strip>>;
-        metadata: z.ZodUnion<readonly [z.ZodObject<{
-            agentId: z.ZodString;
-            kind: z.ZodLiteral<"subagent">;
-            mode: z.ZodEnum<{
+        metadata: z.ZodObject<{
+            agentId: z.ZodOptional<z.ZodString>;
+            kind: z.ZodString;
+            mode: z.ZodOptional<z.ZodEnum<{
                 local: "local";
                 remote: "remote";
-            }>;
-            name: z.ZodString;
-        }, z.core.$strip>, z.ZodObject<{
-            data: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-            kind: z.ZodString;
+            }>>;
             name: z.ZodString;
-        }, z.core.$strip>]>;
+        }, z.core.$strip>;
         status: z.ZodEnum<{
             cancelled: "cancelled";
             completed: "completed";

package/dist/src/tools/framework/task-contract.js

@@ -1 +1 @@
-import{z}from"#compiled/zod/index.js";import{jsonValueSchema}from"#shared/json-schemas.js";const TASK_CANCEL_TOOL_NAME=`task_cancel`,TASK_UPDATE_TOOL_NAME=`task_update`,TASK_IDS_SCHEMA=z.array(z.string().min(1)).min(1).describe(`Task ids from earlier subagent task receipts.`),TASK_CANCEL_INPUT_SCHEMA=z.strictObject({taskIds:TASK_IDS_SCHEMA}),TASK_UPDATE_INPUT_SCHEMA=z.strictObject({message:z.string().min(1).describe(`Brief description of what this task is currently doing.`)}),taskMetadataJsonSchema=z.union([z.object({agentId:z.string(),kind:z.literal(`subagent`),mode:z.enum([`local`,`remote`]),name:z.string()}),z.object({kind:z.string(),name:z.string()})]),taskOutputJsonSchema=z.object({data:jsonValueSchema,type:z.enum([`result`,`error`])}),taskViewJsonBaseShape={metadata:taskMetadataJsonSchema,taskId:z.string()},TASK_VIEW_JSON_SCHEMA=z.discriminatedUnion(`status`,[z.object({...taskViewJsonBaseShape,status:z.literal(`working`)}),z.object({...taskViewJsonBaseShape,inputRequests:z.array(jsonValueSchema).readonly(),status:z.literal(`input_required`)}),z.object({...taskViewJsonBaseShape,lastOutput:taskOutputJsonSchema.extend({type:z.literal(`result`)}),status:z.literal(`completed`)}),z.object({...taskViewJsonBaseShape,lastOutput:taskOutputJsonSchema.extend({type:z.literal(`error`)}),status:z.literal(`failed`)}),z.object({...taskViewJsonBaseShape,status:z.literal(`cancelled`)})]),TASK_VIEW_OUTPUT_SCHEMA=z.object({inputRequests:z.array(z.unknown()).optional(),lastOutput:z.object({data:z.unknown(),type:z.enum([`result`,`error`])}).optional(),metadata:z.union([z.object({agentId:z.string(),kind:z.literal(`subagent`),mode:z.enum([`local`,`remote`]),name:z.string()}),z.object({data:z.record(z.string(),z.unknown()).optional(),kind:z.string(),name:z.string()})]),status:z.enum([`working`,`input_required`,`completed`,`failed`,`cancelled`]),taskId:z.string()}),TASK_VIEWS_OUTPUT_SCHEMA=z.object({tasks:z.array(TASK_VIEW_OUTPUT_SCHEMA)}),SUBAGENT_TASK_RECEIPT_OUTPUT_SCHEMA=z.strictObject({agentId:z.string(),status:z.literal(`working`),taskId:z.string()});export{SUBAGENT_TASK_RECEIPT_OUTPUT_SCHEMA,TASK_CANCEL_INPUT_SCHEMA,TASK_CANCEL_TOOL_NAME,TASK_UPDATE_INPUT_SCHEMA,TASK_UPDATE_TOOL_NAME,TASK_VIEWS_OUTPUT_SCHEMA,TASK_VIEW_JSON_SCHEMA,TASK_VIEW_OUTPUT_SCHEMA};
+import{z}from"#compiled/zod/index.js";import{jsonValueSchema}from"#shared/json-schemas.js";const TASK_CANCEL_TOOL_NAME=`task_cancel`,TASK_UPDATE_TOOL_NAME=`task_update`,TASK_TOOL_NAMES=new Set([TASK_CANCEL_TOOL_NAME,TASK_UPDATE_TOOL_NAME]),TASK_IDS_SCHEMA=z.array(z.string().min(1)).min(1).describe(`Task ids from earlier subagent task receipts.`),TASK_CANCEL_INPUT_SCHEMA=z.strictObject({taskIds:TASK_IDS_SCHEMA}),TASK_UPDATE_INPUT_SCHEMA=z.strictObject({message:z.string().min(1).describe(`Brief description of what this task is currently doing.`)}),taskMetadataJsonSchema=z.object({agentId:z.string().optional(),kind:z.string(),mode:z.enum([`local`,`remote`]).optional(),name:z.string()}),taskOutputJsonSchema=z.object({data:jsonValueSchema,type:z.enum([`result`,`error`])}),taskViewJsonBaseShape={metadata:taskMetadataJsonSchema,taskId:z.string()},TASK_VIEW_JSON_SCHEMA=z.discriminatedUnion(`status`,[z.object({...taskViewJsonBaseShape,status:z.literal(`working`)}),z.object({...taskViewJsonBaseShape,inputRequests:z.array(jsonValueSchema).readonly(),status:z.literal(`input_required`)}),z.object({...taskViewJsonBaseShape,lastOutput:taskOutputJsonSchema.extend({type:z.literal(`result`)}),status:z.literal(`completed`)}),z.object({...taskViewJsonBaseShape,lastOutput:taskOutputJsonSchema.extend({type:z.literal(`error`)}),status:z.literal(`failed`)}),z.object({...taskViewJsonBaseShape,status:z.literal(`cancelled`)})]),TASK_VIEW_OUTPUT_SCHEMA=z.object({inputRequests:z.array(z.unknown()).optional(),lastOutput:z.object({data:z.unknown(),type:z.enum([`result`,`error`])}).optional(),metadata:z.object({agentId:z.string().optional(),kind:z.string(),mode:z.enum([`local`,`remote`]).optional(),name:z.string()}),status:z.enum([`working`,`input_required`,`completed`,`failed`,`cancelled`]),taskId:z.string()}),TASK_VIEWS_OUTPUT_SCHEMA=z.object({tasks:z.array(TASK_VIEW_OUTPUT_SCHEMA)}),SUBAGENT_TASK_RECEIPT_OUTPUT_SCHEMA=z.strictObject({agentId:z.string(),status:z.literal(`working`),taskId:z.string()});export{SUBAGENT_TASK_RECEIPT_OUTPUT_SCHEMA,TASK_CANCEL_INPUT_SCHEMA,TASK_CANCEL_TOOL_NAME,TASK_TOOL_NAMES,TASK_UPDATE_INPUT_SCHEMA,TASK_UPDATE_TOOL_NAME,TASK_VIEWS_OUTPUT_SCHEMA,TASK_VIEW_JSON_SCHEMA,TASK_VIEW_OUTPUT_SCHEMA};

package/dist/src/tools/framework/task-update.d.ts

@@ -1,3 +1,4 @@
+export declare const TASK_UPDATE_SESSION_INSTRUCTION = "Background task updates\nYou are running as a background task. For multi-step work, use `task_update` at meaningful milestones to briefly state what you are currently doing. Keep updates terse and activity-focused; do not include preliminary findings or results. Do not wait for a response, and return your final result normally.";
 export declare const taskUpdate: import("#tools/native-definition.js").NativeToolDefinition<{
     message: string;
 }, unknown>;

package/dist/src/tools/framework/task-update.js

@@ -1 +1 @@
-import{TASK_UPDATE_INPUT_SCHEMA}from"#tools/framework/task-contract.js";import{defineNativeTool}from"#tools/native-definition.js";const taskUpdate=defineNativeTool({description:`Briefly tell the parent agent what this background task is currently doing. Report activity, not preliminary findings or results.`,inputSchema:TASK_UPDATE_INPUT_SCHEMA},{availability:[`delegated-task-child`],handling:{action:`task-update`,kind:`dispatch`}});export{taskUpdate as default,taskUpdate};
+import{TASK_UPDATE_INPUT_SCHEMA}from"#tools/framework/task-contract.js";import{defineNativeTool}from"#tools/native-definition.js";const TASK_UPDATE_SESSION_INSTRUCTION="Background task updates\nYou are running as a background task. For multi-step work, use `task_update` at meaningful milestones to briefly state what you are currently doing. Keep updates terse and activity-focused; do not include preliminary findings or results. Do not wait for a response, and return your final result normally.",taskUpdate=defineNativeTool({description:`Briefly tell the parent agent what this background task is currently doing. Report activity, not preliminary findings or results.`,inputSchema:TASK_UPDATE_INPUT_SCHEMA},{availability:[`delegated-task-child`],handling:{action:`task-update`,kind:`dispatch`}});export{TASK_UPDATE_SESSION_INSTRUCTION,taskUpdate as default,taskUpdate};

package/dist/src/tools/provided/sleep.d.ts

@@ -12,7 +12,7 @@ export type { SleepToolInput, SleepToolOutput };
  * export default sleep();
  * ```
  *
- * Calls pause the durable turn workflow rather than holding an application
- * runtime open with an in-process timer.
+ * Each call runs as a durable workflow, so the wait does not hold an
+ * application runtime open.
  */
 export declare function sleep(): ToolDefinition<SleepToolInput, SleepToolOutput>;

package/dist/src/vue/index.js

@@ -1,3 +1,3 @@
-import { n as defaultMessageReducer, t as useEveAgent } from "../chunks/use-eve-agent-DUMU6dap.js";
+import { n as defaultMessageReducer, t as useEveAgent } from "../chunks/use-eve-agent-D7apPojZ.js";
 
 export { defaultMessageReducer, useEveAgent };

package/dist/src/vue/use-eve-agent.js

@@ -1,3 +1,3 @@
-import { t as useEveAgent } from "../chunks/use-eve-agent-DUMU6dap.js";
+import { t as useEveAgent } from "../chunks/use-eve-agent-D7apPojZ.js";
 
 export { useEveAgent };

package/docs/agent-config.md

@@ -147,9 +147,9 @@ See [Default harness](./concepts/default-harness#compaction) for how the loop ap
 
 ## Runtime limits
 
-Use `limits` for framework-owned runtime caps. Session token limits stop the
+Use `limits` for framework-owned runtime caps. Session usage limits stop the
 current durable session from starting another model call after accumulated
-provider-reported input or output token usage reaches the configured limit:
+provider-reported tokens or model token cost reaches a configured limit:
 
 ```ts title="agent/agent.ts"
 export default defineAgent({
@@ -157,6 +157,7 @@ export default defineAgent({
   limits: {
     maxInputTokensPerSession: 200_000,
     maxOutputTokensPerSession: 20_000,
+    maxTokenCostUsdPerSession: 1.5,
     sessionTimeoutMs: 7 * 24 * 60 * 60 * 1_000,
   },
 });
@@ -169,14 +170,13 @@ then emits `session.completed` and releases the continuation; the next
 qualifying channel message starts fresh. Set it to `false` to disable the
 timeout. Expiration does not delete stored session data.
 
-Input and output budgets are checked independently. The model call that crosses
-either limit is allowed to finish because providers only report exact token
-usage after a call completes. Before the next model call, eve pauses the
+Input tokens, output tokens, and model token cost are checked independently.
+The model call that crosses a limit is allowed to finish because exact usage
+arrives after the call completes. Before the next model call, eve pauses the
 session and sends a deterministic continuation prompt with two options:
-**Approve** grants a fresh budget window of the configured size (both input
-and output windows reset together), and **Stop** cancels the in-flight turn
-through the standard cancellation path (`turn.cancelled` → `session.waiting`)
-— a user decision, not an error. The session stays resumable; because it is
+**Approve** grants a fresh window of each configured size, and **Stop**
+cancels the in-flight turn through the standard cancellation path
+(`turn.cancelled` → `session.waiting`) — a user decision, not an error. The session stays resumable; because it is
 still over budget, the next message re-raises the prompt. Declining a
 delegated child's prompt cancels the root turn, which cascades to the whole
 delegation tree — the delegating parent never receives an error result it
@@ -186,23 +186,28 @@ copy. The reply is processed once the budget is granted.
 
 Sessions that cannot reach a human — task-mode runs such as schedules and
 delegated runs without input proxying — skip the prompt and fail the next model
-call with `SESSION_TOKEN_LIMIT_REACHED`. A delegated task with no inherited
-quota also fails instead of raising a continuation prompt that could only
-grant another zero-token window.
+call with `SESSION_TOKEN_LIMIT_REACHED` for token budgets or
+`SESSION_TOKEN_COST_LIMIT_REACHED` for model token cost. A delegated task with
+no inherited quota also fails instead of raising a continuation prompt that
+could only grant another zero-value window.
 
 When `maxInputTokensPerSession` is omitted, root sessions apply a default
 input budget of `40_000_000` provider-reported input tokens.
-`maxOutputTokensPerSession` is unset unless configured. Setting either limit
-to `false` uncaps that axis — the session never stops on it.
+`maxOutputTokensPerSession` and `maxTokenCostUsdPerSession` are unset by
+default. `maxTokenCostUsdPerSession` is a US-dollar limit on model token cost,
+not tool or infrastructure spend. It uses the cost reported with each model
+step; AI Gateway supplies this value, while model steps without reported cost
+do not add to the limit. Set any usage limit to `false` to uncap that axis.
 
 Delegated subagent sessions have no fixed default. Each child receives a
 share of the delegating parent's remaining quota at dispatch time — the
 remainder in the current budget window split evenly across the batch's local
 subagent calls — and a completed child's usage counts against the parent's
-quota, so a delegation tree can never outspend the budget configured at its
-root. Approving a continuation opens a fresh parent window for later child
-grants without erasing lifetime usage. An authored child limit applies only
-when it is tighter than the parent's grant; an uncapped parent delegates
+quota. Token-cost budgets follow the same rules, including splitting the
+remaining US-dollar budget across a batch and adding completed child cost back
+to the parent. Approving a continuation opens a fresh parent window for later
+child grants without erasing lifetime usage. An authored child limit applies
+only when it is tighter than the parent's grant; an uncapped parent delegates
 uncapped children.
 
 ## Workflow world
@@ -250,7 +255,7 @@ installed package must stay external in hosted output, list it in
 | -------------- | --------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `reasoning`    | `AgentReasoningDefinition`              | provider default | Provider-agnostic reasoning effort forwarded to the agent's turn model calls.                                                                                                                                 |
 | `modelOptions` | `AgentModelOptionsDefinition`           | none             | Provider option overrides forwarded to the model call.                                                                                                                                                        |
-| `limits`       | `AgentLimitsDefinition`                 | field-specific   | Framework-owned runtime limits. Sessions complete after 30 days by default; token-limit defaults and inheritance are described above. Set a limit to `false` to disable it.                                   |
+| `limits`       | `AgentLimitsDefinition`                 | field-specific   | Framework-owned runtime limits. Sessions complete after 30 days by default; usage-limit defaults and inheritance are described above. Set a limit to `false` to disable it.                                   |
 | `experimental` | `{ workflow?: { world?: string } }`     | unset            | Opt-in settings that can change or disappear in any release. Treat them as unstable. `workflow.world` selects the Workflow world package backing session state, queues, hooks, and streams on the root agent. |
 | `outputSchema` | Standard Schema or a JSON Schema object | none             | Structured return type for function-like invocations such as a subagent turn, schedule, or remote job. Ordinary interactive turns ignore it unless the client supplies a per-message schema.                  |
 | `build`        | `{ externalDependencies?: string[] }`   | none             | Hosted-build packaging controls. `externalDependencies` keeps listed packages external while eve compiles authored modules such as tools and channels, and traces those packages into the hosted output.      |

package/docs/channels/eve.mdx

@@ -91,7 +91,7 @@ Stream a session as newline-delimited JSON from `GET /eve/v1/session/:sessionId/
 
 ### Cancel a turn
 
-Post to `/eve/v1/session/:sessionId/cancel` to request cancellation of the active turn. You can include the observed `turnId` to keep a late request from cancelling a newer turn. Cancellation is asynchronous; confirm it on the stream as `turn.cancelled` followed by `session.waiting`.
+Post to `/eve/v1/session/:sessionId/cancel` to request cancellation of the active turn. You can include the observed `turnId` to keep a late request from cancelling a newer turn. Include `tasks: true` to also cancel every background task owned by the session, including while the session is parked. Cancellation is asynchronous; confirm the turn boundary on the stream as `turn.cancelled` followed by `session.waiting`, and inspect task state in a later turn to confirm task cancellation.
 
 See [Cancel the in-flight turn](../concepts/sessions-runs-and-streaming#cancel-the-in-flight-turn) for response statuses, HTTP status codes, subagent cancellation, and race behavior.
 

package/docs/concepts/built-in-tools.md

@@ -1,6 +1,6 @@
 ---
 title: "Built-in Tools"
-description: "The default and opt-in tools eve provides, including Workflow, glob, grep, and sleep."
+description: "The default and opt-in tools eve provides, including glob, grep, and sleep."
 ---
 
 eve provides a default tool set for every agent and additional tools you can add with one file. Each default occupies the same `agent/tools/<name>.ts` slot you would author yourself, so an authored definition replaces it and `disableTool()` removes it. Use this page to review what the model can call, opt into more capabilities, or override and disable defaults. For custom tools, see [Tools](../tools).
@@ -28,7 +28,7 @@ The model-facing file tools accept absolute paths and paths beginning with `$HOM
 
 Notes:
 
-- **`agent`** is available only in the root session. Its child uses the root's instructions, tools, connections, and sandbox, but starts with fresh conversation history and fresh [state](./state). The child receives neither `agent` nor `Workflow`; declared subagents do not receive the built-in `agent` either. See [Subagents](../subagents).
+- **`agent`** is available only in the root session and always runs in the background. Its call returns a task receipt immediately, and task notifications deliver updates or the final result. The child uses the root's instructions, tools, connections, and sandbox, but starts with fresh conversation history and fresh [state](./state). The child receives neither `agent` nor `Workflow`; declared subagents do not receive the built-in `agent` either. See [Subagents](../subagents).
 - **`load_skill`** only pulls instructions into context. It adds no new execution surface, because behavior still comes from the tools the agent already has.
 - **`connection_search`** surfaces a connection's tools by their qualified name (e.g. `linear__list_issues`), which the model can then call directly. The model sees it only when the agent has connections.
 - **`web_search`** has no local executor; the provider runs it. AI Gateway models use Exa by default. To use Parallel instead, export `webSearch({ provider: "parallel" })` from `agent/tools/web_search.ts`. Direct provider models continue to use their native search implementation. To supply your own implementation, override it with `defineTool()`.
@@ -40,12 +40,11 @@ Review these default tools before production use. Disable, wrap, restrict, or re
 
 Some framework-provided tools stay out of the default set. Add the corresponding file when your agent needs one:
 
-| Tool       | Definition to export                                | Purpose                                            |
-| ---------- | --------------------------------------------------- | -------------------------------------------------- |
-| `glob`     | `glob` from `eve/tools/glob`                        | Find sandbox files by glob pattern.                |
-| `grep`     | `grep` from `eve/tools/grep`                        | Search sandbox file contents by regex.             |
-| `Workflow` | `experimental_workflow()` from `eve/tools/workflow` | Orchestrate root-agent copies from generated code. |
-| `sleep`    | `sleep()` from `eve/tools/sleep`                    | Pause and durably resume the current turn.         |
+| Tool    | Definition to export             | Purpose                                    |
+| ------- | -------------------------------- | ------------------------------------------ |
+| `glob`  | `glob` from `eve/tools/glob`     | Find sandbox files by glob pattern.        |
+| `grep`  | `grep` from `eve/tools/grep`     | Search sandbox file contents by regex.     |
+| `sleep` | `sleep()` from `eve/tools/sleep` | Pause and durably resume the current turn. |
 
 For example, add file discovery and content search with two files:
 
@@ -59,7 +58,7 @@ export { grep as default } from "eve/tools/grep";
 
 The filename supplies the model-facing tool name. The tools run against the agent's sandbox and use the same schemas, results, and error behavior as eve's framework implementations. Wrap either definition with `defineTool({ ...glob, description: "..." })` or `defineTool({ ...grep, description: "..." })` when you need to change its description or approval policy.
 
-The sections below cover `Workflow` and `sleep` in more detail.
+The section below covers `sleep` in more detail.
 
 ## Override a default
 
@@ -125,86 +124,6 @@ Three moves shape the harness. The right one depends on whether the model should
 - **Disable** when the model should not have the capability at all. A `disableTool()` sentinel removes the built-in, and the model never sees it. Reach for this to lock down `bash` or `web_fetch` in an agent that should not run shell commands or fetch arbitrary URLs.
 - **Author a new tool** when you want a capability the harness does not ship. Give it a fresh slug under `agent/tools/` and it joins the built-ins instead of replacing one. See [Tools](../tools) for the authoring model.
 
-## Workflow tool
-
-The opt-in experimental `Workflow` tool lets the model write JavaScript that coordinates the agent's own subagents as a single durable step. The program can run them in sequence, feed one result into the next, fan out over a list, and combine the results. You enable the capability and the model decides and runs the orchestration.
-
-A single turn can already call several subagents, and parallel tool calls dispatch concurrently. What a workflow adds is _programmatic_ coordination. The program decides how many subagents to run based on an earlier result, which output feeds which call, and how to combine everything. That is logic the model cannot express as a few one-off calls.
-
-`Workflow` is a model-facing tool, not an API for authored tools, hooks, or application code. Authored code cannot submit a Workflow program or use `Workflow` to start an arbitrary user-authored Vercel Workflow. Use the [client SDK](../guides/client/overview) when application code needs to start or continue an eve session; use ordinary application APIs for other deterministic orchestration.
-
-### Enable Workflow
-
-Export the experimental Workflow definition from `agent/tools/workflow.ts`. The helper name carries the "experimental" warning, but the tool the model actually sees is named `Workflow`.
-
-```ts title="agent/tools/workflow.ts"
-import { experimental_workflow } from "eve/tools/workflow";
-
-export default experimental_workflow();
-```
-
-Without that file, the `Workflow` tool stays off. It earns its keep only when the agent has subagents (or the built-in `agent`) worth coordinating:
-
-```ts title="agent/subagents/analyst/agent.ts"
-import { defineAgent } from "eve";
-
-export default defineAgent({
-  description: "Analyzes one metric: queries, computes, writes a short finding.",
-  model: "anthropic/claude-opus-4.8",
-});
-```
-
-When asked for a weekly business review, the model picks the metrics, runs one `analyst` per metric in parallel, and combines the findings. The program below is the kind of JavaScript the model authors. It fans `analyst` out over a runtime-decided list of metrics and merges the results:
-
-```js
-const metrics = ["revenue", "signups", "churn"];
-const findings = await Promise.all(
-  metrics.map((metric) => tools.analyst({ message: `Summarize last week's ${metric}.` })),
-);
-return findings.join("\n\n");
-```
-
-Each `tools.analyst(...)` call dispatches a child subagent, so the parent stream records one `subagent.called` per metric and one `subagent.completed` as each finishes:
-
-```json
-{ "type": "subagent.called", "data": { "name": "analyst", "toolName": "analyst", "callId": "call_1", "childSessionId": "ses_a1", "sequence": 0 } }
-{ "type": "subagent.called", "data": { "name": "analyst", "toolName": "analyst", "callId": "call_2", "childSessionId": "ses_a2", "sequence": 1 } }
-{ "type": "subagent.called", "data": { "name": "analyst", "toolName": "analyst", "callId": "call_3", "childSessionId": "ses_a3", "sequence": 2 } }
-{ "type": "subagent.completed", "data": { "subagentName": "analyst", "callId": "call_1", "output": "..." } }
-{ "type": "subagent.completed", "data": { "subagentName": "analyst", "callId": "call_2", "output": "..." } }
-{ "type": "subagent.completed", "data": { "subagentName": "analyst", "callId": "call_3", "output": "..." } }
-```
-
-### What a workflow can orchestrate
-
-A workflow reaches only this agent's own agents: the built-in `agent` (a copy of itself), declared [subagents](../subagents), and [remote agents](../guides/remote-agents). That is the whole list. No files, network, shell, skills, or connections. A workflow is a coordination layer over subagents, not a place to do other work. Each call can still request structured output via `outputSchema`, exactly like a direct subagent delegation.
-
-### Caps on workflow-spawned subagents
-
-Workflow orchestration is capped in two independent ways.
-
-**Per-program call budget.** One Workflow program may dispatch at most `maxSubagents` subagent calls in total, counted across the whole program — sequential and parallel calls alike. Configure it on `experimental_workflow`; the default is 100. Calls beyond the budget do not start a child session; they resolve inside the program with a `WORKFLOW_SUBAGENT_LIMIT_REACHED` error result, and the budget is stated in the tool's description so the model sizes its fan-out to fit.
-
-```ts title="agent/tools/workflow.ts"
-import { experimental_workflow } from "eve/tools/workflow";
-
-export default experimental_workflow({ maxSubagents: 4 });
-```
-
-**Root-only orchestration.** Only the root session receives `Workflow`. Children started by a workflow receive neither `Workflow` nor the built-in `agent`, so Workflow programs cannot recurse. A declared child can still call subagents defined in its own directory (see [Subagents](../subagents)).
-
-### Where the JavaScript runs
-
-The orchestration code never touches the agent's process. The runtime hands the program text to a small isolated JavaScript engine (a QuickJS sandbox) and runs it there. Nothing from the host realm crosses in, so there is no `process`, no `globalThis` from the agent, and no `import`/`require`. The program can reach exactly two things, the agent functions bridged in as `tools.<name>` and the ordinary language built-ins.
-
-That is an allowlist, not a denylist. The sandbox cannot read files, open a socket, or see an environment variable because those are not present, not because each one is blocked in turn. When the program calls an agent function, that call bridges back out to the runtime, which dispatches it exactly like a direct delegation. The orchestration glue stays inside the sandbox.
-
-### Durability, approvals, and observability
-
-- **Durable.** The whole orchestration counts as one step. Subagents dispatched together run concurrently, and if a run parks (suspends durably without holding compute; see [Execution model and durability](./execution-model-and-durability)) on a long-running or human-gated child, it resumes where it left off after a restart.
-- **Approval-safe.** A subagent that needs human approval (HITL, human-in-the-loop) mid-run surfaces its request to the user, and the workflow picks back up once that is answered, same as direct delegation.
-- **Observable.** Every orchestrated subagent emits the usual `subagent.called` / `subagent.completed` events on the parent stream and gets its own child session and stream. The telemetry matches direct delegation, so existing dashboards and cost attribution keep working.
-
 ## The opt-in `sleep` tool
 
 The framework also ships a durable `sleep` tool, but does not add it to agents by default. Enable it with `agent/tools/sleep.ts`:
@@ -215,11 +134,11 @@ import { sleep } from "eve/tools/sleep";
 export default sleep();
 ```
 
-The model calls it with `{ seconds }` when it is useful to wait before checking progress or status again. The pause sleeps the durable turn workflow, so it does not hold an application runtime open, and the same turn continues automatically when the duration elapses. If one model response makes concurrent `sleep` calls, eve waits for the longest requested duration.
+The model calls it with `{ seconds }` when it is useful to wait before checking progress or status again. Each call runs as a durable tool workflow, so it does not hold an application runtime open, and the same turn continues automatically when the duration elapses. Concurrent `sleep` calls run in parallel, so the turn continues after the longest requested duration.
 
 ## What to read next
 
 - [Tools](../tools): define your own tools, gate them on approval, and shape their output with `toModelOutput`
 - [Dynamic capabilities](../guides/dynamic-capabilities): generate the tool set per session with `defineDynamic`
 - [Sandbox](../sandbox): configure the sandbox used by shell and file tools
-- [Subagents](../subagents): declare the agents that `agent` and `Workflow` can call
+- [Subagents](../subagents): declare specialists that the model can call as background tasks

package/docs/concepts/context-control.md

@@ -14,7 +14,7 @@ Control context by putting information in the narrowest surface that needs it. K
 | A procedure needed only for some tasks               | A [skill](../skills)                                   | Its description until the model loads the full skill                             |
 | A typed action or external operation                 | A [tool](../tools) or [connection](../connections)     | The callable schema and the result of each call                                  |
 | Files or command execution                           | The [sandbox workspace](../sandbox)                    | A workspace hint, then files and command output the model requests through tools |
-| A specialist with a separate prompt and capabilities | A [subagent](../subagents)                             | Only the subagent's final result in the parent context                           |
+| A specialist with a separate prompt and capabilities | A [subagent](../subagents)                             | A receipt followed by background task notifications                              |
 | Instructions or capabilities that vary by caller     | A [dynamic capability](../guides/dynamic-capabilities) | The values resolved for the active session                                       |
 | Scoped context retrieved from cross-session storage  | [Memory](../memory)                                    | Attributed user-role messages recalled before the current delivery               |
 
@@ -46,7 +46,7 @@ See [Sandbox](../sandbox) for workspace seeding, runtime access, backends, and l
 
 ## Delegate to a specialist with a subagent
 
-Use a subagent when work needs its own instructions, tools, skills, state, or sandbox. The child runs in a separate context instead of adding its working history to the parent. The parent receives the result of the delegation.
+Use a subagent when work needs its own instructions, tools, skills, state, or sandbox. The child runs in a separate context instead of adding its working history to the parent. The call returns a task receipt, and later task notifications deliver its outcome.
 
 See [Subagents](../subagents) for the distinction between root-agent copies and declared specialists, including their isolation boundaries.
 

package/docs/concepts/execution-model-and-durability.mdx

@@ -64,7 +64,7 @@ You don't write workflow code directly. Workflow primitives (`start()`, `resumeH
 
 ## Parked work
 
-Some work has to wait, including a human approving a [tool](../tools), an interactive OAuth sign-in for a [connection](../connections), or a long-running [subagent](../subagents). At those points the turn parks durably. The workflow suspends and holds no compute until the input it's waiting on arrives (a click, a callback, a child completing), even if that's much later. When it does, the conversation picks up exactly where it left off.
+Some work has to wait, including a human approving a [tool](../tools) or an interactive OAuth sign-in for a [connection](../connections). At those points the turn parks durably. The workflow suspends and holds no compute until the input it's waiting on arrives, even if that's much later. When it does, the conversation picks up exactly where it left off. Background tools and subagents return a task receipt instead, so the turn continues and later task notifications deliver progress or the outcome.
 
 ## Message delivery and steering
 

package/docs/concepts/sessions-runs-and-streaming.md

@@ -58,7 +58,7 @@ The stream is newline-delimited JSON (NDJSON), one event per line:
 | `input.requested`         | The run paused for human input ([HITL](/docs/human-in-the-loop) approval or `ask_question`); carries `requests`. |
 | `input.resolved`          | The server accepted terminal human-input outcomes; carries `resolutions` with responses when provided.           |
 | `subagent.called`         | A subagent was delegated; carries `childSessionId` to attach to.                                                 |
-| `subagent.completed`      | A delegated subagent finished.                                                                                   |
+| `subagent.completed`      | A background subagent was admitted and returned its task receipt.                                                |
 | `reasoning.appended`      | A reasoning text delta.                                                                                          |
 | `reasoning.completed`     | The finalized reasoning block.                                                                                   |
 | `message.appended`        | An assistant text delta.                                                                                         |
@@ -95,7 +95,7 @@ Note: consider the privacy, confidentiality, and user-experience implications fo
 
 `message.completed` can fire more than once in a turn: the agent often emits interim assistant text before a tool call. To tell tool-call narration from a terminal reply, check `message.completed.data.finishReason`. `step.completed.data.finishReason` mirrors the step outcome, and usage lives on `step.completed`.
 
-A delegated subagent publishes progress on its own child-session stream. The parent only emits `subagent.called` with a `childSessionId`, which a client uses to attach.
+A delegated subagent publishes progress on its own child-session stream. The parent emits `subagent.called` with a `childSessionId`, which a client uses to attach. `subagent.completed` carries a working task receipt after admission; later updates and outcomes arrive as task-triggered `message.received` notifications.
 
 `step.failed` and `turn.failed` carry `{ code, message, details? }` for the failed fragment or turn, and `session.failed` is the terminal session-level variant. `turn.cancelled` is not a failure: the cancelled turn ends without any failure event, `session.waiting` follows, and the session accepts the next message normally. Whatever the turn streamed before cancellation stays on the stream. Durable history keeps the accepted user input and previously settled work, but discards incomplete assistant output and unfinished tool state. When a turn requested an output schema, the finalized payload lands on `result.completed` as `data.result` before the turn boundary. `authorization.required` carries the sign-in challenge (`data.authorization` may include `url`, `userCode`, `expiresAt`, `instructions`), and `authorization.completed` carries `data.outcome` (`"authorized" | "declined" | "failed" | "timed-out"`).
 
@@ -191,7 +191,15 @@ curl -X POST http://127.0.0.1:2000/eve/v1/session/<sessionId>/cancel
 # {"ok":true,"sessionId":"<sessionId>","status":"accepted"}
 ```
 
-`"accepted"` means the live session durably queued the request. Confirm an actual cancellation on the stream as `turn.cancelled` followed by `session.waiting`; the session then accepts the next message normally. If the turn is waiting on active local or remote subagents, eve also requests cancellation of every adopted child, recursively, before settling the parent. Each child reports its own cancellation boundary on its child-session stream; the parent does not emit `subagent.completed` for cancelled work. A live but already-parked session also returns `"accepted"` and consumes the command as a no-op. `"no_active_turn"` means the session or channel address is unknown or terminal. Both statuses are success, so clients can fire and forget. See the [eve channel](../channels/eve) for the full route contract.
+By default, background tasks that were already admitted survive initiating-turn cancellation. Pass `tasks: true` to cancel every background task owned by the session as well. This works while the session is parked, so you can stop background work without resetting the session:
+
+```bash
+curl -X POST http://127.0.0.1:2000/eve/v1/session/<sessionId>/cancel \
+  -H 'content-type: application/json' \
+  -d '{"tasks":true}'
+```
+
+`"accepted"` means the live session durably queued the request; cancellation completes asynchronously. Confirm turn cancellation on the stream as `turn.cancelled` followed by `session.waiting`. Inspect task state in a later turn to confirm task cancellation. The session then accepts the next message normally. Background work that has not yet been admitted is rejected with the cancelled step. Each cancelled child reports its own boundary on its child-session stream. A live but already-parked session returns `"accepted"`; plain cancellation is a no-op there, while `tasks: true` still cancels indexed tasks. `"no_active_turn"` means the session or channel address is unknown or terminal. Both statuses are success, so clients can fire and forget. See the [eve channel](../channels/eve) for the full route contract.
 
 The HTTP route returns `202` for `"accepted"` and `200` for
 `"no_active_turn"`. Only the accepted result includes `sessionId`.

package/docs/guides/client/streaming.mdx

@@ -237,7 +237,7 @@ stream index after the captured prefix.
 
 ## Abort a request
 
-Pass an `AbortSignal` to cancel the POST or stream. Aborting is local transport cancellation: turns are resumable across disconnects, so detaching never stops the server-side turn — it keeps running and remains attachable by index. To stop the turn itself, POST the session's [cancel route](../../channels/eve#routes) and watch the stream settle with `turn.cancelled` followed by `session.waiting`.
+Pass an `AbortSignal` to cancel the POST or stream. Aborting is local transport cancellation: turns are resumable across disconnects, so detaching never stops server-side work. Use `session.cancel()` to stop the active turn, or `session.cancel({ tasks: true })` to also stop background tasks owned by the session. Cancellation is asynchronous; watch the stream for `turn.cancelled` followed by `session.waiting`, and inspect task state in a later turn to confirm task cancellation.
 
 Arm the timeout before awaiting `send()` so it covers the POST as well as the stream:
 

package/docs/guides/deployment/vercel.mdx

@@ -51,6 +51,24 @@ See [Sandbox](../../sandbox) for resource limits, network policy, and lifecycle
 
 ## Deploy the agent
 
+A project containing only several independently addressed root agents can use eve's hostless workspace layout:
+
+```text
+my-project/
+├── package.json
+└── agents/
+    ├── support/
+    │   └── agent/
+    └── research/
+        └── agent/
+```
+
+In an eve workspace, eve discovers direct `agents/<name>/` children that contain nested or flat agent files and do not have their own `package.json`. Their directory names become their public identities, exposed at `/<name>/eve/v1/*`. A child with its own `package.json` is a separate package rather than a member of the parent eve workspace. Run an agent-specific command from a member directory or pass `--agent <name>` at the workspace root; interactive commands open a picker when the name is omitted. Run project-level build, link, and deploy commands from the workspace root. Workspace members share the root package, dependencies, and build scripts.
+
+Create this layout with `eve init my-project --agents support,research`, or add one agent to an existing workspace with `eve init billing`.
+
+With no authored `vercel.json#services`, `eve build` derives the complete Vercel Services graph on every build. If `vercel.json` declares `services`, that authored graph is authoritative instead; use `vercel build` to build and validate the complete project. This supports heterogeneous projects with frontends, private APIs, bindings, and other non-eve services without generated configuration files.
+
 Deploy the linked project to production:
 
 ```bash
@@ -77,8 +95,8 @@ Vercel uses the generated output to configure these services:
 Check the health route and connect the development TUI:
 
 ```bash
-curl https://your_agent.vercel.app/eve/v1/health
-eve dev https://your_agent.vercel.app
+curl https://your_agent.vercel.app/support/eve/v1/health
+eve dev https://your_agent.vercel.app/support
 ```
 
 Set `VERCEL_AUTOMATION_BYPASS_SECRET` locally before connecting if the deployment uses Deployment Protection.