DEV Community: hopbase

How to Reconcile LLM API Usage and Allocate Costs by Department: A Reproducible Method

hopbase — Wed, 28 Oct 2026 18:42:25 +0000

The short answer: reconciling an LLM API bill takes three layers of data you can recompute yourself, not a vendor's promise of "transparent billing". Layer one is the individual task: on HopBase, once a video or asynchronous image task finishes, its query response carries usage.cost_usd, the amount actually deducted from your balance for that task; an uncharged failure reports 0, and one curl command checks it. Layer two is the itemised record: the console Usage page exports a CSV filtered by date, key, member, department or key creator, and every row carries the official cost, discount, exchange rate and charged amount to verify official cost × discount ÷ exchange rate = charged amount line by line. Layer three is allocation: every key shows its creator, per-key spending charts exist, department managers see and manage their own department's keys and usage, and quotas can be set per key, member and department. With all three in place, a department chargeback is just a filter and an export.

Why LLM bills are hard to reconcile

A company that runs chat, image and video models at the same time deals with at least four billing units: tokens for chat, images for most image models, seconds or video tokens for video, and flat per-call fees for a few others. Add a handful of practical problems and the numbers stop lining up:

Asynchronous tasks are priced when they end. A video submission only carries an estimate; the real charge is known once the task finishes, and vendors differ on whether and how much a failed task costs.
Failed requests. A failed request is normally free, but when the client disconnects after output has already been generated, the generated part is usually billed. If the bill does not say so, you get the classic "it errored and I was still charged" dispute.
Currencies. Official list prices are mostly in US dollars while the account balance may be kept in another currency. Without the exchange rate in between, nobody can recompute the charge.
Shared keys. Once several projects share one key, nobody can tell afterwards who spent what.

So the goal is concrete: every charge should trace back to a task or request, a key, the person who created that key and a department, and the amount should be recomputable from published list prices.

Layer 1: the actual charge, straight from the task query

Once an asynchronous task (video, async image and so on) is completed, failed or cancelled, the single-task query response gains a top-level usage object:

usage.cost_usd is the amount actually deducted from your USD balance for that task — the same number as in the usage record;
usage.cost is the same charge expressed in CNY, and usage.currency names the currency of cost (always CNY) — reconcile against cost_usd;
a failed task that was not charged reports 0; in the rare case an image task fails after its charge was settled (for example, the model returned no usable image), it reports the real charge;
the field is absent while the task is running, and only the key that created the task sees it.

It applies to GET /v1/video/tasks/{task_id} (Seedance, Grok Imagine, Kling, MiniMax, Midjourney), GET /api/v1/tasks/{task_id} (Wan, HappyHorse) and GET /v1/images/tasks?task_id=... (GPT Image and Gemini image async tasks). Checking it takes one command:

# Query with the key that submitted the task; jq keeps only status and cost
curl -s https://api.hop-base.com/v1/video/tasks/$TASK_ID \
  -H "Authorization: Bearer $HOPBASE_API_KEY" \
  | jq '{status: (.task.status // .status), usage}'

# Once the task has finished you get something like (amount illustrative):
# { "status": "completed", "usage": { "cost_usd": 0.35, "cost": 2.4, "currency": "CNY" } }

In a Seedance response, task.usage is the billable token count and the top-level usage.cost_usd is the money — do not mix them up. For MiniMax and Wan, which already return a top-level usage, cost_usd, cost and currency are merged into it. The practical benefit: your own system can write the real charge into its order or job record the moment the task ends, instead of polling the console or booking the submission estimate as cost.

Layer 2: itemised records you can recompute row by row

Synchronous chat requests create no task and their responses carry token counts only, so the money lives in the usage records. The export button on the console Usage page downloads a CSV that follows the filters on the page (date range, key, member, department, key creator), up to 50,000 rows and 400 days per file. Each row has nine columns:

time, model, usage;
official list-price currency, official cost in that currency;
discount, exchange rate, charged amount in the balance currency;
note.

Read left to right, four of those columns are the verification formula itself: official cost × discount ÷ exchange rate = charged amount. When the list-price currency and the balance currency are the same, the exchange-rate cell is empty and the formula becomes official cost × discount = charged amount. You can compute the official cost from the vendor's own price page, and the discount is the one on your account, so every row can be checked independently without trusting anyone's totals. Early records without a list-price snapshot leave those columns empty.

Failed requests are noted as "Request failed, not charged"; a request interrupted after output was generated is noted as "Request interrupted, charged for the usage already generated", and the end of the file counts both. Those are exactly the rows that cause disputes, so stating the rule in the record beats explaining it afterwards. For automation, GET /v1/usage with an API key returns the balance and that key's quota usage.

Layer 3: allocating by key and by department

Allocation starts with one key per cost centre. HopBase enterprise accounts have members and departments, and a few facts decide whether allocation actually works:

Every key shows its creator. Keys a member created and keys the owner or a department manager created and assigned to a member stay distinguishable, and exports can filter by creator.
Spending charts per key. The console shows spending trend, request count and model mix per key, so unusual spend points straight at a key.
Department manager scope. A department manager sees and manages the keys and usage of members in their own department, can create keys for those members, and cannot see other departments. The owner sees the whole company. When a member moves department, the scope follows.
Layered quotas. Quotas can be set per key, per member and per department, and hitting any of them blocks the request with a 402 whose message says whether the key, member or department quota ran out — not a vague "insufficient balance".

A monthly department chargeback is then: pick the department and the month on the Usage page, export. Each department gets its own itemised file and can recompute it with the formula above.

A reconciliation checklist you can use on any vendor

After an async task ends, can you get its actual charge from the API — not an estimate or a base cost?
Can you export itemised records with official cost, discount and exchange rate, and recompute each row?
Are failed requests and "interrupted after output was generated" requests labelled separately?
Does every amount state its currency, and is the exchange rate visible when list-price and balance currencies differ?
Can you filter exports by key, member and department, and does each key record its creator?
Can quotas be layered, and does a quota error tell you which layer ran out?
Are you actually getting the model you pay for? Test that yourself with our model fidelity verification method.

Every item can be checked with curl or an export file, which makes the list usable against any vendor — including us.

FAQ

Is usage.cost_usd in the task query the same as the charged amount in the console?

Yes. usage.cost_usd is the charged amount from that task's usage record — the amount by which your balance actually went down — so you can match it one-to-one against the exported records.

Why is there no usage.cost_usd while the task is still running?

The final charge of an async task is only known when it ends; any number returned earlier could only be an estimate. The field therefore appears once the task is completed, failed or cancelled. While it runs, keep polling as before.

Are failed tasks charged?

Failed video tasks are never charged, and the query reports usage.cost_usd as 0. In rare cases an image task fails after its charge was settled; the query then reports the real charge, and the same amount appears in your usage records. Failed synchronous requests are free; a request interrupted after output was generated is charged for what was generated and labelled as such in the export.

Why does another key not see the cost of my task?

The cost is returned only to the key that created the task. That keeps the "one key per cost centre" boundary intact and stops other keys on the same account from seeing spend that is not theirs.

Do chat requests have a per-request amount too?

Chat responses carry token counts but no amount. The per-request amount is in the console usage records, the CSV export lets you recompute each row, and filtering plus export gives you totals per key or department.

Originally published on the HopBase blog.

How to Benchmark LLM API Performance: TTFT, Streaming Stability, and a Reproducible Method

hopbase — Wed, 28 Oct 2026 18:38:23 +0000

The short answer: LLM API performance comes down to three measurable things — the P95/P99 distribution of time-to-first-token (TTFT), streaming stability (the share of long outputs that finish without a silent mid-stream cutoff), and how prompt-cache hits amplify both speed and cost. Total latency and averages will mislead you: generation time is dominated by output length, and a mean hides the tail your users actually feel. A useful benchmark is boring on purpose — a fixed prompt set, temperature 0, at least 30 runs in one time window, percentiles instead of averages, and the same test repeated against the vendor's official API in the same window. Performance should not be an adjective on a vendor page; it should be a number in your terminal. The method below starts from a single curl command and is fully reproducible.

Why total latency is a bad metric

Total generation time is dominated by output length: 2000 words take ten times longer than 200 regardless of link quality. In streaming, what users actually feel is two things: when the first token arrives (TTFT), and whether tokens keep flowing steadily after it. TTFT is the true link metric — it contains the entire overhead of ingress, gateway scheduling, and provider-side queueing.

Read distributions, not means

Averages hide the tail: 90 requests at 1s plus 10 at 8s average to a decent-looking 1.7s, yet every tenth user hits 8 seconds. A fat P95/P99 means queueing or retries — one of the engineering-quality criteria in the fidelity test. Discipline: fixed prompt, temperature 0, at least 30 consecutive runs in one time window, then read percentiles.

Truncation rate: the most ignored metric

A silent mid-stream cutoff on long output is the worst failure mode in streaming: you get half the content and no error code. The test is simple — request long outputs (say 2000 words), repeat N times, and measure the share of streams that finish cleanly with a proper SSE termination. A channel with a high truncation rate makes any TTFT number meaningless.

Cache hits: performance and cost are the same coin

On a prompt-cache hit, input is billed at a discount and TTFT drops visibly — performance and cost are one thing here. Hit rate depends on routing topology: requests must land on the same backend account, so randomly routed traffic converges toward zero. How affinity scheduling preserves hit rates under load: our high-concurrency engineering notes; the billing mechanics: the prompt cache guide.

Error codes and retry behavior

An easily missed item: does the gateway pass the model provider's error codes through untouched? A channel that swallows 429s and turns them into timeouts breaks your backoff logic and collapses under peak load. Test it by deliberately triggering rate limits or invalid parameters and comparing behavior with official docs.

A benchmark that starts with one command

TTFT is measurable with plain curl (with streaming on, time_starttransfer is the first-chunk arrival):

curl -N -s -o /dev/null \
  -w "TTFT %{time_starttransfer}s | total %{time_total}s\n" \
  https://api.hop-base.com/v1/chat/completions \
  -H "Authorization: Bearer $HOPBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-luna","stream":true,"messages":[{"role":"user","content":"Introduce yourself in one sentence"}]}'

Swap in any model ID your key returns from GET /v1/models. Loop it 30 times, repeat during peak hours, and you have P95 and jitter. Full discipline: fixed task set, temperature 0, drop the first cold run, retest across time windows, and always compare the vendor's official API against the service under test in the same window.

How we instrument ourselves

HopBase records model, usage, latency, and status for every request — the same trail that powers billing audits powers our performance monitoring; resident probes continuously test every channel so anomalies are handled before users notice. That is why we publish the method: the numbers you measure and the numbers we watch come from the same link.

FAQ

What counts as a good TTFT?

Absolute values depend on model, region, and ingress. What is comparable is a same-window A/B against the vendor's official API — the gap and the stability of the distribution say more than any absolute number.

Is a gateway slower than going direct?

The fixed cost of one extra hop is milliseconds; the gains from less queueing and cache hits are hundreds of milliseconds to seconds. Run both sides with the method above and let the numbers decide — no need to trust anyone.

How do I keep noise out of the test?

Temperature 0, fixed prompts, N of at least 30, drop cold starts, retest across windows — and never compare across different time windows, or provider-side time-of-day swings will masquerade as gateway differences.

For enterprise onboarding and comparative benchmarks, contact us; integration details in the docs.

Originally published on the HopBase blog.

How to Verify Your LLM API Provider Isn't Swapping Models: A Reproducible Fidelity Test

hopbase — Wed, 28 Oct 2026 18:34:19 +0000

The short answer: you can verify whether an API channel swaps models or degrades quality with three families of reproducible checks — cost-structure checks (prompt-cache behavior cannot be faked economically), behavioral-boundary checks (model families leak their identity at the edges), and blind quality benchmarks (fixed task sets, real sample sizes). Any provider that does not welcome these tests has answered your question already.

The biggest anxieties when buying LLM API access from any third-party provider or aggregator: is the model real, is it silently degraded, and where does my data go. The market's usual answer is a promise — "no routing, no degradation, no swapping." Promises are unverifiable; methods are verifiable. We have run these checks continuously for two years; this is the public version of our internal methodology. Use it on any channel — including us.

Step 0: stop asking the model what it is

One system prompt makes any model claim any name — and official models routinely misreport their own version anyway. Identity must be verified by behavior, not self-declaration.

Check 1: prompt-cache economics (hardest to fake)

Claude and GPT prompt caching has an officially defined billing structure: cache writes carry a premium, cache reads are discounted, and cache_read_input_tokens is visible in usage. That is a built-in polygraph:

Repeat requests with the same long system prompt — from the second call you should see stable cache hits (high read-token share, faster first token);
Services that randomly route your traffic show dramatically lower or zero hit rates, because your requests land on different accounts and machines;
Hit rates map to real money. Faking them long-term means the channel subsidizes you — economically unsustainable.

Check 2: model-family hard boundaries

Every model family has boundaries it cannot hide: the real context-window limit (push near-limit inputs and watch truncation behavior), tokenizer differences (token counts for identical text differ systematically across families — compare against usage), parameter surface (unsupported parameters should error or be ignored exactly as the official API does), and stop-sequence / stream-chunking habits. No single item is proof; the combined fingerprint is very hard to fake completely.

Check 3: injection traces

Some channels inject their own instructions around your system prompt — identity rewrites, ads, constraints. Detect by controlled comparison: run the same request set against the vendor's official API and the service under test, and compare obedience details on instruction-recall and role-boundary tasks. We have seen everything from one-line disguises to 4KB injected blocks; all of them show up under A/B contrast.

Check 4: blind degradation testing (sample size matters)

"It feels dumber" is not evidence — output variance is large even on the official API. The credible protocol: fix 20-50 tasks with objective answers (code completion, multi-step reasoning, instruction following), run both channels at temperature 0, compare pass rates, and re-test across weeks to catch time-of-day model swaps. Only a gap that persists beyond noise is a finding.

Check 5: engineering quality

The model can be real while the pipe is bad: look at first-token latency distribution rather than the mean (jittery P95 = unstable path), mid-stream truncation rates on long outputs (silent truncation is the worst failure mode), and whether the model provider's error codes pass through (services that swallow 429/529 into timeouts destroy your retry logic).

Why we publish this

Because this is the bar HopBase holds itself to — every route we offer is tested this way before it goes live, and anything that fails is rejected. And because our pricing page labels each plan's channel attributes in public. Transparent channel provenance plus reproducible verification beats a hundred repetitions of "we never swap." Run every check in this article against us.

For enterprise onboarding evaluation, talk to an advisor; integration details are in the docs.

Originally published on the HopBase blog.

Midjourney v8.2 API: Async Calls, 4-Image Jobs, --ar/--hd Sizes and Per-Image Cost

hopbase — Wed, 28 Oct 2026 18:33:27 +0000

Midjourney v8.2 (model ID midjourney-v8-2) is now live on HopBase, submitted over the OpenAI-compatible POST /v1/images/generations endpoint and polled for results with GET /v1/video/tasks/{task_id}. The biggest difference from most image models is that every job returns a fixed set of 4 candidate images, and aspect ratio and quality are written into the prompt (--ar sets the ratio, --hd renders at native 2K) instead of being passed as request fields. Billing follows the number of images actually returned: $0.0067 per image at 1K and $0.0108 per image at 2K. Check that your key can see it with GET /v1/models.

How to call it

Two-step async: POST /v1/images/generations returns 202 with a task ID, then you poll GET /v1/video/tasks/{task_id}. Status moves through queued → processing → completed, and only completed and failed are terminal.
Use the full model ID: midjourney-v8-2. The authoritative ID is whatever GET /v1/models returns.
Key access: Midjourney is enabled per API key; if midjourney-v8-2 is not in your key's GET /v1/models list, enable it in the console first.
A prompt is required: sending a reference image with no text description is rejected. At most 1 reference image, passed in the images field.
Output lifetime: on completion outputs carries 4 signed links, valid for 24 hours from the moment the task completes. Polling again returns the same links without extending them, and expired links return 410, so download inside that window.
Timeouts are free: a task still unfinished 2 hours after creation is marked failed and not billed.
Actual charge per task: once the task is terminal, the task query carries usage.cost_usd, the amount actually deducted, so you can reconcile cost per job in code.

Pricing: the official rate converted to a per-image price

Tier	How to trigger	Per image	Per job (4 images)
Standard	Default	$0.0067	$0.0267
2K	Add `--hd` to the prompt	$0.0108	$0.0433

Midjourney prices officially by GPU time (0.8 GPU minutes for a standard job, 1.3 minutes with --hd), and we convert that official rate into a per-image price. Billing follows the number of images actually returned, so a single call costs four images' worth — put that in your budget model rather than estimating from a one-image price. To compare against single-image models, multiply their per-image price by the number of candidates you would otherwise generate — see live pricing at https://hop-base.com/pricing. The console itemises the actual cost of every request.

Aspect ratio and size

Size is not a request field; it comes from --ar in the prompt, and adding --hd renders at native 2K. Measured values:

`--ar`	Standard	With `--hd`
1:1 (default)	1024 × 1024	2048 × 2048
16:9	1456 × 816	2944 × 1648
9:16	816 × 1456	1648 × 2944
4:3	1232 × 928	2544 × 1904
21:9	1680 × 720	3376 × 1440

--ar only accepts integer ratios, so --ar 1.5:1 is rejected. The ceiling is 14:1, tightened to 4:1 once --hd is on.

Parameter support

Supported: --ar, --hd, --s (0-1000), --c (0-100), --weird (0-3000), --iw (0-3), --sref with --sw, --no, --seed, --tile, --exp.
Not supported on v8.2, rejected with 400 at submit: --q/--quality, --niji, --repeat, --oref, --cref, --stealth, --stop, --draft, and :: multi-prompt weighting.

We reject this set at submit time rather than forwarding it: some of these the model silently ignores (you pay and get nothing for it), and the rest only fail after the job has run for tens of seconds. The error message names the parameter and why it is not supported.

Three-minute integration

# 1. Submit; returns 202 plus a task ID
curl https://api.hop-base.com/v1/images/generations \
  -H "Authorization: Bearer sk-your-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"midjourney-v8-2","prompt":"a red apple on a wooden table, studio light --ar 16:9"}'

# 2. Poll with the id from the previous step; once completed, take the 4 links from outputs (valid 24 hours)
curl https://api.hop-base.com/v1/video/tasks/YOUR_TASK_ID \
  -H "Authorization: Bearer sk-your-key"

FAQ

Can I generate just one image?

No. Every Midjourney generation mode returns a fixed 2×2 grid of four candidate images. That is how the model itself works, not a restriction added on our side. Neither the image-count field in the request nor --repeat changes the result, which is why we do not accept any value of n other than 4 — better to say so at submit time than to silently charge you for four.

How do I control the size?

In the prompt: --ar sets the ratio and --hd renders at native 2K. The quality field in the request body has no effect on this model and is rejected if you send it. The full size table is above.

Does it support reference images?

Yes — at most 1, passed in the images field, with --iw (0-3) to tune how strongly it is followed; for style references, use --sref together with --sw. Note that v8.2 does not support --oref or --cref; Midjourney has replaced them with its new editing models.

Are failed jobs billed?

No. Only jobs that actually produce images are billed; failed jobs cost nothing. If a prompt is stopped by content moderation the response gives an explicit failure reason, so you can rewrite it and retry.

Cost in code: budgeting a batch

PER_IMAGE = {"1k": 0.0067, "2k": 0.0108}   # official list price, USD per returned image
def batch_cost(jobs: int, tier: str = "1k") -> float:
    return jobs * 4 * PER_IMAGE[tier]        # every job returns 4 images

print(batch_cost(500))        # 500 standard jobs -> ~$13.40
print(batch_cost(500, "2k"))  # 500 --hd jobs     -> ~$21.60

Full parameter reference and error codes: Midjourney v8.2 docs. Live list prices for every model: hop-base.com/pricing. Originally published on the HopBase blog.

GPT-5.6 vs Claude Sonnet 5 for Coding: Practical Differences in Chinese-Language Codebases

hopbase — Wed, 28 Oct 2026 18:29:25 +0000

"Should I use GPT or Claude for coding?" We hear this question more than any other. As a gateway serving both model families to developer teams every day, we see where their behavior actually differs. This isn't a benchmark shootout — just what actually matters for your choice.

Two Different Personalities

Claude Sonnet 5 excels at engineering consistency across large codebases: when you're modifying a feature in a big repo, it reads the surrounding code first, keeps changes aligned with the existing style, and rarely decides to "helpfully" refactor things. Paired with Claude Code's agent mode, multi-file tasks complete much more reliably.

GPT-5.6 excels at single, explosive performance: algorithm problems, standalone utilities, scripts from scratch — it delivers fast and accurate. It's also better at "guessing intent" from vague specs. Paired with Codex CLI, the experience is buttery smooth.

Chinese Language Differences

Both models handle Chinese comprehension fine at this point. The difference is in output habits: Claude tends to continue in the same comment style as your code; GPT is bolder about converting Chinese requirement descriptions into English identifier names. If your team requires Chinese comments and commit messages, Claude's "compliance" will save you revision cycles.

Token Consumption and Real Cost

In equivalent multi-turn coding sessions, Claude accumulates much longer context, but cache hits afterward slash input costs dramatically — look at actual spend after caching, not just list prices.
GPT typically needs shorter context for similar tasks, so per-turn is cheaper, but agent-style multi-turn loops might iterate more times.
For batch and offline jobs where latency doesn't matter, picking the economy tier saves more than switching models.

A worked example at list price

One agent turn with a 50K-token context, of which 40K is a cached prefix, and 3K output tokens (official list prices per million tokens: claude-sonnet-5 $2 input / $0.20 cached / $10 output; gpt-5.6-sol $4 / $0.40 / $20):

claude-sonnet-5: 10K × $2/M + 40K × $0.20/M + 3K × $10/M = $0.020 + $0.008 + $0.030 = $0.058
gpt-5.6-sol:     10K × $4/M + 40K × $0.40/M + 3K × $20/M = $0.040 + $0.016 + $0.060 = $0.116

Claude also bills a one-time cache write when the prefix is first stored, so short sessions benefit less. The real comparison is total spend per finished task: a model that needs fewer turns can win even at a higher per-token rate. Prices change — check live pricing at https://hop-base.com/pricing before you budget.

Our Recommendation

Large repo daily iteration, strong engineering discipline: Claude Sonnet 5 + Claude Code.
Standalone scripts, algorithms, rapid prototypes: GPT-5.6 + Codex.
Still unsure? Take the same task, run it against both models, and your repo is the only benchmark that matters.

Run the same task against both

Claude speaks the Anthropic Messages protocol and GPT the OpenAI protocol, so an A/B test is two calls with the same prompt:

PROMPT='Add input validation to parse_order() in orders.py; keep the existing Chinese comment style.'

# Claude Sonnet 5 (Anthropic Messages)
curl https://api.hop-base.com/v1/messages \
  -H "x-api-key: $HOPBASE_API_KEY" -H "anthropic-version: 2023-06-01" -H "Content-Type: application/json" \
  -d "{\"model\":\"claude-sonnet-5\",\"max_tokens\":2048,\"messages\":[{\"role\":\"user\",\"content\":\"$PROMPT\"}]}"

# GPT-5.6 Sol (OpenAI Chat Completions)
curl https://api.hop-base.com/v1/chat/completions \
  -H "Authorization: Bearer $HOPBASE_API_KEY" -H "Content-Type: application/json" \
  -d "{\"model\":\"gpt-5.6-sol\",\"messages\":[{\"role\":\"user\",\"content\":\"$PROMPT\"}]}"

Compare the diffs, then compare the usage blocks: token counts × list price is your real cost per answer. Newer generations (Claude Sonnet 5.5, GPT-6 Sol) have since launched at similar or lower list prices, and the same method applies to them. Run GET /v1/models first to see which IDs your key can call.

Someone else's benchmark can't replace your codebase.

Setup guides: Claude Code · Codex CLI · live pricing. Originally published on the HopBase blog.

Claude Fable 5.1 API: 1M Context, $0.25/M Cache Reads and Migrating from Fable 5

hopbase — Wed, 28 Oct 2026 18:25:21 +0000

Anthropic's newest flagship, Claude Fable 5.1 (model ID claude-fable-5-1), is available through the HopBase API over the native Anthropic Messages protocol. If your key already calls Claude, switching is a one-line model-name change; confirm with GET /v1/models.

Model specs

1M context window, 128K max output: whole repositories, long documents, and long multi-turn conversations fit in a single request, with no need to split long outputs.
Adaptive thinking, always on: no thinking parameter needed; steer reasoning depth and spend with output_config.effort (low through max).
Built for long-horizon agent work: stronger than Fable 5 at long-running autonomous coding, document / spreadsheet / slide work, multi-step research, vision, and computer use. Same tokenizer as Fable 5, so token counts are essentially unchanged.
Native Anthropic Messages API: standard /v1/messages; the Anthropic SDK and Claude Code switch over with zero code changes.

Pricing: official list price

Item (per million tokens)	Claude Fable 5.1	Claude Fable 5
Input	$10	$10
Output	$50	$50
Cache write (5 min / 1 hour)	$12.50 / $20	$12.50 / $20
Cache read (hit)	$0.25 (0.025×)	$1.00

Cache reads cost a quarter of Fable 5's, so long sessions and agent loops that re-read the same prefix save the most.

What the cache-read cut means per turn

Take an agent loop that re-sends a 200K-token prefix (system prompt + tool definitions + repo context) every turn, adds 5K fresh input tokens and gets 2K output tokens back:

Fable 5.1: 200K × $0.25/M + 5K × $10/M + 2K × $50/M = $0.05 + $0.05 + $0.10 = $0.20 per turn
Fable 5:   200K × $1.00/M + 5K × $10/M + 2K × $50/M = $0.20 + $0.05 + $0.10 = $0.35 per turn

Over a 50-turn session that is about $10 versus $17.50 — a 43% saving with no prompt changes, as long as the prefix stays byte-identical so it keeps hitting the cache (the one-time cache write is extra in both cases). Live list prices for every model are on the pricing page.

Three things to check when migrating from Fable 5 / Opus 5

Forced tool use is gone: tool_choice any / tool returns 400. Use auto plus an instruction naming the tool, and strict: true or structured outputs when you need schema-valid JSON.
Thinking blocks are bound to the model: pass them back unchanged within a conversation and keep the history append-only — editing earlier turns invalidates earlier thinking blocks.
No assistant prefill: as with every Claude model since 4.6, control output format with structured outputs or the system prompt.

Three-minute quickstart

curl https://api.hop-base.com/v1/messages \
  -H "x-api-key: sk-your-key" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, introduce yourself"}]
  }'

Full setup steps are in the Anthropic SDK guide and the Claude Code guide. If you already have a key, just switch the model name to claude-fable-5-1.

Originally published on the HopBase blog.

Claude Opus 5.5 vs GPT-6 Sol vs GPT-6 Luna: API List Prices and Cost per Request

hopbase — Wed, 28 Oct 2026 18:21:19 +0000

The short answer: Claude Opus 5.5, GPT-6 Sol and GPT-6 Luna are available through the HopBase API at official list price. Opus 5.5 (claude-opus-5-5) is Anthropic's next-generation Opus: 1M context, 128K max output, $4 input / $20 output per million tokens — 20% below Opus 5 at $5 / $25 — with cache hits at $0.20. GPT-6 Sol (gpt-6-sol) targets complex coding and agent workflows: 1.05M context, $2 / $10, cached input $0.2. GPT-6 Luna (gpt-6-luna) targets high throughput and cost efficiency: 1.05M context, $0.1 / $0.5, cached input $0.01. Above 272K tokens both GPT-6 models switch to a long-context rate (Sol $4 / $15, Luna $0.2 / $0.75). In one line: Opus 5.5 for Claude Code and tool-heavy agents, Sol for Codex and coding agents, Luna for high-volume classification, extraction and routing, and GPT-6 Astra for the hardest problems. Your key's GET /v1/models response is the source of truth for availability.

Published list prices for the three new models

Model ID	Positioning	Context	Input / output (per 1M tokens)	Cache read
`claude-opus-5-5`	Anthropic's next-generation Opus	1M (128K max output)	$4 / $20	$0.20
`gpt-6-sol`	Complex coding and agent workflows	1.05M	$2 / $10 ($4 / $15 above 272K)	$0.2
`gpt-6-luna`	High throughput, cost efficiency	1.05M	$0.1 / $0.5 ($0.2 / $0.75 above 272K)	$0.01

For reference, GPT-6 Astra is $10 / $50 (cached $1) and Claude Opus 5 is $5 / $25. Opus 5.5 cache writes cost $5 per million for the 5-minute TTL and $8 per million for the 1-hour TTL. These are official list prices; every request's actual charge is itemised in your usage records. Since this post first went out, newer siblings have launched (for example Claude Sonnet 5.5 and GPT-6.1 Sol) — see live pricing at https://hop-base.com/pricing.

What the same request costs on each model

Straight from the list prices above, for one request with 20K input tokens, 2K output tokens and no cache hits:

GPT-6 Luna: 20K × $0.1/M + 2K × $0.5/M ≈ $0.003
GPT-6 Sol: 20K × $2/M + 2K × $10/M ≈ $0.06
Claude Opus 5.5: 20K × $4/M + 2K × $20/M ≈ $0.12
GPT-6 Astra: 20K × $10/M + 2K × $50/M ≈ $0.30

Luna and Astra are about 100x apart. That is why model choice should follow the task: inside one product, intent detection and field extraction that run hundreds of thousands of times a day belong on Luna, and only the smaller share of requests that need long reasoning chains should go to Sol, Opus 5.5 or Astra. Giving each workload its own API key also separates cost by purpose in your usage records.

How to choose

Claude Code and tool-heavy agents: Opus 5.5. It is 20% cheaper than Opus 5 and cache hits cost only $0.20, so long sessions that keep re-reading the same system prompt and tool definitions get cheaper the more they hit the cache.
Codex CLI, coding agents and complex workflows: GPT-6 Sol. At $2 / $10 it offers 1.05M context, enough to put a whole repository in context — just remember the long-context rate beyond 272K.
High-volume batch work: GPT-6 Luna. Classification, tagging, extraction, rewriting and routing decisions — many calls, each simple — cost a fraction of a cent per call on Luna.
The hardest problems you can afford: GPT-6 Astra. Run Sol or Opus 5.5 first and escalate only what fails or falls short; that is far cheaper than sending everything to the flagship.

The most reliable method is still to run each candidate on your own evaluation set and compare output quality with the actual charges in your usage records, rather than relying on leaderboards. While you are at it, confirm you are getting the model you pay for with our model fidelity verification method.

Three-minute integration

Claude uses the Anthropic protocol with Base URL https://api.hop-base.com (no /v1); GPT uses the OpenAI-compatible protocol with Base URL https://api.hop-base.com/v1. One key can be enabled for both families; GET /v1/models tells you which IDs it can call.

# First check which models this key can call
curl https://api.hop-base.com/v1/models -H "Authorization: Bearer $HOPBASE_API_KEY"

# Claude Opus 5.5 (Anthropic protocol)
curl https://api.hop-base.com/v1/messages \
  -H "x-api-key: $HOPBASE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-opus-5-5","max_tokens":64,"messages":[{"role":"user","content":"Reply with exactly: ok"}]}'

# GPT-6 Sol / Luna (OpenAI-compatible; swap the model for gpt-6-luna)
curl https://api.hop-base.com/v1/chat/completions \
  -H "Authorization: Bearer $HOPBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-sol","messages":[{"role":"user","content":"Reply with exactly: ok"}]}'

For Claude Code, set ANTHROPIC_BASE_URL to https://api.hop-base.com and ANTHROPIC_AUTH_TOKEN to your HopBase key, then switch the model to claude-opus-5-5 (Claude Code guide). For Codex CLI, use the Responses API (wire_api = "responses") with gpt-6-sol as the model (Codex CLI guide).

FAQ

How much cheaper is Opus 5.5 than Opus 5?

At list price, input drops from $5 to $4 and output from $25 to $20 — 20% on both. Cache hits cost $0.20, 0.05x the input price. Opus 5.5 has a 1M context window and 128K max output.

What does 272K mean for GPT-6 Sol and Luna?

Both models have a 1.05M context window, but beyond 272K tokens they are billed at the long-context rate: $4 / $15 for Sol and $0.2 / $0.75 for Luna. Everyday requests under 272K pay the base rates of $2 / $10 and $0.1 / $0.5.

Can my key call these three models?

Availability is scoped per API key. Call GET /v1/models with the key; whatever IDs come back are the ones it can call. Do not guess model names.

Are these the prices I pay?

They are the official list prices published on our pricing page. For enterprise volume, contact us for a quote; every request's charge can be checked line by line in your usage records.

Originally published on the HopBase blog.