Sort Sume image models by created? The field is one shared value
GET /v1/images/models returns the same created timestamp for every model, so it cannot tell you which is newest. What to use instead, with a script to prove it.

Can you find the newest image model on Sume by sorting GET /v1/images/models by created? No. On origin/main every catalog entry returns the same created value, 1785801600, which is 2026-08-04 00:00 UTC. The comment next to the constant in the API says Sume does not keep a per-model creation timestamp, so the field is there to keep the response OpenRouter-shaped, not to rank models by age.
This matters because the field is easy to misuse. The docs example shows a created number on a model, and OpenRouter-style clients often sort by it. A sort will return the catalog in an arbitrary order, and a filter such as "models newer than last month" will include or exclude every model at once.
What to use instead
To detect a new model, diff the set of ids. A model that was not in yesterday's snapshot is new, and a model that disappeared was retired. The id is the stable key: org/slug form such as google/nano-banana-2, with legacy bare ids still accepted as aliases (Sume Image API docs).
To detect a change in an existing model, compare its supported_parameters and its pricing line from the endpoints call. Those are the fields that change what you can send and what you pay, which is what most readers actually care about.
| Field | Reliable for ranking by age? | Use it for |
|---|---|---|
| created | No, one shared value | nothing; ignore it |
| id | Yes, as a key | spotting added and removed models |
| supported_parameters | Not for age | spotting new ratios, qualities, n ranges |
| endpoints pricing | Not for age | spotting price changes |
Prove it in ten lines
The script below fetches the catalog and prints how many distinct created values it contains, the date they decode to, and the model count. Run it when you doubt this post: if Sume ever starts publishing per-model times, the distinct count will rise above one and the advice here no longer applies. It needs SUME_API_KEY in the environment.
import os, requests
from datetime import datetime, timezone
r = requests.get("https://api.sume.com/v1/images/models", timeout=30,
headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"})
r.raise_for_status()
models = r.json()["data"]
created = {m["created"] for m in models}
print(f"{len(models)} models, {len(created)} distinct created value(s)")
for c in sorted(created):
print(c, datetime.fromtimestamp(c, tz=timezone.utc).isoformat())
if len(created) == 1:
print("created cannot rank these models; diff the ids instead")A snapshot diff that works
Save the ids to a file each day and compare. A daily diff of ids is the whole mechanism; the linked posts show full scripts for price and catalog watching. See alert when a Sume image model price changes and what to do when a model is missing from the catalog.
If you only need to know whether a specific model exists today, request its endpoints record: an unknown id returns 404 model_not_found with a pointer to the catalog URL.
Related posts
More in Developers
- Split a Sume job's queue wait from its run time with job events
Read GET /v1/jobs/{id}/events and subtract timestamps: job.queued to job.started is queue wait, job.started to the terminal event is run time. Python sample.
- Export every Sume job to CSV with next_cursor pagination in Python
Loop GET /v1/jobs?limit=100 and pass next_cursor back as starting_after until it is absent, then write id, status and captured cost to CSV with csv.DictWriter.
- Sume MCP 256 KiB output budget: oversize error is not a failed job
Sume's MCP tool results are capped at 256 KiB serialized. An oversize result returns an explicit error instead of a cut-off value, and the job may be fine.
- Sume MCP wait_busy 429: a retryable isError, paid creates queue 20 s
A busy Sume MCP server returns an isError result with http_status 429, retryable. The paid-create limits behind it and how to back off without double billing.
Written by Sume