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

typed++ is the paid, hosted top of typed's lineup: typed++max, typed++xhigh, and typed++high. The two upper rungs carry a context window of roughly 950K; typed++high is a separate model with a roughly 131K window.

Before that matters, the part to read first: typed's default tier is free, runs on your own machine, and needs no account and no API key. typed (a 35B MoE) and typed-max (a dense 27B) run against a model server on your own hardware. typed is never in the request path -- that is why they cost nothing.

Getting started costs nothing and takes no signup:

curl -fsSL https://app.typed.cloud/install.sh | bash
typed local
typed

typed local sizes a known-good model preset for your machine. The installer takes an API key as an optional argument -- a key is needed only to reach the paid typed++ tiers:

typed --model typed++max

The thing to understand before you turn it on is that typed++ is metered against your monthly budget, and the top tier draws it down substantially faster than the lower ones. That is the whole trade. The rest of this explains how the metering works, because we would rather you understand the economics than discover them at the end of the month.

Why it is a separate family

The free family is two local models: typed, a 35B MoE, and typed-max, a dense 27B. Both run on your hardware against any server that answers POST /v1/messages and GET /props -- llama-server, or a Genie server on an NPU. The CLI probes /props for the window, probes tool support, and adapts to whatever answers.

typed++ is a different family and a different constraint. It targets 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 these are separate axes. More thinking bought nothing on easy and mid-difficulty work -- every depth scored the same. Separation only appeared on the hardest suite, and there it arrived like a cliff. The runs were three to six tasks per arm from a single day, which is enough to see a cliff and not enough to locate it precisely.

typed++ is a bet that past that point what you want is a different model, not a longer think.

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. Within typed++, typed++max draws down budget substantially faster than typed++xhigh, which in turn draws more than typed++high. Output draws more than input on every tier.

Two things push your real burn above the headline: output-heavy work, where the gap between tiers is wider, and cache-heavy work, where the input discount leaves output a larger share of what you are paying for. Plan for more on both.

We are not marking it up. The proportion we keep is the same across the typed++ tiers, 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.

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. It means you spend the budget you already have where it is worth spending: typed++ on the hard hour, and the free local tiers -- which cost you nothing and never leave your machine -- on the other seven.

Three tiers, honestly labeled

typed++ exposes three tiers: typed++max, typed++xhigh, and typed++high. They are real, separately named tiers backed by different serving configurations, not one model with a capped token budget wearing three labels.

What we will not do is simulate a tier. Capping a thinking budget and calling it a lower rung makes for a fuller product page and misrepresents what you are buying. Each typed++ tier is a real serving configuration or it does not ship.

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 -- the default, free, and running on your own machine -- for everything else. Spending paid budget on a routine refactor is just waste.

A question this invites: if the free local default already passes everything we throw at it, 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. A benchmark where everything passes is the wrong instrument for finding the 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. typed++max burns budget quickly, and 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.
• Sampling typed++ still costs real budget. typed++high is a cheaper way into the family than typed++max, and the two local tiers are free -- but the local tiers are a different family, so running them tells you nothing about whether your problem is past the typed++ cliff.
• 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 gap between tiers is wider on output-heavy work, and wider 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++max

Or via the API, as the model field:

"model": "typed++max"

The typed++ tiers appear at the top of /v1/models. There is no header, no environment variable, and no flag to enable first; naming the model is what selects it.

--effort also still works, and it selects across BOTH families:

--effort	tier
max	typed-max	free, local
xhigh	typed	free, local
high	typed++high	paid, hosted
medium / low	typed++xhigh	paid, hosted

The effort word picks a tier, and two of them are free and run on your own machine.

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.

None of that applies to the free tiers. typed and typed-max run on your machine, never reach us, and need no account, no key, and no quota. Team plans start at $25/seat.