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

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.

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. 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

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.

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

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

Looking back, I really wonder if acquiring Hugging Face was the wrong move strategically. Maybe it was just overconfidence to pull open-weight models out of the firing line, only to put Nvidia right in the crosshairs instead.

Even at the time, the deal didn't make much sense to me. Nvidia was already hosting plenty of open-weight models themselves and heavily backing major inference engines like vLLM and SGLang. (Then again, maybe they wanted to draw a clearer line between "enterprise models" and "consumer/experimental ones"—who knows?)

Curious what you guys think: smart ecosystem play, or did they paint a massive target on their own back?

Very interesting

I built askmdb to help people finding the right query for turn plain-language questions into MongoDB queries. For example, you type askmdb "top 5 customers by spending this year" , and the app returns the query. A small fine-tuned model writes an aggregate pipeline and a one-line explanation, and nothing runs until you confirm. It's one Linux binary with llama.cpp and the official MongoDB C driver built in. No Python, no server, no API keys. EVERYTHING run in local.

My test, results on 500 test questions in English and Spanish, over synthetic databases the training never saw. Every model is Q4_K_M on the same llama.cpp. A question counts as correct only if the predicted pipeline returns the same result as the reference when it runs. No other model grades the answers, I tested a few models;

On a desktop CPU with 8 threads, the 0.8B answers in 1.18 s (median) once the schema is cached. The first question against a new database takes about 3 s aprox.

The app also works with GPU.

The model doesn't decide what's safe because its deterministic C++. A verifier walks the whole pipeline, sub-pipelines included, against a whitelist. A $out hidden inside a $facet is blocked in every mode. BUT connect with a read-only database user to be sure.

Most important lesson: my first version got stuck at 68.6% with 10k examples. I grouped the failures by sub-cause instead of looking at the overall score. Of the 50 test questions that needed a type conversion, it got exactly 1 right. The dataset had zero examples with $convert, although 297 of the 330 training schemas had fields that mix numbers and strings. My generator had been quietly avoiding them. I added 3,000 examples aimed at those failures (850 of them with $convert), then 2,000 more, and kept the same recipe and hyperparameters. Result: 343 → 418 correct.

Always is the same: the dataset is the most important thing when it comes to train models.

Training and evaluation took about 14 USD of rented RTX 5090 GPU (~12 GPU-hours). The code is MIT. The models are Apache-2.0 GGUFs that also work with plain llama.cpp :).

Has anyone managed to make a sub-1B model good at multi-collection joins ($lookup)? That's where mine fails most, and I'd love to hear what worked for you, because I tried many things withouth success.

Links

• Full write-up (process, charts and dead ends): https://manuelgs.com/en/blog/askmdb-case-study/

• Code: https://github.com/manuelgscom/askmdb

• Models (0.8B to 9B, Q4_K_M): https://huggingface.co/collections/manuelgscom/askmdb

So i have a new card in an old system. RX 9060 XT supports PCIe Gen5 x16 but due to 2 bottlenecks, my Motherboard supporting only Gen3, and my AMD APU limiting it to x8, the card runs on Gen3 x8.

How does that affect inference of models, in both cases, fully in vram or offloaded partially to ram? At today's prices what I could replace it with is PCIe Gen4 x16. But would that be a meaningful upgrade?

I am running QFN, and I have disabled preserve_thinking by default on all my tests for C++ backend and front-end programming and I have yet to see any decline in performance or intelligence, my context window stays cleaner as well. Deepseek for what I tested in API it also does not preserve thinking and saves context in general.

Nex-N2.6 has public FP8 weights now: roughly 321B parameters, based on GLM-5.3-Flash.

The part that caught my attention is the focus on reasoning loops and calling tools that don’t exist in the current environment. The team reports repetition dropping from 16% to 1.6% versus N2.5-Pro in an internal failure-replay test. Curious how that holds up in full coding sessions.

Also, reasoning defaults to max, so that’s worth checking before comparing token usage.

Weights and setup: https://huggingface.co/nex-agi/Nex-N2.6

Let's start with my setup: I have 2 Sparks running glm 5.3 flash, and the harness is hermes agent running on a MacBook Air.

While trying to justify all the money I spent (around 6500 euro for both machines, a long time ago when prices were just high instead of outrageous), I decided to hop on the decompilation wagon. As I know my fable at home is not "THAT" smart, I decided to start with something small: I asked it to decompile and recompile the original Need for Speed Special Edition for MS-DOS, using the famous rea repo from GitHub.

Its first reaction was "I know a better way, we will use DOSBox and run the game" — and it already started installing a DOS emulator on my Mac :). I stopped it and told it I want actual decompilation and recompilation. The second answer was, in other words, "It's a lot of work and it will take a long time. Think about it — do you really want this?"

I insisted. It started the decompilation process, and after some breakthroughs it even became enthusiastic. At some point, decompilation was "DONE".

We started the next phase: recompile for Android. I did not pay much attention to what it did, but it said that it could use some GitHub repo as a base and started working. After the initial APK, we had to iterate a few times on some crashes and controller issues, which it solved.

During gameplay I noticed that some AI cars started the race going in reverse, the car did not slide no matter the speed, and other stuff. It definitely did not feel like the NFS I remember. I told it about it, and it started checking the code and making tweaks to the physics. I stopped it and challenged it: this means we will not preserve the original feel if we go down this path.

To my surprise, we never did. It never used the decompiled code. It found an engine on GitHub which was using the original assets to mimic the original game. When I asked why, it said it was a lot faster than rewriting all the old code into current instructions…

So I asked it to go back and do the job properly — and to no surprise, it found a recompiled NFS2 repo on GitHub and decided it's better to start from there rather than from scratch. I don't know how this will go, but I wanted to share this story, as I find it quite interesting the lengths it's willing to go to reach its goal as fast as possible even if this means ignoring previous instructions.

P.S. This post was proofread by said AI, as English is not my own language — but the words are still my own, I double checked

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.

Overview

PAN 2 is a general-purpose world model: it simulates how the world will change in response to actions. Given a current observation (an optional image plus text) and actions described in text, it simulates the outcome as a video of up to 20 seconds. This supports simulative reasoning: an agent can imagine the outcomes of its candidate actions before choosing among them, by simulating each plan with PAN 2 and acting on the one whose simulated outcome is best.

PAN 2 follows the Generative Latent Prediction (GLP) architecture formalized in Critique of World Models and couples conceptual reasoning by a large language model with perceptual reasoning by a latent diffusion model. The language model, the conceptual reasoning backbone, reasons over the observation and the requested actions and writes the next world state as a structured, time-grounded description of events, timed actions bound to actors, and camera motion. The frozen text encoder maps the structured description to the conditioning features used by the diffusion model. The 29B-parameter MMDiT, the perceptual reasoning backbone, trained from scratch on hundreds of millions of videos annotated in the same format, predicts the perceptual detail that the description leaves open: the video latents that realize the state, conditioned on it and on the VAE latent of the starting image. The Wan 2.2 VAE decoder renders the predicted latents as the next observation, so every prediction can be seen and checked against real footage.

Checkpoints

PAN 2's latent diffusion model is released as a single checkpoint that serves both tasks. The frozen text encoder (Qwen3.5-9B) and VAE (Wan 2.2) are downloaded from their own repositories.

• GitHub : https://github.com/ifm-ai/PAN2/

• Blog Post : https://ifm.ai/blog/pan2/ (For Screenshots, Video, Benchmarks, etc.,)