Changelog

Full history: CHANGELOG.md in the repository.

All notable changes to this project will be documented in this file.

[Unreleased]Copy Anchor Link

MarketplaceCopy Anchor Link

• MCP server (@bytewells/mcp) — agents can search the Store, fetch Actor details and input schemas, start runs, read datasets / OUTPUT, and buy fare-capped time-window passes when a run returns 402 rental-required. Stdio and streamable HTTP transports; optional BYTEWELLS_ACTORS pins. Does not start monthly rentals. See MCP server.

• Login / Connect with Apify — continue with Apify on sign-in, or connect an existing Bytewells account from Settings / New Actor. OAuth (PKCE) stores an encrypted Apify token so the console can list and import Actors as draft listings without pasting APIFY_TOKEN. CLI bw import apify remains for tokens and CI. See Import from Apify.

• Time-window passes with fare capping — besides the monthly rental, developers can price optional per-listing Flash (1 h), Burst (24 h) and Sprint (7 d) passes, so AI agents can use an Actor for a short burst. Charges accumulate in rolling windows anchored at the first charge and are capped at the next tier's price (Flash → Burst → Sprint → Monthly): e.g. Flash $2 / Burst $8, uses at 9h, 11h, 18h and 20h cost $8 in total and the Burst covers 9h → 33h. Passes are paid from prepaid credits; every charge carries the usual commission and developer earnings are recorded in the earnings ledger and paid monthly. Orgs opt into auto-purchase (PUT /v2/me/pass-settings), or buy explicitly (POST /v2/store/:username/:actorName/passes); 402s include a machine-readable pass offer. Run-scoped tokens never buy passes. Existing rentals and listings are unchanged until a developer sets pass prices.

• Developer earnings ledger and monthly payouts. Rentals and passes are charged on the platform account and recorded per sale. Developers bear Stripe's variable fees at cost, earnings are held 14 days and paid monthly once they reach $50, and developers can sell before verifying with Stripe. The $5 sign-up credit is compute-only.

New environment variablesCopy Anchor Link

• APIFY_OAUTH_CLIENT_ID / APIFY_OAUTH_CLIENT_SECRET — Apify OAuth confidential client (DCR). Redirect URI: {PLATFORM_URL}/v2/auth/apify/callback.
• APIFY_TOKEN_ENCRYPTION_KEY — 64 hex chars; AES-GCM key for stored Apify OAuth tokens.
• EARNINGS_HOLD_DAYS (default 14), PAYOUT_MIN_CENTS (default 5000), PAYOUT_DAY_OF_MONTH (default 1), UNPAYABLE_GRACE_DAYS (default 90), BILLING_FEE_BPS (default 70), PASS_PROCESSING_BPS (default 350) — developer earnings ledger and monthly payouts. Replaces PASS_PAYOUT_MIN_CENTS.

[1.6.0] - 2026-08-05Copy Anchor Link

Disk-pressure protection for the runner fleet plus an Apify-parity fix on dataset reads: a full runner disk can no longer black-hole the READY queue, and GET /v2/datasets/:id/items without a limit now returns the whole dataset like real Apify does. Also: community feedback funnels, and the npm publish pipeline un-wedged (npm still served 1.0.1 while the repo was at 1.5.0).

RunnerCopy Anchor Link

• Disk admission gate — a full runner disk fails every image pull in ~90s, and because work is runner-pull, a disk-full runner out-claims healthy capacity and drains the READY queue by fast-failing it while hiding the demand from the scaler (prod 2026-08-04/05: 104 failed runs, both 80 GB runner disks at 100%). At RUNNER_DISK_CLAIM_MAX_PCT (default 90%) disk usage the runner stops claiming and idles, letting the queue back up so the scaler's starvation escalation provisions healthy capacity. The threshold is validated into 1–100 at startup (envInt accepts 0, which would gate every claim and silently brick the runner).
• Registry-scoped image eviction — at RUNNER_DISK_EVICT_PCT (default 80%) the periodic cleanup also removes unused tagged images, but only tags under the configured IMAGE_REGISTRY prefix: those are the only images with a guaranteed re-pull path, and exactly the fleet's growth source (dangling-only pruning never shrinks a fleet whose growth is new per-actor tags). Locally built images are never evicted — with no registry there is no re-pull path, so removal would be permanent. Per-tag non-forced removes let the daemon protect in-use images. Eviction must sit below the claim gate — enforced at startup with warn + clamp — and engaging the gate kicks cleanup immediately (debounced per episode) instead of waiting out the 30-minute sweep.
• Infra retry floor — image-pull failures and missing-image container-create 404s are host problems, not actor bugs, so they now retry on a small platform floor (2 attempts, 60s delay) even when the actor has retries disabled; the floor never reduces a more generous actor policy. Pull errors are prefix-stamped at the failure site so transport-level errors (registry outage, DNS) classify correctly, and the rethrow always produces a real Error — a non-Error rejection previously crashed the failure handler itself, leaving the run un-terminalized.
• `st