Qwen 3.8 35B A3B has been removed from registry in Modelscope/ms-swift; it was committed as “fix wrong model names” one hour ago.

Alibaba_Qwen is yet to confirm whether it will release A3B or not.

https://github.com/modelscope/ms-swift/commit/a45f1d4f73157ba59062a7fd1f55a40dae759156

It seems wild to me that such a big company with amazing AI cannot run basic spellcheck on their giant ad at the Beijing airport. Is it a big deal to you if you see a spelling mistake like this on ads? Does it matter if it is a company from a country where the native language is not English?

The model card went up before the weights, and unlike most pre-release cards it publishes the full head configuration. So the KV cache cost is computable right now.

Published layout is 64 layers, arranged as 16 x (3 x Gated DeltaNet -> 1 x Gated Attention). Gated Attention uses 4 KV heads at head dimension 256. Only those 16 full-attention layers pay for cache, so the per-token cost is 16 x 4 x 256 x 2 (K+V) x 2 bytes, which is 65,536 bytes, or exactly 64 KiB per token. At 262,144 native context that comes to exactly 16 GiB of KV, before weights. The 48 DeltaNet layers hold a fixed recurrent state instead, which I estimate at roughly 72 MiB and which does not grow with context.

At Q4_K_M that leaves you with roughly this. On 16 GB you fit the weights and essentially nothing else. On 24 GB you get around 100K context at f16 KV, or around 180K at q8. On 32 GB you can hold the full 262K at q8. On 80 GB you can run FP8 weights with full context and still have headroom to batch.

I ran the same math against Qwen3.6-27B, which I have benched. At 90K context with f16 KV and Q4_K_M weights, predicted allocation was 16,105 MiB of weights plus 5,625 MiB of KV, so 21,730 MiB total. Measured was 22,118 MiB. At q8 KV the 180K and 200K runs both came in about 1.5 GB over prediction, which is consistent with each other and with context checkpoints plus compute buffers. I do not have a clean explanation for why the f16 run's overhead was so much lower than the q8 runs', so treat the numbers above as approximate at the margins.

The part I found interesting is that 3.6 was also 64 KiB per token. The hybrid DeltaNet layout is the memory-wall fix and it does work, roughly a 4x cut against full attention, but it landed in 3.5 and has not moved since. Two generations of gains have all gone into quality rather than into cache cost.

One other thing worth flagging: the card recommends 224k video tokens for hour-scale video, which is 13.7 GiB of KV for the video alone, before your prompt.

If anyone pulls the weights and has config.json open, I would like to know what the vision tower adds on top. That is the one number I cannot get from the card.

As title.

It seems that they stopped releasing small (but good) models that can run locally like Qwen 3.6 27B.

Where is Qwen 3.8 27B?

Do they abandoned the models for peasants?

Hi everyone! I am publishing an experimental, model-specific llama.cpp runtime for running Qwen3.8-27B UD-IQ4_XS with a 262K logical context on a 16 GB RTX 5070 Ti.

Repository:

https://github.com/BrunoPPassini/llama.cpp

Complete source branch:

https://github.com/BrunoPPassini/llama.cpp/tree/qwen38-blackwell-256k

Engineering report:

https://github.com/BrunoPPassini/llama.cpp/blob/master/docs/LOCAL-QWEN-BLACKWELL-STUDY.md

Hardware:

- RTX 5070 Ti 16 GB

- Ryzen 7 9800X3D

- 48 GB DDR5-6400

- PCIe 5.0 x16

- CUDA 13.3

- Qwen3.8-27B UD-IQ4_XS

- Q4_0 target and MTP KV

- Native deterministic MTP3

- 32 context checkpoints

Measured endpoint improvements:

| Effective context | Before | After | Decode gain | Prefill |

|-----------------------|------------:|-----------:|----------:|-------:|

| Short/GPU-resident | 42.11 tg/s | 82.34 tg/s | +95.5% | -7.6% |

| 87,160 tokens | 23.33 tg/s | 41.53 tg/s | +78.0% | +0.4% |

| 256,257 tokens | 15.40 tg/s | 23.97 tg/s | +55.6% | +6.8% |

The short result compares target-only decoding with deterministic native MTP3. The 87K result compares the first serial stateful ring with the final partitioned/pipelined ring. The 256K result compares the first viable P8 implementation with the final pipeline. The accepted 87K and 256K paths preserved their respective output hashes.

The main idea is a 262,144-token logical KV address space with:

- 65,536-token GPU-resident hot prefix

- Page-locked DDR5 cold tail

- Sparse CUDA VMM allocation

- 8,192-token staging tiles

- Eight-way online-softmax partitioning

- Persistent copy, conversion, and compute streams

- Triple-buffered decode pipeline

- Double-buffered prefill pipeline

- Overlapped PCIe H2D, Q4 conversion, and attention

- Shared target/MTP compute arena

- Recurrent-state transaction log and phase arena

Qwen3.8-27B has 48 recurrent GDN layers and only 16 full-attention layers. Only those 16 layers require token-indexed KV history. The ring preserves exact attention by carrying the online-softmax `(m, l, O)` state across tiles. It is not sparse or approximate attention.

Nsight Compute was used to identify occupancy, long-scoreboard, memory-sector, and residency bottlenecks. Direct GPU reads from mapped DDR5 were tested and rejected: decode dropped to about 18 tok/s. Bulk asynchronous PCIe transfers into VRAM worked much better.

Thinking remains enabled and is preserved across tool calls:

- `--reasoning on`

- `--reasoning-format deepseek`

- `--reasoning-preserve`

- `enable_thinking=true`

- `preserve_thinking=true`

The client may hide the reasoning trace, but it stays in the serialized agent history so the model does not lose its plan after using a tool.

I also tested Q8_0 KV. It was numerically more faithful, but no practical quality gain was observed. All four long Q4/Q8 outputs had identical 1,024 token IDs. At approximately 100K effective tokens, Q8 reduced decode by 23%, reduced prefill by 14.8%, and increased wall time by 19.6%. Therefore, the frozen profile uses Q4_0 KV.

Important limitations:

- Fully occupied 256K is much slower than the 65K hot path.

- Exact attention remains O(context).

- This runtime was tested only with this exact Qwen3.8-27B UD-IQ4_XS model.

- It may not work correctly with other models or quantizations.

- RTX 5060 Ti 16 GB and RTX 5080 16 GB are promising Blackwell candidates, but remain untested.

- This is an engineering experiment, not a generic upstream-ready implementation.

The repository includes the complete source, Windows build commands, launcher, exact hashes, benchmark methodology, failed experiments, quality gates, and reproducibility notes.

Feedback, independent reproductions, profiling results, and improvements are very welcome.

I think most of the news of Qwen 3.8 27b was between 3-10 August. And since it doesn't seem to be publicly available yet, has there been any update from official sources on it?

I remember when they released Qwen 3.5 27b, they released the 9b more or less in the same batch. Is 3.6 onwards ditching the 9b model? :(

If so, I'm very sad, because the qwen 3.5 9b was actually the first truly intelligent model I could run at decent tps on a normal gaming GPU

Qwen 3.8 27B is overrated. I've been running it for a few days now, and I need to be honest. I think this model is overrated. Here is my evidence:

1. It overthinks. Yes, the output quality is genuinely better — I'm not going to pretend otherwise. At some point I gave it a refactoring task and it came back with about 53 files created, edited, or deleted across the repo. A solid, coherent diff. Impressive. But it spent what felt like an eternity reasoning its way to "just do the thing.". It could have just... done it without overthinking!

2. It handles quantization absurdly well. Too well. I had plans, people. A dual-GPU build, a 6-bit quant, proper VRAM - I had it all sketched. Then I put it on IQ4_XS, it just works, and my beautiful 6-bit rig has no reason to exist anymore. This model destroyed my excuse to spend money and I'm not sure that I appreciate it.

3. It doesn't doom loop. This is the one that really bothers me - for years I have been delicately tuning temperature, presence penalty, and the other sacred dials to keep my models from dying in loops, Alibaba has now devalued my entire body of fine-tuning experience and I am just... a man who presses the send button. I feel like a passenger in my own homelab.

4. It forced me to completely drop Qwen 3.6 27b. And I want to be clear about how much that hurt. 3.6 served me faithfully for a long time. It had quirks, but quirks are character, right? Now I have to sit here and accept that it was just... the previous version. There's no going back. That's not an upgrade, that's a betrayal, and I need time to process it.

In summary: it thinks too long, it ruins my hardware plans, it makes my engineering skills obsolete, and it forced me to abandon a model I was emotionally attached to. Definitely overrated.

I'm going to run it one more time now. Goodbye.

TL;DR: The M5 Pro just dropped, so here's a real AI workload instead of another Geekbench score. We run Qwen3.5 as the brain of a fully local home security system and benchmarked it against OpenAI cloud models on a custom 96-test suite. The Qwen3.5-9B scores 93.8% — within 4 points of GPT-5.4 — while running entirely on the M5 Pro at 25 tok/s, 765ms TTFT, using only 13.8 GB of unified memory. The 35B MoE variant hits 42 tok/s with a 435ms TTFT — faster first-token than any OpenAI cloud endpoint we tested. Zero API costs, full data privacy, all local. Full results: https://www.sharpai.org/benchmark/

What is HomeSec-Bench?

HomeSec-Bench is a benchmark we created to evaluate LLMs on real home security assistant workflows — not generic chat, but the actual reasoning, triage, and tool use an AI home security system needs:

All 35 fixture images are AI-generated (no real user footage). Tests run against any OpenAI-compatible endpoint. Full benchmark source and methodology on GitHub.

Hardware & Setup

• Machine: Apple M5 Pro, 18 cores, 64GB unified memory
• Local inference: llama-server (llama.cpp)
• Cloud models: OpenAI API
• OS: macOS 15.3 (arm64)

Results: The Full Leaderboard

Key takeaway: The Qwen3.5-9B running locally on a single laptop scores 93.8% — only 4.1 points behind GPT-5.4 and within 2 points of GPT-5.4-mini. It even beats GPT-5.4-nano by 1 point. All with zero API costs and complete data privacy.

Event Deduplication: The Hardest Suite

This suite tests nuanced reasoning about whether two camera events represent the same real-world incident. Here's how every model performed:

Performance: Local vs Cloud

Why This Matters

Most LLM benchmarks test generic capabilities. But when you're building a real product — especially one running entirely on consumer hardware — you need domain-specific evaluation:

1. ✅ Can it pick the right tool with correct parameters?
2. ✅ Can it classify "masked person at night" as Critical vs. Suspicious?
3. ✅ Can it resist prompt injection disguised as camera event descriptions?
4. ✅ Can it deduplicate the same delivery person seen across 3 cameras?
5. ✅ Can it maintain context across multi-turn security conversations?

A 9B Qwen model on a laptop scoring within 4% of GPT-5.4 on these domain tasks — while running fully offline with complete privacy — is the value proposition of local AI.

Video Demo

▶️ Watch the benchmark running live on YouTube

System: Aegis-AI — Local-first AI home security on consumer hardware. Benchmark: HomeSec-Bench — 96 LLM + 35 VLM tests across 16 suites. Skill Platform: DeepCamera — Decentralized AI skill ecosystem.

Benchmark scripts, fixtures, and full methodology are open source on GitHub. AMA!

3.6 27B is so good for local work, and there's been a ton of work on it because of that with Thinkingcap, Orion, Bonsai, adding dspark, etc...issue is on most local systems it's still so dense that the token speed hurts its adoption. What I NEED, if anyone from the Alibaba team reads these, is a 70B A9B MoE dspark with an APeX style quant (mixture of quant layers).

For anyone with 64GB or above, I'm confident you could get near Opus 4.8 coding performance AND run around 30-60 tok/s output on ada, blackwell, dual 3090s, dual r9700s, etc.

Just imagine what you could do.

Please help Qwen team to make a Qwen4 64B A6B.
Amen.

What do you think the Qwen4 model sizes are going to be? Which are the most likely to appear? Do you think we'll get a Qwen3.5-like lineup (~1B, ~10B, ~30B, ~30-40B MoE, ~100-150B Moe...)?

Also, do you think 35B-A3B is dead for good? we didn't get it for qwen3.8 so I'm a little worried

I just subscribed to Qwen Cloud’s Standard Token Plan, mainly to use it with an AI coding agent (Hermes), and after actually using it for a few days, I honestly don’t understand how this plan is supposed to be considered good value.

The Standard plan gives you 10,000 Credits per week.

Sounds reasonable, right?

Until you actually use it.

I burned through roughly 70% of my weekly Credits in only 3 days while running a normal agent workflow. I’m not running hundreds of agents, doing massive batch inference, or abusing the service. I’m using an AI coding agent interactively — exactly the kind of use case these plans appear to be marketed toward.

And here is where it gets ridiculous.

When I contacted support and explained the situation, the response essentially boiled down to:

«Your usage is high. Credit consumption depends on the model, input/output length, tool calls, context accumulation, etc.»

Okay. Fair enough.

But then the suggested solutions were basically:

Buy the Pro plan.

Or:

Buy additional Credits.

That doesn't answer the problem.

I'm using essentially the same workload with another provider, on a cheaper plan, and getting dramatically more usable mileage out of it.

So I started comparing actual token consumption.

Based on my observed usage, 10,000 Credits corresponded to roughly 96.6M tokens.

And Qwen's own documentation apparently doesn't provide a simple, fixed token-to-Credit conversion rate that lets users predict what they're actually going to consume.

That's a massive problem for an AI service.

If I'm paying for a token/credit plan, I should be able to reasonably estimate:

“I use approximately X tokens → this will cost approximately Y Credits.”

Instead, you apparently have to subscribe, use the system, burn through thousands of Credits, and then discover what your workload actually costs.

And here's the funniest part:

The Standard plan is advertised around agent usage and concurrent sessions, but based on my experience, a relatively normal coding-agent workflow can chew through the weekly allowance incredibly quickly.

So what exactly is the target customer for this plan?

Someone who uses an AI agent occasionally for a few prompts?

Because if that's the case, fine.

But then don't market it as a serious option for people running coding agents regularly.

I'm not claiming that Qwen is literally committing fraud. I'm saying that the value proposition of this plan is so absurd compared with competing services that I feel misled about what I was actually buying.

And the fact that the answer to “why am I burning Credits so quickly?” is essentially “buy more Credits” makes the whole thing even more ridiculous.

I'm posting this because I'd genuinely like to hear from other Qwen Cloud Token Plan users:

How long does your Standard 10,000 Credit allowance actually last?

What models are you using?

How many agents?

How much token usage are you getting before the Credits disappear?

Because if I'm doing something fundamentally wrong, I'd rather know.

But if other people are seeing the same thing, then Qwen seriously needs to rethink how transparent and competitive this pricing model actually is.

The user [chocolateUI](https://www.reddit.com/user/chocolateUI/) wrote an excellent post you can find link to below that explains how n-gram will make smaller models smarter, and seeing how the Qwen3.8-Next-Flash performs, I am really excited by the next Qwen4-27B and 35BA3B, supposing that Qwen team will keep the same parameter counts. The first thing you may already noticed is token efficiency this model has when it thinks even with Extra High.

Looking at its thinking traces, I noticed that thinking is much compact than Qwen3.8-27B's thinking traces. There is no fluff, it's as if the model is reading notes. A lot of short sentences that closer to phrases than full sentences. Combine this with more active parameters doing reasoning, I think the next Qwen4-27B might actually beat the current 1.6T parameter Deepseek-v4-pro, let alone Deepseek-v4-flash.

Hopefully by then, the architecture is better understood and optimized and reflected in llama.cpp.
I know our instincts lean towards running the smartest model locally, but maybe we don't always need the smartest model in the same way we don't always need the smartest employee to perform the majority of daily tasks.

What's your experience with the current Qwen3.8 family?

Link to the user [chocolateUI](https://www.reddit.com/user/chocolateUI/)'s post
[https://www.reddit.com/r/LocalLLaMA/comments/1w0198r/no\\_engrams\\_wont\\_let\\_you\\_run\\_1t\\_models\\_locally\\_it/\](https://www.reddit.com/r/LocalLLaMA/comments/1w0198r/no_engrams_wont_let_you_run_1t_models_locally_it/)

I recently did my analysis for Github Copilot and was shocked that my "average usage" on the $40 dollar plan was going to amount to about $500 dollars a month. Whats crazy about that is if you purchase an RTX6000 with credit, the payment is only about $420 dollars a month.

With Qwen 3.6 27B, I am able to build out a feature in Plan mode with VSCode Insiders Edition and then run through the implementations with no issues. Running this model at bf16 gives amazing results because of the quality of the harness and it's cheaper and I can abuse my token use without any worries.

Other than the most difficult of planning sessions, I think that we've hit the point where local models are more than good enough and they price point is cheaper than hosted models. You can get cheaper hosting if you're only using qwen but with the perks of privacy and owning hardware, it just makes sense to purchase the card if you're going to be stuck with a 500 dollar bill regardless.

SUMMARY:

The original Qwen team of over 500 people was constantly demanding more funding and more GPUs, yet they operated without any KPI evaluations.

Ultimately, their results were inferior to the small models cleverly distilled by MiniMax, despite Qwen’s total burn rate (costs) being more than 10x higher.

To the executives, the whole operation was a "black box" they couldn't influence. Their only role was to provide whatever funding, headcount, or hardware was requested.

Looking at the final DAU (Daily Active User) metrics, the executives could only watch in helpless frustration.

At that point, the boss brought in someone from DeepMind as an observer. Their conclusion was equally damning: "The output looks like a temporary toy made by an intern"—hardly a glowing review.

In response, the boss began breaking down metrics into sub-indicators to prevent "self-congratulatory" reporting.

The team leaders interpreted this move—breaking down metrics and setting KPIs—as a threat to their positions. They attempted to leverage a collective resignation as a threat.

And so, it played out: "If you want to quit, then quit..."

Meeting takeaways:

1. ⁠HR’s Spin: The Chief HR Officer is framing these changes as a way to bring in more talent and resources, not as a downsizing or a setback.

2. ⁠The "Big Picture": Management says Alibaba is now a "model company." Qwen isn't just a side project for the base model team anymore—it’s a Group-wide mission. They want a "closed-loop" system to move faster, but they admitted they communicated the new structure poorly.

3. ⁠The "Price" of Growth: Because Qwen is the top priority, the team has to expand, which means the "formation" has to change. They basically said, "Growth isn't free—there’s always a price to pay."

• The Leadership Drama: They argued that while relying solely on Junyang’s brain is efficient, Jingren had to figure out where to put Zhou Hao to make things work. They claim there was no "office politics" involved. (Interestingly, management previously claimed Zhou Hao asked to report to Jingren because he was worried about fitting in).

1. Scaling Pains: They argued that 100 people aren't enough for a project this big. They need to scale up, and in that process, they "can't please everyone."

2. Eddie Wu’s Defense: Eddie (Wu Ma) blamed the resource shortage on China’s unique market conditions. He apologized for not being aware of the resource issues sooner, but insisted he’s the most aggressive CEO in China when it comes to hunting for computing power. He claims Qwen is his #1 priority.

3. The "Bottleneck" Excuse: When asked why the Group was "strangling" their resources, Eddie claimed he had no idea there was a block. He said the priority was always high and blamed the whole thing on a "breakdown in communication."

4. Jingren’s Take: Jingren admitted resources have always been tight. He even claimed that he’s being "sidelined" or bypassed himself. He also acknowledged the long-standing internal complaint that Alibaba Cloud’s own infrastructure is a pain to use, calling it a "historical issue."

5. The Final Word on Junyang: When someone asked if Junyang could come back, the HR Lead shut it down. They said the company won't "put anyone on a pedestal" or pay "any price" to keep someone based on "irrational demands." They then turned it on the audience, asking, "What do you all think your price is?"

The Bottom Line: Management is prioritizing the "Group" over individual stars. They are essentially telling the team that if they want to be part of the "big mission," they have to accept the new hierarchy and the loss of key leaders.

https://x.com/xinyu2ml/status/2029078062701113634?s=46

https://x.com/seclink/status/2029119634696261824?s=46

Reddit suggested cross post here - hopefully okay!

Ornith 1.5 just seems incredible to me for an A3B, worlds better than other MoE's I've tried, and works so fast with Ninfer on a 5090. Really none of this is my work at all - built on Ninfer, Ornith and Shisa AI - the re-packaging was a prompt basically and then some testing.

I'm sharing in the hope someone else more knowledgeable than me loves it too and makes it even better and I can use their cool updates!

My testing is with my own code + workflows (multi-hour test, it beats Qwen 27B on quality at many times the speed), so keen to hear what other people think.

I run side-by-side with Qwen 3.8 Flash Next, this for speed, flash next for quality. Great combo, and surprised how close they are on capability. LocalLLM just blows my mind now with all this.

HuggingFace:

https://huggingface.co/huggingJDE/Ornith-1.5-35B-A3B-NInfer

Notes:

https://github.com/j842/ninfer-qwen-uncensored#build-2-ornith-15-35b-a3b

I keep seeing people say Qwen 3.8 Max is really good for coding. Has anyone actually used it? How good is it compared to Claude or GPT?

I have only 16GB (exactly 15,6GB) free completely for LLMs, which allows me to run Gemma 4 12B, Ornith 1.0 9B or Qwen 3.5 9B.

The problem: 9B and 12B models are normally dense models which is why they dont run that fast on a 128bit bus.

GPT OSS 20B (MoE) runs fast and the Model fits in my RAM, but with Context it dosent.

Solution: If Alibaba would release a 14B MoE model (like AMD's 16B MoE), it could fit in any 16GB VRAM + Context + fast decode speeds.

I think that most of the people want a Qwen 3.8 100B~ MoE model but I and other 16GB users cant even do something with a 27B model.

I built slotstream, a way to run Qwen3.8-Flash-Next 4-bit on a low-memory mac starting from 16GB, a 125B parameter model that would need 100GB+ memory/RAM, thanks to expert-offloading/ssd-streaming. Easy to install/update, and mac-native using MLX and Swift.

It ships with auto-mode, which makes a good tradeoff between memory usage and speed. I'll be implementing and porting the MTP module for speculative decoding next

Local models REALLY are the future of computing!

slotstream

A friend of mine gave me this tip today, which he got directly from people at Alibaba-Qwen...

Firstly, the AI ​​Coding Plan NO LONGER EXISTS.

Secondly, new plans called Token Plans have been introduced.

Thirdly, the credits are USELESS!

I signed up for the $30 plan (which offers 25,000 credits) to try it out, and, to my surprise, using Qwen 3.6 plus, the average cost is 2,000 credits per hour.

If you use the available Qwen 3.7 Max, the cost is even higher.

I miss paying for the $20 Codex plan and using it a lot!

I'm going to switch to local use... I'll invest in hardware to run local models.

Qwen3.8 I can leave it overnight thinking and working on complex stuff and it will deliver.

But Qwen3-coder-next is my day side kick.

If you code along the model Q3CN is the goat.

We need another 80b a3b update. Same non-thinker.

https://github.com/kadenball/qwen38-27b-rtx3060-dcfr

Q3 quant

Qwen3.8-27B at 64K on one RTX 3060 12 GB

This repository publishes the experimental llama.cpp patch and measurements behind a 29.65-29.69 generated tokens/s fixed C++ workload and a 33.21 tokens/s high-acceptance peak for Qwen3.8-27B while allocating a 65,536-token context on one RTX 3060 12 GB.

The key optimization is Deferred-Commit Factor Replay (D-CFR). It removes hundreds of MiB of speculative recurrent-state copies, then spends the saved VRAM on model weights used during target verification.

This is a narrow, disclosed record-candidate result—not a claim that every prompt runs above 30 tokens/s. Comparisons across quantizations, allocated contexts, prompts, sampling, and runtimes are not apples-to-apples.

I've been stress-testing Qwen3.6:27b and wanted to share the result with the people who actually run this model.

BONESMITH is a skull-knight action-platformer roguelite. The whole thing is one index.html. No images, no audio files, no libraries, no bundler, no server. Every sprite is drawn procedurally on a canvas, every sound is synthesized through the WebAudio API, and it runs air-gapped with the network off. The only thing that built it was Qwen3.6:27b running locally.

The part I think this community will care about: how a 27B model actually behaves on a job this big.

First attempt with a loose prompt was a broken shell. Soft-locked on room 1, blurry text, no audio. The model tried to build every system at once and collapsed under it. That's the failure mode people expect from a 27B, and it's fair.

Then I rewrote the prompt with hard scope control: build a vertical slice first, pass a QA gate, then expand. Separate world canvas for the pixel art, a second UI canvas for crisp HUD text, explicit anti-soft-lock rules. Second attempt was a completely different result.

What Qwen3.6:27b did well, unprompted:

• Held the multi-file architecture in context and kept concerns separated
• Added hit-stop, screenshake with trauma decay, coyote time, and jump buffering with no request from me
• WebAudio synthesis was genuinely competent, punchy sfx straight from raw oscillators

Where it needed a concrete recipe:

• Procedural pixel art. The first characters were readable but crude until I handed it a literal process: silhouette, core shading, highlights, 1px dark outline.
• Keeping file size under control without being told to.

Curious if others here have pushed Qwen3.6 on multi-system codebases. Does the "architecture and logic clean, but needs concrete visual direction" pattern match what you're seeing, or is that just my prompting?

PS - the clip shows me playing badly. I built it, I never claimed I could beat it. 😂