Fugu Max vs Ultra v2: When to Pay for More Reasoning

Start with Fugu Max when a task already has a clear acceptance test. Pay for Ultra v2 when a harder task repeatedly fails that test and the additional reasoning reduces the total cost of reaching an accepted result. A higher token price can be worthwhile, but the model name cannot establish that trade-off for you.

Sakana announced both variants on September 11, 2026. Prices and documentation below were checked September 12. This is a buying framework with illustrative calculations; we did not run a head-to-head benchmark.

Sakana’s announcement presents Max and Ultra v2 as two objectives within its orchestration architecture: cost efficiency and higher capability on difficult tasks. The company says both are immediately available through its OpenAI-compatible API. These are hosted system choices; using open models inside a service does not make the complete service an open-weight download.

The distinction matters if you buy complete agent work rather than isolated answers. An orchestration system can select and coordinate underlying models, but you still need to supply the right tools, data and acceptance criteria. Our earlier Fugu introduction covers that architecture. This comparison asks which new price tier deserves a place in a workflow.

Do not confuse the Fugu Max model with a subscription carrying the word Max. A model rate and a monthly account allowance answer different questions. Compare the actual API variant on the invoice and keep subscription entitlement outside the token arithmetic below.

The current Fugu pricing page lists the following US-dollar rates per million tokens. Cached input is a separate billing category, not an automatic discount for all repeated text. Record the cache usage the service actually reports.

Ultra v2’s long-context condition is expressed as context greater than 272K. The page does not fully explain every boundary-accounting case. Before pricing a request close to that threshold, confirm what the service counts and how it applies the rate. The table faithfully records the published categories; it is not a reconstructed billing specification.

The same page lists Max web_search and web_fetch at $0.007 per call. Add these when used. Do not apply the ordinary configurable Fugu pool’s blended-price explanation to these fixed-rate variants, or assume that all downstream tool spending is included.

For an illustrative request with 100,000 uncached input tokens and 10,000 output tokens, Max costs $0.26: 0.1 × $2 plus 0.01 × $6. Ultra v2 costs $0.80 at its ordinary rates: 0.1 × $5 plus 0.01 × $30. That is about 3.08 times the token cost for the same billed token counts. It is not a measured difference in the cost of completing a task.

For an illustrative 300,000-input, 10,000-output request, Max costs $0.66. Ultra v2 costs $3.45 if its published long-context rates apply to the full request. This assumption is explicit because threshold billing needs confirmation. Neither example includes cache reads, tools, failed attempts or human review.

Equal token counts are useful for explaining a rate card. They are a poor forecast when the systems produce different reasoning lengths, call different tools or require different numbers of retries. Use actual usage records for a pilot and retain failed attempts in the total. The review-cost guide explains why a cheap draft can still be expensive to accept.

Sakana reports stronger benchmark performance for Ultra v2 and positions Max around cost efficiency. Those are vendor-reported results. This article does not independently validate the benchmark runs, their task distribution or their relevance to your repository. We therefore do not turn the announcement into a universal ranking.

Choose examples that resemble the decision you face: a multi-file repair with regression checks, a research answer with conflicting evidence, or a structured document requiring several connected deductions. Also include routine cases. A test set consisting only of exceptionally hard tasks cannot tell you whether to upgrade everyday traffic.

Keep the brief, tools and acceptance rules comparable. Preserve each system’s actual settings rather than pretending differently named effort controls are equivalent. The benchmark interpretation guide provides the distinction between a published score and evidence from your own task distribution.

A useful escalation rule names the failure that more reasoning is expected to address. For example: the cheaper run has the correct files and permissions but cannot produce a patch that passes the agreed regression case. Record that condition before asking Ultra v2 to continue or retry.

Escalation is less promising when the missing ingredient is a credential, a source document or a decision only the user can make. More reasoning cannot establish an unavailable fact. Fix the information gap first. Otherwise the expensive run may simply produce a more elaborate version of the same unsupported answer.

Treat the fallback as another attempt in the same task budget. Count the original run, the escalation, repeated tool work and the final review. If you pass a prior draft to Ultra v2, label that as an assisted escalation test. It is different from independently giving both variants the same starting brief.

Before starting, write down the task categories, what counts as acceptance and who will review the work. Afterward, report accepted and rejected cases, total charge, waiting time and review effort separately. Averages can hide a category that becomes less reliable even when the overall bill improves.

If Ultra v2 helps only on complex structured reasoning, route that category to it and keep routine work on Max. If results are mixed, keep the selection reversible and collect more representative cases. A small pilot supports a local routing decision, not a broad claim that one system is best.

An AI transformation project should turn the model choice into a measurable acceptance decision. Keep the dated rates with the pilot record so a later price change can be evaluated without confusing it with a change in quality.

The two variants differ in price and in the tasks the vendor positions them for, and the guide’s sections exist because a pilot can measure one of those and report it as the other. The illustrative pilots below each confuse one measure with another. They are design examples drawn from the rate card’s own categories, not teams we have worked with.

Each pilot would have produced a cost figure that the invoice later contradicted. The record in the next section writes the measure down before the run so that the figure and the invoice can be compared.

The guide asks a team to compare accepted work, confirm the boundary accounting, escalate for a recorded reason and adopt the smallest change the pilot supports, and a record per task category holds all four. The category: the task type, its acceptance test and who reviews it. The rates: the published categories, dated, with the boundary accounting as the service confirmed it rather than as the page implies it. The runs: for each task, the variant used, the billed token counts by category, tool calls at their per-call price, retries and the review effort, with failed attempts kept in the total. The escalation: the named failure that justified sending a task to Ultra v2, and whether it was an independent run from the same brief or an assisted continuation of a prior draft. The outcome: accepted or rejected, elapsed time and total charge, reported by category rather than averaged. And the decision, as a routing rule for one category, reversible, with the dated rates kept beside it.

An illustrative record for a multi-file repair category reads: category, repairs that must pass an agreed regression case, reviewed by the repository owner; rates, the September 12 card, with the long-context accounting confirmed before any request approached the threshold; runs, Max first on every task, with billed tokens, two web_fetch calls and one retry recorded; escalation, three tasks sent to Ultra v2 because Max had the right files and permissions but no passing patch, each run independently from the same brief; outcome, two of the three accepted, with the charge and review time beside the Max attempts they followed; decision, route that failure pattern to Ultra v2 and keep routine repairs on Max, to be revisited when the rates or the acceptance rate change.

The record is also what separates a price change from a quality change later. Rates move and model behavior moves, and a record that carries the dated card beside the accepted-work results lets the two be told apart when the bill does.

As-of date. September 12, 2026: sources retrieved and reviewed. The article is dated September 12, 2026. Verified event dates are stated separately.

Sources and method. Two Sakana primary pages checked September 12, 2026. Published rate categories transcribed and illustrative arithmetic recalculated.

Limits. No model runs or independent benchmark reproduction. Boundary accounting and actual account terms must be confirmed for a purchasing decision.