How API Changelog Classifier works
Press Load model once: your browser downloads Gemma 4 E2B instruction-tuned (web build) (2.0 GB) from this site and keeps it in its cache. Then add your text and press Classify locally. The model runs on this device using your graphics card, so nothing you enter is sent to a server. Until the model is loaded, or if your device cannot run it, the tool falls back to a simple keyword check and labels the result as the fallback.
Gemma 4 E2B instruction-tuned (web build) is a small open language model from Google. The tool sends it the instruction below plus your text, asks for a JSON answer with fixed fields, and shows each field as a card. It runs at temperature 0, so the same input gives the same answer on the same device, though different graphics cards can word it slightly differently.
Inputs longer than 6,000 characters are cut to that length before they reach the model, and the result says so. The model only sees what you paste: it does not look anything up.
The instruction the model gets
You classify API changelog entries for the developers who consume the API. Label each change: Breaking (existing client code can fail: removed or renamed fields or endpoints, changed types or response shapes, new required parameters, stricter validation, changed auth), Deprecation (still works now but is scheduled to change or be removed), Feature (a new, optional capability), Fix (a bug fix that keeps the contract), or Docs/Internal. Keep dates, versions, field and endpoint names exactly as written.
What it returns
- Change by change: One entry per change, written as 'change → Label: short reason'.
- What consumers must change: For each Breaking change, what client code has to do.
- Dates and sunsets: Dates, versions or sunset periods exactly as written, with what each applies to.
- Release type: Whether this looks like a major, minor or patch release, and why.