Publish a release from main (0.12.0) - only the pre-migration 0.1.0.dev1 is on PyPI

[thaihuynhxyz]

Main is at 0.12.0 and already ships the merged AIConfigurator packages, but the only published aisimulate artifact on either index is 0.1.0.dev1, which predates the migration. That gap has a concrete downstream cost in ai-dynamo/dynamo, described below. Asking whether a release from main can be cut.

What is published today

artifact	index	published version	repo main
aisimulate (wheel)	pypi.org and pypi.nvidia.com	0.1.0.dev1	0.12.0
aisimulate-core (crate)	crates.io	0.1.0-dev.1	0.12.0

0.1.0.dev1 declares:

Requires-Dist: aiconfigurator==0.11.0.dev20260728
Requires-Dist: aiconfigurator-core==0.11.0.dev20260728
Requires-Python: >=3.10,<3.13

Main no longer has those dependencies at all — python/aisimulate/pyproject.toml ships aiconfigurator and aiconfigurator_core itself via [tool.maturin] python-packages.

How this looks like a timing accident, not a mistake

when	what
2026-08-14 08:09	aisimulate 0.1.0.dev1 wheels uploaded to PyPI
2026-08-17 21:33	40bc989a9 migrates full AIConfigurator into AISimulate
2026-08-19 21:40	dynamo 825ae4233 (#13478) starts consuming the published wheel

The wheel was cut three days before the migration, and dynamo adopted it two days after. So dynamo is consuming the last pre-migration artifact, and it has simply not been re-cut since. Nothing here looks wrong on either side — the artifact is just older than the code.

Why it matters downstream

Because that wheel pins the July AIC pre-release exactly, every dynamo nightly built from main installs aiconfigurator-core 0.11.0.dev20260728.

We measured a behavioral difference between that pre-release and the 0.11.0 release, in the SLA planner's forward-pass readiness gate. On the same 14 forward-pass observations:

• aiconfigurator-core 0.11.0.dev20260728 reports readiness=insufficient_data
• aiconfigurator-core 0.11.0 reports readiness=ready

On a live aggregated deployment that difference is the whole feature: with the pre-release the planner's load-based scaling never arms. Shadowing 0.11.0 onto the same image with PYTHONPATH opens the gate and the planner starts emitting scaling decisions, which localizes the behavior to the core version rather than to our deployment.

Dynamo cannot fix this on its own side. Bumping its AIC pin to 0.11.0 is unsatisfiable while aisimulate==0.1.0.dev1 is a hard dependency:

No solution found when resolving dependencies:
  Because aisimulate==0.1.0.dev1 depends on aiconfigurator==0.11.0.dev20260728
  and you require aiconfigurator==0.11.0, we can conclude that your requirements
  and aisimulate==0.1.0.dev1 are incompatible.

And there is no other aisimulate release to move to. Related dynamo PR (held): ai-dynamo/dynamo#13721

The ask

Cut and publish a release from main (0.12.0). Since main is synced to AIC parity through 095f58a (#31) and ai-dynamo/aiconfigurator main is 0.11.0, that release should carry the newer gate behavior.

Once it is published, dynamo's side is a small migration rather than a pin bump: drop the standalone aiconfigurator / aiconfigurator-core requirements and take both packages from aisimulate, since the wheel now provides them. Happy to open that dynamo PR.

Two questions on scope:

1. Is aisimulate-core on crates.io also expected to move to 0.12.0? Dynamo's lib/bindings/python/Cargo.toml currently pins the aiconfigurator-core crate, so the Rust half of the migration needs a published crate too.
2. Is 0.12.0 the intended next public version, or is the jump from 0.1.x still under discussion? Asking so the dynamo-side pin targets the right number.