DEV Community: Jessica Doering

Students Can Get Zed Pro Free for 1 Year

Jessica Doering — Mon, 09 Nov 2026 01:39:04 +0000

I came across this and thought it was worth sharing for any students that could use it.

Zed is offering students a full year of Zed Pro free.

If you haven't heard of Zed, it's a free, open-source code editor built in Rust. It's designed to be fast, lightweight, and collaborative, with AI features built into the development environment.

It's available for Linux, macOS, and Windows.

One of its more interesting features is real-time collaboration. You can work in the same files with other developers, share terminals, and use voice chat without leaving the editor.

Pretty handy for group projects, especially if you're studying programming or working with classmates.

The free student plan includes:

12 months of Zed Pro
$10 in AI token credits every month
Unlimited edit predictions, which suggest code changes as you type
Access to newer AI models including GPT-6.1 Sol and Claude Sonnet 5.5 (Does not include more expensive models like Claude Opus, Claude Fable or GPT-6 Astra)
Real-time collaboration, including shared editing, terminals, and voice chat

The AI credits are usage-based. You get $10 worth of model usage each month, not unlimited prompts. But for something that costs nothing, it's a decent deal.

How to qualify:

Be at least 18 years old
Be currently enrolled at an accredited university
Have a GitHub account that's at least 30 days old
Have a valid university email address to verify your enrollment

The offer is available to eligible students worldwide, not just in the United States.

You can apply directly through Zed's official education page:

Get Zed Pro Free for Students

Training MoE Models Is Complicated. Hugging Face Just Wrote the Manual.

Jessica Doering — Sun, 08 Nov 2026 23:00:14 +0000

I've spent a fair amount of time recently experimenting with Mixture of Experts (MoE) models on my own hardware. Mostly trying to figure out how far I could push them, how much I could offload to system RAM, and whether I could get models running that technically had no business running on my laptop.

So when I saw that Hugging Face had released something called The Ultimate MoE Training Handbook, I was immediately interested.

And then I opened it.

Apparently, Hugging Face decided that a normal tutorial just wasn't going to cut it.

Published on November 5, 2026, the handbook is an enormous, interactive technical resource covering pretty much everything involved in training Mixture of Experts models at scale. We're talking model architecture, expert routing, load balancing, distributed training, GPU communication, quantization, inference, and plenty of things that can go spectacularly wrong along the way.

But what makes this particularly interesting to me isn't just how much information they've packed into it. It's how much practical engineering knowledge they're making publicly available.

First, Why Are MoE Models Such a Big Deal?

If you've been following open-weight language models lately, you've probably noticed that Mixture of Experts architectures are everywhere.

According to the handbook, 18 of the top 20 open-weight models on the Artificial Analysis index at the time of publication use MoE architectures.

That's a pretty significant majority.

The basic idea behind a Mixture of Experts model is that not every parameter needs to be activated for every token.

In a traditional dense model, the model uses its full set of parameters during each forward pass. With an MoE, certain layers contain multiple smaller neural networks called experts, and a router decides which ones to activate for each token.

This allows a model to have a very large total parameter count while using a much smaller subset for each token.

For example, the smaller MoE used in Hugging Face's training walkthrough has 6.86 billion total parameters, but only 1.22 billion active parameters per token.

That's one of the things I find so fascinating about these models. You can have a massive amount of model capacity without needing to perform computations across every parameter for every token.

Figure 3.4.1: Expert Granularity. This visualization demonstrates how expert capacity can be organized into differently sized networks while keeping computation per token comparable. Source: Hugging Face, The Ultimate MoE Training Handbook.

Of course, there's a catch.

Just because fewer parameters are active doesn't mean the others magically disappear from memory. That's something I became very familiar with while experimenting with expert offloading.

And training these models introduces an entirely different collection of problems.

Training an MoE Isn't Just Training a Bigger Model

One of the things the handbook does really well is explain why MoE training gets complicated so quickly.

With a dense model, you already have plenty to worry about. Memory consumption, training stability, learning rates, GPU utilization, and everything else involved in getting a model to train properly.

Now add multiple experts and a system responsible for deciding which ones process each token.

Suddenly you have questions like:

What happens if the router keeps choosing the same experts?
How do you prevent some experts from being overloaded while others barely get used?
What happens when the experts are distributed across multiple GPUs?
How much time gets wasted moving tokens between those GPUs?
How can you tell whether poor performance is caused by the model, the hardware, or the configuration?

And these aren't just theoretical concerns.

The handbook walks through actual experiments, configurations, measurements, and troubleshooting techniques.

I particularly like that it doesn't just tell you which settings to use. It explains what those settings do, why they matter, and what you should look for when something goes wrong.

Figure 1.2: Training Triage Flowchart. A practical guide to diagnosing training problems by identifying symptoms and tracing them to potential causes. Source: Hugging Face, The Ultimate MoE Training Handbook.

One Configuration Problem Caused a 25× Slowdown

In one of their distributed training experiments, Hugging Face found that an incorrect network configuration caused GPU communication to fall back to ordinary TCP sockets rather than the intended high-performance network transport.

The result?

Their expert-parallel training test went from 42.0 TFLOP/s per GPU down to approximately 1.7 TFLOP/s.

That's about a 25× slowdown.

Not because the model was poorly designed. Not because the GPUs were incapable of handling the workload.

Because the communication between machines wasn't using the correct network path.

Imagine having access to a cluster full of expensive GPUs and discovering that a configuration issue is making your training run dramatically slower than it should be.

It's a great reminder that performance problems aren't always where you expect them to be.

And I appreciate that the handbook includes this kind of information instead of presenting everything as though the experiments worked perfectly on the first attempt.

You Can Actually Turn a Dense Model Into an MoE

Another section I found particularly interesting covers something called upcycling.

Instead of building and training an entirely new Mixture of Experts model from scratch, you can take an existing trained dense model and use its weights to initialize an MoE.

The idea is to reuse some of the training work that's already been done.

This can give the MoE a head start instead of beginning with randomly initialized weights.

There's an interesting tradeoff, though. That head start isn't necessarily permanent. The handbook discusses research where MoE models trained from scratch eventually caught up with their upcycled counterparts.

How quickly that happens varies, and of course the original dense model required compute to train in the first place.

Still, I love the idea of taking an existing model and transforming its architecture rather than starting over completely.

It's one of those concepts that immediately makes me want to start another experiment.

Which is probably the last thing I need right now.

What If You Don't Have Eight H100s Sitting Around?

The handbook's hands-on training recipes are designed around a fairly serious hardware setup.

Their examples assume a cluster environment with eight GPUs per node, and the initial training exercises use eight GPUs with roughly 80 GB of memory each.

So no, this isn't something you're going to casually reproduce on your gaming laptop over the weekend.

They do explain how to rent suitable hardware through Hugging Face Jobs, but renting high-end GPU resources is still an expense.

However, I think this is where the resource becomes especially valuable.

You don't need to own the hardware to learn from the experiments.

The architecture explanations, interactive figures, training comparisons, and troubleshooting sections are useful even if you never launch one of the training jobs.

There's an entire section breaking down the anatomy of MoE training, including expert routing, load balancing, expert size, sparsity, activation functions, and more.

You can explore the reasoning behind the design choices used by large models without having to reproduce those models yourself.

And if you're already experimenting with smaller models locally, there's plenty of information that can help you better understand what's actually happening.

Why I Think This Release Matters

Something I really appreciate about the open AI community is how much knowledge gets shared.

We have open-weight models, public datasets, training frameworks, research papers, and tools that allow individual developers to experiment with technology that would have been almost completely inaccessible not that long ago.

But there's still a big difference between having access to model weights and understanding how those models were actually built.

A research paper might explain a new technique, but it doesn't necessarily walk you through the hundreds of little engineering decisions required to make everything work.

Which settings were chosen? What alternatives were tested? Why did one configuration perform better than another? What broke during training, and how did the team figure out what was wrong?

Those details are what makes this handbook stand out to me.

It isn't just an explanation of Mixture of Experts architecture. It's an attempt to document the practical knowledge involved in training these models, including the less glamorous parts that don't always make it into papers or model announcements.

Of course, reading a handbook isn't the same as having the experience, hardware, or budget to train a frontier model yourself.

But having access to this information is a pretty good place to start.

Definitely Worth Bookmarking

I'm still working my way through the handbook, and I suspect it's something I'll be returning to as I continue experimenting with local models.

A lot of the material is well beyond what I'm currently doing, and probably will be able to do in the near future but that's actually part of the appeal.

I like learning about things like this, and maybe this is something I could eventually grow into attempting myself someday.

If you're interested in Mixture of Experts models, whether you're training them, running them locally, or just trying to understand why so many newer language models use this architecture, I'd recommend taking a look.

Just maybe don't expect to get through the whole thing over your morning coffee.

Read it here: The Ultimate MoE Training Handbook

And if you've been experimenting with MoE models yourself, I'd love to hear what you've been trying. I'm always interested in seeing what other people manage to get running on hardware that probably wasn't meant for it.

I Never Thought I'd Be a Programmer. Yet Here I Am.

Jessica Doering — Sat, 07 Nov 2026 20:41:58 +0000

Here I am sitting at home on a rainy Saturday, so I thought I'd share my story. It's nothing special, but that's the point. And maybe it could inspire someone else who is worried about changing gears in their life to make that leap. It's never too late to learn something new, to change and to grow.

If you had told me when I was younger that I'd someday be writing code, building software, experimenting with AI models, and going to college for IT, I probably would have laughed at you.

Not because I thought those things were impossible, but because I never imagined myself doing any of them.

Funny how life works out sometimes.

I grew up around computers. I just didn't care that much.

My dad was a programmer.

And not just someone who tinkered with computers as a hobby. He was pretty well known for his work in our area. He'd even been featured in the newspaper for some of the things he'd created. My dad also often created little personalized learning games for me to play when I was very young.

So computers weren't exactly unfamiliar territory in my house.

I had an IBM computer when I was a kid. I knew my way around DOS, and I even made some little text-based games.

This was back when using a computer meant knowing at least a little bit about what you were doing. There weren't pretty interfaces for everything, and you couldn't just click a button and expect things to happen.

I also had friends who ran their own bulletin board systems (BBSs). One of those friends eventually became my husband.

Looking back, it's kind of funny how much technology was around me growing up.

You'd think I would have naturally followed in my dad's footsteps.

Nope.

I was much more interested in animals.

I took a completely different path

I wasn't exactly a model student in high school.

Actually, that's putting it nicely.

I slacked off, stayed back, dropped out at 17, and got my GED.

I wasn't thinking about college or careers in technology. I just wanted to get out into the world and start working.

And that's what I did.

I did attend one year of community college years later, but of course, never finished.

I ended up spending most of my working life with animals, which was something I'd always loved. I was a dog and cat groomer, and a veterinary assistant. I genuinely enjoyed all of that.

Honestly, I still think animals are easier to get along with than people most of the time.

I'm not exactly the world's biggest people person.

I know my dad was disappointed that I didn't pursue programming or something related to computers. And I can understand that now, looking back. He had this whole world of knowledge and experience that he probably would have loved to share with me.

But at the time, I just wasn't interested.

I had my own path, and it went in a completely different direction.

Eventually, I got married, had my kids, and spent a few years as a stay-at-home mom.

Computers were still part of my life, of course, but not in any particularly interesting way.

I usually had a halfway decent laptop. Nothing fancy. Just something I could use for social media, browsing the internet, and playing whatever games it could manage to run.

Programming wasn't even on my radar.

Somehow, I became someone who writes code

Things really took off when I got my first actually good computer.

I don't think there was one specific moment when I decided I wanted to become a programmer.

It happened gradually.

I'd get curious about something, try to figure out how to do it, and then get another idea.

I started experimenting with little scripts and automations. Nothing particularly impressive at first, but every time I figured something out, I wanted to try something else.

One experiment turned into another.

A little script turned into a small project.

And before I knew it, I was starting to learn programming languages, building applications, working with APIs, and spending ridiculous amounts of time figuring out why something wasn't working.

And the strangest part?

I actually loved it.

Not every minute, obviously. There have been plenty of times I've wanted to throw my computer out a window.

But I love making things.

I love having an idea and figuring out how to turn it into something real.

I love learning how software works, even when the process involves hours of confusion, a dozen open browser tabs, and discovering that the problem was something embarrassingly simple.

ChatGPT

I still remember how fascinating it was when ChatGPT first appeared.

Here was this thing that I could actually have a conversation with.

I could ask it questions. I could get it to write things. I could generate random cat pictures. I could even ask it to write little scripts that would automate things on my computer.

At the time, that absolutely blew my mind.

I know that probably sounds funny now, considering how much AI has changed in just a few years.

But back then, it felt like discovering an entirely new world.

And I started getting curious.

Not just about what these tools could do, but about how they worked and what else I could make them do.

AI opened up so many more possibilities. It gave me a starting point when I wanted to learn something new. It made experimenting accessible, and provided me with a constant tutor that was there to answer questions and explain things as often as I needed.

At some point I started experimenting with training and fine-tuning small language models.

I worked with technologies I didn't even know existed a few years ago.

I was excited about learning more.

Going back to school was another surprise

As if discovering a love for programming wasn't unexpected enough, I eventually decided to enroll in college.

For IT.

Me.

If you'd told teenage me that I'd voluntarily go back to school someday, I probably would have thought you'd lost your mind.

But here I am.

I've been attending college online for awhile now, I'm in the honor society, and I've been genuinely enjoying learning new things that I never would have imagined myself studying.

And I'm proud of that.

Not because I think having a degree or being in an honor society makes someone more capable. There are plenty of incredibly talented developers who never went to college.

But because it's something I never believed I'd do.

That's still a little surreal to me.

Maybe we don't have to figure everything out when we're young

I think one of the biggest things I've learned from all of this is that we put way too much pressure on people to figure out what they want to do with their lives when they're young.

I certainly didn't have it figured out.

I didn't take the traditional route into technology. I didn't spend my teenage years dreaming about becoming a software developer. I didn't go straight from high school to college and into a tech career.

I spent years doing something entirely different.

And I don't regret that.

Working with animals was something I genuinely loved, and being home with my kids was an important part of my life.

Those years weren't wasted. They were my life.

And somewhere along the way, I found a new passion that I never saw coming.

Life has a funny way of coming full circle

Sometimes I look at what I’m building now and just laugh.

The girl who grew up with a programmer dad, and couldn't have cared less about his computers, is now spending her days deep in code. When I tell him what I’m up to these days, I honestly don’t think he fully believes it.

But that might be the best part of this whole journey.

You don’t have to have your life mapped out at 17, or 25, or 35. You can pivot hard into something that once seemed completely out of reach.

I still have moments where I feel like I have no idea what I’m doing. And yes, I still prefer animals to most people. Some things never change.

But I found a world I love making things in, and honestly, I'm just excited to see what comes next.

I Retested My MoE Offloading Benchmarks. Some of My Conclusions Changed.

Jessica Doering — Sat, 31 Oct 2026 19:33:06 +0000

A follow-up to my original 16GB GPU experiment, this time with consistent quantization, repeated benchmarks, and a few unexpected results.

I recently published an article about experimenting with Mixture-of-Experts (MoE) offloading on my laptop.

I tested five different models, compared traditional layer offloading against selective expert offloading, and came away with some pretty interesting results.

Some models performed better with selective offloading. Others were considerably faster using traditional layer splitting.

And one model, LFM2.5, performed so badly with selective offloading that I really wanted to figure out what was going on.

Well, the article got some great feedback.

People pointed out things I hadn't properly accounted for, questioned some of my assumptions, and suggested better ways to test what I was seeing.

Which, honestly, is exactly the kind of feedback I love getting.

So naturally, I went right back down the rabbit hole.

And this time, some of the results were very different.

First, what needed fixing?

If you haven't read the original article, you can find it here:

MoE Offloading Isn't Always Faster: I Tested 5 Models on a 16GB GPU

In that experiment, I was testing whether selective MoE offloading could improve performance when running models that were too large to fit entirely in my GPU's VRAM.

The idea is to keep certain operations running on the GPU while offloading selected expert weights and their computation to the CPU.

I used llama.cpp with the --n-cpu-moe option and compared it against traditional layer splitting using -ngl.

But there were a couple of problems with my original testing.

The models weren't all using the same quantization.

I had Phi-3.5 running at Q4_K_M, Apex at Q5_K_M, Qwen at Q6_K, and Gemma and LFM at Q8_0.

That made it difficult to know whether the performance differences were related to the model architectures, quantization, or something else.

A couple of people brought this up in the comments, particularly regarding LFM's terrible performance.

I also wasn't doing enough repeated measurements.

Another person pointed out that laptop thermals, background activity, and ordinary measurement noise could influence the results. He suggested interleaving the configurations rather than running one strategy completely before moving to the other.

That was a really good point.

My original benchmarks were useful for spotting interesting behavior, but some of the smaller differences weren't necessarily meaningful.

So I decided to do another round of testing.

The new test setup

I'm still using the same laptop:

GPU: NVIDIA RTX 4090 Laptop GPU, 16GB VRAM
CPU: Intel Core i9-14900HX, 24 cores / 32 threads
RAM: 32GB DDR5
OS: CachyOS / Arch Linux
Inference engine: llama.cpp with CUDA and Flash Attention enabled

But I changed several things about the testing process.

All five models were now running at Q4_K_M.

I also updated llama.cpp, adjusted the offloading configurations to accommodate the smaller quantized models, and kept enough free VRAM to avoid pushing the GPU right to its memory limit.

For each model, I used the same prompt:

"What are 3 practical benefits of using Arch Linux?

Each configuration received a warmup request before measurement.

I then ran three repeated measurements per strategy in an interleaved order, with short cooldowns between runs.

Instead of relying on a single result, I used the median generation speed.

This doesn't make the experiment perfectly controlled. In particular, changing the quantization, offload settings, and llama.cpp build means I can't attribute every difference to quantization alone.

But it does give me a much better picture of how these models behave under a consistent Q4_K_M setup.

The new results

Here's what happened with the initial 100-token Q4_K_M tests:

Model	Traditional Split	Selective MoE	Result
Phi-3.5-MoE	6.17 tok/s	5.15 tok/s	Traditional +19.8%
Apex-35B	8.20 tok/s	9.70 tok/s	Selective +18.3%
Qwen3.5-35B	7.44 tok/s	9.00 tok/s	Selective +21.0%
LFM2.5-24B	32.96 tok/s	35.44 tok/s	Selective +7.5%
Gemma 4 26B	13.58 tok/s	13.58 tok/s	Tie

Well, that was interesting.

In my original tests, traditional splitting was faster on Qwen, LFM, and Gemma.

Now selective offloading was ahead on Qwen and LFM, and Gemma was essentially tied.

Phi-3.5 had also gone in the opposite direction.

But I wasn't quite ready to declare those results final.

Some of the individual runs had pretty significant variation, including one unusually fast Apex result and one unusually slow LFM result.

So I extended the testing to 512-token generations on a few of the models.

And that's where things got even more interesting.

Qwen: Quantization really does seem to matter

This was probably the result I was most interested in investigating.

In my original tests, Qwen3.5-35B at Q6_K performed better using traditional layer splitting.

But Apex-35B, which uses a related 256-expert MoE architecture, performed better with selective offloading at Q5_K_M.

I wondered whether the quantization difference was contributing to that behavior.

The new Q4_K_M results certainly suggested it might be.

So I went a little further.

I tested the same Qwen3.5-35B checkpoint at Q4_K_M and Q6_K, using the same llama.cpp build and longer 512-token generations.

Here's what I found:

Quantization	Traditional Split	Selective MoE
Q6_K	6.79 tok/s	6.75 tok/s
Q4_K_M	6.47 tok/s	8.38 tok/s

At Q6_K, the two strategies were practically tied.

At Q4_K_M, selective MoE offloading was 29.5% faster.

That's a substantial difference.

And unlike the original Apex-versus-Qwen comparison, this time I was comparing different quantizations of the same model, on the same inference engine build.

I still can't say quantization was the only factor, because the layer placement also needed adjusting to fit the different model sizes.

But this is much stronger evidence that the combination of quantization and memory placement has a major influence on selective offloading performance.

It also changed how I think about fine-grained MoE architectures.

Originally, I suspected that models with 256 routed experts might be particularly problematic for CPU offloading.

These results suggest it's not nearly that simple.

A 256-expert model can perform quite well with selective offloading, depending on the configuration.

LFM: The biggest surprise needed another look

If you read my first article, you might remember LFM2.5.

That was the model that managed a rather miserable 2.11 tokens/sec with selective offloading at Q8_0.

Traditional splitting achieved 9.03 tok/s.

More than four times faster.

It was such a dramatic difference that several people commented on it.

Mudassir suggested that the heavier 8-bit expert weights might be putting too much pressure on CPU memory bandwidth.

I suspected something similar, but didn't have the evidence to separate that from the architecture itself.

Well, switching to Q4_K_M produced a massive improvement.

The initial 100-token run reached 35.44 tok/s with selective MoE offloading.

That's approximately 16.8 times the original result.

Traditional splitting also improved considerably, reaching 32.96 tok/s.

But there was a problem.

One of the selective runs dropped all the way to 11.23 tok/s, while the other two were above 35 tok/s.

That's a pretty ridiculous amount of variation.

So I repeated the experiment using longer 512-token generations.

This time, the results looked quite different:

Strategy	Median Generation
Traditional Split	21.72 tok/s
Selective MoE	21.88 tok/s

Essentially a tie.

The weird 11.23 tok/s dip didn't reappear in those longer runs, but both configurations were considerably slower than their original 100-token medians.

That raises questions about workload length, sustained performance, and what might be changing during generation.

What I can say is that LFM clearly isn't inherently terrible at selective expert offloading.

Under the new Q4_K_M configuration, it performed reasonably well.

But whether the improvement came primarily from quantization, different layer placement, changes in llama.cpp, or a combination of all three still needs more investigation.

And the longer test also reminded me of something important.

A configuration that looks faster over 100 tokens might not have the same advantage over 512.

That's something I'll definitely keep in mind when benchmarking models in the future.

Then I tried speculative decoding with Gemma 4

Because apparently five models and two offloading strategies weren't enough to keep me entertained.

I also wanted to see whether Multi-Token Prediction (MTP) speculative decoding could improve performance when using selective MoE offloading.

Gemma 4 26B-A4B has a separate MTP drafter that can propose multiple tokens for the main model to verify.

The idea is that generating and verifying several tokens together can sometimes be faster than generating them individually.

In theory, that sounded promising.

In practice, my results were not particularly encouraging.

Without MTP, selective offloading reached:

13.58 tokens/sec

With the MTP drafter enabled:

7.24 tokens/sec

So instead of speeding things up, it reduced throughput by approximately 46.7%.

I wanted to understand why.

During a longer 512-token test, I captured the drafter telemetry:

draft acceptance = 0.11678103 accepted / 882 generatedmean len = 1.35

Only 11.68% of the proposed draft tokens were accepted.

That's a pretty awful acceptance rate.

The longer MTP run also measured just 6.03 tok/s.

Speculative decoding has overhead. If the drafter isn't making predictions that the target model can accept often enough, the extra work can outweigh whatever speedup you hoped to achieve.

The low acceptance rate gives me a much more concrete reason to investigate the slowdown than simply assuming CPU/GPU synchronization was responsible.

I still want to check whether the drafter configuration or some other compatibility issue contributed to the poor acceptance rate.

So I wouldn't conclude from this that speculative decoding and CPU offloading are fundamentally incompatible.

Just that this particular configuration definitely didn't help.

Something else the repeat testing revealed: Noise

One of Riccardo's main suggestions was to account for measurement variation.

And after seeing these results, I'm glad I did.

For example, the three Apex selective offloading runs were:

9.21 tok/s9.70 tok/s25.50 tok/s

That last run was affected by early end-of-sequence generation, making it a poor comparison with the other runs.

LFM also produced that unusually slow 11.23 tok/s result.

And Gemma's traditional offloading runs varied from 8.98 to 16.85 tok/s.

Those are not small differences.

Interleaving the configurations helped make the testing process fairer, but it didn't magically remove every source of variation.

Using medians helped reduce the influence of individual outliers, although three measurements still aren't enough to establish a particularly reliable performance distribution.

The longer tests were especially useful because they showed that some of the apparent advantages became much smaller when the workload changed.

Going forward, I think longer generations and more repeated measurements are going to be standard practice for my experiments.

It's a little more work, but clearly worth it.

So what did I actually learn?

I went into the original experiment wanting to find out whether selective MoE offloading was a better way to run large models on a GPU with limited VRAM.

My first conclusion was that it depended on the model.

That still seems true, but now I'd add quite a bit more to it.

Quantization can change the outcome.

Qwen went from traditional splitting performing slightly better at Q6_K to selective offloading gaining a substantial advantage at Q4_K_M.

Offloading configuration matters.

Two configurations using the same model can place very different amounts of work on the CPU and GPU. The amount of VRAM occupied doesn't tell the whole story.

Short benchmarks can be misleading.

LFM's apparent 7.5% selective advantage in the 100-token tests practically disappeared over the longer generations.

Speculative decoding isn't a free speed boost.

Gemma's MTP drafter had a very low acceptance rate and made generation considerably slower under my tested setup.

And perhaps most importantly, a measurement and an explanation aren't the same thing.

I can measure that something runs faster or slower.

Explaining exactly why sometimes requires considerably more testing.

That distinction is becoming more obvious the deeper I get into this.

What's next?

I'm not quite finished experimenting.

I'd still like to test more quantization levels on the exact same checkpoint, ideally with more carefully controlled offloading configurations.

I'm also interested in monitoring actual CPU memory bandwidth and GPU behavior during inference.

That might help answer some of the questions about where these slowdowns are coming from instead of relying on educated guesses.

And eventually, I still want to repeat some of these tests on a machine with 64GB of RAM.

I'm especially curious how much more flexibility that provides for keeping expert weights in system memory without running into swap pressure.

But for now, I think I've learned quite a bit from these two rounds of testing.

Final thoughts

One of my favorite things about sharing experiments publicly is that sometimes people notice things you missed.

I thought my original results were interesting, and I still do.

But several people asked good questions about the methodology, the quantization differences, and whether the measurements were reliable enough to support some of my conclusions.

They were right to ask.

And when I went back and tested those things, some of my conclusions changed.

I'm glad they did.

I'd much rather discover that my original explanation wasn't quite right than keep repeating it because it sounded reasonable.

That's half the fun of experimenting with this stuff.

You start with one question, find an interesting result, and suddenly you're investigating three completely different things you hadn't even considered.

And occasionally you realize you've spent an entire weekend benchmarking language models instead of doing literally anything else.

You know, perfectly normal behavior.

A big thank you to everyone who took the time to read the original article and offer thoughtful feedback. It genuinely helped make this second round of experiments better.

And if anyone has suggestions for what I should test next, particularly around quantization, CPU memory bandwidth, or speculative decoding, I'd love to hear them.

Apparently I haven't spent enough time staring at tokens-per-second measurements yet.

MoE Offloading Isn’t Always Faster: I Tested 5 Models on a 16GB GPU

Jessica Doering — Fri, 30 Oct 2026 14:04:55 +0000

Follow-up post here:

Driven by reader feedback to fix flaws

Jessica Doering

Oct 31

I Retested My MoE Offloading Benchmarks. Some of My Conclusions Changed.

#ai #machinelearning #llm

9 min read

I do a lot of experimenting with local language models, and I just ended up going down a bit of a rabbit hole.

It started when I came across an article about running larger Mixture-of-Experts (MoE) models on GPUs that don't have enough VRAM to hold the entire model.

The idea was pretty simple. Instead of offloading entire model layers to system RAM, you could selectively offload just the MoE experts and leave the rest of the work on the GPU.

I thought that sounded interesting. And since I have a laptop with 16GB of VRAM and 32GB of RAM, I figured I'd give it a try.

Well, one model turned into another, which turned into another, and before I knew it, I was benchmarking five different models, comparing offloading strategies, and trying to figure out why some configurations worked so much better than others.

You know, a perfectly normal way to spend a day.

And I learned quite a bit along the way.

First, what exactly is MoE offloading?

If you've experimented with running local LLMs, you're probably familiar with the problem of trying to load a model that's too large for your GPU.

You can use CPU offloading to make it fit, but there's usually a pretty significant performance penalty.

Traditional layer offloading moves entire transformer layers between the GPU and CPU. That means parts of the model that could benefit from GPU acceleration end up running on the CPU instead.

MoE models give us another option.

Unlike dense models, where essentially all the model's parameters participate in processing each token, MoE models have multiple experts, and only a subset is activated for each token.

For example, Microsoft's Phi-3.5-MoE has around 42 billion total parameters, but only about 6.6 billion are active per token.

That doesn't mean the other parameters disappear. They still need to be stored somewhere.

But since only certain experts are needed for each token, we can potentially keep some of those expert weights in system RAM while leaving attention and other parts of the model on the GPU.

In llama.cpp, this is possible using:

--n-cpu-moe N

Where N specifies how many initial layers will have their MoE expert weights kept on the CPU.

In theory, this should let you run larger models without sacrificing quite as much performance as traditional layer offloading.

But I wanted to see how well it actually worked.

My test setup

All of these experiments were done on my Acer Predator laptop running CachyOS (Arch Linux).

Here's the hardware:

GPU: NVIDIA RTX 4090 Laptop GPU, 16GB VRAM
CPU: Intel Core i9-14900HX, 24 cores / 32 threads
RAM: 32GB DDR5
Inference engine: llama.cpp with CUDA support
Flash Attention: Enabled

I used GGUF models and ran everything through llama-server.

I started with Phi-3.5-MoE because it seemed like a good candidate for testing this technique. From there, I added several other MoE models with different architectures and quantization levels.

For the initial comparisons, I used a 4,096-token context window, a warm-up request, and the same short benchmark prompt.

This wasn't intended to be some exhaustive scientific benchmark. I wanted to see what actually happened on my hardware and whether the differences were significant enough to investigate further.

The models I tested

I ended up testing five models:

Model	Quantization	GGUF size
Phi-3.5-MoE (42B)	Q4_K_M	24GB
Apex-35B V1.0	Q5_K_M	24GB
Qwen3.5-35B-A3B	Q6_K	27GB
Gemma 4 26B A4B	Q8_0	26GB
LFM2.5-24B-A2B	Q8_0	24GB

All of them were larger than my available GPU memory.

That was the whole point of the experiment.

I wanted to compare two approaches:

Traditional layer offloading: Move complete layers to the CPU until the model fits within available VRAM.
Selective MoE offloading: Keep GPU-eligible non-expert operations on the GPU while moving selected expert weights and their computation to the CPU.

I adjusted the settings for each model to fit within my memory limits.

And this is where things started getting interesting.

The results were definitely not what I expected

Here's a comparison of the generation speeds I measured:

Model	Selective MoE	Traditional offloading
Phi-3.5-MoE	5.67 tok/s	4.03 tok/s
Apex-35B	5.18 tok/s	3.69 tok/s
Qwen3.5-35B	4.37 tok/s	5.23 tok/s
Gemma 4 26B	4.40 tok/s	5.77 tok/s
LFM2.5-24B	2.11 tok/s	9.03 tok/s

I originally expected selective MoE offloading to be the better option across the board.

That was definitely not the case.

On Phi-3.5-MoE and Apex-35B, selective offloading improved generation speed by around 40%.

But on Qwen, Gemma, and especially LFM, traditional layer offloading was faster.

And not just by a little.

LFM was more than four times faster with traditional offloading.

That one really caught my attention.

More GPU usage doesn't always mean better performance

One of my favorite discoveries came from testing Phi-3.5-MoE.

I started experimenting with how many expert layers I should keep on the CPU.

At one point, I had nearly all 16GB of VRAM occupied.

Here's what happened:

CPU expert layers	VRAM used	Generation
13	15,945 MiB	5.29 tok/s
16	13,833 MiB	4.66 tok/s
20	11,015 MiB	5.67 tok/s

The fastest result came from offloading more experts to the CPU.

I actually got better generation speed while using significantly less VRAM.

Now, I don't want to claim that leaving more VRAM free automatically makes inference faster. There are plenty of things that could affect these results, including CPU/GPU scheduling, memory bandwidth, caching, and normal variations between runs.

But it was still interesting to see that the configuration using the most GPU memory wasn't necessarily the fastest.

Sometimes the best configuration isn't the one that pushes your GPU to its absolute limit.

Quantization might matter more than I realized

Another thing I noticed was how differently models behaved at different quantization levels.

For example, Qwen3.5-35B at Q6_K performed better with traditional offloading.

But Apex-35B, which uses a related Qwen3.5 MoE architecture and was quantized to Q5_K_M, performed better with selective MoE offloading.

That made me wonder whether the additional CPU memory bandwidth needed for higher-precision expert weights was affecting performance.

It would make sense. When experts are running on the CPU, the amount of data being read from system RAM can become a significant bottleneck.

But I haven't proven that's the reason yet.

These are different model checkpoints, and there may be architectural or implementation differences affecting the results too.

I'd like to test the exact same model at Q4, Q5, and Q6 using both offloading methods. That would be a much better way to isolate the effect of quantization.

For now, it's an interesting observation rather than a conclusion.

Then there was LFM...

I really wasn't expecting this result.

LFM2.5-24B-A2B has around 24 billion total parameters, with approximately 2 billion active per token.

You might think that relatively low active parameter count would make it an especially good candidate for selective expert offloading.

Nope.

With selective offloading, I got:

2.11 tokens/sec

With traditional layer splitting:

9.03 tokens/sec

That's a huge difference.

My suspicion is that the Q8_0 expert weights, CPU memory bandwidth, and repeated synchronization between CPU and GPU may be playing a role.

But again, I would need more detailed profiling to know exactly what's happening.

What this really showed me is that the number of active parameters alone doesn't tell you how efficiently a model will run on your hardware.

The architecture, quantization, and inference implementation all matter.

And sometimes the approach that sounds better on paper performs much worse in practice.

I also experimented with context length

After finding a configuration I liked for Phi-3.5-MoE, I wanted to see what would happen when I increased the context window.

Using Flash Attention, I tested 4K, 8K, and 16K context settings.

Context setting	VRAM used	Generation
4K	11,015 MiB	5.67 tok/s
8K	11,531 MiB	5.56 tok/s
16K	12,563 MiB	5.85 tok/s

The memory increase was much more manageable than I expected.

I also tried the same thing with Apex-35B, where the measured VRAM increase from 4K to 16K was only around 252 MiB.

It's worth mentioning that these tests changed the configured context capacity. They weren't benchmarks of processing prompts that actually contained 16,000 tokens.

That distinction matters, because processing a genuinely long prompt is a different workload.

Still, it was encouraging to see how much room I had for larger context settings without immediately running out of VRAM.

What about putting all the experts on the CPU?

I tried that too.

With Phi-3.5-MoE, I used:

--cpu-moe

And, well, that didn't go particularly well.

The model loaded, but system memory pressure increased enough to cause heavy swapping.

Generation dropped to around 3.14 tokens/sec, and I was seeing approximately 90MB/s of swap activity.

At that point, my 32GB of RAM was clearly becoming a limitation.

This doesn't mean full CPU expert offloading is always a bad idea. With more RAM, a different model, or a different quantization, it might be perfectly reasonable.

But for this particular model and my laptop, selectively offloading only some of the experts worked much better.

So, is selective MoE offloading worth using?

I think the answer is yes, but not necessarily for every model.

That's probably my biggest takeaway from all of this.

When I started, I was mostly interested in seeing whether I could run models that were too large for my GPU.

And I can.

But what I ended up learning was that getting a model to fit in memory is only half the problem.

How you distribute its workload between the CPU and GPU can make a surprisingly big difference.

For Phi-3.5-MoE and Apex-35B, selective offloading gave me better performance.

For other models, especially LFM2.5, the traditional approach was considerably faster.

I don't think there's a single offloading configuration that's going to work best for every MoE model.

At least, that's certainly not what my experiments have shown so far.

A few things I still want to test

I'm not quite finished with this rabbit hole yet.

I'd like to repeat the benchmarks with longer outputs and multiple runs per configuration, rather than relying on one short warm benchmark.

I also want to compare different quantizations of the same model to better understand how much precision affects CPU-side expert performance.

And eventually, I'd love to repeat some of these experiments on a machine with 64GB of RAM to see how much difference the extra memory makes.

There's also the question of actual usability. Tokens per second is useful, but I'd like to compare how responsive these configurations feel during longer conversations and more complicated tasks.

For anyone interested in trying this themselves, here's a basic example using llama.cpp:

llama-server \
  -m /path/to/model.gguf \
  -ngl all \
  --n-cpu-moe 20 \
  -c 8192 \
  -fa on

The 20 is just an example, not a magic number. You'll need to adjust it for your model and hardware, and compare it against traditional layer offloading.

Also, keep an eye on system RAM and swap usage. Just because a model starts successfully doesn't mean it's going to run comfortably.

Final thoughts

I went into this experiment thinking I'd learn a neat trick for running bigger models on my laptop.

Instead, I ended up learning quite a bit about how different MoE architectures behave, how quantization can affect performance, and why CPU/GPU memory placement isn't nearly as straightforward as I originally thought.

And I still have plenty of questions.

That's one of the things I enjoy most about experimenting with local LLMs. You can read all the explanations and documentation you want, but sometimes you don't really understand what's happening until you start testing things yourself.

Even better when the results make you question what you thought you understood in the first place.

If you've experimented with MoE offloading, I'd love to hear what kind of results you've seen, especially on GPUs with limited VRAM.

I'm curious whether anyone else has run into such dramatic differences between architectures.

Is Tech Actually Welcoming to Beginners, or Do We Just Say It Is?

Jessica Doering — Thu, 29 Oct 2026 16:58:14 +0000

We hear it all the time in tech.

Everyone starts somewhere. There are no stupid questions. Don't be afraid to ask for help. Keep learning.

And I agree with all of that.

But I've been wondering lately, are we actually as welcoming to beginners as we like to think we are?

Because telling someone they're welcome is one thing. Making them feel comfortable enough to actually participate is another.

The fear of asking a stupid question

When I first started learning to code, I was pretty nervous about asking questions.

I wasn't necessarily worried that someone would be outright mean to me. I was more worried about looking like I had absolutely no idea what I was doing.

Which, to be fair, half the time I didn't. That's kind of the point of learning something new, right?

But that didn't stop me from overthinking things.

What if this is something I should already know? What if the answer is ridiculously obvious? What if someone wonders why I'm even trying to build things when I don't understand something so basic?

I can't imagine I'm the only person who's ever felt that way.

And apparently, I'm not.

I was looking through the 2026 Stack Overflow Developer Survey, and a couple of numbers caught my attention.

21.1% of respondents said they worry about being judged or criticized when participating in technical or professional communities.

Another 20.1% said they don't feel confident asking questions publicly.

Now, these numbers aren't specifically about beginners. They're from respondents more broadly, and I don't want to misrepresent that.

But still, roughly one in five people answering that question are worried about what others might think of them.

That's a pretty significant number of people who might have something to ask, share, or contribute but hesitate to do it.

It makes me wonder how many people are reading discussions, learning from everyone else, and never saying a word because they're afraid they'll look stupid.

You can correct someone without making them feel stupid

I want to be clear about something. I'm not suggesting we should stop correcting people or pretend everything everyone does is amazing.

That wouldn't help anybody learn.

I've made plenty of mistakes, written some questionable code, and probably approached things in ways that would make a more experienced developer scratch their head.

And I'm sure I'll continue doing all three.

But there's a difference between someone explaining why your approach might not be the best and someone making you feel stupid for trying it in the first place.

You can point someone toward documentation without the whole "Did you even bother reading the docs?" attitude.

You can disagree with someone without turning it into a contest over who knows more.

And you can give someone honest feedback without making them regret asking for it.

I think sometimes people forget how intimidating tech can be when you're new.

Things that seem completely obvious to someone who's been programming for ten years might be something a beginner has spent the last three hours trying to figure out.

And sure, maybe the answer really was in the documentation the whole time.

We've all been there.

But nobody learns everything overnight, and making someone feel stupid isn't going to help them learn any faster.

What about women in tech?

This is another part of the conversation I'm interested in.

I'm a woman who builds things and is still learning all the time, and I can genuinely say that a lot of my experiences in the tech community have been really positive.

Especially here on DEV.

I've met some wonderful people, received helpful feedback, and had other developers encourage me to keep building and sharing my projects.

And I appreciate that more than I probably say.

But getting comfortable enough to put my work out there in the first place? That took some courage.

I'm naturally someone who second-guesses herself, and when I first started sharing my projects, I was constantly wondering what people would think.

Was my code good enough? Was what I built even worth sharing? Would more experienced developers look at it and wonder why I was so excited about something they could probably throw together in an afternoon?

Looking back, I probably worried about those things a lot more than I needed to.

But here's where I get curious.

How much of that hesitation comes from being a beginner? How much comes from personality? And for women, is there sometimes another layer to it?

I can't honestly say I've experienced some terrible amount of sexism in tech, because I haven't. At least not in the communities I've been participating in.

But I also know that my experience doesn't represent every woman's experience.

I'm curious whether other women have felt like they needed to prove they knew what they were talking about before anyone would take them seriously.

Or whether they've noticed people making assumptions about their abilities.

And I'm just as interested in hearing from women who've had really positive experiences.

I don't think this is a conversation where we should assume everyone has had the same experience, because obviously we haven't.

That's what makes it worth discussing.

Finding your people makes a difference

Something I've learned since I started sharing my work is just how much the right community can change things.

There are places on the internet where asking a basic question feels like you're volunteering to be publicly roasted.

And then there are places where people are genuinely excited to see what you're working on, even when it's something small.

I've been lucky enough to find more of the second kind.

When I first started posting on DEV, I was nervous.

Now I'm sharing projects, writing articles, participating in discussions, and occasionally posting something before I've had enough time to talk myself out of it.

Progress!

And it's not because I've suddenly become some expert who knows everything.

Trust me, I definitely haven't.

I look things up constantly. I make mistakes. I run into problems that leave me staring at my screen wondering what I did wrong.

But I've learned that I don't need to know everything to have something worth contributing.

Sometimes you share something you've built and someone teaches you a better way to do it.

Sometimes someone else is working through the exact same problem you just figured out.

And sometimes a little project you're proud of inspires another person to try building something of their own.

That's the kind of interaction that makes people want to participate.

We have to do more than say beginners are welcome

I don't think tech is some universally hostile place where everyone is waiting to tear beginners apart.

There are so many genuinely kind, helpful people out there, and I've met quite a few of them.

But I also think there's room for improvement.

We can tell beginners to ask questions all day long, but if the response they get makes them wish they'd kept quiet, what good does that do?

We can encourage people to share their projects, but if we immediately dismiss anything that isn't particularly advanced, we're not exactly giving them a reason to share the next one.

And I think it's worth remembering that something simple to you might be a huge accomplishment to someone else.

Maybe it's their first working app.

Maybe it's the first bug they managed to track down on their own.

Maybe they finally understand something that's been confusing them for weeks.

That excitement is real, even if the accomplishment seems small from where you're standing.

I still get excited when I figure something out that I probably should have understood ages ago. And I'm not planning to stop anytime soon.

I think most of us can remember what it felt like when we were first learning something completely unfamiliar.

We just need to remember that feeling when we're the ones with a little more experience.

Because a welcoming community isn't really defined by what it says about beginners.

It's defined by how it treats them when they actually show up.

I'm curious what everyone else thinks

I'd really love to hear about your experiences, especially if they've been different from mine.

When you were first learning, did you feel comfortable asking questions or sharing your work?
Have you ever avoided participating in a community because you were afraid of being judged?
For women in tech, do you feel your experience has been any different, good or bad?
Are there particular communities that made you feel genuinely welcome?

I know my experience is only one perspective, and I think hearing from people who've had both positive and negative experiences could make for a really interesting discussion.

After all, if we want tech communities to be welcoming, it probably helps to listen to the people we're trying to welcome.

I Built Mimu Because Even Taking Notes Is Too Much Work

Jessica Doering — Sat, 24 Oct 2026 02:35:32 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

I have a lot of ideas. Sometimes they're useful. Sometimes they're not. And sometimes I think of something I want to remember while I'm doing something completely unrelated.

The problem is that stopping to organize those thoughts feels like a whole separate task. Give a note a title, decide where it belongs, add tags, maybe set a reminder... suddenly the tiny thought I wanted to save has homework.

So when this week's challenge asked us to build something that rewards laziness, I knew exactly which chore I wanted to avoid.

I built Mimu, a little voice-note companion that lets me say what's on my mind and get on with my day. The note-taking is my part. The note-organizing is Mimu's.

And because I wanted to experiment with open models, the AI runs on devices I control rather than through a paid AI API.

What I Built

Mimu remembers for you.

On my phone, I tap the microphone, ramble for a few seconds, check the transcript, and save it. Whisper transcribes the audio in the browser. Later, a small Gemma model running on my computer turns that raw thought into a note with a useful title, formatted Markdown, a category, and tags.

The original transcript stays intact, so I can always see what I actually said. And if I don't feel like talking, I can type instead.

For example, I might say, "I need to call the dentist Thursday at two." Mimu can save that as an organized note with a due date instead of leaving me to remember which of my 47 scattered notes contains the dentist's appointment.

It also has a few features I added after getting the basic idea working:

Ask Mimu: Ask questions like "Who do I need to call?" and get an answer based on your saved notes, with links to the notes it used.
Morning digest and reminders: The desktop model prepares a short summary of what's due today and what I saved yesterday. Due-time reminders can be sent to the phone without needing the desktop to stay on.
Search and editing: Find notes by words, categories, and tags, or fix anything yourself without having the model overwrite it later.
Offline capture: Notes wait on the phone if the connection drops and sync when it comes back.
Markdown export: Save one note as .md or export everything as a ZIP of Markdown files. My notes don't have to live inside Mimu forever.

It's a responsive web app, so I can capture and browse notes on my phone and work through the library on a bigger screen. I gave it a tiny mascot, too, because apparently I cannot build an app without giving it a face.

[Insert mobile screenshots]

Demo

Try Mimu: https://mimu.pinkpixel.dev

I made a hosted demo because I didn't want the first thing a judge had to do to be "create two cloud accounts and configure a database." You can start a demo account or sign in with GitHub and explore sample notes right away.

To watch your own notes get organized by AI, you'll need Ollama on a computer. Mimu's Desktop page gives you a command to install and connect the Node worker, which downloads the Gemma model the first time. You can pair your phone by scanning a QR code. The app works as a note library without that worker, but Gemma-powered organizing, Ask, and digests need it running.

One important privacy detail: in the hosted demo, note text is stored in a separate database for each demo account under my Turso setup. Audio isn't uploaded; it's transcribed on the device and discarded. The language model still runs on the user's own computer. Anyone who prefers their own infrastructure can self-host Mimu instead.

Code

The source is available here:

pinkpixel-dev / mimu

Speak a thought, and a local AI sorts it into searchable Markdown notes.

Mimu

Mimu remembers for you.

Mimu is a voice notes app for people with too many ideas and not enough patience for note-taking. You tap the mic on your phone, say whatever's on your mind, and it's saved. Later, a model running on your own computer turns those rambling transcripts into tidy Markdown notes with a title, a category, and tags. You can search them, edit them, and export the whole library as plain Markdown whenever you want.

The speech recognition runs on your phone, and the organizing runs on your desktop. No paid AI API is involved anywhere.

See it in action

Here's a quick demo video. Click the thumbnail to watch it on YouTube.

Desktop

Mobile

Try it

There's a hosted demo at mimu.pinkpixel.dev, so you don't need a Turso or Cloudflare account to try Mimu.

Open the site and tap Start a demo (or Continue with…

View on GitHub

The README includes the setup instructions, architecture, and a quickstart for deploying your own copy.

How I Built It

I started on October 20, which happened to be International Sloth Day. Appropriate timing for an app dedicated to doing less.

My first plan was a phone app and a separate Tauri desktop app. Then I looked at the deadline and remembered that I am, unfortunately, only one person. I went with one React PWA that works on both screens and a headless Node worker on the desktop. It meant I could spend more of the week making the whole experience actually work, rather than maintaining two UIs.

The main pieces are:

Whisper tiny (English) through Transformers.js for speech-to-text in the browser.
Gemma 4 gemma4:e4b through Ollama on my computer for organizing notes, interpreting dates, writing digests, and answering questions.
React + Vite for the PWA, Hono on Cloudflare Workers for the API, and Turso/libSQL for note storage and full-text search.
A Node worker that picks up pending jobs, talks to Gemma locally, and sends the results back through the API.

The audio is handled on the phone. The saved text travels through the API to the database, and the desktop worker reads that text to process it. So this is local AI inference, not an entirely offline app. I think that distinction matters.

The bigger model wasn't better

Before settling on Gemma, I tested three sizes against ten messy sample notes, using structured JSON output through Ollama.

Gemma model	Valid JSON	Median time per note
`gemma4:e2b`	10/10	3.2s
`gemma4:e4b`	10/10	3.4s
`gemma4:12b`	10/10	13.7s

The funny thing is that all three were worse at organizing categories when I gave them a bad instruction. I told them to reuse existing categories "even loosely," and suddenly a grocery list was a "General Thought" and a failing CI build belonged with software ideas.

A much more specific rule about types of notes fixed the problem. E4B made six sensible categories in that test, without the extra wait from the 12B model. That was a useful reminder that throwing a bigger model at a vague prompt doesn't necessarily fix the prompt.

My phone had other plans

I initially tried Whisper with WebGPU. It looked promising until I tested it on my iPhone: the model download hit 100%, Safari reloaded, and I got to repeat the whole experience. No visible error. Just goodbye.

I added little diagnostic breadcrumbs that survived a reload and tracked the crash to ONNX session setup. The browser could detect a WebGPU adapter, but that didn't mean the model could actually run on it.

Switching to WASM fixed the issue. On the same phone, the model loaded in about 3.3 seconds and transcribed a three-second audio clip in about 1.8 seconds. For a model this small, WASM was also competitive on my desktop, so I made it the default everywhere.

I learned more from testing on a real phone than from a lot of happy-path desktop tests.

The tricky part wasn't formatting. It was not making things up.

At one point, Whisper misheard a phrase and Gemma confidently cleaned it up into something that meant the opposite of what I had said. The resulting note looked wonderfully polished. It was also wrong.

That's a dangerous failure for an app that's supposed to remember things for me.

I experimented with ways to make Gemma flag suspicious transcript fragments instead of quietly repairing them. In a small repeated test with deliberately garbled and clean phrases, asking for uncertainty inside the main organizing call caught only some of the errors. Giving uncertainty detection its own tiny model pass caught all ten garbled examples with no false alarms in that test, at roughly 0.6 seconds more per note.

Mimu now has a little "Mimu wasn't sure about" section, and the app verifies that a flagged phrase really appeared in the transcript. It doesn't eliminate every possible transcription error, but it gives me a chance to fix something ambiguous instead of trusting a very convincing invention.

I kept giving my lazy app more work

Once the capture-and-organize loop worked, I wanted Mimu to do more than make a neat pile of notes.

I added natural-language due dates, so "Thursday at two" can become an actual date and time. In my test of 16 phrases run twice, giving Gemma the capture timestamp and timezone produced 32/32 correct date-and-time results. Adding a calendar cheat sheet actually made it worse. That one surprised me.

Then came Ask Mimu, morning digests, and reminders. Ask uses full-text search first, then has Gemma answer from the retrieved notes, with references checked against the notes it received. If the search finds nothing, it says so instead of improvising.

The final result still has more moving pieces than my original "just let me talk" idea. But they're moving so I don't have to.

Why Does Open Innovation Matter?

Mimu wouldn't be the same project if every voice note had to go through a paid transcription API and every bit of organizing required another hosted model call.

Using open models let me decide where the work happens. Whisper runs right in the browser, so audio doesn't have to leave the phone. Gemma runs on my own computer through Ollama, so I can experiment with prompts, swap model sizes, and keep using the AI features without paying per note or per question.

It also meant I could test the model's actual behavior instead of treating it like a mysterious service. I could compare sizes, measure timings, change how uncertainty was handled, and build simple checks around what the model returned.

There are trade-offs. You need a computer capable of running the model, and some features aren't available until the desktop worker connects. The app also uses cloud storage to sync text between devices, so I'm not claiming the whole system is private-by-default or offline. But the audio stays on the phone, inference happens locally, and you can deploy the app under your own accounts. And your notes can leave as Markdown whenever you want.

That combination of control, portability, and the freedom to tinker is what made this project exciting to me.

The Lazy Payoff

I haven't done a formal time-savings study, so I'm not going to pretend Mimu saves an exact number of minutes every day. The benefit I was going for is smaller and more familiar: removing the little bits of friction that make me not bother writing something down at all.

Instead of stopping to decide on a title, folder, tags, and maybe a reminder, I can just talk. And later, I can search for the thought without remembering how I named it. That's the kind of laziness I can get behind.

I did test the complete flow with a real phone and laptop: start a demo, connect the worker, pair the phone, speak a note, and watch Gemma organize it. I also tested offline capture and resync. Those aren't hypothetical features in a mockup; they worked in my end-to-end tests.

The part I still want to keep testing is how well it handles real, everyday notes over time. A clean demo with a few examples is one thing. A growing pile of random thoughts from my brain is an entirely different workload.

Which, conveniently, I can provide in abundance.

Prize Categories

I'm entering Best Use of Gemma. Gemma 4 is the core of Mimu's note organization, date extraction, question-answering, and digests, running locally through Ollama.

I Fixed WebGPU on Linux. Then Forgot How I Did It.

Jessica Doering — Wed, 21 Oct 2026 21:13:14 +0000

I spent a ridiculous amount of time trying to get WebGPU working properly on my Linux machine.

I eventually figured it out, wrote a script to launch Chrome with all the necessary flags, and even made a desktop launcher so I could just click an icon whenever I wanted to run browser-based AI models.

Problem solved.

Except recently, I started thinking about all the trouble I'd gone through and realized something.

I couldn't remember how I'd fixed it.

Actually, I couldn't even remember where I'd saved the script.

So I did what any reasonable developer would do in 2026. I sent an AI agent to search my computer for code I'd written myself.

And what did it find?

Not only had I saved the script, I'd also written documentation explaining how it worked and backed everything up in TWO different resource directories.

Apparently, past me was considerably more organized than present me remembered.

Anyway, since I've already done all the hard work (and then forgotten about it), I figured I might as well share what I learned.

I just wanted to run AI models in my browser

I've spent quite a bit of time experimenting with local AI models, particularly small language models running through Transformers.js and ONNX Runtime.

I love the idea of running models directly in the browser. No server to maintain, no API calls to pay for, and inference happens right on your own hardware.

WebGPU makes a lot of that possible by allowing web applications to use the GPU for computation.

Which sounds great, right?

Except my setup wasn't exactly cooperating.

I'm running Arch-based Linux with Wayland on a laptop with hybrid graphics:

Intel Raptor Lake UHD integrated graphics
NVIDIA RTX 4090 Laptop GPU

And getting Chrome, Vulkan, NVIDIA, and Wayland to play nicely together was an absolute pain.

There are several layers involved. Your GPU drivers need to work, Vulkan needs to find the right device, Chrome needs to use the right graphics backend, and WebGPU needs to initialize successfully.

And just because one of those things works doesn't mean the next one will.

I spent a lot of time troubleshooting different configurations before I finally had something reliable enough to use regularly.

The solution that worked for me

Eventually, I ended up with a Bash script that launches a separate Chrome instance configured specifically for WebGPU.

Here's the script I recovered:

#!/usr/bin/env bash

# Launch Google Chrome with NVIDIA PRIME offload + Vulkan + WebGPU on X11.
# Dedicated separate profile so it can run alongside normal Chrome.

set -euo pipefail

CHROME_PROFILE_DIR="${HOME}/.config/chrome-webgpu-nvidia"

mkdir -p "$CHROME_PROFILE_DIR"

VK_LOADER_DRIVERS_SELECT='*nvidia*' \
__NV_PRIME_RENDER_OFFLOAD=1 \
__GLX_VENDOR_LIBRARY_NAME=nvidia \
__VK_LAYER_NV_optimus=NVIDIA_only \
google-chrome-stable \
  --user-data-dir="$CHROME_PROFILE_DIR" \
  --enable-unsafe-webgpu \
  --enable-features=Vulkan \
  --ozone-platform=x11 \
  "$@"

It's not particularly complicated to look at.

But getting to the point where I knew which settings to use was another story.

I also created a .desktop launcher for it, so now when I want to experiment with WebGPU, I can just open that version of Chrome without having to remember any of this.

Which, as we've established, is probably a good thing.

What all those settings actually do

1. Getting Chrome to use the NVIDIA GPU

My laptop has two GPUs. There's the integrated Intel GPU and the dedicated NVIDIA GPU.

With hybrid graphics, applications don't necessarily use the GPU you'd expect.

That's a problem when you're trying to run models on your RTX 4090 and your browser decides the integrated GPU looks perfectly adequate.

So my script sets four environment variables:

VK_LOADER_DRIVERS_SELECT='*nvidia*'
__NV_PRIME_RENDER_OFFLOAD=1
__GLX_VENDOR_LIBRARY_NAME=nvidia
__VK_LAYER_NV_optimus=NVIDIA_only

Here's what they're for:

VK_LOADER_DRIVERS_SELECT filters the Vulkan driver manifests so that the NVIDIA driver is selected.
__NV_PRIME_RENDER_OFFLOAD=1 enables NVIDIA PRIME render offloading.
__GLX_VENDOR_LIBRARY_NAME=nvidia selects NVIDIA for GLX vendor dispatch.
__VK_LAYER_NV_optimus=NVIDIA_only tells NVIDIA's Optimus Vulkan layer to expose only the NVIDIA GPU.

Not all four variables necessarily matter for every application or graphics path, but this combination was part of my working configuration.

The important thing was making sure Chrome could actually access and use the GPU I wanted.

2. Making Wayland cooperate by... not using native Wayland

This one still makes me laugh.

I'm running a Wayland desktop, but my working Chrome launcher includes:

--ozone-platform=x11

That tells Chrome to use its X11 backend, which runs through XWayland inside my Wayland session.

At the time, I was running into problems getting Vulkan and Chrome's native Wayland backend to cooperate with NVIDIA.

Running Chrome through XWayland was the workaround that finally worked for my setup.

So after all that effort to get things running properly under Wayland, part of my solution was essentially telling Chrome to pretend it was running under X11.

Sometimes the practical solution isn't the elegant one.

It's the one that actually works.

3. Giving Chrome its own profile

This was one of the more useful discoveries.

--user-data-dir="$CHROME_PROFILE_DIR"

Chrome normally reuses an existing browser instance when you try to launch it again with the same profile.

So if Chrome is already open and you try launching another window with different GPU flags, you might discover that your new settings aren't actually being applied.

Using a separate profile directory gives my WebGPU launcher its own Chrome process and GPU configuration.

That also means I can keep my regular browser open while running a separate instance for development.

No need to mess with my normal browsing setup every time I want to test something.

4. Enabling Vulkan and WebGPU

Finally, these two flags:

--enable-unsafe-webgpu
--enable-features=Vulkan

The first enables experimental WebGPU support and bypasses certain GPU restrictions.

The second enables Chromium's Vulkan graphics feature.

There's an important distinction here: enabling Vulkan in Chrome doesn't necessarily guarantee that WebGPU itself is using Vulkan through Dawn, Chromium's WebGPU implementation.

The exact behavior depends on your Chromium version, platform, and graphics configuration.

Also, --enable-unsafe-webgpu is intended for development and testing. It's not something I'd recommend casually enabling in your everyday browser.

A note about newer Chrome versions: WebGPU support on Linux has been improving, so you might not need this exact configuration anymore. In particular, newer releases have expanded support for Intel and NVIDIA hardware. Check your current browser and driver support before copying every flag into your own setup.

How to check whether it's actually working

After launching Chrome with the script, open:

chrome://gpu

Look at the Graphics Feature Status section.

Ideally, you want to see hardware acceleration enabled for WebGPU and Vulkan rather than software fallbacks.

It's also worth checking the GPU and driver information to make sure Chrome is using the NVIDIA device instead of Intel or a software renderer like SwiftShader.

But don't stop there.

Being able to see WebGPU listed as hardware accelerated doesn't guarantee your actual application will run correctly.

Try running a real WebGPU sample or the model you're planning to use.

I've learned this the hard way more than once.

For example, while building my recent Mimu note-taking app, Safari on my iPhone reported that WebGPU was available. But attempting to initialize the Whisper model with WebGPU caused the tab to crash and reload.

The WASM version worked fine.

And for that particular small model, WASM was fast enough that using WebGPU wasn't worth the trouble anyway.

That was another useful reminder that the theoretically faster option isn't always the best one.

And then I forgot where I put everything

So here's where this whole thing comes full circle.

Recently, I've started keeping detailed build logs for my projects.

Not just what I built, but what broke, what I tried, why I made certain decisions, and what I'd do differently if I approached the same problem again.

Writing more on DEV has actually encouraged this habit. Thinking about what I might eventually write makes me pay more attention to what I'm doing while I'm building.

And I've already found myself going back through my notes and reconsidering decisions I made just a day or two earlier.

Which got me thinking about all those earlier experiences with WebGPU.

I wished I'd documented them better.

Turns out, I had.

I just couldn't remember doing it.

My AI agent found the original launcher in:

~/.local/bin/chrome-webgpu-nvidia

The desktop entry was in:

~/.local/share/applications/

And the documentation and additional copies were sitting in my PINKPIXEL/RESOURCES directory.

In two different folders.

I had already done everything I was wishing past me had done.

I just hadn't done a particularly good job of making that information easy to find again.

Which is even funnier considering I'm currently building an app designed to help people capture, organize, and remember things.

Apparently, I really do need it.

What I learned from all this

The technical lesson here is that getting WebGPU working on Linux can involve more than just enabling a browser flag, especially with hybrid graphics.

Depending on your hardware and software versions, you may need to pay attention to which GPU is being selected, which graphics backend Chrome is using, and whether your application is actually getting hardware acceleration.

But I think the bigger lesson for me has less to do with WebGPU.

I've built a lot of things over the years. I've solved problems, experimented with technologies, and figured out workarounds that took far more effort than I expected.

And then I moved on to the next interesting thing.

I didn't always stop to think about what I'd learned or how useful that experience might be later.

That's something I've been trying to change.

Keeping build logs has made me more thoughtful about the decisions I'm making, and writing about my experiences has encouraged me to look at them more closely.

Sometimes that means discovering a better way to approach something.

Sometimes it means remembering a useful technique.

And sometimes it means finding out that I already solved a problem, documented it, backed it up twice, and completely forgot about the whole thing.

At least now I know where my WebGPU script is.

For the moment, anyway.

In Defense of Being a Little Lazy

Jessica Doering — Wed, 21 Oct 2026 02:02:53 +0000

This week's DEV challenge is about building something that rewards laziness.

Which did make me laugh a little bit.

We're usually encouraged to be more productive, work harder, get more done, and make better use of our time. And now here's a challenge asking us to reward people for being lazy.

But the more I thought about it, the more I started wondering whether laziness is really such a bad thing.

Because there are different kinds of laziness.

There's the kind where you avoid doing something you really should be doing. I'm certainly guilty of that sometimes.

But then there's the kind that makes you look at a tedious, repetitive task and think, there has got to be a better way to do this.

And I think that second kind deserves a little more credit.

Sometimes laziness makes us creative

As developers, we do this all the time.

We'll spend hours building a tool to automate something that probably only takes a few minutes to do manually.

Does it always make sense? Absolutely not.

Do we do it anyway? Of course we do.

But I think there's something valuable in that instinct. It's not necessarily about being unwilling to work. Sometimes it's about being unwilling to keep doing work that doesn't need to exist.

That kind of laziness can lead to some pretty clever solutions.

But what about doing nothing?

Here's where I think it gets even more interesting.

We've gotten so used to measuring everything in terms of productivity that even our free time sometimes feels like it needs a purpose.

We take breaks so we can come back refreshed and work harder. We track our sleep so we can perform better. We turn hobbies into projects, projects into products, and sometimes products into businesses.

And there's nothing inherently wrong with any of that.

But does everything really need to accomplish something?

What about doing absolutely nothing just because you feel like it?

Not to recharge. Not to improve your focus. Not because it's part of some carefully planned routine.

Just because you want to.

I think there's value in allowing ourselves that kind of freedom, too.

Maybe it's about choosing where our effort goes

I'm starting to think the good version of laziness isn't really about avoiding effort.

It's about being more selective with it.

Sometimes that means finding a smarter way to do something.

Sometimes it means recognizing that something doesn't need to be done at all.

And sometimes it means giving yourself permission to spend an afternoon doing something completely unproductive without feeling guilty about it.

I have been diligently working on my challenge submission, which I suppose is the opposite of being lazy, but the theme for this week got me thinking.

Maybe laziness has a little more going for it than we give it credit for.

What Do You Make When You Can Make Anything?

Jessica Doering — Tue, 20 Oct 2026 16:45:47 +0000

I have more creative freedom than I've ever had.

Some days, I have so many ideas that I can't wait to sit down and start building.

Other days, I open my editor, stare at the empty screen, and can't think of a single thing I want to make.

It's not because I've run out of possibilities.

It's because I've got too many.

When everything sounds interesting

I've always been someone who likes making things. I get curious about something, start wondering how it works, and before long I'm opening a new project folder.

Sometimes it's something practical. A tool that solves a problem I've run into, or something I wish existed but haven't been able to find.

Other times, it's something completely unnecessary that just sounds fun to build.

And sometimes I don't even care all that much about the finished product. I just want to see if I can make it work.

That's one of my favorite things about programming. There's always something new to explore, something to figure out, or a random idea that might actually turn into something interesting.

But there's a downside to being interested in so many things.

I can sit down with every intention of working on something and find myself mentally bouncing between a dozen different possibilities.

Maybe I should finish one of my existing projects.

Maybe I should try that new library I came across yesterday.

Maybe I should build that little CLI tool I've been thinking about.

Or maybe I should make something entirely different.

And somehow, after considering all of those options, I end up doing absolutely none of them.

Not because I don't want to make something.

I want to make everything.

The barriers are disappearing

I think AI has made this feeling even more noticeable for me.

There was a time when an idea came with a fairly substantial list of things we'd have to figure out before we could even start building it.

Do we know the language? Could we work with the framework? Would we have to spend weeks learning something new just to get a basic version running?

Those questions might not necessarily stop us, but they did help narrow down what we were realistically going to attempt.

Now, a lot of those barriers are smaller.

I can experiment with a language I'm unfamiliar with, explore a framework I've never used, or take an idea much further than I could have on my own in the same amount of time.

And I love that.

I still have plenty to learn, and AI certainly doesn't make the hard parts of building software disappear. But it does make more ideas feel within reach.

Which means I have fewer reasons to dismiss an idea before I start.

That sounds great. In theory.

Most of the time, it is.

But it also means that almost every passing thought can turn into a potential project.

And when nearly everything feels possible, choosing what to spend my time on becomes its own challenge.

I don't think it's always a creative block

I've been thinking about the difference between having no ideas and having too many.

Because from the outside, they can look exactly the same.

You sit there staring at an empty editor, not writing a single line of code.

But what's happening in your head can be completely different.

Sometimes I genuinely don't feel inspired. Nothing sounds particularly interesting, and I'd rather go do something else.

Other times, I have so many ideas competing for my attention that I can't settle on one long enough to begin.

It's almost like standing in front of an enormous menu where everything looks good.

You'd think having more choices would make the experience better.

Instead, you spend twenty minutes trying to decide what you want.

And the funny thing is, I know perfectly well that I don't have to make the best thing.

I'm not running a company where every project needs a business case. I'm not trying to build the next big startup every time I sit down at my computer.

Most of the time, I'm just making things because I enjoy making them.

So why does choosing sometimes feel like such a big decision?

The things I could be making

I think part of it is that every project I choose to work on represents a bunch of other projects I'm not choosing.

If I spend the night working on a terminal app, I'm not experimenting with that interesting new UI framework.

If I start something new, I'm not finishing something old.

If I spend three hours exploring an idea that goes nowhere, I could have spent those three hours improving something I already built.

And yes, I realize how ridiculous that sounds when I'm talking about something I do for fun.

But I think that's part of what happens when you're curious about a lot of things and have the tools to pursue them.

You start feeling the weight of all the things you could be doing.

Even when nobody is asking you to do any of them.

I also think there's something strangely exciting about an idea before you start building it.

In your head, it's full of potential. You can imagine what it might become, all the interesting features you could add, and all the things you'll learn along the way.

Once you actually start, you have to make decisions. You run into limitations. Some parts are less interesting than you expected.

The idea becomes a real project, with all the ordinary work that comes with one.

And meanwhile, somewhere in the back of your mind, another shiny idea is waiting.

Maybe I don't need to make anything

I love that I can sit down at my computer and turn some random thought into something real.

I love learning new things, trying unfamiliar technologies, and making tools that probably wouldn't exist if I hadn't decided to build them.

But I'm starting to wonder if I've gotten so used to having something to work on that sitting down without a project feels like a problem I need to solve.

Maybe not every ounce of free time needs to become a new repository.

Maybe sometimes I can just explore something without turning it into an application.

Or spend some time actually using the things I've already made.

Or close the editor and do something else entirely.

I don't think the answer is to stop starting projects. Starting things is one of the ways I learn, and honestly, it's a huge part of what makes programming fun for me.

And I don't think I need to force myself to finish everything I begin, either. Sometimes an experiment has already given me what I wanted from it, even if it never becomes anything more.

Maybe the harder thing for me to learn is that having the ability to make something doesn't mean I have to.

That I can have ten ideas and choose just one of them without worrying about the other nine.

And that sometimes, when nothing feels quite right, I can simply leave the editor closed.

Because the possibilities aren't going anywhere.

Maybe having the freedom to make anything also means having the freedom to make nothing.

The Terminal Made Me a Better Developer (And Not for the Reasons I Expected)

Jessica Doering — Mon, 19 Oct 2026 00:36:51 +0000

When I first started using the terminal, sure, it was useful. I could navigate around directories, install packages, run a dev server, do some Git stuff. But most of those things could also be done by clicking a few buttons.

And clicking buttons seemed perfectly reasonable to me.

I wasn't really sure about being one of those people who does absolutely everything from a terminal just because I can.

But the more I got into development, and especially the more time I spent working with Linux, the more I found myself using it.

Sometimes because it was faster. Sometimes because whatever I was trying to do didn't have a convenient graphical option. And sometimes because I was following instructions and had absolutely no idea what half the commands were doing.

Eventually, I started getting curious about that last part.

What was that command actually doing? Why did it work? Why did it fail? And why was I running it in the first place?

Somewhere along the way, I realized I was learning a lot more than how to use a command line.

I was starting to understand how things worked underneath all the nice interfaces I'd gotten used to.

And that's been far more useful than learning to type commands quickly.

I started paying more attention to the filesystem

I've always understood files and folders. I think most of us have been moving things around in file managers for years without giving it much thought.

But working in the terminal made me pay attention to things I normally wouldn't have noticed.

For example:

pwd
ls -la
cd ..

Nothing exciting there, right?

But when you're working in the terminal, knowing where you are actually matters.

I've lost count of how many times I've tried running something only to discover I wasn't in the directory I thought I was.

Or wondered why a configuration file wasn't showing up, only to remember it was hidden.

Or had something fail because I used a relative path without thinking about what it was relative to.

These are pretty basic things, but they're also things I could get away with not thinking about when I was just clicking through folders.

I started paying more attention to hidden files, symbolic links, absolute versus relative paths, and where applications store their configuration.

And suddenly, a bunch of little things that used to confuse me started making more sense.

Not because the terminal magically made me smarter. I just had to understand what I was doing instead of relying on an interface to handle it for me.

I finally started understanding processes

This was a big one for me.

When you open an application normally, you click an icon and it opens. When you're finished, you close it.

Simple enough.

But there's a lot going on behind that, and I didn't always give it much thought.

Running things from the terminal made processes a lot more visible.

Especially when working on web apps.

If you've spent any time developing with Vite, you've probably encountered the dreaded port-already-in-use situation.

You try to start your dev server, and something is already sitting on the port you wanted.

Sometimes it's another instance of your app that you forgot was still running. Ask me how I know.

Instead of just closing random terminal windows and hoping for the best, I started learning how to see what was actually running.

ps aux
pgrep -af node
ss -ltnp

And if I specifically want to know what's listening on port 5173:

ss -ltnp | grep ':5173'

These commands let me investigate the processes and listening sockets on my system. Depending on permissions, I might not be able to see every process associated with a socket, but it's a useful place to start.

It seems like a small thing, but understanding the relationship between a running application, its process, and the port it's using helped a lot of other concepts click for me.

Before, I knew my dev server was running because the browser showed my app.

Now I had a better idea of what running actually meant.

Permissions started making a lot more sense

Linux permissions were another one of those things I sort of understood in theory.

Read, write, execute. Got it.

Except apparently I didn't always get it, because I'd still run into situations where I couldn't modify a file or execute a script and wonder what the hell was going on.

The terminal made it easier to actually look at what was happening.

ls -l script.sh
stat script.sh

Instead of just getting a permission-denied message and being annoyed about it, I could check who owned the file and what permissions it had.

I started understanding why a file might be readable but not writable, or why a script wouldn't execute even though it was sitting right there.

I also learned that execute permission on a directory doesn't mean quite the same thing as execute permission on a file. On a directory, it's about being able to traverse it.

That's one of those little Linux details that seems weird until you understand it.

And then there's sudo.

I think it's pretty easy when you're learning Linux to see a permission error and think, well, I'll just stick sudo in front of it.

Problem solved!

Except maybe not.

You might get the command to work, but you still don't know why it needed elevated permissions. And depending on what you're doing, you might end up creating files owned by root that really shouldn't be.

I've learned that getting something to work and understanding why it wasn't working are two very different things.

That lesson has come up quite a bit in development, actually.

Networking became a little less mysterious

Networking is one of those subjects where I understood the general concepts long before I felt comfortable troubleshooting anything.

I knew what DNS was. I knew what ports were. I understood that applications communicate over networks.

Great.

But when something wouldn't connect, that knowledge didn't necessarily tell me where to start.

Was the hostname resolving? Was the server actually responding? Was my application even listening on the port I thought it was?

Or had I somehow managed to break something entirely unrelated?

The terminal gave me a way to start narrowing those things down.

dig example.com
curl -I https://example.com
ss -ltn

These commands look at different pieces of the puzzle.

dig lets me check DNS resolution.

curl lets me make an HTTP request and inspect the response.

And ss lets me see which TCP ports are listening on my own system.

None of these commands will magically explain every network problem, obviously. But they give me somewhere to start.

And I think that's what made the biggest difference.

I stopped treating every connection failure as one big mysterious problem and started trying to figure out which part was actually failing.

Because "my app can't connect" could mean quite a few different things.

And knowing which one you're dealing with makes troubleshooting a whole lot easier.

I got better at actually reading errors

This might sound ridiculous, but I think one of the most useful things I've learned from working in the terminal is to actually read what my tools are telling me.

Not just glance at the error, decide something is broken, and immediately start trying things until it works.

I mean really read it.

When you're working in the terminal, you see a lot of output.

Compiler errors, dependency warnings, stack traces, server logs, and sometimes an absolutely ridiculous wall of text because one little thing went wrong.

At first, all that output can be overwhelming.

And sometimes it still is.

But the more I worked with it, the more I started recognizing what was worth paying attention to.

A missing environment variable isn't the same thing as a network request failing.

A dependency conflict isn't a syntax error.

And an application that crashes immediately is a very different problem from one that's running perfectly fine but not responding the way you expected.

I still have plenty of moments where I stare at an error wondering what on earth it's trying to tell me.

But I'm much more likely now to investigate the actual error instead of immediately throwing another possible solution at it.

And when I do have to look something up, I usually have a much better idea of what I need to look up.

That's made a pretty big difference.

The real benefit has been learning how to investigate things

I think this is the part I didn't expect when I started using the terminal more.

I thought I'd learn some useful commands. Maybe speed up a few workflows.

What I didn't expect was how much it would change the way I approached problems.

Now, when something doesn't work, I'm more likely to start asking questions.

Where is this command actually running?

What process is using that port?

Who owns this file?

Is the server responding at all?

What does the error message actually say?

And I don't mean that I always know how to figure these things out.

Far from it.

Half the time I'm still looking up commands, reading documentation, or finding out that the thing I thought I understood works a little differently than I expected.

But that's kind of the point.

I don't think being comfortable with the terminal means memorizing hundreds of commands or being able to type some ridiculous one-liner from memory.

It means knowing that there's probably a way to investigate what's happening, and being willing to figure out how.

Sometimes that means using a command I already know.

Sometimes it means spending twenty minutes reading documentation to figure out why that command didn't do what I expected.

Both are useful.

A few things worth experimenting with

If you're relatively new to the terminal, or you've mostly been using it to install packages and start development servers, here are a few little exercises worth trying.

These examples are mostly aimed at Linux, since that's what I use. Some commands will be different on macOS or Windows.

The goal isn't to memorize them. It's to look at what they show you and try to understand why that information matters.

1. Take a closer look at a project directory

Open a terminal inside one of your projects and try:

pwd
ls -la
find . -maxdepth 2 -type f

Look at where you are, which files are hidden, and how things are organized.

Try running the commands from different directories and see what changes.

Pay particular attention to relative paths. They're simple until they're the reason something isn't working.

2. Find your development server

Start a development server like you normally would.

Then open another terminal and run:

pgrep -af node
ss -ltnp

If you're using a Node-based development server on Linux, see if you can find its process and the port it's listening on.

If you can't see the process information you expected, look into why. It might be a permissions issue, or your server might be running through a different executable.

The investigation is the exercise.

3. Look at file permissions

Pick a file in your project and run:

ls -l package.json
stat package.json

What do all those permission bits mean?

Who owns the file?

What can the owner do that other users might not be able to?

You don't need to go changing permissions just to experiment. In fact, I'd recommend understanding what you're looking at before doing that.

4. See what happens during an HTTP request

Try:

curl -v https://example.com

There's quite a bit of information in that output.

Look at the connection details, TLS negotiation, request headers, and response headers.

You don't need to understand every line right away.

Pick something unfamiliar and look it up.

That's literally how I've learned a lot of this stuff.

5. Experiment with pipes

Here's a tiny one:

printf 'apple\nbanana\napricot\n' | grep '^a'

You should see:

apple
apricot

That little | sends the output of one command into another command.

It's such a simple idea, but it's also one of the things that makes Unix-like command-line environments so useful.

Instead of needing one giant tool that does everything, you can connect smaller tools together.

Once that concept clicks, a lot of terminal workflows start making more sense.

And it's worth experimenting with beyond this little example.

You don't have to do everything in the terminal

I should probably mention this because I know how these conversations sometimes go.

I am not suggesting everyone should abandon graphical applications and spend the rest of their lives staring at a terminal window.

I use graphical applications all the time.

There are plenty of things I'd rather do with a good interface, and I'm not going to make my life unnecessarily complicated just to prove I can do something from the command line.

I also don't think using a terminal automatically makes someone a better developer.

You can copy and paste commands all day without understanding a single thing about what they do. Just like you can click around a graphical interface without really knowing what's happening.

The difference, at least for me, has been curiosity.

When I started paying attention to what commands were doing, why they were working, and why they occasionally failed spectacularly, I started learning a lot more.

The terminal just makes it particularly easy to see some of the things that graphical interfaces usually handle for you.

It's not really about typing faster

I started using the terminal because it was useful.

And sure, I've gotten faster at certain things. There are plenty of tasks where opening a terminal and typing a command is easier than clicking through a bunch of menus.

But that hasn't been the most valuable part.

What's really changed is how I see the software I'm working with.

An application isn't just something that opens when I click an icon anymore. There are processes running, files being accessed, permissions being checked, network connections being made, and all kinds of smaller things happening behind the scenes.

And when something goes wrong, I have a much better idea of where to start looking.

I still have a ridiculous amount to learn. I look things up constantly, experiment with things I don't fully understand yet, and occasionally break something because I was a little too confident.

But I'm getting better at figuring things out.

And that's what working in the terminal has really helped me with.

Not becoming some command-line expert.

Just becoming a better investigator.

Which, the more I learn about development, the more I realize is a pretty important skill.

I Built a New Tab Extension for DEV

Jessica Doering — Sun, 18 Oct 2026 17:13:41 +0000

I spend a lot of time on DEV these days. Reading posts, finding interesting projects, participating in challenges, and occasionally writing something myself.

I also like daily.dev. Having a feed of developer content right there whenever I open a new tab is pretty convenient.

So naturally, I started thinking... what if I had something like that, but just for DEV?

And because apparently I can't have an idea without turning it into another project, I built one.

It's called DEV Tab, and it's a free, open-source browser extension that replaces your new tab page with a feed of posts from DEV.

It's now available on the Chrome Web Store.

Install DEV Tab for Chrome

Firefox support is built too, and the add-on is currently awaiting review. I'll update this post with the link once it's approved.

Firefox was approved!
Install for Firefox

A little more than just a feed

The original idea was pretty simple. Open a new tab, see what's happening on DEV, and click through to anything interesting.

But, as usual, I kept thinking of things to add.

You can browse posts from Today, This Week, Rising, and Latest, along with dedicated sections for trends, events, podcasts, and videos.

There are also tag filters, so you can quickly jump between subjects you're interested in. You can save your favorite tags, hide tags you'd rather not see, and follow posts from specific DEV organizations.

A few other things I added:

Search directly from the new tab page.
Keyboard navigation using arrow keys and Enter.
A compact view if you'd rather see more posts and fewer images.
Reaction counts and previews of the three newest comments.
A shortcut to create a new DEV post.
Feed caching, so opening a new tab doesn't mean waiting for everything to load again.

Nothing particularly revolutionary here. I just wanted a convenient way to explore DEV without having to go looking for things.

Then I decided it needed a dashboard

This part wasn't in my original plan, but I spend enough time writing on DEV that I thought having a better overview of my own activity would be useful.

If you add your DEV API key in the extension settings, you unlock some additional features, including a personal dashboard.

The dashboard includes your follower count, views, reactions, comments, and new followers, with options to look at the last 7, 30, or 90 days.

There's also a daily views chart, an activity heatmap that lets you browse previous years, and a list of your published posts and drafts.

You can see recent followers, top supporters, and where your readers are coming from, too.

I particularly like having the activity heatmap and post statistics together. It's interesting to look back and see when I was active and how different posts performed.

The dashboard screenshot above uses fictional example data, by the way.

Connecting your DEV account is completely optional

You don't need an account or API key to use the extension. The public feeds, search, filters, and other browsing features work without one.

But if you do connect your DEV account, you also get access to your personal feed based on the tags you follow, your reading list, and semantic search.

You can generate an API key from your DEV settings.

The extension doesn't have a backend, analytics, or tracking. Your API key stays in your browser's local extension storage and is only sent to DEV for authenticated API requests.

I wanted to keep it simple and avoid introducing a separate service just to display information DEV already makes available.

A few limitations

There are a couple of things I would have liked to include but couldn't because of the DEV API.

For example, you can't directly react to posts, leave comments, or save articles to your reading list from the extension.

You can view reaction counts and preview comments, but interacting with a post opens it on DEV itself.

I'd love to have those actions directly in the feed someday, but for now, that's a limitation of what's available through the API.

Built with WXT, React, and TypeScript

I used WXT for the extension framework, along with React and TypeScript.

This was my first time using WXT, and I really liked being able to build for Chrome and Firefox from the same codebase.

One thing I spent some time on was making sure the feed wouldn't constantly refetch everything whenever a new tab opened. The first page of each feed gets cached for ten minutes, and previously loaded posts can still appear if you're offline.

It's a small thing, but when you're replacing something as frequently used as the new tab page, I think it matters.

Give it a try!

DEV Tab is open source, so you can take a look at the code, report bugs, suggest features, or contribute if you'd like.

Chrome Web Store

GitHub

The Firefox version is currently awaiting approval, and I'll add the link here when it's published.

This started as one of those little "wouldn't it be nice if..." ideas, and somehow turned into a full browser extension with a personal analytics dashboard.

I guess that's what happens when you keep finding things you want to build.

If you use DEV regularly, I'd love to hear what you think! And if there's something you'd find useful in a future version, let me know.