typed

← All posts

typed++ is live: dynamic agentic workflows, deep reasoning

-- Jeff Yaw

Last updated

Update, 23 September 2026: the economy tier is now spelled typed (it was typed--), the free tier that runs on your machine is typed-local (it was typed), and with a paid account the CLI defaults to typed.

typed++ is the paid, hosted top of typed's lineup. Below it sits typed, a lighter hosted tier with the lowest draw per token of anything typed serves. Both carry a 1M context window, so what separates them is quality and price, not how much they can hold. Each is its own serving configuration.

Before that matters, the part to read first: without a paid plan, typed's default tier is free, runs on your own machine, and needs no account and no API key. typed-local runs against a model server on your own hardware. typed is never in the request path -- that is why it costs 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 hosted tiers:

typed --model typed++

The thing to understand before you turn it on is that typed++ is metered against your monthly budget, and it draws that budget down substantially faster than typed does. 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 one local tier, typed-local. It runs on your hardware against any server that answers POST /v1/messages and GET /props -- llama-server, or the GenieX Server (Snapdragon) on an NPU. The CLI probes /props for the window, probes tool support, and adapts to whatever answers.

The hosted tiers are a different family and a different constraint. They target 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 typed++ 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.

Dynamic sub-agentic workflows

The other half of what typed++ buys you is not depth on one turn. It is the model deciding, mid-task, to stop working alone.

typed ships an Agent tool. The model calls it to hand a self-contained sub-task to a subagent that runs its own loop, with its own context. The subagent sees none of the parent conversation -- the delegating prompt has to carry everything it needs -- and its final message comes back as data for the next step, not as prose already printed to you. The available subagent types are read out of your project's own .claude/agents definitions at startup, so the roster is whatever your repo defines, plus a general-purpose one.

Nothing about that is scripted. There is no workflow file, no DAG you author in advance. The model decomposes the work when it sees it, picks how many subagents to spawn and what each one gets, and emits those calls together so they run at once. That is what "dynamic" means here: the shape of the fan-out is a decision the model makes per task, not a pipeline you wrote last week.

Turning it on is one command:

typed ultracode on
typed

That flips a machine-wide marker and adds one instruction to the system prompt: for substantive multi-part work, decompose it, fan out parallel subagent calls for the independent pieces, and adversarially verify anything important with a second, independent subagent before reporting it. Work solo on conversational turns and trivial edits. It is an orchestration setting, not an effort setting -- it governs whether the model fans out, not how hard it thinks on a single turn, and the two compose.

Parallel means parallel, with one deliberate constraint: consecutive tool calls only run together when they cannot affect each other. A run of reads goes concurrently; a write splits the run. [Read, Read, Edit, Read] executes as [Read, Read], then [Edit], then [Read], so the edit still observes both reads and the trailing read still observes the edit. Reordering across a write would let a read land on either side of it depending on scheduling, which is the class of bug that makes parallelism cost more than it returns.

There is also /bg. It starts a read-only subagent that runs while you keep working and delivers its answer into the conversation when it lands -- "go figure out where this is configured while I finish this refactor". Read-only is the whole reason it is a contained feature instead of a rewrite: a task that wrote files after its turn ended would attribute those writes to a later, unrelated checkpoint and corrupt a rewind, and a detached task hitting a permission prompt would ask you about work you started ten minutes ago. A read-only task records nothing and reaches no mutating gate, so neither problem needs managing. Two at a time.

You are not left guessing what the fleet is doing. Each subagent's tool actions are forwarded to your scrollback as labeled, indented lines as they happen. Concurrent subagents interleave, but every line carries its subagent's label.

The limits, stated plainly

  • One level deep. A subagent cannot spawn subagents. This is structural, not a policy: the Agent tool is excluded from the nested registry, so there is nothing to call. Orchestration is a tree of depth one, and a runaway recursion is not a failure mode that exists.
  • Fan-out multiplies budget draw. Subagents bill like any other request and compete for the same provider. Five subagents on a hard problem is five times the work being paid for. This is the single fastest way to spend a month, and it stacks with typed++ being the most expensive tier typed serves.
  • It is a paid feature. typed ultracode on requires a Pro, Max, Ultra, or any Team plan with an active subscription. Starter is refused: one ultracode session would burn through its entire monthly volume.
  • The free local tier runs solo, by design. Subagents are off there: a local model server has one slot, so fanning out would queue against itself and gain nothing. The marker can be on and a local session will still work alone. The same is true of any hosted session whose tool list excludes Agent -- the instruction is withheld rather than issued against a tool that is not there, because a model told to fan out on a missing tool just burns turns on unknown-tool errors.
  • Background tasks are read-only and capped at two. See above for why; it is a deliberate boundary, not a stub.

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. Counting tokens instead would misreport what you owe, because prompt caching means most of the tokens a coding agent consumes are cache reads priced at a fraction of the rate.

So an expensive model does not shrink your ceiling. It drains the ceiling faster. typed++ draws down budget substantially faster than typed does, and output draws more than input on both.

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 on both hosted tiers, and two things that rests on are locked by tests in our build: that a hosted 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 tier -- which costs you nothing and never leaves your machine -- on the other seven.

Two hosted tiers, honestly labeled

typed++ and typed are separately named because they are separately configured. Each is its own serving setup, with its own model behind it and its own rates. Neither one is the other with a knob turned down.

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 hosted 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 economy tier, and the default with a paid plan -- or on typed-local -- free, and running on your own machine -- for everything else. Spending premium budget on a routine refactor is just waste.

A question this invites: if the free local tier 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++ burns budget quickly, and there is no separate spend cap for it and no per-request confirmation. The usage page and the quota headers on every metered response are what you have; watch them.
  • Fan-out multiplies that drain. Every subagent bills like any other request; the CLI itself warns you that ultracode runs 10-50x the tokens of a solo session when you switch it on. Orchestration is the fastest way to spend a month, and it compounds with typed++ being the priciest tier. If you want the depth without the multiplier, leave ultracode off.
  • Sampling typed++ still costs real budget. typed is a cheaper way into the hosted family, and the local tier is free, but the local tier is a different family, so running it 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++

Or via the API, as the model field:

"model": "typed++"

Orchestration is a separate switch from the tier. It is machine-wide, it persists across sessions, and it composes with either hosted id:

typed ultracode on     # enable
typed ultracode        # no argument: print the current state
typed ultracode off    # disable

The hosted 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.

If you carry --effort words in shell aliases from an older setup, they still resolve. They are aliases for the tiers above, not a second way to choose:

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

The map is not a ladder: max and xhigh both land on the free local tier, while high, medium and low land on paid hosted tiers, so low is the end that bills. Naming the tier with --model sidesteps all of this. With no flag and no effort word, the CLI runs typed with a key on a paid plan and typed-local without one.

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 tier. typed-local runs on your machine, never reaches us, and needs no account, no key, and no quota. Team plans start at $25/seat.