Using Claude Code for embedded work

[peter-h]

This is a reasonable tutorial - just 30 mins of your life



I can think of several reasons why I could not use it, starting with Claude probably being unable to run my code, although I am not actually sure whether some "integration" might be possible. I also do not use git and have no interest in it (have my own version management and backup scheme).

It reportedly works well for web app development, because these are easy to test.

I do use Claude for "fetching" algorithms, checking my code for stupid errors, and generally helping out. And there is really does improve productivity. But the overall file is still written by myself, to do what I want. With Claude Code you have to give it your entire project source.

[langwadt]

With Claude Code you have to give it your entire project source.

no you don't, you a can easily use to write snippets of code

[abeyer]

I can think of several reasons why I could not use it, starting with Claude probably being unable to run my code, although I am not actually sure whether some "integration" might be possible. I also do not use git and have no interest in it (have my own version management and backup scheme).

If you have your own tools for build/version control/etc... available from the command line, you just need to write up a markdown file with instructions for how to use them and that's the "integration" that claude code needs.

[hans]

I use(d) OpenCode in combination with a local LLM (Qwen3 Coder). I've heard good stories with people using with Claude too. You can use a whole ton of different AI backends..

OpenCode has a few MCPs with local access (like list files, view file content and edit file content).
[unfortunately] also to bash for listing/finding files. But so far so good (fingers crossed)

If you give OpenCode a narrow enough prompt it will only look for relevant code, read it, and make modifications. OpenCode also has a Plan and Build mode, so it won't (or shouldn't) start doing things if you just give it a prompt to sketch things out.
Even then if you use version control, commit beforehand and let it do its thing. You're free to discard any changes you don't like..
That is if OpenCode stays in your target directory. I should check if it has some guardrails for that.. and not run rm -rf / --no-preserv-root.

I asked OpenCode to take a look at my codebase, and then it will scan through half of my project files. If I was to use an external provider, it would all be uploaded. But there is still some filtering behind this.. it won't scan every file when it presumes something is some scafffolding code.
The problem I foresee with local LLM is context window size. I can put up Qwen3 Coder up to 256K tokens, but I need to run the 80B model at Q4 or Q6 to make it fit in 128GB of (unified) RAM on my Mac M4 Max. It also takes forever to "Prompt Process" that many tokens, as OpenCode can run a dozen prompts at this context size. I believe newer M5 Max have "up to" 4X PP speed.
So I also use Qwen3.5 35B model now, at ~80-100K tokens, its a lot more responsive. But I see LMStudio reporting its often discarding a ton of tokens between the dozen or so prompts it runs.

I still want to explore more. When I started out with OpenCode I had it do some simple modifications in a C# project. When you then have to wait 2-3 minutes between each prompt, my ADHD brain instantly zones out and I thought; hmm, normally I find programming fun because it sucks me in perfectly and whatever modification I make has instant results when I run it.
Is programming with 2-3 min delay fun? No I do not. Can I do something else in between these prompts? No I cannot.

But I'm interested to see if it is possible to sketch out an architectural document ('implement every message of this uBlox GPS receiver') and then have AI rip for little while in a sandboxed environment... Adafruit had some videos on their channel the other day with this exact scenario. I think they ran OpenClaw on a Raspberry Pi.

[SpacedCowboy]

I used Claude code to write an optimising compiler that produces 6502 code, targetted primarily at the atari 8-bit though it also pays lip-service to the C64 and has a generic linker-script approach to how it works. I gave it a custom (5-byte) float and (8-byte) double format to work with, and told it I wanted "bank switching" automatically enabled so functions could be put into banked RAM. I was thinking about the "xe" variant, but Claude made it generic so it worked with the Compy and Rambo 3rd-party expansions that extended the original atari bank-switching technique.

I told it I wanted the "shadow RAM" that was available "underneath" the ROM at $C000-> available for programs at all times, and it told me that would interfere with all the interrupt-driven parts of the atari OS (true, I knew that but was planning on writing an NMI interrupt-handler that swapped the OS back in just-in-time for interrupts to work then swapped the OS back out). It did it for me, figuring out the vectors to modify, downloading a simulator it could test with that reported state to stdout, and going through trials to make sure the generated code actually ran. I didn't directly ask it to do that...

I started writing a doc to keep myself up-to-date with what the language could do, and so (when I release it) there's some instructions to make it useful. Claude noticed the file, realised what it was, and started updating it itself when I asked it to make more changes.

The point is, if it can do that sort of R&D on a 40+ year old architecture, it can probably know about the ins and outs of a modern one, and even if it failed to ingest the datasheet of your $obscure-manufacturer part, just feed it in as part of the prompt process.

I will say that "write a compiler" was beyond the local models I tried - and I'm running on a Macbook M4 Max with 128GB of RAM so I could play with some large local models. 122B Qwen3-Coder 3.5 was the best of the bunch, but it still wasn't even close to the Claude results. Night and day.

I'm very happy with the compiler. Here's the "help" output:

Code: [Select]

simon@M4MBP doc % xtc -h
Usage: xtc [options] <input.xt ...>

Options:
  -a, --assemble-only        Compile to .asm module (no runtime)
  -D <name[=value]>          Define preprocessor symbol
  -E, --preprocessed <path>  Write preprocessed output to file
  -Fli, --fn-leaf-inline <n> Max leaf-function size to inline
                             (default: 100, requires -O2+)
  -Flu, --fn-loop-unroll <n> Auto-unroll counted for-loops with trip
                             count <= n (default: 5 at -O2+, 0 otherwise)
  -H, --xtc-home <path>      Set xtc home directory
  -h, --help                 Show this help
  -I <path>                  Add include search path
  -O0                        No optimisation (the default)
  -O, -O1                    Peephole + register tracking
  -O2                        + const prop, dead code/store elim, tail call
                               opt, leaf inlining, loop unrolling (<=5)
  -O3                        + branch inversion, strength reduction,
                               cross-function DCE, label cleanup
  -o, --output <path>        Output file (.asm or binary)
  -q, --quiet                Suppress informational output
  -Q, --quit-style <which>   Action after main() returns: rts (default), loop
  -S, --xtc-stack            Use xtc software stack globally
  -falloc=bump|heap          Heap allocator: bump (fast, no free)
                             or heap (coalescing free-list, supports
                             delete). Default: heap on targets with a
                             dedicated heap region, bump elsewhere.

Platform options:
  -m <layout>                Load a memory layout (.lnk file). Searches
                             for <layout> as a file path (appends .lnk
                             if needed), then support/layouts/<layout>.lnk
                             Default: xl
  --dump-layout              Print memory-map diagram and exit (use with -m)
  --list-layouts, -ll        List available built-in layouts by platform

Warning options (-Wno-<category> to suppress):
    new-in-loop              new inside a loop body (leaks)
    escape                   stack-addr stored in longer-lived slot
                             (global, heap field, outer scope)
    class-init               bad initialiser on stack class
    asm-clobbers             asm{} clobbers annotation mismatch
    unknown-annotation       unrecognised function annotation
    unknown-pragma           unrecognised # directive

Function annotations (after params, comma-separated):
  Calling convention / prologue:
    : hwStack                Force 6502 hardware stack
    : xtcStack               Force xtc software stack
    : naked                  No prologue/epilogue (for ISRs)
  Interrupt handlers (mutually exclusive with :naked):
    : irq                    IRQ handler; OS-safe prologue, RTI epilogue
    : vbi                    VBI handler; same shape as :irq, runs each
                             vertical-blank (install via Vbi.install)
  Placement (where in the memory map the function lives):
    : main                   Force into the main (always-visible) region
    : banked                 Force into a bank page (banked targets only;
                             incompatible with :irq / :vbi)
    : shadow                 Force into shadow RAM under the OS ROM
                             (xl-shadow / xt-shadow / xe-shadow only)
  Shadow-target helpers:
    : needsOS                Wrap body with ROM enable/disable on shadow
                             targets (no-op on non-shadow)
                             (all annotations are case-insensitive)

Output format (determined by -o extension or [output] in .lnk):
    .asm                     6502 assembly source
    .xex .exe .bin .com      Atari XEX binary
    .prg                     C64 PRG binary

Support file search order:
    -H > $XTC_HOME > cwd > ~/xtc > /usr/local/xtc > /opt/xtc

And here's that md-file doc to give an overview of what the language can do (huh, can't upload a .md file, ok here it is as .pdf)
 xtc.pdf (179.8 kB - downloaded 73 times.)

[woofy]

This thread should be in the AI section.

Claude code is quite able to write, edit, compile, flash, run and debug programs. Plug a Nucleo board in and try it.

[SpacedCowboy]

Shows how behind the times I am - I wasn't even aware there *was* an AI section

[gmb42]

If certain folks did use it, the S/N of threads may improve by a tremendous amount.

[5U4GB]

Just had a look, it's here BTW, and it seems to be 99% politics and economics of AI, while this thread is about technical use of AI.  I think it's probably better here where it's on-topic for embedded.

I use Claude as a back-seat driver to check code, alongside Coverity, PVS Studio, the clang analyzer, and others.  I'd never use it to write code but it's a really powerful tool for looking at your code and saying "hey, about this bit over here...".

[peter-h]

That is how I use it, but I am on the free version, so not Claude Code.

It dumps me after only a few interactions, or even just one involving looking at some source file, so I get one go every few hours. I set up a second Claude account (using a different email) and that strategy works. Often, one checks the output of the other and the result is really interesting! So when one of them cuts me off until time xx:xx I can just switch to the other one.

ISTM that if you use Code (i.e. pay the £18/month or so) you are able to send it more source code to work on. Or maybe it actually does more. Yesterday I was running a 2008 VisBas program (a weird thing which script-drives another ancient commercial application to generate loads of PDF reports; written by an ex-M$ guy, runs only under win2000 so running in a VMWARE VM) which bombs out at a specific point. I uploaded the VB source code to Claude, together with the logged error message, and it suggested some debugs one could put in to narrow it down (I need to work out how to build this thing!) but that was as far as it went.

Last week I developed what is basically a data acquisition and timing product (based on my existing 32F417 project which I plan to use for absolutely everything for the rest of my life because I am never going up that horrid learning curve again ). It does some funky stuff like using the RTC for hh:mm timing, and doing some funky stuff like not zeroing the timer if the power was lost for less than 5 mins. This involves saving the RTC hh:mm in an RTC RAM location (as a packed uint32_t) every 1 minute and then you can tell how long the power was off for (the RTC itself runs off a ~1 week 0.47F supercap). Claude completely correctly worked out the logic and came up with code for other features I wanted. It correctly addressed stuff like computing hh:mm difference, with handling of the midnight rollover case.

The only indication that it is not a formal code analysis program, but rather a "pattern recogniser", happened when I had

// uint32_t count=6;
uint32_t count=7;

and it insisted count is initialised to 6 I gather "computer scientists" continue to be amazed how far it gets without actually understanding anything

What I don't get, looking at the above video, is how it works with embedded, where it obviously cannot run the code and see the result. You have to give it the files, it looks at them, generates code for whatever new feature, etc. You then edit the suggested code back into your sources (in Cube IDE in my case). And you don't need Code to get that functionality.

[paulca]

A chatbot goes through input filtering the code bots don't.  The code bots have dedicated code analysis/parsing agents, chat bots might if you are lucky.

These threads contain far too much "I think", "I guess", "I haven't tried yet."

I'm going to stay out of them until that is fixed.

STOP speculating and go and use it, the proper one, not the "magazine cover disk" free version.

And peter-h.  When you complain that things are difficult and people give you solutions... why do you insist on saying, "Does not apply, I have my own way of doing things."   This is not how engineering works mate.  The work "Practice" is not meant in the context of violin.  We (developers) have a shared responsibility to the practice and keeping it forward faced.  "Best practices" suggest there are others.

[paulca]

I posted a thread in here about what happened when I gave claude a tiny prompt like: "What does this do?" in my STM32 Soft-DSP project folder.

Start with something like that.  Then just ask it questions, chat with it about the code, then tell it about something which has annoyed you or something you have wanted but never got round to.

Let the magic happen.

EDIT:  However.  The first resistance point I expect is going to be:  "Where do I run this code bot then?"

The best answer is in a Linux bash terminal.  That's going to push a lot of less serious devs nose out.

GitBash is too thin.  Powershell ... works, but that's debabtable with or without Claude.  Powershell == DotNet CLI.  You need to learn DotNet to use it.

Cygnwin I am told is not worth the effort. 

So for our windows only peers, WSL is the next best thing.  That's going to be painful on Windows 7. 

Which ends us with a VM running Linux.   That's a bit of an environmental reconfigure which will either require really tight, really well done networking (for code base open in both claude and CubeIDE) or tight disipline on the version control to push and pull between them.  NOT advised.

I think the best option, though no where near "ideal" is going to be an IDE extension.  There will 100% be a claude code extension for Eclipse by now.  Has to be.  If there is, then Claude will get access to the IDE API and can directly action the build within Cube... and see the output logs when it flashes and runs it's tests.  For me this part is speculation.  I don't use Windows anymore.  Save for gaming.  I have used Claude Code in VSCode extension and it supports terminal mode, but the underlying OS is Linux or MacOS.  So bash or zsh shell.

[Siwastaja]

peter-h, you should really give Claude Code a try. With your posting history, I believe it's exactly what you need - relatively complex codebase you have to maintain nearly alone, you want to understand details, make modifications here and there; you have a lot of questions.

In project like yours, copy-pasting snippets between a chatbot really does not work. That works for creating isolated small tools etc. You need a coworker who learns the codebase and uses tools. That's exactly the Claude case.

Pay for one month with the cheaper $20 license and give it a shot. Just /init on your project and then give it a few hard questions, something you would normally post here. You will be surprised how well it works and actually starts to solve your problems.

It's exactly the eager and pretty capable junior engineer you need in your team. Expect that it's available ~97% of the time, not 20% like a full-time hire human being (or 5-10% of part-timer). And the cost is $100-$200 / month, depending on how much you use it. The $20 license is only sufficient for serious enough initial testing or occasional small fixes.

[peter-h]

Just /init on your project

What is that?

I am running win7-64. Obviously I can run a terminal window but if Claude Code needs to run some local executable...

[5U4GB]

I set up a second Claude account (using a different email) and that strategy works.

For anyone else thinking of doing this, beware that they require you to provide a mobile phone number for SMS verification and you can only use that number once.  If you set up two accounts, you'll need two separate numbers, and it often doesn't work outside the US/Europe.  There's a 700-message thread in the Claude github repo on this.

[SpacedCowboy]

I'm not familiar with Windows, but on a Mac I just use terminal to interact with Claude.

You download the installer, which will set up Claude Code (just type "claude" in Terminal.app). Do that from within the source directory because its going to cache a bunch of stuff there for future use. Plus you'll benefit from having a doc/ folder for it to write .md files to as it evolves solutions, comes up with things to fix in future etc. You can tell it to write whatever it needs to, to a file, so it can pick up on the bug it just found later on. It can be quite informative to read some of those files.

Anyway, once in the terminal, it will read/write files continuously- source files, docs, tests, you-name-it. It can also run executables - and it will. The standard approach it takes is "try, write regression test, verify by actually running". In my case above, it realised it needed a 6502 simulator, so it wrote one and then used it. It runs xxd to dump files in hex to verify what's in a file is what it thinks ought to be there. It can pull down documentation from the web (or you can feed it the same). It really is like interacting with a developer, over a terminal instead of over the phone.

Try it, the actual Claude Code version, not the web chat. It's a brave new world. Here's a sample just by cutting/pasting from the terminal window as I type this reply:

Code: [Select]

                                               
⏺ Bash(timeout 5 ./bin/osx/xts -m xe /tmp/hb.xex 2>&1 | tail -100 | head -30)   
  ⎿  A=00 X=00 Y=01 SP=F9 ----ZC | B659: STA $B685      | A=00 X=00 Y=01 SP     
     =F9 ----ZC                                 
     A=00 X=00 Y=01 SP=F9 ----ZC | B65C: LDY #$00       | A=00 X=00 Y=00 SP     
     … +30 lines (ctrl+o to expand)                                             
                                             
⏺ Bash(timeout 10 ./bin/osx/xts -m xe /tmp/hb.xex -M 100000000 2>&1 | tail -15)
  ⎿  A=A0 X=61 Y=00 SP=FD -V---C | AE11: BNE $AE15      | A=A0 X=61 Y=00 SP   
     =FD -V---C                                                                 
     A=A0 X=61 Y=00 SP=FD -V---C | AE15: LDA $D301      | A=22 X=61 Y=00 SP     
     … +18 lines (ctrl+o to expand)             
                                                                               
⏺ Bash(timeout 15 ./bin/osx/xts -m xe -d /tmp/hb.xex 2>&1 | tail -10)           
  ⎿  sim6502: xe mode (1 bank segments)         
                                                                               
⏺ Bash(timeout 15 ./bin/osx/xts -m xe -g0 /tmp/hb.xex -M 50000000 2>&1 | tail   
      -20)                                     
  ⎿  |                                        |                                 
      |                                        |                                 
      |                                        |                         
     … +17 lines (ctrl+o to expand)                                             
                                                                               
  Read 1 file (ctrl+o to expand)                                         
                                                                               
⏺ Bash(sed -n '8998,9015p' /tmp/hb.lst)                                       
  ⎿    610E                   TAX                                               
        610F                   PLA                                       
        6110                   RTS                                               
     … +15 lines (ctrl+o to expand)                                             
                                                                               
⏺ Bash(bash tests/run_fixtures.sh 2>&1 | grep -E "heap|retain" | head -10)     
  ⎿    PASS  heap_basic             xe-heap  O2   (13 tests)                   
        PASS  heap_basic             xe-heap  O3   (13 tests)                   
        PASS  heap_retain            xe-heap  O2   (6 tests)                     
     … +7 lines (ctrl+o to expand)                                             


This is Claude tracking down (and fixing, as I type) an obscure memory-banking bug where it had to go refactor the heap-helper code for when a recursive function had managed to get more than 255 iterations down, and the index,Y addressing mode for access to the bank-switch register wasn't working.

[5U4GB]

you are able to send it more source code to work on.

Just be aware that unless you've got the setup configured just right, you're giving Anthropic the right to train the model on your code, which means your code could end up in other companies' products.

[5U4GB]

Just /init on your project

Opinion is divided on the subject:



Claude takes a guess at what's needed and can end up burning a lot of tokens and wandering off in the wrong direction if it guesses wrong.  Starting with a well-written CLAUDE.md is a better approach.

[Siwastaja]

Claude takes a guess at what's needed and can end up burning a lot of tokens and wandering off in the wrong direction if it guesses wrong.  Starting with a well-written CLAUDE.md is a better approach.

I totally agree, but it's a good introductory lesson for a beginner. Maybe it's better to ask "hey, I'm new to this thing, analyze the whole codebase, tell me how it works and suggest what could be done".

For me, CLAUDE.md generated by /init had maybe 2/3 unnecessary content which needed cleanup (like unnecessary build commands I hadn't used in 3 years and had forgotten myself), and lacking the user insight which you need* to add anyway - maybe better /init would interrogate the user and write CLAUDE.md based on that. And too much technical details about things Claude can (and should) just check when relevant.

Then again, it does not actually hurt enough to be a real concern... As always, this AI thing is flexible and tends to work out and arrive at stable and decent outcome nevertheless.

*) or rather, "might want" - the strength is exactly that you don't need to follow any specific process! Nearly anything works out in some useful way.

[peter-h]

Just be aware that unless you've got the setup configured just right, you're giving Anthropic the right to train the model on your code, which means your code could end up in other companies' products.

Indeed, this is a known issue with any system "learning" from sparse data.

According to press reports, some companies, notably legal ones, have banned staff from using “AI” for client work, because the server is obviously storing the query, and its computed response, and is likely to serve this to another user, in another company, which somebody also contacted for legal advice on the same scenario, and the client could work out that the other party to some litigation obtained such and such advice. This is the standard weakness of large scale data collection / pattern matching, if the sources for your specific query are very sparse. So e.g. if you ask it the maximum voltage rating of a BC109, there is no leakage issue because you can find that in 1000 data books, all of which are accessible to “AI”. But if you ask it for ways to circumvent patent (number xxxxxxxx) then two clients working the same server are more than likely to be served the same advice.

So if you have done code which does something obscure, it is likely to get fed to multiple users.

I don't want to bugger up my source code... Does Claude Code install a windows executable application which communicates with Claude, and has access to a specified directory on your PC? All examples I see are linux or Mac based.

[5U4GB]

According to press reports, some companies, notably legal ones, have banned staff from using “AI” for client work, because the server is obviously storing the query, and its computed response, and is likely to serve this to another user, in another company, which somebody also contacted for legal advice on the same scenario, and the client could work out that the other party to some litigation obtained such and such advice.

It also works in the other direction, you could end up with someone else's copyrighted work in whatever you're generating with the AI.  This is at least as big, or an even bigger, headache for companies operating under strict legal regimens.

Most enthusiastic users of AI have no idea that this is an issue, and no policy to handle it.  It's going to take a SCO-vs-IBM scale lawsuit before anything changes.

I don't want to bugger up my source code... Does Claude Code install a windows executable application which communicates with Claude, and has access to a specified directory on your PC? All examples I see are linux or Mac based.

The general advice if you're running Claude locally is to run/lock it inside a VM.  I use the web version because that has no access to my local filesystem, or indeed local anything.

[langwadt]

According to press reports, some companies, notably legal ones, have banned staff from using “AI” for client work, because the server is obviously storing the query, and its computed response, and is likely to serve this to another user, in another company, which somebody also contacted for legal advice on the same scenario, and the client could work out that the other party to some litigation obtained such and such advice.

It also works in the other direction, you could end up with someone else's copyrighted work in whatever you're generating with the AI.  This is at least as big, or an even bigger, headache for companies operating under strict legal regimens.

yeh, something like: I've seen this XX opensource project but I don't like the license, can you write something that does the same?

and magically you have something that does the same with what ever license you like ...

[voltsandjolts]

and magically you have something that does the same with what ever license you like ...

With whatever license you're willing to take legal responsibility for, the AI supplier washes its hands of it. Also, it seems that for many jurisdictions, AI outputs may not be copyrightable, which removes the legal basis of your chosen license, and the code is public domain. Human prompts into an AI are likely copyrightable. AFAICT IANAL.

e.g.
https://pec.ac.uk/blog_entries/copyright-protection-in-ai-generated-works/

AI has spat out other folks code verbatim so there will likely be some sort of legal case about this soon enough.

[peter-h]

I use the web version because that has no access to my local filesystem, or indeed local anything.

Are you using Claude Code in this way?

you could end up with someone else's copyrighted work in whatever you're generating with the AI.

Most people doing this forcefully argue that any output from "AI" is public domain, and if it is a close paraphrase of some (sparse) source material, that is fine also, and in any case protected by any "fair usage" policy

Keeping this specifically on the embedded topic, I've seen some weird code which I think it "found somewhere". Claude has a reputation, reportedly, for getting stuff primarily from github, and in that sense it is useful because extracting a piece of self contained working code from github is generally nontrivial, IME. Now github is probably PD, but you don't actully know that, because if somebody uploaded some copyright code, who will find out? I know for a fact that there are systems out there doing searches for copyright material: I run a community site and recently we got pursued by some copyright protection agency for a photo somebody posted 5 years previously; I told them to F off because forums are specifically protected under GDPR provided the material is removed within ~5 days. Github, thus attacked, will probably silently delete that file...

[hans]

I will LOL for the day when a LLM will just "let me look for API keys on Github" and finds a few for rate-limited APIs like Octopart, Mouser, etc.

Anyhow, I don't expect code from LLMs to be of amazing standard. But most code shouldn't be written like its your life work. It should implement a feature, in an easy to read way, with good maintability. When projects grow, its usually hard to keep an overview if you're working alone.

Fwiw:
This is one of the first things I tried to use OpenCode for. I have about 44K LOC project here (18K main, 8.5K infrastructure, 15K test and the rest are sandbox/tools), and it does a fair job at finding code smells for me and making suggestions for large refactors.
Since my last post, I moved over from OpenCode as GUI to OpenChamber. Its not completely bump/bug-free, but at least I get prompted before running a particular tool (like bash or editing files). It also seems to automatically delegate smaller tasks to subagents like "explore" which run in a new context, and thus run faster.
I switched over from Qwen3.5/Qwen3Coder to Gemma4 31B. Iirc Qwen3.5 is a Mixture of Experts model, which means only a few B parameters are active at a time. It ran fast but was hallucinating like crazy. It spend a full hour running in circles adding code, seeing the build fail, then making silly changes and eventually giving up. Then when I gave suggestions how to fix it, it just tossed everything and "tried again".
Gemma 4 seems to be making very solid forward progress. Although I've seen with others that Claude 4.6 Sonnet is still much more capable. Unfortunately, in their infinite wisdom, Anthropic only accepts Credit Card payments which as an European I obviously don't have. So maybe I will sign up to Claude via GooglePay some day, just to compare, or have it hack away at the more complex/architecture drafting tasks. Not every task needs to be most complex/expensive model.

I will say that "write a compiler" was beyond the local models I tried - and I'm running on a Macbook M4 Max with 128GB of RAM so I could play with some large local models. 122B Qwen3-Coder 3.5 was the best of the bunch, but it still wasn't even close to the Claude results. Night and day.

122B on 128GB of RAM? Is that Q4 with a limited context size?
I tried Qwen3 80B and that was really stretching my system thin. I still allocate 96GB as VRAM, and it couldn't really handle context sizes much beyond 100K. And that is a problem on a medium-large project when the prompts get so big it has to prune 2/3s for every intermediate prompt..
Afaik AI models also move very very quickly still, despite apparent plateau of capability. They do get increasingly better and more efficient with a similar amount of weights. Unfortunately open models are still 0.5 - 1 year behind, so it is exciting to know that cutting edge Claude models will probably run local by this christmas. Then again Claude's holding back Mythos because its "too powerful" does spark my interest to try that as well... if we ever get to see it.