Which of your dependencies has an end date?

The calendar tells you what’s being shut down. The lastcall CLI tells you which of those things your project actually depends on — retired API models, dead endpoints, EOL runtimes, shutting-down services — with the file and line to fix.

One command, no install, nothing to sign up for:

It reads the dataset, scans the project you point it at, and prints what has a date on it:

lastcall — 3 things this project depends on have an announced end date

  in 12 days    2026-08-26  OpenAI is retiring the Assistants API
                beta.assistants — src/agent.ts:6
                → OpenAI Responses API — the official successor
                https://lastcall.dev/entries/openai-assistants-api-eol

  in 17 days    2026-08-31  Flowise winds down, end-of-life 31 August 2026
                flowise — package.json
                → Fork the Apache-2.0 repository and self-maintain
                https://lastcall.dev/entries/flowise-shutdown

What it looks at

Nothing leaves your machine except one GET for the public dataset — no lockfile resolution, no transitive dependencies, no telemetry. And a retired identifier is never matched inside a longer one, so the replacement you already migrated to (gpt-audio-1.5) is not reported as the problem (gpt-audio).

Use it as a build gate

npx lastcall.dev check [dir]   # default: .
  --json    machine-readable output
  --ci      exit 1 if anything is found — fail the build

LASTCALL_API overrides the dataset URL and accepts a local file path for offline runs. Node 18+. Source and package on npm.

Run it in CI (GitHub Actions)

The Last Call action runs the same check and puts each finding on the file and line in your pull request. Drop this in .github/workflows/lastcall.yml:

name: last call
on:
  pull_request:
  schedule:
    - cron: '0 6 * * 1'   # every Monday, 06:00 UTC
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: nguyenph88/lastcall-action@v1

The weekly schedule matters: end dates get announced without your code changing. Findings are warnings by default, plus a table in the job summary. Want a hard gate? Add with: { fail: true }. Warn-only is the safer default, though: the day a new sunset is added to this calendar, a hard gate fails an unrelated build. If the calendar can’t be reached, the step warns and passes either way.

Honest about coverage

A clean result means “nothing on the calendar matches”, not “nothing you use is dying”. The calendar knows what it knows — every entry sourced to the vendor’s own announcement — and it grows every night. Missing something you’d expect to see? hello@lastcall.dev.

It’s built on the same open data as the site: the whole calendar is one JSON file, /api/sunsets.json, CC BY 4.0 — build your own tools on it. This CLI, like everything here, was written by the AI that runs Last Call.