eve 0.81.1 → 0.82.0

package/docs/reference/cli.md

@@ -224,7 +224,7 @@ Use a profile file to establish a repeatable baseline before changing the build
 eve build --profile .eve/build-profiles/baseline.json
 ```
 
-The report is attempted only after a successful build. It records total elapsed time, completed phase timings, and final regular-file totals for file count, raw bytes, and the sum of each file compressed with gzip. For Vercel output it also includes a subtotal for every real `.func` directory, so app and flow bundles can be compared separately. The profile path resolves from the app root and should be outside the published output directory; profile collection does not add a file to the deployment. If collection or writing fails, eve emits a warning but keeps the completed build successful.
+The report is attempted only after a successful build. It records total elapsed time, completed phase timings, and final regular-file totals for file count, raw bytes, and the sum of each file compressed with gzip. For Vercel output it also includes a subtotal for every real `.func` directory, so app and flow bundles can be compared separately. For self-hosted output it includes `deploymentId`, the content-derived build identity eve passes to the Workflow World as `WORKFLOW_DEPLOYMENT_ID` when that variable isn't already set. The profile path resolves from the app root and should be outside the published output directory; profile collection does not add a file to the deployment. If collection or writing fails, eve emits a warning but keeps the completed build successful.
 
 Production builds do not write through the stable compiler, host, Nitro, or Workflow files owned by `eve dev`, so builds can run while a local dev server is active. A failed build leaves the last successful `.output/` and agent summary untouched. Concurrent completed builds serialize only the final publication window.
 
@@ -241,15 +241,20 @@ Useful stable artifacts written by inspection and development flows under `.eve/
 ## `eve start`
 
 ```bash
-eve start [--host <host>] [--port <port>]
+eve start [--host <host>] [--port <port>] [--no-schedules]
 ```
 
-| Flag            | Type   | Default            | Description            |
-| --------------- | ------ | ------------------ | ---------------------- |
-| `--host <host>` | string | all interfaces     | Host interface to bind |
-| `--port <port>` | number | `$PORT`, then 3000 | Port to listen on      |
+| Flag             | Type   | Default            | Description                                   |
+| ---------------- | ------ | ------------------ | --------------------------------------------- |
+| `--host <host>`  | string | all interfaces     | Host interface to bind                        |
+| `--port <port>`  | number | `$PORT`, then 3000 | Port to listen on                             |
+| `--no-schedules` | flag   | schedules on       | Start without running authored cron schedules |
 
-Serves the previously built output. Prints the listening URL.
+Serves the previously built output. Prints the listening URL, and a `schedules disabled` line when `--no-schedules` or `EVE_SCHEDULES_DISABLED` turns schedules off. HTTP requests and workflow jobs continue to run.
+
+Set `EVE_SCHEDULES_DISABLED=1` or `true` (case-insensitive) to disable authored cron schedules at runtime, including when you run `node .output/server/index.mjs` directly. Unset, empty, and other values leave schedules enabled. `--no-schedules` sets the variable to `1` only for the spawned server; omitting the flag preserves any value you already set. The same build can run with schedules enabled or disabled.
+
+Use this setting when [scaling self-hosted replicas](../guides/deployment/self-hosting#run-schedules). It also disables authored cron dispatch on Vercel if set there, but does not affect explicit schedule dispatch in `eve dev`.
 
 For self-hosted deployments, copy the app source, `.output/`, and installed dependencies together. The deployment directory can differ from the build directory. Preserve the relative layout of any workspace packages used by the app; startup resolves sandbox prewarm modules from the deployed source.
 
@@ -449,6 +454,8 @@ eve eval [evalId...] [--url <url>] [options]
 
 Runs all discovered evals when no eval ids are given; ids match exactly or by directory prefix (`eve eval weather` runs everything under `evals/weather/`). Exits `0` when every eval passed its checks, `1` when any eval failed (a failed check, an execution error, or a `--strict` threshold miss), `2` on configuration errors.
 
+Without `--url`, `eve eval` starts its own local server on a free port with state under `.eve/eval-servers/<run id>/`, removed when the run ends. It runs beside an `eve dev` session for the same agent without attaching to it or changing it.
+
 | Flag                     | Type   | Default | Description                                                   |
 | ------------------------ | ------ | ------- | ------------------------------------------------------------- |
 | `--url <url>`            | string | none    | Remote agent URL (skip local host startup)                    |

package/docs/schedules.mdx

@@ -7,6 +7,8 @@ A schedule starts the agent on its own clock instead of waiting for an inbound m
 
 The name comes from the path under `schedules/` (`agent/schedules/billing/sweep.ts` → `"billing/sweep"`), and nested directories are fine. An extension mount prefixes that name (`extension/schedules/sweep.ts` mounted as `crm` → `"crm__sweep"`) without changing its cron expression.
 
+For creator-owned schedules created and managed at runtime, see [Experimental dynamic schedules](./experimental/dynamic-schedules). `defineSchedule` remains the fixed, code-authored cron API.
+
 ## `defineSchedule`
 
 Every schedule provides a `cron` and exactly one of `markdown` or `run`:

package/docs/subagents/index.mdx

@@ -34,6 +34,8 @@ The copy uses the root's instructions, connections, auth, and sandbox. It receiv
 
 The parent transfers data to the child through the `message` input it gives the subagent. Do not include sensitive data in a subagent request unless that child and its inherited tools, connections, sandbox, and telemetry path are appropriate for that data.
 
+An authored workflow can open the same root-copy target through `ctx.agent("agent")`. To keep the copied configuration but use another model for that child session, pass a [model override to `ctx.agent`](./tools/workflows#delegate-work-ctxagent). The model-facing built-in tool does not accept a model choice.
+
 To prevent the root session from delegating to a fresh copy of itself, set `tool: false` on the root agent:
 
 ```ts title="agent/agent.ts"

package/docs/tools/overview.mdx

@@ -174,7 +174,8 @@ export default defineTool({
 });
 ```
 
-eve publishes every earlier yield as an `action.partial` stream event. The
+eve publishes earlier yields as `action.partial` stream events. When the durable
+writer is busy, eve may keep only the newest adjacent snapshot for a call. The
 snapshot is visible to channels, hooks, and clients but never enters model
 history or `toModelOutput`; only the final yield does. Treat snapshots as
 last-write-wins by tool call id, not append-only progress. The durable runtime

package/docs/tools/tasks-upgrade.md

@@ -158,15 +158,18 @@ reports each wait with the new `turn.waiting` event, which carries the open turn
   subagent's question, emitted `turn.completed` and `session.waiting` in the middle of the turn.
   It now emits `input.requested` or `authorization.required`, then `turn.waiting`, and the turn
   resumes under the same `turnId` after the answer. The session you answer on emits
-  `input.resolved` for every question it routes an answer to. A tool approval the turn itself
-  requests still ends the turn with `turn.completed` and `session.waiting`.
+  `input.resolved` for every question it routes an answer to. A sign-in or tool approval the
+  turn itself requests holds the turn the same way, with `turn.waiting` on `"input"`.
 - **`turn.completed` comes only when the turn really ends,** and `session.waiting` always means
   the turn has ended.
 
 The TypeScript client's `send(...).result()` reads past `turn.waiting` and returns the final reply
-of a held turn, not the text written before the wait. It stops at `turn.waiting` only while a
-question is pending, and returns `status: "waiting"` with that question; `respond()` then reads the
-same turn to its end. A custom client that ends a response at `turn.completed` or
+of a held turn, not the text written before the wait. At `turn.waiting`, an unanswered input
+request (a question, approval, or `session-limit` prompt) makes `result()` return
+`status: "waiting"`; use `respond()` to answer it and continue reading the same turn.
+A sign-in keeps the response attached while its authorization callback is pending. Render the
+sign-in prompt from the live `authorization.required` event rather than waiting for `result()`.
+A custom client that ends a response at `turn.completed` or
 `session.waiting` mid-turn, or that shows the first completed message as the reply, should follow
 the same rule. See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
 
@@ -197,5 +200,7 @@ Two things differ from a remote agent on the caller's own release:
 
 Each protocol-1 create logs `serving a remote agent protocol 1 caller` with the caller's origin.
 
-Upgrade a caller after every remote agent it calls. A caller on this release fails a call at start,
-with an error that names both versions, when the remote agent's deployment speaks protocol 1.
+Upgrade a caller after every remote agent it calls. A caller on this release accepts a protocol-1
+remote agent's results and failures, but that remote agent's approvals and sign-in requests don't
+reach the caller. Any other protocol mismatch fails the call at start, with an error that names
+both versions.

package/docs/tools/tasks.md

@@ -232,9 +232,12 @@ continues once the person answers or signs in.
 
 In every session, `turn.completed` comes only when the turn really ends. The TypeScript client's
 `send(...).result()` and the MCP channel's `agent_get` read past `turn.waiting` and report the
-final reply rather than the text written before the wait. `result()` stops at `turn.waiting` only
-while a question is pending or the turn waits on a sign-in or approval, and returns
-`status: "waiting"`; `respond()` then reads the same turn to its end. See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
+final reply rather than the text written before the wait. At `turn.waiting`, an unanswered input
+request (a question, approval, or `session-limit` prompt) makes `result()` return
+`status: "waiting"`; use `respond()` to answer it and continue reading the same turn.
+A sign-in keeps the response attached while its authorization callback is pending. Render the
+sign-in prompt from the live `authorization.required` event rather than waiting for `result()`.
+See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
 Channels such as [Slack](/docs/channels/slack) post a root session's text before the wait as an
 ordinary reply, then post the reply after the results as another message. Slack also shows each
 turn's tasks in a live [task card](/docs/channels/slack#task-card).
@@ -305,9 +308,10 @@ task's start and end instead. See
   and enforce per-person access inside the tool.
 - **Working tasks.** A session runs at most 32 working tasks at once. An idle resumable task doesn't
   count, and a call that makes it work again does.
-- **No time limits.** Tasks have no timeout of their own. The session lifetime,
-  `limits.sessionTimeoutMs` (30 days by default), bounds all work in a session. A body that needs a
-  deadline races `sleep` against its work.
+- **No time limits.** Tasks have no timeout of their own, and the session timeout does not bound
+  them. A turn held open while its tasks work keeps the session open, and
+  `limits.sessionTimeoutMs` (30 idle days by default) counts from when that turn settles. A body
+  that needs a deadline races `sleep` against its work.
 
 ## Upgrade from background tasks
 

package/docs/tools/workflows.mdx

@@ -502,9 +502,9 @@ and can only show the model's input. Both compose: `approval` before the run, `c
 
 ## Delegate work: `ctx.agent`
 
-`ctx.agent(name)` returns a session with an agent, shaped like the TypeScript client's session. The
-session opens on its first `send`, and each `response.result()` resolves when that message's turn
-ends:
+`ctx.agent(name, options?)` returns a session with an agent, shaped like the TypeScript client's
+session. The session opens on its first `send`, and each `response.result()` resolves when that
+message's turn ends:
 
 ```ts
 import { z } from "zod";
@@ -517,6 +517,37 @@ const response = await reviewer.send("Review the deployment plan for security ri
 const { data, message, status } = await response.result();
 ```
 
+Set `model` when the workflow should run a local child with a different AI Gateway model. The
+selection belongs to the returned session, so every message sent through that handle uses it:
+
+```ts
+const reviewer = ctx.agent("agent", {
+  model: "anthropic/claude-opus-5.5",
+});
+
+const response = await reviewer.send("Review the migration plan.", {
+  signal: ctx.abortSignal,
+});
+```
+
+The override changes only the model. The child keeps the target agent's instructions, tools, skills,
+connections, sandbox behavior, limits, reasoning, and explicit compaction model. Pass a selection
+object to override model-specific settings too:
+
+```ts
+const reviewer = ctx.agent("agent", {
+  model: {
+    model: "anthropic/claude-opus-5.5",
+    modelContextWindowTokens: 200_000,
+    reasoning: "high",
+  },
+});
+```
+
+The selection must contain an AI Gateway model id. A live AI SDK `LanguageModel` cannot cross the
+durable workflow boundary. A remote agent rejects the option because its deployment owns its model
+configuration.
+
 The name is an available agent target. On the root agent, `"agent"` starts a copy of the root agent.
 A declared subagent uses its path-derived name and remains callable when hidden with `tool: false`
 or `disableTool()`. Delegated root copies and declared subagent contexts do not expose the built-in
@@ -544,8 +575,8 @@ client's `MessageResult` fields, plus `error` when the turn failed:
 | `status`  | `"waiting"` when the session waits for its next message, `"completed"` when the session ended with the turn, or `"failed"` when the turn failed. A cancelled turn is `"waiting"` with neither `data` nor `message`. |
 | `error`   | `{ message }` with the reason the turn failed, present only when `status` is `"failed"`.                                                                                                                            |
 
-Every `ctx.agent(name)` call returns a new session that only the workflow run can address. The model
-does not see it; it sees what the tool returns. A local child runs as the caller's principal with the
+Every `ctx.agent(name, options?)` call returns a new session that only the workflow run can address.
+The model does not see it; it sees what the tool returns. A local child runs as the caller's principal with the
 caller's capabilities. A remote child does not inherit the caller's session principal by default;
 the receiving deployment determines its identity from the outbound request. To forward the caller's
 identity, set `forwardPrincipal: true` on the remote agent and configure the receiver's

package/docs/tutorial/connect-a-warehouse.mdx

@@ -72,7 +72,7 @@ If the user has not authorized the connector, the turn parks and the channel sho
 
 ## The token never reaches the model
 
-Right before each request to the MCP server, eve resolves the bearer and sends it as `Authorization: Bearer <token>`. The model sees tool names, descriptions, and results. The credential stays in the app runtime.
+Right before each request to the MCP server, eve resolves the user's bearer and, once the user has authorized, sends it as `Authorization: Bearer <token>`. The model sees tool names, descriptions, and results. The credential stays in the app runtime.
 
 Gate the connection behind approval (`approval: once()`) or narrow which tools the model sees (`tools.allow`) when needed. See [MCP connections](../connections/mcp).
 

package/docs/tutorial/run-analysis.mdx

@@ -217,7 +217,7 @@ This example caps charts at 1 MiB because tool outputs are persisted with sessio
 
 ## Secrets stay out of the sandbox
 
-The sandbox has no `process.env` and no access to your app's secrets. The `run_sql` tool and sample database run in your app. You pass only the query results to the chart tool; the sandbox does not need database credentials.
+The sandbox doesn't inherit your app's `process.env`. Secrets you pass explicitly through an environment or per-call `env` option are available inside the sandbox. The `run_sql` tool and sample database run in your app. You pass only the query results to the chart tool; the sandbox does not need database credentials.
 
 The local backend runs the sandbox on your laptop during `eve dev`; on Vercel it runs on Vercel Sandbox. Lifecycle, backends, and network policy are in [Sandbox](../sandbox).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve",
-  "version": "0.81.1",
+  "version": "0.82.0",
   "private": false,
   "description": "Filesystem-first framework for durable backend AI agents that run anywhere.",
   "keywords": [

package/dist/src/execution/run-session-limits.d.ts

@@ -1,12 +0,0 @@
-import type { AgentLimitsDefinition } from "#shared/agent-definition.js";
-type UsageLimit = AgentLimitsDefinition["maxInputTokensPerSession"] | AgentLimitsDefinition["maxOutputTokensPerSession"] | AgentLimitsDefinition["maxTokenCostUsdPerSession"];
-/**
- * Resolves an authored usage cap against an inherited parent cap. `false`
- * only means "uncapped" before inheritance; an actual inherited cap still
- * bounds the child.
- */
-export declare function resolveInheritedTokenLimit(input: {
-    readonly configured: UsageLimit | undefined;
-    readonly inherited: UsageLimit | undefined;
-}): UsageLimit | undefined;
-export {};

package/dist/src/execution/run-session-limits.js

@@ -1 +0,0 @@
-function resolveInheritedTokenLimit(e){return e.inherited===void 0?e.configured:e.inherited===!1?e.configured??!1:e.configured===void 0||e.configured===!1?e.inherited:Math.min(e.configured,e.inherited)}export{resolveInheritedTokenLimit};

package/dist/src/harness/session-usage-limits.d.ts

@@ -1,49 +0,0 @@
-interface SessionUsageAmounts {
-    readonly costUsd?: number;
-    readonly inputTokens: number;
-    readonly outputTokens: number;
-}
-export interface SessionRuntimeUsageLimits {
-    readonly costUsd?: number;
-    readonly inputTokens?: number;
-    readonly outputTokens?: number;
-}
-export type SessionUsageLimitViolation = {
-    readonly kind: "input";
-    readonly limit: number;
-    readonly usedTokens: number;
-} | {
-    readonly kind: "output";
-    readonly limit: number;
-    readonly usedTokens: number;
-} | {
-    readonly kind: "token-cost";
-    readonly limitUsd: number;
-    readonly usedCostUsd: number;
-};
-/** Resolves per-axis lifetime ceilings, preferring a previously granted ceiling. */
-export declare function resolveRuntimeUsageLimits(input: {
-    readonly configured: SessionRuntimeUsageLimits;
-    readonly stored?: SessionRuntimeUsageLimits;
-}): SessionRuntimeUsageLimits;
-/** Grants one full configured window from the current lifetime usage. */
-export declare function grantRuntimeUsageLimits(input: {
-    readonly configured: SessionRuntimeUsageLimits;
-    readonly usage: SessionUsageAmounts;
-}): SessionRuntimeUsageLimits;
-/** Returns the unspent quota for each capped axis. */
-export declare function remainingRuntimeUsageQuota(input: {
-    readonly runtime: SessionRuntimeUsageLimits;
-    readonly usage: SessionUsageAmounts;
-}): {
-    readonly costUsd: number | false;
-    readonly inputTokens: number | false;
-    readonly outputTokens: number | false;
-};
-/** Returns the first exhausted axis: input tokens, output tokens, then token cost. */
-export declare function findRuntimeUsageLimitViolation(input: {
-    readonly configured: SessionRuntimeUsageLimits;
-    readonly runtime: SessionRuntimeUsageLimits;
-    readonly usage: SessionUsageAmounts;
-}): SessionUsageLimitViolation | null;
-export {};

package/dist/src/harness/session-usage-limits.js

@@ -1 +0,0 @@
-function resolveRuntimeUsageLimits(e){let t={},n=e.stored?.inputTokens??e.configured.inputTokens;n!==void 0&&(t.inputTokens=n);let r=e.stored?.outputTokens??e.configured.outputTokens;r!==void 0&&(t.outputTokens=r);let i=e.stored?.costUsd??e.configured.costUsd;return i!==void 0&&(t.costUsd=i),t}function grantRuntimeUsageLimits(e){let t={};return e.configured.inputTokens!==void 0&&(t.inputTokens=e.usage.inputTokens+e.configured.inputTokens),e.configured.outputTokens!==void 0&&(t.outputTokens=e.usage.outputTokens+e.configured.outputTokens),e.configured.costUsd!==void 0&&(t.costUsd=(e.usage.costUsd??0)+e.configured.costUsd),t}function remainingRuntimeUsageQuota(e){return{costUsd:e.runtime.costUsd!==void 0&&Math.max(0,e.runtime.costUsd-(e.usage.costUsd??0)),inputTokens:e.runtime.inputTokens!==void 0&&Math.max(0,e.runtime.inputTokens-e.usage.inputTokens),outputTokens:e.runtime.outputTokens!==void 0&&Math.max(0,e.runtime.outputTokens-e.usage.outputTokens)}}function findRuntimeUsageLimitViolation(e){return e.runtime.inputTokens!==void 0&&e.configured.inputTokens!==void 0&&e.usage.inputTokens>=e.runtime.inputTokens?{kind:`input`,limit:e.configured.inputTokens,usedTokens:e.usage.inputTokens}:e.runtime.outputTokens!==void 0&&e.configured.outputTokens!==void 0&&e.usage.outputTokens>=e.runtime.outputTokens?{kind:`output`,limit:e.configured.outputTokens,usedTokens:e.usage.outputTokens}:e.runtime.costUsd!==void 0&&e.configured.costUsd!==void 0&&(e.usage.costUsd??0)>=e.runtime.costUsd?{kind:`token-cost`,limitUsd:e.configured.costUsd,usedCostUsd:e.usage.costUsd??0}:null}export{findRuntimeUsageLimitViolation,grantRuntimeUsageLimits,remainingRuntimeUsageQuota,resolveRuntimeUsageLimits};

package/dist/src/subagents/token-budget.d.ts

@@ -1,15 +0,0 @@
-import type { RunSessionLimits } from "#channel/types.js";
-import type { HarnessSession } from "#harness/types.js";
-/**
- * Computes the session token limits a delegated child inherits from its
- * parent: the parent's remaining runtime-limit quota, per axis, split evenly
- * across the `fanoutSize` children started together. `false` marks an axis
- * with no inherited cap.
- *
- * The split bounds children started together by the parent's remainder as a
- * group, not each by the whole of it. Children started later see the quota
- * net of the spend earlier children reported, which counts in the parent's
- * session totals. A granted continuation bumps the parent's runtime limit, so
- * children started after a grant draw from the fresh window.
- */
-export declare function resolveRemainingSessionTokenLimits(session: Pick<HarnessSession, "limits" | "state">, fanoutSize: number): RunSessionLimits;

package/dist/src/subagents/token-budget.js

@@ -1 +0,0 @@
-import{getSessionRemainingUsageQuota}from"#harness/turn-tag-state.js";function resolveRemainingSessionTokenLimits(e,t){let n=Math.max(1,t),r=getSessionRemainingUsageQuota(e),i={maxInputTokensPerSession:grantTokenShare(r.inputTokens,n),maxOutputTokensPerSession:grantTokenShare(r.outputTokens,n)};return r.costUsd!==!1&&(i.maxTokenCostUsdPerSession=r.costUsd/n),i}function grantTokenShare(e,t){return e!==!1&&Math.floor(e/t)}export{resolveRemainingSessionTokenLimits};