typed

Migrate to typed

For Pro / Max customers evaluating typed as a fallback for an existing AI coding CLI subscription (or a replacement, if it fits).

1. The config change

The fastest path is the typed launcher. One curl installs it with your API key wired in:

curl -fsSL https://app.typed.cloud/install.sh | bash -s <your-typed-key>

The dashboard pre-fills the command with your key + a Copy button. Once installed, typed and t are on your PATH:

typed                  # launches `claude` against typed.cloud
t                      # one-keystroke alias, identical behavior
typed --resume <id>    # any flags pass through

The launcher sets every required env var, picks the right defaults, and skips Claude Code's first-run "approve this key?" prompt.

If you would rather wire it up by hand, typed speaks the Anthropic API directly. Set three environment variables and any Anthropic-API-compatible client switches over:

export ANTHROPIC_BASE_URL=https://api.typed.cloud
export ANTHROPIC_AUTH_TOKEN=<your typed key>   # bearer/gateway pattern
export ANTHROPIC_MODEL=typed++xhigh

ANTHROPIC_AUTH_TOKEN (which Anthropic SDKs send as Authorization: Bearer) is the recommended variable: typed.cloud is a gateway, and Claude Code understands the bearer pattern as a proxy token, so it skips the interactive "approve this key?" prompt that fires when you use ANTHROPIC_API_KEY instead. typed.cloud accepts both header shapes, so existing configs continue to work, but new setups should prefer ANTHROPIC_AUTH_TOKEN.

The third line is required. typed uses its own model identifiers -- typed++max, typed++xhigh, typed++high (paid, hosted) and typed (free, run on your own machine); if your client sends an upstream model name like claude-3.5-sonnet, typed returns a 400 with the full list of valid identifiers in the error body. See section 1a below for how to choose.

Pick a typed++ id for this path. The snippet above uses typed++xhigh -- the hosted workhorse, and the same default the launcher fills in for Claude Code. The free typed id is local-only: it runs on a llama-server on your own machine and is reachable only through the first-party typed CLI pointed at that server (see the local setup guide). Sending it to api.typed.cloud from a hand-wired client returns a 503 config error, not a free response.

The canonical list is also available programmatically: the Anthropic SDK's client.models.list() works against typed (or curl https://api.typed.cloud/v1/models -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN"). SDK consumers that introspect the model surface see every canonical id in Anthropic-API shape -- the three paid typed++ models and the free local one; back-compat aliases stay valid for /v1/messages but are intentionally omitted from discovery.

We run our own day-to-day on Claude Code against typed. Other Anthropic-API-compatible clients (Cursor, Cline, Roo Code, OpenClaw, and any tool that reads ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY from the environment) should work the same way. The API is wire-compatible. If your client doesn't pick up the env vars, set the same values in its config file.

You can flip back at any time by swapping the variables. Nothing else changes.

1a. Choosing a model

typed exposes four model ids in two families. Set ANTHROPIC_MODEL to one of them.

typed++ -- paid, hosted, three rungs. These run on our infrastructure and draw on your plan's budget. The rungs differ in how much reasoning they spend.

Model ID Use when Quality Latency Cost per request
typed++max Genuinely hard problems: architectural design, complex multi-file refactors, debugging that needs deep reasoning, anything irreversible Highest Slowest (often 10-40s on hard prompts) Highest reasoning effort. Most expensive per request; reserve for hard work.
typed++xhigh The hosted workhorse. Routine refactors, feature work, code review High (cache-reliable) Fast (typically 3-8s) Dialed to "high" reasoning effort. Cache-reliable, so most coding-client traffic gets cache discounts and runs noticeably cheaper per request.
typed++high High-volume routine work where cost matters more than depth Mid Fastest of the three Cheapest paid rung. One limit the other two do not have (a smaller context window) -- see below.

typed -- free, runs on your own machine. The model runs on a llama-server you point typed at; typed is out of the request path entirely, which is why the tier costs nothing and needs no account. See the local setup guide.

Model ID Use when Notes
typed Everyday coding on your own hardware, offline work, anything you would rather not send anywhere The mixture-of-experts local model, and the tier the first-party CLI picks when nothing names one -- which is what a fresh install selects. A launch that falls back to Claude Code as the client defaults to typed++xhigh instead -- see "Which default you actually get" below.

Within typed++ the ladder is consistent: each rung carries strictly more reasoning effort than the one below it, and lower rungs are cheaper because they emit fewer reasoning tokens. The free typed tier is not a continuation of that ladder -- it is a different model on different hardware, so do not read it as a rung "below typed++high".

typed++high comes with one limit the rungs above it do not have:

Model ID Limits
typed++high Smaller context window than the rungs above (see below). Image input is accepted.

The limit is enforced with an explicit error rather than a silent workaround: exceed the window and you get a 413. We deliberately do not re-route an oversized request onto a different model, because that would quietly bill you for a model you did not choose.

1b. Running typed and Claude side by side

The launcher does not replace claude or modify your shell; it only sets env vars on the subprocess it spawns. Both commands stay on your PATH and run as independent processes:

  • claude: runs Claude Code against Anthropic directly with your Claude subscription auth. Unaffected by the typed install.
  • typed (or t): spawns Claude Code with ANTHROPIC_BASE_URL / ANTHROPIC_AUTH_TOKEN / ANTHROPIC_MODEL pointed at typed.cloud.

You can run as many of either at the same time across separate terminal panes / tmux windows / IDE terminals. Each invocation is its own process with its own environment:

Scenario Result
Pane A: claude, Pane B: typed Independent. Pane A hits Anthropic, Pane B hits typed.cloud.
N typed panes simultaneously All share one typed.cloud account / one monthly quota pool. No concurrency lock on the API side; you just burn quota proportionally.
M claude panes simultaneously All share one Anthropic subscription / one rate-limit budget. Same logic.
Mix of typed and claude panes typed.cloud's rate-limiter and Anthropic's are completely separate; the two backends don't see each other.

Toggle without rewriting aliases. Three subcommands let you flip the launcher's behavior without setting / unsetting env vars by hand:

typed status     # show current routing state + api key source
typed disable    # writes a flag file; subsequent `typed`/`t` exec `claude` WITHOUT typed env vars
                 # (your Claude subscription is used instead)
typed enable     # remove the flag file; route through typed.cloud again

Useful for bouncing between accounts mid-session without uninstalling or rewriting shell rc files.

One caveat (Claude Code's, not typed's). Claude Code writes session state to a per-project directory. Two claude-family processes (whether claude or typed/t) running in the same project directory at the same time can race on transcript / session files. Running them in different project directories, the natural pattern when you'd want both, is fine.

Context windows by model. The two upper typed++ rungs and image-bearing (multimodal) requests share the same context window. typed++high and the free local tier are the exceptions:

Model Context window
typed++max / typed++xhigh ~950K tokens
Multimodal (any image-bearing request, either of the two rungs above) ~950K tokens
typed++high ~131K tokens (text and images), shared by the prompt and the output -- see below
typed whatever your own llama-server was started with -- typed reads the real value at startup and sizes the session to it

~950K covers the typical envelope of a Claude Code session with room to spare, and it applies uniformly to the two upper rungs: same window for text and for image-bearing requests, with no opt-in header, no model change, and no per-request configuration. Requests above the window return a typed-branded error rather than silently truncating. (For reference, current-generation Claude models, Opus 4.6/4.7/4.8 and Sonnet 4.6, include a 1M window at standard pricing; current Haiku 4.5 and legacy Sonnet 4.5 still cap at 200K.)

If you opt into typed++high, size your sessions against its smaller ~131K window: it is a different model from the rungs above, so it does not inherit the ~950K figure. An oversized request there returns a 413 rather than being promoted onto a larger, pricier model behind your back.

That ~131K is one budget shared by the prompt and the model's output. The request's max_tokens, counted up to 32,000, is taken out of the window before your prompt is measured, so the prompt gets what is left. Coding clients commonly send max_tokens of 32,000 or more, and at that setting the prompt budget is about 99K tokens, not 131K. It is a little less in practice, because the context typed adds to each request (knowledge snippets, a short working-directory note when your client's system prompt names one, plus any codebase or skill you attach) is reserved out of the same window. If typed++high keeps returning 413s on a prompt well under 131K, this is why: trim toward ~99K, or lower max_tokens.

The free local models are bounded by your own hardware, not by us. Their window is whatever you gave llama-server, which is normally far smaller than any hosted figure above, and the same sharing applies: the requested max_tokens comes out of that window too -- see the local setup guide.

Reading the budget off the response. Every served /v1/messages response carries the numbers above as headers, so a client can size itself against what the server actually enforced instead of a figure copied from this page. x-typed-context-window is the whole window for the route that served the request, in tokens. x-typed-context-input-budget is what is left of that window for the prompt once the context typed reserves (knowledge snippets, a short working-directory note when your client's system prompt names one, plus any codebase or skill you attached) and, on typed++high and the free local tier, the request's max_tokens are taken out -- it is the exact number the request-too-large check compared your request against, so a request whose estimated size exceeds it returns a 413. x-typed-context-breakdown is a JSON object with a per-bucket token estimate (system, tools, messages, knowledge, codebase, cwd, skill, max_tokens) that says where the tokens went. The estimates use a 4-characters-per-token heuristic, and the check also counts typed's own system prompt on top of your request, so leave a margin under the input budget rather than filling it to the last token.

Which default you actually get. There is no server-side default. The API requires model on every request: /v1/messages returns a 400 -- model and max_tokens are required -- when the field is missing or is not a string, and it never picks a tier on your behalf. "The default" is therefore a CLIENT-side concept, and which tier you land on depends on what is launching:

What you launch Tier when nothing names one
typed / t after a successful install, or after typed cli on (first-party CLI -- what the installer selects) typed -- the free local model, no account required
typed / t spawning Claude Code (the fallback client, e.g. after typed cli off or a partial install) typed++xhigh -- a hosted rung, because the free typed tier is local-only and needs the first-party CLI
The first-party CLI invoked directly typed
Anything else (raw SDK, curl, another gateway) none -- send model yourself or take the 400

The launcher only fills ANTHROPIC_MODEL in when you have not set it (ANTHROPIC_MODEL="${ANTHROPIC_MODEL:-<default>}"), so an explicit ANTHROPIC_MODEL, a .typed repo pin, a global pin from typed use <tier>, or a client --model flag all outrank the built-in default. Run typed status to see the tier your next launch would use and where that value came from.

Reach for typed++xhigh when you want the hosted workhorse -- cache-reliable, fast, enough reasoning headroom for normal feature work. Bump to typed++max when you have a hard problem that is worth the latency, and drop to typed++high when you want a quick answer on routine work and can accept less depth.

Legacy aliases that work for backward compatibility:

Alias Resolves to
typed-xhigh typed (the previous spelling of the default)
typed-local typed
typed-plus-plus typed++max
typed-high typed++high
typed-medium typed++xhigh
typed-minus-minus typed++high
typed-pro typed++xhigh
typed-long-context typed++xhigh (legacy alias from when typed had a distinct long-context tier; there is no separate long-context rung today, and a request that exceeds the hosted context cap returns a 413 rather than being moved to a larger one)

typed-low and typed-fast are gone and are NOT aliases. Both were removed on 2026-08-19, for the same reason: each named a combination no surviving model reproduces -- the typed++xhigh rung with reasoning switched off entirely -- so mapping either onto a survivor would have silently changed what you were billed for and how deeply your prompt was reasoned about. Sending either now returns a 400 like any other unknown id, and a saved pin on either is treated as stale. If you were on one of them, pick typed++xhigh for the hosted workhorse, typed++high for the cheapest paid rung, or typed to move off paid entirely. (typed-fast still appears on billing history from before the rename -- that is a historical label on old rows, not an id you can send.)

Anything else, including all claude-*, gpt-*, or typos, returns a 400 with the full list of valid IDs in the error body.

1c. The typed CLI: a first-party client, opt-in

Everything above runs your existing client against typed.cloud. typed also ships a first-party coding agent CLI, built in-house alongside the backend. It is opt-in:

typed cli on       # subsequent typed / t runs launch the typed CLI
typed cli off      # back to the previous default
typed cli          # print the current state

(typed tui on|off is an interchangeable alias for typed cli on|off and still works. typed beta on|off is a deprecated alias for the same thing and still works for now.)

Claude Code against typed.cloud remains fully supported either way. typed cli off reverts completely, and TYPED_CLIENT in the env overrides the choice for a one-shot run. Nothing else about your setup changes.

What carries over unchanged. The typed CLI reads the same configuration surfaces Claude Code does, so an existing setup works without rewriting anything:

  • CLAUDE.md discovery (user, project, .claude/, CLAUDE.local.md), including @import lines.
  • AGENTS.md, the client-neutral instruction file other coding agents read, from the project root and its ancestors. If a directory has both files and they differ, typed loads both (other tools stop at the first), so keep the pair identical if you switch between tools. AGENTS.md files below the directory you start in are not read; start in the package directory to pick one up.
  • settings.json permission rules: the same allow / deny / ask arrays and Tool(prefix*) syntax, merged from the same files.
  • Skills (.claude/skills), slash commands (.claude/commands), agents (.claude/agents), and hooks (nine events, with the same stdin-JSON and exit-code semantics).
  • Agent Skills standard skills from .agents/skills (project) and ~/.agents/skills (user), the cross-client layout other coding agents install into, including grouping folders and the standard frontmatter. Skills with a description are also catalogued for the model, which loads one by reading its SKILL.md when a task matches.
  • MCP servers from .mcp.json and .claude.json (stdio, Streamable HTTP, and SSE, with the same local > project > user precedence; a project .mcp.json loads once you trust the project), and CLAUDE_CONFIG_DIR everywhere ~/.claude would apply. A server that changes its tools mid-session (notifications/tools/list_changed) is re-listed before the next request.
  • The headless interface: -p, --output-format json, with the same envelope field names your scripts already parse.

What's different. The first-party client exists because some things work better when the client and the backend are designed together:

  • Deterministic permissions. Tool gating is rules-only, no model-in-the-loop safety classifier. Denials are reproducible and name the exact rule; one keystroke at a gate saves an allow rule for that command shape to your project settings.
  • /undo. Per-session shadow snapshots are taken before the first write to each file, so you can rewind a bad run even on a dirty tree, without git ceremony.
  • Live cost HUD. The status line shows your real session spend in dollars as reported by the server per request, plus token counts and your prompt-cache hit rate, not a client-side estimate.
  • Verification-cycle cap. The loop short-circuits the repeat-the-same-check spiral (re-running an identical command or re-reading an unchanged file past a small budget) and steers the model to either conclude or make a change. On by default; tune or disable with TYPED_VERIFY_CYCLE_CAP.

First-run note: the typed CLI asks before using project config it discovers, and hooks are opt-in at that prompt (they execute arbitrary commands, so they never run silently). Full reference: typed doctor, typed --help, and the typed CLI reference.

2. What works identically

  • Most coding workflows: refactoring, debugging, code generation, code explanation, test writing, doc writing.
  • Image input: paste screenshots, design mockups, error messages. typed accepts the same multimodal content shape Claude does.
  • Context window: ~950K tokens on the two upper typed++ rungs. The same ~950K applies to image-bearing (multimodal) requests, with no opt-in header, no model change, and no per-request configuration. Between those two rungs the choice changes reasoning depth, not window size. (typed++high is a separate model with a ~131K window, and the free local models are bounded by your own server -- see "Context windows by model" above.) Claude's current-generation Opus 4.6/4.7/4.8 and Sonnet 4.6 include a 1M window at standard pricing; current Haiku 4.5 and legacy Sonnet 4.5 cap at 200K.
  • MCP servers: if your client already mounts MCP servers against Claude, the same configuration works against typed.
  • Prompt caching: available on the hosted typed++ models. Most reliably engages on typed++xhigh; the other rungs cache on a best-effort basis. (The free local models cache in your own llama-server, not in ours.)

3. What's different

typed is a frontier-class model, not Claude.

  • Edge cases will differ. Most coding work feels identical; some won't. We encourage spot-checking on the workflows that matter to you.
  • Knowledge cutoff varies by underlying model. For recent libraries, frameworks, and APIs published after the model's training, paste relevant docs into the prompt.
  • No Claude artifacts (browser-rendered code previews). Keep Claude for that surface if you rely on artifacts heavily.
  • Billing structure differs. typed bills monthly. By default, requests past quota return a 429 with a one-click top-up prompt; opt in to auto-top-up in your dashboard if you'd rather skip the prompt and auto-charge instead. Claude resets every 5 hours and weekly. Different shapes; better fit for some workflows.
  • Coding-only product surface. typed is tuned for coding workflows. General chat and creative writing will work but are not the design target.

4. Sales-final policy (clearly disclosed)

All sales final. Cancellations take effect at the next renewal. The remainder of your paid period is served normally, and your API key keeps working until the period ends.

We process discretionary refunds on a case-by-case basis for billing errors or extended service outages on our side. Email support@typed.cloud. We do not promise an automatic refund window because cost-of-goods scales with usage, and we would rather be honest about the economics than build the refund into the price.

If you are not sure typed will work for your workflow, the right thing to do is pay for one month, try it for a week, and cancel before renewal if it does not suit you. The remaining three weeks of that month still serve normally. That is the trial.

5. Getting started

  1. Sign up at app.typed.cloud and pick a plan.
  2. The dashboard shows a one-line installer for the typed launcher (with your API key already inlined). Copy/paste, run, done.
  3. Run typed (or t) from any project directory. Usage appears in your dashboard within a few seconds of the first request.

If you would rather configure manually, set the three env vars from section 1 (ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_MODEL) in your shell or your client's config and run your normal client.

If you hit problems, email support@typed.cloud. Include your account email and the approximate UTC timestamp of the failed request. That is enough for us to find the trace.

Last updated 2026-09-09.