Regression: gpt-5.3-codex-spark falls back to image-capable unknown-model metadata after 0.144.0 catalog update

Open 💬 3 comments Opened Jul 10, 2026 by ignatremizov

What version of Codex CLI is running?

v0.144.0 and current main after the model catalog update that removed the gpt-5.3-codex* metadata from the bundled catalog.

The regression appears between rust-v0.143.0 and rust-v0.144.0.

What subscription do you have?

Not subscription-specific. Observed on Pro 20x.

Which model were you using?

gpt-5.3-codex-spark

The resolved backend slug in the 400 was:

gpt-5.3-codex-spark-1p-codexswic-ev3

What platform is your computer?

Not platform-specific.

What terminal emulator and version are you using (if applicable)?

Not terminal-specific.

Codex doctor report

Not applicable. This is a model catalog / metadata fallback regression.

What issue are you seeing?

gpt-5.3-codex-spark no longer resolves to model-specific metadata, so Codex falls back to generic unknown-model metadata and advertises image_generation to a model that intentionally does not support image generation.

Observed CLI behavior:

codex -m gpt-5.3-codex-spark

› Ping

⚠ Model metadata for `gpt-5.3-codex-spark` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.

■ {
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "Tool 'image_generation' is not supported with gpt-5.3-codex-spark-1p-codexswic-ev3.",
    "param": "tools"
  },
  "status": 400
}

This is not a request to add image generation to Spark. The earlier behavior/expectation is the opposite: Spark should be known to the client as a text-only/no-image-generation model, so Codex should not send the image_generation tool for it.

The failure is caused by the catalog/fallback path losing that model-specific capability knowledge. Generic fallback metadata currently uses the default input modalities (text, image) for backward compatibility. The tool planner then treats image input support as sufficient to expose standalone image_generation when the provider supports image generation. For Spark, that produces an invalid request.

What steps can reproduce the bug?

  1. Use Codex CLI v0.144.0 or current main with the bundled model catalog.
  2. Run:

``sh
codex -m gpt-5.3-codex-spark
``

  1. Submit a simple prompt such as Ping.
  2. Observe the warning that gpt-5.3-codex-spark metadata was not found.
  3. Observe the Responses API 400 rejecting the image_generation tool for gpt-5.3-codex-spark-1p-codexswic-ev3.

The catalog change is visible from the release tags:

git show rust-v0.143.0:codex-rs/models-manager/models.json \
  | jq '.models[] | select(.slug | startswith("gpt-5.3-codex")) | .slug'
# "gpt-5.3-codex"

git show rust-v0.144.0:codex-rs/models-manager/models.json \
  | jq '.models[] | select(.slug | startswith("gpt-5.3-codex")) | .slug'
# no output

gpt-5.3-codex-spark-* slugs therefore no longer have a catalog prefix to match and go through model_info_from_slug fallback metadata.

What is the expected behavior?

gpt-5.3-codex-spark should resolve to explicit model metadata instead of unknown-model fallback metadata.

That metadata should preserve the intended Spark capability surface:

  • no fallback warning for gpt-5.3-codex-spark or backend-suffixed Spark slugs,
  • no image_generation tool in the request,
  • text-only / no image-generation capability for Spark,
  • no change to models that actually support image generation,
  • no request to enable image generation on Spark.

Additional information

Relevant code paths:

  • bundled model catalog: codex-rs/models-manager/models.json
  • longest-prefix model lookup: codex-rs/models-manager/src/manager.rs
  • fallback metadata for unknown slugs: codex-rs/models-manager/src/model_info.rs
  • default input modalities for fallback/omitted metadata: codex-rs/protocol/src/openai_models.rs
  • image-generation tool visibility gate: codex-rs/core/src/tools/spec_plan.rs

Related issue:

  • #22637 was closed as by-design because gpt-5.3-codex-spark does not support image generation. This issue is the client-side regression that now sends the unsupported image_generation tool after losing Spark-specific metadata.

Likely culprit range:

  • b7807380149d259f905dd23a7e188ba0148878b8 removed the gpt-5.3-codex bundled catalog entry as part of an earlier models.json update.
  • 3380969a29134630d56feb6218e8e8dcc5e8196d is the later models.json update present in current main.

Short implementation plan:

  1. Restore a model-catalog entry/prefix for gpt-5.3-codex-spark with Spark-specific capabilities, especially input_modalities = ["text"] and supports_image_detail_original = false.
  2. Keep gpt-5.3-codex metadata separate if it is still needed for the base family; ensure the more specific Spark prefix wins for gpt-5.3-codex-spark-* backend slugs.
  3. Add a regression test for model lookup showing gpt-5.3-codex-spark-1p-codexswic-ev3 does not use fallback metadata and resolves to text-only Spark metadata.
  4. Add/request planner coverage showing the model-visible tool surface for Spark does not contain image_generation.
  5. Longer term, consider making image-generation support an explicit model capability instead of deriving it from image input modality, since vision/image input and image generation are separate capabilities.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗