I refactor TypeScript codebases for a living, and in 2026 I finally have a setup where I can do meaningful refactors entirely on my own hardware. Not toy refactors. Real ones. Renaming a generic across files, lifting an interface into a shared module, switching a service from one dependency injection pattern to another. The kind of work that fails spectacularly when a model hallucinates a type or forgets which file owns the export.

This post is the result of weeks of testing local models on TypeScript repos with my RTX 5090 and a MacBook Pro M4 with unified memory. I will tell you which model I actually keep loaded, which ones look great in benchmarks but fall apart on real refactors, and exactly what to watch for when types start drifting.

Why is TypeScript refactoring harder for local models than Python?

TypeScript is unusually punishing for small models. A Python refactor often survives loose typing because the runtime forgives a lot. TypeScript does not. If a local model rewrites a function signature and forgets to update one caller, the compiler catches it. If it strips a generic parameter, every consumer breaks. If it invents a property on an interface, the entire chain of inference collapses.

Refactoring also means the model has to hold three things at once: the file it is editing, the type definitions that file depends on, and the files that import from it. That is a context problem before it is an intelligence problem. As I cover in my VRAM requirements guide for local AI coding, context length is the single biggest constraint on local coding, and TypeScript projects pay that tax twice because of declaration files and barrel exports.

Which local models did I actually test for TypeScript work?

I spent serious time with three classes of models on real refactors:

The first is the OpenAI 20 billion parameter open source model. It is small enough to leave headroom for a generous context window on a 32 GB GPU. On a clean problem, it generates at around 170 tokens per second on my 5090. It is also the model I default to when I need to ingest a lot of files at once.

The second is Qwen 2.5 Coder at 32 billion parameters. This is a stronger reasoner. On the same gym class generation prompt where the OpenAI model hit 175 tokens per second, Qwen ran at 42 tokens per second. Slower, but the output quality on coding tasks tends to be noticeably better when context fits.

The third is the same Qwen 2.5 32B running on a MacBook Pro M4 with unified memory. The M-series shared memory architecture is genuinely a different beast for local AI. A 48 GB M4 Pro effectively gives you 48 GB of VRAM, which changes the model selection calculus completely.

I also briefly tried the same workflow through Claude Code Router pointed at my local LM Studio endpoint, which lets you drive a local model through the Claude Code terminal interface. That setup is excellent for the editing experience but it does not change the fundamental ceiling of the underlying model.

Which model actually preserves TypeScript types across a refactor?

For real type-preserving refactors, Qwen 2.5 Coder 32B is the model I trust the most when context fits. It understands generics. It carries constraints across function boundaries. When I ask it to lift an interface from one file into a shared types file and update imports, it gets the imports right more often than the smaller models.

The OpenAI 20B model is competent but it makes a specific class of mistake that bites you in TypeScript. It will sometimes simplify a generic into a concrete type. The output compiles, the function works on the example you tested, and three callers later you find out the generic mattered. This is the failure mode I see most often on small models doing TypeScript work.

When I tried to push Qwen 32B with a 75,000 token context on my 32 GB GPU, the estimated VRAM hit 45 GB. That does not work on a 5090. LM Studio will let you load it anyway by spilling into shared system RAM, and at that point the model becomes unusably slow. My video feed actually started lagging during that test because I was thrashing the entire system. I cover this exact failure mode in my local AI coding reality check post because it is the single most common reason people give up on local AI coding.

The practical answer for a 24 to 32 GB GPU is Qwen 2.5 Coder 32B with a constrained context window of around 20,000 to 30,000 tokens, with flash attention and K cache quantization at F16 enabled. Those two flags shaved enough VRAM off my setup to make a real refactor feasible.

How does each model handle imports and multi-file refactors?

Imports are where local models reveal their limits. A multi-file TypeScript refactor needs the model to remember three things simultaneously: the new location of a symbol, every file that previously imported it, and the exact import syntax your project uses (named, default, type-only, barrel, path alias). Get any of those wrong and the compiler fails.

Qwen 2.5 Coder 32B is the only local model I tested that consistently handles all four of those import variants without hand-holding. It respects path aliases configured in tsconfig, it produces type-only imports when the symbol is only used as a type, and it updates barrel files when you ask it to.

The OpenAI 20B model handles named and default imports reliably but tends to lose path aliases. It will rewrite an import as a relative path even when your project uses an alias. This is fixable with a prompt that tells it to preserve the alias style, but it is one more thing to remember.

Anything below 20 billion parameters fell off a cliff for me on multi-file work. The smaller coder models can edit a single file but they get stuck in loops the moment a code agent like Kilo Code or Continue tries to explore the repository, because the agent burns context just to understand the file structure. That loop behavior is exactly what I cover in detail in my sub-agent strategies for local AI coding guide, which is how I work around the context ceiling for larger refactors.

If you want a curated set of TypeScript and Python projects sized correctly for local AI agent work, I keep a list of starter repositories I use for this exact testing.

Get the Local AI Starter Projects

What context window do you actually need for TypeScript refactoring?

This is the question nobody answers honestly. The default context window in LM Studio is 4,000 tokens. That is functional for a chat. It is useless for a real TypeScript refactor.

Here is the honest math from my own repositories. A modest sample app with a Python backend and a TypeScript frontend tokenizes to around 38,000 tokens for the full repo and around 9,000 tokens for just the source. A real production TypeScript codebase will burn through 30,000 to 50,000 tokens before the agent has even started reasoning, because the agent needs to read multiple files just to find where the change should go.

For agent-driven refactoring with Kilo Code, Continue, or Claude Code Router pointed at a local model, I aim for a minimum of 30,000 tokens of context and I prefer 50,000 when my hardware allows. Below 20,000 you will hit the loop-of-doom where Kilo Code keeps trying to condense an almost-empty context because it sees the ceiling approaching.

The trade-off you cannot avoid: more context means more VRAM, which means a smaller model. On 32 GB of VRAM you can have either Qwen 32B with a tight context window or OpenAI 20B with a generous one. I have settled on the OpenAI 20B with a 50,000 token context for agent work and Qwen 32B with a 27,000 token context for direct chat refactoring where I paste in the relevant files myself. My full reasoning on this trade-off lives in the local vs cloud LLM decision guide.

Is Ollama or LM Studio better for TypeScript refactoring in 2026?

Both expose the OpenAI-compatible API that every code agent expects, so the model you run is more important than the runtime. I use LM Studio because the GUI makes it easy to compare context windows and watch VRAM utilization in real time, which is essential when you are tuning for TypeScript work where context costs are unpredictable.

Ollama is the better choice if you want to script model swaps or run multiple models on a server. If you are setting up a development workstation specifically for local TypeScript work, my Ollama local development guide walks through the workflow I use when I want my local models reachable from multiple machines on my network.

The real point is that the agent on top, whether that is Kilo Code, Continue, or Claude Code through CCR, treats both runtimes identically. Pick the one whose ergonomics you prefer.

What about Apple Silicon for TypeScript refactoring?

Apple Silicon with unified memory is the underrated option for local TypeScript work in 2026. A MacBook Pro with an M4 Pro chip and 48 GB of unified memory can load Qwen 2.5 Coder 32B with a context window large enough for real refactors, and it does so quietly while drawing a fraction of the power my 5090 desk setup uses.

The catch is that token generation speed on M-series silicon is slower than a recent Nvidia consumer GPU, but for refactoring that is often acceptable. You are not generating thousands of tokens. You are generating a careful, type-correct edit. Speed matters less than fitting the context. If you are choosing hardware, my VRAM requirements guide breaks down exactly why unified memory architectures often beat dedicated GPUs for this specific workload.

What is my actual 2026 TypeScript refactoring stack?

Here is what I run today when I need to refactor a TypeScript codebase locally:

For agent-driven work where I want the model to explore the repo and propose multi-file edits, I run OpenAI 20B in LM Studio with a 50,000 token context window, flash attention enabled, K cache at F16, and Claude Code Router pointing the Claude Code terminal interface at my local endpoint. This gives me the editing UX of Claude Code with the privacy and cost profile of fully local inference.

For direct, surgical refactors where I already know which files matter, I load Qwen 2.5 Coder 32B with a 27,000 token context, paste the relevant files into LM Studio chat, and review every edit by hand before applying it. This is slower per token but the output quality is high enough that I rarely need a second pass.

For anything that touches more than five files or requires deep reasoning about architecture, I am honest with myself and reach for a cloud model. Local AI coding is real in 2026 but it is not yet a complete replacement for state-of-the-art cloud inference on the hardest problems.

Where to go from here

If you want to watch me set this exact stack up from a fresh install, including the LM Studio configuration, the Claude Code Router config, and the integration with Kilo Code and Continue, the full master class is on YouTube: Ultimate Local AI Coding Guide For 2026.

And if you want to learn how to run real local AI engineering in production, not just demos, join the AI Engineer community where I share my hardware setups, model evaluations, and the specific prompts I use for TypeScript refactoring: https://aiengineer.community/join.