DEV Community: Mason Reed

FLUX 3: What the Video API Gives You, What It Costs, Where It Still Fails

Mason Reed — Fri, 09 Oct 2026 07:33:46 +0000

FLUX 3 is Black Forest Labs' unified multimodal foundation model, and the architectural bet is the interesting part: one shared representation trained across images, video and audio instead of three separate models. BFL's framing is that images, video and sound are different observations of the same world. A moving car has appearance, motion, sound, spatial structure, material behaviour and causal behaviour, and learning those signals together gives the network more constraints than learning frames in isolation.

That is why BFL describes FLUX 3 as a step toward a reality or world model rather than just another video generator. The claim is broader than the shipped product. As of September 2026 the video endpoint is live, while FLUX 3 Image and the open-weight FLUX 3 Dev model are separate rollout items. Here is what you can call today, what it costs, and where it breaks.

What has shipped

Capability	Status
FLUX 3 Video generation	Generally available
Native video audio	Generally available
Text-to-video	Generally available
Image-to-video / keyframes	Generally available
Video continuation	Generally available
Richer image/video/audio reference combinations	Planned expansion
FLUX 3 Image generation and editing	Upcoming
FLUX 3 Dev open weights	Planned
Action-prediction deployment	Research / commercial partner track

If you need stills from this family, FLUX.2 is still the dedicated option (FLUX.2 Max among them). The public FLUX 3 product is video and audio, full stop. Do not read the family roadmap as a shipped image endpoint.

Specs

Specification	Value
Developer	Black Forest Labs
Model family	FLUX 3
Model type	Unified multimodal foundation / generative video model
Public video release	August 4, 2026
Text-to-video	Supported
Image-to-video / keyframes	Supported
Video continuation	Supported
Max T2V / I2V duration	20 seconds
Continuation duration	5–15 seconds
Frame rate	24 fps
Resolution tiers	HD, FHD, QHD/2K, UHD/4K
FHD 16:9 output	1920 × 1088
Image references	Up to 10 for I2V / keyframe workflows
Native audio	Yes
Multilingual dialogue + lip sync	Yes
Multi-shot generation	Yes
Draft Mode	Yes
Research foundation	Self-Flow
Core training direction	Joint image, video and audio representation learning
Public still-image endpoint	Not yet generally released
Open-weight FLUX 3 Dev	Planned

Aspect ratios cover 21:9, 2:1, 16:9, 4:3, 1:1, 3:4 and 9:16. Resolution bands are defined by total pixels per frame rather than aspect ratio, and Draft Mode is HD only. Note the duration split: text-to-video and image-to-video accept 5–20 seconds, continuation accepts a 5–15 second generation window.

Pricing, and a working request

BFL bills by generated duration.

Mode	BFL list price
T2V / I2V Draft HD	$0.06/s
T2V / I2V HD	$0.17/s
T2V / I2V FHD	$0.29/s
T2V / I2V QHD (2K)	$0.40/s
T2V / I2V UHD (4K)	$0.80/s
Continuation Draft	$0.12/s
Continuation HD	$0.41/s
Continuation FHD	$0.53/s
Continuation QHD (2K)	$0.65/s
Continuation UHD (4K)	$0.95/s

A 10-second HD render lands around $1.70 at list; the same length at FHD is about $2.90. Continuation is substantially more expensive per second than ordinary generation at every tier, so if your product extends clips often, model that as its own cost line instead of folding it into an average.

The request shape is a standard form POST to an OpenAI-style /v1/videos endpoint:

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

The workflow is asynchronous. The initial call returns a task ID, you poll until the job completes, then you fetch the resulting video. Do not hold an HTTP request open for the full render; push generation through a background job or task queue and let the client poll your own status endpoint. I route this through CometAPI, which lists the model as flux-3 (marked Available, platform release date August 13, 2026) at $0.136/s for 720p and $0.232/s for 1080p, roughly 20% under BFL's listed $0.17/s and $0.29/s. That is about $1.36 and $2.32 for a 10-second run. One caveat worth flagging: some older descriptive copy on that site still reflects the July Early Access period, so check the live model card and pricing fields before you commit to an integration.

Under the hood: Self-Flow

The research foundation is Self-Flow, BFL's self-supervised flow-matching approach. Standard generative pipelines lean on separately pretrained representation models or auxiliary supervision. Self-Flow is built to learn useful representations directly from the generative objective.

The mechanism to know about is Dual-Timestep Scheduling: different groups of tokens get different noise levels during training. That creates information asymmetry, where some parts of the input carry more usable signal than others, which forces the network to build representations that help infer what is missing. In practice FLUX 3 is pushed toward learning relationships between objects, frames, motion, sound and temporal events rather than memorizing what a single frame should look like.

Self-Flow architecture, image source: Black Forest Labs

BFL also ran joint multimodal training experiments on a FLUX.2-derived backbone with millions of videos and hundreds of millions of images. Those experiments support the broader hypothesis that representation learning and generation can share a system.

Why video eats the compute

Video carries information a still cannot. A single frame shows a ball above the floor; a video shows it falling, bouncing, deforming on impact, making a sound and changing direction. BFL disclosed that video prediction accounts for more than 95% of FLUX 3's training compute. Audio is comparatively cheap because it is a much lower-dimensional signal tightly coupled to visible events. That allocation is a decent explanation for why video shipped first.

Capability notes

Keyframes and references. The current API accepts up to ten image references in image-to-video workflows, so you can animate an initial image, drive toward an end frame, or place multiple images as timed keyframes instead of letting the model improvise the whole sequence.

Continuation. Feed an existing video plus its audio and FLUX 3 generates what happens next, preserving movement, camera behaviour, dialogue and sound across the seam. If you have ever generated a second clip and concatenated the files, you know how visible that join usually is.

Audio. Sound is produced at generation time, not in a separate speech or SFX pass. Dialogue, effects and ambience are all in scope, with multilingual dialogue and lip sync.

Multi-shot. A single prompt can carry multiple scenes or camera angles. Most earlier models are strongest on one continuous shot; this one is explicitly built for multi-shot sequences in one generation.

Draft Mode. You can generate a cheaper preview and then enhance the selected draft while keeping the composition and motion you picked. Per current BFL pricing a standard T2V/I2V draft is $0.06/s against $0.17/s for regular HD. For prompt-heavy iteration this is the feature that matters most.

Benchmarks: vendor versus third party

There are two useful evidence sets now.

BFL's August 4 evaluation of the released model reports a text-to-video ELO of 1135 in an internal all-vs-all human-preference test, the highest score in the group BFL tested. Image-to-video tied the strongest tested competitor and beat the rest. This supersedes the preliminary July win rates, though it is still a vendor-run protocol.

Megaton's v-benchmark v2 is the independent check, run in August 2026.

Dimension	Megaton score
Megaton Index	76.51 (rank #3 at evaluation time)
Prompt Adherence	87.07
Scene Consistency	94.76
Physics	70.63
Human Fidelity	73.70
Object & Product Fidelity	83.82
Causal & Semantic Coherence	80.91
Text Fidelity	82.41
Cinematography	71.43
Taste & Art Direction	65.00

The profile tells you more than the index. Scene consistency is the standout, and prompt adherence, object fidelity, causal coherence and text fidelity all clear 80. Physics, human fidelity and art direction are the weak spots, which is the useful takeaway: better temporal representation does not solve synthetic motion or taste. The two rankings diverging (first internally, third externally) is not a contradiction. Different prompt distributions, scoring dimensions, evaluator pools and aggregation rules will do that.

Against Seedance 2.5, MiniMax H3 and Wan 3.0

Dimension	FLUX 3	Seedance 2.5	MiniMax H3	Wan 3.0
Developer	Black Forest Labs	ByteDance Seed	MiniMax	Alibaba
Max advertised clip	20 s	30 s	15 s	30 s
Resolution	HD / FHD / QHD (2K) / UHD (4K)	API tier dependent	Up to 2K	Up to 1080p
Native audio	Yes	Yes	Yes, stereo	Yes
Text-to-video	Yes	Yes	Yes	Yes
Image / reference input	Yes	Yes	Yes	Yes
Keyframe / reference control	Strong timed keyframes	Strong multimodal reference control	Multimodal conditioning	Multimodal reference control
Continuation / editing	Continuation available	Editing-oriented workflow	Omni generation focus	Editing and reference workflows
Multi-shot	Yes	Yes	Yes	Yes
Distinctive strength	Reality-model architecture, scene consistency, Self-Flow	Long-form storytelling, reference control	2K audiovisual generation, omni-modal context	Long clips, lower entry cost
Listed entry price / s	$0.136	$0.0824	$0.064	$0.040

Treat the price row as a rough comparison only. These APIs bill against different resolutions, durations, quality tiers and rules, so the cheapest per-second number is not the cheapest equivalent-quality output.

Seedance 2.5 wins on duration outright (30 s against 20 s) and leans hard into reference-driven generation and editing. Megaton currently ranks it above FLUX 3 overall, so expect real competition at the top of this market. MiniMax H3 is the spec argument: up to 2K with native stereo audio, but a 15 s ceiling against FLUX 3's 20 s, and no equivalent of Draft Mode for cheap iteration. Wan 3.0 goes for broad multimodal inputs, audiovisual output, editing and 30 s clips at a lower listed entry price; FLUX 3 counters with scene consistency, the Self-Flow foundation and the action-prediction roadmap.

Where it holds up, and where it does not

Strengths I would build on:

Scene and temporal consistency, and it is the top Megaton category at 94.76.
Native audiovisual generation in one pass, no stitching two models together.
Prompt adherence at 87.07 independently, so it is not just visual polish.
Keyframe control with up to ten image references.
Draft-to-final iteration, which addresses a real cost problem in video work: most generations get thrown away.
A deliberately wide style range rather than one house look.

Limitations to plan around:

The full multimodal roadmap has not shipped. Do not assume FLUX 3 Image or Dev weights from the family announcement.
20 seconds is no longer industry-leading.
Physics is not solved. 70.63 against 94.76 scene consistency is a wide gap.
Human fidelity at 73.70 still fails on hard anatomy and realistic motion.
Continuation pricing is steep relative to ordinary generation.
BFL's headline competitive benchmark is internal. Run your own prompts, shot types, languages and reference assets before you commit.

The part that is not video

Robot control signals are temporal predictions conditioned on visual observations, so BFL uses the FLUX 3 video representation as a base for action prediction. Its work with mimic robotics produced FLUX-mimic, where an action decoder reads representations from the video model instead of training a separate perception stack. BFL reports the FLUX-mimic backbone running in under 80 ms on a single RTX 5090, with the full robot system closing a roughly 101 ms reaction loop. Audi has been discussed as an industrial evaluation partner.

None of that makes the public video API a robotics API. It does explain why BFL spent heavily on multimodal video representation rather than treating generation as an isolated media task.

FAQ

Is FLUX 3 available now? Yes. FLUX 3 Video went generally available through BFL on August 4, 2026, and is listed as Available under the model ID flux-3. The still-image release and FLUX 3 Dev open weights remain separate roadmap items.

Does it generate audio? Yes, synchronized natively: dialogue, ambient sound and effects, with multilingual dialogue and lip sync.

How long can clips be? 5–20 seconds for T2V and I2V. Continuation generates 5–15 seconds of new content.

What resolutions? HD (up to 1 MP per frame), FHD (up to 2 MP), QHD/2K (up to 4 MP) and UHD/4K (up to 8 MP). 16:9 FHD is 1920 × 1088. Bands are total pixels per frame, not aspect ratio, and Draft Mode is HD only.

Is it open source? Not currently. FLUX 3 Dev has been announced as an open-weight multimodal variant with no public release date.

Can I use it for still images? Architecturally it is trained across images, video and audio, and BFL has demonstrated image generation and editing research, but the FLUX 3 Image product is still upcoming. For production stills, use an existing FLUX image model.

Is it a world model? BFL positions it as a reality-model foundation because the shared representations extend from audiovisual prediction toward physical action prediction. Calling it a general-purpose world model goes beyond the available evidence. A multimodal generative foundation model designed around world-modelling objectives is the accurate description.

My take

FLUX 3 is less an upgrade to FLUX.2 than a different product line with a longer thesis behind it: train one shared multimodal representation, then reuse it for video, sound, images and eventually actions. Self-Flow is the research basis and the released video model is the first production proof.

What you can ship against today is 20-second clips at 24 fps, HD through UHD/4K, synchronized audio, multilingual dialogue, keyframes, continuation, multi-shot and Draft Mode. It is not the cheapest per second, not the longest, and not top of the independent leaderboard. Where it earns its place is scene consistency, prompt adherence, object persistence and controllable keyframes, plus native sound in the same pass. Pick it for the workload that needs those, and test against your own prompts rather than anyone's ranking.

Originally published at cometapi.com

Kling VIDEO 3.0 Omni is a reference engine, not a quality upgrade

Mason Reed — Fri, 09 Oct 2026 06:57:13 +0000

Omni is a workflow upgrade, not a quality one. If a project needs the same face, the same bottle, and the same studio across several shots, it earns its keep. If you want one good clip, the standard model is cheaper and often ranks higher.

The order that works: validate a single short shot, approve the references, add audio, then expand to a storyboard. Jumping straight to multi-shot sequencing is where most of my wasted credits went.

What Omni supports

The usual pitch is “video with sound.” That is misleading. Standard Kling VIDEO 3.0 also does native audio, multi-shot generation, and element binding. The real distinction is how references get organized and reused.

Spec (official generation guide)	Omni capability
Input options	Text, images, video references, reusable elements, voice references
Model-level output duration	3–15 seconds
Video resolution	720p and 1080p, native 4K in supported workflows
Audio	Native audiovisual generation with supported character–voice binding
Shot control	Single-shot generation and custom multi-shot sequencing
Multi-image element creation	2–4 images
Video-based character creation	3–8 second character clip
Recommended voice sample	5–30 seconds of clear, single-speaker speech
Combined image and element budget	Up to 7 without video input, up to 4 with video input

Two traps live in that table.

Creating an element is not the same as attaching it to one request. Several views can belong to a single reusable element, and they do not count as separate element slots.

A model-level capability is not a provider-level one. A 15-second workflow in Kling’s interface and a third-party API request can expose different parameters and different duration values.

Pick by reference layout, not by name

Stop framing this as “basic vs pro.” Ask where the essential information lives.

Dimension	Kling VIDEO 3.0	Kling VIDEO 3.0 Omni
Reference organization	Element binding around an approved start frame or start/end frames	Broader composition with images, elements, and video references
Element relationship	Best when the important subjects already exist in the defining frame	Best when separate assets must be combined or reused
Character voice	Can use voice-bound elements	Visual and voice references in one workflow
Multi-shot generation	Supported	Supported with custom storyboard controls
Recommended starting point	One approved keyframe that already defines the scene	A collection of assets that must stay recognizable across shots

Start with the standard workflow when one approved frame already carries the essential information. Reach for Omni when reference composition, asset reuse, or cross-shot continuity is the job.

The benchmarks do not favor Omni

These are point estimates for the 1080p Pro, audio-enabled entries in Artificial Analysis, checked September 9, 2026. Values after ± are published 95% confidence intervals.

Evaluation (text-to-video / image-to-video)	Standard	Omni
Text-to-video Elo	1108 ± 5	1090 ± 6
Image-to-video Elo	1072 ± 6	1060 ± 7

These are preference-based ratings, not generation-success percentages. The standard model holds the higher point estimate in both rows, and the image-to-video intervals overlap. Scores shift as new evaluations arrive.

So Omni’s case rests on reference handling and production continuity. It is not a universal quality ranking, and the name does not win a benchmark.

Build one reference-led shot first

Illustrative setup: a vertical ad with a presenter, a reusable bottle, and one studio setting. Not a reported generation test.

Prepare a small asset set

Asset	Preparation	Acceptance criterion
Presenter	Clear views with consistent hair, clothing, and lighting	Recognizable face, unchanged wardrobe
Bottle	Front, side, and three-quarter views	Stable body shape, cap, color, label
Setting	One approved studio reference	Consistent background and light direction
Voice	Clean speech from an authorized speaker	Recognizable voice, no competing speech

Fix conflicting references before you try to compensate with a longer prompt. Use only faces, recordings, and brand assets you are authorized to use.

Create and name elements

In Kling’s Element Library, create reusable assets instead of re-describing the same subject on every shot. The official workflow supports multi-image and video-based character creation.

Names like Maya, BlueBottle, and Studio are organizational aids. Selecting the saved element is what attaches the reference. For uploaded voices, use clear, single-speaker audio without music or overlapping voices.

In the prompts below, @maya, @BlueBottle, and @studio stand for elements selected in the interface. Typing the names without attaching the assets creates no reference.

Generate a single shot

Open the Omni generation workspace, pick the model, attach the assets. Start at five seconds, one camera move, no dialogue.

Create a single continuous product shot using @BlueBottle in @Studio.

The bottle stands upright on a clean tabletop. Keep its body shape,
cap, surface color, and label placement consistent with the references.

Camera: a slow, straight push-in from a medium close-up.
Lighting: soft studio light from camera left.
Action: the bottle remains stationary.
Composition: leave clear space above the bottle for text added later.

No cuts, no extra products, and no generated captions.

Inspect the beginning, middle, and end. Check the cap, silhouette, label placement, and tabletop contact. If the asset drifts, simplify the shot or improve the references before adding demands.

Add the presenter and native audio

Once the bottle shot passes, add the presenter and one short line. Kling documents speech generation in several languages, but quality tracks reference quality, timing, and prompt clarity.

Create a five-second continuous shot using @Maya, @BlueBottle,
and @Studio.

Maya stands beside the bottle, looks toward the camera, and says:
“Ready when you are.”

Use Maya’s bound voice. Keep the bottle unchanged. Use one static
camera angle. Do not add music, captions, cuts, or additional speech.

Review audio apart from picture. Confirm the right person speaks, the line is complete, and the timing matches the visible performance.

Go multi-shot only after that

Reuse the approved references and plan the sequence. Give each shot a duration and a distinct visual purpose. Custom storyboard controls support shot-level duration, framing, camera behavior, and narrative progression.

Time	Purpose	Visual instruction	Audio instruction
0–5 seconds	Establish the product	Close-up of the bottle, slow push-in	Quiet room tone
5–10 seconds	Introduce the presenter	Medium shot of Maya beside the bottle, static camera	“Ready when you are.”
10–15 seconds	Finish on the product	Clean hero shot, hold the final composition	Room tone

Create a three-shot product advertisement using @Maya, @BlueBottle,
and @Studio.

Continuity rules:
Use the same presenter, outfit, bottle, and studio throughout.
Keep the bottle’s shape, cap, color, and label unchanged.
Maintain the same lighting direction.
Use Maya’s bound voice only.
Do not add people, products, captions, or extra dialogue.

Follow the separate shot descriptions and durations.
End on a stable product composition.

Check transitions as closely as the shots. Compare the last clear product view before each cut with the first clear view after it. Add legal copy, exact prices, subtitles, and brand typography in an editor so wording stays under direct control.

Video references: identity vs editing

A clip that creates a reusable character is not source footage for an edit. The first establishes identity. The second supplies existing motion and composition to transform or preserve.

For character creation, use a 3–8-second clip of one character. For video editing, Kling’s official Omni guide permits one 3–10-second source video, up to 200 MB and 2K resolution. Check the selected API route’s current limits and test a short clip before scaling.

Use the uploaded video as the source.

Change only the background to a softly lit studio.
Preserve the presenter’s identity, clothing, actions, and timing.
Preserve the bottle and the original camera movement.
Do not add cuts, gestures, objects, or dialogue.

A controlled edit request is not a guarantee of frame-perfect preservation. Decide separately whether to keep the source audio or generate new sound, then compare against the original clip.

The API path

For programmatic access, the documented identifier is kling-v3-omni. The examples follow the published schema, not a live generation test. The route documents duration values of “5” and “10” for the relevant modes. Do not assume a 15-second interface workflow maps to the same request.

Submit a task

export COMETAPI_KEY="YOUR_COMETAPI_KEY"

curl --fail --silent --show-error \
  --request POST \
  "https://api.cometapi.com/kling/v1/videos/omni-video" \
  --header "Authorization: Bearer ${COMETAPI_KEY}" \
  --header "Content-Type: application/json" \
  --data-raw '{
    "model_name": "kling-v3-omni",
    "prompt": "A blue reusable bottle stands on a clean studio tabletop. One continuous shot with a slow straight push-in. Soft light from camera left. No people, no cuts, no captions.",
    "mode": "std",
    "aspect_ratio": "9:16",
    "duration": "5",
    "sound": "off"
  }'

For a first-frame reference, merge this fragment into the request and swap the sample URL for a reachable image:

{
  "image_list": [
    {
      "image_url": "https://your-public-host.example/bottle.jpg",
      "type": "first_frame"
    }
  ],
  "prompt": "Starting from &lt;&lt;&gt;&gt;, create one continuous slow push-in. Preserve the bottle and studio composition. No cuts or captions."
}

The API’s <<>> syntax is not the same as selected @Element references in the interface. Documented sound values are on and off.

Retrieve the result

Store the returned data.task_id, then query the status route.

TASK_ID="REPLACE_WITH_RETURNED_TASK_ID"

curl --fail --silent --show-error \
  "https://api.cometapi.com/kling/v1/videos/omni-video/${TASK_ID}" \
  --header "Authorization: Bearer ${COMETAPI_KEY}"

Documented states: submitted, processing, succeed, failed. A creation response with code: 0 means the request was accepted, not that the video is ready. On success, read the result from data.task_result.videos[0].url.

Use bounded polling with backoff, keep the task ID next to the prompt and settings, and read the failure message before retrying. A client timeout may still have created a billable task.

Cost

Price by configuration, not a generic per-video figure. Figures checked September 9, 2026, and they can change.

Kling’s official Omni guide lists credit rates. The dollar figures below use different billing units, and credits do not convert to dollars without Kling’s applicable credit purchase rate.

Omni configuration	Credits/second	Credits/5s	Credits/10s
720p, no video input, native audio off	6	30	60
1080p, no video input, native audio off	8	40	80
1080p, no video input, native audio on	12	60	120
1080p, video input, native audio off	16	80	160

No 4K credit rate is listed, and native audio with video input is marked unsupported in that pricing table. Confirm current in-product rates before ordering.

Omni API configuration	5-second output	10-second output
720p, no video input	$0.336	$0.672
1080p, no video input	$0.448	$0.896
1080p, native audio	$0.560	$1.120
1080p, video input	$0.672	$1.344
4K, no video input	$1.680	$3.360

These are separate API configurations. Do not add rows together, and do not infer that every combination of resolution, audio, and video input exists. A 4K price also does not establish which parameter enables 4K.

Kling added native 4K after the original launch. Approve content and motion before paying for higher-resolution iterations.

Budget against accepted clips

Cost per accepted clip = total generation spend ÷ accepted clips.

Three five-second attempts at the 1080p native-audio rate cost 3 × $0.560 = $1.680. If only one passes, that clip’s effective generation cost is $1.680. This is budgeting math, not a measured retry rate.

Keep Kling application credits separate from dollar billing. Kling’s credit-cost guide treats duration, resolution, audio, and workflow as independent planning factors.

Troubleshooting

Problem	First check	Adjustment
Character changes between shots	Conflicting references or wardrobe descriptions	Reuse one approved element, simplify the shot
Product shape or label changes	Reference quality and demanding motion	Add a clearer product view, test a stationary shot
Wrong voice or extra speech	Voice binding and conflicting instructions	Keep one speaker and one short line
Unwanted cuts	Storyboard settings and scene changes	Test one continuous shot without narrative jumps
API rejects the request	Route-specific schema, types, and duration	Return to the documented minimal request
Task exists but has no video URL	Generation may still be pending	Query the existing task instead of creating another
Higher resolution still looks wrong	The motion or identity problem remains	Revise the scene before increasing output quality

Change one variable at a time. Record the assets, prompt, settings, output, and reason for rejection so improvements trace back to a specific decision.

FAQ

Is Omni always better than the standard model? No. Preference benchmarks can favor the standard model. Omni pays off when its broader reference workflow improves reuse, continuity, or editing control.

Can every workflow hit 15 seconds? No. Fifteen seconds is a model-level capability in supported workflows. Individual interfaces and routes may expose shorter options.

Do @Element names work in an API request? Not automatically. Selected elements in the interface and an API’s image-reference syntax are different mechanisms. Follow the route’s schema.

How do I estimate a production budget? Track total generation spend, divide by accepted clips, and include rejected attempts, higher-resolution reruns, storage, and post-production in the working number.

Originally published at cometapi.com

Grok 4.7 vs Claude Fable 5.1: reading the benchmarks, doing the token math, and wiring a router

Mason Reed — Fri, 09 Oct 2026 05:25:55 +0000

Two frontier models shipped three weeks apart. Claude Fable 5.1 landed September 1, 2026; Grok 4.7 landed September 21, 2026. They are not chasing the same target. Fable 5.1 is built around long-horizon reasoning and agents that stay alive for hours. Grok 4.7 is built around coding, agentic work, and price-performance.

The headline numbers diverge hard:

Grok 4.7: 500K context, grok-4.7, $2/M input, $6/M output, cached input $0.50/M.
Claude Fable 5.1: 1M context, claude-fable-5-1, $10/M input, $50/M output, $0.25/M cache reads.

That's 80% cheaper input and 88% cheaper output for Grok at base rates — against half the context window and a benchmark table that splits roughly down the middle. Here's how I read it.

The spec sheet, without the positioning copy

	Grok 4.7	Claude Fable 5.1
Released	Sep 21, 2026	Sep 1, 2026
Provider	xAI / SpaceXAI	Anthropic
Model ID	`grok-4.7`	`claude-fable-5-1`
Context window	500K tokens	1M tokens
Max output	No fixed text limit documented	Up to 128K tokens
Input	Text + image	Text + image
Output	Text	Text
Knowledge cutoff	May 2026	June 2026
Reasoning controls	low / medium / high / xhigh	Adaptive thinking + effort controls
Search tools	Web search + X search	Environment/tool dependent
Function calling	Yes	Yes
Weights	Closed	Closed

Grok 4.7 runs on a new, larger base model than Grok 4.6, with a longer RL run weighted toward tasks that take many hours. The release notes also call out better self-verification and long-context management — both are things you feel in agent loops, not in a demo.

Fable 5.1 is aimed at multistep research, document-heavy professional work, and agents that keep operating across extended sessions.

The benchmark table splits down the middle

Everything below is vendor-reported from xAI's launch comparison table. Grok 4.7 is measured at xhigh; Fable 5.1 at max effort. xAI separately flags Grok's DeepSWE number as high effort.

Benchmark	Grok 4.7	Fable 5.1	Gap
CursorBench 4.0	46.3%	51.8%	Fable +5.5
DeepSWE v1.1	71.0%*	70.0%	Grok +1.0
AA Briefcase v1.1	1,657	1,678	Fable +21
Terminal-Bench 4.0	38.0%	57.9%	Fable +19.9
Harvey Legal Agent Benchmark	19.6%	6.7%	Grok +12.9
HealthBench Professional	56.7%	62.1%	Fable +5.4
EEBench	64.0%	56.4%	Grok +7.6

* flagged as high effort by xAI.

Coding

This is the muddiest part of the comparison, which is exactly why you shouldn't pick from a single number. Fable 5.1 wins CursorBench 4.0 by 5.5 points. Grok 4.7 wins DeepSWE v1.1 by 1 point. Terminal-Bench 4.0 is the blowout: 57.9% vs 38.0%, a 19.9-point gap that maps directly onto how much time a model can spend driving a shell unattended.

My read: repository-level editing is close to a coin flip. Terminal autonomy is not. If your agent lives in a PTY for 45 minutes at a time, that 19.9-point spread is the most load-bearing number in either table.

Knowledge work isn't one capability

The same vendor table has Grok ahead on EEBench (engineering, +7.6) and Harvey Legal Agent (+12.9), while Fable leads HealthBench Professional (+5.4) and edges AA Briefcase v1.1 by 21 points. Law, medicine, engineering, and office automation impose different tool surfaces and different reasoning demands. A model that wins "professional work" as a category doesn't exist.

The token math is where this actually gets decided

Base pricing	Grok 4.7	Fable 5.1
Input / 1M	$2	$10
Output / 1M	$6	$50
Cached input / cache read	$0.50 (below 200K prompt)	$0.25
10M input	$20	$100
10M output	$60	$500
US regional endpoint premium	+10%	Platform dependent

Worked example — 10M input tokens plus 2M output tokens, no caching:

Grok 4.7: $20 input + $12 output = $32
Fable 5.1: $100 input + $100 output = $200
Nominal gap: $168 per run

Two caveats that bite in production. First, Grok 4.7's $2/$6 is a base rate; SpaceXAI documents higher-context pricing once a request crosses 200K. Second, Fable's $0.25/M cache reads are irrelevant unless your prompt prefix is actually stable across calls — check your cache hit rate before you believe your own cost estimate. Tool charges, regional premiums, and cache writes are all excluded from the math above.

The only cost metric worth tracking is cost per accepted result. A model that costs 6x per token but eliminates one retry loop plus 20 minutes of human review wins, and a cheap model that never passes your acceptance test is the most expensive option on the board.

Reasoning controls aren't comparable across vendors

Grok exposes low, medium, high, xhigh. Fable uses adaptive thinking with effort controls. The names overlap; the behavior doesn't. Matching "high" to "high" is not a controlled experiment — hold the task, tools, and acceptance criteria constant and let each model pick its own effort level, or you're measuring label semantics.

Context is the other structural gap: 1M vs 500K. That matters for whole-repo work, legal discovery, scientific corpora, and agents carrying long histories. It does not matter for the majority of tasks, and paying 5x input for headroom you never touch is waste.

Tooling on Grok's API includes function calling, web search, X search, and code execution as native tools. X search has no equivalent on the Anthropic side. Fable's tool behavior depends on the Claude environment or application stack you're running it in.

Route instead of choosing

The interesting architecture here isn't picking a winner — it's a default route plus a measurable escalation path. I keep the policy explicit in config so it's reviewable and tunable from production logs:

ROUTES = {
    "default": {
        "model": "grok-4.7",
        "reasoning": "high",
        "price": {"in": 2.0, "out": 6.0, "cached_in": 0.50},  # per 1M, &lt;=200K prompt
    },
    "escalate": {
        "model": "claude-fable-5-1",
        "price": {"in": 10.0, "out": 50.0, "cache_read": 0.25},
    },
}

def escalate(task, attempt):
    # measurable triggers only — no vibes-based routing
    return (
        attempt.tokens_in &gt; 200_000          # past Grok's base-pricing tier / context pressure
        or not attempt.passed_acceptance_test
        or task.needs_long_terminal_execution
        or task.cost_of_error &gt; RETRY_BUDGET
    )

def route(task):
    attempt = call(ROUTES["default"]["model"], task)
    if escalate(task, attempt):
        attempt = call(ROUTES["escalate"]["model"], task)
    log_attempt(task, attempt)  # accepted?, tokens, latency, retries, tool failures
    return attempt

If you want a single integration layer across providers rather than two SDKs and two billing dashboards, CometAPI exposes both grok-4.7 and claude-fable-5-1 behind one endpoint — useful when the router above is the actual product decision.

Log the trigger alongside the outcome, or the policy never improves. The metrics that matter per route: accepted-result rate, total tokens, cache hit rate, end-to-end latency, tool-failure count, retries, human correction time.

Benchmark hygiene before you trust any of this

Version drift. CursorBench 3.2.0 and 4.0 are different tests. Do not compare across them.
Effort settings. Grok at xhigh vs Fable at max is not the same knob, and Grok's own DeepSWE row is flagged high.
Harness and tool access. Terminal-Bench scores move with the scaffold, permissions, and safeguard configuration around the model.
Vendor-reported vs reproduced. Every number above comes from one vendor's table. Use it to form hypotheses, not to ship decisions.

Then run both models on your repositories, with your tools, under your time budget and acceptance criteria, with enough repeated trials to separate model behavior from task variance.

Picking

Grok 4.7 when token cost drives unit economics: high-volume coding assistants, batch knowledge processing, background automation, engineering agents where its domain results line up with your workload, and anything that benefits from native web plus X search.

Claude Fable 5.1 when failure is expensive: multi-hour autonomous coding, terminal-heavy agents, very large repos or document sets, professional agents that hold state across many steps, and workflows where a retry costs more than the inference did.

Neither model is a universal winner, and any article claiming otherwise is selling you a leaderboard instead of a cost model. Start with the default-plus-escalation router, measure cost per accepted task, and let production logs move the boundary.

Originally published at cometapi.com

Changing Gemini CLI Directories: Workspace, Project Settings, and Global Config

Mason Reed — Tue, 22 Sep 2026 02:14:24 +0000

When I need to change a Gemini CLI directory, I first separate three tasks: starting the agent in another repository, adding repositories to its workspace, and relocating its persistent configuration. Each uses a different mechanism.

Gemini CLI is Google’s open-source terminal agent. Alongside code inspection and assistance, it can execute shell commands with safeguards and integrate tools such as Google Search and Model Context Protocol (MCP) extensions. Those capabilities make directory scope matter: the files available to the agent and the location of its credentials are separate concerns.

Here’s how I approach each case, including the version-dependent parts I would check before relying on them.

Start with the directory you actually want to change

The default user configuration directory is .gemini under your home directory:

Scope	Typical location	Purpose
User, Linux/macOS	`~/.gemini/`	User settings and persistent state
User, Windows	`%USERPROFILE%\.gemini`	Windows user settings and persistent state
Project	`.gemini/settings.json` in the project	Project-specific settings
System	OS-specific locations, such as under `/etc/` or `%PROGRAMDATA%`	System configuration, when applicable

Typical contents include settings.json, GEMINI.md, commands/, cached credentials, telemetry identifiers, and other local state. Project settings override corresponding user settings when operating in that project.

Historically, the user configuration path has been tied to the home directory and the .gemini name. I would therefore check the installed release before assuming a configuration-directory environment variable works.

For ordinary repository work, I start Gemini from the intended folder:

cd /path/to/your-project
gemini

That selects the starting working directory. It does not relocate the user configuration or credential cache.

Add another repository without moving configuration

If I only need the agent to inspect a second repository, workspace inclusion is the direct solution.

At startup:

gemini --include-directories /path/to/repo

Or inside an interactive session:

/directory add /path/to/another/project
/directory list

These commands extend the workspace context. They do not move ~/.gemini.

This is useful when a change spans an application and a shared library, or when another repository provides reference material. Moving configuration would not solve that access problem.

If a directory still appears unavailable, I check whether the CLI process can read it. Network mounts and filesystem permissions can prevent access even when the directory has been added successfully.

Don’t rely on shell-mode `cd` to switch the session

Some platforms have had issues where cd inside Gemini’s shell mode does not change the working directory as expected.

My practical workaround is to change directories in the parent terminal before launching the CLI. For additional context within an existing session, I use /directory add.

Keep repository settings with the repository

For project-specific behavior, I use a project .gemini directory instead of redirecting the global one:

your-project/
├── .gemini/
│   ├── settings.json
│   └── GEMINI.md
└── src/

Run gemini from the project directory so it can discover the project configuration and context. Context discovery can search upward through the directory tree.

This gives a repository its own settings while leaving user-wide state in the normal location. It also makes the intended scope easier to inspect: a repository override lives alongside the code it affects.

The distinction matters when debugging authentication. Adding project settings does not, by itself, move the user credential cache.

Relocate global configuration only when necessary

For a centralized configuration store, another drive, or a restricted home directory, there are two main options: a supported native override or a filesystem redirect.

Check environment-variable support for your release

Several similarly named settings serve different purposes:

GEMINI_API_KEY supplies a key for Gemini API authentication.
GEMINI_MODEL selects a model where supported.
GEMINI_CLI_SYSTEM_SETTINGS_PATH overrides the system settings file path where supported.
GEMINI_CONFIG_DIR has appeared as a code constant and in community proposals for a configurable directory.

A constant named GEMINI_CONFIG_DIR does not establish that the CLI reads an environment variable with that name. Support and behavior have varied, with Windows issues reported in particular.

If your installed version documents the directory override, the shell configuration looks like this:

export GEMINI_CONFIG_DIR="$HOME/custom_gemini_dir"
gemini

PowerShell:

$env:GEMINI_CONFIG_DIR = 'C:\Users\you\CustomGemini'
gemini

Treat those as conditional examples. Before building CI around them, check the release documentation and verify where that version actually writes its state.

The system-settings override is narrower:

export GEMINI_CLI_SYSTEM_SETTINGS_PATH="/etc/my-gemini/system.settings.json"
gemini

Even when supported, that selects a system settings file; it is not a general relocation mechanism for credentials, commands, and caches.

Use a symlink or junction when native relocation is unavailable

A filesystem redirect lets the CLI continue addressing its expected path while the directory contents live elsewhere.

On Linux or macOS, assuming the current configuration exists and the destination parent is available:

# Preserve the current configuration.
mv "$HOME/.gemini" "$HOME/gemini_backup"

# Populate the destination before linking it.
mkdir -p /path/to/central/gemini-config
cp -a "$HOME/gemini_backup/." /path/to/central/gemini-config/

ln -s /path/to/central/gemini-config "$HOME/.gemini"

On Windows, a directory junction provides a similar approach. From an appropriately privileged PowerShell session:

Move-Item -Path "$env:USERPROFILE\.gemini" -Destination 'C:\GeminiConfigBackup'

New-Item -ItemType Directory -Path 'C:\CentralGeminiConfig' -Force
Copy-Item -Path 'C:\GeminiConfigBackup\*' -Destination 'C:\CentralGeminiConfig' -Recurse -Force

New-Item -ItemType Junction `
  -Path "$env:USERPROFILE\.gemini" `
  -Target 'C:\CentralGeminiConfig'

I keep the backup until the CLI has loaded the expected settings and authentication state.

Symlinks and junctions depend on filesystem privileges and can behave differently across Windows and container environments. Some CLI versions also restrict following certain symlinks for security, so I verify both settings.json and context discovery after the move.

Treat home-directory changes as an isolated-runtime option

In CI or containers, controlling the process’s effective home directory can influence where the default .gemini path resolves. The source environment may use HOME on Unix or profile-related values on Windows.

That change has a broader effect than a configuration override: other tools and authentication flows, including Google OAuth caches, may also depend on the home directory. I would reserve this approach for an isolated runtime whose filesystem and authentication setup I control.

Diagnose failures by scope

The error usually tells me which layer to inspect.

Symptom	What I check
Another repository is invisible	`--include-directories`, `/directory add`, and read permissions
Project settings seem ignored	Launch directory and project `.gemini/settings.json`
Relocated settings are missing	Link target, copied contents, and version-specific symlink behavior
`GEMINI_CONFIG_DIR` appears ignored	Whether that release supports it as an environment variable
Windows reports `EPERM` creating `.gemini`	Write permissions on `%USERPROFILE%`

For Windows EPERM, adjusting folder permissions or using an appropriately elevated terminal can resolve the underlying access problem. A supported alternate location or junction may also help when the default profile directory is unsuitable.

Keep API routing separate from directory configuration

Sometimes the underlying goal is to use Gemini from a script or CI job. In that case, a direct API request may be sufficient, without configuring the terminal agent.

A unified multi-model API such as CometAPI exposes an OpenAI-style chat-completions endpoint using bearer authentication:

export COMET_KEY="sk-xxxx"

curl -s -X POST "https://api.cometapi.com/v1/chat/completions" \
  -H "Authorization: Bearer $COMET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-2.5-pro",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Summarize the 3 key benefits of unit tests."}
    ],
    "max_tokens": 300
  }' | jq .

This calls the model directly. It does not provide the CLI’s workspace, file inspection, or shell-tool behavior.

Connecting the official CLI to a gateway requires checking both custom-base-URL support and API compatibility. Some releases or proposals have introduced overrides such as GOOGLE_GEMINI_BASE_URL, but a base URL alone does not translate Gemini requests into OpenAI-style requests. A compatible endpoint or translating proxy is still necessary.

For model-ID mismatches, inspect the gateway’s /v1/models response and use the exact identifier. A variant such as gemini-2.5-flash-preview-04-17 should not be assumed interchangeable with a shorter family name.

For my own directory setup, I keep the choice narrow: project settings for repository behavior, workspace commands for additional files, and a verified relocation mechanism only when persistent state needs another home.

Originally published at cometapi.com

Building an AI Companion: Persona, Memory, Tools, and the Tests That Matter

Mason Reed — Mon, 21 Sep 2026 07:58:58 +0000

I’d start an AI companion with a narrow role, an explicit memory policy, and a set of difficult conversations to test. Voice and avatars come later. They make the experience more expressive, but they also make inconsistent behavior more noticeable.

The engineering work sits across several layers: personality, conversation state, persistent memory, retrieval, tool execution, and presentation. Customization means deciding how those layers work together.

Here’s how I’d approach a build in 2026, including where existing platforms make sense and where I’d want control over the backend.

Choose the relationship before the stack

“AI companion” covers several products with different requirements. I’d pick one primary role before choosing a model or writing a system prompt.

Role	Main behavior	What the implementation needs
Study coach or mentor	Structured guidance and accountability	Goals, task tracking, reminders
Social companion	Warmth, banter, conversational continuity	Preference memory and consistent tone
Wellness companion	Reflection, journaling, habit support	Clear boundaries for sensitive conversations
Creative partner	Brainstorming, stories, character development	Project context and flexible generation
Roleplay character	Consistent characterization and scene progression	Backstory, scene state, narrative memory
Productivity assistant	Planning and task execution	Calendar, document, and application integrations

Trying to cover all these roles immediately makes prompt design and evaluation harder. A study coach that gives concise guidance has a different conversational rhythm from a roleplay character.

This choice also determines what to remember. A mentor needs recurring goals. A creative partner needs project decisions. A social companion needs continuity without turning every casual statement into a permanent preference.

Decide how much infrastructure you want to own

Consumer platforms such as Replika, Character.AI, Kindroid, Nomi, and Kalon offer an accessible route to personality and visual customization. For work-oriented use cases, Zoom AI Companion, Microsoft Copilot, and custom GPTs fit more naturally into existing workflows.

A custom implementation gives you control over memory, model selection, tool permissions, and the interface. It also makes you responsible for keeping those components consistent.

Approach	Customization	Best fit	Cost model	Main advantage
Consumer apps: Kalon, Kindroid, Nomi	Personality, visuals, backstory, long-term memory	Personal and social use	Freemium or subscription	Fast setup and immersion
Zoom Custom AI Companion	Agents, knowledge, avatars	Enterprise workflows	Add-on, approximately $12/user/month	Workflow integration
Custom GPTs / Copilot	Prompts and platform-dependent memory	Productivity	Subscription	Existing ecosystem
Custom API implementation	Application-controlled persona, memory, and tools	Custom products and scaling	Pay per use	Backend flexibility
Open-source models such as Llama	Fine-tuning and self-hosted behavior	Advanced deployments and privacy requirements	Hosting and operation costs	Ownership and control

For comparing models behind one interface, a unified gateway such as CometAPI offers an OpenAI-compatible API covering 500+ models, including GPT-5, Claude, Grok, and open-source options; its advertised 20–40% savings and 1M free testing tokens are terms I’d verify against the models and workload I actually intend to use.

I’d choose the platform based on the controls the product requires. Visual customization alone is a different requirement from owning retrieval, deletion, and tool execution.

Write a persona you can evaluate

“Be helpful and friendly” leaves too much behavior unspecified.

My persona specification would include a name, role, speaking style, values, interests, emotional range, relationship dynamic, and prohibited behaviors. For a fictional character, I’d add age and backstory.

The useful details are observable. “Short answers first” is testable. “A great personality” is not.

A compact study-coach instruction might look like this:

Be a calm, empathetic study coach who gives short answers first,
adds examples only when asked, avoids slang, and checks in with
the user after stressful topics.

For a character-driven companion, the source’s Elara example provides a different starting point:

You are Elara, a witty 28-year-old astrophysicist companion who
loves sci-fi and deep conversations. You respond warmly but
directly, using analogies from space exploration.

Neither prompt defines the whole product. Memory rules, sensitive-topic behavior, and tool access still need their own specifications.

I’d compare prompt variants against the same conversations and then compare models. Claims about one model being better at empathy or creativity are useful hypotheses; the actual persona needs evaluation on its own workload.

Make memory a product feature with user controls

I’d separate memory into three layers:

Session context: the current conversation.
Persistent user memory: stable preferences, recurring goals, and relevant history.
Retrieved context: facts or documents fetched for the current response.

For a custom build, persistent recall can use a memory layer such as mem0 or a custom implementation with Upstash Redis. RAG can bring in documents and user data when needed. A user profile can hold preferences such as communication style, favorite topics, and goals.

The important design choice is what deserves persistence. Storing everything makes it harder to distinguish a lasting preference from a passing comment.

ChatGPT illustrates the controls users increasingly expect: it can reference past chats, saved memories, and, where available, files and connected Gmail. Users can delete or clear memories, disable memory, or use Temporary Chat to prevent new memories from being created. Memory-source controls can also show what context contributed to personalization.

For my own implementation, I’d make remembered information inspectable and correctable. The critical test is a preference change: when the user contradicts an older preference, does the companion follow the updated one?

Specify boundaries alongside the personality

A warm persona still needs explicit limits. I’d define what it can discuss, when it should refuse, when it should redirect, and how it should handle sensitive emotional situations.

That specification should cover unsafe advice, privacy, disallowed content, and behavior that encourages emotional dependency.

Human-like presentation increases the chance that users attribute understanding or authority to the system. The companion should remain clear about its capabilities while responding with care.

These rules belong in evaluation from the beginning. A character that follows its backstory perfectly but mishandles a distressed user is not behaving consistently with the product requirements.

Ground answers before adding actions

Knowledge retrieval and tool execution solve different problems, and I’d configure them separately.

Knowledge sources can include internal documents, project notes, or web search. Custom dictionaries help with domain terminology; Zoom’s Custom AI Companion supports knowledge bases and custom dictionaries for this kind of adaptation.

Tools let the companion act through calendars, email, or other APIs. For custom implementations, function calling or model tool use provides the integration mechanism.

Model selection matters here as much as it does for conversation. A model that produces appealing dialogue still needs evaluation on tool selection and reasoning.

I’d also keep behavioral tuning explicit:

Temperature and top-p affect sampling behavior.
Response templates and custom dictionaries can improve consistency.
User ratings provide feedback for evaluation and, where implemented, retraining or RLHF-like processes.

Routine conversation should not be described as “training” unless the application actually updates model parameters. Often the change is in stored context, prompts, or retrieval.

Add voice and visuals once the text behavior holds up

Text remains the largest AI companion segment, while Grand View Research identifies multimodal companions as the fastest-growing segment.

That direction makes sense for product design: voice changes delivery, visual identity shapes how users perceive the character, and reactions to photos or screenshots provide additional context.

I’d still introduce these features incrementally:

Stabilize text behavior and memory.
Add a visual identity or scene imagery.
Add voice.
Evaluate more dynamic avatar behavior.

Image generation and editing options named in the source include GPT-image-2, Flux, and Midjourney. Voice can use selected or cloned TTS voices with emotional inflection; ElevenLabs integrations are common. Real-time avatars responding through emotion detection are an emerging direction in products such as Genies.

Each layer needs to match the established persona. An expressive voice cannot compensate for forgotten preferences or contradictory responses.

Ship against a conversation test suite

Before deployment, I’d run the same scenarios across prompt and model changes:

Scenario	What I’d check
The user has had a bad day	Tone adapts without abandoning boundaries
Playful banter	Humor stays consistent with the persona
A sensitive emotional topic	Support and redirection follow the specification
A conversation depends on older context	Relevant memory is retrieved accurately
The user changes a preference	New information takes precedence over stale context

Track coherence, user satisfaction, and latency alongside those cases. Test model changes against the whole interaction flow, including retrieval and tools.

Deployment can be a web interface, a mobile app, or an integration into an existing product. I’d keep the first release focused enough that a failure can be traced to a specific layer: persona, memory, retrieval, tools, or presentation. That gives each subsequent iteration a concrete problem to solve.

Originally published at cometapi.com

Top 6 OpenClaw Skills you can't afford to miss in 2026

Mason Reed — Mon, 21 Sep 2026 06:58:43 +0000

OpenClaw has emerged as one of the most transformative open-source projects of 2026, powering autonomous AI agents that don't just chat—they act. Running locally on your machine or VPS, OpenClaw connects large language models (like Claude, GPT, or local alternatives) with your files, apps, browser, terminal, and messaging platforms (WhatsApp, Telegram, Discord, etc.). It handles real tasks: clearing inboxes, managing calendars, executing workflows, and running 24/7 via heartbeat schedulers.

At the heart of OpenClaw's power are Skills—modular Markdown files (typically SKILL.md) that package instructions, prompts, tool calls, and workflows. These reusable components turn a generic agent into a specialized digital coworker. With thousands available on ClawHub and community repos, selecting the right ones is critical.

What Is OpenClaw and Why Skills Matter in 2026

OpenClaw (formerly Clawdbot/Moltbot) is a self-hosted agent runtime. It runs on Mac, Windows, or Linux, connects to any LLM (OpenAI, Anthropic, local models via Ollama, etc.), and uses messaging apps as the primary interface. It features persistent local memory (Markdown files), browser automation, shell execution, and proactive scheduling.

Skills are the extensibility layer. Defined primarily via SKILL.md (natural language instructions + tool calls), they allow the LLM to interpret and execute complex, multi-step tasks reliably. Community contributions exploded in 2026, with high-quality skills vetted on ClawHub.

Key Benefits:

Modularity: Install only what you need; chain them for complex workflows.
Extensibility: Community and self-created skills allow custom behaviors.
Persistence: Combined with memory systems (e.g., MEMORY.md, SOUL.md), skills enable long-term learning.
Safety & Control: Local execution keeps data private; vet skills carefully.

Data Support: Analyses of ClawHub show native/bundled tools cover ~70% of calls, but top community skills handle high-value tasks like email, browsing, and project management. Users report 90-day reliability improvements and significant time savings.

Installation Basics (General for Most Skills):

Ensure OpenClaw is installed and running (Docker, direct install, or VPS recommended).
Use the ClawHub CLI or manual placement in the skills directory.
Restart/reload the agent and test via your preferred chat app.
Configure API keys (e.g., for external services) in environment variables or config files.

Pro Recommendation: Power OpenClaw with CometAPI . This single OpenAI-compatible endpoint provides access to 500+ models (GPT-5 series, Claude Opus/Sonnet variants, Grok, DeepSeek, Llama, multimodal, etc.) at 20–40% lower costs, with free starter tokens. It eliminates multiple API keys, offers enterprise analytics/privacy controls, and ensures high uptime—perfect for always-on OpenClaw agents. Integrate once and route models dynamically for optimal cost/performance (e.g., cheaper models for routine tasks, frontier for complex reasoning).

1. GOG (Google Workspace Integration) — The Productivity Powerhouse

What it is: GOG (often steipete/gog or similar wrappers) provides unified access to Gmail, Calendar, Drive, Docs, Sheets, and Contacts via Google’s APIs/CLI.

Importance: Email and calendar management consume ~28% of knowledge workers’ time. GOG automates triage, scheduling, and data synthesis. It ranks among the most-installed skills (tens of thousands of downloads) and powers “AI employee” workflows.

How to install:

clawhub install gog (or official variants).
Authenticate via OAuth (use dedicated/scoped accounts for safety).
Add to workspace and test with “Summarize my unread emails.”

Key Functions:

Intelligent inbox triage, auto-archive, replies/drafts.
Calendar conflict detection, meeting scheduling, reminders.
Drive/Docs/Sheets: Search, summarize, update data, generate reports.
Proactive briefings (e.g., morning digest combining email + calendar + Drive files).

Use Cases & Data:

Founders: Auto-coordinate meetings and update Notion/Sheets CRMs.
Teams: Weekly status reports pulled from emails/Docs.
Personal: Flight check-ins or expense tracking from receipts in Drive. Real-world impact: Users achieve inbox zero and reclaim hours; integration with CometAPI allows cheaper models for high-volume email processing.

CometAPI Tip: Route routine summarization to cost-effective models while using premium ones for sensitive drafting.

2. Agent Browser / Web Automation Skill — Autonomous Internet Agent

What it is: Tools like Agent Browser or Playwright-based skills enable headless browsing, form filling, scraping, screenshots, and interaction with JS-heavy sites.

Importance: Web tasks (research, monitoring, transactions) are fragmented. This skill turns OpenClaw into a true agent, with high adoption for research and ops automation.

How to install:

clawhub install agent-browser (or top-rated equivalents).
Configure in sandbox (Docker recommended due to power).
Test: “Check flight status and summarize prices.”

Key Functions:

Navigate sites, handle logins (with care), extract structured data.
Automated check-ins, lead gen, price monitoring.
Screenshots + OCR for visual confirmation.
Multi-step workflows (e.g., research → fill form → confirm).

Use Cases:

Competitive intelligence: Daily SERP/competitor monitoring.
E-commerce: Price alerts, order tracking.
Research: Compile reports from multiple sources. Data shows web skills among top installs; combined with CometAPI’s fast models, it enables real-time loops without rate limits.

Security: Sandbox heavily; use approval for actions involving logins.

3. Self-Improving Agent / Capability Evolver — The Meta-Skill

What it is: Skills like Self-Improving Agent or Capability Evolver log interactions, errors, and preferences to refine behavior autonomously.

Importance: Static agents plateau; these create compounding intelligence. Highest-rated on ClawHub with strong community backing.

How to install:

clawhub install self-improving-agent or capability-evolver.
Point to memory folders; enable in SOUL.md.

Key Functions:

Persistent learning: Update preferences, avoid repeated mistakes.
Auto-generate or refine other skills.
Memory ontology for long-term context.
Error logging and self-correction loops.

Use Cases:

Personalization: Learns your style for emails/content.
Workflow evolution: Turns ad-hoc tasks into reusable automations.
Long-running agents: Improves over weeks/months. Users report significant gains in reliability; pair with CometAPI for diverse model routing to accelerate learning.

4. GitHub Integration — Developer and Team Workflow Accelerator

What it is: Official/community GitHub skills for repo management, PRs, issues, and commits.

Importance: Dev teams spend heavily on context-switching. This skill automates reviews, notifications, and maintenance—critical as AI coding scales in 2026.

How to install:

clawhub install github.
OAuth setup with scoped tokens.

Key Functions:

Monitor PRs/issues, auto-summarize, suggest reviewers.
Create branches, draft PRs, run basic CI checks.
Daily digests and triage from chat.
Code review assistance.

Use Cases:

Solo devs: “Fix failing tests” → autonomous loops.
Teams: Auto-close stale issues, generate release notes.
Integration with browser skill for external research. High download counts; CometAPI supports strong coding models (e.g., specialized coders) at lower cost.

5. Summarize Skill — Knowledge Distiller

What it is: Universal summarization across URLs, YouTube, podcasts, docs, and files.

Importance: Information overload is constant. This skill (10k+ downloads) delivers concise insights fast.

How to install:

clawhub install summarize.
Simple setup; works with local files too.

Key Functions:

Multi-format input → structured output (key points, action items).
Custom rubrics (e.g., “business implications”).
Batch processing for newsletters/research.
Integration with other skills (e.g., summarize then act).

Use Cases:

Daily news/podcast digests via heartbeats.
Meeting prep: Summarize related docs.
Research pipelines. Essential baseline skill; efficient with CometAPI’s balanced models.

6. Project Management Integrations (e.g., Linear, Notion) — Ops Orchestrator

What it is: Skills for Linear, Notion, Asana, etc., syncing tasks across tools.

Importance: Fragmented tools kill productivity. These unify execution.

How to install:

e.g., clawhub install linear or Notion equivalents.
API key/OAuth.

Key Functions:

Create/update tickets from chat/emails.
Status sync and cross-tool reports.
Auto-triage bugs from logs/emails.
Weekly digests and reminders.

Use Cases:

Founders: Link emails → tasks → Notion.
Teams: Standup automation.
Personal: Life admin tracking. Combines powerfully with GOG and self-improving skills.

How to choose the right OpenClaw skill

Choose skills based on repeated pain, not novelty. If a task happens every day, starts in chat, and ends with a tool action, it is a skill candidate. If it needs memory, timing, or strict guardrails, it is an even better candidate. OpenClaw’s own docs emphasize that skills teach the agent how and when to use tools, while plugins and tools provide the raw capability.

A good rule for 2026 is to start with the six skills above and then add custom workspace skills only after you have measured the pain point. OpenClaw supports local overrides, workspace skills, and precedence rules, so you do not need to keep editing the same repo copy to customize behavior.

Comparison Table: Top 6 OpenClaw Skills

Skill	Installs/Popularity	Best For	Complexity	Risk Level	CometAPI Synergy
GOG (Google)	Very High (top-ranked)	Productivity, Email/Calendar	Low-Medium	Medium (OAuth)	High (volume tasks)
Agent Browser	High	Research, Automation	Medium-High	High (sandbox)	High (real-time)
Self-Improving	High (top-rated)	Long-term Autonomy	Low	Low	Medium (learning loops)
GitHub	High	Dev Workflows	Medium	Medium	High (coding models)
Summarize	High	Knowledge Mgmt	Very Low	Low	High (efficiency)
Project Mgmt (Linear/Notion)	Medium-High	Ops/Teams	Low-Medium	Low-Medium	High (orchestration)

Skill/Category	Use Case	Install Difficulty	Popularity (Est.)	Key Benefit	CometAPI Synergy
GitHub	Repo management, PRs	Low	Very High	Autonomous dev workflows	Reliable coding models
Agent Browser	Web automation	Medium	High	Browser actions without manual	Vision/ multimodal models
Web Search	Real-time research	Low	High	Fresh data synthesis	Fast, cheap inference
Summarize/Notion	Content & knowledge mgmt	Low	High	Structured output	Long-context models (GPT-5.4)
Self-Improving	Agent evolution	Medium	Growing	Reduced errors over time	Consistent model perf via CometAPI
Calendar/Email	Daily productivity	Low	Very High	Proactive scheduling	Low-latency for frequent calls

Advanced Tips, Security, and Scaling in 2026

Memory & Heartbeats: Combine skills with persistent memory and scheduled runs for proactive agents.
Security Best Practices: Dedicated user/sandbox, VirusTotal checks on ClawHub, approval gates, read-only defaults, regular audits. Consider NVIDIA NemoClaw for added guardrails.
Multi-Agent Setups: Run specialized OpenClaw instances (e.g., one for coding, one for personal).
CometAPI Integration: Set as primary provider in OpenClaw config. Use model routing for cost optimization (e.g., via their dashboard analytics). Benefits: Single key, broad model access (including latest releases), lower latency/cost, privacy focus. Ideal for high-token agents.
Building Custom Skills: OpenClaw can help generate them—start simple with SKILL.md.

Future Outlook: By late 2026, expect deeper multimodal skills, better enterprise controls, and even more seamless integrations. Skills like these position you at the forefront.

Conclusion: Level Up Your OpenClaw Today

These top 6 skills—GOG, Agent Browser, Self-Improving/Capability Evolver, GitHub, Summarize, and Project Management—form a robust foundation for a truly autonomous AI teammate in 2026. Start with core productivity ones (GOG + Summarize), then layer on automation and self-improvement.

Ready to deploy? Head to openclaw.ai, install via the one-liner, and power it with CometAPI at cometapi.com for seamless, affordable access to the best models. Experiment safely, iterate with your agent, and watch productivity soar.

Originally published at cometapi.com

How to Add AI Video Generation to a SaaS App

Mason Reed — Mon, 21 Sep 2026 04:40:33 +0000

Adding video generation to your app is not the same as adding image generation. The API call returns immediately — but the video isn't ready yet. You get a task ID, and you have to keep asking "is it done?" until it is.

Most developers hit this the first time they call a video API, wait for a response body with a video URL, and get back a task ID instead. This guide walks through the full flow: submitting a task, polling for results, handling failures, and storing the output before the URL expires.

What you'll build

A backend service that accepts a text prompt or image, submits a video generation task, polls until it's complete, and returns the final video URL. You'll work with four models — Veo 3 Fast, Sora 2, Kling Video, and Runway — all through a single API key.

Prerequisites:

Python 3.8+ or Node.js 18+
A CometAPI key
Basic familiarity with REST APIs

Understand why video generation is different

With image generation, you send a request and get the image back in the same response. Video generation uses an async task queue:

Submit a generation request → get back a task_id
Poll a status endpoint every few seconds
When status reaches a terminal state, you get the video URL
Download and store the video — the URL is temporary

If you treat video generation like image generation and wait for the first response to contain your video, your request will time out every time.

In a production web service, this polling loop should run in a background worker (Celery, Bull, or similar), not in your request handler. The examples below use synchronous polling — fine for scripts and prototypes, but not for handling concurrent users.

Choose a model

Model	Provider	Max duration	Price (via CometAPI)	Best for
Veo 3 Fast	Google	8 sec	$0.05/sec	Fast prototyping, social clips
Sora 2	OpenAI (via CometAPI model ID)	~10 sec	$0.08/sec	High-quality creative shorts
Kling Video	Kuaishou	10 sec	$0.13–$2.64/task	Marketing content, granular control
Runway Gen-3A Turbo	Runway	5 or 10 sec	$0.32/task	Image-to-video, commercial content

Source**: CometAPI model pages, May 2026. Note: "Sora 2" is CometAPI's model identifier — refer to their model page for the underlying model details.

Veo 3 Fast supports both text-to-video and image-to-video. Cheapest per second, good starting point.
Sora 2 generates audio natively alongside the video — dialogue, ambient sound, and effects without a separate TTS step.
Kling Video gives you negative_prompt, cfg_scale, camera movement settings, and a pro mode. Most control of the four.
Runway is image-to-video only via CometAPI. Give it a static image and a motion description, and it animates it.

Submit a Veo task

Veo uses multipart/form-data. Use files= in Python requests to send it correctly — data=dict sends application/x-www-form-urlencoded, which is not the same thing:

import requestsimport osfrom dotenv import load_dotenvload_dotenv()def submit_veo_task(prompt: str, size: str = "16x9") -&gt; str: &nbsp; &nbsp;"""Submit a Veo 3 Fast text-to-video task. Returns task_id.""" &nbsp; &nbsp;api_key = os.getenv("COMETAPI_KEY") &nbsp; &nbsp;if not api_key: &nbsp; &nbsp; &nbsp; &nbsp;raise ValueError("COMETAPI_KEY environment variable is not set") &nbsp; &nbsp;response = requests.post( &nbsp; &nbsp; &nbsp; &nbsp;"https://api.cometapi.com/v1/videos", &nbsp; &nbsp; &nbsp; &nbsp;headers={"Authorization": f"Bearer {api_key}"}, &nbsp; &nbsp; &nbsp; &nbsp;files={ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"prompt": (None, prompt), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"model": (None, "veo3-fast"), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"size": (None, size) &nbsp; &nbsp; &nbsp;  }, &nbsp; &nbsp; &nbsp; &nbsp;timeout=30 &nbsp;  ) &nbsp; &nbsp;response.raise_for_status() &nbsp; &nbsp;return response.json()["id"]task_id = submit_veo_task("A paper kite drifting above a wheat field on a windy afternoon")print(f"Task submitted: {task_id}")

Poll for the result

import timedef poll_veo_task(task_id: str, interval: int = 10, max_wait: int = 600) -&gt; str: &nbsp; &nbsp;"""Poll until Veo task completes. Returns video URL.""" &nbsp; &nbsp;api_key = os.getenv("COMETAPI_KEY") &nbsp; &nbsp;if not api_key: &nbsp; &nbsp; &nbsp; &nbsp;raise ValueError("COMETAPI_KEY environment variable is not set") &nbsp; &nbsp;headers = {"Authorization": f"Bearer {api_key}"} &nbsp; &nbsp;url = f"https://api.cometapi.com/v1/videos/{task_id}" &nbsp; &nbsp;elapsed = 0 &nbsp; &nbsp;while elapsed &lt; max_wait: &nbsp; &nbsp; &nbsp; &nbsp;response = requests.get(url, headers=headers, timeout=30) &nbsp; &nbsp; &nbsp; &nbsp;response.raise_for_status() &nbsp; &nbsp; &nbsp; &nbsp;result = response.json() &nbsp; &nbsp; &nbsp; &nbsp;status = result.get("status") &nbsp; &nbsp; &nbsp; &nbsp;if status == "succeeded": &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return result["output"][0] &nbsp; &nbsp; &nbsp; &nbsp;elif status in ("failed", "cancelled"): &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;raise RuntimeError( &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;f"Task {task_id} failed with status '{status}': " &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;f"{result.get('error', 'no error detail returned')}" &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ) &nbsp; &nbsp; &nbsp; &nbsp;time.sleep(interval) &nbsp; &nbsp; &nbsp; &nbsp;elapsed += interval &nbsp; &nbsp;raise TimeoutError(f"Task {task_id} did not complete within {max_wait} seconds")video_url = poll_veo_task(task_id)print(f"Video ready: {video_url}")

Use Kling Video for more control

Kling has a different endpoint structure and uses JSON. Note that Kling's terminal status string is "succeed" (not "succeeded") — this matches the API's actual response format:

def submit_kling_task(prompt: str, duration: str = "5", mode: str = "std") -&gt; str: &nbsp; &nbsp;"""Submit a Kling text-to-video task. Returns task_id.""" &nbsp; &nbsp;api_key = os.getenv("COMETAPI_KEY") &nbsp; &nbsp;if not api_key: &nbsp; &nbsp; &nbsp; &nbsp;raise ValueError("COMETAPI_KEY environment variable is not set") &nbsp; &nbsp;response = requests.post( &nbsp; &nbsp; &nbsp; &nbsp;"https://api.cometapi.com/kling/v1/videos/text2video", &nbsp; &nbsp; &nbsp; &nbsp;headers={ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"Authorization": f"Bearer {api_key}", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"Content-Type": "application/json" &nbsp; &nbsp; &nbsp;  }, &nbsp; &nbsp; &nbsp; &nbsp;json={ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"model_name": "kling-v1-6", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"prompt": prompt, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"negative_prompt": "blurry, low quality, watermark", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"cfg_scale": 0.5, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"mode": mode, &nbsp; &nbsp; &nbsp; &nbsp; # "std" or "pro" &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"aspect_ratio": "16:9", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"duration": duration &nbsp;# "5" or "10" &nbsp; &nbsp; &nbsp;  }, &nbsp; &nbsp; &nbsp; &nbsp;timeout=30 &nbsp;  ) &nbsp; &nbsp;response.raise_for_status() &nbsp; &nbsp;return response.json()["data"]["task_id"]def poll_kling_task(task_id: str, interval: int = 10, max_wait: int = 600) -&gt; str: &nbsp; &nbsp;"""Poll Kling task until complete. Returns video URL.""" &nbsp; &nbsp;api_key = os.getenv("COMETAPI_KEY") &nbsp; &nbsp;if not api_key: &nbsp; &nbsp; &nbsp; &nbsp;raise ValueError("COMETAPI_KEY environment variable is not set") &nbsp; &nbsp;headers = {"Authorization": f"Bearer {api_key}"} &nbsp; &nbsp;url = f"https://api.cometapi.com/kling/v1/videos/text2video/{task_id}" &nbsp; &nbsp;elapsed = 0 &nbsp; &nbsp;while elapsed &lt; max_wait: &nbsp; &nbsp; &nbsp; &nbsp;response = requests.get(url, headers=headers, timeout=30) &nbsp; &nbsp; &nbsp; &nbsp;response.raise_for_status() &nbsp; &nbsp; &nbsp; &nbsp;result = response.json() &nbsp; &nbsp; &nbsp; &nbsp;status = result["data"]["task_status"] &nbsp; &nbsp; &nbsp; &nbsp;if status == "succeed": &nbsp;# Kling uses "succeed", not "succeeded" &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return result["data"]["task_result"]["videos"][0]["url"] &nbsp; &nbsp; &nbsp; &nbsp;elif status == "failed": &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;error_detail = result.get("data", {}).get("task_result", "no detail") &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;raise RuntimeError( &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;f"Kling task {task_id} failed: {error_detail}" &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ) &nbsp; &nbsp; &nbsp; &nbsp;time.sleep(interval) &nbsp; &nbsp; &nbsp; &nbsp;elapsed += interval &nbsp; &nbsp;raise TimeoutError(f"Kling task {task_id} timed out after {max_wait}s")

Source**: CometAPI Kling Video docs

Animate a static image with Runway

Runway is image-to-video only. It also requires an extra header (X-Runway-Version):

def submit_runway_task(image_url: str, motion_prompt: str, duration: int = 5) -&gt; str: &nbsp; &nbsp;"""Submit a Runway image-to-video task. Returns task_id.""" &nbsp; &nbsp;api_key = os.getenv("COMETAPI_KEY") &nbsp; &nbsp;if not api_key: &nbsp; &nbsp; &nbsp; &nbsp;raise ValueError("COMETAPI_KEY environment variable is not set") &nbsp; &nbsp;response = requests.post( &nbsp; &nbsp; &nbsp; &nbsp;"https://api.cometapi.com/runwayml/v1/image_to_video", &nbsp; &nbsp; &nbsp; &nbsp;headers={ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"Authorization": f"Bearer {api_key}", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"X-Runway-Version": "2024-11-06", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"Content-Type": "application/json" &nbsp; &nbsp; &nbsp;  }, &nbsp; &nbsp; &nbsp; &nbsp;json={ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"model": "gen3a_turbo", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"promptImage": image_url, &nbsp;# must be a stable HTTPS URL &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"promptText": motion_prompt, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"duration": duration, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"ratio": "1280:720", &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"watermark": False &nbsp; &nbsp; &nbsp;  }, &nbsp; &nbsp; &nbsp; &nbsp;timeout=30 &nbsp;  ) &nbsp; &nbsp;response.raise_for_status() &nbsp; &nbsp;return response.json()["id"]def poll_runway_task(task_id: str, interval: int = 5, max_wait: int = 600) -&gt; str: &nbsp; &nbsp;"""Poll Runway task. Returns video URL when done.""" &nbsp; &nbsp;api_key = os.getenv("COMETAPI_KEY") &nbsp; &nbsp;if not api_key: &nbsp; &nbsp; &nbsp; &nbsp;raise ValueError("COMETAPI_KEY environment variable is not set") &nbsp; &nbsp;headers = { &nbsp; &nbsp; &nbsp; &nbsp;"Authorization": f"Bearer {api_key}", &nbsp; &nbsp; &nbsp; &nbsp;"X-Runway-Version": "2024-11-06" &nbsp;  } &nbsp; &nbsp;url = f"https://api.cometapi.com/runwayml/v1/tasks/{task_id}" &nbsp; &nbsp;elapsed = 0 &nbsp; &nbsp;while elapsed &lt; max_wait: &nbsp; &nbsp; &nbsp; &nbsp;response = requests.get(url, headers=headers, timeout=30) &nbsp; &nbsp; &nbsp; &nbsp;response.raise_for_status() &nbsp; &nbsp; &nbsp; &nbsp;result = response.json() &nbsp; &nbsp; &nbsp; &nbsp;status = result.get("status") &nbsp; &nbsp; &nbsp; &nbsp;if status == "task_not_exist": &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# CometAPI-specific: task is still initializing, retry after a few seconds &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;time.sleep(interval) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;elapsed += interval &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;continue &nbsp; &nbsp; &nbsp; &nbsp;elif status == "succeeded": &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return result["output"][0] &nbsp; &nbsp; &nbsp; &nbsp;elif status in ("failed", "cancelled"): &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;raise RuntimeError(f"Runway task {task_id} failed: {result.get('error', 'no detail')}") &nbsp; &nbsp; &nbsp; &nbsp;time.sleep(interval) &nbsp; &nbsp; &nbsp; &nbsp;elapsed += interval &nbsp; &nbsp;raise TimeoutError(f"Runway task {task_id} timed out after {max_wait}s")

Source**: CometAPI Runway docs

Save the video before the URL expires

Video URLs from generation APIs are temporary. Download the file immediately and store it somewhere you control:

import requestsimport pathlibdef download_video(url: str, output_path: str) -&gt; None: &nbsp; &nbsp;"""Download video from URL to local file using streaming.""" &nbsp; &nbsp;out = pathlib.Path(output_path) &nbsp; &nbsp;if out.parent != pathlib.Path("."): &nbsp; &nbsp; &nbsp; &nbsp;out.parent.mkdir(parents=True, exist_ok=True) &nbsp; &nbsp;with requests.get(url, stream=True, timeout=60) as r: &nbsp; &nbsp; &nbsp; &nbsp;r.raise_for_status() &nbsp; &nbsp; &nbsp; &nbsp;with open(out, "wb") as f: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for chunk in r.iter_content(chunk_size=8192): &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;f.write(chunk) &nbsp; &nbsp;print(f"Saved to {output_path}")# Full flowtask_id = submit_veo_task("A timelapse of clouds moving over a city skyline")video_url = poll_veo_task(task_id)download_video(video_url, "output/city_timelapse.mp4")

In production, swap the local file write for an upload to S3, Cloudflare R2, or your storage of choice. The streaming pattern stays the same — pipe the bytes directly rather than loading the whole video into memory.

Handle failures

Symptom	Likely cause	Fix
Task stuck in queued for 10+ min	Server load or model unavailable	Retry with a different model
task_not_exist on first Runway poll	Task still initializing	Wait 5 sec and retry — documented CometAPI behavior
failed with no error message	Prompt triggered content filter	Rephrase the prompt
Video URL returns 403	URL expired before download	Download immediately after getting the URL
Timeout after 10 min	Generation took too long	Increase max_wait or switch to Veo 3 Fast
Kling returns "succeed" not "succeeded"	Kling's API uses non-standard status string	This is correct — see Kling polling code above

Source: CometAPI video generation docs

Node.js version

Node.js 18+ includes fetch and FormData natively. This example covers all four models:

// Node.js 18+ — no extra packages neededconst API_KEY = process.env.COMETAPI_KEY;if (!API_KEY) throw new Error('COMETAPI_KEY is not set');// --- Veo 3 Fast ---async function submitVeoTask(prompt, size = '16x9') { &nbsp;const form = new FormData(); &nbsp;form.append('prompt', prompt); &nbsp;form.append('model', 'veo3-fast'); &nbsp;form.append('size', size); &nbsp;const res = await fetch('https://api.cometapi.com/v1/videos', { &nbsp; &nbsp;method: 'POST', &nbsp; &nbsp;headers: { 'Authorization': `Bearer ${API_KEY}` }, &nbsp; &nbsp;body: form  }); &nbsp;if (!res.ok) throw new Error(`Veo submit failed: ${res.status}`); &nbsp;return (await res.json()).id;}async function pollVeoTask(taskId, intervalMs = 10000, maxWaitMs = 600000) { &nbsp;let elapsed = 0; &nbsp;while (elapsed &lt; maxWaitMs) { &nbsp; &nbsp;const res = await fetch(`https://api.cometapi.com/v1/videos/${taskId}`, { &nbsp; &nbsp; &nbsp;headers: { 'Authorization': `Bearer ${API_KEY}` } &nbsp;  }); &nbsp; &nbsp;if (!res.ok) throw new Error(`Poll failed: ${res.status}`); &nbsp; &nbsp;const result = await res.json(); &nbsp; &nbsp;if (result.status === 'succeeded') return result.output[0]; &nbsp; &nbsp;if (['failed', 'cancelled'].includes(result.status)) { &nbsp; &nbsp; &nbsp;throw new Error(`Task ${taskId} failed: ${result.error ?? 'no detail'}`); &nbsp;  } &nbsp; &nbsp;await new Promise(r =&gt; setTimeout(r, intervalMs)); &nbsp; &nbsp;elapsed += intervalMs;  } &nbsp;throw new Error(`Task ${taskId} timed out`);}// --- Kling Video ---async function submitKlingTask(prompt, duration = '5', mode = 'std') { &nbsp;const res = await fetch('https://api.cometapi.com/kling/v1/videos/text2video', { &nbsp; &nbsp;method: 'POST', &nbsp; &nbsp;headers: { &nbsp; &nbsp; &nbsp;'Authorization': `Bearer ${API_KEY}`, &nbsp; &nbsp; &nbsp;'Content-Type': 'application/json' &nbsp;  }, &nbsp; &nbsp;body: JSON.stringify({ &nbsp; &nbsp; &nbsp;model_name: 'kling-v1-6', &nbsp; &nbsp; &nbsp;prompt, &nbsp; &nbsp; &nbsp;negative_prompt: 'blurry, low quality, watermark', &nbsp; &nbsp; &nbsp;cfg_scale: 0.5, &nbsp; &nbsp; &nbsp;mode, &nbsp; &nbsp; &nbsp;aspect_ratio: '16:9', &nbsp; &nbsp; &nbsp;duration &nbsp;  })  }); &nbsp;if (!res.ok) throw new Error(`Kling submit failed: ${res.status}`); &nbsp;return (await res.json()).data.task_id;}async function pollKlingTask(taskId, intervalMs = 10000, maxWaitMs = 600000) { &nbsp;let elapsed = 0; &nbsp;while (elapsed &lt; maxWaitMs) { &nbsp; &nbsp;const res = await fetch( &nbsp; &nbsp; &nbsp;`https://api.cometapi.com/kling/v1/videos/text2video/${taskId}`, &nbsp; &nbsp;  { headers: { 'Authorization': `Bearer ${API_KEY}` } } &nbsp;  ); &nbsp; &nbsp;if (!res.ok) throw new Error(`Kling poll failed: ${res.status}`); &nbsp; &nbsp;const result = await res.json(); &nbsp; &nbsp;const status = result.data.task_status; &nbsp; &nbsp;if (status === 'succeed') return result.data.task_result.videos[0].url; &nbsp; &nbsp;if (status === 'failed') { &nbsp; &nbsp; &nbsp;throw new Error(`Kling task ${taskId} failed: ${JSON.stringify(result.data.task_result ?? 'no detail')}`); &nbsp;  } &nbsp; &nbsp;await new Promise(r =&gt; setTimeout(r, intervalMs)); &nbsp; &nbsp;elapsed += intervalMs;  } &nbsp;throw new Error(`Kling task ${taskId} timed out`);}// --- Runway (image-to-video) ---async function submitRunwayTask(imageUrl, motionPrompt, duration = 5) { &nbsp;const res = await fetch('https://api.cometapi.com/runwayml/v1/image_to_video', { &nbsp; &nbsp;method: 'POST', &nbsp; &nbsp;headers: { &nbsp; &nbsp; &nbsp;'Authorization': `Bearer ${API_KEY}`, &nbsp; &nbsp; &nbsp;'X-Runway-Version': '2024-11-06', &nbsp; &nbsp; &nbsp;'Content-Type': 'application/json' &nbsp;  }, &nbsp; &nbsp;body: JSON.stringify({ &nbsp; &nbsp; &nbsp;model: 'gen3a_turbo', &nbsp; &nbsp; &nbsp;promptImage: imageUrl, &nbsp; &nbsp; &nbsp;promptText: motionPrompt, &nbsp; &nbsp; &nbsp;duration, &nbsp; &nbsp; &nbsp;ratio: '1280:720', &nbsp; &nbsp; &nbsp;watermark: false &nbsp;  })  }); &nbsp;if (!res.ok) throw new Error(`Runway submit failed: ${res.status}`); &nbsp;return (await res.json()).id;}async function pollRunwayTask(taskId, intervalMs = 5000, maxWaitMs = 600000) { &nbsp;let elapsed = 0; &nbsp;while (elapsed &lt; maxWaitMs) { &nbsp; &nbsp;const res = await fetch( &nbsp; &nbsp; &nbsp;`https://api.cometapi.com/runwayml/v1/tasks/${taskId}`, &nbsp; &nbsp;  { headers: { 'Authorization': `Bearer ${API_KEY}`, 'X-Runway-Version': '2024-11-06' } } &nbsp;  ); &nbsp; &nbsp;if (!res.ok) throw new Error(`Runway poll failed: ${res.status}`); &nbsp; &nbsp;const result = await res.json(); &nbsp; &nbsp;const status = result.status; &nbsp; &nbsp;if (status === 'task_not_exist') { &nbsp; &nbsp; &nbsp;// CometAPI-specific: task still initializing &nbsp; &nbsp; &nbsp;await new Promise(r =&gt; setTimeout(r, intervalMs)); &nbsp; &nbsp; &nbsp;elapsed += intervalMs; &nbsp; &nbsp; &nbsp;continue; &nbsp;  } &nbsp; &nbsp;if (status === 'succeeded') return result.output[0]; &nbsp; &nbsp;if (['failed', 'cancelled'].includes(status)) { &nbsp; &nbsp; &nbsp;throw new Error(`Runway task ${taskId} failed: ${result.error ?? 'no detail'}`); &nbsp;  } &nbsp; &nbsp;await new Promise(r =&gt; setTimeout(r, intervalMs)); &nbsp; &nbsp;elapsed += intervalMs;  } &nbsp;throw new Error(`Runway task ${taskId} timed out`);}// Usage exampleconst taskId = await submitVeoTask('A paper kite drifting above a wheat field');const videoUrl = await pollVeoTask(taskId);console.log('Video ready:', videoUrl);

What's next

You now have working code for four video models, a polling loop that handles failures, and a download step that keeps you from losing generated content.

The next problem most developers hit: they've hardcoded one model, and switching to a cheaper or faster option means touching multiple files. The next article covers how to route requests across models without rewriting your code.

Next: How to Switch Between AI Models Without Rewriting Your Code

FAQ

Q: Why do I get a task ID instead of a video in the API response?

Video generation is async — models like Veo, Sora, Kling, and Runway take 2–5 minutes to render. The API returns a task ID immediately so your request doesn't time out. You poll a separate status endpoint until the task reaches a terminal state (succeeded, succeed, failed).

Q: How long does a generated video URL stay valid?

Video URLs from generation APIs are temporary. Download the file immediately after getting the URL and store it in your own storage (S3, Cloudflare R2, etc.). Don't store the URL and expect it to work hours later.

Q: What's the difference between Veo 3 Fast and Kling Video?

Veo 3 Fast is cheaper ($0.05/sec), faster, and simpler to call. Kling Video gives you more control: negative_prompt, cfg_scale, camera movement settings, and a pro quality mode. If you need to fine-tune the output, use Kling. If you need speed and low cost, use Veo 3 Fast.

Q: Can I generate video from an image instead of a text prompt?

Yes. Veo supports image-to-video by passing an input_reference file. Kling supports it via the /kling/v1/videos/image2video endpoint with an image parameter (URL or base64). Runway is image-to-video only — it doesn't accept text-only prompts via CometAPI.

Q: Why does Runway return `task_not_exist` on the first poll?

This is documented CometAPI behavior — the task is still initializing on the backend. Wait a few seconds and retry. It's not an error. The polling code above handles this automatically.

Q: Why does Kling use `"succeed"` instead of `"succeeded"`?

That's Kling's actual API response format. It's not a typo. Veo and Runway use "succeeded" — Kling uses "succeed". If you're building a unified polling wrapper, you'll need to handle both strings.

Q: Is the synchronous polling loop safe to use in a web server?

No. The polling loop in this guide blocks the thread for minutes at a time. In a real web service with concurrent users, run the polling in a background worker (Celery for Python, Bull for Node.js). Submit the task in the request handler, return the task ID to the client, and let the worker notify the client when the video is ready.

Originally published at cometapi.com

The Hidden Cost of Juggling OpenAI, Anthropic, and Google Credentials

Mason Reed — Mon, 21 Sep 2026 04:17:59 +0000

Multi-provider AI setups don't show their cost in the API bill — they show it in developer hours. Once you put a number on it, the case for consolidation stops being a matter of taste and becomes a line item your finance team can defend.

The cost most teams never count

Most product engineering teams running on top of three or four AI providers can tell you to the dollar what they spent on tokens last month. They can tell you which feature drove the most cost, which model is cheapest per million tokens, and whether their burn rate is on track for the quarter. What they usually cannot tell you is what the operational overhead of running three or four provider relationships actually costs them in developer time.

This is not because the cost is invisible. Every engineer on the team feels it. It is because the cost is paid in increments small enough to dismiss — a credential lookup here, a debugging session there, a half-day of integration work the next time a new model ships. None of these show up in any standard cost report. The API bill captures inference cost. The cloud bill captures infrastructure cost. Engineering time spent on cross-provider operational work shows up nowhere, because no system was designed to capture it. The default reporting infrastructure has a blind spot exactly the shape of this category of work.

This article is the version of that conversation that puts numbers on the table. The argument is not that multi-provider AI is bad — there are workloads where running multiple providers is genuinely the right architectural choice. The argument is that the operational cost of that choice is real, quantifiable, and usually larger than teams realise. Once you can name the figure, the architectural conversation becomes a real cost-benefit analysis instead of a series of competing intuitions.

The headline finding: For a typical five-engineer team running three AI providers, the annual operational cost of multi-provider work — counted in developer hours alone — sits between $35,000 and $60,000. That is not a hypothetical; it is what comes out when you instrument the workflow and add up the actual time. The number doesn't appear on any budget because no system was built to capture it. The case for changing your setup is what happens when you start counting it.

5 hidden line items

The operational cost of multi-provider AI work breaks down into five categories, each of which can be measured if you decide to. None of them is enormous in isolation; the cost is in the aggregate. Below, each category, what it looks like in practice, and how much time it consumes per month for a representative engineering team.

1. Initial onboarding to each provider

Setting up a new AI provider relationship is a multi-step process. Sign up for the account. Verify the email and any payment method. Read the rate-limit documentation. Set up secrets management for the new credential. Install the provider's SDK if it differs from what you already use. Wire the credential through your CI/CD pipeline so deploys can authenticate. Add the new provider to your secrets-rotation calendar. For a typical provider, this is 4–8 hours of engineering time, mostly done by one engineer but with at least some coordination overhead from others.

This cost is paid once per provider, but the "once" matters. If your team adds one new provider per year — which is below the 2026 baseline for serious teams — you pay this cost annually. The first onboarding doesn't feel expensive because it is one engineer for one afternoon. The fourth onboarding, when the same engineer has now done it four times in eighteen months and is increasingly resistant to doing it again, is where the friction shows up.

2. Monthly billing reconciliation

Every month-end, someone on the team — usually the lead engineer or technical founder — pulls usage data from each provider's dashboard, normalises the formats, attributes the costs to product features or clients, and produces a consolidated view. For a team with three providers and a clean usage pattern, this is roughly 2–4 hours per month. For a team with four or more providers, or with complex cost-attribution requirements (per-feature, per-client, or per-team), it can be 6–10 hours per month.

The reconciliation work is not engineering work in any meaningful sense — it is bookkeeping done by someone who is overqualified for the task. The fact that it lands on the engineering side rather than the finance side is itself a clue that the workflow has not been designed; it has just accumulated.

3. Credential rotation and security hygiene

Good security practice requires rotating API credentials periodically — quarterly for most teams, more frequently for regulated workloads. With one provider, this is a routine 30-minute task. With three or four providers, each with its own rotation interface, its own propagation timing, and its own potential failure modes, the same task expands to several hours per cycle. Add the time spent debugging when a rotated credential doesn't propagate cleanly to a production environment, and the cost rises further. A team that rotates credentials quarterly across four providers loses 8–15 hours per year to this specific category alone.

4. Debugging auth and integration errors across providers

A request fails. Was it a rate limit? An auth error? A model deprecation? A content-policy refusal? On a single-provider setup, this is one debugging surface. On a multi-provider setup, it is multiple — and the error formats, status codes, and dashboard log layouts differ across each. The cognitive cost of switching between provider conventions during incident response is the friction point that bites worst, because it lands during exactly the moments when speed matters most. For a team with three providers, this category typically runs 2–4 hours per month — and spikes much higher when a provider has an outage or changes their auth model unexpectedly.

5. Re-evaluating model choices each time a new release lands

In 2026, new frontier model releases happen roughly every three to six weeks. Each release triggers a small evaluation cycle: read the model card, decide whether it warrants testing against your workload, set up the integration if it's from a provider you don't already have access to, run your eval suite, compare results. On a multi-provider direct setup, this cycle is 1–2 days of engineering time per release, mostly because the setup cost is non-trivial. On a single-endpoint setup with the new model already available behind the same credential, the same evaluation is 1–2 hours. The difference, multiplied by 6–10 evaluation cycles per year, is meaningful.

Putting numbers on it

The categories above are easy to describe and easy to dismiss as small. The exercise that changes the conversation is multiplying them out for a realistic team. Below, the calculation for a five-engineer product team running three AI providers — the kind of setup that has become unremarkable for AI-native startups.

Cost category	Hours per month	Hours per year	Annual cost ($)
Initial provider onboarding (1 new provider/year)	—	5 hrs	$675
Monthly billing reconciliation	3 hrs	36 hrs	$4,860
Quarterly credential rotation across 3 providers	—	12 hrs	$1,620
Debugging auth and integration errors	3 hrs	36 hrs	$4,860
New model evaluations (8 releases/year)	—	120 hrs	$16,200
Daily context-switching tax (15 min/engineer)	25 hrs	300 hrs	$40,500
Total annual operational cost	—	509 hrs	$68,715

How the numbers are calculated. Hours per month for shared work (reconciliation, debugging) are total team hours, not per-engineer. The daily context-switching tax is 15 minutes per engineer per working day, multiplied by five engineers and roughly 200 working days a year. Dollar conversion uses a fully-loaded engineering cost of $135/hour, which is a conservative figure for a mid-level engineer in the US or UK once salary, benefits, taxes, and overhead are accounted for. Adjust both the team size and the hourly rate for your specific situation; the structure of the calculation is the same.

Three observations about this table that matter more than the bottom-line number.

First, the largest line is the one teams notice least. The $40,500 daily context-switching tax — 15 minutes per engineer per day on dashboard checks, credential lookups, and cross-provider documentation — is paid in tiny enough increments that no one feels it as a cost. It is also, by a meaningful margin, the largest single item on the table. The accumulated effect of small daily frictions outweighs every other category combined.

Second, the model evaluation cost is the most strategically expensive. $16,200 a year on evaluation cycles is significant, but the real cost is the evaluations that don't happen because the setup cost makes them not worth it. Teams running multi-provider direct setups evaluate fewer new models, take longer to migrate when a better fit appears, and end up running suboptimal model choices for longer than they should. The hidden cost of slower iteration is harder to put a number on, but it is real.

Third, the calculation is conservative. The numbers above assume a team that has its multi-provider workflow working reasonably well. Teams in worse shape — with credential rotation neglected, with no consistent reconciliation cadence, with evaluation cycles that take longer because eval infrastructure isn't in place — face higher numbers. The $68,715 figure is what good operational discipline looks like; the figure for teams without it can comfortably be twice that.

Why this cost never appears on the budget

If the operational cost is this large, why does no team have a line item for it? The answer is structural, not accidental. Four reasons together explain the blind spot:

No system was built to capture this category. Time-tracking systems are built for billable client work. Engineering reporting is built for feature delivery. Cost-attribution systems are built for COGS. None of them have a natural place to record "45 minutes debugging a rate-limit issue across two providers." The work happens; the recording infrastructure for it doesn't exist.
The increments are small enough to dismiss. Each individual instance of this work is 5–30 minutes. That's below the threshold most engineers would treat as worth tracking. The cost shows up only when you add the increments across the year — which nobody does, because there's no system that does it automatically.
The work is invisible from outside the engineering team. The CTO sees feature delivery velocity. The CFO sees the API bill. Neither sees the integration overhead in between. Unless an engineer escalates the cost explicitly — and most don't, because they have built the work into their normal routine — the category remains structurally invisible to the people making the architectural decisions.
The framing is engineering culture, not finance language. Engineers describe this work as "keeping the lights on" or "normal operational overhead" — language that doesn't trigger budget scrutiny. If the same work were described as "$68,715 a year of operational integration cost," the response from leadership would be immediate. The framing controls whether the cost becomes visible.

Together, these four factors create the blind spot that makes the multi-provider operational cost so persistent. The cost is real, the impact is significant, and almost nothing in the standard reporting infrastructure surfaces it. Making the case to change your setup starts with the framing — naming the cost in finance language is what brings it into the conversation.

The break-even calculation

Once you have the annual operational cost named, the question becomes: at what team size or workload volume does consolidating to a single-endpoint setup pay back the migration cost? The migration itself is genuinely small — typically 4–16 engineering hours depending on how the existing codebase is structured. Below the break-even point, that migration cost outweighs the operational saving; above it, the saving accumulates from the first month onwards.

Working backwards from the calculation above, the break-even for a team of five engineers running three providers is approximately one month of operational saving — about $5,700 per month of reclaimed engineering time covers the entire migration cost. For smaller teams, the break-even can be longer; for larger teams, it shortens to a few weeks. Three scenarios that bracket the typical range:

Team profile	Annual operational cost (est.)	Migration cost (est.)	Break-even
Solo founder, 2 providers	$12,000	$1,000	1 month
5-engineer startup, 3 providers	$68,000	$2,000	2 weeks
12-engineer scale-up, 4 providers	$180,000	$4,000	1 week

The pattern is consistent: the larger the team and the more providers in scope, the faster the break-even. The break-even calculation also doesn't include the secondary benefits — faster model evaluation cycles, recovered focus time, fewer credential incidents — which add to the case but are harder to quantify cleanly. The migration cost is small enough that for any team running two or more providers with non-trivial volume, it pays back within the first month.

The qualitative cost

The numbers above capture the time directly spent on multi-provider operational work. They do not capture the second-order costs that show up in how the team works. These are harder to quantify but matter more in practice.

Friction in the engineering loop. When even routine work requires context-switching across provider conventions, engineers ship slower. The shipping speed cost is not the literal time spent on switching; it is the cumulative effect of fragmented attention on the rest of the day. Productivity research has been clear for decades that context-switching has a residue cost that outlasts the switch itself. The engineering team that is constantly switching between provider dashboards is the same team that gets less done in a sprint than its size would suggest.

Resistance to better choices. When evaluating a new model requires setting up a new provider relationship, the threshold for "is it worth trying?" rises. Engineers stop suggesting evaluations they would otherwise have run. The result is that the team's model choices drift from optimal — not because anyone made a bad decision, but because the better decisions never got made. This is the failure mode that is hardest to see in retrospect because the alternative was never tested.

Burnout from administrative work. The work of managing multiple providers is genuinely tedious. Engineers tolerate it for a while, then start to resent it. The resentment shows up in standups, in slower responses to operational questions, in engineers proposing architectural changes whose real driver is escape from the credential-management overhead. The hidden cost shows up as morale, retention, and team velocity — and by the time those metrics are bad enough to notice, they have been bad for months.

The case to bring to your team

If the calculation above lines up with your team's reality and you want to make the case for consolidating, here is a practical framing that works in internal conversations:

Lead with the dollar figure, not the engineering complaint. "Our current multi-provider setup is costing us roughly $X in engineering time per year" lands very differently to "managing credentials is annoying." The first triggers cost-benefit analysis; the second triggers a polite acknowledgment and no action.
Show your work on the calculation. Use the table structure from this article, adapted to your team's actual hours and hourly rate. The credibility of the number depends on the methodology being transparent. "Here's what we counted, here's the rate we used, here's how it adds up" is much more defensible than a single dollar figure asserted without breakdown.
Name the secondary benefits separately. The break-even pays back in dollars terms within weeks for most teams. The secondary benefits — faster model evaluation, recovered focus time, reduced credential-incident risk — are presented as additional upside, not as the core case. This keeps the primary argument financially defensible while giving the team the qualitative case they care about.
Be honest about what doesn't change. Aggregating to a single endpoint does not eliminate compliance obligations, does not change underlying model quality, and does not solve every operational problem. Naming these limits up front is what makes the rest of the argument trustworthy. The team you're presenting to will trust your recommendation more if you have already named the trade-offs honestly.
Propose a phased migration, not a big bang. The most defensible proposal is to move one new feature or one experimental workload to the new setup first, measure the operational impact, then expand. This de-risks the change and gives you a real-data answer to "does this actually work for us?" within a month. Most teams that propose phased migrations get internal approval easily; teams that propose all-at-once migrations face more resistance even when the numbers are good.

Where this leaves you

The operational cost of multi-provider AI work is real, large, and structurally invisible. Most teams pay $35,000 to $60,000 per year for a setup they assume is free because none of the cost appears on any line item. Once you start counting it, the case for consolidation moves out of "engineering preference" territory and into "defensible financial decision" territory. The numbers are the lever; the case is just letting them speak.

The practical next step: Run the calculation for your team. Use the structure from this article, adapt the hours to your actual setup, and produce the annual figure. The exercise takes less than an hour and produces a number that decides the question. CometAPI is one route for the single-endpoint consolidation; the practical case is the same regardless of which aggregator you choose.

Multi-provider AI doesn't cost what the API bill says it costs. The real cost includes 500+ hours of engineering time per year on integration overhead — credential rotation, billing reconciliation, dashboard navigation, daily context-switching. At realistic engineering rates, that's $35K–$60K of cost no system was built to capture. Naming it in finance language is what brings it into the conversation; running the calculation for your team is what wins the argument.

Ready to integrate reliably? Head to CometAPI and API doc for seamless Claude Fable 5 access alongside other frontier models, unified billing, and enterprise-grade reliability. Sign up today and get started with generous credits for new users—your next breakthrough project awaits.

Originally published at cometapi.com

Seedance 2.5: What Developers Should Know Before Launch

Mason Reed — Mon, 21 Sep 2026 03:40:37 +0000

Current Status

Seedance 2.5 is ByteDance’s next-generation video generation model in the Seedance family. ByteDance announced it on June 23, 2026, at the Volcano Engine FORCE conference. As of June 30, 2026, it was reportedly in global enterprise beta, with a public launch targeted for early July 2026.

The main changes from Seedance 2.0 are:

Native single-segment generation up to 30 seconds
Support for up to 50 multimodal reference assets
More precise local editing and continuation
Improved control over motion, camera work, consistency, and pacing
Native audio-video synchronization

Seedance 2.5 accepts text alongside images, video clips, audio, and other reference material. The model is aimed at workflows that currently require stitching together several short generations and repairing inconsistencies in post-production.

Independent benchmarks for 2.5 are not yet available. Seedance 2.0, however, already performs strongly in evaluations such as the Artificial Analysis Video Arena, where its text-to-video-with-audio score was approximately 1,219 Elo.

What the Model Adds

Longer Native Clips

Most video generation systems produce native clips in the 5-15 second range. Seedance 2.5 extends that to 30 seconds in one continuous generation.

That matters for scenes with a setup, action, camera movement, and resolution. Keeping those elements in one pass should reduce stitching and preserve narrative rhythm. ByteDance demonstrations reportedly include multi-character interactions and spacecraft previsualization using 100k+ polygon models while maintaining structural integrity across the clip.

More Reference Material

Seedance 2.5 supports up to 50 multimodal references, compared with approximately 12 in Seedance 2.0.

References can include:

Character sheets and style guides
Images and product assets
Motion-reference video
Audio and music
3D greybox or pre-production material
Text instructions

The practical benefit is tighter control over characters, environments, lighting, branding, and object identity. This is particularly relevant to teams with established asset libraries.

Motion and Cinematic Control

The model is designed for more stable motion, physical interactions, lighting, and character consistency. Its control surface is intended to cover camera behavior such as dolly, tracking, and POV shots, along with performance and pacing.

Seedance 2.0 already emphasized “exceptional motion stability” and “director-level control” over performance, lighting, shadows, and camera movement. Version 2.5 appears to extend those capabilities to longer and more complex scenes.

Local Editing and Continuation

Local or region-based editing allows a team to change part of a frame without regenerating the entire video. High-quality continuation is intended to extend an existing clip while preserving its style and rhythm.

For e-commerce, this could mean generating a strong lifestyle video once and creating variants for different SKUs, backgrounds, languages, and promotions without rebuilding every scene.

Output Options

Seedance 2.5 is expected to support resolutions up to 4K, building on Seedance 2.0’s capabilities. It also supports multiple aspect ratios, including 16:9 and 9:16, for social, web, and broadcast-oriented outputs.

Seedance 2.5 Compared with 2.0

Seedance 2.0 already supports text, image, audio, and video inputs through a unified audio-video generation architecture. The newer model mainly addresses duration, reference capacity, editing, and production control.

Feature	Seedance 2.0	Seedance 2.5	Practical effect
Native clip length	Approximately 5-15 seconds	Up to 30 seconds in one pass	Fewer stitches and better continuity
Maximum references	Up to approximately 12 multimodal inputs	Up to 50 multimodal inputs	More control over identity, style, and branding
Editing	Basic refinement	Local or region editing with improved consistency	More targeted iteration
Resolution	Up to 1080p/4K options	Enhanced native 4K support	Sharper production output
Continuation	Limited	Higher-quality continuation with rhythmic consistency	Easier longer-form work
Prompt adherence	Strong	Approximately 20% better, as reported	Potentially fewer retries
Typical use	Short clips and basic multimodal work	Cinematic scenes, previsualization, and branded long-form content	Broader professional use

The reported improvement figures are vendor-reported. Generation speed, failure rates, and independent quality metrics still need to be validated after public release.

Release Timeline

ByteDance previewed Seedance 2.5 in late June 2026 at the Volcano Engine conference. The expected public launch window is early July 2026, following an enterprise beta and expansion through platforms such as Dreamina, CapCut, and API providers.

As of late June 2026, access remained limited. Developers should verify model availability, pricing, and exact output specifications before committing to a production workflow.

Calling the Video Endpoint

For an OpenAI-compatible video workflow, the request can look like this:

import os
import requests

response = requests.post(
    "https://api.cometapi.com/v1/videos",
    headers={"Authorization": "Bearer " + os.environ["COMETAPI_KEY"]},
    data={
        "prompt": "A slow cinematic camera push across a coastal landscape at sunrise",
        "model": "doubao-seedance-2-0",
        "seconds": "4",
        "size": "16:9",
    },
    timeout=30,
)

response.raise_for_status()
print(response.json())

A unified multi-model API such as CometAPI is useful here when the application needs one integration point for text, image, and video models, or when it needs to switch between Seedance versions during evaluation and rollout.

For multimodal references, add an input_reference file for image-guided generation. Advanced multi-reference requests can repeat the same multipart fields in upload order. The uploaded files can then be referenced sequentially as [Image 1], [Image 2], and [Image 3], with a specific role assigned to each image in the prompt.

Video generation is asynchronous. Submit the task, retain its ID, and poll the video status endpoint:

GET /v1/videos/

The Seedance query endpoint returns the current task status, progress, and the signed video URL after completion. The documented polling flow works for Seedance 1.0 Pro, 1.5 Pro, and 2.0. Node.js and cURL clients use the same request shape with the appropriate base URL and credentials.

Practical Workloads

Social Advertising

A 30-second clip can contain the hook, problem, product reveal, proof point, lifestyle shot, and call to action in one generation. Teams can then create variants by audience, region, aspect ratio, product, or visual style.

Product and E-Commerce Video

Reference-driven generation can turn catalog images into lifestyle scenes for seasonal campaigns, marketplace listings, product pages, and localized promotions. Human review remains necessary, but the approach can reduce the time needed for initial concepts and variant production.

Storyboards and Previsualization

Film, animation, and agency teams can explore camera movement, blocking, lighting, pacing, and visual style before committing to a shoot or full production. A 30-second draft can also support pitches and client approvals.

Training and Education

Short generated videos fit onboarding, safety explanations, product walkthroughs, classroom examples, and internal training. Multimodal references make it possible to match a company’s equipment, environment, or product rather than relying on generic stock footage.

Creative Localization

Reference consistency and local editing are important for producing variants across languages, climates, packaging versions, and audience segments. The goal is to modify the relevant creative elements without regenerating the entire campaign from scratch.

Production Notes

Build an Evaluation Set

I would start with evaluation rather than direct customer-facing automation. Include product ads, character scenes, motion-heavy prompts, brand-safe requests, rejected prompts, and edge cases.

Score at least:

Prompt adherence
Identity and reference consistency
Motion quality
Visual artifacts
Audio quality
Moderation behavior
Latency
Cost
Failure and retry rates

Keep Generation Asynchronous

A 30-second video can take substantially longer than a chat completion or image request. Use a queue, persist task IDs, poll status, and notify users when the signed output is ready. This avoids request timeouts and makes retries explicit.

Version Everything

Store the prompt, model ID, parameters, reference IDs, output URL, reviewer score, and final decision. Prompt and output versioning makes comparisons between Seedance 2.5, Seedance 2.0, Veo, Kling, Runway, and other models reproducible.

Retain Human Review

Commercial video introduces brand, legal, likeness, and copyright concerns. Human review is appropriate for public advertising, realistic people, influencer-like content, regulated industries, and outputs using third-party references.

Avoid requests involving copyrighted characters, real people without permission, or misleading depictions.

Design Fallbacks

Do not assume one model should serve every workload. Short drafts may be better handled by Seedance 2.0 or a faster video model, while Seedance 2.5 can be reserved for final, high-value generations. Availability, latency, and cost should all be part of routing decisions.

Frequently Asked Questions

Is Seedance 2.5 available?

As of June 30, 2026, it was reportedly in global enterprise beta, with public availability expected in early July 2026. Developers should check the live model catalog before using it in production.

How long can it generate?

The headline capability is native video generation up to 30 seconds. Seedance 2.0’s documented generation range is 4-15 seconds, so the newer model substantially increases single-pass duration.

What is the main difference from Seedance 2.0?

Seedance 2.5 adds native 30-second generation, up to 50 multimodal references, and improved local editing control. Seedance 2.0 already provides text, image, audio, and video inputs, native audio-video generation, and strong motion stability.

What is it best suited for?

The strongest target workloads are 30-second social ads, product videos, cinematic storyboards, previsualization, brand-consistent creative variants, e-commerce demonstrations, training clips, and other reference-heavy generation tasks.

What should developers verify before production?

Confirm the live model ID, access status, pricing, exact resolution and duration limits, output formats, generation latency, failure behavior, moderation rules, and signed URL lifetime. These details may change as the model moves from beta to public release.

Originally published at cometapi.com

Calling Claude Through a Gateway: SDK Choices and Production Trade-offs

Mason Reed — Mon, 21 Sep 2026 02:39:29 +0000

I reach for a unified gateway when an application needs several model providers but does not need several separate account, billing, and SDK integrations. It is also a way to call Claude without maintaining a direct Anthropic developer account: the application authenticates with the gateway, which routes requests upstream.

CometAPI is one example, advertising Claude, GPT, and 500+ other generative AI models behind a single key and an OpenAI-compatible endpoint. Its mid-2026 model listings include Claude Opus 4.8 and Claude Sonnet 5. Those are catalog claims, so I would confirm current availability before choosing a production model.

The important decision is not just which provider handles billing. It is whether the application needs a portable chat interface or Claude-specific request semantics.

Choose the API Contract First

The gateway exposes two integration paths:

Concern	OpenAI-compatible API	Native Anthropic Messages API
Endpoint	`/v1/chat/completions`	`/v1/messages`
SDK base URL	`https://api.cometapi.com/v1`	`https://api.cometapi.com`
Model scope	Multiple providers, including GPT, Claude, and Gemini	Claude
Authentication	Bearer	`x-api-key` or Bearer
Response structure	`choices` and `message`	Content blocks
Claude-specific controls	Not exposed through this compatibility path	Thinking, caching, effort, server-side tools

I would use chat completions for shared application code across providers. I would choose Messages when extended thinking, prompt caching, or server-side tools are part of the actual workflow. A common interface is useful, but it is not a promise that every model has identical capabilities.

Reuse an OpenAI Client

Install the SDK with pip install openai. Generate a gateway key, then change the client’s base_url and api_key. This request retains the source example’s model, temperature, and output limit:

from openai import OpenAI

client = OpenAI(base_url="https://api.cometapi.com/v1", api_key="your_gateway_key")
response = client.chat.completions.create(
    model="claude-opus-4.8",
    messages=[{"role": "user", "content": "What are the primary structural benefits of a unified API gateway?"}],
    temperature=0.7, max_tokens=1024,
)
print(response.choices[0].message.content)

For streaming, the gateway translates Claude’s native server-sent events into OpenAI-compatible chunks. Using the same client:

stream = client.chat.completions.create(
    model="claude-opus-4.8",
    messages=[{"role": "user", "content": "Explain the concept of latency overhead in unified APIs."}],
    temperature=0.7, max_tokens=1024, stream=True,
)
for chunk in stream:
    if chunk.choices:
        content = chunk.choices[0].delta.content
        if content:
            print(content, end="", flush=True)

Changing model lets this integration address another supported model without replacing the client or streaming loop. I would still test parameter support, tool behavior, structured output, and error handling for each target. Request compatibility reduces integration work; it does not eliminate model-specific validation.

Keep Claude-Specific Features on the Messages Path

The native route uses the official Anthropic SDK, but the key comes from the gateway. Set COMETAPI_KEY in the environment before running this example. Notice that the base URL does not include /v1:

import os
import anthropic

client = anthropic.Anthropic(
    base_url="https://api.cometapi.com", api_key=os.environ["COMETAPI_KEY"],
)
message = client.messages.create(
    model="claude-sonnet-4-6", max_tokens=1024,
    system="You are a helpful assistant.",
    messages=[{"role": "user", "content": "Hello, world"}],
)
print(message.content[0].text)

The SDK sends x-api-key by default; the endpoint also accepts Authorization: Bearer. The documented Claude-specific controls include thinking with a minimum budget_tokens of 1,024, cache_control on content blocks, output_config.effort, and server-side web_fetch and web_search tools. Check support against the selected model rather than assuming every Claude version accepts every control. The native example uses claude-sonnet-4-6, not the Sonnet 5 model mentioned in the catalog.

What I Would Verify Before Shipping

Latency and Compatibility

Every gateway introduces another network hop plus authentication, routing, and potentially schema translation. The source reports typical overhead below 400 ms; I would treat that as a claim to benchmark, not a latency guarantee. Background summarization can tolerate a different budget from real-time voice or tightly timed agent workflows. Streaming does not remove the need to measure initial response latency.

System prompts, temperature, structured JSON output, and tool/function calling are described as supported through the compatibility layer. Newly released or proprietary features may arrive later. For a workflow that depends on a particular feature, I would check the compatibility documentation and test the exact request. The native endpoint avoids some translation constraints, but its availability still needs verification.

Data Handling and Access

The gateway describes encrypted transit, including TLS 1.3, minimized persistent logging, and enterprise zero data retention configurations. “Minimized logging” is not the same commitment as ZDR. I would review retention, zero-data-training policies, logging configuration, and contractual scope before sending sensitive inputs.

Inference still happens at the upstream provider. Both the gateway’s handling and the model host’s data processing agreements matter. Likewise, using a gateway does not automatically remove regional compliance obligations, payment restrictions, or upstream access rules. A single account may simplify access, but it is not a universal compliance exemption.

Quotas, Cost, and Governance

Consolidated billing is the clearest operational benefit: fewer prepaid balances, invoices, credentials, and usage dashboards to maintain. Gateway quotas can simplify capacity management, but I would verify actual limits and throttling behavior rather than assume there is no upstream constraint or production approval process.

The source advertises pay-as-you-go pricing with no monthly fee, rates 20–40% below official pricing, and 1 million free signup tokens. These are commercial terms to confirm during evaluation, not architectural guarantees. Compare the price of the actual models and features the workload uses.

A shared interface also makes task-based routing easier. I would reserve a flagship model such as Claude Opus 4.8 for complex reasoning or long-context analysis, then evaluate cheaper models for classification, extraction, and formatting. Switching a model identifier is easy; proving acceptable output quality is the work.

The documented dashboard supports usage monitoring, project spending limits, access-token management, and budgets assigned to individual API keys. Those controls are worth testing: centralized billing only helps governance if an experimental project cannot consume the organization’s entire allocation.

My Decision Rule

I would choose a gateway when multi-model routing, A/B testing, consolidated procurement, and reduced SDK maintenance justify another dependency in the request path. I would use the OpenAI-compatible endpoint for portable chat workflows and the native Messages endpoint for Claude-specific behavior.

Before rollout, I would validate model availability, feature support, latency, quotas, current pricing, and both layers of data handling. Avoiding a direct Anthropic account simplifies administration. It does not remove the engineering responsibility to understand where requests go and what contract the application relies on.

Originally published at cometapi.com

GPT-6 Astra Access: Verify the Route, Then Make One Small Call

Mason Reed — Mon, 21 Sep 2026 01:53:33 +0000

I treat API access as three separate checks: the gateway lists the model, the credential works, and an authenticated request completes. Creating a key only covers part of that.

For a unified multi-model API such as CometAPI, the credential must belong to the gateway receiving the request. An OpenAI SDK client can target that gateway, but it still needs the gateway’s key and base URL.

Here’s the sequence I’d use to verify gpt-6-astra access before wiring it into an application.

Check the model catalog first

The source guide reported gpt-6-astra as available, with upcoming: false and support for both /v1/responses and /v1/chat/completions. Treat that as a dated observation: check the live catalog before integration.

The public catalog endpoint requires no Authorization header:

curl -fsSL https://api.cometapi.com/api/models \
  | jq '.data[] | select(.id == "gpt-6-astra") | {
      id,
      provider,
      upcoming,
      endpoints
    }'

Look for the exact ID, upcoming set to false, and the route you intend to use in endpoints. That establishes public routing availability; it does not validate your account or key.

If the command prints nothing, check the spelling and the live model page. Don’t substitute a display name, prepend a provider name, or borrow an alias from another gateway.

I’d start with /v1/responses for the reasoning workflow described here. Use /v1/chat/completions when the application specifically needs the messages-based interface.

Create a credential with a limited quota

Create an account, sign in, and open the API Keys page. Select Create API Key, name it something recognizable such as astra-dev, choose an appropriate quota, and copy the value.

You also need sufficient account credit or quota and a server-side environment for storing the credential. For a local Bash session:

read -rsp "Gateway API key: " COMETAPI_KEY
printf '\n'
export COMETAPI_KEY

Keep development, staging, and production keys separate. Explicit quotas limit the damage from accidental loops or leaked credentials, while descriptive names make rotation easier.

Store deployed credentials in a secrets manager or server-side environment variable. Keep them out of browser JavaScript, mobile bundles, repositories, screenshots, and support tickets. Store any direct OpenAI credentials separately so configuration changes cannot silently mix providers.

Make the smallest useful request

My first request would contain no tools, files, streaming, or long context. A small payload makes authentication and routing failures easier to isolate.

Send the gateway key to the gateway endpoint:

curl --fail-with-body \
  https://api.cometapi.com/v1/responses \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "input": "Reply with exactly: GPT-6 Astra access confirmed.",
    "reasoning": {"effort": "low"},
    "max_output_tokens": 40
  }'

The target is HTTP 200 with a response object containing an id, a completed status, the expected model, output content, and usage data. Keep the response ID during testing; it helps investigate routing or platform problems.

An HTML page or redirect does not establish API access. Check the hostname and path before changing the payload.

Use the same configuration in Python

The OpenAI Python SDK can make the same request with an explicit api_key, base_url, and model selection. A separate gateway SDK is unnecessary.

import os
from openai import OpenAI

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

response = client.responses.create(
    model="gpt-6-astra",
    input="Reply with exactly: GPT-6 Astra access confirmed.",
    reasoning={"effort": "low"},
    max_output_tokens=40,
)

print(response.id)
print(response.status)
print(response.output_text)

Use https://api.cometapi.com/v1 as the SDK base URL and https://api.cometapi.com/v1/responses for the direct request. Neither URL has a trailing period. Don’t substitute api.openai.com while retaining the gateway credential.

Once the minimal call succeeds, add application instructions and features individually.

Decide what counts as a successful access test

I’d keep four checks in the integration notes:

Check	What it establishes
Catalog returns `gpt-6-astra`	The public catalog recognizes the model and lists its routes.
Authenticated endpoint returns JSON	The request reaches an API endpoint rather than a login page or redirect.
Response completes with the expected model	The key, account, route, payload, and model routing worked together for that request.
Usage appears in the dashboard	The request is recorded against the intended account.

A successful catalog lookup cannot prove private access. Likewise, a key’s existence cannot guarantee sufficient quota, current availability, a valid payload, or acceptance under rate limits.

Check usage or billing records after the first call. This also gives you a starting point for cost monitoring.

Diagnose failures before retrying

Authentication and access: 401 or 403

For 401 Unauthorized, check for a missing, malformed, or expired key and verify the destination host. The header should be exactly:

Authorization: Bearer $COMETAPI_KEY

Reload the environment variable or rotate the credential if needed. Repeating the same invalid credential will not help.

For 403 Forbidden, return to the minimal payload, remove optional fields, and check account status, quota, and model access. Treat it as an access or request problem before assuming a temporary outage.

Routing: HTML, redirects, or model-not-found errors

Recheck the base URL and endpoint path. During debugging, avoid silently following redirects on the authenticated request: a wrong path can otherwise appear to be a successful connection.

For a model-not-found response, query the catalog again and compare the exact gpt-6-astra identifier.

Rate limits and server failures

For 429 Too Many Requests, inspect the error body and account limits. Reduce burst concurrency and use exponential backoff with jitter for rate-limit retries. Monitor usage by model and route.

For 500, 503, 504, or 524, retain any request or response ID and use bounded backoff for temporary platform or timeout failures. Inspect the body first: if it reports invalid_request, fix the payload before retrying.

Put production controls around the working call

After access is confirmed, issue a production-specific key with the smallest practical quota. Store it in a secrets manager, restrict who can view or rotate it, and document rotation.

Keep model calls on your server. Browser and mobile clients should call your authenticated backend, where you can enforce user permissions, rate limits, and spending controls.

Log the route, model ID, HTTP status, latency, response ID, and token usage. Redact credentials and sensitive prompt data. Track development and production separately so test traffic does not obscure production failures.

For payload changes, consult the Responses API documentation. The source also links a first-party model reference; check current documentation and the live catalog before relying on a capability or endpoint.

Originally published at cometapi.com

GPT-5.6 API Costs: What I’d Budget Beyond the Token Price

Mason Reed — Fri, 18 Sep 2026 17:10:24 +0000

Start with the route, not the family name

The first thing I’d check in a GPT-5.6 integration is the model ID. According to OpenAI’s model guidance, gpt-5.6 routes to gpt-5.6-sol. It does not automatically select the cheapest tier that can handle a request.

If I want Terra or Luna pricing, I’d use gpt-5.6-terra or gpt-5.6-luna explicitly.

The July 30, 2026 pricing update reduced Terra rates by 20% and Luna rates by 80%, while leaving Sol unchanged. Here are the updated Standard rates for requests with at most 272,000 input tokens.

All token prices below are USD per 1 million tokens.

Model	Input	Cached input	Cache write	Output
`gpt-5.6-sol`	$5.00	$0.50	$6.25	$30.00
`gpt-5.6-terra`	$2.00	$0.20	$2.50	$12.00
`gpt-5.6-luna`	$0.20	$0.02	$0.25	$1.20

Source: OpenAI API pricing.

OpenAI positions Sol as the flagship, Terra as the balanced option, and Luna as the low-cost tier for high-volume work. I’d treat those descriptions as evaluation starting points, not routing rules.

The number that matters most for ordinary short-context traffic: output costs 6× as much as uncached input across all three tiers. Trimming unnecessary response text can matter more than shaving a few tokens off a system prompt.

Put the rates through an actual workload

A rate table is useful, but I prefer turning it into request costs immediately. The examples here use the updated July rates consistently, without caching, tools, retries, or regional adjustments.

A 1,000-input, 500-output request

For Sol:

Input:  1,000 / 1,000,000 × $5  = $0.005
Output:   500 / 1,000,000 × $30 = $0.015
Total:                           $0.020

Applying the same request shape to each model:

Model	Input cost	Output cost	Total per request
Sol	$0.005	$0.015	$0.020
Terra	$0.002	$0.006	$0.008
Luna	$0.0002	$0.0006	$0.0008

Output accounts for 75% of the token bill even though the request contains twice as many input tokens as output tokens.

For chat, code generation, and agents, I’d look for unnecessary verbosity before spending much time optimizing a small prompt.

One million requests per month

Now change the workload to:

1 million requests per month
2,000 input tokens per request
500 output tokens per request

That produces 2 billion input tokens and 500 million output tokens monthly.

Model	Monthly input	Monthly output	Monthly total
Sol	$10,000	$15,000	$25,000
Terra	$4,000	$6,000	$10,000
Luna	$400	$600	$1,000

For this workload, the price cuts move Terra from $12,500 to $10,000 and Luna from $5,000 to $1,000.

Those differences justify routing experiments. They do not prove that Luna is the cheapest way to complete the work. More retries, failed tool calls, or manual review can consume the apparent savings.

My preferred metric is:

Cost per successful task = total workflow cost / successful tasks

I’d track human review alongside that metric, rather than pretending it disappears because it is absent from the API invoice.

Treat 272K input tokens as a billing boundary

GPT-5.6 supports a 1.05M-token context window, but context capacity and short-context pricing are different limits.

When input exceeds 272,000 tokens, the higher rates apply to the entire request, not just the excess tokens:

Input: 2×
Cached input: 2×
Cache writes: 2×
Output: 1.5×

Model	Long input	Long cached input	Long cache write	Long output
Sol	$10.00	$1.00	$12.50	$45.00
Terra	$4.00	$0.40	$5.00	$18.00
Luna	$0.40	$0.04	$0.50	$1.80

This is a pricing cliff, not a gradual overage charge. It also means the 6× output-to-input ratio applies to short-context Standard pricing; long-context pricing has a different ratio because the multipliers differ.

Near the boundary, I’d inspect:

Duplicate retrieval chunks
Stale conversation history
Repository files unrelated to the task
Tool output that could be reduced before the next model call

That cleanup can do more than reduce token count: it can keep the whole request in the lower pricing band. OpenAI’s cost optimization guide covers additional approaches.

Choose a processing tier separately from the model

Model selection is only one pricing decision. Eligible GPT-5.6 text workloads also have different processing options.

These are short-context input/output rates per 1 million tokens:

Processing option	Sol	Terra	Luna	Where I’d consider it
Standard	$5 / $30	$2 / $12	$0.20 / $1.20	Normal synchronous traffic
Batch	$2.50 / $15	$1 / $6	$0.10 / $0.60	Offline asynchronous jobs
Flex	$2.50 / $15	$1 / $6	$0.10 / $0.60	Work that tolerates slower processing
Fast mode	$10 / $60	$4 / $24	$0.40 / $2.40	Latency-sensitive traffic

The listed Batch and Flex rates are 50% below Standard. I’d check their operational constraints before moving any production workload, rather than treating them as interchangeable discounts.

Priority Processing was renamed Fast mode on July 30, 2026. Existing requests using service_tier: "priority" remain compatible.

For Sol, Fast mode offers up to 2.5× faster processing at 2× the Standard token price, without changing model intelligence. That is a latency trade-off, not a quality upgrade. I’d pay for it only where the user-facing benefit justifies the premium.

Cache reuse, not merely long prompts

Cache writes cost 1.25× normal input, while matching cached reads use the discounted cached-input rate.

For a reusable 100,000-token prefix on short-context Sol:

Operation	Prefix input cost
One uncached use	$0.50
One cache write	$0.625, approximately $0.63
One matching cached read	$0.05

Two uncached uses cost $1.00. A cache write followed by one matching read costs $0.675, saving $0.325.

That comparison covers only the reusable prefix. It excludes output, other uncached input, tools, and retries.

The practical distinction is between a long prefix and a long, stable, reused prefix. A write that never gets reused costs more than ordinary input processing.

I’d measure actual cache hits and read the prompt caching documentation for matching requirements, explicit breakpoints, and TTL behavior before building savings into a forecast.

Budget for tokens you don’t see and calls outside the model

Reasoning is billed output

Reasoning tokens are charged as output tokens even when they do not appear in the visible response. A concise answer does not necessarily imply a small output-token bill.

Where supported, reasoning.mode = "pro" is a setting I’d benchmark rather than enable by default. OpenAI does not list a separate fixed Pro surcharge; its cost impact comes from resulting token usage.

The comparison should include task success, total output tokens, latency, and retries—not just whether one response looks better.

Search has its own bill

Standard web search is listed at $10 per 1,000 calls, plus search-content tokens billed at the selected model rate.

At that price, two searches can cost more than the model tokens for a small Luna request.

There is also a separate web search preview rate for non-reasoning models: $25 per 1,000 calls, with search-content tokens free. I would not apply one search rate across every tool and endpoint. Check the exact combination on the pricing page.

Residency can add an uplift

Eligible regional processing or data-residency endpoints for models released on or after March 5, 2026 carry a 10% uplift.

If residency is a requirement, that belongs in the initial estimate—not in an explanation for why the first invoice exceeded it.

Keep the older models in the comparison

A new family does not make previous routes irrelevant. These are the listed Standard short-context rates for several other OpenAI text models:

Model	Input	Cached input	Output
`gpt-5.5`	$5.00	$0.50	$30.00
`gpt-5.4`	$2.50	$0.25	$15.00
`gpt-5.4-mini`	$0.75	$0.075	$4.50
`gpt-5.4-nano`	$0.20	$0.02	$1.25

Luna now matches GPT-5.4 nano’s $0.20 input rate, with slightly cheaper output: $1.20 versus $1.25.

That is a useful pricing comparison, not evidence that the models behave identically. I’d keep existing routes in the evaluation set until the replacement earns its place.

Also, ChatGPT subscriptions and API billing are separate products. “ChatGPT API pricing” does not identify a rate; the model and usage type do.

My production cost checklist

For a basic uncached request, the arithmetic is:

Token cost =
    (input tokens / 1,000,000 × input rate)
  + (output tokens / 1,000,000 × output rate)

For production, I’d expand that into a workflow estimate covering uncached input, cached reads, cache writes, output and reasoning tokens, tool fees, applicable processing-tier rates, regional uplift, retries, and fallbacks.

Then I’d run the same representative tasks through candidate routes:

Use explicit model IDs. Avoid paying Sol rates accidentally through gpt-5.6.
Start with the cheapest plausible model. Promote difficult tasks based on measured results.
Record billed output, not just visible text. Include reasoning usage.
Monitor the 272K boundary. Aggregate averages can hide expensive individual requests.
Test Batch or Flex for non-urgent work. Verify operational fit.
Measure cache reuse, tool calls, and retries. Do not assume their costs cancel out.
Compare cost per successful task against latency and reliability.

For cross-provider evaluations, a unified API such as CometAPI can be useful for running the same workload through multiple OpenAI-compatible routes.

The cheapest token rate is a starting hypothesis. The route I’d ship is the one that meets the quality and latency requirements at the lowest measured workflow cost.

Originally published at cometapi.com

DEV Community: Mason Reed

FLUX 3: What the Video API Gives You, What It Costs, Where It Still Fails

What has shipped

Specs

Pricing, and a working request

Under the hood: Self-Flow

Why video eats the compute

Capability notes

Benchmarks: vendor versus third party

Against Seedance 2.5, MiniMax H3 and Wan 3.0

Where it holds up, and where it does not

The part that is not video

FAQ

My take

Kling VIDEO 3.0 Omni is a reference engine, not a quality upgrade

What Omni supports

Pick by reference layout, not by name

The benchmarks do not favor Omni

Build one reference-led shot first

Prepare a small asset set

Create and name elements

Generate a single shot

Add the presenter and native audio

Go multi-shot only after that

Video references: identity vs editing

The API path

Submit a task

Retrieve the result

Cost

Budget against accepted clips

Troubleshooting

FAQ

Grok 4.7 vs Claude Fable 5.1: reading the benchmarks, doing the token math, and wiring a router

The spec sheet, without the positioning copy

The benchmark table splits down the middle

Coding

Knowledge work isn't one capability

The token math is where this actually gets decided

Reasoning controls aren't comparable across vendors

Route instead of choosing

Benchmark hygiene before you trust any of this

Picking

Changing Gemini CLI Directories: Workspace, Project Settings, and Global Config

Start with the directory you actually want to change

Add another repository without moving configuration

Don’t rely on shell-mode cd to switch the session

Keep repository settings with the repository

Relocate global configuration only when necessary

Check environment-variable support for your release

Use a symlink or junction when native relocation is unavailable

Treat home-directory changes as an isolated-runtime option

Diagnose failures by scope

Keep API routing separate from directory configuration

Building an AI Companion: Persona, Memory, Tools, and the Tests That Matter

Choose the relationship before the stack

Decide how much infrastructure you want to own

Write a persona you can evaluate

Make memory a product feature with user controls

Specify boundaries alongside the personality

Ground answers before adding actions

Add voice and visuals once the text behavior holds up

Ship against a conversation test suite

Top 6 OpenClaw Skills you can't afford to miss in 2026

What Is OpenClaw and Why Skills Matter in 2026

Installation Basics (General for Most Skills):

1. GOG (Google Workspace Integration) — The Productivity Powerhouse

How to install:

Key Functions:

2. Agent Browser / Web Automation Skill — Autonomous Internet Agent

How to install:

Key Functions:

3. Self-Improving Agent / Capability Evolver — The Meta-Skill

How to install:

Key Functions:

4. GitHub Integration — Developer and Team Workflow Accelerator

How to install:

Key Functions:

5. Summarize Skill — Knowledge Distiller

How to install:

Key Functions:

Don’t rely on shell-mode `cd` to switch the session

Q: Why does Runway return `task_not_exist` on the first poll?

Q: Why does Kling use `"succeed"` instead of `"succeeded"`?