Sebastian Raschka's new tutorial walks developers through building an on machine alternative to paid AI coding assistants like Codex and Claude Code, pairing a downloadable open weight language model with local tooling that reads files, edits code, and runs commands, and framing…
Earlier this year, Sebastian Raschka writes, Anthropic throttled its flagship model. He did not file a complaint. He opened a terminal and rerouted the same task through a language model he ran himself.
That moment is the working example behind his new tutorial, Using Local Coding Agents, and it tells you what the piece is really about. Not whether local AI tooling is 'better,' but whether a developer who depends on a paid service wants a fallback for the day that provider quietly changes the rules.
The stack Raschka lays out is unglamorous and concrete. Two pieces. First, an open-weight language model, meaning a model whose trained parameters are publicly downloadable, as opposed to accessible only through a vendor's API, that runs on the developer's own hardware. Second, a coding harness, the operating environment wrapped around the model that reads files, edits code, runs shell commands, and verifies the result. Together they form a complete coding assistant, similar in shape to Anthropic's Claude Code or OpenAI's Codex, except that nothing leaves the machine.
The architecture carries two reader stakes the source actually supports.
The first is cost collapse. Once the hardware is bought, the only ongoing operating cost is electricity. There is no per-token billing, no monthly seat fee, no 'pro tier' gating a feature the developer uses daily. Raschka's own framing, that hardware and electricity are the only costs, is the most defensible number in the piece. The tutorial does not attempt to quantify what local inference actually costs in watts, GPU hours, or break-even against a typical subscription plan, and neither should the reader.
The second is privacy by default. Source code, prompts, and any sensitive inputs (Raschka uses personal receipts as his example) never leave the machine. For a developer whose work touches proprietary codebases, internal repos, or anything covered by a customer's data-processing agreement, that is a structural property, not a marketing line. It is also the property that becomes most valuable the day a vendor changes its terms.
What the piece is not is a takedown of paid tools. Raschka is unusually upfront about the tradeoff. He still alternates between Codex and Claude Code as his daily drivers because Codex plan limits are currently generous enough that cost has not been a concern, and because frontier tooling updates faster than any local stack can keep up. He uses local setups for testing and for the enjoyment of running a fully local pipeline. That posture matters. A reader who treats the tutorial as a manifesto against subscription services is reading past the author.
The practical artifact behind the tutorial is the rasbt/local-coding-agent-evals repository, which holds reproducible evaluation assets and links to an agent-problem-pack defining the problem set the harness is tested against. For a developer deciding whether to take the local path seriously, the existence of a maintained eval suite is the difference between a personal project and a referenceable workflow.
The adjacent research thread is the arXiv paper Polar, 'Agentic RL on Any Harness at Scale', which argues agentic reinforcement-learning training can transfer cleanly between harnesses, including local ones. If that claim holds, the local stack stops being a hobbyist corner and starts behaving like a legitimate target for serious agent training. The tutorial does not depend on Polar to make its case, but the two artifacts together describe the same direction of travel.
For a reader who already followed Raschka's earlier piece, Beyond Standard LLMs, this is the build-it-once-and-use-it installment. The earlier article mapped the conceptual terrain: what a coding-agent harness is, what its core components do, why a developer might want to build one from scratch. The new tutorial assumes that map and replaces it with a working configuration.
The honest question the piece leaves open is not whether the local stack works, but where it stops being worth the operational weight. Frontier closed-weight models still lead on raw capability, and a local harness running on consumer hardware will not match them token-for-token. What the local stack buys is something the closed services cannot sell at any price: the knowledge that the developer's workflow is not one vendor decision away from a quiet throttle, a plan-limit change, or a usage-policy rewrite. For some readers, that is the whole point. For others, it is a complement to a paid tool, not a replacement.
Raschka's own answer is the latter, and the piece is more useful for saying so.