Migrate off GPT-4.1 mini before deprecation and make the model configurable per deployment

[sihbher]

Summary

GPT-4.1 mini is being deprecated and needs to be replaced with a newer, supported model in ContentFlow before the retirement date to avoid service disruption. In addition, we propose making the model configurable per subscription so future model swaps don't require code changes.

Background

ContentFlow currently depends on a hardcoded GPT-4.1 mini for its model calls. Since this model is scheduled for deprecation, we need to migrate to a supported successor. This was confirmed as still open with Nadeem Ishqair (owner), who requested this issue be filed to track the work.

Problem

• GPT-4.1 mini will be retired; once deprecated, requests to it will fail.
• ContentFlow will break wherever it references the deprecated model unless migrated in time.
• The model is currently not configurable, so every deprecation or model change forces a code/deployment change. This is a recurring maintenance burden.

Proposed work

1. Immediate migration

1. Identify all references to GPT-4.1 mini in ContentFlow (config, deployment names, environment variables, code, prompt/model routing).
2. Select the replacement model based on cost, latency, and quality parity for ContentFlow's use cases.
3. Update configuration/deployment to point to the new model.
4. Validate output quality and regression-test the affected ContentFlow flows.

2. Make the model configurable per deployment

• Introduce a configurable model setting scoped to each deployment (e.g., a deployment-level config value / environment variable) instead of a hardcoded model reference.
• ContentFlow should read the model name/deployment from this configuration at runtime, with a sensible default and validation/fallback if an unsupported value is set.
• This lets each deployment select its own model and lets us swap models on future deprecations without code changes.