Skip to main content

The OGX Python SDK Has a New Foundation

· 2 min read
E Geiger
E Geiger
OGX Team
OGX Team
Core Team

Starting with ogx_client 1.1.4, the Python SDK is built on a new code generation backend. The package name and API surface stay the same — most codebases need only an import path change.

What changed​

The OGX Python SDK was previously generated by Stainless, an external SaaS code generation service. Starting with version 1.1.4, the SDK is generated by OpenAPI Generator from the same OpenAPI spec that defines the OGX server.

The package is still ogx_client. You still pip install ogx_client. The client classes, API methods, and keyword arguments are the same. What changed is what's underneath — and that matters for the project's long-term health.

Why we made the switch​

Three things drove the decision (see the original discussion for the full context):

Sovereignty. Relying on an external managed service to generate our SDK meant we couldn't ship fixes on our own schedule. We needed the pipeline in our hands. This became urgent when Anthropic acquired Stainless and discontinued the service — but the migration was already underway before that happened, motivated by the same concern.

Local development. With Stainless, generating an SDK required pushing code to GitHub and waiting for the external service to process it. Developers couldn't test SDK changes locally. With OpenAPI Generator, a developer can modify the API, regenerate the client, and run tests — all before opening a PR. API and client changes now ship together in a single commit.

Multi-language coverage. OGX targets Python, TypeScript, Java, and Go. OpenAPI Generator supports all of them with a single, adjustable template system. We maintain custom templates to preserve the SDK's look and feel, but the generation pipeline is unified across languages.

What it means for you​

For most codebases, migrating is a search-and-replace.

What's different at a glance​

  • Import paths: ogx_client.types is now ogx_client.models, with a flat namespace (no more types.shared, types.chat, etc.)
  • Type names: some types were renamed -- OpenAI prefix and Object suffix added to align with the OpenAPI spec
  • Pagination: auto-paginating iterators are gone; list endpoints return one page at a time
  • Removed client features: client.copy(), client.with_raw_response, client.with_streaming_response, and file_from_path are no longer available
  • Exception attributes: e.status_code is now e.status; e.response is no longer available (use e.headers, e.body directly)
  • Python 3.12+ and Pydantic 2.x are now required

The main change is the import path for types:

# Before (<= 1.1.3)
from ogx_client.types import ResponseObject

# After (>= 1.1.4)
from ogx_client.models import OpenAIResponseObject

Some type names also changed — resource types gained an OpenAI prefix or Object suffix to align with the OpenAPI spec naming. The actual fields on these types are identical.

Quick checklist​

  • Upgrade Python to 3.12+ and Pydantic to 2.x (if not already)
  • Upgrade ogx_client to >= 1.1.4
  • Replace from ogx_client.types with from ogx_client.models in all imports
  • Update type names per the mapping tables in the migration guide

Full migration guide​

For the complete reference — including all type name mappings, pagination changes, removed client features, and exception attribute differences — see Migrating to ogx_client 1.1.4: The Complete Reference.