LukePS
90d · built 2026-11-10
Performance
What LukePS shipped in the selected window, measured in ETV, and how it compares with the 90 days before it.
Effective capacity
+3.3engineers
delivers like 4.3 (4.3x pre-AI)
Output (ETV)
0.8ETV
+1520.0% vs 0.1 prior
Features share
25.9%
+25.9 pp vs prior window
Fixes share
14.8%
+14.8 pp vs prior window
Work mix
25.9% Features21% Maintenance21% Tests17.3% Docs14.8% Fixes
6 commits over 90 days, ending 2026-11-10.
Daily performance
Daily ETV, stacked by Features, Maintenance, Tests, Docs and Fixes.
Repository spread
Where this developer's commits land. Concentrated work (top1 > 80%) vs polymath spread (top1 < 30%).
Most impactful commits
Top 10 by ETV in the last 90 days.
- 0.2ETV[sdk] Skip the per-request OIDC token check until the token nears expiry (#448) This PR removes OIDC token work from the hot path of every Sandbox API request while the current token is still valid. **Why** `APIClient.request()` calls `ensureValidToken()` before every request. For JWT (OIDC) tokens, that called `getVercelOidcToken()` every time. In `@vercel/oidc` 4.0.0 that can mean reading `VERCEL_OIDC_TOKEN_FILE` from disk, awaiting two dynamic imports, and decoding the JWT, all to return the same token in almost every case. Concurrent requests each ran their own check. **Approach** Because the token's `exp` claim already tells us when a refresh is needed, we can cache it and skip the check until then: - `decodeUnverifiedToken` now also reads `exp`. The client stores `tokenExpiresAt` at construction and after each refresh. - `ensureValidToken()` returns immediately while the token is more than 5 minutes from expiring. That's the same buffer already passed to `getVercelOidcToken`. - Inside the buffer, or when the token has no `exp`, it calls `getVercelOidcToken` as before. Concurrent requests share one in-flight refresh. - Refresh failures are still swallowed and the current token is kept. The next request retries. - Non-JWT access tokens are unchanged: no checks at all. **Behavior change to review** Before, a long-lived client re-read the token source on every request. That source is the request-context `x-vercel-oidc-token` header in Vercel Functions, or the token file. Now it keeps using its current token until that token is within 5 minutes of expiring. The token is still valid and has the same team and project scope, so requests should behave the same. A token that is rotated early (before its own expiry window) won't be picked up until then. **Validation** - New `api-client.token.test.ts` mocks `@vercel/oidc` and covers 7 cases: - No refresh call while the token is far from expiry. - A refresh inside the buffer, after which the new token and its `owner_id` (as the `teamId` query param) are used. - A refresh once time moves the token into the buffer (fake timers). - One shared refresh for 3 concurrent requests. - Retry after a failed refresh. - A check on every request when `exp` is missing. - No checks for non-JWT tokens. - 4 of the 7 tests fail on `main` (checked by stashing the change). The other 3 confirm that existing behavior is kept. - `pnpm typecheck` is clean. `pnpm build && pnpm test`: 25 files passed, 1 skipped.github.com-vercel-sandbox · 3b6e77ab · 2026-11-09
- 0.2ETV[images]: Add `runtime` images (#313) # Overview Open source our legacy `runtime` images for `node` & `python`. These contain the necessary `Dockerfile` configurations to run `node-22`, `node-24`, `node-26` and `python3.13` runtimes. These will get published with prefixed `al-{version}` tags in the same repositories as the `sandbox:node` and `sandbox:python` repositories and provide a migration for customers away from the legacy `runtime` property. > [!NOTE] > These images are **deprecated** and will not be maintained going forward. > They are purely here for future reference. --------- Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>github.com-vercel-sandbox · 92535f1c · 2026-08-26
- 0.2ETV[sandbox-cli] Take sandbox name and path as separate args in read and write (#442) `sandbox read` (alias `cat`) and `sandbox write` now take `<name> <path>` as two positional arguments, matching `exec`, `stop`, `extend`, and the other per-sandbox commands. **Why** #380 added these commands with a single `SANDBOX_NAME:PATH` argument borrowed from `copy`. Every other command that targets an existing sandbox takes the name as its own first positional, so `read`/`write` were the odd ones out. ```sh # before sandbox read my-sandbox:/vercel/sandbox/package.json sandbox write my-sandbox:/vercel/sandbox/app.js < ./app.js # after sandbox read my-sandbox /vercel/sandbox/package.json sandbox cat my-sandbox /vercel/sandbox/package.json sandbox write my-sandbox /vercel/sandbox/app.js < ./app.js ``` **Approach** Both commands now use the shared `sandboxName` positional plus a plain `path` positional. The `remotePath` type and `parseRemotePath` helper in `cp.ts` existed only for these two commands, so they are removed along with their tests. `copy` keeps `NAME:PATH`, since it needs to tell local and remote paths apart. The commands are not released yet (the #380 changeset is still pending), so there is no compatibility shim; the existing changeset is updated to show the new usage instead of adding a second one. **Validation** - `pnpm typecheck` passes. - `pnpm vitest run`: 36 files, 401 tests pass, including the fake-sandbox tests for `read`, missing-file `read`, and `write --mode 755` using the new argument order, and the built-binary `--help` checks for `read`, `cat`, and `write`. - Built binary `read --help` / `write --help` list `<name>` and `<path>`. - `docs/index.md` regenerated with `pnpm generate-docs`; root help example, skill doc, and `write` examples updated. Not tested against a live sandbox; the handler logic is unchanged apart from where the name and path come from. --------- Co-authored-by: roboeve[bot] <311457182+roboeve[bot]@users.noreply.github.com> Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com> Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>github.com-vercel-sandbox · 0a60b67d · 2026-11-06
- 0.1ETV[interactive]: Ensure that command server is healthy before connecting (#317) # Overview Validate that the `/health` endpoint of the sandbox interactive server is active and ready to serve traffic before trying to create a websocket connection.github.com-vercel-sandbox · 370a8113 · 2026-08-27
- 0.0ETV[images] add fx coding agent to the universal image (#403) Adds [fx](https://github.com/vercel-labs/fx), the native coding agent from Vercel Labs, to `vercel/sandbox/universal` next to the other coding agents. **Why** The universal image already ships opencode, Claude Code, Codex and pi. fx is built to run inside agent sandboxes, so it should be available out of the box too. **Approach** fx is a single native binary, so there's nothing to add from npm or apt. The image downloads the pinned GitHub release tarball (`ARG FX_VERSION=0.0.14`, the current latest), checks it against the `.sha256` file published with the release, and unpacks the binary into `~/.local/bin` as the `ubuntu` user. That directory is already on `PATH` and is where the upstream `fx.sh/setup.sh` installer puts fx, so `fx upgrade` keeps working without sudo. It uses the `linux-x86_64` asset, which matches the image's only build platform (`linux/amd64`). - `Dockerfile`: install step after the user `PATH` setup, plus `fx --version` in the final smoke check - `README.md`: list fx under Coding agents - Changeset: patch bump for `sandbox-image-universal` **Validation** - Ran the install step as written against a fresh `HOME`: the checksum check passes, and `~/.local/bin/fx --version` prints `0.0.14`. - I haven't built the full image locally (no Docker available). CI's image build and the `fx --version` smoke check cover that. --------- Co-authored-by: roboeve[bot] <311457182+roboeve[bot]@users.noreply.github.com>github.com-vercel-sandbox · 60f5678d · 2026-10-26
- 0.0ETVConfigure Dependabot for npm package updates (#458)github.com-vercel-sandbox · 153e6bc0 · 2026-11-09