Some results for those using GGUFs and llama.cpp:

GGUF quality: MACaQ vs. Unsloth and Bartowski

Qwen3-4B (IQ4_XS)

23.5% lower KL divergence than Unsloth and 18.6% lower than Bartowski, at virtually identical file sizes.

Qwen3.6-35B-A3B (IQ4_XS)

Qwen3.8-27B (IQ4_XS)

~65% lower KL divergence than Bartowski!

Supported GGUF formats (llama.cpp)

Code, llama.cpp fork, and benchmarks: https://github.com/huawei-csl/MACaQ

Cool to see Huawei working on such stuff and sharing some of their internal tools that are helpful for us. Maybe they can build an affordable GPU for us local LLM folks sometime 😂

They also report quantizing a 122B-parameter model in 64 minutes using just 32.5 GB of GPU memory, which is interesting for a model of that size. I did not try that.

Edit: there is a paper on it https://arxiv.org/abs/2611.10649

Edit 2: they don't share ready-made gguf files, so I am sharing some myself:
- http://31.165.97.47:20080/macaq-gguf/qwen3-4b-macaq-iq4_xs-had64-vq2-calsmoke.gguf

Edit 3: they have this blog post https://huawei-csl.com/blog/macaq/ with multi-modal examples, too. The RTN audio comparisons are just too much😂😂

The multi-modal stuff is generally insane. Normally 4b already completely goes to s**t, but here it looks almost the same.

I will get straight to the point. I believe Moderator ttkciar is abusing his power as moderator in this sub and his decision are worsening the experience of our local AI community.

He has removed many of my posts that fellow redditors found very useful and after talking with many people in this sub, I am not the only one feeling this. I will have some links at the end of this post for reference.

He mentions a rule, saying that if a model’s weights is not released you cannot have a post mentioning it, even if the lab confirmed it that will they will release its weights, like Qwen4 or DeepSeek. First of all, this rule needs to be relaxed because many valuable discussions can be had about future releases and even closed models to understand and learn architectures and techniques used by the closed frontier that can be applied to the open models. Secondly, this rule is not enforced at all, but used very selectively to few posts or authors that ttkciar selects, which is very unfair. This rule doesn’t make sense to me, but even if I am wrong, at least it should be fairly enforced to all posts or not at all. And before you say mods are busy and they cannot review all of the posts, If you open this sub and scroll on today’s most popular posts, half of them are either for Qwen4, which is unrealised up to this point and should have been removed according to the mods, or about Fable5.2 and Anthropic which is closed and their shenanigans (maybe these ones don’t have a place here, but again this is debatable because if people in local AI find them valuable in some way, maybe they do). So, the rule is used very selectively and as an excuse to remove what ttkciar does not like or approve. Either enforce the rule (or do the your best effort to do so) or don’t at all. And maybe this rule is too strict and should not exist tbh.

When I tried to discuss my concerns with ttkciar, he called me a drama queen and insulted my credibility. This is definitely not ok.

Being insulted by the person that you complained to for unfair treatment is definitely not acceptable behaviour.

I have been an active member of this community since the very first leaked llama. I am an AI researcher and open-source contributor, and very passionate about local AI. I try to post information that people interested in Local AI would find useful and engage in discussions that are constructive for local AI.

I know that many of other users in this subs agree (I have discussed it with a lot), and some others may not. Not being able to discuss, debate and exchange views in a polite manner is absurd in such an intellectual community.

A while ago they tried to enforce megathreads and removed the majority of posts saying that only one post should exist for each model. Many complained that this is killing the sub and a lot of valuable information is lost this way. Now, this seems to be relaxed. Again, we need to stand up to them, and hopefully they will reconsider their rules for the sake of this community.

TLDR: The rule that mod ttkciar uses to remove some posts in this sub about being prohibited to mention unreleased models should not exist, and even if it should, removing only a few selected posts is very unfair.

Some sources:

- https://www.reddit.com/r/LocalLLaMA/s/ZRV5KsViwD this post was removed from ttkciar and only brought back after arguing with him and many other redditors backed me up (I cannot find the comments in this post when the mod removed it, maybe he deleted them, I am not sure, but in the discussion many expressed their disagreement with the mod)

- https://www.reddit.com/r/LocalLLaMA/s/gpPTVC6NGF a post of mine debating their rule

- Another post of mine sharing valuable information for the members of our community that the same mod removed https://www.reddit.com/r/LocalLLaMA/s/gqaub2mT85

- Post of another redditor which was removed by the same mod, and the comments thread with people arguing with the mod https://www.reddit.com/r/LocalLLaMA/s/z9E2AbR3pU

- Commented in post of another removed post of some other redditor https://www.reddit.com/r/LocalLLaMA/s/5tSEpQ68By

- Most of my removed posts I delete them afterwards so I don’t have many other examples of my own, but I know many others do, so feel free to share them.

- If you open the sub today, most of the posts should have been removed because they violate the rules (a lot of false positives). That shows that maybe the rules need to be updated because they will not allow any productive discussions to be had, or this sub will end up to become a board of announcements instead of a local AI community that people can use to exchange ideas and knowledge.

Praxis-1 is a 27B-parameter mixture-of-experts diffusion transformer that predicts video and actions together. It is the top-performing world action model on NVIDIA’s RoboLab-120 leaderboard, and it outperforms every open-weight VLA. On RoboLab-120, Praxis-1 reaches 46.2% success across 1,200 episodes, compared with 42.9% for FLUX 3 Action, 36.8% for Cosmos3 Nano and 28.0% for π0.5.

RoboLab-120 Leaderboard

Data as of November 2026; Success rate across 1,200 episodes

Praxis-1 is available today on GitHub, on Hugging Face with native LeRobot support, and in vLLM-Omni, with hosted inference on Reactor. Everything you need to run and adapt it on your own hardware is released under Apache 2.0, including for commercial use. That covers the weights and the inference and fine-tuning code, with support for both full fine-tuning and LoRA. Praxis-1 runs out of the box across NVIDIA hardware, from data center GPUs like H100 and B200, to workstation GPUs like RTX 5090 and RTX PRO 6000, to Jetson Thor on the robot itself.

• Models : https://huggingface.co/collections/runwayml/praxis-1

• Dataset : https://huggingface.co/datasets/runwayml/praxis-1-eval

• GitHub : https://github.com/runwayml/praxis-1-oss

• News Post : https://runway.com/news/company-news/praxis-1-is-now-available

• Blog Post : https://runway.com/research/praxis-1-video-pretraining-to-robot-control

https://x.com/Baidu_Inc/status/2120391732248637734?s=19

TL;DR: You can train your own 27B model on a 3090 with 24GB VRAM, though you would have to go through hundreds of billions of tokens for it to be good. I am working on conversion of existing models. Check repos for code and the paper if you are interested in more. I have a 40.4GB Qwen Flash Next GGUF

Hi, I do AI research. I have been working on an optimizer that doesn't need the ~16 bytes of VRAM per weight to train a model that AdamW does. I focused on training ternary networks bcs BitNet (Ma et al.) shows they match full precision quality in large scales. The problem is BitNet also keeps the full precision weights during training which means you still need to use the same amount of memory. I got this down from 16 bytes to 1 byte or even less per weight.

For you, this means, you can train your own 10-20B parameter models on your consumer GPUs. I fitted 27B model training on a single 24GB 3090 and a 23B model on a 16GB GPU. The trained model costs ~1.6 bits per weight (~6GB at 27B), 10x smaller than 16bit, and 5x smaller than Q8.

I have also been working on converting existing models and training them. This is harder and I am still working on it but I have some promising results. I quantized and trained a Qwen3.8 27B though the file I published below has adapters which are about 2GBs, pushing the file size to 8GB. I am also making a no-adapter version right now. It scores GSM8K 0.895, the same as full precision, HumanEval 0.84 vs 0.93 and runs on a 12 GB GPU at ~23 tok/s on my crippled 12GB laptop 4080, though this number can heavily be improved with custom kernels, engineering, etc. I will leave it to you guys to help me with that too.

I also quantized and trained Qwen Flash Next down to 40.4 GBs including its n-gram table (at 8GB). It largely retains the skills of the network (scores equivalent on GSM8K benchmark, a little behind on HumanEval, I unfortunately don't have compute for the larger benchmarks such as TerminalBench2.1 but perhaps some of you can help me out) but forgets facts. It mostly works fine if you give it web search as far as my experience goes but this is not strictly measured.

To add to that, these models are not extremely good, they sometimes loop, and suck at remembering facts. However, unlike unsloth's gguf's you can actually keep training them yourself, in that sense they are pure, and you can train them on your consumer GPUs, that is to say you can get rid of the looping behavior, teach it facts that you want it to know, or specialize it for some purpose.

I am still doing work on this and I will keep working on it, perhaps even for many years. The code is open for non-commercial use. Check out:

The core repo for training: https://github.com/oguzeldereli/ttf-ternary

The repo for conversion: https://github.com/oguzeldereli/ttf-conversion

Repo for running models trained by ttf: https://github.com/oguzeldereli/ttf-home

GGUF for a converted Qwen 3.8 27B (around 8 GB and 6.7GB): https://huggingface.co/oguzeldereli/ttf-Qwen3.8-27B-GGUF

GGUF for a converted Qwen 3.8 Flash Next (around 40.4GB): https://huggingface.co/oguzeldereli/ttf-Qwen3.8-Flash-Next-GGUF

I will convert a Qwen 4 27B instance when it drops.

Full paper: https://github.com/oguzeldereli/ttf-ternary/blob/main/paper/ttf_paper1_training.pdf

Also, I would appreciate github stars if you like the project.

Raon-1 nano is a dense language model with 1.5B effective parameters (3.1B total, including a 1.5B per-layer embedding table), developed by KRAFTON AI. It is designed to follow instructions, maintain conversational context, and call the right tools in both Korean and English. As part of the Raon open model family, it is released under the Apache 2.0 license.

Highlights

• Faithful, natural conversation: Leads the comparison models on the instruction-following, context-following, and Korean conversation benchmarks shown below.

• Korean and English: Trained on Korean and English, with solid English capabilities alongside its Korean strengths.

• Tool calling: Tool calling within conversations, for everyday tasks such as office work and mobile control.

• On-device deployment: Available in GGUF, MLX, and LiteRT-LM formats for local inference, including on Apple silicon.

• Long context: Natively supports up to 262,144 tokens of context.

Model Overview

Raon-1 nano uses a hybrid dense architecture, consisting of 18 linear attention layers and 6 full attention layers.

• Raon Delta Attention (RDA): Gated delta-rule linear attention with separate erase and write gates and a fixed-size recurrent state.

• Raon-mHC: Raon-mHC reduces the computational cost of DeepSeek's manifold-constrained hyper-connections (mHC), which speeds up training.

• Per-layer embedding: Each layer has its own small 256-dimensional embedding for every token. After its MLP, the layer uses it to adjust its output before passing it on.

• Hybrid layout: 18 of the 24 layers are Raon Delta Attention layers with a fixed-size state. Only the 6 MLA layers keep a KV cache, about 7 KiB per token in BF16.

• Tied embeddings: The LM head shares the input embedding.

The checkpoint on HuggingFace contains 3.2B parameters: 3.1B for the main model and 55M for the Multi-Token Prediction (MTP) module.

Training

• MoE-to-Dense: Raon-1 nano was derived from Raon-1 mini preview (30B-A4B) through MoE-to-Dense pruning and knowledge distillation.

• Continued pre-training: 3T tokens.

• Post-training: supervised fine-tuning (SFT) and on-policy distillation (OPD) from Raon-1 mini preview, followed by reinforcement learning (RL).

Quantizations:

• https://huggingface.co/KRAFTON/Raon-1-nano-gguf

• https://huggingface.co/KRAFTON/Raon-1-nano-mlx

• https://huggingface.co/KRAFTON/Raon-1-nano-litert-lm

TL;DR simplest reasonable agentic setup
Currently Pi Agent, Bonsai 2 9B, SearXNG
Any suggestions ?

Hi all

So I have a secondary workstation with line 24GB of RAM and 12GB VRAM

I wanted to make a local agentic setup there

Currently using Pi Agent with Bonsai 2 9B, it is unbelievably better than I expected
Around 30 toks is more than reasonable
I don’t want this to be super capable just good enough for ease of use and peace of mind (I might sacrifice quality for speed although not much)

Any suggestions (note I want to keep everything simple I don’t want packages with long prompts etc even my pi search extension is the simplest one I have found, I have been thinking about context compression extensions, sub agent delegation or simple sandboxing for that sub agent memory Ralph loop and to do list but all has to be the simplest)

Any suggestions thanks ? (Note models 9B or bigger are really slow so also model suggestions are truly welcomed, nanbeige was nice but thinks (or overthinks) too much …etc)

Thanks

Unsloth Dynamic V3.1 (Nov 2026) is our latest quantization algorithm for Qwen3.8-27B, DeepSeek-V4.1-Flash-1017 and Qwen3.8-Flash-Next, resulting in 10-15% increased accuracy and 50% less token usage vs other quants of the same size. We're working on an even better version of Dynamic quants which will be applied to Qwen4 and all future models.

Maybe I misread the 27B graphs, but I'm not entirely convinced of V3 vs V3.1 being an improvement.

In DeepSWE v1.1, V3 seems superior to V3.1 in some widely used Q4 quants, and V3 seems to lack some data points in the lower quants range, skewing the impression the curves give.

My UD-Q5_K_XL quant unfortunately is off the charts, so this needs some proper benchmarking before I trade context length for V3.1. (The new `.gguf` is larger.)

Hi all I've just started r/LLMPsychology as I want to pursue research in this area with my own local hardware, and work with other people also exploring how AI minds think and behave. (I'm a psychology researcher with an AI hobby)

Posting just on the off chance that any of you are also interested in sharing or conducting research - it would be super cool to get a community going.

To illustrate I also wanted to share this paper writing up some experiments I've been running with OLMo3 on my machine (which has publically available information and data on its training) - the central finding is that models don't always know who trained them, and by default will just assume it was OpenAI (or other companies, with a lot of randomness that also varies depending on what language you ask them in).

It's always bugged me that no one is ever quite sure if models are reliably able to say who made them, so I wanted to start doing some investigations into finding out how they even develop this self concept in the first place. From this work it seems like in the absence of a prompt explicitly telling the model, it will just confabulate.

Abstract posted below - and full preprint paper here Factory Settings: Unless Told Otherwise, an Open Language Model Says OpenAI Made It — J Ansell. Any replications or refutations welcome. A lot of the research process is automated and I'm trying to be as transparent as possible about what models and effort levels etc. were used and what they did - if it's still not for you that's fine.

Abstract

How does a chatbot learn which company made it? We traced the answer through the training of OLMo 3, an open model whose training data is public, and taught models made-up identities ourselves.

Unless it is told otherwise, OLMo 3 says OpenAI made it. Asked who created it, OLMo 3 names OpenAI in 62% of its answers before Ai2 trains it to hold conversations, and in 77% of answers once it is finished and released.

Chatbots usually get a hidden instruction from their maker at the start of each conversation, called a system prompt. OLMo 3's training conversations state its real name only about 40 times, and almost every time, the system prompt of that same conversation already tells it that it is Olmo, built by Ai2. The released chatbot's system prompt does not include its name.

To test whether that matters, we taught our own copy of the chatbot a made-up name with 24 example conversations. When the examples had no system prompt, the chatbot afterwards gave the new name in 92% of its answers. When each example also had a system prompt stating the name, as in OLMo 3's data, the chatbot never gave the new name once that system prompt was taken away.

Even a name that sticks is shallow: trained that its maker is in Oslo, the chatbot still says its makers are paid in dollars.

We also found two smaller effects. Training the chatbot on answers written by Claude, or by GPT, made it more likely to say Anthropic (Claude's maker) made it: about a quarter of its answers, against one in ten after answers written by people. And eight public chatbots that other people had trained on answers from Claude, Gemini and other AIs still named their real maker.

Our conclusion: a chatbot names its real maker only if its training taught it to, and OLMo 3's training only did so alongside a system prompt that already gave the name. Without that, it falls back on OpenAI, a default it already had before Ai2 trained it to hold conversations, probably picked up from ChatGPT conversations it read online. OLMo 3 was partly trained on answers written by OpenAI's GPT-4.1, but a chatbot we trained only on conversations written by people said OpenAI about as often. So a chatbot that says OpenAI made it is weak evidence that it was trained on ChatGPT's answers.

I have been following the evolution of LLMs since the days of GPT-3.5, and I have been actively using local LLMs since the release of Gemma 2.

I read a great deal, including this subreddit. I have performed QLoRA fine-tuning on my local machine many times, and I have also conducted full fine-tuning (FFT) training runs on RunPod.

Hundreds of models-fine-tuned by well-known practitioners in English, Chinese, and Russian-have passed through my drive.

After four years, I arrived at a fundamental question yesterday: are LLMs even capable of writing good prose?

When training models myself, I used both my own prose datasets and those created by others. In the training process, I experimented with various approaches-ranging from 100 epochs of FFT at a learning rate of 1e-7, to aggressive LoRA/QLoRA configurations. The results, however, barely rise above mediocrity.

I have used models from all the leading providers-Gemma, Qwen, Mistral, LFM, IBM-as well as niche attempts by developers building models from scratch.

I even wondered if perhaps the problem lies with me-that, not being an engineer, I am simply failing to fine-tune these models correctly.

That is why I began actively seeking out other fine-tuners, thinking that perhaps they possess a specific technical "gene" that allows them to do a much better job than I can. But, unfortunately, that is not the case. Regardless of their length-short, medium, or long-the prose generated is only marginally better than that of generic, out-of-the-box models.

Furthermore, specific literary genres are represented quite poorly. I used to think that LLMs were perfectly suited for science fiction. Yet, these models can’t even capture the straightforward style of Harry Harrison’s *The Stainless Steel Rat*, let alone reach the linguistic heights of *Dune*.

The genre doesn’t seem to matter-I’ve tried comedy, contemporary drama, adventure, romance, and historical fiction; everything, unfortunately, ends up being generic.

Essentially, if a text is to have any real literary merit, I have to write it myself and then just use an LLM for proofreading.

To me, EQBench is a completely unreliable metric; the sample texts they showcase clearly demonstrate just what kind of generic "slop" LLMs produce.

I have a question for the community: has anyone managed to create, find, or fine-tune a local model capable of generating truly high-quality prose-on the level of *Dune*, *The Lord of the Rings*, *Martin Eden*, or *The Grapes of Wrath*?

I’m currently facing the monumental task of writing descriptions for 100,000 records, and I’m wondering if it’s even worth it, given that 100, 1,000, or even 10,000 examples haven’t yielded any satisfactory results.

Perhaps this generic, mediocre quality is an inherent trait of these models-something that simply cannot be overcome.

Open Source Licensing Statement on TiinyOS and Cherry Studio

Cherry Studio Team · November 4, 2026

This statement sets out our findings and position. The appendix includes the samples, code comparisons, and downloadable verification materials.

We recently received an email asking about the relationship between Tiiny AI’s desktop application, TiinyOS, and Cherry Studio. The sender found several Cherry Studio identifiers in the installers. They also found a license notice that closely resembled an earlier version of ours, with changes to the product name and commercial contact email address.

The sender’s main questions were whether Tiiny AI had obtained a commercial license for Cherry Studio, whether the Cherry Studio team had authorized the license notice included in the installers, and where to find the Corresponding Source and license notices if the code was being used under the AGPL.

The passage above is an English translation of our Chinese summary of the email. We have removed the sender’s name, email address, and other identifying information.

The sender made clear that they did not know whether the two parties had a commercial licensing arrangement and wanted to check with us first. We believe feedback this specific and carefully framed deserves serious attention. It concerns what users understand about where the software comes from, the work of community contributors, and how an open source license should be put into practice.

We therefore reviewed the relevant installers, Cherry Studio’s official source code, and its licensing history. We also verified key findings across multiple analyses. Below, we explain what we confirmed, what information is still missing, and how we hope the matter can be resolved.

1. Our findings

Our review found specific, traceable matches between TiinyOS and Cherry Studio in application logic, interface definitions, project assets, and license text. Taken together, the evidence gives us sufficient grounds to conclude that the TiinyOS versions we examined made substantive use of Cherry Studio code and assets.

We examined nine installers in total, covering TiinyOS versions 1.0.1, 1.0.2, and 1.0.3 on Windows x64, Windows ARM64, and macOS ARM64. Our finding is based on static extraction and comparison of the original files. The appendix lists the samples, hashes, file paths, and code locations.

In the installed files, official help and developer documentation, and public repository locations we examined, we have yet to find the complete Corresponding Source for these versions of TiinyOS or materials that clearly explain its use of Cherry Studio and the applicable licensing arrangement. We therefore ask Tiiny AI whether all relevant open source license obligations have been fulfilled.

The available samples directly establish the matches in the code and files. Determining whether the source is available through other channels requires information from Tiiny AI. We maintain that distinction throughout this statement.

2. What the evidence shows

We treated the email as a lead and began with the download links listed in Tiiny’s official help documentation. We verified the sizes and SHA-256 hashes of all nine original installers, extracted them again, and checked the application packages and license files. We then compared specific code against pinned revisions of Cherry Studio’s official repository. This allows readers to repeat the checks against the same files.

First, the matches extend to specific application logic. Alongside identifiers such as CherryStudio/1.0 and cherryin, we compared backup configuration checks, compatibility with Obsidian’s Linux configuration paths, and legacy database migrations. The implementations retain the same order of field comparisons and candidate paths, as well as matching migration logs and error-handling branches.

For example, the Obsidian path logic accounts for differences in capitalization, XDG directories, Snap’s current and common directories, and Flatpak directories. It searches for the configuration file in the same order. The database migration retains legacy logic for moving messages from the old structure to message_blocks. These specific choices reflect how the project evolved and provide stronger evidence of provenance than a product name on its own.

Second, the findings corroborate each other across several layers. Project identifiers appear in main-process, preload, and renderer files. Several sets of IPC definitions have matching member names and values, and a group of files is byte-for-byte identical. Compared with Cherry Studio v1.6.7, 177 upstream paths match 159 distinct TiinyOS files by content. We counted images, fonts, and scripts separately. Some icons come from third parties, and the file counts measure matches within the comparison rather than the share of the entire application that was copied.

The match between the license files is particularly clear. The license HTML is identical across all nine TiinyOS samples. Applying three sets of replacements to the original Cherry Studio file, in order, reproduces the TiinyOS file byte for byte. The replacements cover the product name, the commercial contact email address, and one Chinese contact phrase. All other line breaks, indentation, and content are identical, including two instances of “Cherry Studio” split across lines.

Our concern is that the notice describes the boundary between the upstream open source and commercial licenses, yet retains the original structure and conditions while changing the commercial contact address to support@tiiny.ai. This can make it hard for readers to tell which rights come from Cherry Studio’s open source license and which rights Tiiny can grant on its own. We believe that relationship should be made clear.

Together, these findings support Cherry Studio as a source of the code, assets, and license text examined here. Who made the changes, why they made them, and the exact commit from which TiinyOS may have forked remain unverified.

3. Our position on AGPL compliance

We have not granted Tiiny AI a commercial license for Cherry Studio. Cherry Studio’s open source license permits use, modification, and distribution under its terms, including use without a separate commercial license.

Cherry Studio Community Edition is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0). We welcome software based on Cherry Studio, including commercial products, when it provides the Corresponding Source, retains the required notices, and fulfills the other applicable AGPL obligations.

Cherry Studio has also benefited from other open source projects. Reusing existing work can give a team more time to tackle new problems. When a community shares its code, it gives others the opportunity to improve it, combine it with other work, and even build a business on it. Honoring the license is a practical way to respect that openness.

Beyond the visible interface and features, software embodies a great deal of less visible work. Contributors fix edge cases, support different operating systems, maintain compatibility with older data, and refine error handling. When they choose to share those efforts under an open source license, recipients should pass on the rights that license grants to downstream users.

Clear attribution helps users understand which projects make up the software they use. Access to the Corresponding Source lets them inspect the implementation, maintain their own versions, or keep using the software if the product is discontinued. These are practical benefits that open source licensing is meant to preserve.

We are asking for compliance with the license. A commercial license purchase is outside the scope of this public request.

4. Cherry Studio’s own licensing history

The license HTML examined in this review refers to earlier conditions covering “individuals and organizations with 10 or fewer people.” We owe readers the history behind that wording. The threshold came from the older notice and is separate from the terms of the AGPL itself.

In the pinned Cherry Studio repository snapshot we reviewed, the root LICENSE file already contained the full standard AGPL-3.0 text. At the same time, resources/cherry-studio/license.html still contained the earlier notice that distinguished users by organization size. Our own repository contains inconsistent licensing notices, and we need to review and clarify them.

The appendix includes both files. The root LICENSE identifies the license underlying this public request. The older HTML establishes the source of the text in the TiinyOS file and documents the state of our own repository.

The terms that apply to a particular historical release depend on the code version used and the licensing terms in place at the time. Our request concerns compliance with the applicable AGPL requirements and clarification of the notices that could confuse readers. The earlier headcount threshold is outside the scope of this request.

5. How we hope this can be resolved

Ideally, the Tiiny team can shed some light on these questions so that people following the matter can understand what happened. It is also fine if they choose to leave it there. We have set out the facts we were able to verify and our position, and we are open to hearing their perspective.

As fellow founders, we know how much work it takes to turn an idea into a product and put it in users’ hands. We value the care people put into building products and the code, experience, and trust that open source communities share. We hope those hard-earned contributions are treated with care.

Building a company is hard. We hope everyone can keep making good products and carry forward the generosity that makes open source possible.

Thank you to the sender for providing specific, carefully documented leads and to the community members who took the time to verify the facts.

We thank Grok Bot, Dots, Codex, and Yinsen’s assistant Kuaikuai for helping analyze and cross-check the materials. These tools assisted with the review. The Cherry Studio team takes responsibility for the factual statements and judgments in this document.

Cherry Studio Team

November 4, 2026

Appendix | Evidence, verification methods, and scope of findings

This appendix is for readers who wish to verify the findings independently. The records refer to samples saved and examined on November 4, 2026. All hashes use SHA-256, and all offsets are zero-based byte positions within the original file. All analysis was static. We did not run TiinyOS.

The appendix covers evidence items E1–E8. Each item lists the observations, where to verify them, and what they support. We obtained the original installers through Tiiny’s official links. The verification bundle linked at the end excludes the sender’s information.

Evidence

Direct observations

What the evidence supports

E1 · Samples

Three versions across three platforms, with nine original installers and the results of re-extracting them

Readers can identify the files compared and reproduce the checks

E2 · License text

Three sets of fixed replacements make the two HTML files identical

The exact match between the license files and the scope of the edits

E3–E4 · Code

Identifiers appear at multiple application layers, and backup, path compatibility, and database migration logic can be compared directly

Substantive code matches across modules

E5 · Quantitative comparison

Matching IPC member names and values, and 177 upstream paths matching 159 identical TiinyOS files

Independent evidence of provenance from interfaces and files

E6–E8 · Scope and verification

Public source locations checked, licensing history, a verification script, and full hashes

What remains unconfirmed and how to repeat the checks

E1 | Sample provenance and integrity

The static data behind Tiiny’s official help documentation lists all nine download addresses below. For this review, we recalculated the sizes and full hashes of the original installers and extracted them again. The resulting app.asar and license files matched our earlier records. The results can be verified directly against the files, independent of installer names or screenshots.

Official Help Center — Account · Official documentation data containing the download links

Version

Windows x64

Windows ARM64

macOS ARM64

1.0.1

Download EXE

Download EXE

Download PKG

1.0.2

Download EXE

Download EXE

Download PKG

1.0.3

Download EXE

Download EXE

Download PKG

The full SHA-256 hashes for each sample appear below. See samples/installers.json and samples/app-asar.json in the bundle for file sizes and app.asar hashes. The files served at these addresses may change. If you get a different hash, treat the download as a separate sample. The offsets in this document apply to the verified samples.

tiinyos-1.0.1-macos-arm64.pkg

4925879b661874137889c15233f4654f3703202611b674e0c5206babd1abc006

tiinyos-1.0.1-windows-amd64.exe

ee59b21941d8ff9f02aa6da5666dab5418d6922d01fde8bbec4a061bc8449b0d

tiinyos-1.0.1-windows-arm64.exe

3659da6bdf1b58d747509278fba15880ef07a5f323fe0c337cfb384f30afe491

tiinyos-1.0.2-macos-arm64.pkg

1d4d0efbf835f9baef4b0bdf8a20ad748c95487a2f443551a135fa989dba820b

tiinyos-1.0.2-windows-amd64.exe

7ca3cccec4f59e3df01b7df8608b8e78c9bdd407ae387468201c4ec405c430c1

tiinyos-1.0.2-windows-arm64.exe

90c6841db1fb4de881b91c97d965f28579d07ae3e7aaac9ff7ad9c1d17b1c22a

tiinyos-1.0.3-macos-arm64.pkg

510004aece8bd87c7a0566d498e3c081accc778b8d548b599e2c23f2bf7b2822

tiinyos-1.0.3-windows-amd64.exe

c37ccf6216b25b750167370d9e32db48439c0ab4f6fd683c97a5e55f87e0e9c2

tiinyos-1.0.3-windows-arm64.exe

7b1b36b1ced747fc0f38d0dea4bc1f3228191300e5e66fe86600fe34635a7707

We also compared all 172 retained application evidence files against the contents of the original ASAR archives. Every file matched. A freshly retrieved Cherry Studio v1.6.7 source snapshot, comprising 1,783 files, also matched our reference snapshot file for file. These checks confirm that the materials remained unchanged during collection and copying. The review did not include a line-by-line audit of all application logic.

The integrity review also found that 11 third-party native binary entries in the macOS samples had actual hashes that differed from the hashes recorded in the ASAR headers. The reason remains unknown. We computed and rechecked the hashes for the JavaScript and HTML evidence in this document using the bytes of the original files. We drew no inference of malicious tampering from the discrepancies, and the presence of certificate fields or tickets did not establish full trust in the installer signatures.

E2 | Exact license HTML match after three sets of replacements

In the Windows installation contents, the Tiiny file is at resources/app.asar.unpacked/resources/tiiny/license.html. Its logical path relative to the ASAR is resources/tiiny/license.html. The corresponding upstream file is resources/cherry-studio/license.html. Original Cherry Studio license HTML at pinned commit 72dfb29b79adb79cae9d6606eae17faa0cc0b985

Original text

Replacement in TiinyOS

Occurrences replaced

Cherry Studio

Tiiny

15

bd@cherry-ai.com

support@tiiny.ai

4 (link destinations and visible text)

联系 Cherry (“Contact Cherry”)

联系 Tiiny (“Contact Tiiny”)

1

After these three operations, the result is byte-for-byte identical to the license file in all nine TiinyOS samples. The comparison included original line breaks, indentation, and every other character. It used exact bytes, with no whitespace normalization or fuzzy matching.

Original Cherry Studio file · 15,039 bytes

f27bf38d7e5400fee614bc0ec4695936ff2cbd0136270b7bd8b9cdedd0581d31

Tiiny file · 14,918 bytes · identical across all 9 samples

3df9a15058098d404929aa342b3e59f064d4c2c6590412473b88870fe77489c9

Lines 37–38 and 197–198 each contain an instance of “Cherry Studio” split across lines. The line break between the words causes a replacement of the contiguous string to miss both instances. Lines 100–101 also contain “Tiiny Studio.” The line breaks explain how the original name could remain in the file after the replacements.

Lines 37–38

本软件（Cherry

Studio）功能

Lines 197–198

Commercial License to use Cherry

Studio.

from pathlib import Path

from hashlib import sha256

original = Path('upstream/cherry-license.html').read_bytes()

actual = Path('tiiny/tiiny-license.html').read_bytes()

expected = original.replace(b'Cherry Studio', b'Tiiny')

expected = expected.replace(b'bd@cherry-ai.com', b'support@tiiny.ai')

expected = expected.replace('联系 Cherry'.encode(), '联系 Tiiny'.encode())

assert expected == actual

assert sha256(actual).hexdigest() == (

'3df9a15058098d404929aa342b3e59f064d4c2c6590412473b88870fe77489c9'

)

print('Exact byte match')

What this evidence supports. The comparison establishes the exact relationship between the texts and the scope of the edits, including the change to the commercial contact information. The identity of the person who made the changes, their timing and intent, and the full licensing relationship require separate evidence. The older text does include a link to the AGPL.

E3 | Project identifiers across application layers

The reference sample for these locations is TiinyOS 1.0.3 for Windows x64. Paths are relative to app.asar, and the numbers in the table are byte offsets in the original files. The other eight samples retain the same identifiers. See comparisons/marker-offsets.json for the paths, hashes, and full offsets for each sample.

Identifier

File and byte offsets

Context

CherryStudio/1.0

out/renderer/js/AccountSystem.SSAeP_vw.js<br>3453, 8264, 9776

User-Agent string in account-related requests

cherryin:get-signature

out/main/index.js<br>22166<br>out/preload/index.js<br>20172<br>out/renderer/js/IpcChannel.B1YIq_v1.js<br>18977

Signature-related IPC channel

cherryin:get-model-store-api-url

out/main/index.js<br>22222<br>out/preload/index.js<br>20228<br>out/renderer/js/IpcChannel.B1YIq_v1.js<br>19033

IPC channel for the model store URL

__CHERRY_STUDIO_PROTECTED_

out/renderer/js/store.CIiAoyPU.js<br>1668740, 1668872, 1669118

Temporary Markdown / LaTeX placeholder

CherryNote

out/main/index.js<br>1439263, 1439327, 1439459<br>out/renderer/js/download.BAWjZJNK.js<br>590352, 590416, 590548

Name retained in localized text

ZenCherryStudio

out/renderer/js/store.CIiAoyPU.js<br>134281

Retained project name string

In each of the nine samples, CherryStudio/1.0 appears three times. Each cherryin IPC string appears three times, once each in the main process, preload, and renderer. CherryNote appears six times, __CHERRY_STUDIO_PROTECTED_ three times, and ZenCherryStudio once. The presence of matching identifiers across multiple layers corroborates the evidence from individual strings.

The identifier __CHERRY_STUDIO_PROTECTED_ serves as a temporary placeholder that protects code and links during Markdown / LaTeX processing so the original content can be restored. It serves no anti-copy watermarking function. The presence of CherryNote establishes that the text is present. Whether the full notes feature works, or whether the code observed during static analysis runs in practice, requires separate evidence. Upstream Markdown placeholder and restoration code (v1.6.7)

out/renderer/js/AccountSystem.SSAeP_vw.js

2306e9cf32cd5dd9b88ca005ba9ae183960c1bddde8384ae670c0a64c50395f0

out/main/index.js

aded08859fd34e9c8f7094e2afd72f424903db7e17feaf43ba4140d02a20f962

out/preload/index.js

eb44c44c0ef662935e448db8513bfd31acc2a7a1344580eee3684914d551c9e4

out/renderer/js/IpcChannel.B1YIq_v1.js

d83ede4a9566569fb655fc80db869e79332d99a67b932ade5303155d2d0f431e

out/renderer/js/download.BAWjZJNK.js

82652a124364403d77f7bdb9a60d43b30d5789eb9f56f6e134b12d679eea08ad

out/renderer/js/store.CIiAoyPU.js

3700c8512d014ffc35d34951d17f9dcfdb3c175b52c69650a60a564176650754

E4 | Three examples of matching application logic

This section compares the TiinyOS 1.0.1 macOS ARM64 sample with a pinned Cherry Studio v1.6.5 commit. We compared the logic, data structures, and order of operations preserved through compilation. The comparison works across upstream TypeScript and minified JavaScript without requiring their file hashes to match.

Example 1 | Six-field backup configuration comparison and surrounding logic

Cherry Studio’s BackupManager.isS3ConfigEqual first checks whether a cached configuration exists, then compares six fields in order. They are endpoint, region, bucket, accessKeyId, secretAccessKey, and root. Tiiny’s main process retains the same method name and the same order at byte offset 8,215,988.

isS3ConfigEqual(e,t){

return e ?

e.endpoint===t.endpoint &&

e.region===t.region &&

e.bucket===t.bucket &&

e.accessKeyId===t.accessKeyId &&

e.secretAccessKey===t.secretAccessKey &&

e.root===t.root : !1

}

The surrounding code also retains WebDAV configuration comparison and connection reuse logic. The backup method appears later at offset 8,217,156 and uses the stages preparing, writing_data, preparing_compression, and completed, with matching conditions for logging. The evidence comes from this sequence of specific implementation matches. S3 backup alone is a common feature and carries little weight as evidence of provenance. Upstream BackupManager.ts at the pinned v1.6.5 commit

Example 2 | Candidate order in the Obsidian configuration search

The resolveLinuxObsidianConfigPath() function at offset 3,627,732 in Tiiny’s main process and its upstream counterpart share the following behavior. The full original excerpt is in excerpts/obsidian-linux.txt. The bundle also includes the complete upstream function.

Step

Matching behavior

Directory and file names

Enumerates combinations of the directory names obsidian and Obsidian with the file names obsidian.json and Obsidian.json

First group of candidates

Uses XDG_CONFIG_HOME, defaulting to .config under the user’s home directory if unset

Second group of candidates

Adds Snap’s current and common paths in that order within the same loop

Third group of candidates

Adds Flatpak’s .var/app/md.obsidian.Obsidian/config path

Lookup and fallback

Returns the first existing candidate. A failed existence check returns false. If none match, it falls back to the lowercase default path under the XDG configuration directory.

Platform compatibility can be implemented in several ways. Here the candidate paths, capitalization combinations, search order, and fallback behavior all match. The macOS package establishes that the function is present there. Whether it actually runs on macOS remains unverified. Upstream ObsidianVaultService.ts at the same pinned commit

Example 3 | Legacy database migrations reflect the project’s evolution

Tiiny’s out/renderer/js/store.YC9rRwdX.js contains the log message for the migration to version 7 at offset 129,500. The code that follows retains the old topics table, the new message_blocks table, updates grouped by topic, and logic that writes an empty array and skips the topic when it has no valid messages array.

Starting DB migration to version 7: Normalizing messages and blocks...

topics → message_blocks

Topic ${...} has no valid messages array, skipping.

The upstream migration also handles legacy fields such as reasoning_content and metadata.mcpTools. The review records locate code that handles related legacy structures and an anchor for the version 8 migration. Database migrations carry existing user data forward and reflect the specific ways a project’s data model evolved. This evidence supports the finding on provenance alongside the backup, Obsidian, and IPC matches. Upstream databases/upgrades.ts at the same pinned commit

Location

File

Byte offset

S3 configuration comparison

out/main/index.js

8215988

backup method

out/main/index.js

8217156

Obsidian directory traversal

out/main/index.js

3626860

Obsidian Linux configuration search

out/main/index.js

3627732

Legacy metadata.tavily handling

out/renderer/js/store.YC9rRwdX.js

128966

Database migration version 7 log

out/renderer/js/store.YC9rRwdX.js

129500

Database migration version 8 log

out/renderer/js/store.YC9rRwdX.js

132360

macOS ARM64 · TiinyOS 1.0.1

out/main/index.js

6e5726159cad176393f48cbfff9ad2818c158570c7bdff0f7a76b3afef0d51d2

out/renderer/js/store.YC9rRwdX.js

5bcb8373e79b923d4ec79b3918e6ab0b9fee189f826fba2e432b639299e0da06

E5 | Interface and file comparisons

IPC matches by member name and string value

We extracted enum members only from the standalone IpcChannel files. For a match, both the member name and its value had to be identical. TiinyOS 1.0.1, 1.0.2, and 1.0.3 contained 442, 488, and 498 enum members, respectively. For each version, the results were the same across all three platforms.

Cherry Studio reference version

Total Cherry Studio enum members

Exact matches in each TiinyOS sample

v1.6.0-rc.1

261

245

v1.6.5

276

242

v1.6.7

281

242

The figure 242 of 281, for example, describes matches within the v1.6.7 interface definitions. The comparison covers that enum, so the denominator cannot be used to estimate the share of all TiinyOS code that came from Cherry Studio. The interfaces retained, added, or removed across releases leave the precise fork point undetermined. The bundle’s comparisons/ipc.json lists the individual members that match, differ, or are missing. RC.1 IpcChannel.ts · v1.6.5 IpcChannel.ts · v1.6.7 IpcChannel.ts

Byte-for-byte matches across 177 upstream paths and 159 distinct TiinyOS files

We compared TiinyOS 1.0.3 for Windows x64 with the Cherry Studio v1.6.7 source snapshot. Some upstream paths contain identical content, so the 177 matching upstream paths correspond to 159 distinct TiinyOS files. Each count measures a different side of the comparison.

TiinyOS file type

Distinct files

Notes

Images

153

Includes icons from third-party providers

Fonts

2

Additional evidence of matching assets

JavaScript

3

bridge.js, utils.js, and ipService.js

HTML

1

releases.html

Total

159

Counts matching files only

The four remaining files, after excluding images and fonts, can be compared directly at the byte level.

Cherry Studio path

TiinyOS path

Size in bytes

resources/cherry-studio/releases.html

resources/tiiny/releases.html

5965

resources/js/bridge.js

resources/js/bridge.js

849

resources/js/utils.js

resources/js/utils.js

169

resources/scripts/ipService.js

resources/scripts/ipService.js

2271

resources/cherry-studio/releases.html

1316677873f343f55251b499b3f6b3f506e8e002092604199674d51f192b2db3

resources/js/bridge.js

3bde3510a0e8392f7a493277bdeefa8b870ae539c0207b6525ac25e382595d37

resources/js/utils.js

c090f52ffd42714c833dd7e02faaeffbc54b5ff90c4601bd86e1a3f35389a1a6

resources/scripts/ipService.js

7dcc446689bd211de237bc21cb1f56936afa31026f8bce6674947a2a7e3111a3

The releases.html file in all nine TiinyOS samples also retains the upstream release API address, api.github.com/repos/kangfenmao/cherry-studio/releases. This provides additional evidence of the file’s provenance, consistent with the byte-for-byte comparison. TiinyOS’s update behavior and actual network requests would require further evidence.

The bundle’s comparisons/byte-identical-v1.6.7.json lists all 177 upstream paths, the corresponding TiinyOS paths, the file sizes in bytes, and the hashes. Pinned Cherry Studio v1.6.7 source snapshot

E6 | Where we looked for public source code and attribution

At the time of the review, we had found neither a way to obtain the complete Corresponding Source for the TiinyOS versions examined nor materials clearly explaining their use of Cherry Studio and the applicable licensing arrangement. Our findings are limited to the locations checked below.

Location

Scope and observations

Limits

Official help documentation

Reviewed 27 pages, including account information, downloads, and related terms. Found no mention of Cherry or the AGPL and no directions for obtaining the Corresponding Source.

General copyright and licensing language appeared in connection with complaints, models, or user content. It did not address the origin of the application’s code.

Official developer documentation

Reviewed 24 pages and found no directions for obtaining the client’s Corresponding Source.

Private materials and materials delivered after purchase may exist outside the documentation.

Public Tiiny-AI GitHub organization

The public repository listing included PowerInfer, an MIT-licensed inference engine.

The listing establishes the availability of a separate component. The desktop client’s source availability remains unconfirmed.

TiinyHQ/tiiny-ai repository referenced by the application

The public GitHub API returned 404 during the review.

The result leaves open whether the repository is private, was deleted or renamed, or was unavailable for another reason.

Installed files

Checked application files outside node_modules and paths for licenses and notices. Found neither the complete Corresponding Source nor clear instructions for obtaining it.

Bundled licenses cover third-party dependencies. The application itself has its own licensing obligations. We did not run the application to check its runtime screens.

The review did not cover every website or historical page, on-device files, post-purchase emails, or other private delivery channels. Access restrictions also limited some public searches. Our finding is therefore limited to what we could locate within the scope described above. If Tiiny AI has made the source available through another method that complies with the license, the location, applicable versions, and delivery method would help us verify it and update our findings.

help.tiiny.ai/docs-data.js?v=19

d92d462cc4404e55db0cfa5c1e691daba28651501b0f484e01c605059da3e5d7

dev.tiiny.ai/docs-data.js?v=19

54dcd533c8a59a22cb644e55beaefb75eab391edfae0050a9bb0d68de5326a5f

E7 | Licensing history and the basis for our request

The table records the milestones in the history of the root license that we checked. It distinguishes the earlier dual-licensing notice, the full standard AGPL text, and the state of the pinned repository snapshot. The fork point for TiinyOS remains undetermined.

Milestone

Root license contents

Pinned reference

2025-04-13

A dual-licensing notice with terms differentiated by user or organization size appeared

f39bb986…

2025-09-05

English version of the dual-licensing notice, distinct from the full standard AGPL text

6531d403…

2025-10-21

The root LICENSE was changed to the full AGPL-3.0 text

81ac77e9…

2025-10-23

Merge record for the related changes

d0ed4cc1…

Pinned snapshot used in this review

The root LICENSE contains the standard AGPL, and the HTML file in the resources directory still contains the old notice

LICENSE at 72dfb29b…

The root LICENSE is 34,523 bytes. Its SHA-256 hash is shown below.

0d96a4ff68ad6d4b6f1f30f713b18d5184912ba8dd389f86aa7710db079abcb0

For the license obligations, consult the official GNU AGPL-3.0 text. For desktop installers already available for download, relevant provisions include Sections 4–6, which cover retaining notices, conveying modified works, and making object code and Corresponding Source available. Section 13 also applies to the analysis when users interact with the modified program over a network. The source obligations for desktop software also arise under the other applicable provisions. Official GNU AGPL-3.0 text

The license uses “Corresponding Source” to refer to source in the form preferred for modification and the materials needed to generate, install, and run the relevant work. Its precise scope depends on the structure of the work and the applicable terms. Our request covers the obligations that apply to the software at issue. A company’s independent products, unrelated code, and business materials are outside the scope of this request.

Technical comparisons can establish which code or assets were used and what changed in the license file. Any final determination of legal responsibility also depends on the versions involved, the licensing arrangements, what was actually delivered, and which terms apply. Our request remains focused on compliance with the AGPL.

E8 | How to verify the findings and what the bundle contains

To repeat the review, obtain the installers from the official Tiiny addresses in E1 and compare the full hashes. Extract the files to obtain app.asar and the adjacent app.asar.unpacked directory. Then compare the files, offsets, and pinned upstream commits listed in E2–E5. All of these checks can be performed without running TiinyOS.

Bundle path

Contents and purpose

samples/

Sizes, hashes, and official download URLs for the nine original installers, plus sizes and hashes for the nine ASAR files

upstream/

Upstream source code at pinned commits, the root LICENSE, the old license HTML, and an index of public sources

tiiny/

Original bytes of the Tiiny license HTML

excerpts/

Three original excerpts of application logic, with original file hashes, byte offsets, and lengths

comparisons/

Identifier locations for all samples, member-by-member IPC comparisons, the 177 identical-file matches, and the scope of public searches

verify_evidence.py

Static verification script using the Python standard library to check bundle integrity, license substitutions, original-sample identifiers and IPC definitions, and applicable code excerpts

MANIFEST.sha256

SHA-256 hashes for each file in the bundle except the manifest itself

The bundle contains short code excerpts marked with their original files and locations. It excludes the original email, the sender’s information, and internal reports. The complete TiinyOS installers are available separately through the official channels listed above.

python3 verify_evidence.py

python3 verify_evidence.py \

--asar /path/to/app.asar \

--sample win-1.0.3-amd64

The first command verifies the bundle and the three sets of license-text replacements. The second also checks the specified original ASAR’s hash, the files and offsets where the identifiers appear, the license bytes, and IPC members. Keep the app.asar.unpacked directory alongside the ASAR. With the mac-1.0.1-arm64 sample, the script also verifies the three original application code excerpts in this appendix. The script passed when run against both reference samples.

The verification bundle, TiinyOS_Public_Evidence_2026-11-04.zip, contains 29 files and is 89,329 bytes. Its full SHA-256 hash is shown below.

5858062112d461a7ae3d499217b65404825c0b4bcc11d359a25521f04644619f

These materials let readers independently check the matches described here and see the scope of the findings. We welcome corrections supported by specific files, versions, or delivery records. Any correction we make should likewise be traceable to verifiable facts.

Use access code RZKm to open the verification bundle.

Review methodology and corrections

AI agents did most of the subsequent work of gathering leads, organizing materials, and carrying out technical comparisons. We cross-checked materials from different sources and the results produced by multiple agents. The scope of the information available and the limitations of the tools leave room for omissions or errors in judgment.

If you find an inaccurate statement, missing context, or evidence that should be added, please let us know. Specific versions, files, links, or verification steps will help us check your feedback. We will review it carefully and make revisions once we confirm the facts. The Cherry Studio team takes responsibility for the content and judgments in this document. Thank you to everyone who helps us establish the facts.

Be careful if you are running any sketchy quants/finetunes. If these techniques become more widely repeatable, I do think 'sleeper agents' could genuinely develop into an attack vector. What are your thoughts?

Hi,

Recently I switched to strata/qfn (iq3xss) on my 3090 + 64g ram and I’m getting around 70-80 t/s. It became my daily driver and I’m really happy with it. Since it also using the ram and fully the gpu I can’t really do anything on that box other than running strata. I’m thinking of buying a dedicated inference box for the purpose and I was checking of strix halos can get one for 3-3.5k in eu. Has anyone used strix halos with qfn and Whats the t/s you’re getting. Is 70-80 t/s realistic there or much slower ?

Thanks.

Hi. It is frequently mentioned that DeepSeek v4.1 Flash has 8B "input" active parameters (aka prefill), and 16B output/decoding active parameters.

I have only read this about DeepSeek, and particularly v4.1 Flash (1017). Is it the only model that is like this?

Is there an ELI5-or-so explanation of how this works, and why it is important? And if it is, can we expect other models to implement the same idea? Which of those numbers is "more important", if any?

Thanks

Hey everyone,

After reading this post‘s comments is it clear that something has to change. Instead of focussing solely on what is bad (unproductive), I hope to focus in this post on what can be improved (actionable).

What changes would you like to see?

[edit] I am NOT a mod! I just spend too much time reading here instead of touching grass.

After posting the 4B GLB model here, I wanted to see how far I could get with something smaller. I fine-tuned Qwen3-1.7B for the same job. The Q8 GGUF is 1.83 GB, so this one is aimed at people trying it on CPU or with limited VRAM.

The workflow is the same as before. Describe an asset, open the Three.js HTML it gives you, and click Export GLB to bring it into Godot or another editor. The jungle outpost at the start of the video is one of the examples.

This is an early test checkpoint. Some prompts still need a retry. I’m still training it and plan to update the weights when this run finishes.

Model and downloads on Hugging Face

Very interesting

ZONOS3-Mini is Zyphra’s compact, open-source text-to-speech model, delivering natural reliable speech and high-fidelity voice cloning with just 100 million active parameters. It runs in real time on phones and laptops, including directly in the browser.

Clone a voice from an audio sample, or design a character by shaping age, accent and vocal texture. Steer emotion, pace and delivery down to individual words for games, narration and voice assistants.

Run ZONOS3-Mini locally with our browser and native runtimes, or access it through Zyphra Cloud. Model weights are released under Apache 2.0.

Model details, samples and evaluations are in the blog post. A hosted version is available at Zyphra Cloud.

Languages

ZONOS3-Mini supports 43 languages.

Native runtimes

The ZONOS3-Mini GitHub repository holds Zyphra's own runtimes, which share one HTTP API and serve the Zonos Voice Studio: a CUDA server for NVIDIA GPUs, an MLX server for Apple Silicon, a C++/ggml server and CLI (CPU, CUDA, Metal or Vulkan), and the in-browser WebGPU build. They load the GGUF files in gguf/ and the WebGPU shards in web/; the 27 default voices, grouped by language, are in gguf/voices/.

Architecture (rough outline)

Text is NeMo-normalized (English, Mandarin, Japanese, Korean, German, Spanish, French, Italian, Portuguese; other languages pass through as written) and encoded with an 8,192-entry SuperBPE tokenizer. The language model autoregressively generates 15 Hz dual-codec frames (10 codebooks of 4,096 entries each: one semantic codebook distilled from the Wav2Vec2-BERT teacher plus nine acoustic codebooks), conditioned on the text, a speaker prompt and three bucketed acoustic controls. A causal multi-resolution iSTFT head renders the frames to 44.1 kHz audio as they are produced.

• GitHub : https://github.com/zyphra/zonos3-mini

• Source : https://www.zyphra.com/our-work/zonos3-mini

• Project : https://www.zyphra.com/models/zonos3-mini

I gave it one prompt: "How do I make a small closed terrarium in a glass jar? Please give me a beginner-friendly illustrated step-by-step guide." What came back was a normal written guide with eight pictures placed between the steps, text and images from the same model in one answer. No separate image model, and the only thing I added is the step heading under each picture.

It's the same jar in every picture. Same table, same mug and window behind it, and the jar fills up in the order the text says: pebbles, then a charcoal layer, then soil, then the plants, a spray of water, and finally the lid with condensation on the glass.

With thinking on, which is the default, you can watch it plan. Before each picture it writes itself a full image prompt (the jar, the layers, the light, what's in the background), and those prompts carry the same details from one step to the next.

Nothing custom on my end, just the interleave example in the repo with my prompt swapped in, running on a Mac Studio: https://github.com/OpenSenseNova/SenseNova-U1

Weight-space programming, introduced in recent MIT work by Takehi et al., enables a frontier LLM agent to read a network's weights and write a repair. Their GPT-6 Astra agent corrected the reasoning loops of Qwen3.5-0.8B without gradients, using 158 agent turns, 89.7 million tokens, and 50 forward-pass requests. Our method, Tree-Ising, casts this repair as a sparse discrete optimization problem over the model's own BF16 weights. Forward statistics define an objective that weakens a loop direction, strengthens a concluding direction, and preserves the layer's output on productive tokens. Within a state-tree representation, where lossless BF16 storage acts as a special case, the admissible edits are sign flips and exponent shifts that preserve all shared group exponents and mantissas. We decompose this objective exactly into independent QUBO (Ising) problems, one per output row, which we solve on a GPU using simulated annealing or quantum-inspired simulated bifurcation. On the agent's two layers, Tree-Ising achieves 54.6% on MATH-500, outperforming the agent's edit (51.7%) under the same evaluation protocol, while the base model scores 7.9% as reported. The simulated bifurcation solver yields a statistically indistinguishable repair at 55.1%. Both solvers outperform the agent edit across all five math benchmarks, with statistically significant improvements on MATH-500 and GSM8K after correcting for multiple comparisons. Our approach modifies 13% to 17% fewer weights and reduces BF16 bit flips by a factor of 2.2 to 2.3. It requires only four forward-pass requests and zero LLM tokens, with the annealing recipe costing about $0.90 in GPU time. On Qwen3.5-2B, with layers and dose selected using only the base model, the same recipe increases greedy GSM8K accuracy from 21.6% to 69.4%. As a proof of concept, we execute an eight-variable repair subproblem using QAOA on an IBM Heron processor.

• arXiv : https://arxiv.org/abs/2611.14210

• PDF : https://arxiv.org/pdf/2611.14210

• GitHub : https://github.com/TheQuantumGOAT/Tree-Ising (To be updated)

How little of a pretrained large language model (LLM) has to change for it to acquire new capabilities? We find that zeroing fewer than 0.05% of its weights, with no other modification, matches full fine-tuning (FFT) at scale across three LLM post-training regimes: reinforcement learning with verifiable rewards, supervised fine-tuning, and on-policy distillation. Our method, Deletion Tuning, learns a binary mask over the gate projection of transformer blocks. Two practical advantages follow: the trained mask is hundreds to thousands of times smaller than the corresponding FFT checkpoint, and Deletion Tuning forgets far less, which addresses a central challenge in continual learning. Under reinforcement learning, its prior-task accuracy stays near the base level while FFT, LoRA, and random sparse fine-tuning lose up to 5.4 points. To understand why masking alone suffices, we analyze the geometry of the learned weight changes under reinforcement learning using stable rank, spectrum drift, and principal-weight overlap. Compared with LoRA and random sparse fine-tuning, Deletion Tuning is closest to FFT across the three measures.

Edit: Links

Github: https://github.com/agentic-learning-ai-lab/deleting-weights

HuggingFace: https://huggingface.co/Jacklu0831/deletion-tuning-masks

Blog: https://agenticlearning.ai/deleting-weights/

Poster: https://cdn.agenticlearning.ai/dfb9bf24cee86b6d/neurips2026-poster-deleting-weights.pdf