Solar Pro 3: Specs, Retirement Date and Moving to Solar Pro 4

If you are reading about Solar Pro 3 in October 2026, the most important fact is a date. Upstage's model page says the solar-pro3 alias and every version behind it will be fully deprecated on 30 October 2026 (KST), after which requests naming it return an error. Upstage recommends moving to Solar Pro 4.

So this guide is half reference and half migration plan. It covers what Solar Pro 3 was, what you lose and gain by moving, and a checklist for the time that remains.

What Solar Pro 3 was

Solar Pro 3 is a mixture-of-experts model with 102B total parameters and 12B active per forward pass, according to Upstage. It is optimised for Korean, with English and Japanese also supported for input and output, and lists chat, reasoning, structured outputs and tool calling, including parallel tool calls.

The context window is 128,000 tokens and the training data cut-off is July 2025. Upstage lists it at $0.15 per million input tokens, $0.60 per million output and $0.015 per million cached input, and OpenRouter listed the same rates at the time of writing.

The weights were never published. Upstage's Hugging Face organisation carries a Solar Pro 3 tokenizer but not the model; Upstage's recent open-weight releases are a separate line called Solar Open. That matters now, because it means there is no self-hosted fallback once the API stops answering.

Twelve billion active parameters made it cheap to serve for its size. In a mixture-of-experts model it is the active figure, not the 102B total, that sets compute per token and therefore speed and price.

Two snapshots and an alias that moved

Solar Pro 3 is a small case study in why aliases deserve attention. Upstage released solar-pro3-260126 on 26 January 2026. A second version, solar-pro3-260323, followed on 23 March with improved agentic performance and deeper reasoning, and the solar-pro3 alias moved to it. The January snapshot was deprecated on 30 April.

If you called the alias, your model changed in March without a code change. If you pinned the January snapshot, your integration broke in April. Neither is wrong, but both should have been decisions rather than surprises. Pinning model versions covers how to choose, and the same choice applies to Solar Pro 4, which also ships as a dated version behind an alias.

What changes when you move to Pro 4

Upstage released Solar Pro 4 on 6 August 2026 as its flagship for agentic work. The headline differences, all from Upstage's model pages:

• Context rises from 128K to 512K tokens, with a maximum output of 128K.
• Training cut-off moves from July 2025 to February 2026.
• List price doubles: $0.30 in, $1.20 out and $0.06 cached input per million tokens, against $0.15, $0.60 and $0.015.
• Size is not published for Pro 4, so you cannot assume the same 102B/12B shape or the same latency.
• Languages stay the same: Korean, English and Japanese.

The price change deserves a second look. At list prices cached input rises fourfold rather than doubling, so a workload built on long cached prefixes sees a bigger increase than the headline suggests. Upstage's pricing page also schedules a promotional Pro 4 rate from 20 October, $0.15 in, $0.60 out and $0.03 cached, with no end date shown; that matches Pro 3 on input and output while it lasts, but budget on the list price. If cost is the driver, Solar Mini 4 is the other migration target: Upstage lists it at $0.10 in and $0.40 out with the same 512K window. The Solar Mini 4 guide covers when the smaller model is enough, and the Solar Pro 4 guide covers the flagship.

A migration checklist for the next two weeks

Thirteen days is enough time to migrate properly if you start now. A minimal plan:

1. Find every call site. Search code and configuration for solar-pro3, including dated IDs and any reseller IDs such as upstage/solar-pro-3.
2. Collect a regression set. Pull fifty recent production requests with outputs you accepted. These are your expected results.
3. Replay on both candidates. Run the set on Pro 4 and Mini 4 with reasoning off and on. Compare against the Pro 3 outputs, not against an abstract standard.
4. Check structured output and tool calls separately. A schema that parsed every time on Pro 3 may need a prompt adjustment on a new model.
5. Recalculate cost. Use real token counts from the replay, including reasoning tokens, rather than multiplying the old bill by two.
6. Pin the new version. Use solar-pro4-260806 or solar-mini4-260922 rather than the alias, so the next update is a decision.

Where there is no single right answer, compare outputs side by side with the model names hidden, and have the person who owns the feature judge which one they would ship.

If you reach it through a reseller

Catalogues and gateways often keep listing a model after its vendor has scheduled it for retirement, because the listing is maintained separately. Do not take a live catalogue entry as evidence that Solar Pro 3 will keep working after 30 October. When the vendor endpoint goes, every route that depends on it goes too.

The broader lesson is to track deprecation notices for every model in your stack, not only the one that is about to expire. Model deprecation and migration covers how to make that routine rather than a scramble.