DEV Community: Ryan Cole

DeepSeek V4.1 Flash vs V4 Pro: moving production traffic without breaking your budget

Ryan Cole — Fri, 09 Oct 2026 07:41:56 +0000

The pricing page now splits DeepSeek's lineup into two live routes, deepseek-flash and deepseek-v4-pro, and they are not aliases for each other. One serves V4.1 Flash, the other serves V4-Pro-0813. Different prices, different concurrency ceilings, different vision support. If you are wiring up a new integration, pick the ID that matches the workload instead of trusting whatever the old alias resolved to last quarter.

Here is what I look at before moving traffic.

Spec comparison: the architecture flipped

V4 Pro is a very large sparse MoE. V4.1 Flash is an asymmetric causal encoder-decoder MoE, where input processing activates fewer parameters than output generation. That split is deliberate: prefill and decode have different compute profiles, so there is no reason to run both stages through the same active-parameter budget.

Spec	V4.1 Flash	V4 Pro 0813
Architecture	Causal encoder-decoder MoE	Sparse MoE
Total parameters	552B backbone; Hugging Face lists 763B model size	1.6T backbone; Hugging Face lists about 1.7T model size
Active parameters	8B input / 16B output	49B per token
Context window	1M tokens	1M tokens
Max output	384K tokens	384K tokens
Thinking and non-thinking modes	Supported	Supported
Native image understanding	Supported	Not supported
Documented concurrency	2,500	500 on the current configuration
API status	Active as `deepseek-flash`	Active as `deepseek-v4-pro` (V4-Pro-0813)

Two numbers people keep conflating

The 552B in DeepSeek's model card counts backbone parameters. The 763B on Hugging Face is model size, a different accounting scope. Do not treat them as interchangeable totals in a capacity plan.

Similarly, the V4.1 Flash model card recommends max_tokens ≥ 256K for local inference. The API pricing page states a 384K maximum output for both models. A recommended local setting is not an enforced API ceiling.

Benchmarks: the win is execution-heavy, not universal

The published table favors Flash almost everywhere that involves running code, driving a terminal, or chaining tools. Percentage deltas below are my own arithmetic on the published scores; I skip them where the metric is a rating.

Benchmark	V4.1 Flash	V4 Pro 0813	Delta
Terminal-Bench 2.1	90.6	87.9	+2.7 points, +3.1%
Terminal-Bench 3.0	30.0	11.8	+18.2 points, +154.2%
Terminal-Bench 4.0	31.2	12.4	+18.8 points, +151.6%
DeepSWE v1.1	74.2	62.7	+11.5 points, +18.3%
ProgramBench	20.3	15.5	+4.8 points, +31.0%
NL2Repo-Bench	64.0	61.5	+2.5 points, +4.1%
CyberGym	88.1	83.3	+4.8 points, +5.8%
HLE with tools	63.9	60.0	+3.9 points, +6.5%
Automation-Bench	54.8	43.2	+11.6 points, +26.9%
Agents' Last Exam	31.8	25.7	+6.1 points, +23.7%
Codeforces rating	3,471	3,348	+123 rating points
GPQA Diamond	90.9	92.4	-1.5 points
HLE without tools	36.8 (39.1 on text subset)	42.7 on text subset	-3.6 points on the comparable text subset

Read that as two different products rather than a ranking. Flash owns terminal work, repo-level coding, automation, security execution, and tool-augmented reasoning. Pro keeps its edge on closed-book reasoning, specifically GPQA Diamond and HLE without tools. Judge your workload by task mix, not by a single headline number.

Why the serving cost drops

Asymmetric activation

8B active for input, 16B for output, against 49B per token for V4 Pro. Prefill gets cheap, decode keeps enough capacity to stay useful.

KV cache

DeepSeek reports V4.1 Flash uses one quarter of the HBM and one eighth of the SSD of the previous generation's KV cache. The published chart puts global KV cache at 890 bytes per token versus 3,514 bytes for V4 Flash. Long-context services feel this immediately, because that footprint is what limits how many concurrent sessions fit on a node.

Vision and concurrency

Native image understanding plus a documented concurrency of 2,500, five times the current V4 Pro figure of 500. If you are building screenshot-driven agents, document extraction, or visual troubleshooting, this is the part that changes the design, not the benchmark table.

Pricing per 1M tokens

Off-peak / peak, from the current official schedule:

Route	Cache-hit input	Cache-miss input	Output
V4.1 Flash	$0.003 / $0.006	$0.15 / $0.30	$0.60 / $1.20
V4 Pro	$0.022 / $0.044	$0.66 / $1.32	$1.98 / $3.96

Roughly 4.4x on input and 3.3x on output. Prices move, so pin your budget model to the live page rather than to this table.

Migration

Use explicit model IDs

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_API_KEY",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-flash",  # or "deepseek-v4-pro"
    messages=[{"role": "user", "content": "Review this migration plan."}],
)

print(response.choices[0].message.content)

deepseek-v4-flash and deepseek-v4-flash-vision-exp still resolve to V4.1 Flash and bill at the new Flash price, but explicit naming keeps your dashboards and future rollbacks auditable. Use deepseek-v4-pro only when you intend to hit V4-Pro-0813.

If you already route through a unified multi-model endpoint such as CometAPI, the model string is the only switch to flip, though the evaluation work below still applies.

Re-evaluate, do not just smoke-test

Run representative prompts in both thinking and non-thinking modes. Compare task success, token counts, and latency, not just HTTP 200.
Retest tool schemas, JSON output, Responses API behavior, prefix completion, and FIM where you depend on them.
Add image-input tests if the product will use native vision.
Re-baseline budgets at both peak and off-peak rates. Do not carry V4 Pro assumptions forward.
Track prompt-cache hit rate. At scale it dominates input cost.

Record what resolved

The deepseek-v4-pro route currently selects V4-Pro-0813. Log the resolved version, evaluation date, prompt set, and pricing window alongside your results so a future routing change does not invalidate the comparison silently.

Workload routing cheat sheet

Workload	Pick	Why
Coding agents, repo maintenance	V4.1 Flash	DeepSWE, ProgramBench, NL2Repo, terminal scores
Tool-driven automation	V4.1 Flash	Automation-Bench, HLE with tools, agent scores
Image-aware assistants	V4.1 Flash	Native image understanding
High-throughput or cost-sensitive serving	V4.1 Flash	2,500 concurrency, much lower token prices
Historical V4 Pro reproduction	V4 Pro	The route currently identifies V4-Pro-0813
Pure closed-book reasoning	Test on your domain data	Pro stays ahead on GPQA Diamond and HLE without tools

Traps I have hit

Endpoint compatibility is not output compatibility. Reasoning paths, tool selection, token usage, and formatting all shift. Re-run production evals before trusting old thresholds.
The two model IDs are not aliases. Do not swap them by config drift.
Legacy V4 Flash IDs still work and bill at the new rate, so a forgotten environment variable will quietly move you to V4.1 Flash. That is usually what you want, but you should know it happened.
Concurrency limits are documented, not guaranteed by your account tier. Check before designing a 2,500-way queue.

Originally published at cometapi.com

FLUX 3 video over an async HTTP API: requests, polling, keyframes, and real pricing

Ryan Cole — Fri, 09 Oct 2026 07:23:09 +0000

Status check: this is GA now, not early access

BFL closed out the July Early Access phase. The first text-to-video and image-to-video release went generally available through the BFL API and selected partners on August 4, 2026. The production model ID flux-3 appeared in the gateway's Video API format on August 13, 2026. I verified availability, field names and prices on September 24, 2026.

Those facts move, so treat the BFL release announcement and the live model page as the source of truth instead of this post. Early coverage of the July application-based rollout is still useful for launch history, but it does not describe a callable endpoint. What follows is the operational part: create, poll, download, and the schema traps in between.

What the model does

FLUX 3 is BFL's multimodal family covering video, audio, images, and action-related prediction. The video release handles text-to-video, image-to-video, and video continuation behind one provider-native endpoint.

The parts that matter for integration work:

Up to 20 seconds at 24 fps, HD or FHD
Synchronized audio, on by default
Multilingual speech with lip-sync
Multiple shots inside a single generation
Up to ten pinned keyframes for image-to-video control

Specs

Spec	BFL native	Gateway
Workflows	T2V, I2V, video continuation	T2V and I2V listed
Max duration	5 to 20 s T2V/I2V; 5 to 15 s V2V	check live quickstart values
Frame rate	24 fps	provider output
Resolution	rHD native, FHD via video upsampler; no 4K/UHD listed for FLUX 3 Video	720p and 1080p pricing
Native audio	yes, default on	follows the active integration
Image control	1 to 10 keyframes	verify reference-image mapping
Aspect ratios	21:9, 2:1, 16:9, 4:3, 1:1, 3:4, 9:16	quickstart uses explicit sizes like 1280x720
Invocation	async	create, poll, download
Model ID	n/a	`flux-3`

One clarification that keeps circulating: the "up to 4MP" spec belongs to the FLUX.2 image models. FLUX 3 Video does not list 4K/UHD output.

The three-call lifecycle

Operation	Request	Returns
Create	`POST https://api.cometapi.com/v1/videos`	task ID + queued status
Poll	`GET https://api.cometapi.com/v1/videos/{task_id}`	status and progress
Download	`GET https://api.cometapi.com/v1/videos/{task_id}/content`	the MP4

Set the key in a backend env var. macOS/Linux:

export COMETAPI_KEY="your_api_key"

Windows PowerShell:

$env:COMETAPI_KEY="your_api_key"

Create a five-second 720p clip with a multipart request:

curl https://api.cometapi.com/v1/videos \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -F "model=flux-3" \
  -F "prompt=A paper boat glides across a still pond in soft morning light" \
  -F "seconds=5" \
  -F "size=1280x720"

The response starts a job, nothing more:

{
  "id": "video_task_id",
  "status": "queued"
}

Persist that ID next to your own job or user record before you poll anything. A worker restart should never cost a user a second billed generation. Then poll:

curl https://api.cometapi.com/v1/videos/{task_id} \
  -H "Authorization: Bearer $COMETAPI_KEY"

Ten seconds is a sane starting interval. Terminal success states I've seen: completed, succeeded, success. Terminal failures: failed, failure, cancelled, canceled.

Download, then move the file into your own bucket rather than pinning a provider URL as the permanent asset:

curl https://api.cometapi.com/v1/videos/{task_id}/content \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  --output flux3_output.mp4

Complete Python job runner

This creates, persists, polls, checks failure states, validates the MP4 signature, and writes to disk.

import os
import time
from pathlib import Path

import requests

api_key = os.environ["COMETAPI_KEY"]
base_url = "https://api.cometapi.com"
headers = {"Authorization": f"Bearer {api_key}"}

response = requests.post(
    f"{base_url}/v1/videos",
    headers=headers,
    files={
        "model": (None, "flux-3"),
        "prompt": (
            None,
            "A product bottle rotates slowly on wet black stone, "
            "soft rim lighting, macro lens, realistic reflections.",
        ),
        "seconds": (None, "5"),
        "size": (None, "1280x720"),
    },
    timeout=120,
)
response.raise_for_status()

task = response.json()
data = task.get("data") or {}
task_id = (
    task.get("id")
    or task.get("task_id")
    or data.get("id")
    or data.get("task_id")
)
if not task_id:
    raise RuntimeError(f"Create response has no task ID: {task}")

while True:
    response = requests.get(
        f"{base_url}/v1/videos/{task_id}",
        headers=headers,
        timeout=60,
    )
    response.raise_for_status()
    task = response.json()
    data = task.get("data") or {}
    status = str(task.get("status") or data.get("status") or "").lower()
    progress = task.get("progress") or data.get("progress") or "unknown"
    print(f"Status: {status or 'unknown'}; progress: {progress}")

    if status in {"failed", "failure", "cancelled", "canceled"}:
        raise RuntimeError(f"Video generation failed: {task}")
    if status in {"completed", "succeeded", "success"} or progress == "100%":
        break
    time.sleep(10)

response = requests.get(
    f"{base_url}/v1/videos/{task_id}/content",
    headers=headers,
    timeout=300,
)
response.raise_for_status()
video = response.content

if len(video) &lt; 12 or video[4:8] != b"ftyp":
    raise RuntimeError("Content response is not a non-empty MP4 file")

output_dir = Path("output")
output_dir.mkdir(parents=True, exist_ok=True)
output_path = output_dir / f"{task_id}.mp4"
output_path.write_bytes(video)
print(f"Saved: {output_path} ({len(video)} bytes)")

Image-to-video and keyframes: two schemas, not one

I2V is listed as supported through the gateway, but the current public sample only demonstrates text-to-video. Do not assume a reference-image field copied from another model's docs will be accepted unchanged. Check the live gateway reference before you ship that path.

BFL's native API is explicit: I2V uses mode i2v plus the keyframes field. One image pins the start frame, two pin start and end, and up to ten timed images storyboard a continuous clip.

curl -X POST https://api.bfl.ai/v1/flux-3-video \
  -H "x-key: $BFL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "i2v",
    "prompt": "They sprint through the lantern-lit alley as the camera tracks behind them.",
    "keyframes": [
      [0, "data:image/png;base64,"],
      [8, "data:image/png;base64,"]
    ],
    "duration": 8
  }'

Keep native and gateway parameters in separate adapters. Mixing them is the most common failure I see in review. Native fields are mode, keyframes, start_video, resolution, draft; the verified gateway sample uses model, prompt, seconds, size.

Parameter reference

Parameter	API	Controls	Guidance
`model`	gateway	model selection	`flux-3`
`prompt`	both	scene, action, camera, audio	describe change over time
`seconds`	gateway	clip length	start at 5 to 8 s while tuning
`size`	gateway	dimensions	1280x720 for cheap iteration
`mode`	BFL native	t2v / i2v / v2v / draft_enhance	do not send unless mapped
`duration`	BFL native	5 to 20 s T2V/I2V, 5 to 15 s V2V	`auto` supported
`resolution`	BFL native	`hd` or `fhd`	FHD finishes through the upsampler
`generate_audio`	BFL native	synchronized audio	defaults to true
`draft`	BFL native	fast preview	lower-cost creative iteration

Prompting: write a shot list, not a mood

BFL's video prompting guide asks for clear direction on subject and action, camera, scene and atmosphere, motion quality, and continuity. Audio-led scenes need dialogue, voice, sound effects, and ambience spelled out.

The structure I reuse:

Subject + Environment + Action + Camera + Lighting
+ Dialogue/Voice + Sound Effects + Ambience + Constraints

Cinematic:

A lone cyclist rides through a rain-soaked neon street at midnight.
The camera begins low beside the rear wheel, then rises into a smooth tracking shot.
Reflections stretch across wet asphalt under moving cyan and magenta light.
Audio: steady rainfall, chain noise, distant traffic, no music, no dialogue.
Keep the same rider, bicycle, jacket, and weather throughout the shot.

Product:

A premium stainless-steel espresso machine stands on a dark stone counter.
Begin with a macro close-up of water droplets on the metal housing.
Orbit clockwise as the machine brews; steam catches warm side light.
Finish on a clean three-quarter hero angle with the cup in the foreground.
Audio: pump vibration, steam hiss, ceramic contact, quiet cafe ambience.
Do not change the product shape, logo placement, material, or color.

Dialogue with native audio:

A young chef works alone in a compact Tokyo ramen shop at night.
Start close on boiling broth, then pull back as the chef sets down a bowl.
Warm tungsten lighting, natural reflections, documentary handheld motion.
The chef quietly says in Japanese: 「お待たせしました。」
Audio: bubbling broth, soft rain outside, distant street traffic.
No subtitles and no background music.

"Make a cinematic ramen shop video" leaves motion, framing, sound and continuity undefined. You cannot debug that.

Pricing

BFL prices by workflow. T2V and I2V full renders run $0.17/s HD and $0.29/s FHD, with HD Draft Mode at $0.06/s. Video continuation is $0.43/s HD and $0.54/s FHD, HD drafts at $0.12/s. The gateway lists flux-3 at $0.136/s for 720p and $0.232/s for 1080p. Re-check live pricing before any large batch.

Workflow	HD/720p	FHD/1080p	Draft	5 s full	10 s full
BFL T2V	$0.17/s	$0.29/s	$0.06/s (HD)	$0.85 / $1.45	$1.70 / $2.90
BFL I2V	$0.17/s	$0.29/s	$0.06/s (HD)	$0.85 / $1.45	$1.70 / $2.90
BFL V2V continuation	$0.43/s	$0.54/s	$0.12/s (HD)	$2.15 / $2.70	$4.30 / $5.40
Gateway `flux-3`	$0.136/s	$0.232/s	not listed	$0.68 / $1.16	$1.36 / $2.32

In the last two columns the first figure is HD/720p and the second is FHD/1080p.

Cutting iteration cost

Prototype at 720p, then promote only a selected prompt to 1080p.
Five-second clips are enough to validate composition, motion and prompt interpretation.
Change one major variable per run.
On the native API, use Draft Mode before a full-quality render.
Store the winning prompt and reference decisions in your own metadata.

FLUX 3 vs Wan 3.0 vs Seedance 2.5

Pick by workflow, not by a leaderboard. This is also where a unified endpoint earns its keep: keeping flux-3, Wan 3.0 and Seedance 2.5 behind one job pipeline (I route through CometAPI for exactly that) means a model swap is a config change rather than a rewrite.

Dimension	FLUX 3	Wan 3.0	Seedance 2.5
Max clip	up to 20 s T2V/I2V	up to 30 s	up to 30 s
Synchronized audio	yes	yes	yes
T2V / I2V	yes / yes	yes / yes	yes / yes
Reference strategy	up to 10 native keyframes	broad multimodal, Omni-Reference	large multimodal reference capacity
Continuation/editing	native BFL v2v	long-form and editing	extension and editing
Strength	motion logic, multi-shot, synced A/V	input breadth, 30 s generation	long storytelling, reference-heavy control
Gateway starting price	$0.136/s	$0.04/s	$0.0824/s
Fits	cinematic or realistic A/V shots	all-in-one multimodal pipelines	longer, identity-controlled storytelling

Starting prices are not apples-to-apples across resolutions, so budget from each live model page's resolution table.

Production notes

Persist async jobs. Save the task ID at submission time. Worker retries must not re-bill work.

Do not poll tightly. Around ten seconds unless the live docs say otherwise. One-second polling adds load without improving perceived latency.

Validate the download. Check length and the MP4 ftyp signature before marking an asset ready. A 200 does not prove you got a video.

Separate native and gateway schemas. Distinct adapters stop native-only fields from leaking into gateway calls.

Log the full failure context. HTTP status, response body, task ID, model ID, prompt version, size, duration, internal job ID. Redact the key.

Run a fixed evaluation set. 10 to 30 prompts covering camera motion, people, products, typography, dialogue, high-motion scenes and required aspect ratios. Re-run it on every model or integration change, and repeat important prompts, because generation is stochastic.

Vendor numbers worth knowing

BFL reports a text-to-video Elo of 1135 in its all-vs-all human-preference evaluation, and a tie with Seedance 2.0 on image-to-video preference. Useful positioning, but vendor-run preference testing measures perceived output quality, not queue reliability, gateway latency, cost consistency, or generation-to-generation stability. Your own prompt set is the only benchmark that predicts your production.

FAQ

Model ID? flux-3.

Endpoints? POST /v1/videos, then GET /v1/videos/{task_id} and GET /v1/videos/{task_id}/content.

Synchronous? No. Submit, persist, poll, download.

Max duration? 5 to 20 s for T2V/I2V, 5 to 15 s for continuation.

Audio? Yes, synchronized and enabled by default in the native API.

Can I send BFL keyframes through the gateway unchanged? Do not assume it. The schemas differ. Verify the current quickstart first.

Cost of five seconds? $0.68 at 720p or $1.16 at 1080p at current gateway rates.

What I would ship first

Short 720p text-to-video request, durable task ID, conservative polling, download with signature validation, then prompt templates, object storage, retry logic and a repeatable evaluation set. Add keyframes and continuation once I2V field mapping is confirmed against the live reference.

Originally published at cometapi.com

MiMo-V2.5 in practice: 15B active params, native multimodal input, and when Pro is actually worth 3

Ryan Cole — Fri, 09 Oct 2026 05:54:41 +0000

I've been running Xiaomi's MiMo-V2.5 through coding and document-analysis workloads for a while now, and the interesting thing isn't the benchmark sheet — it's that the standard model and the Pro model are optimized for genuinely different jobs. The standard variant is multimodal-first and cheap per token; Pro is text-only, a trillion parameters, and roughly 3.1× the price at Xiaomi's published rates. Picking between them is a routing decision, not a quality decision.

Here's what actually matters if you're about to wire one of these into a production path.

Architecture: what 310B/15B gets you

MiMo-V2.5 is a sparse MoE with 310B total parameters and ~15B active per token. The router picks 8 of 256 experts per token, so you get access to a much larger parameter pool than a plain 15B dense model without paying the full compute bill.

That does not mean self-hosting is cheap. You still need to store and serve all 310B weights, and expert routing plus interconnect bandwidth become the real constraints. Active params are a compute figure, not a memory figure.

The backbone is 48 layers: 1 dense plus 47 MoE. Attention interleaves sliding-window and global layers at a 5:1 ratio — 39 SWA layers with a 128-token window, 9 global layers. Xiaomi reports nearly a 6× KV-cache reduction versus an all-global design. That's the mechanism that makes the 1M context affordable, not a bonus.

On the perception side there's a 729M ViT (28 layers) for image/video and a 261M transformer (24 layers) for audio, both projected into the language backbone. Three Multi-Token Prediction modules (~329M params combined) support speculative decoding and RL efficiency. Training ran on roughly 48T tokens with context progressively extended to 1M in post-training.

Weights are MIT-licensed, public beta dated April 23, 2026.

Spec sheet

Item	Value
Total / active params	310B / 15B
Layers / routed experts	48 (1 dense + 47 MoE) / 256, 8 active
Attention	39 SWA (128-token window) + 9 global
Context / max output	1M / 128K tokens
I/O	text, image, video, audio → text
Encoders	729M ViT; 261M audio transformer
MTP	3 modules, ~329M params
Training	~48T tokens
API surface	tools, web search, streaming, structured output, context caching
Published rate limits	100 RPM / 10M TPM
License	MIT

Rate limits are provider-level and will differ by route and account tier.

Benchmarks: tool use is the strong signal

These are publisher-reported, so treat them as directional. Nothing here guarantees behavior on your repo or your media formats.

Coding and agents

Benchmark	Score
MiMo Coding Bench	71.8
Claw-Eval Text	62.3
Terminal-Bench 2.0	65.8
SWE-Bench Pro	56.1
Claw-Eval Multi-Turn	63.2
ResearchClawBench	16.91

The 65.8 on Terminal-Bench 2.0 is the number I'd weight most for terminal-driven agents, and 56.1 on SWE-Bench Pro suggests real repository-level ability rather than autocomplete. ResearchClawBench at 16.91 is the outlier — if your workload is evidence gathering and citation, test that path separately, because this model is not obviously good at it.

Multimodal

Benchmark	Score
CharXiv RQ	81.0
MMMU-Pro	77.9
HR-Bench 4K	88.5
OmniDocBench	87.2
Claw-Eval Multimodal	23.8
Video-MME	87.7
DailyOmni	83.5
VideoHolmes	64.0

Document and high-res image understanding are clearly the strength. Claw-Eval Multimodal at 23.8 versus 87.2 on OmniDocBench is the gap that matters: perceiving media and acting on it through tools are different capabilities, and the second one needs end-to-end testing on your actual stack.

Standard vs Pro

	MiMo-V2.5	MiMo-V2.5-Pro
Total params	310B	1.02T
Active params	15B	42B
Layers / routed experts	48 / 256	70 / 384
Context ceiling	1M	1M
API max output	128K	128K
Native input	text, image, video, audio	text
SWE-Bench Pro	56.1	57.2
Terminal-Bench 2.0	65.8	68.4

Pro leads by 1.1 points on SWE-Bench Pro and 2.6 on Terminal-Bench 2.0 — a modest margin on the only two tests they share. Pro spends ~2.8× the active parameters to get there and drops multimodal input entirely. If media is a first-class input for you, Pro isn't a candidate at all.

Both model cards list 1M context and Xiaomi's API pages list 128K max output, but usable limits vary by endpoint, account, and request format.

Pricing

Per MTok	Standard (official)	Pro (official)
Input, cache miss	$0.14	$0.435
Output	$0.28	$0.87
Input, cache hit	$0.0028	$0.0036

Pro is ~3.1× standard on both uncached input and output. If you're routing across multiple vendors and want one key and one base URL, CometAPI lists both at 20% below the official uncached pairs ($0.112/$0.224 standard, $0.348/$0.696 Pro) — the relative gap between variants stays the same, so it doesn't change the routing math, only the absolute bill.

Price per token isn't cost per completed task. Tool retries, context bloat, output length, and failed-run recovery dominate real spend. Sample your own workload before you pick a default.

Calling it

Standard OpenAI-compatible client, nothing exotic:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com/v1",
    max_retries=0,
)

response = client.chat.completions.create(
    model="mimo-v2.5",
    max_tokens=256,
    messages=[
        {
            "role": "user",
            "content": "Summarize the main findings in this technical report.",
        }
    ],
)

print(response.choices[0].message.content)

Verify the live endpoint and request schema before deploying — model IDs on third-party gateways move independently of the upstream platform.

Where I'd put it

Good fits: multimodal agents that mix screenshots, documents, video, audio, and tool calls; long-document analysis over repos, contracts, logs, and support history; media summarization and chart interpretation; coding and terminal agents; high-volume automation where sparse activation and low token price both matter.

Bad fits: anything requiring image, audio, or video generation — output is text only. And a 1M context ceiling is capacity, not uniform retrieval accuracy across the window.

Routing table

Signal	Start with	Switch when
Image/video/audio is a first-class input	Standard	Only if multimodal preprocessing is acceptable
Heavy document or mixed-media volume	Standard	Pro only if reasoning failures dominate cost
Difficult repository engineering	Test both	Pro if completion gain beats 3.1× unit cost
Long autonomous terminal runs	Pro	Back to standard if the gain isn't measurable
High-volume routine automation	Standard	Escalate failed/high-value tasks only

Default to standard, route only hard text-first coding and long-horizon agent work to Pro.

The deprecation clock

Xiaomi has announced that the official mimo-v2.5 and mimo-v2.5-pro API model names will be deprecated at 10:00 Beijing time on October 21, 2026, with no automatic replacement (deprecation notice). That applies to Xiaomi's own platform — check your gateway separately. Plan the migration and confirm the live route before you ship anything load-bearing against these IDs.

Quick answers

Open source? Yes, MIT — commercial use, modification, fine-tuning, redistribution.

Params? 310B total, 15B active per token.

Multimodal input? Standard: text, image, video, audio → text. Pro's official spec lists text input.

Context? Up to 1M on both model cards; Xiaomi's current API pages list 128K max output for both. Verify the deployed route.

Coding agents? Pro reports higher shared benchmark scores, but the margin is small — test on your repo and compare task completion, latency, and total cost.

Multimodal agents? Standard, without question — Pro is text-only.

Originally published at cometapi.com

Qwen3.8-Omni-Flash: Field Notes on a 1M-Context Omnimodal Endpoint

Ryan Cole — Fri, 09 Oct 2026 05:22:15 +0000

I've been wiring qwen3.8-omni-flash into a couple of internal tools over the last week — mostly meeting/recording triage and long-video extraction. Short version: it's the first model I've used where I don't have to run a separate ASR pass, a separate frame sampler, and then a text model to reconcile them. You hand it audio, video, images and text in one message and get text back.

Below is what I actually had to figure out: endpoints, the parts of the API that behave unexpectedly, and where this thing is worth its token cost.

The spec sheet that actually constrains your design

Field	Value
Model ID	`qwen3.8-omni-flash`
Input	text, image, audio, video
Output	text
Context window	1M tokens
Max input (non-thinking)	991,808 tokens
Max input (thinking)	983,616 tokens
Max output	131,072 tokens
Thinking	on by default
`reasoning_effort`	`low` / `medium` / `xhigh`
Function calling	yes
Web search	yes
Context caching	yes
Multichannel audio	yes
API surfaces	Chat Completions / Responses

Note the two max-input numbers. Thinking mode eats ~8k tokens of your budget before you've sent anything, so if you're near the 1M edge on a long video, that gap matters when you decide whether to enable deep reasoning.

Keys, regions, and why your base URL is weird

Five minutes of head-scratching saved: the API key and the endpoint have to belong to the same region. Supported regions are Beijing, Singapore, Hong Kong, Tokyo, Frankfurt and Virginia. A Singapore key against a Virginia workspace domain is an auth failure, not a helpful error.

New integrations should use the workspace-scoped domains rather than the legacy DashScope hostnames. The Singapore shape is:

https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1

Swap {WorkspaceId} for whatever the Model Studio console shows you.

# bash
export DASHSCOPE_API_KEY="your-api-key"

# powershell
$env:DASHSCOPE_API_KEY="your-api-key"

Alibaba exposes an OpenAI-compatible surface, so the stock Python SDK works. No vendor SDK required.

pip install -U openai

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DASHSCOPE_API_KEY"],
    base_url="https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1",
)

response = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=[{
        "role": "user",
        "content": "Summarize the advantages of native omnimodal models.",
    }],
)

print(response.choices[0].message.content)

If you'd rather skip the SDK while you're poking at it:

curl "https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1/chat/completions" \
  -H "Authorization: Bearer $DASHSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-omni-flash",
    "messages": [{
      "role": "user",
      "content": "Explain multimodal agent workflows in three bullet points."
    }]
  }'

Images: typed content blocks

Nothing surprising here — same shape as any VL endpoint. Useful for dashboards, screenshots, document QA, visual diffing.

response = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=[{
        "role": "user",
        "content": [
            {
                "type": "image_url",
                "image_url": {"url": "https://example.com/dashboard.jpg"},
            },
            {
                "type": "text",
                "text": "Identify the main metrics and summarize any anomalies.",
            },
        ],
    }],
)

print(response.choices[0].message.content)

Audio: don't just ask for a transcript

If you only wanted a transcript, you'd use a dedicated ASR model and pay less. Where this wins is when the audio needs interpretation — meeting summarization, speech understanding, sound-event analysis, or joint audio-visual reasoning.

For long recordings, ask for structure. A flat "summarize this" gives you mush on a 90-minute call. Ask for speakers, decisions, action items, open questions, and timestamps.

response = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=[{
        "role": "user",
        "content": [
            {
                "type": "input_audio",
                "input_audio": {
                    "data": "https://example.com/meeting.wav",
                    "format": "wav",
                },
            },
            {
                "type": "text",
                "text": "Summarize this meeting and extract action items.",
            },
        ],
    }],
)

print(response.choices[0].message.content)

Multichannel / spatial audio is opt-in. If channel separation is part of the signal you care about — say, separating two mics in a room — you need this flag, otherwise the channels get folded and spatial cues are lost.

response = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=messages,
    extra_body={"use_multichannel": True},
)

Video: your prompt is the entire game

The single biggest quality lever I've found. "Describe this video" burns context on irrelevant frames and returns a vague paragraph. A structured, evidence-oriented prompt changes the output category entirely.

Analyze this product demonstration video.

Return:
1. A chronological summary.
2. Important visual steps with timestamps.
3. Spoken instructions.
4. Product names or UI text visible on screen.
5. Any discrepancy between the narration and the demonstrated action.

video_prompt = """..."""  # the block above

response = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=[{
        "role": "user",
        "content": [
            {
                "type": "video_url",
                "video_url": {"url": "https://example.com/demo.mp4"},
            },
            {
                "type": "text",
                "text": video_prompt,
            },
        ],
    }],
)

The vendor's launch write-up reports that agentic long-video understanding — where the model decides which segments are worth spending compute on — cut token usage per query from 145,736 to 79,117 in their OmniVideoBench setup (a ~45.7% reduction), with OmniVideoBench moving from 63.4 to 67.8 in agentic mode. That's vendor-reported on their own harness, so treat it as "plausible direction" rather than a number you'll get back. Still, the underlying lesson holds regardless of the exact figure: narrowing the question and demanding timestamped evidence is what saves you money.

Set `reasoning_effort` explicitly. Every time.

Thinking is on by default, and xhigh is documented as the default effort. That means the naive call — the one you write to test the key works — is already at maximum reasoning depth. For a high-volume extraction pipeline, that's a silent cost multiplier.

`reasoning_effort`	Where I use it
`low`	extraction, classification, trivial summaries
`medium`	routine analysis, most production paths
`xhigh`	hard multimodal reasoning, agents, ambiguous evidence

response = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=[{
        "role": "user",
        "content": "Analyze the causes of the inconsistencies in this report.",
    }],
    reasoning_effort="medium",
)

The OpenAI-compatible layer also accepts mapped values, but don't assume every OpenAI reasoning string maps to a distinct behaviour here. Read the model-specific doc.

Streaming

Standard Chat Completions deltas. Guard against the empty-choices chunks — you'll hit them.

stream = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=[{
        "role": "user",
        "content": "Analyze this multimodal task and propose a workflow.",
    }],
    reasoning_effort="medium",
    stream=True,
)

for chunk in stream:
    if not chunk.choices:
        continue
    delta = chunk.choices[0].delta
    if delta.content:
        print(delta.content, end="", flush=True)

The parameters worth remembering

Parameter	What it does	Notes
`model`	model selection	`qwen3.8-omni-flash`
`messages`	conversation + media	typed content blocks for media
`stream`	incremental output	use for anything interactive
`reasoning_effort`	reasoning depth	set `low`/`medium`/`xhigh` explicitly
`enable_thinking`	thinking toggle	prefer `reasoning_effort` here; this is non-standard, verify compatibility
`preserve_thinking`	retains reasoning state across turns	pass via `extra_body`; retained reasoning inflates input tokens
`use_multichannel`	spatial audio	only when channel info matters
`max_tokens`	output bound	always set in production

preserve_thinking is the one that bites. Carrying reasoning state forward improves coherence on multi-turn agent loops, but every retained token is an input token you're paying for on every subsequent turn.

Failure modes I've actually hit

Symptom	Cause	Fix
401	bad/missing key	check env var; check key region
Model unavailable	region/provider/rollout mismatch	verify availability in your region + account
Media can't be fetched	URL not reachable from the service	use a publicly reachable source
Slow responses	`xhigh` on a trivial task	drop to `medium` or `low`
Token cost creep	large media or retained history	trim context; audit `preserve_thinking`
Model ignores stereo placement	multichannel off	`use_multichannel: True`
Vague video output	prompt too broad	demand events, timestamps, output format
Runaway response length	no output constraints	set `max_tokens` and a schema

Add the usual production scaffolding on top: request timeouts, exponential-backoff retries, usage logging per request, structured-output validation, and — this one matters more than usual — do not feed arbitrary user-supplied media URLs into the model without validating scheme and host. You're handing a remote fetch to a third party.

Where this model earns its keep

Use it when the relationship between modalities is the thing you're asking about. Not merely because your app happens to touch several file types.

Good fits: meeting intelligence, long-form video analysis, media search, multimodal research agents, training-video extraction, support-recording analysis, and any workflow where audio-visual evidence triggers a tool call.

Bad fits: bulk transcription (cheaper ASR exists), single-image classification (a VL model is cheaper), anything where you already know the answer is in the text.

Cost and latency, in practice

The wins come from media volume and reasoning depth — not from shaving words off your system prompt. Concretely:

low for extraction and classification, medium for routine analysis, xhigh only when the task genuinely needs it.
For long video, narrow the question and demand timestamped evidence rather than asking for a full description.
Use context caching for repeated large contexts.
Stop carrying prior reasoning and prior media forward once they stop contributing to the next turn.

FAQ, compressed

Images? Yes, alongside text, audio and video.
Audio input? Yes, native — transcription, meeting analysis, sound-event understanding, multimodal reasoning.
Audio output? No. The non-realtime qwen3.8-omni-flash documented here returns text. Qwen3.8-Omni-Flash-Realtime is a separate product.
Context window? 1M tokens.
Max output? 131,072 tokens per Alibaba's current docs.
OpenAI SDK compatible? Yes, with the right base URL.
Video with sound? Yes — joint audio-video understanding is the headline capability.
Function calling? Yes.

One note on gateways

If you're already routing across providers and don't want another set of credentials and region semantics to manage, a unified endpoint like CometAPI's (https://api.cometapi.com/v1, OpenAI-compatible) can collapse the integration surface:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com/v1",
)

Before you ship against any gateway for this model, confirm the endpoint is actually enabled on your account and that the media modalities you need are proxied — newly launched multimodal endpoints tend to roll out in stages, and a gateway that supports text today may not pass video tomorrow. Verify the model identifier, supported inputs, and pricing against the live catalog rather than a blog post, including this one.

The model itself is genuinely interesting because it removes an entire preprocessing tier. The thing that determines whether it's economical in your stack is less about the model and more about whether you discipline your media volume, reasoning effort, and conversation state.

Originally published at cometapi.com

Claude Haiku 5.5 in Production: 1M Context, a 100K Pricing Cliff, and a Tokenizer That Bites Back

Ryan Cole — Fri, 09 Oct 2026 05:19:06 +0000

I moved a chunk of my high-volume extraction and triage traffic onto Claude Haiku 5.5 around launch (October 7, 2026) and it is exactly what the tier promises: 1M tokens of context, 128K of standard output, adaptive reasoning, and base rates of $0.10/Mtok input and $0.50/Mtok output for prompts up to 100K tokens.

The model ID is claude-haiku-5-5 on the Claude API, anthropic.claude-haiku-5-5 on Bedrock. It also ships on Google Cloud and Microsoft Azure.

The headline numbers are not where the surprises live. Three things will actually change your bill and your latency profile: the 100K pricing cliff is per-request and there are no exemptions, the new tokenizer counts roughly 30% more tokens for identical text, and every glossy benchmark score was measured at max effort while the product default is medium.

What's actually new versus Haiku 4.5

Effort is now a dial

Haiku 5.5 is the first Haiku with configurable effort levels, so you can trade reasoning depth against latency and token spend inside the same model. Default is medium. For "is this email a refund request, yes/no" I run low. For ambiguous field extraction or tool-planning steps where a wrong answer costs a retry, I bump it up. Adaptive thinking means the model also decides when to reason, which introduces variance in both generated tokens and p95 latency — so tune thresholds on real distributions, not on an average.

The tokenizer quietly eats ~30% of the headline savings

Anthropic's docs are explicit: the same input text counts as approximately 30% more tokens than it does on Haiku 4.5. The rate cut is real — 90% off Standard input/output under 100K — but Anthropic only claims ~75% lower average running cost once request-length mix and per-task token usage are accounted for. That gap is the tokenizer plus workload shape. If your cost model still assumes Haiku 4.5 token counts, your projection is wrong in the optimistic direction.

Long context, with the usual discipline

1M tokens of window is genuinely useful for long documents and fat conversation histories, but the cliff below is why I still use retrieval, truncation, and caching instead of just dumping everything in. A big window is a capability, not a pricing strategy.

The 100K cliff is per request, not per excess token

Prompt length selects the pricing band for the whole request. Cross 100K and the entire call is billed at the higher band — you don't get 100K at the cheap rate plus the overflow at the expensive one.

Rate category	Prompt ≤ 100K	Prompt > 100K
Input	$0.10	$0.50
Output	$0.50	$2.50
5-minute cache write	$0.125	$0.625
1-hour cache write	$0.20	$1.00
Cache read	$0.01	$0.05
Batch input (50% off)	$0.05	$0.25
Batch output (50% off)	$0.25	$1.25

Rates above are official Standard/cache/Batch USD per million tokens, checked October 8, 2026. Cached workflows are where people get this wrong most often: count the whole request, including history and tool definitions, for the selected model, then reconcile input, cache-write, cache-read, and output against the band the request landed in. Pull a few representative cached requests off your invoice before you set a budget.

Here's the arithmetic on a scenario I actually ran, 100,000 requests/month at 2,000 input and 500 output tokens each (200M input, 50M output, all under the cliff, no caching or retries):

REQ, IN_TOK, OUT_TOK = 100_000, 2_000, 500
official = {                       # (input $/Mtok, output $/Mtok)
    "haiku-4.5":  (1.00,  5.00),
    "haiku-5.5":  (0.10,  0.50),
    "sonnet-5.5": (2.00, 10.00),
}
for name, (rin, rout) in official.items():
    total = REQ * (IN_TOK * rin + OUT_TOK * rout) / 1e6
    print(f"{name:11} ${total:,.0f}/month")

rin, rout = (r * 0.8 for r in official["haiku-5.5"])   # gateway Standard = official x 0.8
print(f"{'haiku-5.5*':11} ${REQ * (IN_TOK * rin + OUT_TOK * rout) / 1e6:,.0f}/month")

Output: $450, $45, $900, and $36 for the discounted route. That last row is where a unified multi-model endpoint earns its keep — the same key and request shape also reaches Sonnet 5.5 and Opus 5.5, so routing by complexity doesn't mean a second SDK. CometAPI lists claude-haiku-5-5 at $0.08 input / $0.40 output per Mtok under 100K (and $0.40 / $2.00 over), i.e. 20% off the corresponding official Standard bands. I wouldn't assume that discount stacks on top of Batch or cache pricing without checking the live page.

And note the framing: $450 → $45 is a 90% rate reduction on a fixed-token illustration. It is not a promise that your equivalent workload costs 90% less. Recount your own inputs before you promise anyone a number.

Benchmarks: read the config, not the score

Benchmark	Haiku 4.5	Haiku 5.5	Sonnet 5.5
GDPval-AA v2.1 (Elo)	735	1,620	1,840
AA-Briefcase v1.1 (Elo)	614	1,578	1,824
OSWorld 2.1, offline subset, partial credit	15.7%	72.4%	83.9%
Humanity's Last Exam, no tools	10.2%	45.9%	56.9%
Humanity's Last Exam, with tools	18.7%	57.4%	64.5%
Terminal-Bench 4.0	0.0%	39.2%	70.6%
Chartography, no tools	6.4%	46.4%	61.6%

These are vendor-reported (GDPval-AA and AA-Briefcase come from independently run Artificial Analysis evals). The evaluation config matters more than the digits:

Scores use adaptive thinking at max effort, default sampling, five trials unless stated. Product default is medium. A headline score is not a default-setting guarantee for your app.
OSWorld 2.1 is 82 offline tasks, no internet, 1080p, 500-action cap. The 72.4% is partial credit; strict pass rate is 37.1%.
Terminal-Bench 4.0 runs Claude Code in --bare mode with safeguards on. Haiku 5.5 gets max effort, no fallback, no internet egress, 10 trials per task. Sonnet 5.5 gets five trials and a fallback for some flagged requests. Haiku 4.5 uses a fixed 63,999-token thinking budget.

That last bullet is why 39.2% vs 70.6% isn't a clean comparison. Reproduce effort, tools, scaffold, and budget before comparing against your own harness.

My read: the OSWorld jump is the real story — Haiku 5.5 became dramatically more usable for structured GUI work. But Sonnet 5.5's Terminal-Bench lead confirms the larger-model advantage in agentic coding hasn't moved. Pick by failure cost, not by leaderboard rank.

Choosing between the three tiers

Dimension	Haiku 4.5	Haiku 5.5	Sonnet 5.5
Context	200K	1M	1M
Max standard output	64K	128K	128K
Standard input / MTok	$1	$0.10 ≤100K; $0.50 over	$2
Standard output / MTok	$5	$0.50 ≤100K; $2.50 over	$10
Reasoning	Extended thinking, fixed budget	Adaptive, medium default	Adaptive, high default
Relative latency	Fast	Fastest at standard speed	Fast
Coding depth	Bounded tasks	Stronger subagents	More complex coding
Typical use	Legacy small-model deployments	High-volume workflows	Complex production workflows

All three take text + image input and emit text (that's not image generation). "Fastest" refers to standard-speed modes — Opus Fast Mode is explicitly excluded from that claim. Anthropic's product tiers don't establish parameter counts or architecture details, so don't infer them.

Workload routing I'd actually ship:

Workload	Default	Why
Email classification	Haiku 5.5	Short, repeated, verifiable
Document field extraction	Haiku 5.5	Cheap structured processing
Support triage	Haiku 5.5	Fast first response + escalation
Coding subagents	Haiku 5.5	Low-cost file search, contained edits
Complex debugging	Sonnet 5.5	Meaningfully better on coding evals
High-stakes multi-step reasoning	Opus 5.5	Upper tier
Mixed traffic	Haiku + Sonnet	Route by complexity and confidence

Sonnet wins when stronger judgment avoids repeated failed calls, tool retries, or human corrections. On a labeled sample of your own traffic, measure accepted-task rate, correction cost, and latency; route anything that fails explicit validation or exceeds tested task scope to a stronger model; then re-tune after any prompt, tool, or effort change.

Migration notes that will actually bite you

temperature        -> omit; if sent, must be exactly 1
top_p              -> omit; if sent, must be exactly 0.99
top_k              -> omit; any value returns HTTP 400
temperature+top_p  -> both present returns HTTP 400
assistant prefill  -> banned

Then:

Update the model ID and re-validate every endpoint-specific field.
Recount tokens with the new tokenizer — including stable prefixes and tool definitions, not just user text.
Re-test adaptive-thinking behavior and how you parse response blocks.
Cap external-tool permissions, keep audit logs, and require review before consequential actions.
Watch stop_reason and usage. If Haiku 4.5 completed a response and Haiku 5.5 truncates it, the tokenizer is counting more for the same text and adaptive thinking can eat output budget. Don't copy legacy max_tokens; retune on real tasks.
Report p50/p95 latency, accepted-task rate, and total billable tokens — not token price.
Stage the rollout with a rollback path for anything business-critical.

One subtle one: stored thinking blocks are only valid in the account that produced them, or an account linked to it. An unrelated account sending one has it discarded before the model sees it — the request can still succeed, just without that reasoning. If you continue a tool workflow, keep the conversation blocks and stay on the originating or linked account. A gateway or account switch needs explicit testing; matching a model name doesn't guarantee the blocks survive.

Where it isn't the right tool

Haiku 5.5 is not a universal substitute. Long-horizon reasoning and complex coding are still real differentiators for Sonnet and Opus, and the 1M window costs you real money past 100K, so use it selectively. Adaptive reasoning adds variance you have to measure rather than assume.

For high-volume work with measurable acceptance criteria, this is a straightforward upgrade: cheaper entry pricing, bigger window, adaptive reasoning, and much better published agentic/computer-use evals. For ambiguous decision-making or hard debugging, paying Sonnet or Opus rates often costs less in total because you stop paying for retries and human corrections. Benchmark the whole workflow, not the token.

Originally published at cometapi.com

Running GLM-5.3-Flash Locally: Memory Budgets, Runtime Choices, and Working Commands

Ryan Cole — Thu, 24 Sep 2026 08:33:20 +0000

The first number I would check before deploying GLM-5.3-Flash is 306 GiB: the approximate size of its native FP8 weights. Its 18B active parameters per token describe compute usage, but the full model has about 320B parameters that still need somewhere to live.

The weights are available under the MIT license. Local deployment is possible; the useful question is which combination of RAM, VRAM, quantization, and runtime makes sense for your workload.

My starting point:

Server GPUs: vLLM or SGLang.
Hundreds of gigabytes of RAM plus consumer GPUs: KTransformers.
Quantized workstation experiments: llama.cpp or Ollama.

A 24 GB or 32 GB GPU cannot hold the model alone. Single-GPU deployment relies on system RAM, offloading, and possibly quantization.

Budget for the checkpoint and the requests

The official vLLM recipe puts native FP8 weights at approximately 306 GiB. KTransformers recommends at least 350 GB of available system memory for its native FP8 CPU-GPU path.

GGUF gives you more sizing options. These are approximate model-file sizes, not total runtime requirements:

Quantization	Model size	How I would budget
BF16	642 GB	Server-class memory
Q8_0	341 GB	Large-memory server or workstation
Q6_K_XL	292 GB	High-memory workstation/server
Q5_K_XL	240 GB	256 GB RAM is likely too tight after overhead
Q4_K_XL	200 GB	Roughly 256 GB+ system-memory class
IQ4_XS	157 GB	More realistically a 192–256 GB-class system
Q3_K_XL	148 GB	Large-memory workstation, with a growing quality trade-off
Q2_K_XL	109 GB	128 GB leaves little room beyond the file
IQ2_XXS	102 GB	Aggressive compression
IQ1_S	93.1 GB	Extreme compression; task-specific validation required

Those planning notes are not official minimum specifications. Runtime buffers, metadata, multimodal components, KV cache, and the operating system all need memory. Context length, concurrency, GPU offload, and the quantization implementation change the actual fit.

For a machine with 32–64 GB of system RAM, I would choose a smaller model or hosted access. At 128 GB, the smallest GGUF builds approach the available capacity, but predictable quality and long context are difficult targets. Around 256 GB or more, Q4_K_XL becomes a more practical starting point.

Why 18B active parameters does not solve the memory problem

GLM-5.3-Flash routes each token through only part of its expert capacity. Its hybrid linear and sparse attention, including IndexPool, also reduces long-context costs.

Z.ai reports lower attention compute and KV-cache usage than GLM-5.3. That helps, but cache still grows with context and concurrent requests. A deployment that works at 8K can run out of memory on a much longer conversation.

The official model card lists the following:

Property	Value
Architecture	Native multimodal Mixture-of-Experts
Total / active parameters	320B / 18B per token
Language-model layers	45
Attention	Hybrid linear + sparse attention with IndexPool
Maximum context	1,048,576 tokens
Training corpus	30T multimodal tokens
Inputs / output	Text, images, video, files / text
Weights and license	Open weights, MIT
Official model ID	`zai-org/GLM-5.3-Flash`
Reasoning effort	`low`, `high`, `max`; default `max`

I would configure context around the application’s actual input size. Allocating the full supported window during initial setup makes memory debugging harder.

Start with GGUF for workstation experiments

For a local experiment, I would start here unless matching the native checkpoint is a requirement. Unsloth publishes GGUF builds ranging from 1-bit through BF16.

llama.cpp offers CPU-GPU offloading; Ollama provides a short launch command. Both still need enough total memory for the selected build.

llama.cpp

Install on macOS or Linux:

curl -LsSf https://llama.app/install.sh | sh

On Windows:

winget install llama.cpp

Start the Q4_K_XL server:

llama serve -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

Or run it directly in the terminal:

llama cli -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

This build is about 200 GB. Before starting the download, check the quantization tag, repository file size, and available disk space.

Ollama

Unsloth documents direct Hugging Face loading:

ollama run hf.co/unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL

The memory budget is the same underlying problem regardless of how short the command is.

If Q4 does not fit, 3-bit, 2-bit, and 1-bit builds exist. I would select the highest-quality quantization that leaves room for runtime buffers and cache, then compare it against a native or hosted reference.

Aggressive quantization can affect reasoning reliability, generated code, tool-call formatting, and multimodal behavior. A model that loads has passed only the capacity check.

Use KTransformers when the weights belong in system RAM

KTransformers reads the official FP8 weights directly and distributes expert inference across CPU and GPU. This is the route I would investigate for a workstation with very large RAM capacity and one or more consumer GPUs.

The GLM-5.3-Flash tutorial documents:

Approximately 306 GiB of FP8 weights and a recommendation for 350 GB of available system memory.
NVIDIA SM89 and SM120 support, including RTX 40- and 50-series GPUs.
AVX-512 FP8 CPU expert kernels.
Single-GPU and four-GPU configurations.

An RTX 4090 or RTX 5090 can participate, but most model state still sits outside VRAM. CPU capability, RAM bandwidth, and memory placement matter considerably.

Install and prepare the checkpoint

Create a Python 3.11 environment and install the SGLang integration:

conda create -n glm53flash python=3.11 -y
conda activate glm53flash

pip install "ktransformers[sglang]"

Download zai-org/GLM-5.3-Flash to local storage. Allow sufficient disk space for the checkpoint and available RAM for the server configuration.

Launch the documented single-GPU configuration

MODEL_PATH=/path/to/GLM-5.3-Flash

CUDA_VISIBLE_DEVICES=0 python -m sglang.launch_server \
  --model-path "$MODEL_PATH" \
  --kt-weight-path "$MODEL_PATH" \
  --served-model-name GLM-5.3-flash \
  --host 0.0.0.0 \
  --tp-size 1 \
  --context-length 501025 \
  --mem-fraction-static 0.65 \
  --chunked-prefill-size 2048 \
  --kt-method FP8 \
  --kt-cpuinfer 64 \
  --kt-threadpool-count 2 \
  --kt-num-gpu-experts 0 \
  --kt-gpu-prefill-token-threshold 2048 \
  --cuda-graph-bs 1 2 4 \
  --limit-mm-data-per-request '{"image":8,"video":1}' \
  --mm-process-config '{"image":{"max_pixels":1254400}}' \
  --tool-call-parser glm47 \
  --reasoning-parser glm45

The tutorial validates this 501,025-token configuration. The model’s 1,048,576-token limit does not mean every deployment should allocate that much context.

Check discovery:

curl http://localhost:30000/v1/models

The OpenAI-compatible chat endpoint is http://localhost:30000/v1/chat/completions. This launch command serves the model as GLM-5.3-flash, so use that identifier for chat requests.

If generation is extremely slow, investigate NUMA placement, RAM bandwidth, CPU instruction support, and storage behavior during loading. With substantial expert work on the CPU, memory capacity alone does not guarantee usable interactive performance.

Serve native weights on GPU infrastructure

For production serving, I would start with vLLM when throughput and ecosystem compatibility dominate. SGLang is also worth testing for agent workloads, structured generation, multimodal requests, and concurrency.

Both serve the native checkpoint and support strong multi-GPU scaling. Their focus on CPU offload is more limited than KTransformers or llama.cpp.

vLLM

Use Linux, a supported NVIDIA stack, sufficient aggregate GPU memory, and a recent supported vLLM build or the container specified in the current recipe.

pip install vllm

vllm serve "zai-org/GLM-5.3-Flash" \
  --tensor-parallel-size 8 \
  --served-model-name zai-org/GLM-5.3-Flash

This is a reference launch configuration. Eight GPUs do not automatically imply enough usable memory or support for every feature.

Verify the endpoint:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [
      {"role": "user", "content": "Reply with OK"}
    ]
  }'

The vLLM recipe also covers FP8 KV cache on supported Blackwell systems, MTP speculative decoding, tool and reasoning parsers, and prefill/decode disaggregation. I would take those flags from the current recipe because support changes quickly.

SGLang

Install:

pip install sglang

Launch:

python3 -m sglang.launch_server \
  --model-path "zai-org/GLM-5.3-Flash" \
  --host 0.0.0.0 \
  --port 30000

Verify:

curl -X POST "http://localhost:30000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "Give me three local deployment checks."}]
  }'

The official model card includes multimodal SGLang examples. For tool calling, check the parser configuration for the current integration. Parser flags from an older GLM release are not a reliable template.

Test the application contract before tuning throughput

I would validate a deployment in this order: text generation, intended context length, tool schemas, multimodal inputs, and concurrent traffic.

For the vLLM endpoint above:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [
      {"role": "user", "content": "Return exactly: LOCAL_OK"}
    ],
    "reasoning_effort": "low"
  }'

Adjust the port and served model name for your runtime.

The model defaults to reasoning_effort: "max". Keep max when reproducing benchmarks. For workstation iteration, low or high can be more practical.

My acceptance checks would include:

Check	What to exercise
Context	A document or repository-sized prompt near the application’s intended limit
Tools	Argument JSON, tool selection, repeated calls, recovery from tool errors
Multimodal	Actual image/video formats and resolution ranges
Concurrency	Latency and memory with multiple active requests
Quantization	Identical prompts against the selected GGUF and a native or hosted reference

Separate memory tuning from latency tuning

To reduce memory pressure, lower configured context and concurrency first. A small concurrency target with an explicit queue can suit a workstation better than server-style parallelism.

Quantization reduces weight memory. CPU offload moves substantial model state into RAM, shifting performance pressure toward the CPU and memory bandwidth.

Lowering reasoning_effort can shorten generated reasoning, reduce latency, and consume fewer tokens. It does not reduce the memory needed to load the weights. Any cache savings are indirect, from generating a shorter sequence.

Diagnose failures by when they happen

Symptom	First checks
Loads, then crashes on a long prompt	KV-cache headroom; reduce context and concurrency, then increase gradually
GGUF fits on disk but fails in RAM	Runtime buffers, cache, operating-system headroom
Single-GPU KTransformers is too slow	NUMA, RAM bandwidth, CPU support, CPU expert workload
Tool calls contain malformed JSON	Current runtime parser configuration
Download is hundreds of gigabytes	Expected file size and selected quantization tag

I would monitor both system RAM and GPU memory while increasing workload size. Otherwise, it is easy to mistake a successful checkpoint load for a viable serving configuration.

Decide whether the capability justifies the deployment

The benchmark case for this model is mainly coding, tool-driven automation, long-context document work, and multimodal workflows.

These are Z.ai’s reported scores, not measurements from a local quantized deployment:

Benchmark	GLM-5.3-Flash	GLM-5.2	Difference
Terminal-Bench 2.1	84.3	81.0	+3.3
DeepSWE v1.1	63.4	46.2	+17.2
NL2Repo	56.3	48.9	+7.4
Toolathlon Verified	78.4	59.9	+18.5
AutomationBench v1.0.6	48.8	26.2	+22.6
Agents' Last Exam	26.3	20.4	+5.9
HLE with Tools	55.3	54.7	+0.6
GDPval-AA v2	1773	1504	+269 Elo

I would use those results to decide what to evaluate locally, then let workload-specific tests determine whether the hardware and operating costs are justified.

Where hosted access fits

Self-hosting gives control over data residency, offline operation, quantization, and inference settings. It also makes hardware capacity, maintenance, and scaling your responsibility.

Hosted access removes the upfront hardware requirement and provider-side maintenance, but sends data to the selected service, uses provider-selected quantization, and scales within provider limits.

If I needed a unified multi-model API for reference comparisons or a fallback during deployment work, CometAPI provides an OpenAI-compatible endpoint using model ID glm-5.3-flash:

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://api.cometapi.com/v1",
    api_key=os.environ["COMETAPI_KEY"],
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[{"role": "user", "content": "Reply with OK"}],
)

print(response.choices[0].message.content)

Local hosting can make financial sense with suitable owned hardware, consistently high utilization, or a firm requirement to keep data inside your infrastructure. For intermittent workloads, I would weigh the fixed hardware and operational burden carefully.

My deployment gate would be concrete: the chosen checkpoint fits with headroom, the runtime handles the required tools and inputs, and latency stays acceptable at the intended context and concurrency. Until those checks pass, a running server is still an experiment.

Originally published at cometapi.com

Building Short Videos with Sora 2’s Native Audio

Ryan Cole — Tue, 22 Sep 2026 04:51:43 +0000

Sora 2 is OpenAI’s second-generation text-to-video model, but its most useful change is not purely visual. Audio is generated as part of the video workflow: dialogue, ambience, music cues, and sound effects can be described alongside the scene and synchronized with what happens on screen.

That matters because the traditional workflow is split across several tools: generate the video, record or synthesize dialogue, find sound effects, add ambience, then manually align everything in an editor. Sora 2 attempts to produce those layers together from the first render.

What Sora 2 generates

Sora 2 can produce several practical audio layers:

Synchronized dialogue aligned with character lip movement and timing.
Sound effects connected to visible events such as footsteps, impacts, doors, and object movement.
Environmental audio including rain, wind, room tone, crowds, and distant traffic.
Music cues, such as short stings or background loops. Licensing and style restrictions may still apply.
A basic mix combining the generated elements. For detailed balancing or mastering, export stems when the workflow supports it and finish in a DAW.

The important distinction is that audio is not necessarily a post-process. The model simulates the sound and image together, which can improve synchronization between speech, physical actions, and the surrounding environment.

The audio capabilities worth testing

Dialogue and lip-sync in the generation pass

Sora 2 can generate speech that matches a generated face or animated mouth. This is different from taking a finished video and running a separate lip-sync process over it: the timing and prosody are part of the generation step.

That makes short dialogue-driven content practical without recording actors. Product micro-ads, instructional clips, social cameos, and quick narrative prototypes are obvious use cases.

Sound effects that follow the scene

The model can associate sound with visible physical events:

A cup clinks when it hits a table.
Footsteps reflect the apparent environment.
A door creaks or slams at the moment it moves.
An object impact produces a corresponding sound.

Those details carry a surprising amount of perceived realism. Room tone gives a location scale, while a well-timed impact or sudden thud supplies an emotional cue.

Audio continuity across shots

For sequences made from multiple shots or stitched clips, Sora 2 attempts to maintain characteristics such as:

Similar room reverb
Consistent voice timbre for recurring characters
Matching environmental noise
More coherent audio across cuts

It is not a replacement for a sound editor, but it can reduce the amount of manual EQ and room-tone matching needed during early iterations.

Accessing Sora 2

There are two main access paths:

Sora app or web app — OpenAI announced Sora 2 with an app for creating videos without code. Availability is staged by region, app store, and access window. Recent wider-access periods have included the US, Canada, Japan, and South Korea, with quotas and other limitations.
OpenAI Video API — The video API exposes sora-2 and sora-2-pro. Requests can include a prompt, duration in seconds, output size, and input references. sora-2 is positioned for faster iteration, while sora-2-pro targets higher fidelity and more complex scenes.

A unified multi-model gateway such as CometAPI can expose the same Sora 2 API call style and endpoints, with pricing listed below.

Minimal API request

The v1/videos endpoint accepts model=sora-2 or sora-2-pro. This example asks for dialogue, applause, and a sustained piano note:

curl https://api.cometapi.com/v1/videos \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -F "model=sora-2" \
  -F "prompt=A calico cat playing a piano on stage. Audio: single speaker narrator says 'At last, the show begins'. Add applause and piano sustain after the final chord." \
  -F "seconds=8" \
  -F "size=1280x720"

The request creates a video job. Once processing finishes, the result is an MP4 with audio baked into it; the API returns a job ID and, when ready, a download URL.

Listed API pricing

Model	Price
Sora-2	$0.08 per second
Sora-2-pro	$0.24 per second

A practical prompt-to-video workflow

I generally treat the audio plan as part of the shot plan rather than adding it after writing the visual prompt.

Define the scene, characters, dialogue, mood, and whether the sound is diegetic or musical.
Describe the audio explicitly: speakers, delivery, pacing, effects, and ambience.
Start with a short render, usually 4–8 seconds for rapid iteration.
Check speech timing, lip-sync, background noise, and event-based effects.
Export the mixed result or stems, if available, and finish the mix externally when exact control matters.

Sora 2 is aimed at short cinematic clips. Longer sequences can be created through multi-shot or stitching workflows, but they typically require more iteration.

One-step audio versus a separate narration asset

Use the video endpoint when the goal is a single prompt that produces video and audio together.

A separate speech asset makes more sense when:

The narrator must remain consistent across many videos.
You need to audition different voices.
Voice timbre and prosody require tighter control.
The same narration will be reused in multiple edits.

The speech endpoint is /v1/audio/speech. You can generate an MP3, import it into Final Cut or Premiere, and replace or layer the generated audio. Where supported, the audio can also be supplied as an input reference for a remix workflow.

curl https://api.openai.com/v1/audio/speech \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-speech-1",
    "voice": "alloy",
    "input": "Welcome to our product demo. Today we show fast AI video generation."
  }' \
  --output narration.mp3

The primary Sora 2 workflow already generates audio. Separate speech generation is for voice consistency, external reuse, or more controlled production pipelines.

Node.js example

The official SDK can create the video job directly:

import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

const video = await openai.videos.create({
  model: "sora-2",
  prompt: `
A friendly robot waters plants on a balcony at sunrise.
Audio: soft morning birds, one speaker voiceover says
"Good morning, little world." Include distant city ambience.
Style: gentle, warm.
  `,
  seconds: "8",
  size: "1280x720",
});

// Poll the job and download the result after completion.
console.log("Video job created:", video.id);

The SDK call creates the job; polling and downloading the completed result follow the video API’s job lifecycle.

Prompt structure that works better

I get more predictable results when the prompt has a clear visual section followed by an explicit audio section:

Visual scene and action.

Audio:
- Number of speakers
- Voice, tone, and pacing
- Dialogue
- Sound effects and timing
- Environmental ambience
- Optional mix perspective

For example:

A rainy evening on a narrow city alley. A woman in a red coat hurries across wet cobblestones toward a flickering neon sign.

Audio: Two speakers. Speaker A, the woman, breathes slightly and sounds hurried. Speaker B, an offscreen street vendor, calls out once. Add steady rain on a roof, a distant car, and the clatter of an empty can when she kicks it.

Dialogue:
Speaker A: "I'm late. I can't believe I missed it."
Speaker B, muffled, one line: "You better run!"

Style: cinematic, shallow depth of field, close-up when she speaks. Sync dialogue to lip movement and use naturalistic reverb.

Putting the audio instructions after the visual description helps bind sounds to the events already established in the scene. For timing-sensitive clips, include explicit timecodes:

[SFX: door_close @00:01]
[SFX: impact @00:04]

I also separate camera instructions from audio instructions instead of mixing everything into one sentence.

Remixing and targeted edits

Sora 2 supports remix-style workflows for changes such as extending a scene or replacing its background. Audio changes should be stated in the remix request too:

Replace the music with sparse piano. Keep the dialogue identical,
but move the second line to 2.5 seconds. Preserve the room ambience.

This is useful when the visual result is close and rebuilding the entire shot would be wasteful.

Troubleshooting audio problems

Lip-sync is drifting

Make the dialogue timing more explicit and simplify competing background noise. Strong ambience can mask speech or affect perceived timing.

The voice sounds muffled or too reverberant

Specify the acoustic target:

Dry voice, minimal reverb, close microphone perspective.

Or, for a location-based sound:

Natural room reverb, voice slightly distant from the camera.

Effects are too loud or buried

Use relative balance instructions:

Soft door close. Dialogue should be 3 dB louder than ambience.

The generation contains unwanted artifacts

Regenerate with slightly different wording. Alternate phrasing can produce cleaner audio even when the underlying scene description remains the same.

Three prompt patterns

Product reveal: 7–12 seconds

7s, studio product shot: small espresso machine on a counter.
Visual: slow 3/4 pan in.
Dialogue: "Perfect crema, every time."
Voice: confident, friendly, male, medium tempo.
SFX: steam release at 0:04, small metallic click at 0:06.
Ambient: low cafe murmur.

A short spoken hook paired with a recognizable product sound gives the clip an immediate sensory identity. A brand jingle can still be added in post.

Instructional clip: 10 seconds

10s, overhead kitchen shot.
Visual: hands sprinkle salt into a bowl, then whisk.
Audio: step narration, female and calm:
"One pinch of sea salt."
SFX: salt sprinkle at the start, whisking texture under narration.
Ambient: quiet kitchen.

This combines instructional narration with diegetic sounds that reinforce each action.

Tension beat: 6 seconds

6s, alleyway at dusk.
Visual: quick low-angle shot of a bicyclist's tire skidding.
Audio: sudden metallic screech at 00:02 synced to the skid,
heartbeat-like low bass underlay, distant thunder.
No dialogue.

Short tension scenes depend on precise effects and low-frequency cues. Keeping the sound plan compact makes the timing easier to evaluate.

Where I would not use Sora 2 alone

Long-form narrative work with complex dialogue, many scenes, and detailed mixes still benefits from human performers and dedicated sound design.

I also would not treat synthetic media as a substitute for authenticated recordings in legal proceedings, evidence workflows, or other strict compliance contexts.

For ordinary short-form production, though, native audio changes the iteration loop. I can describe the action, the sound, and their relationship in one request, then spend time refining the creative result instead of manually assembling every layer from scratch.

Originally published at cometapi.com

Building Short Midjourney V1 Videos with an Image-to-Video API

Ryan Cole — Tue, 22 Sep 2026 02:00:39 +0000

Midjourney’s V1 video model is designed around a straightforward workflow: start with one still image and turn it into a short animated clip. The source image can come from Midjourney or from an externally hosted URL.

The default output is roughly five seconds long. Clips can be extended in four-second increments to approximately 21 seconds, and the result is delivered as an MP4. This makes V1 useful for animated stills, product loops, stylized social content, and short visual experiments rather than long-form cinematic sequences.

What V1 Actually Does

Midjourney V1 is an image-to-video model. It prioritizes preserving the source image’s visual identity, including its color palette, brushwork, subject, and overall mood.

The main characteristics are:

Base clip length of approximately five seconds.
Extensions in four-second increments, up to a documented limit of roughly 21 seconds.
Automatic or manual animation modes.
Low- and high-motion controls through --motion low and --motion high.
Configurable batch size, looping, and end frames.
MP4 output.
Primarily SD output at 480p, with HD output at 720p available through the appropriate model or video-type parameter.
A quality and resolution tradeoff aimed at quick iteration, web content, and social media rather than full cinematic production.

The practical implication is that the starting image matters more than it would in a text-to-video workflow. A clear subject, deliberate composition, and usable aspect ratio give the model less ambiguity to resolve.

For programmatic access, I use CometAPI’s unified REST interface, which exposes the Midjourney V1 video capability through /mj/submit/video. The request accepts an image URL in prompt, a videoType such as vid_1.1_i2v_480, a generation mode, and an animateMode.

Decide the Parameters Before Submitting

There are a few decisions worth making before writing the request.

Starting image

External images need to be available at publicly reachable URLs. Choose an image with:

A clear primary subject.
Enough visual separation between foreground and background.
A composition that works at the intended output aspect ratio.
A subject whose expected movement is physically plausible.

Starting aspect ratio affects the final video dimensions and whether the result maps cleanly to SD or HD output.

Motion

Use low motion for subtle camera movement, restrained subject animation, or loop-friendly clips. High motion is more appropriate when the subject needs to travel or the scene contains more visible movement.

You can either let the model infer motion automatically or describe it explicitly in manual mode.

Duration and batch size

The default clip is approximately five seconds. Extensions add four seconds at a time, up to roughly 21 seconds.

The default batch size is four variants. For production jobs or cost-sensitive iteration, request one or two variants instead. A batch size of one is represented by bs: 1.

Resolution

V1 is primarily oriented around 480p SD output. HD output is 720p and requires the relevant documented video type or parameter. The examples below use vid_1.1_i2v_480.

Submit a Video Job

The smallest useful request includes:

prompt: an image URL, optionally followed by a motion description.
videoType: for example, vid_1.1_i2v_480.
mode: usually "fast", or "relax" when supported by the plan.
animateMode: "automatic" or "manual".

Here is a complete request:

curl --location --request POST 'https://api.cometapi.com/mj/submit/video' \
  --header 'Authorization: Bearer sk-YOUR_COMETAPI_KEY' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "prompt": "https://cdn.midjourney.com/example/0_0.png A peaceful seaside scene — camera slowly zooms out and a gull flies by",
    "videoType": "vid_1.1_i2v_480",
    "mode": "fast",
    "animateMode": "manual",
    "motion": "low",
    "bs": 1
  }'

The image URL and motion instruction are combined in the prompt field. In this example, manual animation is paired with low motion, a single output variant, and a slow zoom.

Submit and Poll from Python

The API is asynchronous, so the basic integration pattern is:

Submit the generation request.
Extract the returned job identifier.
Poll the status endpoint.
Download the video once the job reaches completed.

A minimal requests implementation looks like this:

import time
import requests

API_KEY = "sk-YOUR_COMETAPI_KEY"
BASE = "https://api.cometapi.com"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

payload = {
    "prompt": "https://cdn.midjourney.com/example/0_0.png A calm city street — camera pans left, rain falling",
    "videoType": "vid_1.1_i2v_480",
    "mode": "fast",
    "animateMode": "manual",
    "motion": "low",
    "bs": 1
}

# Submit job
r = requests.post(f"{BASE}/mj/submit/video", json=payload, headers=HEADERS)
r.raise_for_status()
job = r.json()
job_id = job.get("id") or job.get("job_id")

# Poll for completion (example polling)
status_url = f"{BASE}/mj/status/{job_id}"
for _ in range(60):  # poll up to ~60 times
    s = requests.get(status_url, headers=HEADERS)
    s.raise_for_status()
    st = s.json()
    if st.get("status") == "completed":
        download_url = st.get("result", {}).get("video_url")
        print("Video ready:", download_url)
        break
    elif st.get("status") in ("failed", "error"):
        raise RuntimeError("Video generation failed: " + str(st))
    time.sleep(2)

For a production worker, I would move the polling loop into a job system, add request timeouts and retry handling, and persist the provider job ID rather than keeping it only in process memory.

Writing Motion Prompts

Motion prompts are natural-language instructions. I get more predictable results by keeping the movement description short and separating camera movement from subject movement.

Useful patterns include:

"camera dolly left while the subject walks forward"
"leaf falls from tree and drifts toward camera"
"slow zoom in, slight parallax, 2x speed"
"subtle motion, loopable, cinematic rhythm"

A more structured prompt can be written like this:

start_frame_url animate: "slow spiral camera, subject bobs gently, loopable", style: "film grain, cinematic, 2 fps tempo"

The useful progression is to state the action first, then add timing and stylistic constraints. Small iterations are more productive than stacking a long list of unrelated instructions.

Automatic versus manual animation

Automatic animation is useful when plausible motion is enough. The model infers how the scene should move and is usually the fastest way to test an image.

Manual animation is better when camera direction, subject movement, or choreography needs to be repeatable. It is also the better choice when the clip must align with live-action footage or a predefined sequence.

Extending and Looping Clips

A generated five-second clip can be extended by four seconds per operation, up to approximately 21 seconds. In the UI, this is exposed through an Extend control. Programmatically, wrappers generally expose an extend flag or a separate extend job referencing the original clip. The exact parameterized endpoints and controls depend on the API documentation.

Extensions should be treated as additional generation work, with costs similar to an initial generation.

For loops, reuse the starting frame as the ending frame or use the --loop parameter. For a different ending, provide another image URL through end and keep its aspect ratio compatible with the starting image. Midjourney also supports a --end parameter. Manual extension can help adjust the motion prompt when continuity starts to drift.

Batch size is another simple cost control. Since the default is four variants, setting bs: 1 is useful when the goal is a single production candidate rather than exploration.

Adding Audio After Generation

Midjourney V1 produces silent MP4 video. Audio is not generated natively, so voice, music, and effects need to be added afterward.

A practical audio pipeline usually has three parts:

Generate narration with a text-to-speech service such as ElevenLabs, Replica, or another voice-cloning/TTS provider.
Generate or source music and sound effects using tools such as MM Audio, Magicshot, or specialized SFX generators.
Mix the tracks in DaVinci Resolve, Premiere, Audacity, or a similar editor.

For timing-sensitive work, I would do the final mix in a DAW or video editor. That provides better control over dialogue timing, sound effects, background levels, and synchronization than trying to assemble everything through isolated API calls.

For a simple silent video plus speech track, ffmpeg is enough:

# Normalize audio length (optional), then combine:
ffmpeg -i video.mp4 -i speech.mp3 -c:v copy -c:a aac -shortest output_with_audio.mp4

For dialogue, music, and effects, render one mixed audio track first, then mux that track into the MP4 using the same approach.

Where V1 Fits

V1 is deliberately constrained: short clips, image-driven motion, and relatively modest control over long sequences. Those constraints are also what make it useful for fast iteration.

The strongest use cases are:

Animated illustrations.
Product hero loops.
Short character movements.
Stylized social clips.
Loopable background visuals.
Motion studies from existing still images.

It is less suitable for long continuous scenes, complex multi-shot narratives, or workflows that require precise cinematic camera rigs. The model is expected to improve over time in sequence length, fidelity, and camera control, but the current workflow is best treated as concise motion design built from a strong still frame.

Originally published at cometapi.com

How I’d Choose Between GPT-Image-2.5 and Nano Banana 2 for Production

Ryan Cole — Tue, 22 Sep 2026 01:23:01 +0000

I’d start with Sunburst for edits that must preserve a product or person, Flare for rapid iteration, and Nano Banana 2 for generation that needs search context, unusual canvas shapes, or predictable batch costs.

That split is more useful than declaring an overall winner. The reported Arena results favor GPT-Image-2.5, especially for editing, but a preference leaderboard doesn’t measure retrieval integration, output constraints, or the cost of producing thousands of acceptable assets.

This comparison uses the September 2026 release and leaderboard snapshot discussed below. The OpenAI benchmark entries are still preliminary; I’d treat them as a reason to prioritize an evaluation, rather than a substitute for one.

Start with the API contract

GPT-Image-2.5 has two API variants. OpenAI launched both on September 8, 2026:

Flare targets everyday generation, fast iteration, and volume.
Sunburst spends more generation time on precision editing and tighter creative control.

Nano Banana 2 is Google’s Gemini 3.1 Flash Image, introduced on February 26, 2026. Google’s release notes place general availability on May 28, 2026, with video-to-image context support added. The older preview model ID was deprecated, although some integration URLs still contain the preview slug.

Here’s the contract I’d compare before looking at sample images:

Capability	GPT-Image-2.5 Flare	GPT-Image-2.5 Sunburst	Nano Banana 2
API model ID	`gpt-image-2.5-flare`	`gpt-image-2.5-sunburst`	`gemini-3.1-flash-image`
Input	Text, image	Text, image	Text, image, video context
Output	Image	Image	Image, text
Main role	Fast generation and controlled edits	Precision editing and premium assets	Grounded multimodal generation
Quality settings	`low`, `medium`, `high`, `xhigh`, `max`, `auto`	Same	Primarily resolution-driven
Common output sizes	1024×1024, 1536×1024, 1024×1536	Same	0.5K, 1K, 2K, 4K
Maximum edge	3840 px	3840 px	Up to 4K
Aspect ratios	Approximately 1:3 through 3:1	Same	Includes 1:4, 4:1, 1:8, 8:1
Transparent backgrounds	PNG and WebP	PNG and WebP	Not a headline API capability
Native search grounding	Not documented at image-model level	Not documented at image-model level	Google Web and Image Search
Thinking	Not exposed as a core capability	Not exposed as a core capability	Supported
Batch API	Not a headline 2.5 feature	Not a headline 2.5 feature	Supported

OpenAI’s model documentation describes Flare as the faster everyday option and Sunburst as the variant optimized for editing precision. Both expose the six quality settings above.

For Google, I’d check the current Gemini 3.1 Flash Image documentation, particularly when migrating an integration that still references the preview model.

Editing is where I’d test Sunburst first

The useful editing question is how much unrelated content changes after each revision.

A product workflow might replace a background, adjust lighting, add seasonal styling, revise copy, and then change the aspect ratio. Each individual render can look good while the bottle, label, or person slowly drifts away from the reference.

OpenAI’s Images 2.5 announcement emphasizes preservation of reference subjects, natural lighting, richer textures, and more consistent multi-turn edits. Sunburst specifically targets the workflows where preserving those details matters more than minimum latency.

That makes it my first evaluation candidate for:

Product photographs where packaging and geometry must survive revisions.
Campaign assets with repeated changes to copy, placement, and styling.
Character or subject transformations driven by reference images.
Structured posters, branded layouts, and transparent design elements.

Flare occupies the faster lane in the same family. OpenAI claims higher-quality output with up to 50% lower generation latency than GPT Image 2.

That figure is an OpenAI generation-to-generation comparison. It says nothing conclusive about Flare’s speed relative to Nano Banana 2. I’d benchmark both with the same prompts, output dimensions, and concurrency before making a latency commitment.

Google’s model also supports conversational editing and subject consistency. Its stronger differentiator is the surrounding Gemini workflow: reasoning, search, multilingual text, and multiple references.

What the Arena numbers actually support

Arena aggregates blind side-by-side human preferences. The reported snapshot looks like this:

Arena metric	Sunburst	Flare	Nano Banana 2
Text-to-Image score	1421±13	1399±13	1261±5
Text-to-Image rank	#1	#2	#9
Text-to-Image votes	3,149	2,856	41,957
Single Image Edit score	1520±9	1491±9	1387±4
Single Image Edit rank	#1	#2	#12
Single Image Edit votes	6,704	5,676	157,693

Sunburst leads Nano Banana 2 by 160 points for text-to-image generation and 133 points for single-image editing. Flare’s corresponding leads are 138 and 104 points.

That is a strong early preference signal, and the editing result is consistent with OpenAI’s stated priorities. It makes Sunburst a sensible first test for controlled revisions.

The sample sizes matter, though. Both OpenAI entries are marked Preliminary, with only a few thousand votes. Google’s entry has 41,957 generation votes and 157,693 editing votes. The new entries have more room to move as comparisons accumulate.

Arena points also aren’t percentages. A 160-point lead doesn’t translate into a fixed percentage improvement in image quality, and the ranking reflects Arena’s prompt distribution. It doesn’t establish which model handles your packaging, typography, references, or acceptance criteria best.

I’d use the leaderboard to choose evaluation order, then measure performance on the application’s actual workload.

Where Nano Banana 2 changes the implementation

Search can be part of generation

Google documents both Web Search and Image Search grounding for Gemini 3.1 Flash Image. Retrieved text and images can inform generation using current web information.

This applies when the Google Search tool is enabled and its attribution requirements are followed. Merely selecting the model doesn’t make every output grounded.

For a travel application, educational diagram, visual search interface, or information graphic, that integration can reduce the work needed to assemble context. A landmark illustration can use retrieved references; a localized graphic can combine factual context with rendered text.

GPT-Image-2.5 doesn’t document equivalent native grounding at the image-model level. An application can supply its own retrieved context and reference images, which narrows the practical difference. If the application already uses Gemini, keeping retrieval and generation in that workflow may be simpler.

Reference scale is explicitly documented

Google highlights identity preservation for up to five characters and fidelity for up to 14 objects in a workflow.

Those figures are useful when scoping compositions with several recurring subjects. They are documented capability claims, rather than a guarantee that every arrangement will preserve every detail.

OpenAI emphasizes strong reference preservation, especially with Sunburst, but the comparison doesn’t provide equivalent character and object counts for its models. I’d separate documented reference scale from observed fidelity during testing.

Localization has a clear place in the feature set

Nano Banana 2 emphasizes international text rendering and translation of text inside an existing visual. That is useful for adapting one campaign across markets.

OpenAI emphasizes infographic accuracy, hierarchy, and layout. For a static advertisement or UI concept where exact spatial structure dominates, I’d try GPT-Image-2.5 first. For multilingual graphics or visuals whose copy depends on retrieved information, I’d start with Google.

Both still need output verification when numerical or legal copy matters. A convincing layout can contain incorrect text.

Canvas requirements can decide the model before quality does

Nano Banana 2 supports 0.5K, 1K, 2K, and 4K output, spanning the documented 512px-to-4K range. Its extreme aspect ratios include 1:4, 4:1, 1:8, and 8:1.

That gives it a straightforward advantage for panoramic backgrounds, narrow mobile creatives, tall product displays, and campaigns needing many canvas shapes.

GPT-Image-2.5 supports custom dimensions within an approximately 1:3 to 3:1 aspect-ratio range. Its documented limits are:

Maximum edge: 3840 pixels.
Maximum output area: 8,294,400 pixels.

Those constraints should stay explicit in application validation. “Supports 4K” would obscure the difference between OpenAI’s limits and Nano Banana 2’s 4096×4096 4K tier.

OpenAI has a separate practical advantage: transparent PNG and WebP backgrounds are explicitly supported. That matters for product cutouts, composited design elements, and assets that need an alpha channel.

My routing decision here would be mechanical: check canvas dimensions and transparency requirements before spending time comparing creative quality.

Photorealism needs its own evaluation

I wouldn’t infer a universal photorealism winner from the Arena ranking.

OpenAI describes improvements to natural lighting, texture, and recognizable reference subjects. Google makes similar claims about detail, texture, lighting, and photographic quality.

Some early subjective comparisons have favored Nano Banana 2 for camera feel, materials, and natural product scenes, while favoring GPT-Image-2.5 for controlled edits and text-heavy layouts. Those observations are useful leads, but they aren’t standardized cross-provider measurements.

For a production evaluation, I’d include skin and hair, glossy and matte products, transparent materials, fabric, food, architecture, indoor lighting, shallow depth of field, and identity preservation from reference photos.

The metric I care about is cost per accepted image. A model that produces one exceptional sample can still be expensive if most outputs need another render or manual correction.

One shared product prompt

The supplied comparison uses this exact prompt:

Photorealistic product photograph of a matte black water bottle standing on a pale concrete ledge. Soft morning light from the left, gentle reflections, shallow depth of field. Centered composition, Include ONLY this text (verbatim): headline "YOURS TO CREATE" in bold sans-serif across the top, subhead "Limited Edition" smaller at the bottom. No other text or logos.

GPT-Image-2.5 Sunburst

Nano Banana 2

I’d score this prompt separately for exact copy, text placement, bottle geometry, material appearance, lighting direction, and unwanted logos. It exercises several requirements at once, so a single overall preference can hide the reason an image fails acceptance.

Compare billing at the image level

The pricing models encourage different budgeting approaches.

GPT-Image-2.5 uses token billing, with consumption affected by quality settings. Nano Banana 2 publishes image-output costs by resolution, making that part of the budget easier to estimate.

Official billing unit	Price
GPT-Image-2.5 text input	$5 / 1M tokens
GPT-Image-2.5 image input	$8 / 1M tokens
GPT-Image-2.5 image output	$30 / 1M image tokens
Nano Banana 2, 0.5K	$0.045 / image
Nano Banana 2, 1K	$0.067 / image
Nano Banana 2, 2K	$0.101 / image
Nano Banana 2, 4K	$0.151 / image

Comparing OpenAI’s $30 with Google’s $60 per million image tokens doesn’t establish that OpenAI costs half as much. The providers tokenize images differently, and OpenAI’s quality ladder changes consumption.

Google’s published pricing also includes Batch API image-output equivalents approximately 50% below standard pricing:

Resolution	Standard	Approximate Batch equivalent
0.5K	$0.045	$0.022
1K	$0.067	$0.034
2K	$0.101	$0.050
4K	$0.151	$0.076

For asynchronous asset production, that is a meaningful feature. For interactive generation, I’d evaluate the standard path separately.

OpenAI’s quality controls support another useful pattern: inexpensive drafts followed by more expensive final renders. Both variants expose low, medium, high, xhigh, max, and auto; the selected setting belongs in both cost and latency measurements.

A unified API can simplify routing

If I wanted one integration for both families, CometAPI is one option. The source’s quoted rates for both Flare and Sunburst are $4 per million text-input tokens and $24 per million output tokens, versus the corresponding official $5/$30 rates; image-input pricing requires a current provider quote.

The same quoted gateway pricing for Nano Banana 2 is $0.0360, $0.0536, $0.0808, and $0.1208 per image at 0.5K, 1K, 2K, and 4K respectively. Batch availability needs checking with the provider.

The engineering value is a common integration through which the application can select a model per request. I’d still keep provider-specific constraints visible in the routing logic.

The routing policy I’d put into an application

I’d make model selection follow the request’s constraints and the cost of rework.

Request characteristic	First model I’d evaluate
Precise edits with minimal unrelated change	Sunburst
Final campaign or product asset	Sunburst
Rapid OpenAI variants and everyday generation	Flare
Transparent PNG or WebP asset	GPT-Image-2.5
Current web or visual context needed	Nano Banana 2
Extreme vertical or horizontal canvas	Nano Banana 2
Native resolution tiers through 4K	Nano Banana 2
Multilingual text or translation inside a visual	Nano Banana 2
Asynchronous volume with published Batch pricing	Nano Banana 2
Several recurring characters or objects	Nano Banana 2 for its documented reference scale
Photorealistic scenes without other constraints	Evaluate both on representative prompts

For an editing-heavy product, I’d begin with Sunburst and test whether Flare meets the same acceptance criteria at lower latency. For a Gemini application generating grounded diagrams or localized assets in many shapes, I’d begin with Nano Banana 2.

Mixed workloads justify using all three. One possible flow is grounded concept generation with Google followed by a controlled Sunburst revision. Another is Flare for initial variants, Sunburst for difficult final edits, and Google for canvas shapes outside OpenAI’s range.

Those are architectures I’d evaluate, not measured guarantees that switching models improves a result. Any handoff belongs in the same reference-preservation tests as a single-model editing sequence.

Before committing, I’d run identical prompt sets at comparable dimensions and concurrency, record actual latency and billed cost, and judge the final assets against explicit acceptance criteria. The preliminary leaderboard makes GPT-Image-2.5 a strong starting point for quality and editing; the production requirements determine whether it earns the request.

Originally published at cometapi.com

Free ChatGPT for Students: What I’d Check Before Paying for Plus

Ryan Cole — Mon, 21 Sep 2026 09:32:44 +0000

College students can use ChatGPT for free. A student email address, however, does not automatically unlock ChatGPT Plus.

For the 2026 academic year, I’d separate access into three buckets: the public Free plan, a personal Plus subscription, and a university-managed ChatGPT Edu workspace. They have different limits, billing arrangements, and data policies. The two-month student promotion from 2025 is a fourth case, but its claim window has closed.

My first step would be to check the university’s software portal. Paying for a personal subscription before checking campus access can mean buying capabilities the institution already provides.

The 2025 student offer has expired

OpenAI offered eligible college students in the United States and Canada two months of ChatGPT Plus at no cost. The claim window ran from March 31 through May 31, 2025.

That date matters. An article describing this as an offer available “right now” in 2026 is mixing a historical promotion with current access.

The promotion worked as follows:

Students at qualifying institutions verified enrollment through SheerID in the ChatGPT interface.
The two free months started when the student claimed the offer.
Existing paid Plus subscribers were also eligible, with the offer credited to their accounts.
Normal subscription billing resumed after the promotional period unless the student canceled.

Students outside the eligible countries, or those who missed the May 31 deadline, could not claim this particular offer.

There is no permanent, globally available free Plus entitlement for college students described here. Future seasonal offers are possible, but I wouldn’t budget around an unannounced promotion.

What those two months provided

The offer gave students the normal Plus subscription benefits for the promotional period. It was a temporary upgrade to the paid product, with the same applicable usage limits.

Those benefits included access to more capable models, priority availability during busy periods, higher messaging limits, and more generous file uploads. Expanded data analysis, image generation, multimodal interactions, and voice features also made Plus more useful for sustained academic work.

Reporting around that period included research tools and the GPT-4.5 preview. I’d treat those as historical feature references: a model available during the 2025 offer is not a promise about the 2026 model picker.

For coursework, the practical gains were straightforward: longer sessions reviewing materials, more room to work with research documents, and fewer interruptions while generating practice problems or analyzing datasets.

Check campus access before comparing subscription prices

ChatGPT Edu is an institutional offering for universities. It supports students, faculty, researchers, and campus operations, with administrative and privacy controls suited to a managed workspace.

The institution pays for access, so an eligible student may have no direct subscription charge.

Arizona State University, the University of Oxford, and the Wharton School of the University of Pennsylvania have been cited as examples of university AI adoption. I would still check the actual campus entitlement. A university partnership alone does not establish that every student, department, or course receives identical access.

The useful questions are concrete:

Is my account eligible for the university’s ChatGPT workspace?
How do I activate access with university credentials?
Which models and tools are enabled?
What usage limits and research-data rules apply?

Why Edu can matter more than a personal upgrade

For me, the most consequential Edu feature is its data policy: workspace data is not used to train OpenAI’s models. That is especially relevant when working with thesis drafts or unpublished research.

It does not, by itself, authorize uploading every research dataset. The university’s rules still determine what belongs in that workspace.

Edu also offers higher usage limits and tools for working with spreadsheets, CSVs, and PDFs. Those capabilities support statistical analysis, visualization, and document summarization. Universities can create and share custom GPTs inside their workspace, such as a course tutor or grant-writing assistant.

Model access has included GPT-4o, with access to newer models depending on the offering and rollout. I would avoid interpreting “higher limits” as “unlimited”: the workspace’s actual limits are what determine whether it supports a long analysis session.

Where the public Free plan is enough

The Free plan remains useful for bounded tasks: explaining a compiler error, reviewing a short function, brainstorming an essay outline, or summarizing a short reading.

I’d start there if my workload mostly consists of short, independent requests. The friction becomes more visible when a task needs repeated file uploads, extended reasoning, or a long uninterrupted conversation.

Free access can involve dynamic message caps and reduced access to more capable models after a limit is reached. Data analysis, uploads, image generation, and advanced reasoning features can also have tighter restrictions.

Specific model names need care. References to GPT-4o mini, GPT-4o, or GPT-5.2 do not establish a stable Free-plan entitlement for all of 2026. The available models and their limits need to be checked against the current plan and account.

Compare the workload, then the price

The personal Plus price discussed here is $20 per month. Whether that makes sense depends on how often the Free plan interrupts useful work.

Decision point	Public Free plan	Personal Plus subscription	University Edu workspace
Who pays?	No subscription charge	Student or another individual payer	Institution
Access limits	Lower, dynamic limits	Higher limits, still subject to caps	Higher institutional limits
Documents and datasets	More restricted uploads and analysis	More generous uploads and analysis	Analysis tools within a managed workspace
Training policy	Data may be used, depending on controls	Data may be used unless opted out	Workspace data is not used for training
Main access requirement	Public account	Paid subscription	University eligibility and provisioning

I wouldn’t use an old comparison table listing o1-preview, “legacy models,” DALL-E 3, or a blanket 5× limit increase as a current purchasing specification. Those details are tied to particular product periods, models, and tools.

Long documents introduce a separate constraint

The context window limits how much material a model can consider at once. A long conversation can lose useful earlier detail, which becomes noticeable when discussing something like a 20-page dissertation.

A paid plan may provide access to models with larger context windows, but subscription tier alone is not a complete specification. The selected model and product behavior matter.

I’d check that separately from message limits. More messages do not automatically mean the model can consider the entire document and conversation in every response.

Alternatives need the same eligibility check

Google announced a student offer for Google One AI Premium, which bundled Gemini Advanced and other tools, providing eligible U.S. college students free access through June 30, 2026, subject to registering by the required deadline.

The access end date and registration deadline are different things. Seeing “free through June 2026” does not establish that enrollment is still open.

For model selection, Gemini is relevant to workflows involving images, video, and Google Search retrieval. Claude is another option for long-document reading and summarization. Neither observation establishes that the required features are free or unlimited; those depend on the applicable plan.

For a student building software that needs multiple providers, CometAPI exposes models through a unified, OpenAI-style REST API, with model selection via a model string. That can reduce provider-specific integration work, but API access belongs in a separate cost comparison from a free ChatGPT account or a campus subscription.

My purchase trigger would be a recurring constraint: hitting message caps during productive work, needing more document analysis, or requiring a capability unavailable through campus access. Until one of those shows up, I’d use the free account and check the university’s provisioning options first.

Originally published at cometapi.com

Building a Resilient Multi-Model AI Stack in 2026

Ryan Cole — Mon, 21 Sep 2026 07:12:47 +0000

The Short Version

For an OpenAI-compatible migration, change the SDK endpoint to:

https://api.cometapi.com/v1

Then replace the OpenAI key with a gateway token. The same integration exposes more than 500 frontier models, including GPT-5.5, Claude Opus 4.7, and Gemini 3.1 Pro. The advertised pricing reduction is 20% to 40% compared with official direct rates.

That configuration change is small. The architectural change is more important: production AI features no longer need to depend on one provider, one region, or one model family.

Why I Prefer a Multi-Model Architecture

A single-provider dependency creates a predictable failure mode. If the provider develops elevated latency, throttles a tenant, or returns 429 Too Many Requests, every feature tied to that endpoint is affected.

I have seen this happen even when an account is operating within its documented Tier 5 limits. If the application hardcodes one provider, the operational choices at 1:00 AM are limited to waiting for recovery or shipping an emergency patch.

A unified gateway such as CometAPI provides another option: move a workload to a comparable model or region without changing the application’s message format. For example, reasoning traffic can be shifted to Claude Opus 4.7 from an operational dashboard while the rest of the application continues using the same client integration.

This is useful even when OpenAI remains the default. Anthropic and Google models such as Claude Opus 4.7 and Gemini 3.1 Pro can outperform GPT-4o on particular coding and multimodal reasoning workloads. Model choice should be a workload decision, not an accidental consequence of whichever SDK was installed first.

Pricing Snapshot

Bulk token purchasing and routing can materially change the economics of an AI feature. The following prices were verified in May 2026 through the gateway’s pricing information.

Model	Official Price (Input / 1M)	Gateway Price (Input / 1M)	Total Savings
GPT-5.5 Pro	$30.00	$24.00	20%
GPT-5.5	$5.00	$4.00	20%
Claude Opus 4.7	$3.75	$3.00	20%
Claude Sonnet 4.6	$3.00	$2.40	20%
Gemini 3.1 Pro	$2.00	$1.60	20%
DeepSeek V4 Pro	$0.52	$0.42	20%
Grok 4.20	$2.00	$1.60	20%

At 100 million GPT-5.5 input tokens per month, direct billing is approximately $3,000. At the listed gateway rate, the same volume costs $2,400, leaving a $600 monthly difference.

That is large enough to cover a staging environment or materially reduce the operating cost of a support agent. It also gives teams room to use different models for different request classes instead of forcing every request through the most expensive option.

Model Selection by Workload

The catalog covers text, image, video, and audio models. The practical mapping looks like this:

Workload	Models	Typical Use
Reasoning	GPT-5.5 Pro, Claude Opus 4.7	Complex planning and autonomous agents
Agentic coding	Kimi K2.6, Qwen3.6-Plus	Repository-scale refactors and “Vibe Coding”
Long context	Grok 4.20, with 2M tokens	Large logs and document analysis
Multimodal	Gemini 3.1 Pro, GPT Image 2	Video analysis and production design
Fast response	DeepSeek V4 Flash	High-volume classification

The service claims a 99.9% availability SLA and an average response time below 400ms. Its routing layer is intended to bypass high-latency nodes when a regional provider is degraded.

Those figures should still be validated against your own traffic patterns. Latency distributions, streaming behavior, payload size, and model-specific limits matter more than a single average.

The Migration Is a Configuration Change

The OpenAI SDK remains the client. The endpoint and credential change; the request structure stays the same.

import os
from openai import OpenAI, APIError

# Step 1: Initialize using the gateway credentials
client = OpenAI(
    # Point to the unified endpoint
    base_url="https://api.cometapi.com/v1",
    # Use the gateway token from environment variables
    api_key=os.getenv("COMETAPI_API_KEY")
)

def run_ai_task(prompt, model="gpt-5.5"):
    try:
        # Step 2: Swap models without changing the request shape
        response = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": prompt}],
            temperature=0.7
        )
        return response.choices[0].message.content

    except APIError as e:
        # Unified handling for 401, 429, and 500 responses
        print(f"API Error: {e.status_code} - {e.message}")
    except Exception as e:
        print(f"Unexpected connection error: {str(e)}")

# Test the switch with a reasoning-heavy model
print(run_ai_task(
    "Analyze our system's scalability benchmarks.",
    model="claude-opus-4-7"
))

The important operational detail is that model selection is now data. A request router can choose gpt-5.5, claude-opus-4-7, or another compatible model based on latency, task type, cost, or current availability.

Avoid Building the Proxy Yourself

One documented migration case involved a mid-sized team maintaining its own internal API proxy. One senior engineer handled SDK updates, provider billing changes, and custom failover routing. That system cost more than $8,000 per month to operate while saving only $300 in API charges.

The arithmetic was negative before considering the opportunity cost. A managed gateway provides the routing and provider integration without a platform fee, which is generally a better trade when the team’s actual savings are modest.

Security and Retention

Using a unified endpoint introduces a governance boundary, so its data policies need to be evaluated like any other third-party dependency. The stated controls are:

Prompts and completions are not used to train future model iterations.
Logs are retained for a maximum of 3 months for debugging, then permanently deleted.
The platform is SOC 2 certified and uses end-to-end data encryption.

For proprietary code and regulated workloads, I would still verify the current agreement, retention configuration, regional processing behavior, and incident procedures before routing production data.

Initial Account Credits

The onboarding offer described for testing is:

Create a free account with no credit card required.
Click Add Token in the dashboard to receive a $0.5 bonus.
Make the first API call to receive an additional $1 credit.
Deposit $10 for the first time and receive a $3 reward.
Update base_url and begin using the listed rates.

The total onboarding balance is approximately $1.50 before the first deposit, which is enough to exercise several models in the Playground.

Questions I Would Resolve Before Production

How long does migration take?

Documented migration cases report approximately 8 minutes for enterprise projects because only base_url and api_key change. Messages, temperature, and streaming logic remain the same. Teams with codebases larger than 150,000 lines have reported their unit tests passing immediately after the configuration change without refactoring.

That is the compatibility claim; I would still run integration tests against every model and response mode used by the application.

What happens during an outage?

The design uses multi-region routing. During a major provider fluctuation, requests can be redirected to another region or a comparable model family. This reduces the single-provider failure surface, although it does not eliminate the need for timeouts, retries, circuit breakers, and application-level fallback behavior.

Are the cheaper models downgraded?

The listed model versions are intended to be identical to their official counterparts, with requests routed to the original providers such as Anthropic or OpenAI. The stated 20% to 40% reduction comes from purchasing hundreds of billions of tokens annually at wholesale rates. There are no monthly subscription fees or hidden platform costs in the described pricing model.

Can unused prepaid credit be refunded?

The prepaid system supports refunds for unused balances. Starting with the approximately $1.50 in onboarding credits is the lowest-risk way to test the Playground and model behavior before depositing funds.

Are prompts used for training?

The stated enterprise privacy policy says that neither input nor output is used to train models. Logs are retained for 3 months for debugging and then automatically purged, with no possibility of recovery.

Are image and video models supported?

Yes. The same API key provides access to multimodal models, including GPT Image 2 for image generation and ByteDance’s Seedance 2.0 for video generation. That makes it possible to build an application spanning text, images, and video without maintaining separate accounts for each provider.

Does it support high-concurrency workloads?

The infrastructure is designed for production workloads with thousands of requests per second. Its stated global average latency is under 400ms, and dynamic rate limits are intended to scale with business demand. Actual throughput should be measured using the concurrency, payload sizes, and models that match your workload.

Originally published at cometapi.com

How to Use Midjourney on Discord in 2026

Ryan Cole — Mon, 21 Sep 2026 05:45:21 +0000

Midjourney remains one of the most powerful and aesthetically acclaimed AI image generators in 2026. While a polished web interface exists at midjourney.com, many creators — especially those who value community feedback, rapid iteration in public channels, and the full suite of Discord-specific commands — continue to prefer the original Discord experience.

This comprehensive guide walks you through everything: setup, latest V8.1 model features, advanced prompting, parameters, best practices, troubleshooting, comparisons, and practical recommendations for scaling your workflow efficiently via CometAPI on Cometapi.com.

How to Use Midjourney on Discord in 2026: The Ultimate Beginner-to-Pro Guide for Stunning AI Art Creation

Why Midjourney on Discord Still Matters in 2026

Quick Answer: Midjourney on Discord offers real-time community interaction, easy upscale/variation buttons (U/V), remix capabilities, and access to the latest V8.1 model with improved sharpness, faster generation (4-5x in standard jobs), HD 2K output, and better prompt adherence.

Key Benefits Over Web-Only:

Live feedback in newbie/general channels.
Direct bot interaction with slash commands.
Privacy options via your own server.
Seamless image referencing and blending.

Latest News (as of May 2026): V8.1 (April 30, 2026) brings enhanced aesthetics, better small-detail retention, Raw mode, and HD support across Discord and web. Video generation (image-to-5s clips, extendable to 21s) is maturing.

Getting Started: Setting Up Midjourney on Discord

Step 1: Create or Log Into a Discord Account

Download the Discord app (desktop/mobile) or use the web version.
Sign up with email or use an existing account.

Step 2: Join the Official Midjourney Server

In Discord, click the + icon in the server list.
Select Join a Server.
Paste: discord.gg/midjourney.
Join and verify if required.

Tip: Start in #newbies or #general channels to observe prompts from thousands of users.

Step 3: Subscribe to a Plan

Midjourney is subscription-based (no free tier for heavy use in 2026).

Plan	Monthly Price	Annual Price (effective)	Fast GPU Hours	Relax Mode	Stealth Mode	Max Concurrent Jobs	Best For
Basic	$10	$8/mo ($96/yr)	3.3 hrs (~200 images)	No	No	3 Fast	Testing
Standard	$30	$24/mo ($288/yr)	15 hrs	Unlimited	No	3 Fast/Relax	Most users
Pro	$60	$48/mo ($576/yr)	30 hrs	Unlimited	Yes	12 Fast/3 Relax	Professionals
Mega	$120	$96/mo ($1,152/yr)	60 hrs	Unlimited	Yes	12 Fast/3 Relax	High-volume

Data Point: Standard plan users generate ~15 hours of fast GPU time monthly, sufficient for hundreds of images depending on complexity. Relax mode offers slower but unlimited generations.

Recommendation: Start with Standard for balanced speed and cost. Upgrade for Stealth (private images) if building commercial work.

Step 4: Your First Image – The /imagine Command

In any channel with the Midjourney bot:

Type /imagine and press Tab.
Add your prompt after prompt:.
Press Enter.

Example:

/imagine prompt: a serene mountain lake at dawn, misty fog, photorealistic, cinematic lighting --v 8.1

Midjourney generates a 2x2 grid of 4 images. Use U1-U4 to upscale and V1-V4 for variations.

Accept Terms of Service on first use.

Mastering Midjourney V8.1 Features on Discord (2026 Updates)

V8.1 emphasizes:

Faster generation: Standard jobs 4-5x quicker.
Improved sharpness & detail retention.
Better prompt adherence.
HD 2K support (add --hd or toggle in settings).
Raw mode for less stylized, more literal outputs.

Version Parameter: --v 8.1 (default in many cases, but specify for consistency).

Niji 7 for anime/stylized: --niji 7.

Advanced Prompt Engineering: From Beginner to 3000-Word Pro

Core Structure (Featured Snippet Style):

Subject (main focus).
Details (environment, lighting, mood).
Style/Artistic References (artist, medium, era).
Technical Parameters (--ar, --v, --q, etc.).

Best Practices (Supported by Data):

Keep it concise: Short prompts often outperform long ones. Midjourney processes core concepts best.
Word order matters: Important elements first.
Use commas to separate ideas.
Synonyms over repetition: "Gigantic" > "big big".
Weights: ::2 for emphasis (e.g., red dragon::2).
Negative prompts: Use --no (e.g., --no blur, text).

Prompt Examples by Category

Photorealistic Portrait:

/imagine prompt: middle-aged Asian woman, thoughtful expression, soft natural window light, detailed skin texture, 85mm lens, f/2.8, cinematic, photorealistic --ar 2:3 --v 8.1 --q 2

Fantasy Scene:

/imagine prompt: ancient elven city in glowing forest, bioluminescent plants, epic scale, dramatic volumetric lighting, in the style of Studio Ghibli and Alphonse Mucha --ar 16:9 --v 8.1

Product Visualization:

/imagine prompt: sleek wireless earbuds on marble surface, minimalist, studio lighting, octane render, 8k --ar 1:1

Tips for 10x Better Results:

Add lighting descriptors: "golden hour, dramatic chiaroscuro, backlit".
Camera/ Lens: "shot on Canon EOS R5, 50mm, shallow depth of field".
Artists: "in the style of Greg Rutkowski, Artgerm, WLOP".
Quality boosters: --q 2 (higher quality, more GPU), --stylize 750 (default ~100, higher = more artistic).

Data Insight: Users who iterate with V-buttons and Remix achieve 40-60% higher satisfaction rates in community polls (anecdotal from Discord activity).

Image Prompts & References

Upload an image, then use its URL in prompt: image_url description --iw 1.5 (image weight).

--sref (style reference) and --cref (character reference) for consistency across generations.

Essential Parameters & Commands Table

Parameter	Example	Effect	Use Case
--ar	--ar 16:9	Aspect ratio	Cinematic (16:9), Portrait (2:3)
--v	--v 8.1	Model version	Latest features
--q	--q 2	Quality	Sharper details (higher GPU)
--stylize	--stylize 400-1000	Artistic intensity	Low = literal, High = creative
--chaos	--chaos 50	Variation	More diverse grids
--hd	--hd	High definition	2K output
--no	--no people	Negative	Exclude elements
--tile	--tile	Seamless patterns	Textures, wallpapers

Other Commands:

/describe (upload image → prompt suggestions).
/remix for prompt editing.
/settings for defaults.
/info for your usage stats.

Best Practices & Workflow Optimization

Create Your Own Server: Add Midjourney Bot for private generation (less noise).
Organize Outputs: Use folders in Discord or export regularly.
Iterate Efficiently: Use V1-V4 → Upscale → Remix.
Community Learning: Observe top prompts in popular channels.
Batch Testing: Use --repeat 4 for variations.
Commercial Use: All plans allow general commercial terms (check TOS for specifics).

Pro Tip: Combine with external tools for post-processing (Photoshop, Topaz AI upscaler).

Midjourney on Discord vs. Web vs. Competitors

Discord Strengths: Community, speed of interaction, discoverability.
Web Strengths: Cleaner UI, easier organization.

Vs. Competitors:

Tool	Artistic Quality	Prompt Adherence	Text in Images	Pricing (Entry)	Speed	Best For
Midjourney	Excellent	Good	Fair	$10/mo	Fast (V8.1)	Art, Concepts
Flux 1.1 Pro	Very Good	Excellent	Good	API ~$0.02/img	Very Fast	Photorealism
DALL-E 3	Good	Excellent	Excellent	Via ChatGPT	Fast	Precision/Text
Ideogram	Good	Very Good	Best	Subscription	Fast	Typography

Midjourney leads in "wow factor" and stylized output.

Scaling Beyond Discord: CometAPI Recommendations for Developers & Power Users

Discord is fantastic for exploration, but for production workflows, websites, apps, or high-volume needs, manual prompting becomes a bottleneck.

Enter CometAPI (Cometapi.com): A reliable unofficial Midjourney API provider offering unified access to Midjourney (and 500+ other models) through clean REST endpoints.

Why Integrate via CometAPI?

Programmatic Access: Generate images from code (Python, Node.js, etc.) without Discord.
Cost Efficiency: Pay-per-use or subscription models often cheaper than high-tier Midjourney plans for bulk.
Automation: Build apps, e-commerce mockups, marketing tools, or SaaS features.
Reliability: Handles queuing, retries, and multiple models in one dashboard.
Ease: Simple API keys, detailed docs, and Apifox testing.

How to Get Started with CometAPI Midjourney:

Visit Cometapi.com and sign up.
Generate API key in console.
Call the Midjourney endpoint with your prompt (supports parameters like --ar, --v 8.1).
Receive image URLs instantly or via webhook.

Use Cases:

Dynamic product imagery for e-commerce.
Automated social media content.
AI art pipelines in design tools.
Enterprise bulk generation with consistent styling.

Pro Recommendation: Use Discord for creative ideation and discovery, then pipe refined prompts into CometAPI for scalable production. This hybrid approach maximizes quality and efficiency.

Troubleshooting Common Issues

Rate Limits: Wait or upgrade plan.
Blurred Images: Increase --q or use HD.
Censorship: Avoid sensitive content (strict filters).
Slow Generation: Switch to Relax mode or check server status.
Bot Not Responding: Ensure you're in a channel with permissions; try DM with bot.

Future Outlook & Tips for 2026 Success

With V8.1 and upcoming V9/ video enhancements, Midjourney continues evolving. Focus on prompt mastery, consistent character references, and ethical use.

Actionable Next Steps:

Join Discord server today.
Experiment with 10 prompts using V8.1.
Sign up at Cometapi.com for API access and scale your creations.
Track updates on midjourney.com/updates.

By combining Discord's creative power with CometAPI's programmatic capabilities, you'll unlock professional-grade AI imagery workflows that save time and elevate output.

Ready to create? Head to Discord or CometAPI and start generating today!

Originally published at cometapi.com

DEV Community: Ryan Cole

DeepSeek V4.1 Flash vs V4 Pro: moving production traffic without breaking your budget

Spec comparison: the architecture flipped

Two numbers people keep conflating

Benchmarks: the win is execution-heavy, not universal

Why the serving cost drops

Asymmetric activation

KV cache

Vision and concurrency

Pricing per 1M tokens

Migration

Use explicit model IDs

Re-evaluate, do not just smoke-test

Record what resolved

Workload routing cheat sheet

Traps I have hit

FLUX 3 video over an async HTTP API: requests, polling, keyframes, and real pricing

Status check: this is GA now, not early access

What the model does

Specs

The three-call lifecycle

Complete Python job runner

Image-to-video and keyframes: two schemas, not one

Parameter reference

Prompting: write a shot list, not a mood

Pricing

Cutting iteration cost

FLUX 3 vs Wan 3.0 vs Seedance 2.5

Production notes

Vendor numbers worth knowing

FAQ

What I would ship first

MiMo-V2.5 in practice: 15B active params, native multimodal input, and when Pro is actually worth 3

Architecture: what 310B/15B gets you

Spec sheet

Benchmarks: tool use is the strong signal

Coding and agents

Multimodal

Standard vs Pro

Pricing

Calling it

Where I'd put it

Routing table

The deprecation clock

Quick answers

Qwen3.8-Omni-Flash: Field Notes on a 1M-Context Omnimodal Endpoint

The spec sheet that actually constrains your design

Keys, regions, and why your base URL is weird

Images: typed content blocks

Audio: don't just ask for a transcript

Video: your prompt is the entire game

Set reasoning_effort explicitly. Every time.

Streaming

The parameters worth remembering

Failure modes I've actually hit

Where this model earns its keep

Cost and latency, in practice

FAQ, compressed

One note on gateways

Claude Haiku 5.5 in Production: 1M Context, a 100K Pricing Cliff, and a Tokenizer That Bites Back

What's actually new versus Haiku 4.5

Effort is now a dial

The tokenizer quietly eats ~30% of the headline savings

Long context, with the usual discipline

The 100K cliff is per request, not per excess token

Benchmarks: read the config, not the score

Choosing between the three tiers

Migration notes that will actually bite you

Where it isn't the right tool

Running GLM-5.3-Flash Locally: Memory Budgets, Runtime Choices, and Working Commands

Budget for the checkpoint and the requests

Why 18B active parameters does not solve the memory problem

Start with GGUF for workstation experiments

llama.cpp

Ollama

Use KTransformers when the weights belong in system RAM

Install and prepare the checkpoint

Launch the documented single-GPU configuration

Serve native weights on GPU infrastructure

vLLM

Set `reasoning_effort` explicitly. Every time.