DEV Community: Dylan Foster

How I’d Route Work Between GLM-5.3 Flash and GLM-5.3

Dylan Foster — Thu, 24 Sep 2026 08:45:55 +0000

I’d start most workloads on glm-5.3-flash and reserve glm-5.3 for difficult text tasks where better reasoning can pay for the extra tokens. Flash adds native visual input, matches the flagship’s 1M-token context window, and costs substantially less. The flagship has stronger reported results on demanding repository work, tool-assisted reasoning, and cybersecurity.

The naming is less useful than the workload split. Flash is a 320B-parameter model, and independent API measurements show the flagship generating output faster. Neither “small” nor “faster” is a safe assumption.

My decision would come down to three things: whether the task needs vision, how often the output passes validation, and what each accepted result costs.

Start with the input and acceptance criteria

For screenshots, rendered interfaces, charts, document layouts, and browser state, I’d choose Flash. It accepts native visual input; the flagship accepts text only.

For routine repository maintenance, debugging, refactoring, and test generation, I’d also evaluate Flash first. The flagship’s coding advantage matters most when the task is difficult enough for that advantage to change the outcome.

Workload	My starting model	Reason
UI implementation and visual debugging	Flash	Can inspect screenshots and rendered results
Documents, charts, and Office workflows	Flash	Can use visual structure and layout
High-volume automation	Flash	Lower token cost and strong tool-use results
Routine repository changes	Flash	Measure acceptance before paying for more capacity
Difficult repository engineering	GLM-5.3	Higher reported coding scores
Long-horizon research with tools	GLM-5.3	Stronger difficult-reasoning results
Authorized vulnerability discovery	GLM-5.3	Dedicated cybersecurity evaluations
Mixed workloads	Both	Default to Flash; escalate selected text tasks

Both support function calling, streaming tool calls, always-on reasoning, and open-weight deployment. Context length alone won’t settle the choice: each supports 1M input context and up to 128K output tokens.

What the two checkpoints actually contain

These models followed different development paths. Z.ai describes Flash as the first native multimodal model in the GLM-5 series, built from a newly trained 30T-token multimodal base. GLM-5.3 retains the GLM-5.2 base, with its gains coming from scaled post-training.

Property	GLM-5.3 Flash	GLM-5.3
Model ID	`glm-5.3-flash`	`glm-5.3`
Architecture	Native multimodal MoE	Text MoE
Total parameters	320B	744B
Active parameters	18B	40B
Base	New 30T-token multimodal pre-training	GLM-5.2 base
Input	Text and visual inputs	Text
Output	Text	Text
Context / maximum output	1M / 128K tokens	1M / 128K tokens
Reasoning effort	`low`, `high`, `max`	`low`, `high`, `max`
Reasoning disabled mode	No; always enabled	No; always enabled

Flash activates 55% fewer parameters per token. Its 45-layer architecture combines sparse attention, linear attention, mHC, and MTP. The flagship activates more than twice as many parameters, but I’d use task evaluations—not parameter count—to decide whether that capacity helps.

Flash’s visual inputs include images and supported video/file workflows. That makes a practical difference in an agent loop: the model can inspect a rendered page or interface state and use that evidence when choosing its next tool call.

Long context has different infrastructure costs

Flash alternates linear-attention and sparse-attention blocks, with mHC around attention and MoE components. Its IndexPool mechanism compresses four indexer key vectors into one.

At a 1M-token sequence length, Z.ai reports:

3.01× lower per-layer attention compute than the flagship.
A 4.44× smaller per-layer KV cache.

Those are architecture measurements. I wouldn’t translate them into an API latency promise: hardware, quantization, batching, serving software, provider load, and reasoning length all affect the actual request.

Both models expose low, high, and max reasoning effort. Z.ai recommends max for difficult coding and benchmark reproduction. I’d keep that setting fixed when comparing models, then evaluate effort levels separately.

The benchmark split supports selective escalation

The vendor results favor the flagship on difficult engineering and reasoning, but Flash wins some tool-use and automation comparisons.

These are the closest matched values from the Flash documentation and flagship evaluation. Matching benchmark names does not guarantee identical harnesses, tool configurations, or context management.

Benchmark	Flash	GLM-5.3
Terminal-Bench 2.1	84.3	88.2
DeepSWE v1.1	63.4	66.9
NL2Repo	56.3	58.0
Toolathlon Verified	78.4	73.0
AutomationBench	48.8	48.2
Agents’ Last Exam	26.3	28.5
HLE with tools	55.3	62.5
GDPval-AA v2	1773 Elo	1769 Elo

I’d treat the small AutomationBench and GDPval-AA v2 differences as near ties. Toolathlon Verified gives Flash a clearer lead; HLE with tools gives the flagship a substantial one.

Coding: the flagship earns an evaluation slot

GLM-5.3 leads by 3.5 points on DeepSWE and 1.7 points on NL2Repo.

There is another useful comparison in Z.ai Code Bench v1.0: with both models evaluated through Claude Code 2.1.207, the flagship scores 34.5% at max effort against Flash’s 29.0%. That is a 5.5-point difference.

Those results justify testing the flagship on difficult repository tasks. They don’t establish that every maintenance ticket needs it. My escalation signal would be failed validation or unusually demanding engineering work, with the final decision based on acceptance rate.

Security: stronger evidence for the flagship

Z.ai reports GLM-5.3 scores of 84.5 on CyberGym and 54.4 on ExploitBench. Under normalized two-hour and six-hour budgets, it completed 105 and 130 ExploitGym tasks, respectively.

Flash does not have an equivalent matched public cybersecurity suite in the cited material. That makes the flagship the better-supported starting point for authorized vulnerability discovery and demanding security analysis.

I’d keep human approval, isolated tooling, audit logs, expert review, and disclosure controls in that workflow. A benchmark score doesn’t replace those controls.

“Flash” doesn’t tell you which endpoint is faster

The Artificial Analysis comparison separates startup latency from output throughput:

Measurement	Flash	GLM-5.3 at max effort
Intelligence Index	57	60
Output speed	50.2 tokens/s	76.6 tokens/s
Time to first token	1.49 s	1.61 s
Context window	1M	1M
Blended price per 1M tokens	$0.10	$0.90

Flash starts slightly sooner; the tested flagship endpoint emits tokens faster once generation begins.

I’d treat these as snapshots of the tested APIs. They don’t establish a permanent speed ranking across providers, and the blended prices are a different comparison from Z.ai’s standard input/output list rates.

For an agent, I’d also measure the full trajectory. Time to first token and output throughput each describe only part of a run that may include reasoning, tool execution, retries, and validation.

Token economics leave room for retries and escalation

Z.ai’s standard pricing puts Flash at $0.15 per million input tokens and $0.50 per million output tokens. The flagship lists at $1.40 and $4.40.

Z.ai rate	Flash	GLM-5.3
Standard input	$0.15	$1.40
Standard cached input	$0.03	$0.26
Standard output	$0.50	$4.40
Promotional input	$0.075	$1.40
Promotional cached input	$0.015	$0.26
Promotional output	$0.25	$4.40

All prices are USD per 1M tokens. Promotions can change.

For a unified multi-model API, CometAPI exposes both model IDs through the same OpenAI-compatible endpoint; the quoted route prices are $0.06 input / $0.20 output for Flash and $1.12 input / $3.528 output for GLM-5.3, with cached pricing requiring a live-route check.

At those route rates, a workload consuming 100M input tokens and 20M output tokens comes out as follows:

Component	Flash	GLM-5.3
Input	100 × $0.06 = $6.00	100 × $1.12 = $112.00
Output	20 × $0.20 = $4.00	20 × $3.528 = $70.56
Total	$10.00	$182.56

That is about a 94.5% reduction for Flash before cache effects or tool charges.

I’d use that difference to fund a measured escalation policy. A cheap request that repeatedly fails can still be expensive, while an expensive request that resolves a difficult task immediately may be worthwhile. Cost per accepted result is the metric I’d optimize.

A minimal comparison through one endpoint

This snippet runs the same text prompt against both model IDs:

from openai import OpenAI
import os

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

models = ["glm-5.3-flash", "glm-5.3"]

for model in models:
    response = client.chat.completions.create(
        model=model,
        messages=[
            {
                "role": "user",
                "content": "Review this migration plan and identify its three highest-risk assumptions.",
            }
        ],
    )
    print(model, response.choices[0].message.content)

This is a connectivity smoke test. The prompt doesn’t include an actual migration plan, and the request doesn’t explicitly set reasoning effort or output limits.

For a useful evaluation, I’d supply real task material and hold the prompt, reasoning effort, tool definitions, maximum output, and acceptance rubric constant. I’d record acceptance, token use, latency, tool failures, and human intervention for each run.

Visual evaluation needs its own setup. Check the live Flash route documentation for the supported image-content schema. A flagship comparison needs a text-only equivalent, which also means the inputs are no longer identical.

Open weights still mean substantial deployment work

Both models have downloadable FP8 and BF16 checkpoints. Their weight licenses differ:

Flash weights use the MIT License.
GLM-5.3 weights use the separate GLM-5.3 License.
The supporting GLM-5 repository code uses Apache-2.0.

The flagship license requires security review before commercial use by Model-as-a-Service operators whose aggregate revenue exceeds US$10 billion over any consecutive 12 months. I’d read the checkpoint’s license directly rather than infer its terms from the supporting code repository.

Flash has the smaller total and active footprint, but a 320B checkpoint is still a substantial deployment. Multimodal components, KV cache, and operation at 1M context add to the infrastructure requirements. Neither model becomes inexpensive to host simply because its weights are downloadable.

I’d consider self-hosting when data control, custom serving, or sustained utilization justifies operating that infrastructure.

The routing policy I’d deploy first

My initial policy would stay simple:

Send visual tasks, routine coding, and high-volume automation to Flash.
Validate the result using the task’s acceptance criteria.
Escalate difficult or failed text tasks to GLM-5.3.
Route authorized security work through the flagship with the required approval and isolation controls.
Adjust routing using measured cost per accepted result.

The outstanding uncertainty is how these results transfer to a particular workload. Several scores are vendor-reported; evaluation tools, prompts, inference settings, and context management can change the outcome. Pricing, availability, rate limits, and route capabilities also need a live check before deployment.

I’d make Flash the default because its vision support and token economics cover a broad range of work. I’d keep GLM-5.3 available because its stronger difficult-coding and reasoning results give a concrete reason to escalate when validation says the default route isn’t enough.

Originally published at cometapi.com

How Much Does Cursor Composer Cost?

Dylan Foster — Tue, 22 Sep 2026 05:24:17 +0000

Cursor Composer is a new, frontier-grade coding model released as part of Cursor 2.0 that delivers much faster, agentic code-generation for complex, multi-file workflows. Access to Composer is governed by Cursor’s existing tiered subscriptions plus token-based usage when you exhaust plan allowances or use Cursor’s “Auto” routing — meaning costs are a mix of a fixed subscription fee and metered token charges. Below you’ll find a full, practical breakdown (features, advantages, pricing mechanics, worked examples and competitor comparisons) so you can estimate real-world costs and decide whether Composer is worth it for your team.

What is Cursor Composer?

Composer is Cursor’s new “frontier model” introduced as part of Cursor 2.0. It was built and tuned specifically for software engineering workflows and agentic (multi-step) coding tasks. According to Cursor’s announcement, Composer delivers frontier-level coding performance while being optimized for low latency and fast iteration — Cursor says most conversational turns complete in under 30 seconds in practice and claims generation throughput roughly four times that of similarly capable models in their internal benchmarks. Composer was trained with codebase-wide search and tool access so it can reason about, and perform edits across, large projects.

Where Composer sits inside Cursor’s product

Composer is not a separate “app” you buy on its own; it’s offered as a model option inside the Cursor product (desktop & web) and is routable through Cursor’s model router (Auto). You get model-level access depending on which Cursor subscription you have and whether you pay metered usage fees beyond your plan’s allowance. Cursor’s model docs list Composer among the available models and the company provides both subscription tiers and token-metering for model usage.

Cursor’s mid-2025 changes to usage pools and credit systems illustrate this trend: rather than truly unlimited use of premium models, Cursor provides plan allowances (and Auto choices), then bills extra usage at API/token rates.

Key features and advantages of Composer

Composer is aimed at developer productivity for nontrivial engineering tasks. The main selling points:

Agentic code reasoning: Composer supports multi-step workflows (e.g., understanding a bug, searching a repo, editing multiple files, running tests and iterating). This makes it better suited than single-shot completions for complex engineering work.
Speed / low latency: Cursor reports Composer is significantly faster in generation throughput compared to comparable models and that typical interactive turns finish quickly, enabling faster iteration loops.
Tight codebase integration: Composer was trained with access to Cursor’s retrieval and editing toolset as well as codebase indexing, which improves its ability to work with large repositories and maintain context across files.
Agent modes & tools: Composer is designed to work with Cursor’s agent modes and the Model Context Protocol (MCP), letting it call specialized tools, read indexed code, and avoid repeatedly re-explaining the project structure. That reduces repetitive token usage in many workflows.

Why that matters: for teams doing deep code edits and multi-file refactors, Composer can reduce manual iteration and context switching — but because it is agentic and can perform more compute work per request, per-request token usage tends to be higher than simple completion models (which drives the metered costs discussion below).

How was Composer built ?

Architecture and training approach

Composer is described as an MoE model fine-tuned with reinforcement learning and a custom, large-scale training pipeline. Key elements highlighted by Cursor:

Mixture-of-experts (MoE) design to scale capacity efficiently for long-context code tasks.
Reinforcement learning (RL) with reward signals tuned to agentic behaviors useful in software engineering: plan writing, using search, editing code, writing tests, and maximizing parallel tool use.
Tool-aware training: during training Composer had access to a set of tools (file read/write, semantic search, terminal, grep) so it learned to call tools when appropriate and integrate the outputs.
Custom infra: Cursor built PyTorch + Ray based pipelines, MXFP8 MoE kernels, and large VM clusters to enable asynchronous, tool-enabled RL at scale. The infra choices (low-precision training, expert parallelism) are intended to reduce communication costs and keep inference latency low.

Why moE + RL matters for code

Code editing requires precise, multi-step reasoning over large repositories. MoE gives the model episodic capacity (lots of parameters available selectively) while RL optimizes for behaviors (don’t hallucinate, run tests, propose minimal diffs). Training with the agent toolset means Composer is not being fine-tuned purely on next-token prediction — it learned to use the tooling available in Cursor’s product setting. That’s why Cursor positions Composer as an “agentic” model rather than just a completion model.

How are Cursor subscription plans priced for Composer?

Cursor’s pricing combines subscription tiers (monthly plans) with usage-based charges (tokens, cache, and certain agent/tool fees). The subscription tiers give you base capabilities and included, prioritized usage; the heavy or premium-model usage is then billed on top. Below are the public list prices and the high-level meaning of each plan.

Individual (personal) tiers

Hobby (Free): entry-level, limited agent requests / tab completions; includes a short Pro trial. Good for light experimentation.
Pro — $20 / month (individual): everything in Hobby plus extended agent usage, unlimited tab completions, background agents, and maximum context windows. This is the common starting point for individual developers who want Composer-level features.
Pro+ — $60 / month (individual, recommended for power users): more included usage on premium models . Cursor’s June 2025 pricing rollout clarified that Pro plans include a pool of model credits (for “frontier model” usage) and that additional usage can be purchased at cost-plus rates or via token billing.
Ultra — $200 / month: for heavy individuals needing substantially larger included model usage and priority access.

Team / Enterprise

Teams — $40 / user / month: adds centralized billing, usage analytics, role-based controls and SSO. Larger teams can also buy Enterprise (custom pricing) that includes pooled usage, invoice/PO billing, SCIM, audit logs and priority support.

Token-Based Pricing for Cursor Composer

Cursor mixes per-user plans with per-token billing for premium or agentic requests. There are two related but distinct billing contexts to understand:

Auto / Max mode token rates (Cursor’s “Auto” dynamic selection or Max/Auto billing buckets).
Model-list / direct model pricing (if you select a model like Composer directly, the model list APIs have per-model token rates).

These different modes change the effective input/output token rates you’ll see on your bill. Below are the canonical figures Cursor publishes in its documentation and model pages — these are the most load-bearing numbers for cost calculations.

Auto / Max

When you go beyond plan allowances (or explicitly use Auto to route to premium models), Cursor charges for model usage on a per-token basis. The most commonly referenced rates for Cursor’s Auto router (which picks a premium model on demand) are:

Input + Cache Write: $1.25 per 1,000,000 tokens
Output (generation): $6.00 per 1,000,000 tokens
Cache Read: $0.25 per 1,000,000 tokens

Those rates were documented in Cursor’s account/pricing docs describing Auto billing and are the backbone of Composer’s operating cost when Composer usage is billed via Auto or when you directly select model usage charged at API rates.

Composer and model-list prices

Cursor’s model list / model-pricing reference shows per-model pricing entries. For some premium models inside Cursor, Composer in model-list prices : Input $1.25 / 1M; Output $10.00 / 1M. In practice this means if you explicitly choose Composer as the model rather than running Auto, the output token rate you incur could be higher than Auto’s $6 output rate

Why input vs output tokens differ

Input tokens are the tokens you send (prompts, instructions, code snippets, file context). Cursor charges for writing those into the system (and occasionally caching them).
Output tokens are what the model generates (the code edits, suggestions, diffs, etc.). Output generation is more expensive because it consumes more compute. Cursor’s published numbers reflect those relative costs.

Comparing Cursor Composer with competitors

When judging cost and value, it’s useful to compare Composer’s unit economics to other widely-used developer AI services. Note that model capabilities, latency, integration, and included plan allowances also matter — price alone isn’t the whole story.

GitHub Copilot (individual tiers)

GitHub Copilot is primarily priced per user with tiers (Free, Pro at ~$10/month, Pro+ and Business tiers higher). Copilot provides a number of “premium” requests per month and charges for additional premium requests (published per-request add-ons). Copilot bundles models (including Google/Anthropic/OpenAI options in some plans) and is sold as a per-developer SaaS. For many individual devs, Copilot’s all-in per-seat price can be simpler and cheaper for routine completions; for heavy multi-step agentic tasks, a token-metered model may be more transparent.

OpenAI (API / advanced models)

OpenAI’s higher-end models (GPT-5 series and premium variants) have different per-token economics that can be higher than Cursor’s Composer rate for certain pro models. OpenAI also provides many performance tiers (and batch or cached discounts) that affect effective costs. If comparing, consider latency, accuracy on coding tasks, and the value of Cursor’s editor integration (which may offset a per-token cost delta).

Which is cheaper in practice?

Small, frequent completions / autocompletes: A per-seat SaaS (Copilot) is often cheapest and simplest.
Large multi-file, agentic tasks: Token-metered models (Composer via Cursor Auto or Anthropic/OpenAI directly) give flexibility/quality but cost more per heavy request; careful modeling of token use is essential.

Conclusion — Is Composer “expensive”?

Composer is not billed as a single flat line-item — it’s part of a hybrid system. For light-to-moderate interactive use, a $20/month Pro plan plus Auto-mode usage may keep your costs low (tens of dollars a month). For heavy, parallel agent workloads with many long outputs, Composer can drive hundreds or thousands per month because output-token rates and concurrency multiply costs. Compared to subscription-first competitors (e.g., GitHub Copilot), Cursor’s Composer trades a higher marginal inference cost for much faster, agentic, repository-aware capabilities.

If your goals are multi-agent automation, repo-wide refactors, or shorter iteration cycles that save engineering time, Composer’s speed and tooling can deliver strong ROI.

How do I use CometAPI inside Cursor? (step-by-step)

Short summary: CometAPI is a model-aggregation gateway (single endpoint that can proxy many model vendors). To use it in Cursor you register at CometAPI, get an API key and model identifier, then add that key + endpoint into Cursor’s Models settings as a custom provider (override base URL) and select the CometAPI model in Composer/Agent mode.

CometAPI also designed a proprietary coding model based on Claude specifically for cursor: cometapi-sonnet-4-5-20250929-thinking and cometapi-opus-4-1-20250805-thinking etc.

Step A — Get your CometAPI credentials

Sign up at CometAPI and create an API key from their dashboard. Keep the key secret (treat it like any bearer token).
Create / copy an API key and note the model name/ID you want to use (e.g., claude-sonnet-4.5 or another vendor model available via CometAPI).CometAPI docs/guides describe the process and list supported model names.

Step B — Add CometAPI as a custom model/provider in Cursor

Open Cursor → Settings → Models (or Settings → API Keys).
If Cursor shows an “Add Custom Model” or “Override OpenAI Base URL” option, use it:

Base URL / Endpoint: paste the CometAPI OpenAI-compatible base URL (CometAPI will document whether they expose an openai/v1 style endpoint or a provider-specific endpoint). (Example: https://api.cometapi.com/v1 — use the actual URL from CometAPI docs.)
API Key: paste your CometAPI key in the API key field.
Model name: add the model identifier exactly as CometAPI documents (e.g., claude-sonnet-4.5 or composer-like-model).

Verify the connection if Cursor offers a “Verify” / “Test” button. Cursor’s custom model mechanism commonly requires the provider to be OpenAI-compatible (or for Cursor to accept a base URL + key). Community guides show the same pattern (override base URL → provide key → verify).

If you want to know more tips, guides and news on AI follow us on VK, X and Discord!

Originally published at cometapi.com

Connecting Raycast AI to an OpenAI-Compatible Gateway

Dylan Foster — Tue, 22 Sep 2026 02:09:07 +0000

I want model selection to be part of my desktop workflow, not a reason to open another application. Raycast’s custom providers make that possible: configure an OpenAI-compatible endpoint, supply your own API key, and select a model inside Raycast AI.

For this setup, I’m using CometAPI, a unified gateway exposing hundreds of models through an OpenAI-style REST API. The integration hinges on https://api.cometapi.com/v1, Raycast’s providers.yaml, and a valid token. The main thing to watch is version-specific configuration: use the template shipped with your installed Raycast version.

Decide What You’re Connecting

Raycast is a macOS productivity launcher with commands, scripts, and AI features. Its AI surfaces include Quick AI for launcher prompts, AI Chat for conversations with attachments and context, and AI Commands or extensions for reusable workflows. It also supports local models through Ollama and remote providers through Bring Your Own Key (BYOK) and custom providers.

Raycast added BYOK in v1.100.0, with BYOK and Custom Providers rolling out during 2025. I’d start with a recent release and check Settings → AI for the controls available in that installation.

The gateway’s catalog spans text, images, embeddings, audio, and video, but I would not treat that catalog as a list of capabilities automatically available in Raycast AI. Chat integration and endpoint-specific integrations are different pieces of work.

For code explanation, refactor suggestions, unit tests, PR summaries, and README drafts, the chat path is the relevant starting point. Image generation needs an extension that calls the image endpoint. Semantic search needs an embedding index and a script or cloud function that Raycast can query. Audio support, including TTS and STT, depends on the underlying model; specialized video backends include Sora and Veo.

Check the Prerequisites First

You need macOS, a recent Raycast installation with the relevant custom-provider controls, and an account with a valid gateway API key. Create a token in the provider’s console and keep it out of shared configuration.

Raycast also needs HTTPS access to api.cometapi.com. On a corporate network, check the proxy and firewall before debugging YAML. Terminal and cURL are enough for a basic connectivity check; Python, Node, and OpenAI SDKs are optional tools for more detailed testing. Standard OpenAI-style clients can use the gateway by overriding base_url.

I’d test authentication and model-list access before touching Raycast. With your token already available locally as GATEWAY_API_KEY, this requests the OpenAI-style models endpoint:

curl --fail-with-body --silent --show-error \
  'https://api.cometapi.com/v1/models' \
  --header "Authorization: Bearer ${GATEWAY_API_KEY}"

This checks that endpoint, not a complete chat workflow. Automatic model discovery still depends on the provider exposing a compatible models response and your Raycast version supporting discovery.

Configure From Raycast’s Own Template

Locate the Configuration

Open Preferences → AI, find Custom Providers or Custom OpenAI-compatible APIs, and choose Reveal Providers Config. Use the directory Raycast reveals rather than guessing a configuration path.

Raycast provides a template, usually named providers.template.yaml. Copy it to providers.yaml in that directory, or edit the existing configuration if you already have custom providers.

The exact schema can differ across releases. Common provider entries include id, name, base_url, and an optional models block, but the installed template should determine their nesting and syntax. I would not paste a supposedly universal YAML example over that template.

Set the Endpoint and Credentials

Add a provider entry using the template’s structure. Give it a distinct identifier and a recognizable display name, then set base_url to https://api.cometapi.com/v1. There is no trailing period in that URL.

Add the token through Raycast’s custom API-key or secure credential fields where supported. Never commit a real token in a shared providers.yaml. macOS Keychain is another option where the integration supports it; environment-variable injection is appropriate for a local proxy you control, not something to assume Raycast’s YAML supports automatically.

You may not need to enumerate every model manually. Raycast can discover models through a properly implemented OpenAI-style GET /v1/models endpoint when that discovery path is supported. Otherwise, follow the template’s model configuration and use exact model identifiers from the provider.

Reload and Run a Small Test

Return to Raycast and refresh models if your version offers that action. If the provider or models do not appear, restart the app.

Open Quick AI, explicitly choose a model from the new provider, and submit a short prompt. I’d keep this first request minimal: it should establish that credentials, model selection, and the response path work before adding attachments, long context, or tools.

Debug the Boundary That Failed

No models in the picker: Check that providers.yaml is in the exact directory opened by Reveal Providers Config. Compare its structure with the installed template, then refresh or restart. If discovery is unavailable, check whether explicit model entries are required.

401 or invalid-token responses: Confirm that the token is valid and has not expired. Run the direct request above and verify that authentication uses Authorization: Bearer …. A failed direct request is a reason to resolve credentials or endpoint access before changing Raycast settings.

Model-specific failures: Verify the model ID first. OpenAI compatibility can still leave differences in response shapes or streaming behavior. If a request fails while streaming, test a non-streaming request directly to narrow the problem, then raise the incompatibility with the provider if needed.

Slow responses: Measure the models you actually intend to use. Gateway routing can introduce variable latency, and a model that works well for a long reasoning task may be a poor choice for an interactive launcher command.

Make the Workflow Worth Keeping

I’d use lightweight, fast models for selected-text summaries, action-item extraction, and short lookups. For deeper reasoning, choose a higher-capacity model; for larger inputs, evaluate context capacity as well. Model selection is a practical cost and latency control, not just a preference.

Track usage in the gateway dashboard and configure budget alerts where available. Shorter system messages and deliberate context management can reduce token use without turning every prompt into an optimization exercise.

For recurring tasks, duplicate a built-in Raycast AI Command and adjust its prompt. Utility commands benefit from predictable instructions and consistent output formats; ideation commands can be more open-ended. Documentation drafting and PR summaries are useful starting points because the output is easy to inspect.

Finally, local credentials do not make remote inference local. Before sending sensitive code, notes, or attachments, read both Raycast’s and the provider’s privacy documentation. I’d keep the initial setup narrow: one tested model, one useful command, and a clear understanding of where the request goes.

Originally published at cometapi.com

How to Prompt GPT Image 2.5 Like a Pro: The Complete 2026 Guide

Dylan Foster — Tue, 22 Sep 2026 01:29:19 +0000

TL;DR GPT Image 2.5 changes image prompting in one important way: a good prompt no longer describes only what you want to create. For editing and reference-based generation, it should also define what must not change.

That matters because GPT Image 2.5 is designed for more precise editing and stronger reference preservation. OpenAI says the model is better at changing only the requested element while keeping the subject, composition, and surrounding details intact.

Good GPT Image 2.5 Prompt = Deliverable + Subject + Scene + Composition + Visual Direction + Exact Text + Constraints + Output

Good Editing Prompt = Change Target + Preserve List + Integration Rules + Exclusions + Output

The second formula is especially important. Instead of saying “Change the background to a beach,” write: “Replace only the background with a quiet Mediterranean beach at sunset. Keep the person, face, pose, clothing, camera position, framing, lighting direction, and foreground unchanged.”

Key Takeaways

GPT Image 2.5 improves fidelity, multi-turn consistency, text rendering, and speed; Flare is the recommended starting point for most users.
Core generation formula: Deliverable + Subject + Composition + Style + Exact Text (in quotes) + Constraints/Exclusions.
For edits the golden rule is “Change only X. Preserve [full list of identity, pose, lighting, geometry, text, style].”
Multiple reference images succeed when each is given an explicit job (subject, clothing, background, palette, etc.).
Transparent backgrounds, exact typography, and sequential editing are markedly stronger when prompted correctly and parameters are set properly.
Flare prioritizes speed and volume; Sunburst prioritizes edit precision and final-asset fidelity. Both share the same token rates.
CometAPI offers unified, cost-effective access to gpt-image-2.5-flare and gpt-image-2.5-sunburst via familiar OpenAI-compatible routes.

What Is GPT Image 2.5

OpenAI released ChatGPT Images 2.5 on September 8, 2026. The update focuses on sharper detail, more natural lighting and texture, reference-image fidelity, precise edits, and stronger consistency across multiple editing turns. OpenAI also reports up to 50% lower image-generation latency compared with Images 2.0.

For developers, the family is split into two API models:

GPT-Image-2.5 Flare — optimized for fast, high-quality everyday generation and high-volume workflows.
GPT-Image-2.5 Sunburst — optimized for demanding generation and editing workflows where precision matters more than latency.

Developers can also use the GPT Image 2.5 API in CometAPI, including the gpt-image-2.5-flare and gpt-image-2.5-sunburst model identifiers.

Benchmark and capabilities

Arena text-to-image benchmark	GPT Image 2.5 Sunburst	GPT Image 2.5 Flare	GPT Image 2
Text-to-image score	1421 ± 13	1399 ± 13	1381 ± 4
Text-to-image rank	#1	#2	#3
Single-image-edit score	1520 ± 9	1491 ± 9	1461 ± 3
Single-image-edit rank	#1	#2	#3

Independent tests and early Arena rankings placed both models at the top of text-to-image and image-editing leaderboards shortly after launch, with clear gains in composition, detail, style fidelity, subject preservation, and speed (Flare often finishing in ~20–40 seconds vs. significantly longer prior generations in some benchmarks).

Key capabilities include text + image inputs, image outputs up to roughly 4K (with constraints: edges multiples of 16, max ~3840 px per side, aspect ratio ≤ 3:1), transparent backgrounds (PNG/WebP), quality tiers (low → max), progressive previews, inpainting/area-specific editing, and strong support for multi-reference and sequential editing. OpenAI reports more than 3 billion images created weekly across ChatGPT Images and the GPT-Image API family.

General Formula for Generating and Editing GPT Image 2.5

The Most Important Rule: Change vs Preserve

This distinction is the single highest-leverage habit for GPT Image 2.5.

Generation (new image from text or references)
Describe everything you want to appear. Be concrete about the subject, framing, lighting, materials, colors, and what must not appear.

Editing (image-to-image or multi-turn refinement)

Name exactly one change.
Explicitly list everything that must remain unchanged (identity, pose, camera angle, framing, lighting direction, shadows, background elements, existing text, colors, geometry, overall style).
Describe how the new element should integrate with the existing light, perspective, texture, and contact shadows.
Add clear exclusions (no extra text, no logos, no watermarks, no heavy retouching).

Vague multi-change prompts or missing preserve lists cause cumulative drift. Restate the preserve list on every turn. When a region must stay pixel-identical, composite the approved local edit back into the original master rather than trusting the model alone.

Minimal generation skeleton

[Deliverable / intended use] + Subject + Composition + Style / lighting / materials + Exact text in quotation marks + Constraints and exclusions

Minimal edit skeleton

Change only [specific element] to [new description]. Preserve [identity, pose, framing, lighting, shadows, background, text, colors, style]. Match the new element to existing light and geometry. Do not add [unwanted elements].

How GPT Image 2.5 Prompting Works

OpenAI’s official prompting guidance is straightforward: start with the image you need, then describe the subject, composition, style, and constraints. For edits, clearly separate the requested change from the details that must stay the same. Refine one thing at a time and inspect every result.Structure prompts as Subject → Composition → Style → Text (quoted) → Constraints. Assign clear roles to every reference image, iterate one change at a time, and set size/quality/background as API parameters rather than prompt text.

Subject

Name the primary person, object, or scene with visible, testable details: appearance, clothing, pose, action, relative scale, and interaction with objects.
Example: “A young archivist with a short auburn bob, round black glasses, and a navy work coat holding a sealed paper envelope with a red wax moon emblem.”

Composition

Specify framing, camera height and angle, subject placement (centered, left third, etc.), negative space, depth of field, and what must be visible (full body with feet, medium close-up, etc.).
Example: “Full body, feet visible, low eye-level camera. Character on the left third; endless archive shelves recede behind her. Clean dark space at upper right for later title placement.”

Style

Describe the visual medium, lighting (source + direction), materials, color palette, texture, and realism level. Prefer concrete visual language over pure mood adjectives. Explicitly request “photorealistic,” “real photograph,” film grain, or a named artistic style when required.
Example: “Detailed hand-painted anime background, restrained cel shading, natural proportions. One warm desk lamp against cool blue moonlight from high windows.”

Text

Place every required string inside quotation marks. Specify location, hierarchy, approximate typography, and how many times the text should appear. Spell unusual or brand names letter-by-letter when critical. Always request “no other text.”
Example: the headline "Open Late" in bold condensed type across the top, and "Thursday to Sunday" in smaller type at the bottom. No other text.

Constraints / Exclusions

List what must not appear and what must remain unchanged. High-value exclusions include no extra text, no logos, no watermarks, no heavy retouching, and no unwanted objects.

For longer or more complex requests, use labeled sections (SCENE / SUBJECT / STYLE / TEXT / CONSTRAINTS). This improves readability and makes later edits easier to maintain.

Critical technical note: Set model, quality, size (or aspect), and background (auto / opaque / transparent) as API parameters. Do not rely on the prompt text to enforce resolution or transparency.

How Do You Use Multiple Reference Images With GPT Image 2.5?

GPT Image 2.5 accepts multiple image inputs. Results improve dramatically when every reference is given an explicit role.

Recommended pattern:

Number or clearly name each reference image.
State its precise job: primary subject identity, clothing/style reference, background/setting, color palette only, lighting reference, etc.
Describe how the elements should combine and which parts move where.
Restate preservation constraints for the primary subject and any protected details.

Example: “Use image 1 as the product (matte black water bottle with exact label text). Use image 2 only for the pale concrete ledge and natural outdoor lighting direction. Place the bottle from image 1 on the ledge from image 2, matching the existing soft shadows and light angle. Preserve the bottle’s exact shape, label text, colors, and reflections. Do not change the concrete texture or add any extra objects.”

Clear role assignment prevents unwanted hybridization of subjects or styles.

Advanced Prompting Techniques

Exact Text & Typography Tutorial

Always enclose required strings in quotation marks.
Specify position, hierarchy, approximate weight and style, and the number of times the text should appear.
Request “no other text,” “no logos,” and “no watermarks.”
For dense layouts or multiple fonts, test medium or high quality and visually verify spelling and legibility in the output.
Critical brand names can be spelled letter-by-letter for extra reliability.

Transparent Backgrounds

Set background="transparent" in the API call (or the equivalent UI control) and request PNG or WebP output. Explicitly ask for clean edges and nothing behind the subject. Inspect the alpha channel carefully around hair, glass, fine details, and contact areas. Add exclusions such as “no background elements, no drop shadows unless requested.” Transparent generation is significantly more reliable in 2.5 when the parameter and prompt constraints are both correct.

Multi-turn Editing Workflow

Start from a strong base generation or approved reference.
Feed the previous output back as the new input image.
Request exactly one change.
Restate the complete preserve list on every turn.
Inspect the result before continuing.
For regions that must remain pixel-perfect, composite the approved local edit into the original master image.

This disciplined loop takes full advantage of GPT Image 2.5’s improved multi-turn consistency while minimizing cumulative drift.

Flare vs. Sunburst: Which Model Fits Which Prompt?

Criterion	GPT-Image-2.5 Flare	GPT-Image-2.5 Sunburst
Primary strength	Speed + high everyday quality	Edit precision & final-asset fidelity
Latency	Up to ~50% lower than GPT Image 2	Longer generation times
Best use cases	Social content, prototyping, high-volume, rapid iteration	Production campaign creative, polished product shots, complex multi-turn edits
Quality vs GPT Image 2	Higher	Highest control / tightest preservation
Recommended starting point	Most workflows	When quality or edit precision is the bottleneck
Token pricing	Same rates for both	Same rates for both
Transparent backgrounds & quality tiers	Fully supported (low → max)	Fully supported

Practical decision rule: Explore ideas, generate variations, and iterate quickly on Flare. When you need the final polished version or when a complex edit sequence begins to drift, re-run the identical prompt + references + settings on Sunburst and compare. Many production teams keep both models available and route traffic accordingly.

Prompt Templates (Ready to Adapt)

1. Clean Product Hero

Purpose: Ecommerce or landing-page hero, square or 4:5.
Subject: [exact product description including materials and any label text in quotes].
Composition: Centered or slight three-quarter view, soft contact shadow, generous negative space at top for headline.
Style: Clean studio lighting from the left, photorealistic, high texture detail.
Constraints: No extra text, no logos, no people reflections, seamless background.

2. Exact-Text Poster / Ad

A vertical poster. Headline “YOUR EXACT HEADLINE” in bold condensed sans-serif across the upper third. Subhead “Secondary line here” in smaller weight directly below. [Full scene and subject description]. [Style]. No other text or logos.

3. Precise Single-Element Edit

Change only the [specific element] to [new description]. Preserve the subject’s exact face/identity, pose, clothing details, camera angle, lighting direction, shadows, background, and all existing text. Match the new element’s lighting, perspective, and contact shadows to the original scene. Do not add any new objects, text, or watermarks.

4. Multi-Reference Character Consistency

Use image 1 for the character’s face, body proportions, and identity. Use image 2 only for the outfit and fabric texture. Place the character from image 1 wearing the outfit from image 2 inside [scene description]. Match the lighting direction of image 1. Preserve identity and pose exactly. No extra accessories or text.

5. Transparent Cutout / Asset

[Detailed subject description] isolated on a pure transparent background. Clean edges, no drop shadow, no background elements, no floor contact shadow unless explicitly requested. Photorealistic. Output ready for compositing.

Replace the bracketed sections with your specifics and always restate constraints on subsequent editing turns.

Why Prompts Fail

Common failure patterns and how to fix them:

Relying on vague mood words (“cozy,” “epic,” “premium”) without attached visual detail → add concrete scale, light direction, materials, and color.
Packing multiple changes into one prompt → limit to one change per turn.
Omitting or shortening the preserve list on later edits → details drift; restate the full list every time.
Exact text not placed in quotation marks or without location/typography guidance → wrong words or extra text appear.
Reference images uploaded without assigned roles → the model blends them unpredictably.
Expecting a higher quality tier to rescue a weak description → the prompt carries the result; quality mainly affects refinement, cost, and latency.
Using special syntax, weights, or “masterpiece 8K ultra detailed” keyword stacking → clear, ordered sentences consistently outperform keyword stuffing.
Forgetting integration instructions on edits → new elements look composited rather than natural.

Higher quality settings (xhigh or max) help with dense text, fine detail, or complex layouts, but they cannot compensate for an underspecified prompt.

PT Image 2.5 Prompting Mistakes Should You Avoid?

Mistake	Weak approach	Better approach
No deliverable	“Make something cinematic”	“Create a 4:5 paid-social product photograph”
Vague edit	“Improve the background”	“Replace only the background with…”
No preservation rules	“Change the shirt”	Lock face, pose, camera, and background
Unassigned references	“Use these images”	Give each reference one role
Too many changes	Five major edits in one request	One controlled change per pass
Assuming prompt = compliance	Trust the generation	Perform visual QA

Accessing GPT Image 2.5 Through CometAPI

CometAPI provides OpenAI-compatible access to both gpt-image-2.5-flare and gpt-image-2.5-sunburst under a single API key and the familiar /v1/images/generations and edits endpoints. Benefits include centralized authentication and billing, competitive token rates, easy switching between Flare and Sunburst, usage visibility, and the ability to combine image generation with the broader catalog of 500+ models without managing multiple vendor accounts.

A typical migration requires only changing the base URL to https://api.cometapi.com/v1, supplying your CometAPI key, and selecting the desired model ID. This setup is especially valuable for production pipelines that need to A/B the two variants, control costs, or route different quality tiers efficiently.

For the latest parameter lists, pricing, and code examples, consult CometAPI’s image generation documentation alongside OpenAI’s official image prompting guide.

Conclusion

GPT Image 2.5 rewards clarity, structure, and discipline. Define the deliverable, describe the visible subject and composition with concrete detail, name the style through lighting/materials/color, put exact text in quotes, and (for every edit) ruthlessly separate the single change from the full preserve list. Give every reference image a clear job, iterate one decision at a time, and let API parameters handle size, quality, and transparency. Start exploration and high-volume work on Flare; move to Sunburst when final precision or complex edit sequences demand it.

Master the Change-vs-Preserve rule and the Subject–Composition–Style–Text–Constraints structure, and GPT Image 2.5 becomes a reliable production tool rather than a source of endless regeneration. Pair it with a unified gateway such as CometAPI and you gain both creative power and operational simplicity.

FAQs

Should GPT Image 2.5 prompts be long?

Not necessarily. A long prompt full of vague adjectives can be weaker than a short prompt with precise composition and preservation instructions. Include detail where failure would matter.

How do I stop GPT Image 2.5 from changing the whole image?

Use a narrow instruction such as “Change only the jacket,” then explicitly list what must remain unchanged: identity, pose, framing, camera position, lighting, background, text, and other approved elements.

How do I preserve a person’s face?

Use a clear reference photo, assign it as the authoritative identity reference, and state which characteristics must remain stable. Do not rely entirely on “same person.”

How do I make GPT Image 2.5 generate exact text?

Provide the final copy verbatim, state where it should appear, specify its hierarchy, and instruct the model not to add other words. Always verify the final text visually.

Can GPT Image 2.5 create transparent PNG images?

Yes. Set the background to transparent and use PNG or WebP output.

Can GPT Image 2.5 generate 4K images?

Yes. The documented maximum includes 3840 × 2160 landscape and 2160 × 3840 portrait output. Resolutions above 2560 × 1440 are experimental, and custom dimensions must satisfy the API’s divisibility and aspect-ratio constraints.

Is GPT Image 2.5 better for editing than GPT Image 2?

OpenAI highlights improved precision editing, reference preservation, and multi-turn consistency. Arena’s early preference results also favored both 2.5 variants at the dated snapshot, but these preliminary rankings can change.

Originally published at cometapi.com

How to Integrat Make to 500+ AI Models with CometAPI

Dylan Foster — Mon, 21 Sep 2026 07:26:19 +0000

In 2026, AI is no longer a standalone tool—it's the engine driving automated business processes. Platforms like Make.com (formerly Integromat) empower users to build complex visual workflows connecting thousands of apps, while AI models handle intelligent decision-making, content generation, data analysis, and more.

However, integrating dozens of AI providers (OpenAI, Anthropic, Google, xAI, etc.) means managing multiple API keys, billing accounts, rate limits, and inconsistent SDKs. This creates friction, vendor lock-in, and higher costs.

CometAPI solves this by offering unified access to 500+ cutting-edge AI models through a single OpenAI-compatible API endpoint. Users get one key, one dashboard for billing and analytics, real-time model access, and typical savings of 20-40% compared to direct provider pricing.

Pairing Make with CometAPI creates a powerful no-code/low-code solution for AI-powered automations. Whether you're generating content, classifying support tickets, building AI agents, or creating multimodal workflows (text, image, video), this integration delivers speed, flexibility, and scalability.

Make's CometAPI integration includes dedicated modules: Create a Chat (with fallback models), Create an API Call (arbitrary authorized requests), and List Models.

What is Make? Why It's Ideal for AI Automations

Make.com is a visual workflow automation platform supporting 3,000+ pre-built app integrations. It excels at:

Drag-and-drop scenario builder with routers, iterators, filters, and error handlers.
Native support for webhooks, scheduling, data parsing, and JSON mapping.
Built-in AI tools and agents (next-gen agents with multimodal support announced in 2026).
Enterprise features: SSO, audit logs, team collaboration.

Why Use CometAPI with Make

Users consolidate traffic (LLM + images) for savings. Developers praise support and pricing transparency. Integration is verified and maintained by CometAPI on Make.

For no-code developers, the traditional method of building AI workflows involves installing separate modules for OpenAI, Anthropic, and Google. This creates "vendor sprawl," where you must monitor multiple billing dashboards and manage separate API credits. Using CometAPI with Make simplifies this architecture by providing one single connection that grants access to over 500 models. Instead of switching modules when you want to move from GPT to Claude, you simply change a text field in your configuration.

Cost efficiency is another primary driver for this integration. CometAPI utilizes institutional bulk purchasing power to set prices permanently 20% to 40% below official vendor rates. In high-volume production environments—such as a Make scenario that processes thousands of customer emails daily—these savings can translate into hundreds of dollars of reclaimed margin every month. Furthermore, CometAPI provides a 99.9% Service Availability SLA, ensuring that if a specific provider like OpenAI experiences a regional outage, your Make scenario remains operational through intelligent multi-region routing.

Prerequisites

To follow this guide, you will need the following:

A Make account (Works on all plans, including Free and Pro).
A CometAPI account (Registration includes free trial credits with no credit card required).
An active CometAPI API Key from your personal dashboard.

Step-by-Step Setup Guide

Step 1: Get Your CometAPI API Key

First, log in to your CometAPI dashboard. Navigate to the API Token section and click the Add API Key button. This will generate a unique key (formatted as sk-xxxx) that acts as your "master key" for all 500+ models. Copy this key and keep it secure. Note the unified Base URL provided in the documentation: https://api.cometapi.com/v1.

Step 2: Create a New Scenario in Make

Log in to your Make account and click Create a new scenario. In the scenario editor, click the large plus icon to add your first module. Search for CometAPI in the search bar. You will see the official CometAPI module listed; select it to see the available actions. For most workflows, you will use the Make an API Call action.

Step 3: Connect Your CometAPI Account

After selecting the action, a configuration window will appear. Click the Add button next to the Connection field. In the "API Key" field, paste the secret key you copied from the CometAPI dashboard in Step 1. Give your connection a descriptive name, such as "My Production CometAPI," and click Save. This connection is now authorized to call any model in the catalog.

Step 4: Configure the API Call

Example using Create a Chat:

Choose model (e.g., claude-opus-4-7 or gpt-5-4-pro).
Set messages, temperature, max_tokens, etc.
Add fallback models for resilience.

Now you must define which model you want to use and what data you want to send.

For text tasks, set the URL to /v1/chat/completions and the Method to POST. In the Body field, use the following JSON structure:

{  "model": "gpt-5.5",  "messages": [    {      "role": "user",      "content": "{{1.text}}"    }  ],  "stream": false}

The {{1.text}} syntax is standard Make mapping. You can replace this by clicking into the field and selecting a variable from a previous module (like a Gmail message or a Google Sheet cell). If you want to generate images, change the URL to /v1/images/generations and use the image-specific body format.

Step 5: Test and Publish

Click the Run once button at the bottom of the scenario editor. Make will execute the scenario and send your request to CometAPI. Once finished, click the bubble above the CometAPI module to inspect the output. You should see a successful 200 OK response with the AI-generated text or image URL. If everything looks correct, toggle the Scheduling switch to "On" to activate your automation.

Which Models Can You Use

The versatility of a unified API means you can use the best tool for every specific task in your Make no-code AI workflow.

Model Category	Example Model ID	Best Make Scenario Use Case
Logic & Reasoning	claude-opus-4-7	Analyzing complex legal contracts or multi-step support tickets.
Coding & Data	deepseek-v4-pro	Writing SQL queries or refactoring code snippets from Airtable.
Efficient Chat	gpt-5.5	Daily conversational assistants and email drafting.
Image Creation	flux-2-max	Creating high-fidelity marketing banners and product mockups.
Video Automation	sora-2	Turning social media posts into short cinematic clips with audio.

Ready-to-Use Make Scenario Templates

Template 1: Customer Support Auto-Reply

This workflow reduces human response time for common inquiries while escalating complex issues.

Trigger: A Gmail or Typeform module detects a new customer message.
Processing: Use Claude Opus 4.7 via the CometAPI module to analyze the message. This model is chosen for its superior context window and low hallucination rate.
Router: Use a Router module to check the AI's "Sentiment" or "Urgency" output.
Branch A: If the issue is simple, the scenario sends an Automated Reply via Gmail.
Branch B: If the issue is a high-priority bug, the scenario sends a Slack notification to the engineering team.
Parameters: Set the body to request a JSON response containing {"category": "bug", "urgency": 10} for easy filtering.

Template 2: Content Repurposing Pipeline

This template allows you to scale your social media presence across multiple languages with extreme cost efficiency.

Trigger: A new row is added to Google Sheets containing a blog post URL.
Action 1: An HTTP module scrapes the text from the URL.
Processing 1: Use GPT 5.5 to generate a high-quality 200-word summary in English.
Processing 2: Send that summary to DeepSeek V3 to translate it into Chinese and generate SEO keywords.
Why Two Models?: DeepSeek is used for the translation step because it is significantly cheaper ($0.216/M tokens vs $4/M for GPT 5.5), allowing you to optimize your per-run costs.
Output: Post the results to a Buffer or Notion module.

Template 3: Image Generation Automation

Automate your e-commerce design process by turning product descriptions into visual assets.

Trigger: A new record is created in Airtable with a product name and "Design Brief."
Action: Use the CometAPI module with the /v1/images/generations endpoint and the Flux 2 Max model.
JSON Body:

{  "model": "flux-2-max",  "prompt": "E-commerce product shot of {{1.Product_Name}}, {{1.Brief}}, photorealistic, 4k",  "n": 1,  "size": "1024x1024"}

Storage: Use an Airtable Update Record module to save the resulting image URL back into a checkbox field for review.

Comparison Table: CometAPI + Make vs. Alternatives

Aspect	CometAPI + Make	Direct Provider + Make	Other Aggregators (e.g., OpenRouter)	Zapier + Single Provider
# Models	500+ unified	Limited per provider	Many, but variable	Fewer
Setup Complexity	Low (pre-built modules)	Medium (multiple connections)	Medium	Medium
Cost Savings	20-40% + unified billing	None	Varies	None
Fallbacks & Routing	Native in modules	Manual	Some	Limited
Observability	Excellent (unified dashboard)	Fragmented	Good	Basic
Multimodal	Full support	Per provider	Good	Varies
No-Code Ease	Highest	Medium	Medium	High
Vendor Lock-in	None	High	Low	High

Cost Optimization Tips for Make + CometAPI

To get the most out of your automation budget, implement these three strategies:

DeepSeek Routing: For classification or simple data extraction tasks, route your traffic to DeepSeek V4 Flash. This model offers a 1M-token context window but costs 90% less than flagship models. By using DeepSeek for the "dirty work" of your scenario and reserving GPT or Claude for the final "polished" output, you can reduce your total scenario cost by over 60%.
Make Filter Modules: Always use a Filter module before your CometAPI call. If a field is empty or does not meet specific criteria, the filter will stop the scenario, preventing unnecessary API calls and saving you "Operations" in Make as well as tokens in CometAPI.
Aggregator Batching: If your scenario processes many records at once, use the Array Aggregator module to combine them into a single list, then send them to CometAPI in one large prompt. This reduces the number of separate API requests, which helps you stay within rate limits and simplifies your usage logs in the dashboard.

Pricing Insights and ROI Calculation

CometAPI: Pay-as-you-go, credits roll over, volume discounts. Examples show significant savings vs. official rates.

Make: Starts low (e.g., ~$9/mo for operations). Combined, ideal for high-ROI automations (time saved >> subscription).

Example ROI: Automate content for 10x output at fraction of manual cost; support triage reduces tickets by 50%+.

Troubleshooting Common Issues

401 Unauthorized Error

This error nearly always points to an issue with your API Key. Double-check that you have not added an extra space at the beginning or end of the key when pasting it into Make. Also, ensure your CometAPI account has a positive credit balance; although signup is free, you must have active credits to make calls beyond the trial.

422 Unprocessable Entity

If you receive a 422 error, check your JSON formatting in the body field. Ensure every opening brace { has a corresponding closing brace } and that you are using straight quotes " rather than "curly" quotes. Additionally, verify that the model name you entered matches the official identifier in the CometAPI model catalog exactly (e.g., gpt-5.5 instead of GPT 5.5).

Scenario Timeouts

Some advanced reasoning models take longer to generate a response. If your Make scenario times out, first ensure that "stream": false is set in your JSON body, as Make does not support raw stream processing in its standard API call module. If the error persists, consider switching to a "Flash" tier model like Gemini 3.1 Flash-Lite or DeepSeek V4 Flash, which are optimized for sub-second responses.

Future-Proofing Your AI Stack with CometAPI on Make

As AI evolves (new models weekly in 2026), this integration lets you adopt instantly without refactoring. Combine with Make Grid, AI Agents, and CometAPI's continuous updates for a robust, scalable system.

CometAPI Recommendation: Start with free credits on CometAPI. Use the playground to test models, then refer to guide and build your first Make scenario. For high volume, explore enterprise options for custom SLAs and dedicated support.

Conclusion

Integrating Make with CometAPI unlocks the full potential of no-code AI automations with unparalleled model choice, cost efficiency, and simplicity. One integration gives access to the entire AI ecosystem—saving time, money, and engineering effort while delivering production-grade reliability.

Ready to get started?

Sign up for CometAPI (free credits) → CometAPI
Build your first scenario on Make.com
Explore more templates and guides on both platforms.

This powerful combo positions your workflows for 2026 and beyond. Experiment, iterate, and scale confidently.

FAQ

Q: Is there an official CometAPI module in Make?

A: Yes. You can find it by searching for "CometAPI" in the module selector. It provides a standardized way to call any model in the catalog without writing custom code.

Q: Can I use multiple different models in a single Make scenario?

A: Absolutely. You can add as many CometAPI modules as you need to a single workflow. For example, you can use one module for text analysis and another for image generation within the same automation path.

Q: Is the CometAPI integration compatible with the Make Free plan?

A: Yes. As long as you have your API key and are using the "Make an API Call" action, it will function perfectly on the Free tier.

Q: How does this integration compare to the native OpenAI module in Make?

A: While the native OpenAI module is restricted to OpenAI models, CometAPI gives you access to 500+ models from all providers (OpenAI, Google, Anthropic, etc.) using the exact same connection, plus a 20-40% cost saving.

Q: Does the integration support image generation?

A: Yes. You can call the /v1/images/generations endpoint to access models like GPT Image 2, Flux 2 Max, and Nano Banana 2 directly from Make.

Originally published at cometapi.com

The 2026 LLM API Pricing Comparison: GPT-5.5, Claude Sonnet 4.6, Gemini 3.5 Flash and DeepSeek V4

Dylan Foster — Mon, 21 Sep 2026 06:57:17 +0000

Pricing is the single most consequential decision in choosing a frontier LLM, and it is also the dimension where most published comparisons are out of date within a quarter. This article cuts through that. Below is a current, sourced view of input and output token pricing across the four models that account for the majority of production frontier-model traffic in 2026 (OpenAI’s GPT-5.5, Anthropic’s Claude Sonnet 4.6, Google’s Gemini 3.5 Flash, and DeepSeek’s V4), together with the levers that meaningfully change your bill at scale: prompt caching, batch processing, and long-context surcharges.

The piece is built around two questions. First: at list price, what does each model cost per million tokens, and how do the quoted rates compare on the inputs and outputs that actually drive a production bill? Second: when you apply a representative workload (100 million tokens a month, 80% input and 20% output, with realistic cache hit rates), what is the monthly bill in dollars on each model? The first answer establishes the rate card; the second tells you what that rate card becomes once it touches a real production pattern.

Quick read: Across the four frontier models, list pricing spans roughly two orders of magnitude. DeepSeek V4 is the cheapest at $0.435 per million input tokens; Claude Opus 4.7 is the most expensive at $5.00. The shape of your workload, particularly your cache hit rate and your input-to-output ratio, changes which model is cheapest in practice, often by more than the rate card suggests.

Why a like-for-like pricing comparison is harder than it looks

Provider pricing pages are written for that provider's own customers, not for someone evaluating four options side by side. The result is that comparing them produces three persistent traps:

Tokens are not the same across providers. Claude Opus 4.7 ships with a new tokenizer that can produce up to 35% more tokens for the same input text than Opus 4.6. Gemini's tokenizer differs from OpenAI's. The rate card is per million tokens, but the token count for the identical prompt varies between providers, meaning the headline rate is only a first approximation of relative cost.
Long-context pricing tiers create cost cliffs. OpenAI's GPT-5.5 family has separate short-context and long-context rates that kick in around 270,000 tokens. Anthropic, conversely, holds the same per-token rate across its full 1M context window. Workloads that sit near these thresholds are priced very differently to workloads that sit comfortably inside them.
Discounts are stacked, not separate. Prompt caching, batch processing, and provider-specific volume tiers can each cut effective cost dramatically, and they stack. A cached batch request on Anthropic can cost as little as 5% of a standard non-cached request. A pricing comparison that ignores these levers overstates list cost, sometimes by an order of magnitude.

The comparison below normalises for these traps where it can, and flags them explicitly where it cannot.

The 2026 frontier LLM pricing comparison

All figures in US dollars per million tokens. Sourced from each provider's official pricing documentation as of May 2026.

Model	Input	Output	Cached input	Batch (50% off)	Context window	Long-context surcharge
GPT-5.5	$5.00	$30.00	$0.50	$2.50 / $15.00	1M	Yes (~270K)
Claude Sonnet 4.6	$3.00	$15.00	$0.30	$1.50 / $7.50	1M	None
Claude Opus 4.7	$5.00	$25.00	$0.50	$2.50 / $12.50	1M	None
Gemini 3.5 Flash	$1.50	$9.00	$0.15	$1.00 / $6.00	1M	Yes (200K)
DeepSeek V4	$0.435	$0.87	$0.0028	Not offered	384K	None

Reading the table: Cached input is the rate paid on tokens served from prompt cache (typically system prompts, few-shot examples, or document prefixes that recur across requests). Batch is the rate paid for asynchronous workloads with up to 24-hour latency. Long-context surcharge denotes whether the provider raises rates above a context-length threshold; for those that do, the threshold is given in parentheses.

Where each model wins

GPT-5.5: the highest-capability default for hard reasoning and agentic work

GPT-5.5 is OpenAI's frontier model for complex professional workloads: coding agents, multi-step planning, long-running tool use, and document analysis where reasoning depth is the dominant requirement. It is also the most expensive of the major US frontier models on input ($5.00 per million) and the highest on output ($30.00 per million), which means it earns its position on workloads where the alternative is paying a flagship rate to a different model that solves the problem less reliably. GPT-5.5 supports caching at a 90% discount, batch processing at 50% off, and long-context pricing kicks in around the 270K-token mark, which is relevant for very long codebases or full-repository contexts but not for typical RAG workloads.

Claude Sonnet 4.6: the recommended default for most production traffic

Sonnet 4.6 is Anthropic's recommended model for the majority of production workloads, and the price-to-capability ratio is the reason. At $3 input and $15 output per million tokens, it sits below GPT-5.5 on both rates while delivering near-Opus quality on the workloads that dominate most production systems: coding, analysis, RAG pipelines, customer-facing chat, and structured output generation. Sonnet's distinguishing pricing feature is that the full 1M token context window is available at standard rates (there is no long-context surcharge), which makes it the cheapest credible option for workloads that occasionally need to ingest very long documents or full repositories. Prompt caching cuts cached input to 10% of standard, which is decisive for any workload with a stable system prompt.

Gemini 3.5 Flash: the most aggressively-priced flagship for short-context work

Gemini 3.5 Flash is the cheapest flagship-class model from a major US provider on raw API pricing, at $1.50 input and $9.00 output per million tokens. For most production traffic, that is the relevant pricing tier, and it materially undercuts both GPT-5.5 and Claude Opus 4.7. Higher price than prior Flash models leads to increased overall costs in token-heavy agentic scenarios (5.5x Intelligence Index cost vs. Gemini 3 Flash due to pricing + usage).. Gemini's other distinguishing feature is the genuinely free tier in Google AI Studio, which is useful for prototyping but not relevant to production cost models.

DeepSeek V4: dramatically cheaper, with caveats worth understanding

DeepSeek V4 lists at $0.435 per million input tokens and $0.87 per million output tokens, which is between five and seventy times cheaper than the US frontier models depending on which one you compare against. The model itself is competitive on many benchmarks, particularly reasoning and code. The caveats are worth being explicit about: data is processed in China, which is a non-starter for some regulated workloads; English-language quality is strong but the model is optimised differently to the US frontier models, and head-to-head testing on your specific workload is essential rather than optional. For workloads where these caveats are acceptable, DeepSeek genuinely changes the cost equation.

A note on Claude Opus 4.7 vs Sonnet 4.6. Opus is included in the table for completeness, but for the great majority of production traffic, Sonnet 4.6 is the better economic choice. Opus costs 1.67x Sonnet on both input and output, and for workloads where Sonnet is sufficient (which is most of them), that premium has no offsetting benefit. Reach for Opus when evaluations show Sonnet is failing on a specific class of task: highly autonomous coding agents, long-horizon professional workflows, and tasks where instruction-following at the margin is decisive.

Worked example: what 100 million tokens a month actually costs

Headline pricing per million tokens means little until it touches a representative workload. The example below uses a profile that approximates a non-trivial production system: 100 million total tokens per month, split 80% input (80M) and 20% output (20M), with a 30% cache hit rate on the input portion. This pattern is broadly representative of a customer-facing chat or RAG workload with a stable system prompt and document context.

The math for each model: cached input cost + uncached input cost + output cost. Cached input is billed at 10% of standard for the providers that offer caching.

Model	Cached input (24M)	Uncached input (56M)	Output (20M)	Total monthly bill
GPT-5.5	$12.00	$280.00	$600.00	$892.00
Claude Sonnet 4.6	$7.20	$168.00	$300.00	$475.20
Claude Opus 4.7	$12.00	$280.00	$500.00	$792.00

What this tells you. On a representative workload,Sonnet 4.6 in turn is roughly half the cost of GPT-5.5. DeepSeek is in a different cost universe entirely. These are list-price numbers; applying batch processing where eligible cuts each total by a further 50% on the inputs and outputs (though not the cache hits).

Two observations worth carrying forward. First: caching is the single most impactful lever you control. The example above assumes a 30% cache hit rate; raise it to 60% (entirely achievable for workloads with a stable system prompt), and total cost drops by roughly another 25%. Second: the input-to-output ratio matters a lot. Workloads that are output-heavy (summarisation, long-form writing) bias toward providers with cheaper output rates, while input-heavy workloads (long-context analysis, large RAG retrievals) bias toward providers with cheaper input rates and no long-context surcharge.

The hidden costs not on the pricing page

List pricing is the floor, not the ceiling. Five additional costs are worth budgeting for explicitly, because they routinely surprise teams scaling from prototype to production:

Reasoning tokens. Models with extended reasoning modes (GPT-5.5 Thinking, DeepSeek V4 thinking mode) generate internal reasoning content that counts as output tokens. A single high-effort reasoning call on a long prompt can run 20,000 reasoning tokens, which is $0.60 of output cost on GPT-5.5 before the visible response is produced. Budget per workload, not per request.
Long-context surcharges. Both Gemini 3.5 Flash and GPT-5.5 raise rates above a context-length threshold. RAG pipelines that include large documents can silently push every request into the higher bracket without anyone noticing until the bill arrives. Measure your actual prompt lengths in production and check whether you are crossing the threshold.
Data residency multipliers. Anthropic charges a 10% premium for US-only inference on Opus 4.7 and Sonnet 4.6. OpenAI applies a 10% uplift on data residency endpoints for the GPT-5.4 family. For regulated workloads where this matters, factor it into the rate card from day one.
Output verbosity drift. When a new model version is more thorough by default (as Opus 4.7 reportedly is compared to Opus 4.6), output tokens per response can creep up even if input length is constant. Output is priced 5x higher than input on the Anthropic line, so a 20% creep in output verbosity is a 20% increase in the dominant cost driver.
Failed and retried requests. Most providers do not bill for 4xx and 5xx errors, but they do bill for partial generations and retries that succeed on the second attempt. In production systems with active retry logic, this can add a few percent to the bill. Worth knowing about when reconciling provider invoices against expected cost.

How CometAPI fits in

All four of these models, plus 500+ others, are available through CometAPI on a single OpenAI-compatible endpoint, with one credential, unified billing, and no per-provider account setup. Pricing on CometAPI is metered per token at the same per-model rates published by the underlying providers, with credits purchased upfront and applied across any model in the catalogue. The value of routing through CometAPI is operational rather than per-token: one credential to manage, one invoice to reconcile, and the ability to swap from GPT-5.5 to Claude Sonnet 4.6 to Gemini 3.5 Flash by changing a single string in your code.

There are workloads where direct provider access is the right call. If you run a single-model workload at very high volume on one provider, with a negotiated enterprise contract, the unit economics of going direct are better. If your compliance posture requires a specific vendor-of-record relationship, an aggregator complicates rather than simplifies that conversation. For the majority of teams running multi-model production workloads, however, the operational friction of managing three or four direct provider relationships is itself a meaningful cost, one that the rate card does not capture.

Try the comparison on your workload. The free tier on CometAPI lets you run the same prompt against GPT-5.5, Sonnet 4.6, Gemini 3.5 Flash, and DeepSeek V4 from a single endpoint, with no separate signups. For a workload-specific cost decision, that one-hour exercise is worth more than any pricing comparison ever published.

How to use this comparison

The right model for your workload depends on which dimension of the rate card matters most for your traffic shape. A practical decision framework:

If reasoning depth is the bottleneck (agentic workflows, complex multi-step planning, the hardest coding tasks), start with GPT-5.5 or Claude Opus 4.7. The premium is real but earned on these workloads.
If you want the best price-to-capability ratio for general production traffic, Claude Sonnet 4.6 is the recommended default. Near-frontier capability, full 1M context at standard rates, and strong caching support.
If you are cost-sensitive and your workload sits below 200K context, Gemini 3.5 Flash is the cheapest credible flagship-class option from a major US provider.
If your workload is high-volume and price-dominated, and DeepSeek’s data-residency posture is acceptable, V4 changes the cost equation enough to be worth a serious evaluation, particularly for batch-shaped workloads.

Want to go further on cost optimization? The pricing data above is the foundation for routing: the practice of sending different queries to different models based on which one can handle them at the lowest cost. The companion piece, Cutting LLM API Costs in Half: A Model Routing Guide for Production Workloads in 2026, walks through the routing patterns that turn this rate card into actual savings on your monthly bill.

Originally published at cometapi.com

How to Add AI Image Generation to a Web App

Dylan Foster — Mon, 21 Sep 2026 04:38:58 +0000

In 2026, AI image generation has transformed from a novelty into a core feature for modern web applications. Whether you're building an e-commerce platform with personalized product visuals, a content creation tool, a social media app, or an educational platform, embedding AI-powered image generation can dramatically enhance user experience, boost engagement, and create new revenue streams.

The global AI image generator market was valued at approximately USD 412-484 million in 2025/early 2026 and is projected to reach USD 1.7 billion by 2034, growing at a CAGR of around 17.4%. Other analyses show even faster expansion in the broader generative AI segment, with daily image creation exceeding tens of millions. Over 150 million people use these tools monthly, producing massive volumes of content.

Why integrate now? Users expect dynamic, personalized visuals. Static images lead to higher bounce rates; AI-generated ones increase time-on-site by enabling customization (e.g., "generate a beach scene with my dog"). Leading models in 2026—such as OpenAI's GPT Image series, Google's Nano Banana / Imagen variants, Black Forest Labs' Flux 2 Pro, and Midjourney—deliver photorealism, accurate text rendering, 4K output, real-time grounding, and conversational editing.

This comprehensive guide covers everything: market context, technical implementation with code, best practices, comparisons, security/ethics, optimization, and tailored recommendations for CometAPI (a unified gateway to 500+ models including image generation like Midjourney, GPT Image, and more). By the end, you'll have actionable knowledge to ship production-ready features.

Why AI Image Generation Matters for Web Apps in 2026

Quick Answer: Adding AI image generation involves choosing an API (e.g., CometAPI for multi-model access), handling frontend prompts and backend calls securely, displaying results with error handling, and optimizing for cost/latency. Key benefits include personalization, faster content creation, and competitive edge.

Supporting Data:

82% of large enterprises use generative AI in at least one function.
Photorealism and text-in-image capabilities have improved dramatically; models like Flux 2 Pro and GPT Image 1.5/2 lead benchmarks.
Cost per image ranges from $0.005 (budget models) to $0.06+ for premium, making high-volume apps viable.

Long-tail keywords covered: "integrate Flux AI image API web app", "Midjourney API React tutorial 2026", "cost-effective AI image generation for SaaS".

Understanding the 2026 AI Image Generation Landscape

Latest Trends and Models

2026 is the year of the "AI image arms race." Key advancements:

4K output and real-time grounding: Models incorporate live data for context-aware images.
Conversational editing: Iterative refinement via chat (strong in GPT Image and Gemini-based models).
Specialized strengths: Flux for photorealism/product shots; Ideogram for text; Midjourney for artistic/consistent characters.

Top models (per LM Arena and comparisons):

GPT Image 1.5/2 (OpenAI): High quality, strong prompting.
Flux 2 Pro (Black Forest Labs): Excellent fidelity.
Imagen 4 / Nano Banana (Google): Speed and integration.
Midjourney: Creative excellence via API.

Market Impact on Web Devs

Integrating these reduces dependency on stock libraries (costly licensing) and enables features like user-generated mockups or dynamic avatars, driving metrics like conversion rates up 20-30% in e-commerce tests (industry benchmarks).

Choosing the Right AI Image Generation API: Comparison Table

Selecting an API is critical. Direct provider APIs work but lead to vendor lock-in and multiple keys. Unified services like CometAPI excel here.

Comparison Table (2026 Data):

Model/Provider	Quality (Elo/Score)	Speed	Price/Image (approx.)	Strengths	Best For Web Apps	CometAPI Access?
GPT Image 1.5/2 (OpenAI)	Top (1264+)	Fast	$0.04-$0.06	Prompt adherence, editing	General, conversational	Yes
Flux 2 Pro	1265+	Medium	$0.03-$0.055	Photorealism, detail	E-commerce, products	Yes
Imagen 4 / Nano Banana	High	Very Fast	$0.02-$0.04	Speed, text, multimodal	Real-time apps	Yes
Midjourney	Artistic leader	Medium	Varies	Creativity, consistency	Design, social	Yes (via CometAPI)
Ideogram v3	Strong text	Fast	Competitive	Typography in images	Marketing banners	Available

Recommendation: Start with CometAPI for one OpenAI-compatible endpoint, access to 500+ models (LLMs + images + video), pay-as-you-go, free tier credits, and no lock-in. It simplifies switching models based on task (e.g., cheap for prototypes, premium for production).

Step-by-Step: How to Integrate AI Image Generation into a Web App

1. Planning and Architecture

Frontend: React/Vue/Svelte for prompt input, preview, gallery.
Backend: Node.js/Express, Python/FastAPI, or Next.js API routes for security (hide API keys).
Flow: User prompt → Backend validation/rate limiting → API call → Store/return URL → Display with lazy loading.
Additional: Async queues (e.g., BullMQ) for high traffic; caching (Redis) for repeats.

2. Setting Up with CometAPI (Recommended)

Sign up at CometAPI.com and get your API key (free credits available).
Use OpenAI-compatible endpoint: https://api.cometapi.com/v1/images/generations (or specific model endpoints).

Example Node.js Backend (Express):

const express = require('express');
const axios = require('axios');
const app = express();
app.use(express.json());

const COMETAPI_KEY = process.env.COMETAPI_KEY; // Never expose client-side

app.post('/generate-image', async (req, res) =&gt; {
  const { prompt, model = 'gpt-image-2' } = req.body; // Or flux, midjourney etc. via CometAPI

  if (!prompt || prompt.length &gt; 4000) {
    return res.status(400).json({ error: 'Invalid prompt' });
  }

  try {
    const response = await axios.post('https://api.cometapi.com/v1/images/generations', {
      model: model,
      prompt: prompt,
      n: 1,
      size: "1024x1024", // or higher for 2026 models
      // quality, style params as supported
    }, {
      headers: {
        'Authorization': `Bearer ${COMETAPI_KEY}`,
        'Content-Type': 'application/json'
      }
    });

    const imageUrl = response.data.data[0].url;
    // Optional: Save to S3/Cloudinary, log usage
    res.json({ imageUrl, revised_prompt: response.data.data[0].revised_prompt });
  } catch (error) {
    console.error(error.response?.data || error);
    res.status(500).json({ error: 'Generation failed. Try again.' });
  }
});

app.listen(3000, () =&gt; console.log('Server running'));

Security Best Practices: Use environment variables, rate limiting (express-rate-limit), input sanitization, and monitor for prompt injection (OWASP GenAI guidelines).

3. Frontend Implementation (React Example)

import React, { useState } from 'react';
import axios from 'axios';

function ImageGenerator() {
  const [prompt, setPrompt] = useState('');
  const [imageUrl, setImageUrl] = useState(null);
  const [loading, setLoading] = useState(false);

  const generate = async () =&gt; {
    setLoading(true);
    try {
      const res = await axios.post('/generate-image', { prompt });
      setImageUrl(res.data.imageUrl);
    } catch (e) {
      alert('Error generating image');
    }
    setLoading(false);
  };

  return (

       setPrompt(e.target.value)} placeholder="A futuristic city at sunset..." /&gt;
      &lt;button onClick={generate} disabled={loading}&gt;
        {loading ? 'Generating...' : 'Generate Image'}
      &lt;/button&gt;
      {imageUrl &amp;&amp; &lt;img src={imageUrl} alt="AI Generated" style={{maxWidth: '100%'}} /&gt;}
    &lt;/div&gt;
  );
}

Enhance with galleries, history (localStorage or DB), and variations (call API with variation params where supported).

4. Python/FastAPI Alternative (for Data-Heavy Apps)

from fastapi import FastAPI
import httpx
import os

app = FastAPI()
COMETAPI_KEY = os.getenv("COMETAPI_KEY")

@app.post("/generate")
async def generate(prompt: str, model: str = "flux-2-pro"):
    async with httpx.AsyncClient() as client:
        response = await client.post(
            "https://api.cometapi.com/v1/images/generations",
            json={"model": model, "prompt": prompt},
            headers={"Authorization": f"Bearer {COMETAPI_KEY}"}
        )
        return response.json()

Deploy with Uvicorn + Docker for scalability.

5. Advanced Features

Image Editing/Inpainting: Use edit endpoints (mask + prompt).
Batch Generation: Loop with async/await for multiple variants.
Upscaling & Post-processing: Chain with dedicated upscaler models via CometAPI.
Real-time: WebSockets for progress updates on longer generations.
Mobile Optimization: Responsive design + PWA for on-device previews.

Best Practices, Optimization, and Scaling

Cost Management: Route cheap models for testing, premium for final output. Monitor with CometAPI dashboards. Implement user quotas.
Performance: CDN for images, lazy loading, progressive enhancement. Aim for <5s response (many 2026 models achieve 2-5s).
UX/UI: Prompt suggestions (AI-powered), negative prompts, style selectors, history gallery, download/share buttons.
Error Handling & Fallbacks: Graceful degradation, retry logic.
Accessibility: Alt text generation (pair with vision LLM via same API), color contrast checks.
Legal/Ethics: Disclose AI-generated content, respect copyrights (use models with commercial licenses), comply with data privacy (GDPR). Avoid harmful content filters.

At 10k users/day with moderate usage, expect $100s-$1000s/month—optimize via model routing and caching.

Case Studies and Real-World Examples

E-commerce: Dynamic product visualizations (e.g., "red sneakers in mountain setting") increase conversions.
SaaS Design Tools: Instant mockups.
Content Platforms: Auto-generate thumbnails or illustrations. Many apps using unified APIs like CometAPI report 40-60% reduction in integration time vs. multiple providers.

Common Challenges and Troubleshooting

Latency: Use faster models or edge caching.
Quality Inconsistency: Refine prompts with examples; use system prompts for style consistency.
Costs Overruns: Set budgets/alerts.
API Changes: Unified services like CometAPI abstract this.

Conclusion: Get Started with CometAPI Today

Integrating AI image generation is no longer optional—it's a superpower for web apps. With robust models, straightforward APIs, and services like CometAPI providing one-key access to Midjourney, GPT Image, Flux, and hundreds more, developers can focus on innovation rather than infrastructure.

Call to Action: Visit CometAPI, grab your free credits, and implement the code above. Experiment with different models to find the perfect fit for your app. Your users (and metrics) will thank you.

FAQs

Q: Can I use DALL-E 3 to generate multiple images in one API call?

No. DALL-E 3 only supports n=1 — one image per request. If you need multiple variations, you'll need to make separate requests, either sequentially or in parallel. DALL-E 2 is the model that supports batch generation (up to n=10 per request).

Q: How long does a DALL-E image URL stay valid?

About 1 hour. OpenAI's image URLs are temporary — don't store the URL and expect it to work the next day. Download the image immediately after generation and save it to your own storage (S3, Cloudflare R2, etc.). Alternatively, use response_format: "b64_json" to get the image data directly in the response, bypassing the URL expiration issue entirely.

Q: What's the difference between GPT Image 2 and DALL-E 3?

GPT Image 2 is better at rendering text inside images, supports quality tiers (low/medium/high), and generates faster. DALL-E 3 returns a URL by default (easier to handle), supports batch-friendly workflows via response_format, and is the safer default for general creative use. The two models also use different parameter sets — response_format works on DALL-E 3 but not GPT Image 2.

Q: Why does my Qwen Image request fail when I set n=2?

Qwen Image only supports n=1. Passing any higher value will return a 400 error. If you need multiple images, make separate requests.

Q: Do I need a separate API key for each model?

No. CometAPI uses a single API key across all models — DALL-E 3, GPT Image 2, Qwen Image, and everything else in their catalog. You switch models by changing the model field in your request, not by managing multiple keys.

Q: What sizes does GPT Image 2 support?

GPT Image 2 supports 1024x1024 (square), 1536x1024 (landscape), 1024x1536 (portrait), and auto (model picks based on the prompt). It does not support arbitrary custom resolutions.

Q: My prompt keeps getting filtered. How do I debug it?

Two things to check: first, look at the revised_prompt field in the response — providers sometimes rewrite your prompt, and seeing what they changed tells you what triggered the filter. Second, check if the data array in the response is empty — that's the signal that generation was blocked rather than a network or auth error. Rephrase the prompt to be more neutral and avoid specific names, brands, or sensitive subjects.

Originally published at cometapi.com

Why Your AI Spend Looks Nothing Like Your Actual Usage Patterns

Dylan Foster — Mon, 21 Sep 2026 04:16:51 +0000

Your monthly AI invoice is a single line that traces nowhere — not to specific features, not to specific teams, not to the workloads that drove the cost. For AI-native startups, the gap between what the bill says and what the product actually does is the reason next quarter's AI forecast is mostly guesswork.

The mismatch

Open the most recent monthly invoice from any of the major AI providers. The format is consistent: a top-line dollar figure, a breakdown by model, possibly a breakdown by API key if you have set that up deliberately. What you will not find is any meaningful mapping to your actual product. Which feature drove most of the cost? Which team's experiments accounted for which slice? How much was production traffic versus internal R&D? Was the spike on the 14th a one-off or a new baseline? The invoice does not answer any of these questions, because the invoice was not designed to.

This is a structural mismatch between how AI providers bill and how AI-native startups actually run. Provider billing is organised around the unit of inference — tokens consumed, requests made, seconds of video generated. Startups are organised around the unit of product — features shipped, experiments run, teams that own things, customers being served. The two shapes do not align, and the cost of that misalignment compounds every time someone asks a question the invoice cannot answer.

This article is the version of that conversation that takes the problem seriously. The argument is not that providers should change their billing — they will not, and frankly do not need to. The argument is that the gap between provider billing and product reality is bridgeable by the team running the product, and the bridge unlocks decisions that are otherwise impossible to make. Most AI-native startups in 2026 are flying without instruments on this; the ones that have instrumented properly are making better calls about pricing, prioritisation, and forecasting than the ones that haven't.

The headline finding: AI spend is bursty, multi-model, and feature-driven. AI billing is monthly, single-line, and provider-organised. The mismatch makes forecasting unreliable, makes feature-level pricing impossible, and makes the AI line item the one your CFO trusts least. The fix is not provider-side — it is at the metering layer, and most teams can build it in a week.

Three patterns that don't fit subscription thinking

To understand why standard billing infrastructure fails AI workloads, it helps to name the three workload patterns that make AI spend behave differently from the SaaS spend that came before it. Each pattern individually creates a forecasting challenge; together, they explain why AI line items are systematically the least predictable category on most startup budgets.

Bursty usage on feature launches

AI workloads do not have a steady-state baseline in the way that SaaS workloads do. A typical AI-native startup's monthly token consumption can spike 5–10x in the week following a feature launch, then drop back to baseline as the launch traffic subsides. The spike is real — it represents actual customers using a new feature — but it is not the new baseline. Anyone forecasting from the spike will overstate next quarter's AI budget; anyone forecasting from the baseline will underestimate the cost of the next launch.

The conventional response — "average it out across the quarter" — is the wrong answer. Averaged numbers hide both the launch behaviour and the steady-state, which means they cannot inform decisions about either. The right framing is to forecast launches and baseline separately, but doing that requires usage data tagged in a way that lets you separate them after the fact. Standard provider invoices do not have that data.

Multi-model workflows where one request touches several providers

A single product feature in 2026 routinely calls more than one model. A document analysis pipeline might use GPT-5.5 for synthesis, Claude Sonnet 4.6 for re-ranking, and Gemini 3.1 Pro for structured extraction — three providers, three rate cards, three contributions to the cost of a single user interaction. From the user's perspective, this is one feature. From the provider invoices' perspective, it is three independent line items distributed across three monthly bills.

The result is that feature-level cost analysis becomes a manual reconciliation problem. Which slice of the OpenAI invoice belongs to the document analysis feature versus the chat feature versus the agent feature? Without explicit tagging at the request level, the answer is unknowable. Most teams either give up on the question or produce rough estimates that can move 50% in either direction depending on how the math is done. Neither is good enough for a product decision.

Internal R&D usage indistinguishable from production

Engineers running prompt experiments, evaluation suites, or new-model comparisons generate genuine API traffic that lands on the same monthly invoice as production usage. When the invoice arrives, there is no native way to separate "production traffic our customers generated" from "R&D our team consumed." For early-stage startups, the R&D fraction can be 30–50% of total spend; for mature ones, it is smaller but still meaningful. Without separation, you cannot answer simple questions like "is our per-customer AI cost going up or are we just experimenting more this month?"

This is the failure mode that hits hardest at series A / series B fundraising. Investors who see flat per-customer AI cost (because experiments and production are being counted together) cannot distinguish efficient products from inefficient ones; the wrong framing can hurt the conversation. Teams that have instrumented R&D versus production separately walk into those conversations with a much sharper story about their unit economics.

Why this matters for forecasting

Forecasting is the activity where the cost of unattributed AI spend shows up most painfully. A finance team trying to model next quarter's AI line needs to answer questions like:

What does our AI cost look like at the current customer count versus 2x it?
How much of last quarter's spend was production traffic versus internal experiments?
If we launch the new agent feature in October, what does that do to the November and December bills?
Which features have the highest AI cost per active user, and are we charging enough to cover them?
What's the marginal AI cost of adding a new enterprise customer of size X?

Each of these questions is answerable with properly attributed data. None of them is answerable from a standard provider invoice. The result is that AI forecasts produced from invoice data are typically either wildly optimistic (smoothing over launch spikes that will recur) or wildly pessimistic (anchoring on a single high-usage month). Both are wrong in different directions, and the finance team learns over time that the AI line is the one they cannot trust — which means it becomes the line they pad most conservatively, which means the budget conversation becomes more contentious than it needs to be.

The shift that fixes this is moving from invoice-level data to request-level data, with each request tagged for the dimensions that matter for forecasting: which feature it served, which team owns it, whether it was production traffic or R&D, which customer or customer-tier triggered it, and which workflow path it took. Once the metering captures these dimensions at the request layer, every forecasting question above becomes a query against that data, not a guess against the invoice.

What proper cost attribution unlocks

The case for instrumenting cost attribution is not just better forecasting. Once the per-request data exists, four downstream decisions become possible that are otherwise either guesswork or impossible to make defensibly.

Pricing the product accurately

AI-native products that charge per seat, per usage, or per outcome all need to know what their underlying inference cost looks like by user, by usage tier, or by outcome category. A product priced at $99/month per user that turns out to cost $112 in AI inference per active user is in trouble; the same product priced at $99/month with $34 of AI cost per user is healthy. The difference between these two situations is invisible from the invoice and obvious from per-feature attribution data. Teams that have this data price their products with confidence; teams that don't are guessing — and the guess goes wrong in both directions often enough that it matters.

Prioritising engineering work

Product roadmap decisions are routinely shaped by cost considerations: "can we afford to ship this feature given the AI bill it will add?" Without attribution, this question is unanswerable in advance. With attribution — specifically, the ability to look at similar existing features and estimate the AI cost of the proposed one — the question becomes a 20-minute analysis. Teams that prioritise this way ship more confidently, sequence work better, and avoid the awkward conversation six months later when a beloved feature turns out to be financially unsustainable.

Defending the AI budget line in CFO conversations

Every AI-native startup's CFO at some point asks the same question: "why is the AI line so volatile, and what are we getting for it?" The teams that can answer in detail — here is the cost broken down by feature, here is the R&D fraction, here are the customer cohorts that consume most, here is the trend over the last six months — have a different conversation than the teams whose only answer is "because of the OpenAI invoice." The CFO's confidence in the budget directly determines how much friction the line item generates each quarter. Detailed attribution buys that confidence cheaply.

Identifying optimisation opportunities surgically

When the AI bill jumps unexpectedly, the question is always "why?" — and the speed of answering that question determines whether the team gets to a fix in a day or a week. With attribution, you can isolate the spike to a specific feature, a specific user cohort, or a specific code path. Without attribution, you have to do detective work across multiple provider dashboards to figure out what changed. Most teams that have done both consistently report that proper attribution turns multi-hour or multi-day investigations into 15-minute queries.

The metering that makes this possible

The shift from invoice-level to request-level cost data depends on metering infrastructure that captures the right dimensions at the moment each request happens. Most teams in 2026 build this on top of one of three patterns, listed in order of increasing investment and capability.

Pattern 1: Per-key segmentation

The simplest pattern, and the one most teams start with. You issue separate API keys for each major dimension you want to attribute on — one key per feature, one per team, one for R&D, one for production. The aggregator's billing dashboard (or, with significantly more effort, the underlying provider dashboards) shows usage broken down by key. At month-end, you have an attribution view that maps cleanly to the dimensions you cared about.

Per-key segmentation is enough for many teams. It handles the production-vs-R&D split, the per-feature attribution for products with a handful of features, and the per-team attribution for small engineering organisations. Where it falls down is when you need finer-grained slicing — per-customer, per-workflow, per-user-tier — because the number of keys becomes unmanageable. For teams that hit that ceiling, the next pattern is the answer.

Pattern 2: Request-level tagging at the application layer

Instead of (or in addition to) per-key segmentation, you instrument your application to tag every AI request with the dimensions that matter: feature, customer ID, workflow step, environment, experiment cohort. The tags are logged to your own observability system alongside the request metadata; cost attribution becomes a query against that data, not a query against the provider invoice.

This pattern is meaningfully more flexible than per-key segmentation because the dimensions are independent — you can slice by customer and feature simultaneously, or by workflow path and team simultaneously, in ways that key-based attribution cannot. The cost is the engineering investment in the metering layer (typically 3–10 days of work for a team that does not already have observability infrastructure) and the discipline of consistently tagging requests in application code.

Pattern 3: Integrated observability platforms

For teams whose AI spend is large enough that the engineering investment in attribution pays back quickly, dedicated AI observability platforms (Helicone, Langfuse, Phoenix, and others in the 2026 landscape) provide request-level tracking out of the box. These platforms sit in the request path, capture all the dimensions you would otherwise build into your own metering layer, and produce dashboards and queries against the data. The trade-off is the vendor relationship and the routing change to put requests through the platform; the benefit is faster time-to-attribution and richer analysis capabilities than most teams would build internally.

Most well-instrumented AI-native startups in 2026 use a combination — per-key segmentation for the coarse dimensions (production vs R&D, team boundaries) and either application-layer tagging or an observability platform for the finer dimensions. The combination scales well as the organisation grows; starting with per-key segmentation gives you immediate value while you decide whether to invest in deeper instrumentation.

A worked example: a 12-person AI-native startup

Concrete numbers help. Below, the per-feature attribution view for a representative 12-person AI-native startup running three core product features, with an additional row for internal R&D and one for shared infrastructure (embeddings, evals). All figures are illustrative but proportionally representative of what teams at this scale typically see.

Cost dimension	Monthly spend	% of total	Per active user	Models used
Feature A: AI chat	$8,200	32%	$0.41	GPT-5.5, Sonnet
Feature B: Document analysis	$6,800	26%	$1.36	Sonnet, Gemini
Feature C: Agent workflows	$4,500	17%	$3.21	Opus, GPT-5.5
Shared infra (embeddings, evals)	$3,200	12%	—	Multiple
Internal R&D and experiments	$3,300	13%	—	Multiple
Total	$26,000	100%	—	—

The conversation this table enables, that an invoice never would, is the per-active-user cost column. Feature A serves 20,000 active users; Feature B serves 5,000; Feature C serves 1,400. The per-user cost variation (41 cents, $1.36, $3.21) is genuinely useful information for the product team: it tells them that Feature C is the most expensive per user to run, and forces an honest conversation about whether the pricing or the underlying architecture needs to change. None of this is visible from a $26,000 monthly invoice without breakdown.

The internal R&D fraction (13%) tells another important story: a healthy investment in experimentation, neither too low (suggesting the team is not exploring new models or prompt strategies) nor too high (suggesting R&D may be eating into production budget). Investors who see this fraction broken out separately are seeing the team's R&D investment explicitly, which is what they need to evaluate the company's engineering culture and unit economics independently.

The forecasting model that emerges

Once the attribution data exists, forecasting next quarter's AI spend becomes a structured calculation rather than a guess. The model has three components — and once it is set up, the team can update it in 15 minutes whenever assumptions change.

Production baseline. For each feature, take the trailing 90 days of per-active-user cost, multiplied by the forecast of active users in the period. This produces a baseline that grows linearly with customer count, which is the right shape for most production AI traffic.
Launch and event spikes. For each planned product launch or major marketing moment, estimate the spike duration (typically 1–3 weeks) and the multiplier (typically 3–10x baseline traffic). Multiply into a one-time addition. This component captures the bursty pattern that breaks naive forecasting.
R&D allocation. Set the R&D budget as a percentage of total (10–20% is typical for AI-native startups in steady state) or as an absolute monthly cap. This component is a planning decision, not a forecast — but it should be set explicitly rather than absorbed silently into the production budget.

The sum of these three is the forecast. When something changes — a new launch added to the roadmap, a customer cohort growing faster than expected, a new model coming online that changes the per-user cost — the forecast updates immediately because the inputs are all explicit. Compare this to the current state in most AI-native startups, where the forecast is "last quarter's total times a growth factor we made up" — and the difference in forecasting accuracy is substantial.

What this means in practice: Teams that move to attribution-based forecasting consistently report two changes. First, the variance between forecast and actual drops from typical ranges of 30–50% down to 5–15%. Second, the conversations between engineering and finance get easier — both sides are looking at the same data, the same assumptions are explicit, and disagreements about the AI line are about real questions ("should we cap R&D this quarter?") rather than about whose number is right.

How to get started this week

If your team is currently flying without instruments on AI cost attribution, the path from invoice-only to properly attributed is shorter than it looks. A practical sequence:

Define the dimensions you actually need to attribute on. For most teams, the starting list is: feature (3–6 categories), environment (production vs R&D), and team (if you have multiple teams using AI). Customer-level attribution is the next layer up but can wait until the first three are working. Resist the urge to track every dimension you might want — start with what answers the questions your CFO is actually asking.
Issue one API key per dimension you want to track coarsely. If your aggregator supports per-key billing dashboards, this is the fastest path to immediate value. One key per feature, one key for R&D, one key for shared infrastructure. The attribution shows up in the dashboard automatically. Time investment: an hour.
Run for one month before drawing conclusions. A single month of data is enough to see the per-feature shape but not enough to identify seasonal patterns or trend lines. Don't make big decisions from the first month; do start a habit of looking at the data weekly so the patterns become familiar.
Decide whether the coarse view is enough. After 30 days, you will know whether per-key segmentation answers the questions you actually need answered. For many teams, it does. For teams that need finer-grained slicing (per-customer, per-workflow), now is the time to add application-layer tagging or evaluate an observability platform — informed by 30 days of real data about what you need.
Build the forecasting model. Once you have three months of attributed data, the three-component forecast (production baseline + launch spikes + R&D allocation) can be built in an afternoon. This is the deliverable that changes the conversation with your CFO. Most teams report it as the single highest-leverage piece of finance instrumentation they ship in their first year.

Where this leaves you

Your monthly AI invoice does not look like your product, and that mismatch is the reason AI forecasting feels harder than it should. The fix is not on the provider side. It is at the metering layer — making sure each request is tagged for the dimensions you actually care about, so that attribution becomes a query against your data rather than a guess against the invoice. Once that infrastructure exists, four things become possible that are otherwise impossible: accurate pricing, defensible prioritisation, credible CFO conversations, and surgical optimisation when things go wrong.

Provider billing is organised around tokens. Your product is organised around features. The mismatch is bridgeable, the bridge is cheap to build, and it unlocks decisions you cannot otherwise make. The teams that have instrumented attribution properly forecast AI cost within 5–15% accuracy; the teams that haven't run 30–50% off. The instrumentation is the difference.

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

AGI vs ASI: The Distinction I Use When Evaluating AI Agents

Dylan Foster — Mon, 21 Sep 2026 03:34:22 +0000

I find the AGI-versus-ASI debate useful only when it changes what I measure or how I build. A model producing a convincing answer is one thing. A system reliably completing unfamiliar work, across domains, without supervision is another.

Artificial General Intelligence (AGI) means broadly human-level cognitive capability across tasks. Artificial Superintelligence (ASI) means capability substantially beyond the best humans across virtually every cognitive domain. Generality is the central requirement for AGI; broad superiority is the additional requirement for ASI. Neither label follows from a strong coding demo.

Start With Three Separate Questions

When evaluating a system, I separate breadth, performance, and autonomy. Can it handle unfamiliar task categories? How well does it perform against competent humans? How long can it operate before someone must intervene? Collapsing those questions into one “intelligence” score hides the failures that matter in production.

Dimension	AGI	ASI
Breadth	General competence across cognitive tasks	General competence with broad superhuman performance
Performance	Human-comparable, with thresholds varying by definition	Substantially beyond the best human experts
Learning	Transfers knowledge and adapts to unfamiliar tasks	Could develop better learning methods and improve AI itself
Scientific work	Performs or assists with human-level research	Could accelerate scientific and technological progress
Status	No broad consensus that current systems qualify	Theoretical
Principal concerns	Reliability, displacement, bias, misuse, control	Those concerns plus potentially severe loss-of-control risks

A narrow system can outperform humans at chess, protein structure prediction, or image classification without being AGI. Conversely, a broadly capable system does not become ASI merely because it runs faster than a person. Digital speed, parallel execution, and scalable deployment matter, but they are not substitutes for demonstrated competence.

What Would Count as AGI?

The idea reaches back to researchers including Alan Turing and John McCarthy. The practical target is a system that can learn, reason, plan, and apply knowledge across domains without needing a separate task-specific training process for each new assignment.

Definitions differ on the human reference point. Some use roughly median human performance; others require expert-level competence across a broad task distribution. DeepMind’s levels framework distinguishes performance levels, including expert, virtuoso, and superhuman capability. That makes “human-level” an incomplete specification unless the task distribution and comparison population are also stated.

For engineering purposes, I would look for transferable knowledge, long-horizon planning, effective tool use, adaptation to unfamiliar conditions, and reliable self-correction. None of these is established by an isolated benchmark result. A system that solves an Olympiad problem but misses a simple instruction has demonstrated an impressive capability, not consistent general competence.

Why Current Models Remain Hard to Classify

Frontier systems can code, analyze documents, use browsers and other tools, process multiple modalities, and assist with research. The source’s 2026 discussion names GPT-5 variants, Claude Opus, Gemini, and OpenAI’s o-series as examples of progress. It also identifies persistent weaknesses in factual grounding, causal reasoning, memory, embodied learning, long-term planning, and self-correction.

The source reports approximately 35–65% on Humanity’s Last Exam, compared with approximately 90% for human experts, and leaders near or at 85% on ARC-AGI-2. Those figures need dated evaluation references, model configurations, and scoring conditions before I would use them in a technical comparison. They are not interchangeable measurements of “percentage of AGI achieved.”

The more revealing contrast is with deployed work. The source cites approximately 2.5% automation of freelance work for top models in some assessments. That is an assessment-specific result, not a universal automation rate, but it illustrates the benchmark-to-workflow gap. GAIA, BIG-bench, and ARC evaluations probe different capabilities; the Legg-Hutter intelligence measure is a theoretical formalization, not an equivalent operational leaderboard.

My working description is advanced general-purpose AI with increasingly agentic capabilities. It communicates what these systems can do without treating a disputed milestone as settled.

Autonomy and Reliability Matter More Than the Label

An answer-generating model and an agent that browses, writes code, runs tests, purchases services, and messages people expose very different operational risks. Extending the time horizon also increases the opportunity for a small mistake to propagate through subsequent actions.

METR’s 2025 time-horizon study provides a more concrete signal than impressions of intelligence. It measured task difficulty using the time a human expert would need, then evaluated agent success. The study found that the 50% task-completion time horizon had doubled approximately every seven months over six years. That is an observed trend, not proof that it will continue or that AGI arrives on a particular date.

I would also resist treating 50% completion as a deployment target. An agent can improve rapidly on that metric while still needing extensive supervision for consequential work. Code that passes an initial check but introduces a security vulnerability remains a failed outcome.

The source attributes continuing weaknesses in multi-step planning, financial analysis, coherent realistic video, and some expert academic exams to the Stanford AI Index 2026. It also cites the International AI Safety Report 2026 on fabricated information, flawed code, and misleading advice. These are central evaluation concerns, not cosmetic defects around otherwise complete general intelligence.

ASI Would Be a System, Not Just a Better Model

ASI is usually defined as intelligence vastly exceeding the smartest humans across scientific discovery, strategic planning, creativity, social reasoning, and other cognitive domains. It remains hypothetical. Claims that it would instantly solve global problems, discover new physics, or make its reasoning incomprehensible are possibilities or speculation, not established properties.

I find the system-level framing more useful: models, memory, tools, compute, data access, deployment infrastructure, and feedback loops working together. A single conversational interface could conceal that infrastructure, but the interface would tell us little about the system’s actual capability.

Recursive self-improvement is one possible mechanism. An AI might improve training software, evaluations, synthetic data generation, inference efficiency, architectures, or hardware design. If those improvements substantially accelerate further improvements, capability growth could speed up. An “intelligence explosion” is a proposed outcome of that feedback loop, not something guaranteed by the definition of AGI.

The upside could include faster progress in medicine, materials, education, climate science, and productivity. The downside includes amplified cyberattacks, deception, biological risks, economic disruption, and loss of human control. If a system outperforms human experts, checking every answer directly becomes harder. Oversight would need multiple approaches: scalable supervision, interpretability, adversarial testing, formal verification where applicable, model-to-model critique, audits, and institutional controls.

Four Possible Routes Beyond Human-Level AI

The source attributes four pathways to a Google DeepMind report titled From AGI to ASI, dated June 2026. I would treat that report attribution and publication date as requiring verification before citing them as established evidence. The pathways themselves are useful hypotheses to distinguish.

Scaling and Algorithmic Change

Continued scaling means more compute, better data, larger or more efficient models, stronger inference-time reasoning, and improved tool use. The open question is which bottlenecks yield to those investments. Data quality, energy, memory, reasoning, embodiment, and alignment do not necessarily improve at the same rate.

Algorithmic change is a different route: new architectures, world models, stronger memory, neuro-symbolic reasoning, active learning, self-play, or planning systems. Future progress need not come exclusively from larger versions of current transformers. Neither pathway establishes a predictable date for superintelligence.

Recursive Improvement and Agent Collectives

Recursive improvement starts with AI contributing to AI development. The important distinction is between useful engineering assistance and a feedback loop powerful enough to accelerate the underlying research process dramatically.

Multi-agent collectives offer another possibility. Specialized systems could search, simulate, debate, verify, and coordinate, potentially producing capability beyond any individual component. The source describes this as an AI organization or virtual agent economy. I would still evaluate the collective as a whole: adding agents is an architectural choice, not evidence that the resulting system is more reliable or superintelligent.

Forecasts Are Scenarios, Not Delivery Dates

The source’s forecasts span 2027–2035 for AGI, while also citing leader expectations around 2026–2029, a reference by Dario Amodei to powerful systems in late 2026 or early 2027, and Ray Kurzweil’s 2029 prediction. It attributes approximately 25% probability by 2029 and 50% by 2033 to forecasting communities. Such figures require the exact question, resolution criteria, and forecast date to be meaningfully compared.

For ASI, the source gives 1–10 years after AGI, speculation around 2030–2040, and an optimistic scenario of AGI in 2027 followed by ASI in 2028–2030. Skeptical scenarios extend for decades. These are competing expectations, not a consolidated expert schedule.

Compute, data, energy, regulation, geopolitical constraints, embodiment, and alignment can all affect progress. Synthetic data and efficiency improvements might relieve some bottlenecks without removing others. I would not make an infrastructure commitment depend on one forecast winning.

Economic activity is easier to measure than arrival dates. The source attributes $581.7 billion in global corporate AI investment in 2025, $344.7 billion in private AI investment, 88% organizational AI adoption, and 70% of organizations using generative AI in at least one business function to Stanford’s 2026 AI Index. These are investment and adoption indicators, not demonstrations of AGI.

What I Would Build Around Today

For cross-model experiments, a unified API such as CometAPI can simplify access to multiple providers through an OpenAI-compatible interface. That is useful infrastructure for comparing agents and evaluators; it does not resolve differences in capability, reliability, or oversight requirements.

My priorities would be representative task evaluations, explicit success criteria, cost and failure tracking, and human review for consequential actions. I would test long-running workflows as workflows, rather than infer their reliability from single-turn answers. Open benchmarks and safety research are useful complements to those application-specific evaluations.

The distinction I keep is straightforward: AGI concerns broad human-level competence; ASI concerns broad capability beyond human experts. For a system I might deploy now, the decisive question is still what work it completes reliably, under which conditions, and how I detect when it fails.

Originally published at cometapi.com

A Practical Multi-Model Gemini Integration with One API Surface

Dylan Foster — Mon, 21 Sep 2026 02:36:27 +0000

By July 2026, running a production AI feature usually means choosing between several models rather than standardizing on one. Gemini 3.1 Pro may be the right choice for long-context reasoning or multimodal analysis, while another provider may be preferable for latency, price, or a particular capability.

The integration cost is the part I dislike. Native SDKs bring separate authentication flows, payload formats, error models, quotas, dashboards, and billing systems. They also make model fallback harder: application code ends up coupled to provider-specific helpers instead of expressing the actual operation—send messages, receive a completion—in a provider-neutral way.

For this kind of architecture, I use a unified gateway such as CometAPI. It exposes more than 500 models through one endpoint, supports the OpenAI SDK as well as the native Gemini request format, and claims up to 20% savings on input and output tokens compared with official native pricing.

What the Gemini lineup brings

Google’s 2026 model family covers more than text generation:

Gemini 3.1 Pro: the flagship reasoning and long-context model for agentic workflows, document analysis, and code generation. The Gemini 3.1 Pro API guide covers its integration.
Gemini 3.5 Flash: the speed- and cost-optimized option for high-volume, latency-sensitive workloads.
Nano Banana 2 (Gemini 3 Pro Image): an image generation and editing model focused on high-fidelity, prompt-accurate visuals. See the Nano Banana 2 API guide.
Veo 3.1: a text-to-video and image-to-video model that generates video clips with synchronized audio. See the Veo 3.1 API guide.
Gemini Omni: a unified multimodal model that reasons across text, images, audio, and video in one request. See What Is Gemini Omni?.

The appeal of a single access layer is operational as much as technical. Instead of separately provisioning Google Cloud IAM, quotas, and billing for every integration, I can use one API key and base URL. Switching between Gemini 3.1 Pro, Nano Banana 2, Veo 3.1, or models from other providers becomes a model-selection change rather than a client-library migration.

Why native multi-SDK integrations become expensive

Each provider makes different assumptions about:

Authentication and credential management
System instructions
Multimodal content schemas
Error and retry behavior
Rate-limit headers and quota accounting
Response and token-usage formats

Those differences are manageable in a proof of concept. They become expensive when the same product supports multiple models and dynamic routing. Middleware has to normalize requests, translate provider-specific failures, and keep downstream parsing stable. Every new model adds another compatibility surface.

There is also a structural vendor-lock-in problem. If business logic depends on native SDK helpers, moving traffic from one provider to another—or adding a fallback when latency or quotas deteriorate—can require a substantial refactor. Fragmented consoles and invoices make cost attribution harder too, especially when several teams share multiple models.

A gateway does not remove all model differences, but it puts the provider-specific translation in one place. The application talks to a standardized interface; the gateway translates requests for the selected backend and normalizes the response.

Two ways to call Gemini

The unified endpoint is:

https://api.cometapi.com/v1

This is an API base URL for an SDK or HTTP client, not a browser page. The client appends a route such as /chat/completions; opening the base URL directly returns a 404, which is expected and indicates that the server is reachable.

There are two supported calling styles:

OpenAI-compatible: use the OpenAI SDK and set model to a Gemini model.
Native Gemini format: call the generateContent endpoint directly using Google’s request schema.

The native endpoint has this form:

https://api.cometapi.com/v1beta/models/{model}:generateContent

Native requests use the x-goog-api-key header. The native Gemini API quickstart documents that format.

Drop-in usage with the OpenAI Python client

For an existing OpenAI integration, the practical change is usually the base URL, API key, and model name:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.cometapi.com/v1",
    api_key="",
)

completion = client.chat.completions.create(
    model="gemini-3.1-pro",
    messages=[
        {
            "role": "system",
            "content": "You are a helpful technical assistant.",
        },
        {
            "role": "user",
            "content": "How does a unified API endpoint simplify multi-model routing?",
        },
    ],
    temperature=0.7,
)

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

The useful property here is not merely that the request succeeds. The response follows the OpenAI JSON schema, so existing parsing, token accounting, and error-handling wrappers can remain in place.

The same abstraction makes routing logic straightforward:

def complete(client, prompt, model="gemini-3.1-pro"):
    return client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=0.7,
    )

try:
    response = complete(client, prompt, model="gpt-5.4")
except Exception:
    response = complete(client, prompt, model="gemini-3.1-pro")

In a real service I would replace the broad exception with provider-aware handling and add bounded retries, but the important routing decision is just the model parameter.

Multimodal requests use the familiar content shape

Gemini 3.1 Pro can process visual and auditory inputs. Through the OpenAI-compatible interface, media can be supplied either as public URLs or as base64-encoded data embedded in the request.

An image request looks like this:

response = client.chat.completions.create(
    model="gemini-3.1-pro",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": (
                        "Analyze the trends shown in this chart and "
                        "summarize the key takeaways."
                    ),
                },
                {
                    "type": "image_url",
                    "image_url": {
                        "url": (
                            "https://example.com/charts/"
                            "performance-summary.png"
                        ),
                    },
                },
            ],
        },
    ],
)

The gateway translates the image_url structure into the backend-specific format. It does not enhance, compress, or otherwise change Gemini’s multimodal capabilities. Accuracy, latency, and processing limits still come from Gemini 3.1 Pro.

The benefit is downstream consistency: generated text, usage data, and finish reasons can be handled using the same parsing path whether the request is served by Gemini 3.1 Pro or another multimodal model.

The trade-off against direct Google integration

A direct integration with Vertex AI or Google AI Studio has one obvious advantage: fewer network hops and direct access to Google’s infrastructure. If absolute minimum latency is the only metric that matters, native access may be the better choice.

A unified endpoint adds an intermediary hop, although optimized routing is intended to keep the additional latency negligible for most applications. In return, I get several operational advantages:

One invoice for usage across Gemini 3.1 Pro, GPT-5.4, and more than 500 supported models
Centralized usage analytics for tokens, latency, and model-level cost distribution
Fewer production credentials to secure
Easier A/B testing and fallback routing
Up to 20% savings on Gemini input and output tokens compared with official native pricing

The cost and management benefits matter most for high-volume workloads such as large-scale document analysis and continuous agentic workflows. They matter less for a low-volume service where native integration is already simple and the gateway’s flexibility is unnecessary.

Limitations worth designing for

A compatibility layer is not the same thing as identical model behavior.

New features may arrive later

Google can release experimental parameters and provider-specific capabilities before they are represented by a standardized gateway schema. There may be a short propagation delay before those features are available through the translation layer.

If day-one access to Google-specific experimental features is critical, I would retain a native integration for the relevant sandboxed workloads rather than forcing every request through the unified path.

Quotas move to the gateway

When traffic is routed through the unified endpoint, rate limits and quotas are managed there rather than directly in Google AI Studio or Vertex AI. The application should inspect gateway rate-limit headers and implement appropriate backoff and retry behavior.

The centralized quota is simpler to administer, but total token consumption across all active models must be coordinated within that quota.

Schemas are standardized, not identical

Different models still interpret prompts differently. System instructions, temperature bounds, safety thresholds, and other behavior can vary between GPT models and Gemini 3.1 Pro even when the request schema is the same.

For dynamic routing, I recommend:

Validating system prompts against every target model
Avoiding assumptions about parameter ranges
Handling model-specific API errors explicitly
Testing both text and multimodal payloads during failover
Treating output quality as a routing metric, not just latency and price

Migration plan

I would migrate an existing native Gemini integration in three passes.

1. Find provider-specific code

Search for imports and calls from the native Google SDKs, including:

@google/generative-ai
google-generativeai

Then inventory every Gemini call and record parameters such as temperature, top-p, system instructions, safety settings, and media handling. These details are where compatibility issues tend to surface.

2. Move configuration out of code

Store the key in an environment variable such as API_KEY rather than hardcoding it. Keep the base URL configurable too, so routing can change without another application release.

For the OpenAI-compatible client, the relevant configuration is:

import os
from openai import OpenAI

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

3. Add and test routing before removing the native path

Wrap model calls behind an application-level interface. Select the model based on latency, cost, quota, or capability, and test simulated rate limits and API failures.

A migration test suite should verify that the application can fail over from GPT-5.4 to Gemini 3.1 Pro—or in the other direction—without exposing an unhandled exception to the user. It should also validate response parsing, token accounting, and both image and audio workflows across target models.

The quick-start documentation provides the setup sequence, but the important architectural step is keeping the gateway configuration and model choice outside feature code.

Final architecture notes

For a production multi-model application in July 2026, I would separate three concerns:

Application behavior: prompts, tools, business logic, and output validation
Model policy: selection based on capability, cost, latency, and availability
Provider transport: authentication, endpoint formatting, retries, and response normalization

A unified Gemini endpoint is useful when the goal is to keep those layers separate. It lets an existing OpenAI SDK call Gemini 3.1 Pro, exposes the broader Gemini family—including Nano Banana 2, Veo 3.1, and Gemini Omni—and supports native Gemini requests when that schema is preferable.

Native SDKs remain the right escape hatch for immediate access to experimental provider-specific features or for systems where an extra network hop is unacceptable. For most applications that need model switching, centralized billing, multimodal support, and simpler operational management, standardizing the transport layer is the more maintainable choice.

Originally published at cometapi.com

Choosing a Coding Agent Model: Claude Opus 5, GPT-5.6 Sol, or Gemini 3.7 Flash

Dylan Foster — Mon, 21 Sep 2026 01:37:39 +0000

There is no benchmark result that settles this choice for every coding agent.

The published Terminal-Bench 2.1 numbers are close: Claude Opus 5 scores 89% at Max effort, GPT-5.6 Sol scores 88.8% in the reported single-agent run and 91.9% in Ultra, and Gemini 3.7 Flash scores 85.8%. Those results are useful for narrowing the field, but they are not a clean ranking. The reasoning effort, harness configuration, and Ultra's multi-agent setup differ.

For a fixed request containing 20,000 input tokens and 2,000 output tokens, the listed prices are USD 0.018 for Gemini 3.7 Flash, USD 0.120 for Claude Opus 5, and USD 0.128 for GPT-5.6 Sol at its short-context rate.

My production metric would be cost per accepted patch, measured against the same repository tasks, tools, tests, retry policy, and sandbox.

The Short Version

Model	Published coding result	Listed price	Model ID	Main integration routes
Claude Opus 5	Terminal-Bench 2.1: 89% at Max effort	$4/M input, $20/M output; $0.120 for the fixed scenario	`claude-opus-5`	Chat Completions, Anthropic-compatible Messages
GPT-5.6 Sol	Terminal-Bench 2.1: 88.8%; 91.9% Ultra	$4/M input and $24/M output up to 272K input tokens; $8/M input and $36/M output above that; $0.128 for the fixed scenario	`gpt-5.6-sol`	Chat Completions, OpenAI Responses
Gemini 3.7 Flash	Terminal-Bench 2.1: 85.8%	$0.60/M input, $3/M output; $0.018 for the fixed scenario	`gemini-3.7-flash`	Chat Completions, Gemini-native generation

As of August 24, 2026, these are the listed rates. Prices and supported routes can change, so I would recheck the individual model pages and text API documentation before deployment.

The fixed-request calculation follows the provider pricing guide:

20,000 input tokens + 2,000 output tokens

Claude Opus 5:
20,000 * $4/M + 2,000 * $20/M = $0.120

GPT-5.6 Sol:
20,000 * $4/M + 2,000 * $24/M = $0.128

Gemini 3.7 Flash:
20,000 * $0.60/M + 2,000 * $3/M = $0.018

That is token cost only. Retries, tool calls, rejected patches, and long-context pricing can change the economics substantially.

Model-Specific Constraints

Claude Opus 5

Claude Opus 5 is available as claude-opus-5.

Input: text, image, and PDF
Context window: 1M tokens
Routes: Chat Completions and Anthropic-compatible Messages
Price: $4/M input and $20/M output
Fixed scenario: $0.120

I would use Messages when the agent depends on Claude-specific controls. Chat Completions is more useful for a portable harness that switches between providers.

The 89% Terminal-Bench 2.1 result was measured at Max effort. That makes it a strong signal, but the higher output-token price needs to translate into a higher accepted-patch rate.

GPT-5.6 Sol

GPT-5.6 Sol uses the model ID gpt-5.6-sol.

Input: text and image
Routes: Chat Completions and OpenAI Responses
Price up to 272K input tokens: $4/M input and $24/M output
Price above 272K input tokens: $8/M input and $36/M output
Fixed scenario at the short-context rate: $0.128

Responses is the natural route for OpenAI-native agent features. Chat Completions is the better fit for a common comparison harness.

The reported Terminal-Bench results need careful interpretation. The single-agent result is 88.8%. The 91.9% Ultra result uses a multi-agent setup, so I would not compare it directly with a single-agent run.

Gemini 3.7 Flash

Gemini 3.7 Flash uses the model ID gemini-3.7-flash.

Input: text, image, video, audio, and PDF
Context window: 1,048,576 tokens
Routes: Chat Completions and Gemini-native generation
Price: $0.60/M input and $3/M output
Fixed scenario: $0.018

Gemini-native generation makes sense when Google-specific features matter. Chat Completions is more convenient for a shared harness.

The large context window and multimodal input expand the possible test surface, especially for design-to-code workflows. They do not prove that repository navigation or stale-context handling will be good.

What the Other Benchmark Says

Terminal-Bench is not enough to characterize a coding agent. The published DeepSWE v1.1 figures provide another signal:

Evidence	Claude Opus 5	GPT-5.6 Sol	Gemini 3.7 Flash
Terminal-Bench 2.1	89% at Max effort	88.8%; 91.9% Ultra	85.8%
DeepSWE v1.1	73.7%	72.7%	65.3%
Context window	1M tokens	1,050,000 tokens	1,048,576 tokens
20K input + 2K output	USD 0.120	USD 0.128 at short-context rate	USD 0.018

DeepSWE v1.1 measures long-horizon software engineering in real codebases. I would only compare those numbers when the scaffold and evaluation setup match.

Context capacity is also not retrieval quality. A model can accept a million-token repository and still fail symbol discovery, cross-file consistency, or stale-context handling.

Build a Repository-Level Evaluation

A useful comparison requires more than sending the same prompt three times. Pin the repository, expose the same tools, use the same dependency versions and test commands, and enforce the same executable acceptance checks.

I use four task classes because each reveals a different failure mode:

Task	What the agent must do	Acceptance condition
Repair a failing CI build	Read the failure log, trace a dependency or type error through the manifest, source, and tests, then run the affected suite.	CI is green without disabling checks or introducing regressions.
Complete an SDK migration	Update imports, configuration, types, and tests across multiple packages while preserving the public interface.	The full suite passes with no deprecated calls or interface breaks.
Patch a security finding	Follow the vulnerable call path, make the smallest safe change, add a regression test, and explain the risk boundary.	The exploit test fails, the regression test passes, and unrelated behavior is unchanged.
Implement a UI from a reference	Use a screenshot or design-system input, reuse existing components, and update visual or interaction tests.	Functional tests and visual thresholds pass without adding a duplicated component layer.

Keep these variables fixed:

Dependency versions
Tool schemas
Token limits
Retry policy
Execution sandbox
Test commands
Fallback behavior

Disable fallback during the model comparison. Otherwise, a successful patch may be attributed to the wrong model.

The primary result should be accepted-task rate. After that, report:

Tool-call success
Regression count
p50 and p95 end-to-end latency
Total token spend
Cost per accepted patch

Store the repository commit hash, raw responses, tool traces, usage records, and environment details. Without those artifacts, the result will be difficult to reproduce.

Choosing the Primary Model

I would choose Claude Opus 5 when the agent needs Messages-native controls or when its Max-effort performance remains strong on multi-file repository tasks. Its published benchmark result is slightly ahead of GPT-5.6 Sol's single-agent result, but the output price needs to be justified by fewer retries or more accepted patches.

I would choose GPT-5.6 Sol when the agent is built around Responses or when difficult terminal and long-horizon tasks justify the premium. Track the 272K input-token threshold in cost estimates, and keep the Ultra result separate from single-agent measurements.

I would choose Gemini 3.7 Flash when raw token cost, multimodal input, or a 1,048,576-token context window matters. It is the cheapest in the fixed request scenario, but rejected patches and retries can remove that advantage quickly.

One Harness, Multiple Providers

The common path for these three models can use one OpenAI-compatible base URL, one key, and Chat Completions, switching only the model ID:

https://api.cometapi.com/v1

claude-opus-5
gpt-5.6-sol
gemini-3.7-flash

A unified multi-model API such as CometAPI is useful here when the goal is to keep authentication, request plumbing, retries, and usage accounting in one harness.

That does not eliminate provider-specific work. Messages, Responses, and Gemini-native generation expose different semantics and features. If production uses one of those native routes, benchmark that exact route rather than assuming the common path is equivalent.

Model	Common route	Native route	Integration decision
Claude Opus 5	Chat Completions	Anthropic-compatible Messages	Use Chat for common tests; Messages for Claude-specific behavior.
GPT-5.6 Sol	Chat Completions	OpenAI Responses	Use the endpoint that production orchestration actually calls.
Gemini 3.7 Flash	Chat Completions	Gemini-native generation	Use Chat for common tests; native generation for Google-specific behavior.

Cost and Fallback Policy

Raw token price is a shortlisting metric. The production metric is:

cost per accepted patch =
total spend across attempts, tool calls, retries, and rejected patches
/
tasks that pass the acceptance suite

After selecting a primary model, evaluate fallback separately. Retryable failures include rate limits and HTTP 500, 503, 504, and 524 responses. Log which model ultimately served every request.

Invalid requests and authentication failures, including HTTP 400 and 401, should be fixed rather than rerouted.

Practical Answers

Is Claude Opus 5 better than GPT-5.6 Sol?

Their published Terminal-Bench 2.1 results are close: 89% for Claude Opus 5 at Max effort, versus 88.8% for GPT-5.6 Sol in the cited single-agent run and 91.9% in Ultra's parallel-agent setup.

Use Claude when Messages-native controls matter. Use GPT when Responses-native orchestration matters. For quality, rerun the same repository tasks because the published settings are not identical.

Is Gemini 3.7 Flash production-ready for coding agents?

It can be, if it passes the repository's acceptance gate. Its published results are 85.8% on Terminal-Bench 2.1 and 65.3% on DeepSWE v1.1, with the lowest raw token price in this comparison.

Measure accepted-patch rate, regression count, tool-call validity, latency, and retry rate before deploying it.

Which model has the best price-to-performance ratio?

There is no universal answer. Start with Gemini 3.7 Flash if raw token cost is the dominant constraint, then calculate total spend per accepted patch.

Claude Opus 5 or GPT-5.6 Sol can still be cheaper per successful task if they require fewer retries or produce fewer rejected changes.

Which is better for large repositories?

Claude Opus 5 lists a 1M-token context window, while Gemini 3.7 Flash lists 1,048,576 tokens. GPT-5.6 Sol lists 1,050,000 tokens.

Those capacities do not establish repository performance. Test symbol discovery, cross-file consistency, stale-context handling, and full-suite pass rate on the same pinned codebase.

Is GPT-5.6 Sol more expensive than Gemini 3.7 Flash?

For the fixed 20K input and 2K output scenario, GPT-5.6 Sol costs USD 0.128 at its short-context rate, compared with USD 0.018 for Gemini 3.7 Flash. GPT-5.6 Sol also moves to a higher rate above 272K input tokens.

The relevant comparison remains cost per accepted patch, not token price alone.

Can one coding-agent infrastructure switch among all three?

Yes, for the common Chat Completions path. The harness can retain one client and key while changing the model ID. Claude Messages, OpenAI Responses, and Gemini-native features require route-specific request handling.

That distinction should be reflected in the evaluation: compare the common route for portability, and benchmark native routes separately when they are part of the production design.

Originally published at cometapi.com

GPT-5.6 vs Claude: I’d Benchmark the Whole Coding Route, Not the Token Price

Dylan Foster — Fri, 18 Sep 2026 17:07:36 +0000

The coding model I want in production is the one that gets an accepted patch through validation at the lowest total cost. That includes failed attempts, escalation, tool execution, and reviewer time. A cheap response that creates another debugging session is not a cheap result.

GPT-5.6 and Claude both offer enough tiers to make routing worth evaluating. Luna and Haiku cover lightweight work; Terra and Sonnet are general coding candidates; Sol, Opus, and Fable belong in harder-task evaluations. Those are starting points, not equivalent capability classes. The specific model names, benchmark results, and prices below are the source article’s reported figures; verify current provider documentation before using them in a budget or deployment.

Start With an Accepted Task

I would track this metric before optimizing token spend:

Cost per successful task =
  (primary model cost + retry cost + fallback cost
   + tool cost + human review cost) / successful tasks

The denominator matters. Expected API spend per submitted task is not automatically cost per successful task: some tasks can still fail after escalation. Record first-pass success and final success separately, then account for everything spent on unsuccessful attempts too.

For each task, I would log model and effort level, input and output usage, cache reads and writes, tool calls, retries, escalation, end-to-end latency, and human review minutes. Model-and-effort combinations are the unit of comparison. Higher reasoning effort only earns its additional spend when it improves acceptance or reduces downstream correction.

Build a Shortlist, Not a Benchmark Leaderboard

The comparison attributed to OpenAI’s GPT-5.6 evaluation reports these results:

Model	Artificial Analysis Coding Agent Index v1.1	SWE-Bench Pro
GPT-5.6 Sol	80	64.60%
GPT-5.6 Terra	77.4	63.40%
GPT-5.6 Luna	74.6	62.70%
Claude Fable 5	77.2	80.00%
Claude Opus 4.8	72.5	69.20%

Sol leads the Coding Agent Index in this table; Fable leads SWE-Bench Pro. The source also reports different results across DeepSWE and Terminal-Bench 2.1. I would use that disagreement to broaden an eval, not declare an overall winner. Harnesses, available tools, reasoning settings, and execution environments all affect coding-agent performance.

My initial lightweight candidates would be Luna and Haiku 4.5 for classification, routing, and simple explanations. For repository Q&A, tests, reviews, and scoped fixes, I would compare Terra and Sonnet 5, escalating to Sol or Opus 4.8. Multi-file refactors justify testing Sol or higher-effort Sonnet first, with Opus or Fable as additional candidates. For architecture migrations and security-sensitive changes, stronger models do not remove the need for human review.

Put the Rates in One Place

These are the source’s reported prices in dollars per million tokens. GPT-5.6 figures are for Standard short-context requests; long-context, Batch, Flex, and Priority processing have separate rates. Check the applicable service tier in the OpenAI pricing documentation.

Model / period	Input	Cached read	Cache write	Output
GPT-5.6 Luna	$1.00	$0.10	$1.25	$6.00
GPT-5.6 Terra	$2.50	$0.25	$3.13	$15.00
GPT-5.6 Sol	$5.00	$0.50	$6.25	$30.00
Haiku 4.5	$1.00	$0.10	$1.25 / $2.00	$5.00
Sonnet 5, through Aug. 31, 2026	$2.00	$0.20	$2.50 / $4.00	$10.00
Sonnet 5, from Sept. 1, 2026	$3.00	$0.30	$3.75 / $6.00	$15.00
Opus 4.8	$5.00	$0.50	$6.25 / $10.00	$25.00
Fable 5	$10.00	$1.00	$12.50 / $20.00	$50.00

Claude’s two write prices correspond to five-minute and one-hour caches. Sonnet’s introductory $2 input / $10 output pricing runs through August 31, 2026; the reported standard $3 / $15 rates begin September 1.

On headline rates, introductory Sonnet is cheaper than Terra. Haiku matches Luna’s input price and charges $5 rather than $6 for output. Opus matches Sol’s $5 input price and charges $25 rather than $30 for output. After Sonnet’s pricing transition, Terra has cheaper input at $2.50 versus $3, with both charging $15 for output. None of those comparisons includes reliability or actual token consumption.

Token Counts Are Part of the Price

I would not apply one provider’s token estimate to another provider’s bill. The source attributes to Anthropic a newer tokenizer in Sonnet 5, Fable 5, and newer Opus models that can produce approximately 30% more tokens for the same text, depending on workload. Log returned usage rather than assuming identical token counts.

There is also a model-selection trap: the source states that the generic gpt-5.6 alias maps to Sol. Where Terra or Luna passes the eval, select that tier explicitly instead of allowing an alias to determine flagship usage.

Work Through the Fallback Arithmetic

Assume each attempt consumes 80,000 input tokens and 10,000 output tokens, without caching. There is one primary attempt and a stronger fallback when it fails. This is a pricing illustration, not measured model performance; tokenization, tool use, effort, and actual success rates can change the result.

Route	Primary attempt	Fallback attempt	Expected API spend with 25% fallback
Terra → Sol	`0.08 × $2.50 + 0.01 × $15 = $0.35`	`0.08 × $5 + 0.01 × $30 = $0.70`	`$0.35 + 0.25 × $0.70 = $0.525`, about $0.53
Introductory Sonnet → Opus	`0.08 × $2 + 0.01 × $10 = $0.26`	`0.08 × $5 + 0.01 × $25 = $0.65`	`$0.26 + 0.25 × $0.65 = $0.4225`, about $0.42
Standard Sonnet → Opus	`0.08 × $3 + 0.01 × $15 = $0.39`	$0.65	`$0.39 + 0.25 × $0.65 = $0.5525`

At equal fallback rates, introductory Sonnet wins this example; Terra becomes slightly cheaper after the reported September 1 change. But reduce Terra’s fallback rate to 10% and its expected spend becomes $0.35 + 0.10 × $0.70 = $0.42. That is slightly below introductory Sonnet’s unrounded $0.4225 and below standard Sonnet’s $0.5525. Rounding both introductory results to cents hides the first difference.

I would not call any row a production winner yet. These figures exclude tools and review, assume identical usage on primary and fallback attempts, and do not establish whether the fallback succeeds.

Measure Cache Reuse Alongside Escalation

The source describes OpenAI matching prompt prefixes through implicit caching, with GPT-5.6 additionally supporting explicit breakpoints and prompt_cache_key. It gives cache writes a 1.25× normal-input rate and reads the discounted cached-input rate.

Claude caching is enabled through cache_control, using a request-level automatic breakpoint or explicit content-block breakpoints. Its default lifetime is five minutes, with an optional, more expensive one-hour write. Reads cost 0.1× the base input rate. These implementation differences matter when repository instructions, tool definitions, coding standards, or project context recur across calls.

For the Terra example, serving 40,000 of the 80,000 input tokens from cache changes a subsequent request to $0.10 regular input + $0.01 cached input + $0.15 output = $0.26, down from $0.35. Writing that 40,000-token prefix instead gives $0.375 for the request using the stated 1.25× multiplier. The displayed $3.13/MTok write price is rounded; the multiplier corresponds to $3.125/MTok.

Caching pays through reuse, not necessarily on the first request. I would measure writes, reads, retries, and fallback together. A lower input bill cannot rescue a route that repeatedly produces unusable patches, and context-window capacity alone says little about effective task cost.

Run a Small Repository Eval Before Building a Clever Router

Around 30 representative tasks is a practical first pass: 10 bug fixes, 10 implementation or test-generation tasks, 5 refactors, and 5 reviews. Compare Terra, Sol, Sonnet 5, and Opus 4.8 where they fit the workload. Add Luna and Haiku for lightweight subtasks, and Fable as a higher-capability reference for difficult work.

Keep acceptance criteria identical: passing tests, successful builds, lint and type checks, resolution of the requested issue, and the amount of human correction required. Parser or AST checks, pytest, npm test, and isolated patch execution provide useful automatic validation. They make cheaper-first routing testable; they do not prove every change correct.

Segment results by task class. A model that is economical for reviews may be a poor default for bug fixes. Track first-pass and final success, total API spend, retries, fallback frequency, cache-hit rate, latency, and review time. Otherwise, an aggregate average can conceal exactly the workload distinction the router needs.

Keep the First Router Rule-Based

My starting policy would be: classify the task, choose the lowest-cost route that passes the relevant eval, validate, then escalate on failure. A candidate sequence is Luna or Haiku → Terra or Sonnet → Sol or Opus → Fable or human review. That is an evaluation hypothesis, not a requirement to traverse every tier.

High fallback rates suggest strengthening the initial route. Premium calls that rarely improve acceptance suggest reducing escalation. Extra effort without better outcomes suggests lowering effort. Repeated context dominating spend suggests improving cache reuse. For security-sensitive or architectural work, I would require human review rather than treating automatic checks as sufficient.

A unified interface can reduce integration work when comparing providers: CometAPI exposes supported models through an OpenAI-compatible Chat Completions interface, allowing model selection through the model parameter. That simplifies switching, but it does not replace provider-specific usage accounting or quality evaluation.

The deployment decision I care about is specific: which route delivers accepted changes for this task class, at an acceptable latency, with the lowest combined API, execution, and review cost? Public benchmarks identify candidates. Production telemetry decides which ones stay.

Originally published at cometapi.com