A model can understand your prompt and still give you an interaction you would never ship. That was my biggest takeaway from testing open source AI for design on our own landing page at The Design Project.
I gave GLM, Kimi, and Claude Opus the same creative challenge: turn three separate roles into one connected product team through a scrolling animation. All three picked up the idea. The difference was how clearly, and how beautifully, they communicated it.
Claude produced the strongest result in this test. The experience also gave me a more useful way to evaluate cheaper models: look at the work required to reach something you would actually use, alongside the cost of generating it.
Table of contents
- Can open source AI for design produce usable UI?
- The landing page test
- GLM vs. Kimi vs. Claude: the results
- How to compare AI design costs
- Where does your product data go?
- How to test open models in your workflow
Can open source AI for design produce usable UI?
Open source AI for design can generate interface code and interaction concepts, but the output still needs design review. In my landing page test, GLM and Kimi captured the basic idea while Claude Opus delivered the strongest execution. Treat that result as evidence about this specific task, rather than a universal model ranking.
There is also a distinction worth making between open weights and open source. Access to a model’s weights can give you more options for running it, but the license determines what you can do with it. For example, Moonshot publishes Kimi K3’s weights under its own Kimi K3 License. Review the official model repository before choosing a deployment approach.
For a product team, the interesting questions are practical. Can the model handle your work? Can you run it through a provider that fits your requirements? Does the output save time once someone has reviewed and refined it?
The landing page test
We had recently redesigned the TDP landing page, and I liked the visual direction. The next opportunity was to make the movement more expressive. Our header showed a designer, an engineer, and a product manager as separate elements, but the message we wanted to communicate was that those roles increasingly work together throughout the product cycle.
I wanted visitors to understand that shift through the scrolling experience. Start with three distinct roles, then bring them together into one team. The animation needed to carry the story.
I tested GLM-5.3-Flash and Kimi K3 against Claude Opus. Each received the same core brief, and I subsequently shared the same scrolling reference with all three. My prompt was conversational: I described the existing header, explained the message, and asked them to explore how the elements could converge.
This was a first-pass exploration of one landing page interaction. I did not run repeated trials or a production accessibility audit, and the tools around each model also affected the experience. The results tell us what happened in that workflow.
GLM vs. Kimi vs. Claude: the results
Claude Opus gave me the clearest visual story. GLM understood the concept but needed refinement, and Kimi’s execution was the weakest of the three in this particular comparison.
| Model | What I observed | What still needed work |
|---|---|---|
| GLM-5.3-Flash | The separate roles came together into one product team. | The copy felt awkward, and the interaction lacked polish. |
| Kimi K3 | It attempted a similar convergence concept. | The visual execution did not land; I preferred GLM’s result. |
| Claude Opus | It built a more coherent sequence around silos converging into one team and one product cycle. | One transition still felt awkward and deserved another pass. |
GLM understood the idea
When I scrolled through GLM’s result, I could see the separate elements turning into one team. The concept was there. But the copy and movement did not feel resolved enough to use as the centerpiece of our landing page.
The workflow also became harder to follow after I supplied the reference. It appeared to struggle with the images, and the interface did not clearly explain what was happening. That uncertainty matters when you are trying to decide whether to wait, intervene, or change direction.
Kimi did not deliver the visual result I hoped for
I was particularly curious about Kimi’s visual capabilities. In this run, though, it produced a similar basic idea with weaker execution than GLM. The result needed more design direction before I would consider moving forward with it.
That is a useful distinction when evaluating AI-generated UI. Recognizing the requested concept is one milestone. Turning it into a convincing interaction requires decisions about pacing, hierarchy, copy, and how the elements relate to each other.
Claude connected the motion to the message
Claude’s result made the progression feel much more intentional. The roles began as silos and converged into one team, with supporting text that reinforced the product-cycle story. I could see the direction immediately (and I was very excited about it).
I estimated roughly 10 minutes for Opus and about 19 minutes for GLM during the session. Those were informal observations, rather than controlled speed measurements. Kimi was still working around the 20-minute check-in, but I did not establish a reliable final duration.
My preference was clear even with the remaining critique: I would take Claude’s direction into the next design iteration.
How to compare AI design costs
Compare the cost of getting to an acceptable result, including generation, retries, and human refinement. A low token price becomes valuable when the model can complete enough of the task to reduce the work your team still needs to do.
Lower pricing was one reason I wanted to try these models. But a price comparison needs the exact model, hosting provider, input and output usage, and cache assumptions. The illustrative token estimates from my session were separate from the actual cost of these landing page runs.
For your own test, record the provider’s billed cost alongside the number of follow-up prompts and the time spent fixing the output. An inexpensive first pass may be useful for a tightly specified component. A more expensive generation may be worthwhile when it gets a difficult interaction much closer to your intended direction.
I still see room to explore open models for coding and more constrained tasks. This experiment gives me a reason to test those tasks separately, rather than assuming the landing page result applies to everything.
Where does your product data go with an open model?
Your product data goes to the infrastructure receiving the request. An open model can give you options about who runs it, subject to its license and hosting availability. It does not automatically make your workflow private, local, or appropriate for every kind of company information.
This is where I explored Baseten. It provides model inference infrastructure: inference means running a trained model to generate an output. Baseten offers hosted model APIs as well as dedicated deployments, so the model developer and the infrastructure provider can be different organizations. Its platform documentation explains those options.
The deployment choice matters. Calling a hosted API is a different setup from deploying a model on dedicated infrastructure. Before bringing product information into the workflow, establish which endpoint receives it, what gets logged or retained, who can access it, and whether the configuration meets your team’s requirements.
That flexibility is one of the reasons I am interested in open models, even when a particular design result falls short.
How to test open models in your AI design workflow
Start with one bounded task and give each model the same context. My setup used Conductor, with Baseten connected through OpenCode. You can also connect Baseten directly in OpenCode using the process in its provider documentation.
- Choose a real design problem. Use one header, onboarding step, or interaction. Define what a successful result needs to communicate before generating anything.
- Connect your provider. Create a Baseten API key, run
/connectin OpenCode, select Baseten, and enter the key. In the Conductor setup I used, the equivalent configuration was available through its model settings and OpenCode configuration. - Select an available model. OpenCode’s
/modelscommand opens the model picker. Confirm the model your provider currently offers and record its exact identifier. - Keep the starting conditions consistent. Give each run the same project state, brief, assets, and reference. Separate workspaces help keep one model’s changes from influencing another’s result.
- Review the working interaction. Check whether it communicates the intended message, then assess layout, copy, responsiveness, keyboard use, and reduced-motion behavior before treating it as ready to ship.
- Record the effort to improve it. Track cost, elapsed time, follow-up prompts, and the fixes you still need. Repeat the test before making a team-wide tooling decision.
Here is a tightened version of the brief I used, which you can adapt:
Our landing page header shows a designer, an engineer, and a product manager as three separate elements. Explore a scroll-driven interaction that brings them together into one product team. The movement should communicate how these roles collaborate across the product cycle while preserving their individual expertise. Work within the existing visual direction and focus on the header. Use the supplied reference to understand the kind of scrolling experience we want.
The most useful part of the brief is the message behind the movement. When you can explain what the interaction needs to communicate, you have a much clearer basis for judging the result.
Bring model choice into your product process
For this landing page, Claude was the direction I wanted to keep developing. GLM and Kimi gave me a clearer sense of what I would need to test next before relying on them for this kind of visual work.
At TDP, we help product teams assess their current process, choose tools, and build AI workflows around the work they actually need to ship. If your team is working through those decisions, explore working with The Design Project.
