typed

← All posts

typed++ is live: the deepest reasoning we can buy

-- Jeff Yaw

Last updated

typed++ is live. It is a new model family that sits above typed-max at the top of our lineup, and it is the deepest reasoning we can currently buy.

There is no upgrade to purchase and no separate quota to manage. If you have a typed subscription today, on any tier including Starter, you can use it right now by naming it:

typed --model typed-plus-plus

The thing to understand before you turn it on is that it draws down your existing monthly budget roughly ten times faster. That is the whole trade. The rest of this explains where the number comes from, because we would rather you understand the economics than discover them at the end of the month.

Why it is a separate family

The typed-* tiers, typed-max through typed-low, are one model family at five reasoning depths. Moving from typed-medium to typed-max buys more thinking on the same underlying capability.

typed++ is a different family. The constraint it targets is what the model can do at all. Some problems have a ceiling made of capability: gnarly architecture calls, ambiguous debugging, the class of task where a better model wins and a longer think just costs you more. That is what it is for.

Our own tier sweeps are what convinced us those are separate axes, and the honest read of them is more interesting than the version we published first. Across five-tier sweeps on our internal suites, the reasoning ladder did not separate at all on easy and mid-difficulty work. Every rung scored the same, and on one suite a higher rung scored slightly lower than the one beneath it, which is what noise looks like. The ladder only started separating on the hardest suite, and there it separated like a cliff: the top two rungs landed the task some of the time and everything below them went to zero.

Two caveats on that, because the numbers are small and I do not want to oversell them. These runs are three to six tasks per arm from a single day, which is enough to see a cliff and not enough to locate it precisely. And at the time we ran them all five rungs were the same model at different effort settings, so capability was held constant by construction. That means the data cannot support the claim we made in the first version of this post, that effort stopped mattering "because capability was the bottleneck." It shows something narrower and still useful: more thinking buys nothing until the work is hard, and then the returns arrive all at once. typed++ is a bet that past that point what you want is a different model.

What it costs you

typed's quota is denominated in a cost unit. Each plan carries a fixed monthly ceiling, and each request debits in proportion to what it costs to serve, computed from the published rates for the model that handled it. (This changed recently. Until July 2026 the quota counted tokens, which stopped working once prompt caching meant most of the tokens a coding agent consumes are cache reads priced at a fraction of the rate. The cost-denominated ceiling is what replaced it.)

So an expensive model does not shrink your ceiling. It drains the ceiling faster. Input on typed++ draws about 10x what the default family draws, and output draws meaningfully more than that.

Treat "about 10x" as the floor. Two things push the real number higher: output-heavy work, where the multiplier is worse, and cache-heavy work, where the discount lands on the input side and leaves output a larger share of what you are paying for. Plan for more than 10x on both.

We are not marking it up. The proportion we keep is the same as on the default family, and two things that rests on are locked by tests in our build: that a typed++ request debits at the cost basis for the model that served it, and that it actually routes to that model instead of being quietly served something cheaper. The pricing parity follows from those two. It is an inference from them, and a test does not assert it directly. The earlier version of this post said otherwise and was wrong.

That is also why it is a toggle. A separately priced tier would have meant a new SKU, a new quota envelope, and a decision from you at signup about a model you had not tried. A toggle means you spend the budget you already have where it is worth spending: typed++ on the hard hour, the default family on the other seven.

One effort level, honestly labeled

At launch typed++ runs at its top effort level only, because that is the only level the family currently exposes. If more become available we will expose them as real, separately named tiers.

What we will not do is simulate them. We could ship a typed-plus-plus-high tomorrow by capping a token budget and calling it a lower rung. It would make for a fuller product page and it would misrepresent what you were buying.

We know the temptation because we already gave in to it once. Our bottom rung used to carry a small thinking budget. We benchmarked it against sending no reasoning parameter at all, ten runs: identical cost per task, identical pass rate, and on the harder task a mean of 74 seconds against 20, roughly 3.7 times slower for the same answer. A thinking budget too small to converge just makes the model dither across more verification turns to arrive where it was going anyway. We deleted the rung, removed it from /v1/models, and wrote a unit test that fails if anyone adds it back.

When to reach for it

Reach for typed++ when the problem is hard in a way more thinking will not fix: architecture and design calls where the tradeoffs are genuinely unclear, debugging where the symptom and the cause are far apart, work where being 90 percent right is the same as being wrong.

Stay on typed-xhigh, still the production default, for everything else. Burning ten times the budget on a routine refactor is just waste.

A question this invites, since we published a benchmark where typed-xhigh went 14 for 14 against a frontier model: if the default family already ties at the top, what is typed++ for? The answer is that the benchmark saturated. Two systems that both pass every task in a set are indistinguishable on that set. All that tells you is that the set could not separate them. It is the same shape as the tier sweeps above: no separation until the work is hard enough, then a cliff. A benchmark where everything passes is the wrong instrument for finding that edge, and typed++ is aimed past it.

The tradeoffs

The honest list of what is worse about this, since a launch post that only lists upsides is an advertisement:

  • You can drain a month in an afternoon. At better than 10x, a Starter budget goes quickly. There is no separate spend cap for typed++ and no per-request confirmation. The usage page and the quota headers on every metered response are what you have; watch them.
  • There is no cheap way to try it. One effort level means you cannot sample the family at low cost to see whether your problem is past the cliff. The first honest test costs real budget.
  • We cannot tell you in advance whether your problem is past the cliff. That is the same prediction problem that makes agent billing hard generally. Our tier data locates a cliff on our own suites, and your codebase is not our suites.
  • The multiplier is worse than the headline on output-heavy work, and worse again the better your caching is working.
  • The evidence base is small. Three to six tasks per arm, one day, our own suites, graded by us.

How to turn it on

Per invocation:

typed --model typed-plus-plus

Or via the API, as the model field:

"model": "typed-plus-plus"

It appears at the top of /v1/models as Typed Plus Plus. There is no header, no environment variable, and no flag to enable first; naming the model is what selects it. Note that --effort will not reach it, since that flag validates against the five-rung ladder.

If you want to see what it is doing to your budget, the dashboard's usage page breaks activity down by request, and we return quota headers (x-typed-quota-tier, x-typed-quota-percent, x-typed-quota-reset) on every quota-gated response.