Massive AlephLM success. The task collective is producing powerful MOE shared knowledge adapters. A serious success and a massive first step towards the next stage. The current family collective results are present here; AbstractPhil/geolip-aleph-qwen
This is akin to a stackable non-intrusive lora that enables increased shared collective behavior.
This includes the three mentioned json tasks, a math task, a tinystories task, and a diffusion task for cifar10. Each adapter anchored to the knowledge within model that already exists while enhancing the knowledge through anchored lookup systems and decision-driven hierarchical access trees.
All tasks activate independently upon manual override, all tasks handle direct shared knowledge when left to greedy decoding, each task issued multiple tests alongside to determine fidelity and accuracy throughout the process.
The results show the gating is more than willing to hop from sector to sector, using alternating weight shifts from the cooperative anchored systems - even systems never trained for the tasks contributing to the accuracy of the results for other tasks due to the lookup accuracy to the heuristic chains, never having seen the tasks before. Each structure is independently trained and the collective cooperates together through a dense activation network.
I never really posted about my DaisyChain project because it's still work in progress. I decided to post a small bit about it and the demo. DaisyChain Genomics: four small DNA/RNA specialists chained behind a learned router that behave like one big genomics model, at ~7× less active compute. I built a modular genomics model chasing a 500M-parameter foundation model, then caught myself measuring it wrong. Here's the honest version. DaisyChain is a different bet: instead of one monolithic DNA model, it's four ~74M specialists (eukaryote, prokaryote, mRNA, splice) chained behind a learned router, each distilled per-domain from HuggingFaceBio's Carbon-500M. Every specialist reports how surprised it is (bits/base) and the router hands each sequence to the link most at home with it. In lineage it's a cluster Branch-Train-Merge mixture of experts, so you can chain on a new domain without retraining the others. The pitch: ~295M total params (under Carbon-500M), but only one ~74M specialist runs per query, so ~7× cheaper per token, routing at 100% held-out. The mistake: Carbon works in 6-mers, and I'd been scoring likelihood as 6-mer cross-entropy. By that number I was +0.043 bits/base behind, splice even "beating" Carbon. But Carbon scores at the base-pair level, which is harder and more honest. Re-run their way: Real gap: 1.862 vs 1.787 bits/base, +0.089 behind, not +0.043 No domain actually beats Carbon; the "splice win" was an artifact Seq recovery: euk 31.5% vs 38.9%, bacteria 40.9% vs 54.1%
DaisyChain is still behind Carbon-500M (itself a draft model, not built to top benchmarks), but by a number I can defend, and the gap closes with every per-domain pass. 🌼
🌼 DaisyChain-Web: train a language model with friends or by yourself with multiple devices, in the browser, no install
Open a webpage, share a room link, and every device that joins becomes part of the training cluster. Phones, laptops, old PCs: they connect peer-to-peer over WebRTC and train one shared transformer together, entirely in the browser.
What's actually happening under the hood:
🧠 A mini transformer LM trains on FineWeb-Edu, streamed live from the HuggingFace Hub. Each device pulls its own slice (data parallelism), tokenized with our 16.5k-token Spikewhale tokenizer ⚡ Every single multiply runs through verified INT8 neural units, no float fallback. On WebGPU browsers it uses the GPU's DP4A integer dot-product hardware, admitted only after proving bit-identical results against the verified units, with a 3×INT8 fast-accurate scheme (CUTLASS's 3xTF32 trick, ported to 8-bit) 🔒 Devices average gradients every step under a sync guard: a per-step roster protocol plus weight-hash verification keeps every device's model bit-identical. If anything drifts, training stops instead of silently forking 📊 Live logs show exactly what every device contributes, step by step 💾 When you're done: test generations right on the page, download a checkpoint, or grab the inference kit, a single self-contained HTML file with the weights baked in that runs generations offline, anywhere Works solo too. Every extra device just grows the effective batch.
"Frontier models need a datacenter GPU" rests on a hidden assumption: that the model reads ALL its parameters every token. Decode is memory-bandwidth bound — sweep 34B params/token and an 8 GB card dies at 1–2 tok/s.
So we ran ONE 34.7B reasoning model — Ourbox-35B-JGOS, a sparse Mixture-of-Experts — as the identical weights across the whole hardware spectrum. All measured:
Why it works: Ourbox holds 34.7B params but only ~3B are active per token (256 experts, top-8). Since decode is bandwidth-bound, a dense 34B moves ~16.7 GB/token while Ourbox moves ~1.45 GB — ~11× less traffic. Put the experts in system RAM, keep attention/router/shared on the GPU, and a 34.7B reasoner runs on an 8 GB laptop — or no GPU at all.
Sparsity alone, proven (same laptop, same quant, ~same footprint): Ourbox-35B (A3B) 20.01 tok/s vs Qwen2.5-32B (dense) 5.36 → 3.7× from sparsity alone, ~2× the best dense-32B on any 8 GB machine. Not a toy: GPQA Diamond 86.4% (maj@8).
Try it live (same prompt, GPU vs GPU-less CPU, live tok/s). Honest scope: one machine's measurements; the CPU path proves it RUNS without a GPU, not that it beats one.
My AI Waifu's architecture has grown too complicate. Even ask AI to help me gen a simplified version of the diagram is still so complicated.
I know I'm too ambitious to build such a complicated local AI workflow with small AI models in limited resource of Jetson Orin Nano 8GB. I don't know if it would work, but the foundation of harness architecture is there.
Here are the models I'm currently using Main LLM: Ministral3-3B-Instruct UD-Q4_K_XL (Multimodal: text, tool call, vision, 8K context -> preferably 16K) Helper LLM: SmolLM2-135M (Agentic Routing, Memory Extraction) Embedding model: Harrier-OSS-v1-270M (Memory, RAG, Semantic Routing) ASR model: SenseVoice (English, Japanese, Cantonese , Mandarin, Korean) TTS model: MioTTS-0.4B-Q4KM + synthesize (English, Japanese with voice cloning preset)
That's 4GB + 0.5GB x 3 + 2GB = ~7.5GB out of 7.4GB available in Jetson
PS: Mistral family models especially such a small param LLM tends to hallucinate all the time. But actually the hallucinations did give my AI Waifu a somewhat poetic tone in her tone. Also it also has vision and tool call capabilities, so I guess I have to live with the hallucinations.
I've been playing around with open source image generation models for a stream I'm doing on Friday. I created a list of prompts to evaluate how they handle different types of situations.
I'm using Flyte Devbox on a NVIDIA DGX SPark to run this all locally, The results get embedded directly in a Flyte report for quick scanning and every run is versioned which is great for coming back to what the prompt was.
In this run I tried the models: - Flux1 schnell - SDXL - NVIDIA's Sana sprint - Qwen Image 2512 - zimage turbo - chroma-hd - Chroma Flash
I want to try getting Flux2, SD35 large, and Krea2 going as well (but may not have time before friday).
Any other open source models that have come up you think are worth trying out?
Qwen3.6-27B-pi-tune v2 is coming plus its sibling 35B-A3B variant
I just wanted to share an update on the progress of future releases for Qwen3.6-pi-tuned family models.
Both 27B and 35B models are now unified under native think/no-think functionality.
The biggest lesson I started to learn after reviewing many suggestions: Fine-tuning for local open-weight agents isn't just about raw coding capability or benchmark numbers. Harness fluency, tool-calling, validation loops, and user-facing behavior matter just as much, sometimes more.
That insight and philosophy is exactly what v2 is based on.
Although it hasn't even been a month since the original release I wanted to get out the 35B-A3B variant as soon as possible due to popular demand.
With the current and upcoming releases of a new class of Agentic LLM's (Fable, GPT5.6, etc) expect v3 to be the best yet.
For everyone already running the original: what's it doing well, and what makes you reach for a different model? These suggestions help shape future releases.
Excited to share: I’m using Grok 4.5 as the model behind Claude Code.
How: SpoX — a zero-dependency Python proxy on localhost:8048.
- Grok subscription → OAuth device code (no API key) - Speaks Anthropic Messages API (and OpenAI chat completions) - Claude Code / VSCodium point ANTHROPIC_BASE_URL at it - Compact window set to 500k so it matches Grok’s real limit
Two files. stdlib only. Start it, log in once, keep building.
🌌 Calling all space lovers — every "Astronomy Picture of the Day" from NASA since 1995 is now an open dataset. For 30+ years, NASA has shared one amazing image of space every single day, colorful galaxies, bright stars, planets, and the sun, each with a short explanation written by a real astronomer.
Honestly, the pictures amazed me — full credit to all the photographers and astronomers behind them. 🙌 Whether you love space, enjoy building things, or just like looking at amazing pictures, this one's for you. If it gives you an idea, let's build it together. 🌠
Feel free to use the dataset, a mention or credit is always appreciated. 🙏
Data from NASA · public domain · not affiliated with NASA #space #nasa #dataset #astronomy #opensource #photographers
reactedtoMiniMax-AI'spost with 🔥about 15 hours ago
Huge news from MiniMax: we’ve secured a $2B funding round, paired with a formal long-term commitment from our CEO IO to allocate 1% of total company equity from his personal holdings to support the global open-source AI community over the next four years.
This capital backs our continuous open model releases, community tooling and transparent frontier AI research. We’re just getting started on our open-source roadmap toward accessible AGI.
If you build with open foundation models and want to push frontier AI together, come join us. Intelligence with Everyone. 🚀
✅ Article highlight: *Sunset and End-of-Life Governance* (art-60-200, v0.1)
TL;DR: This article argues that “the legacy system is retired” is not enough.
Long-lived governed systems do not simply shut down. They end through live-authority closure, archive, successor handoff, retention freeze, deletion finalization, tombstone linkage, and closure receipts. 200 turns end-of-life into a first-class governance surface.
Why it matters: • prevents archive from becoming disappearance theater • prevents successor handoff from laundering identity, authority, or liability • blocks deletion-first closure while disputes, holds, or obligations remain alive • separates ending live operation from ending governance relevance • keeps retired systems explainable through archive bundles and tombstone linkage
What’s inside: • end-of-life envelopes for bounded closure paths • archive bundles for lineage, obligations, audit state, disputes, and evidence • successor-handoff receipts for accepted and non-carried surfaces • retention-freeze manifests for holds, deletion prerequisites, and closure criteria • deletion-finalization receipts for what may and may not be deleted • closure receipts for what ended, what remained, and what reentry can reopen • tombstone-linkage records connecting retired live paths to archive and successor history
Key idea: Do not say:
*“the old system was shut down and the new one took over.”*
Say:
*“this system entered end-of-life under this envelope, preserved this archive bundle, handed off only these admitted surfaces, froze retention before deletion, finalized only eligible deletion, emitted closure receipts, and kept tombstone linkage for future review.”*
Systems can end.
Obligations do not vanish just because the service is off.
reactedtoProCreations'spost with 🤗about 15 hours ago
