Serious AI Work That Never Leaves Your Mac: Draw Things' Local Code Goes Open Source

On October 28, the team behind Draw Things, the image-generation app, released its new app Local Code to everyone — and open-sourced the whole thing. It is a Mac-only AI assistant: you download it directly from its website, pick a model from a built-in selector, download that model onto your machine, and then write code, build slides, generate images and video, and tidy up spreadsheets and documents, all locally. No separate tool installations, no account signup, no API keys, no external MCP servers. Its homepage slogan says it all: "Serious AI work that never leaves your Mac." For anyone who hands code and files to cloud models every day, that sentence is the selling point. But the 376 GB download and the 64 GB-plus memory bar also spell out exactly what that sentence costs.

First, what Local Code is — and is not. It is not another terminal coding assistant, nor a Mac shell around a cloud chatbot. It is a graphical Mac app with Python, Node.js, a shell, and draw-things-cli built in; models run on your own GPU and tools run inside Apple's App Sandbox. The official release post lists a wide set of capabilities: generating images, videos, and sophisticated infographics with precise pie and bar charts using built-in Python; creating slides and explainer videos with rich motion graphics; writing Python or JavaScript, or simply reviewing your code; visiting websites, logging in with your credentials, and making appointments; connecting to Photos, Messages, Mail, Notes, and Calendar to summarize their contents or edit and reorganize them where supported; updating spreadsheets, reading Word documents, and making changes to PowerPoint files. The wider the capability list, the more its boundaries matter — and this article examines them one by one.

Three models, three bars, priced in disk and memory

Local Code does not sell models; it lets you pick one to match your machine. The release post gives three quantified options. The smallest is Qwen 3.8 27B: 27 billion parameters quantized into a 10 GB package, suited to Macs with 16 GB of memory or more. The middle option is DeepSeek 4 Flash 0731: a 304-billion-parameter, text-only model quantized into an 89 GB package, suited to Macs with 48 GB or more. The largest is DeepSeek 4.1 Flash 1017: 763 billion parameters quantized into a 376 GB package that, by the vendor's account, needs only about 36 GB of resident memory, processes prompts at roughly 350 tokens per second, and generates at roughly 18 tokens per second, suited to Macs with 64 GB of memory or more.

Two details in those numbers deserve scrutiny. First, the release post says the top model is "suitable for Macs with 64 GB or more," but the official website's model table lists its recommended memory as 96 GB and its minimum as 32 GB; the middle tier is listed on the site as 32 GB minimum and 64 GB recommended, versus "48 GB or more" in the release post. The same company's two documents do not fully agree. The sensible reading: 64 GB will run it, but 96 GB is the comfortable zone the site recommends; if you only have 64 GB, do not expect the release post's speed figures to reproduce exactly. Second, 376 GB is not a casual download — it approaches half the disk of an entry-level Mac. SSD streaming can keep part of a model on disk and load it as needed so smaller Macs can run big models, but that does not shrink the disk footprint. Checking free space before downloading is the most practical first step.

Local use is free — the clearest sentence in the official pricing. Optional cloud access costs extra: your own API keys, or prepaid credits starting at $9.99. The Teams tier is listed as "let's talk," covering setup, custom skills, and on-premises deployment. The business logic is easy to read: on-device models cost nothing; what you pay for is what the device cannot run, or what you do not want to wait for — cloud models billed per token, keys you bring yourself, no vendor markup. The boundary of "free" is drawn right there: free means "running on your own hardware," not "unlimited intelligence."

How far does "never leaves your Mac" actually hold

Local Code's privacy promise rests on two pillars: local inference and the system sandbox. Local inference means that with a local model, your prompts and files are processed on the machine and not sent to a cloud AI provider. The sandbox means the whole app runs under Apple's App Sandbox and Hardened Runtime: it can use folders you share with it and run built-in Python, Node.js, and shell tools, but it cannot read your entire disk, launch other apps on its own, or use the cloud unless you choose to. MacRumors' coverage repeats the same point: according to the official documentation, the App Sandbox restricts the app's access to files and other parts of the system.

But the word "sandbox" is easy to over-read, so here are three cold showers. First, a sandbox governs what the app can reach, not what you voluntarily hand it — the moment you share a folder with it, or let it log into a website or connect to your mail and calendar, you are widening the boundary yourself. The release post's "visit a website, log in with your credentials, and make an appointment" is precisely the capability that deserves the most caution: it means your login sessions pass through the assistant's hands. Second, cloud mode is user-selected: once you pick a cloud model, prompts and relevant files go to that provider, and the local promise stops applying at that moment. Third, open source is not the same as reproducible builds. A secondary analysis notes that Local Code's source does include the app, its command-line tools, and the libraries behind them, synced from the private development repository — but the Mac app is a Mac Catalyst build that needs an unpublished patched version of Bazel to build, so it cannot yet be fully built from source; the LocalCodeCLI variant runs without signing. The value of open source here is "the code can be inspected," not "anyone can compile the identical app from scratch." Do not confuse the two.

One vendor claim needs its own flag. The release post says DeepSeek 4.1 Flash 1017's "frontier-level intelligence surpasses GPT-5.6 Sol on many benchmarks and in real-world use cases," and that the team ran the same benchmarks on these models with results closely matching the officially reported ones, with no regression in intelligence from quantization. These are the vendor's own claims, and no independent third-party measurement has been seen to back them. Quantized-model benchmark scores are especially sensitive to test conditions; readers should treat this as "vendor claim," not "verified conclusion."

How it compares with cloud assistants

Measured against cloud coding assistants on the same yardstick, the result is not one-sided — four categories split. First, privacy and compliance: local wins cleanly. Code, prompts, and files stay on the machine, so the hardest question in an NDA or compliance review — "will data go to a third party?" — can be answered "no." But that victory has a boundary: it holds only in local-model mode, and the moment you switch to a cloud model it is handed back.

Second, model freshness: cloud wins cleanly. Cloud models can update weekly or even daily; a local model update means re-downloading tens to hundreds of gigabytes. Draw Things' three models are quantized versions from the second half of 2026 — good enough today, but whether they stay current depends on the team continuing to ship new quantized packages. Buying into a local model is, in a sense, buying a snapshot of intelligence at a point in time, not intelligence that is always newest.

Third, latency and availability: local wins in specific situations. Prompt processing at roughly 350 tokens per second and generation at roughly 18 tokens per second (vendor figures, top model) are adequate for everyday coding and document work; more importantly, it does not depend on network quality and keeps working offline. A cloud assistant is faster when the network is good, may queue at peak times, and is simply unavailable with no connection. For people who travel often or work in weak-network environments, this category weighs heavier.

Fourth, tool permissions and trust model: the two take different roads. A cloud assistant usually runs in your terminal with your user identity and broad permissions, and you set the guardrails yourself; Local Code confines its tools in Apple's sandbox, so by default it can touch less. That is good for ordinary users — the ceiling on mistakes is lower — and potentially constraining for power users, who may find the sandbox refuses things they want done. Which is better depends on whether you fear "it does the wrong thing" more than "it cannot do the thing." For vibe coders, my suggestion is to treat Local Code as a lower-privilege second pair of hands, not a full-privilege replacement.

The cost ledger needs to be complete too. A cloud assistant bills monthly by subscription or usage; Local Code's bill is one-time hardware and disk: a 376 GB download, 64 GB-plus of memory, and a download wait that may run for hours. If you already own such a Mac, the marginal cost is close to zero; if you would buy a machine for it, that purchase belongs in the same comparison as two or three years of cloud subscription fees. Free software does not mean free use — disk and memory are its price tags.

From download to first task: do it in this order

Step one is downloading the app itself. Get the direct download from getlocalcode.app; the Mac App Store release is officially "coming soon," so direct download is the only option today. After installing, before picking the biggest model, check two things: how much memory your Mac has, and how much disk space is free. Around 16 GB of memory means Qwen 3.8 27B; 32 GB opens the middle tier; only 64 GB and up should touch the top tier. Free disk space should exceed the model package size with at least 20 GB to spare, because downloading and unpacking temporarily consume extra room.

Step two is downloading the model. Models come from the built-in selector — no hunting for weight files elsewhere — which is the most concrete part of "works out of the box." But estimate the download time honestly from your connection speed: a 376 GB package takes well over ninety minutes even on a 500 Mbps connection, and the Mac should not be allowed to sleep and drop the network mid-download. Start it in the evening and use it the next day. Once downloaded, the selector will recommend a model based on your machine's memory; that recommendation can be trusted, but if disk is tight, manually choosing one tier smaller is no disgrace.

Step three is permissions, and they should be stingy. The first time it asks for folder access, grant only the current project's directory — not the whole home directory or the whole disk for convenience. The sandbox only means something if you respect its granularity; handing over everything dismantles it by your own hand. Likewise, when first connecting mail, calendar, or photos, try a throwaway account or an empty calendar first, confirm the results match expectations, and only then connect your main accounts.

Step four is verifying the cloud switch. By default, cloud models are off — the official line is "off unless you pick one." But the first time you open model selection or settings, it is worth confirming with your own eyes: is the currently selected model a local one, and is any feature quietly routing to the cloud? The check takes 30 seconds, yet it is the only part of the whole privacy promise that requires your own verification.

Step five is the first task. Do not throw an entire repository at it on day one. Give it a tightly bounded small task: review a function under 200 lines and name three improvements, or tidy a messy table into a version with totals. Judge two things: whether its changes are correct, and whether it touched any file you did not authorize. Only widen the task range once that first impression passes.

Three vibe-coding scenarios worth trying first

The first is local code review. Sending a private repository's code to a cloud model for review crosses a line for many people; a local model has no such line. You can ask it to check boundary conditions in a module, hunt for null-pointer and out-of-bounds bugs, or write comments for legacy code. But keep expectations tiered: the entry-level 27B model is fine for catching low-level mistakes and readability problems, not for architecture-level review; only the top tier is worth throwing at complex logic. And human re-checking stays mandatory after review — local models hallucinate problems just as confidently as cloud ones.

The second is offline documents and demo materials. Writing READMEs, organizing changelogs, and turning scattered data into infographics with precise charts are tasks with middling intelligence demands and high privacy demands — exactly the local model's comfort zone. The release post's emphasis on "precise" pie and bar charts is a detail worth noticing: many models invent numbers when drawing charts, and Local Code's claim to precision suggests it generates charts through built-in Python computation — numbers calculated, not drawn. You can verify this yourself: ask it to chart the same dataset twice and check whether the numbers stay stable.

The third is a second opinion. After a round of development with your primary cloud model, let the local model independently review the key changes. Two models with different perspectives often catch each other's misses. This use does not require the local model to be stronger than the cloud one — only independent, cheap, and always available. Positioned as "a free second pair of eyes," expectations land in the right place.

Bottom line: Local Code's most valuable contribution is not the size of the model it runs, but turning "local AI assistant" from a slogan into an out-of-the-box product — no runtime to install, no keys to configure, no MCP to assemble, one download and you start. Its shortcomings are equally concrete: disk and memory bars, inconsistent memory figures across its own documents, benchmark claims without independent verification, and source that cannot yet fully reproduce the Mac app build. If you happen to own a big-memory Mac and have code that should not go to the cloud, it is worth an afternoon's trial. If you expect it to immediately replace a flagship cloud model on heavy work, start with small tasks and do not hand over the whole repository on day one.

Source note: core facts come from Draw Things' official release post (October 28, 2026, including the three models' quantized sizes and memory bars, the capability list, and the open-source repository address) and the Local Code official website (pricing, model table, sandbox description). MacRumors' October 30 coverage was used only as a cross-check (public beta began September 12, cloud credits from $9.99, App Store release coming soon) and is not listed as a formal source. Vendor benchmark claims are flagged as vendor claims in the text; the memory-figure discrepancy between the website's model table and the release post is stated as found; the "cannot yet be fully built from source" point comes from a secondary analysis and is identified as such.