release: 0.23.0

[stainless-app]

Automated Release PR

0.23.0 (2026-04-01)

Full Changelog: v0.22.0...v0.23.0

Features

• Cid/fetching endpoints (d5fa2c2)

---

This pull request is managed by Stainless's GitHub App.

The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.

For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.

🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions

[stainless-app]

🧪 Testing

To try out this version of the SDK:

pip install 'https://pkg.stainless.com/s/openlayer-python/d5fa2c238b72262b13e9c0d121dc61155d3eec30/openlayer-0.22.0-py3-none-any.whl'

Expires at: Fri, 01 May 2026 22:15:03 GMT
Updated at: Wed, 01 Apr 2026 22:15:03 GMT

[stainless-app]

🤖 Release is at https://github.com/openlayer-ai/openlayer-python/releases/tag/v0.23.0 🌻

[claude]

🟡 The date_created field in InferencePipelineRetrieveSessionsResponse.Item has the description "Latest/most recent timestamp in the session", which conflicts with date_of_last_record described as "Timestamp of the last request in the session" — two near-identical descriptions for what are presumably different fields. By naming convention, date_created should describe when the session entity was created (analogous to date_of_first_record), not the most recent activity timestamp. The upstream OpenAPI spec should be corrected so that dateCreated carries a creation-time description.

Extended reasoning...

In src/openlayer/types/inference_pipeline_retrieve_sessions_response.py (lines 19-23), the newly introduced Item model defines three timestamp fields. The field date_created (alias dateCreated) carries the docstring "Latest/most recent timestamp in the session", while date_of_last_record (alias dateOfLastRecord) carries "Timestamp of the last request in the session". These two descriptions are semantically equivalent — both describe the most recent or last activity timestamp in the session. This makes the purpose of date_created confusing and inconsistent with its name.

The naming pattern in the same model strongly implies the intended semantics: date_of_first_record describes the earliest timestamp and date_of_last_record describes the latest timestamp. A field named date_created would conventionally mean when the session database record was created — a creation timestamp — not the most recent activity timestamp. The current description is almost certainly a copy-paste error from the description of dateOfLastRecord in the upstream OpenAPI spec.

The refuter argues that since this is auto-generated code from the OpenAPI spec, the Python SDK faithfully reproduces what the spec defines, and thus the bug is not actionable in this PR. While the fix must ultimately be made in the spec, this does not make the issue non-real. The misleading docstring is introduced in this PR and will be seen by SDK users reading IDE hover text or generated documentation. Developers who encounter both date_created and date_of_last_record in their IDE will be confused about what date_created represents — or worse, may assume the two fields are redundant and ignore one.

Step-by-step proof of confusion:

1. A developer calls client.inference_pipelines.retrieve_sessions(...) and receives an InferencePipelineRetrieveSessionsResponse.
2. They inspect item.date_created and read its docstring: "Latest/most recent timestamp in the session".
3. They also see item.date_of_last_record with docstring: "Timestamp of the last request in the session".
4. Both descriptions point to the same concept, so the developer cannot determine the semantic difference between the two fields from documentation alone.
5. Either they incorrectly treat date_created as equivalent to date_of_last_record (ignoring it as redundant), or they mistakenly use it where they need the actual creation timestamp.

The correct description for date_created should be something like "Timestamp when the session entity was created" to align with the field name and distinguish it from date_of_last_record. The fix should be made in the upstream OpenAPI spec so that the next code generation produces the correct docstring.