Since.dev

View saved version →

---
name: since-before-upgrading
description: Use before upgrading, adding or removing a dependency, before editing a manifest or lockfile (package.json, package-lock.json, requirements.txt, pyproject.toml, poetry.lock, go.mod, Cargo.toml, Gemfile, pom.xml, build.gradle, composer.json and the like), and when a build breaks after a version bump. Asks Since.dev what the change breaks in this code, with the file and line, how severe it is, the days left and what to move to.
---

# Check a dependency change with Since.dev

Since.dev records every release, breaking change, deprecation and security advisory across 18 package registries, with its source. Use it so an upgrade lands working the first time.

## Before you change a version

1. **See what already affects the code.** Call `check_code` with the manifest or lockfile that pins the package:

   ```json
   { "manifest": { "path": "package.json", "content": "<the file's contents>" } }
   ```

   Use `lockfile` instead of `manifest` when the repo has one: it holds the exact installed versions, transitive ones included.

2. **Read what changed between your version and the one you want.** Call `whats_changed` with the package in any spelling or as a purl, and `since` set to the version you have now:

   ```json
   { "package": "npm:react", "since": "18.2.0" }
   ```

   Each change has its kind (removed, renamed, signature changed, deprecated, security), severity, dates, the replacement and a link to its source. `package.releasesBehind` says how far behind you are.

3. **Make the change, then check again** with the updated manifest or lockfile. Fix every `affected` finding before you finish.

## Reading the answer

- `affected`: the code uses the thing that changed. The finding names the file and line.
- `needs_review` and `unknown`: not settled. Read the cited source or ask the user. Never treat them as safe.
- `replacement`: what to move to, from the publisher's own notes.
- `daysLeft`: how long until a removal or end of life takes effect. Do the soonest first.

## When the user wants it fixed for them

If the repository is connected to Since.dev, `fix_code` with `repo` opens a pull request that fixes it, for a person to review. Your client asks before it runs. For a snippet, `fix_code` with `code` and `language` returns the patch.

## Cost

Each call costs credits from the workspace's monthly allowance, and each tool's description says how many. Checking a manifest or lockfile costs more than a single package, so check the file once, then read single packages as you need them.

View saved version →

---
name: since-ci-and-runtimes
description: Use when editing CI workflows (.github/workflows/*.yml), Dockerfiles, docker-compose files or runtime version files (.nvmrc, .node-version, .python-version, .tool-versions, go.mod, global.json), when choosing a runtime or base image version, and when a CI runner or image fails. Asks Since.dev which runner images, base images and runtime versions are past or near end of life, and what to move to.
---

# Check runtimes, images and CI runners with Since.dev

Runtimes and CI runners reach end of life on published dates. After that, runtimes stop getting security fixes, and retired CI runner images make jobs fail. Since.dev tracks these dates from each project's own schedule.

## Runtime version files

Send the file to `check_code` as a manifest:

```json
{ "manifest": { "path": ".nvmrc", "content": "18\n" } }
```

This works for `.nvmrc`, `.node-version`, `.python-version`, `.tool-versions`, `go.mod` and `global.json`. The answer gives each runtime's status, end-of-life date and the line it is on.

## Dockerfiles, compose files and workflows

Read the versions out of the file yourself: base images (`FROM node:18-alpine`), `runs-on:` runner labels (`macos-14`, `ubuntu-22.04`) and `setup-*` action versions (`node-version: 18`). Then check each one as a surface with `check_code`:

```json
{ "surface": "runtime:node@18" }
```

```json
{ "surface": "runtime:github-actions-runner-images@macos-14" }
```

The surface is `runtime:<product>@<version>`, for example `runtime:python@3.9`, `runtime:go@1.23` or `runtime:dotnet@8`.

## See what ends soon

```json
{ "surface": "runtime:nodejs", "within": "180d" }
```

With `whats_changed`, this lists the end-of-life dates coming up, soonest first.

## Moving off an old version

Prefer the newest supported LTS or the version the answer names as the replacement, change every place that pins it (the version file, the Dockerfile, the workflow), then check again. `needs_review` and `unknown` are not settled: read the cited source or ask the user.

View saved version →

---
name: since-model-retirements
description: Use whenever code names an AI model ID (for example gpt-5, gpt-4o-mini-2024-07-18, claude-sonnet-4-5-20250929, gemini-2.5-pro, or a Bedrock, Vertex AI or Azure model ID), when choosing or switching a model, and when a model call starts failing with a model-not-found error. Asks Since.dev whether the model is deprecated or retiring, on which date on the platform the code calls, and what replaces it.
---

# Check AI model retirements with Since.dev

Providers retire models on fixed dates, and requests to a retired model fail. The date depends on where the code calls the model: the provider's own API, Azure, Amazon Bedrock and Google Vertex AI each set their own. Since.dev tracks every model's lifecycle on each of these platforms from the publishers' own pages.

## Check one model

```json
{ "model": "claude-sonnet-4-5-20250929" }
```

Call `check_code` with it. The answer gives the model's status (`supported`, `deprecated`, `retired` or `unknown`), every change with its date per platform, `daysLeft` and the `replacement`.

## Check every model in a file

Send the file to `check_code` as code, with its language or path:

```json
{ "code": "<the file's contents>", "language": "typescript" }
```

It finds each model ID in the code and reports the line it is on.

## Pick the right date

Look at how the code reaches the model. A client made for Azure, Bedrock or Vertex AI uses that platform's date, which can be earlier or later than the provider's own. Quote the date for the platform the code actually calls, not the first one you see.

## When a model is retiring

1. Move to the `replacement` the answer names.
2. Read the replacement's own changes with `whats_changed` (`{ "model": "<replacement id>" }`): a newer model can reject parameters the old one took.
3. Check again so nothing still names the old model.

## See what retires soon

```json
{ "provider": "openai", "within": "90d" }
```

Call `whats_changed` with a provider and `within` to list retirements in the coming days, soonest first.

`needs_review` and `unknown` mean not settled. Read the cited source or ask the user, never assume the model is fine.

View saved version →

---
name: since-what-changed
description: Use before writing code against a library, SDK, framework, API or runtime you learned about in training, especially fast-moving ones, and when the user asks what changed in a package, provider, model or API since a date or version. Asks Since.dev what changed after your training cutoff, so the code matches the versions that exist today.
---

# Ask Since.dev what changed since you were trained

You learned these packages and APIs at a point in time. Since then, functions were renamed or removed, parameters changed, models retired and runtimes reached end of life. Since.dev keeps the record of every change, with its source, so you can catch up before you write code.

## Catch up on one thing

Call `whats_changed` with what you are about to use and `since` set to your training cutoff as a date:

```json
{ "package": "pypi:openai", "since": "2025-01-01" }
```

Instead of `package`, use `provider` (for example `stripe` or `anthropic`), `model`, or `surface` (an API host such as `api.stripe.com`, or a runtime such as `runtime:node@20`). Use a version instead of a date when you know which one the project has: `"since": "1.40.0"`.

Each change gives its kind, severity, dates, the replacement and a link to the publisher's source. Page through more with `nextCursor`. To read one change in full, call `whats_changed` with its `id`.

## Check the code you wrote

After writing it, call `check_code` with the snippet and its language. It reports anything in the code that a recorded change affects, with the line.

## Ask whether something is still supported

```json
{ "surface": "runtime:python@3.9" }
```

With `check_code`, the answer says `supported`, `deprecated`, `retired` or `unknown`, with its source.

Treat `needs_review` and `unknown` as not settled. When an answer cites a source, prefer it over what you remember.