DEV Community: Ryan Cole

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

How to Update Gemini CLI to the Latest Version: Complete Guide, New Features & Pro Tips

Ryan Cole — Mon, 21 Sep 2026 04:35:33 +0000

Gemini CLI has rapidly evolved into one of the most powerful open-source AI agents for developers. By bringing Google's Gemini models directly into your terminal, it enables coding, debugging, deployment, data analysis, and complex agentic workflows without leaving your command line.

As of May 2026, the latest stable release is v0.40.0 (April 28, 2026), with preview and nightly channels delivering even more experimental features. Regular updates bring critical improvements in offline capabilities, agent skills, resource management, themes, interactivity, and integration with the latest Gemini models like Gemini 3.x series.

Failing to update can mean missing out on:

Enhanced security and stability fixes
New sub-agents and parallel task handling
Better context management and MCP (Model Context Protocol) support
Improved performance and lower latency
Accessibility features like colorblind themes

What Is Gemini CLI? A Quick Overview

Gemini CLI is Google's open-source AI agent that turns your terminal into a powerful reasoning and acting (ReAct) environment powered by Gemini models. It supports built-in tools, local/remote MCP servers, interactive shell commands, custom slash commands, and agentic workflows.

Key Capabilities:

Agent Mode: Multi-step planning, tool use, and execution.
Interactive Shell: Run vim, top, or other interactive programs seamlessly.
Context Management: GEMINI.md files, codebase ingestion.
Extensibility: Custom tools, sub-agents, IDE plugins.
Model Access: Automatic updates to latest Gemini models (including experimental ones).

It is free and open-source, with optional paid Google AI subscriptions for higher quotas.

Why Gemini CLI updates matter more now

Gemini CLI is not a tiny utility you install once and forget. Google describes it as an open-source AI agent that brings Gemini directly into the terminal, with support for code understanding, file operations, shell commands, web fetching, and MCP-based integrations. The GitHub project also highlights a free tier for personal Google accounts, Gemini 3 model support, and a 1M token context window, so new releases can affect both capabilities and usage limits.

That matters because Gemini CLI has been moving quickly in 2026. The official release notes separate nightly, preview, and stable channels, and they explicitly recommend the stable release for most users. The latest release notes also show active feature work such as offline search support, GitHub-style themes, MCP resource tools, and a newer memory-management approach.

The practical takeaway is simple: if you use Gemini CLI daily, updates are not just about bug fixes. They can change model routing, auth behavior, available tools, and how safely the CLI behaves in more automated environments.

The latest Gemini CLI news you should know before updating

Gemini CLI updates frequently across three channels: Stable (recommended), Preview, and Nightly.

1) Google changed Gemini CLI service behavior in March 2026

On March 18, 2026, the Gemini CLI team announced service changes that would add more robust abuse detection and prioritize traffic differently based on license type and account standing. The same update said that, starting March 25, 2026, free-tier users would be limited to Gemini Flash models, while Gemini Pro models would require paid subscriptions. Google also reminded users that they can regain more direct control of quotas and billing by using their own paid API key through AI Studio or Vertex AI.

For readers, that means “updating Gemini CLI” is now partly a product-policy issue, not just a software-version issue. Two users on the same version may still experience different behavior depending on account type, model choice, and traffic conditions.

2) The April 2026 release stream added more utility

The April 28, 2026 release notes for v0.40.0 describe several visible improvements:

Offline Search Support: Bundled ripgrep for fast local codebase searching without internet.
GitHub-Style Colorblind Themes: Improved accessibility and customization.
Advanced MCP Resource & Memory Management: New resource tools for better handling of external contexts and tools.
Improved Narrative Flow & UI/UX: Smoother interactions and storytelling in agent responses.
Streamlined Local Model Support: Easier integration with on-device or self-hosted models.

Recent preview/nightly additions include sub-agents for parallel workflows (around v0.36+), enhanced plan mode with review steps, tab autocomplete, notifications, and better error handling for transient issues.

Why These Matter: Developers report 2-5x productivity gains in complex tasks like bug fixing, deployment, and data pipelines due to these features. Sub-agents help prevent context overload by delegating subtasks.

3) Security reporting has made update hygiene more important

A recent security report warned that malicious campaigns were impersonating the official Gemini CLI, including fake websites, cloned repositories, misleading social posts, and typosquatted npm packages. The safest response is to use only official sources and verify the package name before installing or updating.

How to update Gemini CLI the official way

The built-in update command

The official Gemini CLI cheatsheet lists gemini update as the command to update to the latest version. It also lists --version / -v as the flag for showing the current CLI version, which is the quickest way to confirm whether the update worked.

gemini update

gemini --version# orgemini -v

The same cheatsheet also shows that Gemini CLI is designed as a command-line app with REPL mode, prompt mode, resume mode, and extension/MCP management built in, so version upgrades can affect both the core assistant and the surrounding workflow commands.

Install and reinstall paths you may also see

Gemini CLI can be installed globally with npm using npm install -g @google/gemini-cli. Quick-install options via npx @google/gemini-cli, global npm installation, and Homebrew on macOS/Linux.

That gives you a useful rule of thumb: if your install is healthy, use the built-in gemini update path. If the install itself is damaged, inconsistent, or stuck between package managers, a clean reinstall from the official package source is often the safer recovery route. That second sentence is an operational recommendation, not a direct vendor claim.

Release-channel choice matters

Gemini CLI’s official release notes define three channels: nightly, preview, and stable. Nightly contains the most recent changes, preview is for experimental features and early feedback, and stable is the recommended option for general use.

If you want to minimize surprises, the stable channel is the right default. If you publish content, manage teams, or rely on Gemini CLI in automation, stable should be your baseline and preview should be treated as a test lane.

Comparison table: the best ways to update Gemini CLI

Update path	Best for	What you do	Notes
gemini update	Most users on a healthy install	Run the built-in CLI update command, then confirm with gemini --version / gemini -v.	This is the most direct, official update path.
Fresh reinstall via official package	Broken or inconsistent installs	Use the official package route shown in the docs: npm install -g @google/gemini-cli. The README also lists npx and Homebrew options.	Best when your install method is tangled or your package manager state is unreliable.
ACP Agent Registry inside an IDE	JetBrains, Zed, or other ACP-compatible IDE users	Gemini CLI is officially available in the ACP Agent Registry, which lets supported IDEs install and update it directly.	Great for teams that prefer updating from inside their editor.
Switch release channels	Testers and early adopters	Use the release notes to decide between nightly, preview, and stable. The docs recommend stable for general use.	Nightly and preview move faster, but they can be noisier.

How to Update Gemini CLI: Step-by-Step Guide

Step 1: Check Your Current Version

Bash
gemini --version

Or:

Bash
gemini -v

This confirms your installation and version.

Step 2: Update Methods

Recommended for Most Users (Global Install):

Bash
npm install -g @google/gemini-cli@latest

Specific Update Command:

Bash
npm update -g @google/gemini-cli

Preview Channel (Experimental Features):

Bash
npm install -g @google/gemini-cli@preview

Nightly Channel:

Bash
npm install -g @google/gemini-cli@nightly

Without Installation (npx – Always Latest):

Bash
npx https://github.com/google-gemini/gemini-cli

This is ideal for testing or one-off use.

Step 3: Post-Update Verification and Restart

Close and reopen your terminal.
Run gemini --version again.
Start a new session: gemini and sign in if prompted (Google account or API key).

Pro Tip: Use npm install -g @google/gemini-cli@latest --force if you encounter permission or cache issues.

Step 4: Verify your account and release channel

The current docs note that most individual users can sign in with a personal Google account, while organizations and some enterprise setups may need a Google Cloud project or different auth path. The same docs recommend starting Gemini CLI and logging in with a Google account for the simplest local workflow.

That matters because a successful upgrade may still feel “wrong” if your account type changed, your quota changed, or the CLI now routes you to a different model set. The March 2026 service update made those distinctions more visible.

Troubleshooting when the Gemini CLI update fails

Mixed package managers can cause messy installs

Update loops and PATH conflicts when legacy installs, npm, and pnpm get mixed together. Community issue reports also describe auto-update confusion when pnpm installations are detected as npm installs. The lesson is not that Gemini CLI is broken; the lesson is that package-manager consistency matters.

If gemini update does not behave as expected, check how the tool was originally installed, and avoid mixing global installs across npm, pnpm, and other package managers on the same machine.

Some environments have hit installation or runtime compatibility issues

There are also historical issue reports about Node.js version compatibility and PATH problems after upgrades. If you manage a team environment, it is smart to standardize Node.js versions and document the exact install method alongside the CLI version.

Security-first update hygiene is not optional anymore

Because recent reporting has highlighted fake Gemini CLI download campaigns, always verify that you are using the official google-gemini/gemini-cli repository or the official Gemini CLI documentation before you update. The official repo and docs are the safest anchor points; random “early access” installers are not.

Troubleshooting Common Update Issues

Permission Errors: Use sudo npm install -g ... (macOS/Linux) or run PowerShell as Administrator (Windows). Better: Use nvm or fix npm permissions.
Update Not Applying: Clear npm cache: npm cache clean --force, then reinstall.
Version Mismatch: Ensure you're using a fresh terminal session.
Proxy/Firewall: Configure npm proxy settings.
Node.js Version: Require Node.js 18+ (recommend 20+).
Broken Install: Uninstall first: npm uninstall -g @google/gemini-cli, then reinstall.

Monitor GitHub issues for platform-specific bugs.

Advanced Configuration After Updating

Authentication: gemini → Sign in with Google for higher quotas or use Gemini API key.
GEMINI.md: Create in project root for persistent context and custom instructions.
Slash Commands & Custom Tools: Extend functionality.
MCP Servers: Connect local/remote tools for enhanced capabilities.
Themes & Settings: Customize via config for accessibility.
Plan Mode: Enable for safer multi-step executions with review.

Comparison Table: Gemini CLI Update Channels

Feature/Aspect	Stable (v0.40.0)	Preview	Nightly	npx (No Install)
Stability	High (Recommended)	Medium-High	Low (Experimental)	High
Latest Features	Balanced	Early Access	Cutting-Edge	Always Latest
Update Frequency	Weekly/Monthly	Frequent	Daily	On-demand
Use Case	Production/ Daily Work	Testing New Features	Developers/Contributors	Quick Tests
Quota/Performance	Optimized	May vary	Variable	Same as installed
Risk	Lowest	Moderate	Highest	Low

Real-World Use Cases and Productivity Gains

Code Generation & Refactoring: Ingest entire repos via context.
Debugging & Deployment: Interactive shell + agents for Cloud Run, etc.
Data Analysis: Combine with local tools.
Content & Research: Offline search + Gemini reasoning.
Agentic Workflows: Sub-agents handle parallel tasks like testing, docs, and deployment.

Users report significant time savings, with features like plan mode reducing errors.

Integrating with APIs: Why CometAPI Complements Gemini CLI Perfectly

While Gemini CLI excels in terminal interactivity, pairing it with a unified API provider like CometAPI unlocks production-scale advantages:

Key Benefits of CometAPI for Gemini Workflows:

Cost Savings: Up to 20%+ lower prices than direct Google Gemini APIs (e.g., Gemini 2.5 Pro at competitive input/output rates).
Unified Access: One API key for Gemini models + others (GPT, Claude, etc.) – seamless switching.
High Reliability & Speed: Optimized routing, reduced latency for CLI-augmented scripts.
Easy Integration: Standard OpenAI-compatible format. Call Gemini models from scripts or custom MCP tools via CometAPI endpoint (https://api.cometapi.com/).
Scalability: Higher rate limits and enterprise features without managing multiple keys.

Example Integration in Your Workflow: Use Gemini CLI for interactive sessions, but route heavy batch jobs or custom agents through CometAPI SDKs/scripts for cost efficiency and reliability.

Recommendation for CometAPI.com Readers: Sign up at CometAPI.com, grab your key, and configure it in custom tools or external scripts. It's the smartest way to scale Gemini-powered development beyond the terminal while keeping costs low and performance high. Whether building AI apps, automating pipelines, or experimenting with agents, CometAPI ensures you maximize value from the latest Gemini models.

Conclusion: Stay Ahead with Updated Gemini CLI + CometAPI

Updating Gemini CLI to v0.40.0+ is straightforward yet unlocks transformative terminal AI capabilities. With rapid releases focused on agents, context, and usability, it's a must-have for modern developers.

For optimal results, combine the interactive power of Gemini CLI with the cost-effective, unified API access from CometAPI. This hybrid approach delivers the best of both worlds: seamless local workflows and scalable, affordable cloud intelligence.

Action Steps Today:

Update now: npm install -g @google/gemini-cli@latest
Explore new features in v0.40.0
Visit CometAPI for Gemini API integration and savings

Stay productive, innovate faster, and build the future from your terminal.

Originally published at cometapi.com

Claude Sonnet 5: What the Leaks Mean for Developers

Ryan Cole — Mon, 21 Sep 2026 04:06:37 +0000

As of June 23, 2026, Anthropic has not announced Claude Sonnet 5. Nevertheless, the model identifier claude-sonnet-5 has reportedly appeared in internal configurations, error logs, Claude tooling, and partner developer platforms.

That is not launch confirmation, but it usually means release preparation is well underway. Current speculation points to late June 2026, potentially June 24 or the week beginning June 29.

The timing matters. Anthropic recently launched Fable 5 and Mythos 5, models positioned above Opus for demanding reasoning and agentic work, before suspending access worldwide after a US export control directive cited national security concerns related to a reported jailbreak vulnerability. The suspension affected domestic users as well. Anthropic has not said that development stopped; the accurate statement is that access was suspended.

That leaves the Sonnet tier in an especially important position: capable enough for serious development work, but generally fast and economical enough to deploy at scale.

Where Sonnet Fits in Anthropic's Lineup

Anthropic's current model tiers remain fairly straightforward:

Haiku 4.5: optimized for speed.
Sonnet 4.6: the general-purpose balance of intelligence, latency, and cost.
Opus 4.8: the highest-end option for difficult reasoning and long-running work.

Fable 5 and Mythos 5 were introduced as a more capable class above Opus, but their availability is currently suspended. Sonnet 4.6 therefore remains the practical default for many coding and agent workloads, while Opus 4.8 handles tasks where failure is expensive or the reasoning horizon is unusually long.

Sonnet models have historically been popular because they deliver much of the capability developers need without Opus-level pricing and latency.

What the Developer-Platform Sightings Suggest

Recent reports from June 22-23 mention claude-sonnet-5 in Anthropic configurations, Claude applications and tools, and cloud partner environments such as Vertex AI or similar platforms.

There was also an earlier reference to Sonnet 5, reportedly under the codename Fennec, with dated identifiers such as:

claude-sonnet-5-20260203

The evidence being discussed publicly includes:

Model references in partner infrastructure error logs and model lists.
Community posts and X discussions showing “Sonnet 5” labels.
A release cadence consistent with Anthropic's recent pattern of shipping major models every few weeks or months.

None of this establishes a public release date. It does indicate that the model may have progressed beyond an internal research artifact.

Expected Release and Availability

The current rumor window is late June 2026, with June 24 often cited as the earliest possible date. Another version of the rumor points to the week beginning June 29. Anthropic has not confirmed either date.

If the model ships, the likely distribution path is Claude.ai, the Anthropic API, and cloud partners such as AWS Bedrock and Vertex AI. The exact rollout will depend on Anthropic's internal testing and safety checks.

The suspension of Fable 5 and Mythos 5 is a useful reminder that technical readiness and public availability are separate questions. A model can appear in infrastructure before Anthropic is prepared to expose it broadly.

Likely Areas of Improvement

Everything below is projection. Sonnet 5 has not been officially launched, so its capabilities, pricing, and benchmarks remain unconfirmed.

1. More Reliable Coding Agents

Sonnet 4.6 improved codebase understanding, bug fixing, long-session consistency, and instruction following. Anthropic reported that early Claude Code users preferred Sonnet 4.6 over Sonnet 4.5 approximately 70% of the time, and preferred it over Opus 4.5 approximately 59% of the time.

For Sonnet 5, I would expect the emphasis to remain on agentic software development:

Reading and navigating large repositories.
Planning changes across multiple files.
Calling tools consistently.
Avoiding unnecessary rewrites.
Running verification steps before reporting completion.
Maintaining context over long coding sessions.

This is where the Sonnet tier has commercial leverage. Opus may provide deeper reasoning, but Sonnet is often the model teams can afford to call repeatedly inside production workflows.

2. A Smaller Gap With Opus

Anthropic's official pricing currently lists:

Claude Opus 4.8: $5 per million input tokens and $25 per million output tokens.
Claude Sonnet 4.6: $3 per million input tokens and $15 per million output tokens.

If Sonnet 5 keeps the existing Sonnet pricing tier while improving its reasoning quality, it could become a particularly strong option for coding agents, enterprise automation, internal tools, and research assistants.

The useful metric will not be benchmark score alone. Teams should measure cost per successful task, including retries, human corrections, and failed tool calls.

3. Better Use of Long Context

Claude Sonnet 4.6 introduced a 1M-token context window in beta. Anthropic's pricing documentation states that Fable 5, Mythos 5, Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6 include the full 1M-token context window at standard pricing.

Sonnet 5 will likely continue in that direction, potentially offering a 1M+ token context window. The important improvement would not simply be the maximum token count. Long-context systems are useful only when the model can retrieve and apply information buried deep in a repository, contract, research archive, or support history.

Better attention across long inputs and fewer missed details would matter more than a larger headline number.

4. More Capable Computer and Tool Use

Sonnet 4.6 made substantial progress on computer use, web tasks, spreadsheet navigation, and multi-step workflows. Opus 4.8 extended the agentic direction with dynamic workflows in Claude Code, including planning large tasks and running many parallel subagents.

Sonnet 5 may bring some of that behavior to a cheaper and faster model. The likely target workloads include:

Browser-based agents.
Internal administration tools.
Structured function and tool calling.
Spreadsheet and document workflows.
Software navigation.
Automations that must interact with real systems rather than generate text alone.

5. More Honest Self-Checking

Anthropic's Opus 4.8 launch highlighted a claimed improvement in self-verification: Opus 4.8 was around four times less likely than its predecessor to overlook flaws in code it had written.

That behavior is valuable in production. A model that reports uncertainty, asks for missing context, or admits that tests failed is more useful than one that confidently produces an incorrect result.

If Sonnet 5 inherits some of Opus 4.8's self-checking behavior while retaining Sonnet-level cost and speed, the practical improvement could be larger than a raw benchmark gain.

Sonnet 5 Versus Opus 4.8

The following comparison combines current data for Sonnet 4.6 and Opus 4.8 with projections for Sonnet 5:

Feature	Claude Sonnet 5 (expected)	Claude Opus 4.8	Practical takeaway
Intelligence tier	Mid-tier, balanced	Frontier, highest	Opus for maximum complexity; Sonnet may narrow the gap
SWE-Bench Verified	~82%+ projected	~80-81% for related Opus results	Sonnet could lead on value
Context window	1M+ tokens expected	1M tokens	Roughly equivalent, with a possible Sonnet edge
Input/output pricing per MTok	~$3 / $15 expected	$5 / $25	Sonnet offers substantial savings
Latency	Fast expected	Moderate	Sonnet
Coding and agents	Excellent, potentially with parallel agents	Superior for long-horizon work	Task-dependent
Vision and multimodal work	Improved diagrams rumored	Strong	Unconfirmed Sonnet advantage
Best fit	Daily development, agents, high-volume workloads	Complex research and autonomous work	Sonnet for ROI, Opus for depth

For many coding, analysis, and agent workflows, Sonnet 5 could provide better price-performance. The source estimate is that it may cover 70-80% of common workflows, leaving Opus 4.8 for tasks that require maximum reasoning depth.

That estimate should be validated against real workloads. Blind preferences and benchmark results do not always predict production behavior.

How I Would Route Workloads

Opus 4.8 is currently the safer choice for the hardest tasks because it is official, documented, and available. Anthropic recommends it for complex reasoning, long-horizon agentic coding, and high-autonomy work.

If Sonnet 5 launches, I would treat it as the likely production default for high-volume tasks:

Code review assistance.
Customer-support copilots.
Data extraction.
Research summarization.
Routine code generation and explanation.
Workflow automation.
Agent orchestration.

The routing policy would look something like this:

Use Sonnet 4.6 or Sonnet 5 for routine, high-volume operations.
Escalate architecture reviews, risky code changes, financial analysis, legal reasoning, and long-running autonomous work to Opus 4.8.
Test Fable-class models only when access, policy, and safeguards permit.
Run A/B evaluations before changing the default model.

A unified multi-model API such as CometAPI can reduce the infrastructure work involved in comparing Claude, GPT, Gemini, and other providers, but the evaluation layer still belongs in your application. Routing without measurement is just guesswork.

Prepare Before the Model Ships

Establish a Real Baseline

Capture results from Claude Sonnet 4.6 and Claude Opus 4.8 before testing Sonnet 5. Use representative prompts and production-shaped inputs:

Coding tasks.
Customer tickets.
Internal documents.
Long-context retrieval.
Tool calls.
Strict JSON output.
Known failure cases.

Track at least:

Success rate.
Cost per successful task.
End-to-end latency.
Human correction time.

A model that costs 20% more but cuts manual review by 50% may be cheaper overall.

Keep Model Names Out of Core Business Logic

The Fable 5 and Mythos 5 suspension demonstrates why model availability cannot be treated as permanent. Avoid coupling product behavior directly to one provider or model identifier.

Put model selection behind configuration or a routing layer. That makes it possible to test a new release, shift traffic during an outage, or use different models for different task classes without rewriting the application.

Test Replacement Behavior, Not Just Output Quality

When Sonnet 5 becomes available, compare it with Sonnet 4.6 and Opus 4.8 on the same workload. Include tool failures, malformed output, missing context, retries, and long-running sessions.

The best replacement is not necessarily the model with the highest score. It is the one that produces the lowest cost for an acceptable success rate and correction burden.

What Is Confirmed?

Has Claude Sonnet 5 launched?

No. As of June 23, 2026, Anthropic has not officially released Claude Sonnet 5. The current official Sonnet model is Claude Sonnet 4.6.

When is it expected?

Rumors point to late June 2026. June 24 has been cited as a possible early release date, while another report points to the week beginning June 29. Anthropic has confirmed neither.

What is the model ID?

The reported identifier is:

claude-sonnet-5

That identifier is not official. Anthropic's current documented Sonnet model ID is:

claude-sonnet-4-6

Will Sonnet 5 outperform Opus 4.8?

That is unknown. The likely positioning is stronger cost-performance for Sonnet 5, with Opus 4.8 retaining an advantage in deep reasoning and long-horizon autonomous work. The only reliable answer will come from side-by-side testing on real applications.

What should developers use today?

Keep production workloads on official, available models such as Claude Sonnet 4.6 and Claude Opus 4.8. Build evaluation, routing, and cost tracking now so a future Sonnet 5 release can be tested without turning the launch into an infrastructure migration.

Originally published at cometapi.com

Integrating GPT-5.6: API Access, Real Costs, and Fallback Design

Ryan Cole — Mon, 21 Sep 2026 03:24:36 +0000

When I evaluate a model API, the first successful request is only the starting point. I want to know which route I’m calling, what a completed workflow costs, and what happens when that route stops responding.

For GPT-5.6, I’d approach integration in that order: verify access, test representative workloads, then build the routing and failure behavior around the results.

An OpenAI-compatible interface can reduce integration work. It still leaves decisions about model selection, budgets, and fallback behavior in the application.

Verify the model route before writing the integration

API access lets applications use a model in coding assistants, research agents, support workflows, internal knowledge tools, data analysis, and SaaS features.

The access workflow is straightforward:

Create an account with the API provider.
Generate an API key.
Configure the endpoint.
Select an available model route.
Send a request and consume the response.

The detail I’d verify first is the model identifier. The source guide describes GPT-5.6 options named Sol, Terra, and Luna, and gives gpt-5.6-sol and gpt-5.6-terra as possible route names. Those names need checking against the provider’s current catalog before deployment.

I wouldn’t infer a variant’s performance from its name. The useful comparison is how each available route handles the application’s requirements: reasoning quality, cost, latency, and throughput.

A minimal request

CometAPI is one option for accessing multiple models through a shared API key and an OpenAI-compatible endpoint. The source’s illustrative request uses the following URL and payload:

curl https://api.cometapi.com/v1/chat/completions \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "messages": [
      {
        "role": "user",
        "content": "Explain how a unified API layer helps production AI apps."
      }
    ]
  }'

Set COMETAPI_KEY to the credential issued by the provider, and replace gpt-5.6 if the dashboard lists a different active route.

This demonstrates the request structure; it doesn’t establish that a particular model alias is currently available. I’d confirm that separately before making the route a production dependency.

Decide where model access belongs

A product might begin with one text model and later add separate models for reasoning, coding, fast chat, images, video, and speech. A backup model adds another dependency.

With direct integrations, that can mean multiple credentials, billing dashboards, SDKs, rate limits, and error formats. I’d decide early whether the application should manage those differences itself or put a shared access layer in front of them.

Integration	Operational consequence
One direct provider integration	An outage or limit at that provider can interrupt the application.
Unified API layer	The application keeps a common interface while the underlying model route can change.
Unified API with configured fallback	A failed primary request can be sent to another suitable model or provider route.

A shared interface makes model changes easier to manage. Fallback still needs to be designed and configured; a common request format alone doesn’t define what happens after an error.

This matters for agents, automation, SaaS features, and developer workflows involving tools such as Claude Code or Cursor. As the model stack changes, I want route selection to remain a manageable part of the integration.

Price completed work, including failures

The source does not provide GPT-5.6 token rates, so there isn’t enough information here to calculate a production bill. Current prices need to come from the active route’s pricing information.

Even with those rates, token price is only one input. Long prompts, large outputs, repeated agent calls, retries, and failed requests all affect the cost of delivering a result.

I’d evaluate pricing through three questions:

What does a successful user action cost? Include the requests and retries needed to finish it.
Can the route handle the expected traffic? Check latency, rate limits, errors, and availability.
What happens to cost and behavior during fallback? A backup route becomes part of the production workload when the primary route fails.

A low listed price is useful only if the route also meets the application’s quality and performance requirements.

Compare models on the same workload

I’d compare GPT-5.6 with available alternatives such as Claude, Gemini, DeepSeek, Grok, and Qwen using representative application prompts.

For a coding assistant, I care about whether it solves the coding task. For an agent, I care about tool instructions and repeated execution. For customer support, I care about whether it handles the actual support workflow consistently.

Generic prompts can confirm that an endpoint responds. They give much less evidence about whether the model fits the product.

The comparison should include:

Measurement	What it helps answer
Task quality	Does the output meet the product’s requirements?
Input and output token usage	How much usage does each request generate?
Latency	Does the route fit the user experience?
Error and retry behavior	How often does the workflow need recovery?
Cost per completed workflow	What does useful output actually cost?

Treat trial credit as an evaluation budget

The source advertises $1 in free credit for new registrations at the provider used in the example. I’d check the current offer and supported routes before relying on it.

Trial credit can support initial request tests, output comparisons, token measurements, and checks of latency and error behavior. It should be treated as a limited evaluation allowance.

“Free API” commonly refers to trial credits, a testing quota, a promotion, or temporary access. It does not establish unlimited production usage.

My evaluation sequence would be:

Select a small set of real application prompts.
Record input and output token usage.
Run the same tasks through suitable alternative models.
Measure latency and errors.
Estimate monthly usage from the expected workload.
Test fallback before launch.

This gives the trial a concrete purpose: gather enough evidence to choose a route and budget for it.

Make fallback an explicit application behavior

A provider outage is only one reason a request might need another route. Rate limits, timeouts, latency spikes, and temporary model unavailability can also interrupt a workflow.

The basic fallback sequence is:

Send the request to the primary GPT-5.6 route.
Detect a failure or timeout.
Send the request to a suitable backup model.
Return the backup response if it succeeds.

The word suitable matters. Different models can produce different outputs, so availability alone doesn’t make a model a good replacement.

For chat, a different response may be acceptable. For coding, support automation, or an agent following tool instructions, I’d evaluate the backup against those same task requirements before depending on it.

Fallback can reduce user-facing errors, but it does not guarantee every request will succeed. The backup also needs to be available and capable of completing the task.

Test recovery before an outage forces the issue

I’d include fallback in the initial production work. Waiting for a provider incident leaves both routing behavior and backup output quality untested at the moment they matter most.

The evaluation should establish whether the backup can complete the workflow, maintain acceptable quality, and stay within the application’s latency and cost constraints.

That applies equally to chatbots, coding tools, internal automation, customer support, and high-traffic SaaS features.

Keep production measurements close to the model decision

Model selection shouldn’t end when the integration ships. Long contexts, document-heavy requests, and agent loops can change usage substantially as real traffic arrives.

I’d track average input tokens, average output tokens, cost per user action, cost per workflow, and projected monthly usage from the beginning. Alongside those, I’d watch latency, errors, and fallback behavior.

Those measurements make later changes easier to justify. A different route might reduce cost, improve response time, or handle a task more consistently. A flexible model layer gives the application room to make that change without turning every model release into another integration project.

My launch criteria would be concrete: a verified route identifier, working authentication, acceptable results on real tasks, measured usage, and a tested backup path. That is the evidence I’d want before letting a model API become a dependency users rely on.

Originally published at cometapi.com

One OpenAI Client, Multiple Models: What I Check Before Shipping

Ryan Cole — Mon, 21 Sep 2026 02:25:06 +0000

A shared API client is the easy part of a multi-model application. The harder part is making sure that switching model does not silently change instruction handling, break tool calls, or turn a cheap request into an expensive retry loop.

I use an OpenAI-compatible gateway to keep provider integration out of application logic. The application supplies a gateway URL, a gateway credential, and a model identifier; the gateway handles upstream routing and schema translation. That reduces SDK maintenance, but it does not make the models interchangeable.

Start With the Client, Not the Routing Policy

With the Python SDK, the relevant configuration is base_url and api_key. The JavaScript/TypeScript client uses baseURL. The credential must belong to the endpoint receiving the request: pointing at a gateway while keeping an unrelated provider key is not enough.

A unified multi-model service such as CometAPI is relevant here because it exposes multiple providers through one integration. I keep the endpoint and model IDs in configuration rather than embedding a provider catalog in application code.

import os
from openai import OpenAI

client = OpenAI(
    base_url=os.environ["AI_BASE_URL"],
    api_key=os.environ["AI_API_KEY"],
)

reasoning_response = client.chat.completions.create(
    model=os.environ["AI_REASONING_MODEL"],
    messages=[
        {"role": "system", "content": "You are a precise technical assistant."},
        {"role": "user", "content": "Analyze this system architecture for latency bottlenecks."},
    ],
)
print(reasoning_response.choices[0].message.content)

document_response = client.chat.completions.create(
    model=os.environ["AI_DOCUMENT_MODEL"],
    messages=[
        {"role": "user", "content": "Refine this technical documentation for clarity."},
    ],
    max_tokens=1000,
)
print(document_response.choices[0].message.content)

This uses the official openai Python package. Set AI_BASE_URL to the gateway's documented OpenAI-compatible endpoint and both model variables to identifiers verified in its current catalog. The prompts are smoke tests; a useful architecture review or documentation edit also needs the actual material in the request.

The same client handles both calls. That is the integration benefit, not a promise that every parameter works on every route. For example, the document request's max_tokens=1000 needs to be supported and translated correctly. I would test temperature controls separately rather than assume that temperature=0.2 is accepted by every reasoning model.

What the Gateway Actually Does

For a chat completion, the gateway authenticates the incoming request and reads its model field. It resolves that identifier to an upstream destination, translates the OpenAI-shaped payload into the provider's native schema, and sends the request using the appropriate upstream authentication.

On the return path, it converts the response into the shape the client expects, including content, token usage, and finish reasons where supported. The application can then read response.choices[0].message.content without maintaining a separate response parser for each provider.

Credential ownership is a separate deployment decision. A gateway may supply upstream access, or it may support credentials you configure yourself. I would verify that contract instead of assuming a particular service has a bring-your-own-key vault. Where upstream keys are yours, scope them narrowly, test authentication per provider, and configure billing alerts and usage limits.

This arrangement centralizes integration work. It also centralizes failure: a gateway outage can affect every model behind the endpoint, even when those providers are healthy.

Treat Model Comparisons as Evaluation Inputs

I would not commit a routing policy based on a model launch announcement or an old pricing table. First verify the exact gateway model ID, availability, supported parameters, context limits, and current price. A provider's public model name and a gateway's routing identifier are not necessarily identical.

The supplied comparison describes a July 2026 snapshot: GPT-5.5, reportedly released in April 2026, and Claude Sonnet 5, reportedly released in June 2026. Those release, retirement, pricing, and performance claims need confirmation against current official documentation. They are not established by a successful request through an OpenAI-compatible endpoint.

For reference, these are the snapshot's specific claims, preserved as claims rather than a verified production catalog:

Dimension	GPT-5.5 claim	Claude Sonnet 5 claim
Positioning	Flagship reasoning and agentic model	Most agentic Sonnet release, approaching Opus-class performance at lower cost
Context and output	Roughly 1.05M-token input context; 128K maximum output	1M-token input context, default and maximum; 128K maximum output
Evaluations	Terminal-Bench 2.0: 82.7%; Expert-SWE: 73.1%; GDPval: 84.9%; FrontierMath Tiers 1–3: 51.7%	Largest gains over Sonnet 4.6 concentrated in coding and agentic tasks
Price per 1M tokens	Approximately $5 input / $30 output, standard tier	$2 input / $10 output introductory pricing through August 31, 2026; $3 / $15 thereafter

The same snapshot describes GPT-5.5 as supporting reasoning, tool use, and computer use, with those evaluation scores improving on GPT-5.4. It positions Sonnet 5 for long-document synthesis, legal and financial analysis, instruction following, self-verification, and low hallucination and sycophancy rates. I would treat those descriptions as hypotheses to test on actual workloads, not routing guarantees.

It also claims that earlier gpt-5-chat-latest variants were lightweight, non-reasoning tiers and that the GPT-5.2 Instant/Thinking/Pro line was deprecated in June 2026 with traffic migrated to GPT-5.5. Model lifecycle claims are particularly important to verify before relying on an alias. A familiar name is not evidence of unchanged behavior.

Route by Successful Task Cost

My routing criteria start with the work: prompt complexity, required context, output contract, latency budget, and acceptable cost. Simple classification deserves a cheaper-model evaluation. Multi-step execution needs tests that include tool results and recovery. Long-document analysis needs retrieval and synthesis checks across the document, not just a context-window number.

A flagship reasoning model may be unnecessary for high-volume classification. Likewise, a large document-oriented model may be unnecessary for a constrained code-generation task that a smaller model handles reliably. Neither observation establishes a universal winner; the relevant metric is cost per successful task, including failures and retries.

I would compare candidate routes on task quality, time to first token, total latency, token consumption, JSON/schema validity, context handling, and fallback behavior. Published benchmarks can narrow the candidate set. They cannot validate an application's output contract.

Compatibility Needs Its Own Test Suite

Parameter and Instruction Translation

Anthropic's Messages API expects a top-level system parameter, while an OpenAI-style request can carry system instructions in the messages array. The gateway needs to extract and translate those instructions without losing their meaning. I would explicitly test system prompts rather than infer support from a successful user-only request.

Output limits deserve similar attention. max_completion_tokens and max_tokens are not names to swap blindly across routes. Confirm what the gateway accepts, how it maps the value, and whether the upstream model enforces the requested limit. A parameter that disappears during translation is harder to detect than an explicit validation error.

Unsupported parameters may be rejected, mapped, or stripped, depending on the gateway. None of those behaviors should be assumed safe without inspection. For temperature boundaries, system-message structures, and other edge cases, I want integration tests against every active route.

Tools and Structured Output

A normalized chat response does not establish tool-calling compatibility. OpenAI tool definitions, Anthropic tool use, and Google's function-calling schema have differences, especially around tool-choice constraints and complex nested schemas. Test the definitions the application actually sends, then validate the resulting tool arguments.

The same applies to JSON and schema-constrained output. Receiving syntactically valid JSON is not the same as satisfying the required schema. I would make schema validation part of the success criteria used to compare models and approve fallbacks.

Provider-specific token-bias controls, moderation options, or other proprietary features may have no equivalent in the shared interface. Where those features matter, a documented pass-through mechanism or a direct provider integration may be necessary. One SDK is useful, but losing a required capability is not an acceptable trade.

Streaming and Latency

A streaming gateway must normalize upstream events into OpenAI-compatible Server-Sent Events, such as data: {...}, and forward them incrementally. Buffering the whole response before sending it defeats the point of streaming, even if the final body looks correct.

The source proposes 5–30 milliseconds as a gateway processing-overhead target, excluding upstream transit time. I would treat that as a measurement target, not a service guarantee. An extra network hop also introduces geography and connection-management effects; deployment near the application and upstream connection pooling both deserve inspection.

Model time to first token and completion time can range from hundreds of milliseconds to several seconds, so small proxy overhead may be acceptable. Still, measure gateway processing, network transit, first-token latency, and total completion time separately. A single end-to-end timer cannot explain whether slow responses come from the proxy or the model.

Design Failure Handling Before Enabling Fallbacks

Error normalization is useful only when it preserves enough information to act. Providers can report different status codes and bodies for rejected requests. The source's examples include 400 Bad Request for a safety-related rejection and 422 Unprocessable Entity for a context violation; those are examples, not universal provider contracts.

If the gateway collapses every upstream failure into 502 Bad Gateway or 500 Internal Server Error, the application loses the distinction between a bad payload, a rate limit, and an outage. I want the original upstream status and diagnostic message preserved in response metadata, with enough route information to debug the failure.

For transient conditions such as 429 Too Many Requests or 503 Service Unavailable, define explicit retry or alternate-model behavior. Then simulate those conditions in staging. A configured fallback is not proven until the application handles it without unhandled errors and the replacement model still satisfies the task's output requirements.

Multi-region gateway deployments and automated failover can reduce gateway availability risk where the deployment supports them. A secondary client that calls a provider directly is another option. That bypass must be tested independently because its authentication, feature support, and error behavior may differ from the gateway route.

My Production Gate

Before increasing traffic, I check that each route authenticates, uses a current model ID, and has documented parameter support. For credentials I control, I check least-privilege access, rotation procedures, billing alerts, and usage limits. I also verify what upstream credential management the gateway actually provides.

Observability must attribute latency and token usage to the selected route and credential. Where the gateway exposes diagnostic headers, the logging stack should parse them. I track proxy overhead separately from generation time and watch token-consumption drift, since a model switch can change cost even when request volume stays flat.

Finally, I run daily integration tests against active routes, covering system prompts, tool schemas, output limits, temperature support, streaming, and error translation. I start with a small subset of non-critical traffic and compare successful-task cost and latency before expanding. A unified endpoint earns its place when it reduces integration work without hiding the differences the application depends on.

Originally published at cometapi.com

Gemini 4 Pro’s Leaked Scores: What I’d Check Before Switching Models

Ryan Cole — Mon, 21 Sep 2026 01:29:54 +0000

Gemini 4 Pro leads GPT-6 Astra and Claude Fable 5.1 in a circulating benchmark table. That makes it interesting to evaluate. It does not establish that Google has shipped a better model.

The reporting dated September 20, 2026 describes an unreleased model without an official model card, public API endpoint, or confirmed pricing. The scores come from community posts, alleged internal checkpoints, and Arena.ai sightings. Some earlier sheets were reportedly flagged as predictions or partially copied data.

My read: the claimed improvements in coding, computer use, and multimodal reasoning deserve attention. I would still keep production decisions tied to reproducible evaluations and actual access.

Start with the provenance

Several different kinds of evidence have become bundled into the Gemini 4 story.

The strongest context cited in the reporting is Google’s July 2026 earnings discussion of investment in a “larger Gemini 4 base model.” That supports an account of increased training investment. It does not validate a particular checkpoint, benchmark result, context limit, or token price.

The remaining claims fall into three groups:

Source	What it claims	What remains unresolved
Posts attributed to leaker Pankaj Kumar and subsequent community reporting	An internal Pro checkpoint, an October release, possibly an earlier Flash-Lite variant	Checkpoint identity and launch timing
Arena.ai encounters under names such as `gemini-3.8-flash`	Strong SVG, Three.js, structured output, and agent behavior	Whether the model was Gemini 4
A circulating comparison sheet	Benchmark scores, prices, and context limits across several model families	Authenticity, evaluation settings, and reproducibility

The comparison sheet includes Gemini 4 Pro, Flash, and Flash-Lite alongside GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, and GPT-5.6 Sol.

Google has not confirmed the table or the reported Arena identities. The reporting points to a history of stealth evaluations before launches, but that pattern cannot identify a particular anonymous model.

What the benchmark sheet actually says

I find the numbers easier to assess when the comparison and its limitations sit together. Every result below is an unverified claim from the circulating sheet.

Benchmark	Gemini 4 Pro	GPT-6 Astra	Claude Fable 5.1
DeepSWE v1.1	88.7%	86.9%	69.1%
Terminal-bench 2.1	95.3%	94.1%	92.8%
Terminal-bench 4.0	69.7%	66.4%	57.9%
GDPval-AA v2	2064 Elo	1994 Elo	1853 Elo
OSWorld-2.0	86.8%	84.5%	77.9%
HLE-Verified	72.1%	67.3%	62.1%
LVBench	95.8% agentic / 95.0% static	93.8%	90.4%

The OSWorld-2.0 number is described as a partial score with batch tools enabled. LVBench gives separate agentic and static results for Gemini, while the comparison supplies only one figure for each competitor. Those details matter when deciding whether the rows represent equivalent evaluation conditions.

Coding and sustained agent work

DeepSWE v1.1 is presented as a long-horizon software engineering evaluation. The sheet puts Gemini 4 Pro at 88.7%, ahead of Astra’s 86.9%, Fable’s 69.1%, and Claude Opus 5’s 75.0%.

The two Terminal-bench versions measure different workloads in the reporting: version 2.1 covers agentic terminal coding, while version 4.0 covers general agent capabilities. I would keep their results separate rather than treat them as interchangeable measures of coding quality.

If reproduced, these results would make Gemini 4 Pro a serious candidate for repository work: refactoring across files, debugging, running tools, and recovering from failed steps. They would still leave the practical question of how reliably it finishes my tasks.

Knowledge work and specialist evaluations

The sheet’s 2064 GDPval-AA v2 rating would make Gemini 4 Pro the only listed model above 2000 Elo. It also claims:

Vals Finance Agent v2: 74.2%.
Harvey’s Legal Agent Benchmark: 18.7% on complex legal workflows, measured by all-pass rate.
CharXiv Reasoning: 94.7% for reasoning over complex charts without tools.
BioMysteryBench and LABBench2: leading results on human-solvable and difficult subsets, without exact scores supplied in the article.

I would resist flattening these into a single “professional work” score. An all-pass legal workflow result, a chart reasoning accuracy, and an Elo rating describe different properties.

The same applies to HLE-Verified’s claimed 72.1%: it suggests strong multidisciplinary expert reasoning under that evaluation, subject to verification. It does not establish reliability for every specialist application.

Price and context contain their own uncertainty

The leaked pricing is attractive enough to influence deployment plans—if it survives launch.

Model	Input per 1M tokens	Output per 1M tokens	Claimed maximum input
Gemini 4 Pro	$2.25	$11.25	2M tokens
Gemini 4 Flash	$0.75	$3.75	2M tokens
Gemini 4 Flash-Lite	$0.35	$1.75	2M tokens
GPT-6 Astra	$12.00	$60.00	1M tokens
Claude Fable 5.1	$10.00	$50.00	200k tokens in the sheet

The Gemini Pro figures are quoted without caching. They amount to roughly one-fifth of Astra’s listed token prices. Fable 5.1’s reported cache-read discounts complicate any comparison based solely on uncached rates.

The reporting also gives Gemini 3.x Pro pricing as $2–$4 per million input tokens and $12–$18 per million output tokens, depending on context length. That makes the leaked prices look plausible, but plausibility is a weak substitute for a published rate card.

The context numbers disagree

The sheet lists 2M input tokens for the Gemini 4 family, 1M for Astra, and 200k for the Claude Fable/Opus 5 line.

However, the same reporting says official Anthropic documentation commonly gives Fable 5.1 a 1M context window. The 200k entry may describe a particular evaluation configuration or simply be wrong. I would not use it to claim a confirmed tenfold context advantage.

Other community accounts mention targets around 1.5M tokens or higher, and separate “ghost-routing” claims suggest 10M ceilings. These are distinct claims, not a coherent specification.

For repository agents, I care about retrieval fidelity and task completion as the context fills. A maximum token count alone cannot answer either question.

What the Arena demos can tell us

Reported encounters with the anonymous model include SVG scenes such as a pelican riding a bicycle, mechanical butterflies built in Three.js, long JSON outputs without obvious repetition, and capable agent behavior.

Community comparisons reportedly judged some of these outputs superior or competitive with Astra. I understand why those examples spread: complex visual output makes differences immediately visible.

Their evidentiary limit is substantial, though. A compelling result from a placeholder model does not establish its identity, typical performance, or production configuration.

Claims about multi-million-token context, 256k output limits, cross-session memory, and native internet or tool access also need separate confirmation. A demo may combine model behavior with capabilities supplied by the surrounding application.

I would save the prompts as future evaluation cases. I would avoid using the screenshots as a deployment ranking.

Architecture and reasoning: separate reports from inference

The reporting attributes “most ambitious pre-training run yet” language to Google and describes a significantly larger base model. It then infers possible increases in parameter count, effective capacity, training compute, and multimodal coverage.

Those are reasonable possibilities. They do not reveal whether the architecture uses denser scaling, mixture-of-experts, different sparsity, or another approach.

The alleged `argon` checkpoint

Descriptions of an early checkpoint called argon mention a High thinking-effort mode, roughly 2.4 minutes for one generation, and an output ceiling of 256k tokens, compared with a reported previous limit of approximately 64k.

If accurate, those details suggest room for more computation and longer generations. They do not establish typical latency, effective output quality, or production limits.

The reporting expects reasoning controls comparable to current Gemini Flash low, medium, and high thinking levels. Until documented, I would treat that as an interface expectation.

The expected capability direction

The proposed focus is consistent across the leaks: sustained software engineering, tool use, context reliability, and multimodal understanding.

The article connects those expectations to agentic features attributed to Gemini 3.5/3.8 Flash and the September 2026 Gemini 3.8 Live models. Expected improvements include function calling, code execution, search grounding, structured JSON/XML outputs, video comprehension, spatial reasoning, and voice interactions.

For application development, I would turn those expectations into test cases. “Better tool use” becomes successful function selection and argument construction. “Long-context reliability” becomes retrieving the right evidence from a large input. “Stronger agents” becomes completing a task despite intermediate failures.

The RSI claim needs different evidence

Recursive self-improvement has become attached to the launch speculation, but the reporting provides no independently verified evidence that Gemini 4 autonomously improved its own model weights through a closed loop.

It references executive comments connecting AI investment to longer-term self-improvement goals and research such as Dream-RSI, where agents improve exploration strategies without changing model weights.

That distinction is central. Improving an agent’s strategy, using AI in model research, and autonomously producing better model generations are different claims. The leaked benchmark table cannot establish the last one.

How I’d prepare an evaluation

The September 20 account describes Astra and Fable 5.1 as publicly available and independently evaluated, with different strengths and closely matched overall results on third-party trackers. Gemini 4 Pro remains an alleged upcoming option in that snapshot.

I would keep building against available models and prepare a repeatable comparison:

Freeze representative tasks. Include repository changes, terminal work, structured outputs, and the multimodal inputs the application actually receives.
Record execution conditions. Capture tool access, thinking settings, context size, caching, retry policy, and agent configuration.
Measure completed work. Track correctness, latency, failures, and total spend across retries and tool loops.
Re-run when public access exists. Verify the documented model ID, limits, and pricing before interpreting results.
Route by observed performance. A cheaper Flash variant may suit one workload while a Pro model earns its cost on another.

A unified multi-model API such as CometAPI can simplify that comparison through an OpenAI-compatible interface, provided the required models and features are available. I would still check feature support rather than assume that changing a model parameter preserves every provider-specific behavior.

October 2026 is the reported release expectation, with some late-September speculation and a possible earlier Flash-Lite release. None is an official commitment in the supplied reporting.

My threshold for switching is straightforward: public access, documented operating limits, and better results on the workloads I need to ship. The leaked numbers give me reasons to run those tests. They do not supply the results.

Originally published at cometapi.com