There is a slightly awkward question in the current model landscape: if Astra is available, why am I still reaching for Luna?
Because the best model for a task is not always the most capable model in the catalogue. Sometimes it is the model that can make the smallest correct change, understand the existing visual language, and get out of the way quickly.
For the homepage redesign I have been working on, that model has been Luna.
Start with the model that can see the design
My design-first entry point was GLM 5.x through its web URL. I still like that surface for visual work because it lets me start with the page as a composition: hierarchy, atmosphere, contrast, density, typography, and the feeling a visitor gets before they read every word.
The first question was not “what framework should this use?” It was closer to: “What should this page feel like when someone lands on it?”
That led to the direction visible in the current homepage: a dark, terminal-like interface over a stormy ocean image, a strong nameplate, restrained red-orange accents, a compact information block, and a bottom navigation that feels more like an instrument panel than a generic portfolio menu.
GLM gave me the design conversation. It helped establish the visual thesis before I got lost in implementation details. That distinction matters. Design-first does not mean asking a model to generate a finished website and accepting whatever falls out. It means using the model to explore the page’s identity before polishing its mechanics.
Astra Light is already a serious everyday model
I also have Astra. Astra Light, in particular, is better than the name might suggest. In my day-to-day work it is in the same practical tier as Sol on high reasoning: capable enough to understand a real codebase, make sensible edits, and preserve context across a focused task.
That is not a claim that the models are identical. They have different habits, different failure modes, and different strengths. It is a statement about the work I actually need done. For many frontend changes, the gap between “very capable” and “most capable” is invisible once the task has been reduced to a clear, bounded edit.
The useful lesson is not to crown one winner. It is to stop treating the model ladder as a single ranking. A model can be excellent for architecture and unnecessary for changing a button label. It can be brilliant at a first pass and wasteful for the twelfth tiny correction.
Luna handled the last mile
Once the visual direction was clear, I used Luna to do almost every minor change:
- nudge spacing and alignment;
- adjust the scale and rhythm of type;
- tune colours and transparency;
- refine the terminal header and footer controls;
- make the page feel less like a mockup and more like a finished surface;
- respond to each screenshot with one small, targeted correction.
The speed was the point. Luna could take the current state, apply the next small change, and return control quickly. I was able to keep the human visual loop active: make a change, look at the page, decide what feels wrong, describe that one thing, repeat.
That is a different workflow from handing a large redesign to a heavyweight model and waiting for a grand rewrite. The page improved through dozens of small judgements. Luna was the right size for those judgements.
And the token usage barely registered. I did not use 2% of the available allowance for this iteration cycle. That is not a vanity metric. It changes how freely I can explore. When each small correction is cheap, I do not have to bundle five guesses into one prompt. I can ask for the one change I can see, verify it, and continue.
Token efficiency is king here—not because tokens are the only measure of quality, but because efficient tokens buy more iterations. More iterations buy better visual judgement. For design work, that loop is often worth more than a single spectacular first answer.
The honest architecture: it is a single-page HTML app
There is another part of this process worth admitting plainly: the homepage is a single-page HTML app.
That is enough.
For a presentation page, the job is to establish identity, communicate what I do, show selected work, and give someone a clear next action. It does not need an elaborate application architecture just to prove that I know how to build one. There is no meaningful product value in adding routing, a server layer, a content database, or a state-management system when the page’s purpose is presentation.
The implementation still needs to be disciplined. A single HTML file can have good semantic structure, responsive behaviour, keyboard-friendly controls, sensible contrast, and maintainable CSS. “Simple” does not mean careless. It means the architecture matches the job.
If the page grows into a content system, a case-study library, authenticated interactions, or a proper product surface, the architecture can grow with it. Until then, a single-page HTML app is an honest and useful boundary.
The model stack I actually want
My current preference is not one model. It is a sequence:
GLM 5.x in the web UI
|
| establish visual direction
v
Astra Light or Sol high
|
| handle a larger, more connected implementation pass
v
Luna
|
| make fast, cheap, observable corrections
v
finished presentation pageSometimes I skip the middle. Sometimes Luna is enough from the start. Sometimes Astra is the better choice because the change crosses several components or needs more sustained reasoning. The point is to route by task shape rather than prestige.
Using Luna when Astra is available is not a downgrade. It is a sign that I am paying attention to the work. A fast model with a narrow brief can be more useful than a powerful model asked to overthink a one-line CSS adjustment.
The page in front of me is the proof I care about: design direction came from GLM, the capable general-purpose options were available, and Luna carried the page through its tiny corrections at speed. It is a small architecture, a small token bill, and a much better homepage.
That is exactly the kind of engineering trade I want more of.