Models and deployments

The generative AI hub doesn't train its own general-purpose model. It gives governed access to models from several providers plus a few SAP-built models, under one contract, one set of credentials and SAP's operational controls. This lesson covers where the models come from, how to deploy and pin them, and where to check what is available and when it retires.

Where the models come from

Remote models run on the provider's platform and are reached through SAP AI Core; SAP notes, for example, that Azure OpenAI models are accessed through a private instance of the chat-completions API that isn't publicly accessible. SAP-hosted models run on SAP AI Core infrastructure. Anthropic's Claude models are reached through the aws-bedrock executable; separately, SAP and Anthropic announced in May 2026 that they plan to bring Claude to the SAP Business AI Platform for Joule agents. That plan has no date; the Bedrock route is what exists today.

SAP's own models

• SAP-ABAP-1: a foundation model built by SAP and fine-tuned on SAP S/4HANA ABAP and CDS code. It supports code-to-text (explaining ABAP), has a 128,000-token context window, and is the same model SAP uses for Joule for Developers in ADT, Joule for Consultants and custom code migration. SAP's documentation says it "can only be accessed via the Orchestration service" and needs the extended plan. For learning, the same page says you can test it free for 30 days with the generative AI hub's "Try now" trial.
• SAP-RPT-1.5 and SAP-RPT-1.6: relational pre-trained transformers for predictions on tabular enterprise data (classification and regression by in-context learning, without training). SAP-RPT-1.5 arrived in mid-2026 and SAP lists SAP-RPT-1.6 (a standard and a large variant) as generally available in the AI Core model library; SAP also describes a tabular orchestration workflow that selects context and builds the prediction call. Check the What's New page for exact dates and features before you design around them, because SAP's product pages and FAQs don't always agree.

Two ways to call a model

Through the foundation-models scenario, you create a configuration and a deployment for one specific model (for Claude, executable aws-bedrock plus the model name) and call that deployment's URL. Through the orchestration scenario, one orchestration deployment serves many models: you name the model in the request's configuration. SAP lists the advantages of orchestration plainly: it's provider-agnostic, you "can switch models via a config parameter without creating new deployments", and you can add modules such as filtering, masking and grounding as needed.

Versions, deprecation and regions

Models retire. SAP's Model Lifecycle page: where a model version is specified in a deployment, "the deployment stops working on the deprecation date of that model version." You choose between auto upgrade (set modelVersion to latest, the default when no version is given, and existing deployments move to new versions automatically) and manual upgrade (pin a version and patch the deployment yourself). Auto upgrade avoids outages but can change behavior without warning; manual upgrade keeps behavior stable but needs a calendar.

Availability also differs by region and landscape; SAP publishes model availability and feature availability by region, and some features are marked as not offered for sovereign cloud. The authoritative list of models, token conversion rates, rate limits and deprecation dates is SAP Note 3437766; SAP's documentation for orchestration also points to SAP Note 3505347 for supported models and costs. SAP's What's New page shows how fast this moves: new model versions were announced in June, July, August and September 2026.