A week with ChatGPT Sol and Luna at work — what actually felt different

Once options labeled Sol and Luna showed up in my ChatGPT model picker, I had to decide which one to leave as my default. So I spent a week alternating between the two on real work and kept notes on where each one felt “good enough.”

Let me set expectations up front. This is a personal review of a week spent alternating between the model options labeled Sol and Luna at work. There are no scores or benchmarks here — only qualitative impressions: how long I felt I was waiting, how many revision loops it took, and whether I could use the output as-is. The options and limits you see in the picker can vary by account, plan, and timing, so read this against what your own account shows.

How did I split the week?

Short answer: I sent the same kinds of tasks to both lanes and compared them by how many rounds of fixes it took to get something usable.

My usual ChatGPT workload falls into four buckets:

Code review and debugging help — pasting C++ and Linux error logs and narrowing down likely causes
Design note cleanup — turning scattered meeting notes into rationale and decisions
Everyday drafts — chat replies, issue descriptions, commit messages, short announcements
Blog post skeletons — outlining, and polishing sentences in Korean and English

For the first two days I ran everything through Sol, then everything through Luna for the next two. For the remaining three days I picked a lane per task myself. The comparison criteria were simple: how long the wait felt, how many times I had to re-ask before getting what I wanted, and whether I could use the result without editing it.

When did Sol clearly win?

Short answer: On tasks with several tangled constraints, where a wrong answer is expensive to back out of, Sol noticeably cut down the back-and-forth.

The biggest gap was in debugging help. When I pasted a build log, a linker error, and the relevant CMake snippet together, Sol didn’t stop at listing candidate causes — it pruned them on its own, along the lines of “given this symptom, this candidate is ruled out.” Luna produced a plausible list just as fast, but I had to feed it more context a few more times before it reached a similar conclusion.

Design note cleanup was also easier with Sol. When I gave it meeting notes that contradicted each other, Sol pointed out the contradiction first and asked which side should count as the decision. As a result, I rewrote the summary far less often.

The trade-off was a noticeable wait. Even short questions felt like they got a beat of thinking before the answer, so the two days I used Sol for lightweight things like chat replies were actually frustrating. My first impression of Sol was: worth the wait on heavy work, overkill on light work.

When did Luna actually do better?

Short answer: For short, repetitive drafting, Luna got to a “good enough” result faster, and not breaking my flow mattered a lot.

For everyday drafts, Luna simply fit my hands better. Commit messages, issue descriptions, and short announcements have a fixed shape and are easy to fix if they’re off, so a faster response meant higher productivity. Even when the first pass wasn’t perfect, trading quick tweaks like “shorter” or “plainer tone” several times felt natural.

Blog skeletons were similar. When I’m getting several outline options and picking one, speed basically is quality. Sol’s outlines were individually more logical, but since I was going to rework the skeleton anyway, that difference didn’t land.

Over the three days I chose lanes myself, I found that Luna was enough for most of my daily requests. I only switched to Sol when I was stuck on a problem or when the output would live on as a document.

What disappointed me?

Short answer: The line between the two lanes was blurrier than I expected, and sometimes deciding which one to use became a task in itself.

First, there was a choice cost. The time I spent asking myself “is this a Sol question or a Luna question?” quietly added up. For mid-difficulty work, like a small script fix, both gave similar results, and the deliberation felt wasted.

Second, Luna’s confidence. It’s a strength on light tasks, but on questions that hinged on facts it sometimes gave smooth, definitive answers. Because the prose read so well, it was easy to skip verification. I needed the habit of checking anything factual against official docs, regardless of lane.

Third, Sol isn’t a cure-all either. Its answers got longer and more careful, so when I wanted a one-line conclusion I sometimes got a long analysis back. It felt much better once I specified the format first, like “conclusion first, three lines.”

Finally, usage limits and availability can vary by account and over time, so “leave Sol on as the default and keep going” wasn’t always a realistic strategy. That’s something to judge from your own model picker and the official guidance.

Who should bother splitting between them?

Short answer: If you regularly get stuck on hard problems, Sol is worth keeping in reach; if most of your work is short drafts, Luna as the default is plenty.

Here’s the rule of thumb I landed on after a week:

Worth reaching for Sol: you often do debugging or design review with many layered constraints, where following a wrong answer is costly to undo
Luna as default is enough: most of your work is chat replies, summaries, commit messages, or short drafts you refine through quick back-and-forth
Don’t overthink it: if you only ask a few light questions a day, the time spent choosing may outweigh the difference

My conclusion is “Luna by default, Sol when stuck.” Rather than starting with Sol, running things through Luna quickly and handing off to Sol when two or three rounds still don’t narrow the answer was the least tiring workflow for me.

If tool subscriptions feel expensive, see only the discount route.