MiniMax: MiniMax M3 (batch)

The minimax/minimax-m3:batch entry was last present in the OpenRouter snapshot of 2026-09-21 and absent from the snapshots of 2026-09-23 and 2026-09-24. A live fetch on 2026-09-24 finds it still gone. The model catalog lists the standard minimax/minimax-m3 entry and no batch variant of it; …/models/minimax/minimax-m3:batch/endpoints answers 200 with "endpoints":[]; and …/model/minimax/minimax-m3:batch answers 404, Model not found: minimax/minimax-m3:batch. OpenRouter's variant guide says what that pair means: "When the resolved catalog entry does not exist … the single-model route returns 404 and the endpoints route returns 200 with "endpoints": []. Treat either as an unavailable model, not as a signal to retry with the base slug." The batch entry is gone from the router.

The model is not. MiniMax M3 is not retired: the standard entry lists thirteen endpoints when fetched on 2026-09-24, MiniMax's own among them, and the weights at MiniMaxAI/MiniMax-M3 were public and not gated on the same day. Nothing was renamed: the standard entry keeps the minimax/minimax-m3-20260531 canonical slug that the batch row carried, and no batch entry under any other MiniMax slug took its place. It was not folded into another tier either. OpenRouter's catalog simply has no batch tier for this model any more.

The provider behind the batch entry can be measured. OpenRouter's batch quickstart says "A batch runs on one provider. By default OpenRouter picks the cheapest eligible batch endpoint for the model". Of the thirteen endpoints on the standard entry on 2026-09-24, exactly one has the context length (524,288) and completion cap (471,859) that were pinned for the batch row when it went missing, and exactly one has the same sixteen supported parameters. Both are Together's. Together's input, output and cached-input rates on that listing also equal the batch row's pinned rates, but six other endpoints charge the same, so the price alone attributes nothing. The pinned values are kept in data/vanished/answered/openrouter-models--minimax-minimax-m3-batch.md.

Together has not withdrawn the model. Its serverless model list, fetched 2026-09-24, still carries MiniMaxAI/MiniMax-M3, with the same context length and the same rates. Its changelog records the model arriving on serverless on June 12, 2026 and no deprecation of it since. Its batch overview still says "Most serverless models support batch processing". Together's endpoint also still appears on OpenRouter's standard entry. So this is not the gpt-oss-20b case, where Together dated its serverless removal to September 14, the same day as the last OpenRouter snapshot that still carried the batch entry.

The reason is therefore unknown. OpenRouter does not publish per-entry reasons for withdrawing a variant, and neither MiniMax nor Together says anything about a batch tier for this model. Two facts put the removal in context without explaining it. It was part of a wave. Between the 2026-09-21 and 2026-09-23 snapshots, eight other :batch entries left the catalog with this one, including qwen/qwen3.5-9b:batch, qwen/qwen3.8-2.4t-a95b:batch and thinkingmachines/inkling:batch, whose models Together's serverless list still carries. And batch entries come back. openai/gpt-oss-20b:batch, gone from the 2026-09-21 snapshot, is listed again in the 2026-09-23 snapshot and in the live catalog on 2026-09-24.

That is why the feeds: binding stays. If minimax/minimax-m3:batch is ever a catalog entry again, it binds straight back to this page. The timeline dates the first snapshot without the batch entry. It does not record a retirement of MiniMax M3, which is live, open-weight and listed on OpenRouter under thirteen providers.