#开源/仓库

3 today

May 6Wednesday

Synced · WeChatMay 6, 12:07

Two Chinese open-source projects turn Mac into a private AI workstation

Mininglamp open-sourced Cider and Mano-P 1.0 for Apple Silicon local inference and GUI agents. Cider speeds Qwen3-VL-2B prefill by 57%–61% on M5 Pro; Mano-P 1.0-72B scores 58.2% on OSWorld. The key constraint is W8A8 memory: on 16GB devices accuracy falls from 58.0% to 54.0%, so 32GB+ is recommended.

Why it matters: HKR-H/K/R all pass: the Mac-local workstation angle is clickable, and Cider/Mano-P include testable numbers. Score stays at 80 because the source entity is not a top-tier model lab.

May 5Tuesday

r/LocalLLaMAMay 5, 23:02

SenseNova-U1-8B-MoT open-source multimodal architecture draws LocalLLaMA discussion

SenseNova open-sourced SenseNova-U1-8B-MoT, an 8B native multimodal understanding and image-generation model. Its Hugging Face text says NEO-Unify removes VE and VAE, supports interleaved image-text generation, and high-density rendering; the post does not disclose test scores. The key question is whether the monolithic design yields reproducible gains.

Why it matters: HKR-H/K/R all pass: the open 8B unified multimodal model has a concrete architecture hook. No benchmark scores, license detail, or deployment cost are disclosed, so it stays in the 72–77 band.

Take

SenseNova-U1-8B-MoT has the right bait: 8B parameters, open source, native multimodal understanding, image generation, and a NEO-Unify pitch that removes VE and VAE. That directly pokes at the messy stack around Qwen-VL, InternVL, LLaVA-style adapters, and separate diffusion/VAE plumbing. If one compact model handles interleaved text-image generation and dense information rendering reliably, the architecture deserves attention.

The evidence is thin. The Reddit body is blocked by 403, and the summary gives no benchmark, license, VRAM profile, sampling setup, or failure cases. “High-density rendering” is exactly where demos lie: OCR, tables, UI screenshots, and Chinese long images break polished claims fast. I’d file this as architecturally interesting, not yet performance-relevant.

r/LocalLLaMAMay 5, 15:33

vibevoice.cpp: Microsoft VibeVoice ported to ggml/C++ with no Python at inference

LocalAI released vibevoice.cpp, a ggml/C++ port of Microsoft VibeVoice for CPU, CUDA, Metal, and Vulkan inference. TTS uses a 30s reference clip for 24kHz cloned speech; ASR uses a 7B model with diarized JSON and was tested on 17min audio. The key constraint is memory: 17min CPU Q8_0 peaks near 26GB, with no streaming output yet.

Why it matters: HKR-H/K/R all pass: a practical open-source VibeVoice C++ port with concrete runtime numbers. Reddit-source scope and niche audio deployment keep it in the 72–77 featured band, not same-day must-write.

r/LocalLLaMAMay 5, 05:38

FastDMS: 6.4X KV-cache compression running faster than vLLM BF16/FP8

FastDMS released an MIT implementation that cuts KV memory to 1/5–1/8 of vLLM BF16 at 8K context. A Llama-3.2-1B replication reports PPL 9.200 with 6.4x compression; Qwen3-8B c=1 drops KV from 1.406 GiB to 0.184 GiB. The key detail is physical reclamation of evicted slots, not just nominal KV-byte reduction.

Why it matters: HKR-H/K/R all pass: the hook is counterintuitive, with compression, PPL, KV GiB deltas, and physical slot reclamation. Reddit/open-source sourcing keeps it in 78–84, below P1.

May 4Monday

r/LocalLLaMAMay 4, 19:09

Deep research report with Hermes Agent and qwen3.6-35b-a3b Q6_K

A Reddit user used Hermes Agent and qwen3.6-35b-a3b Q6_K to produce a 21-page research report. The run took 6 loops and over 5 hours on an RTX 4060, at about 28 tokens/s. The repo includes prompts, scripts, intermediate artifacts, and the final report.

Why it matters: HKR-H/K/R all pass: this is a local-agent experiment with hardware, runtime, speed, and artifacts. Reddit source limits reach, so it stays in the 72–77 featured-threshold band.

QbitAI · WeChatMay 4, 12:24

DeepSeek-TUI, a “DeepSeek Claude Code,” reaches 2.3k GitHub stars

DeepSeek-TUI reached 2.3k GitHub stars; the Rust project is MIT-licensed. It targets DeepSeek V4 with a 1M-token context, RLM up to 16 V4 Flash subtasks, MCP, Shell, Git, and three control modes. Watch cache misses: uncached tokens cost 10x cached tokens.

Why it matters: HKR-H/K/R all pass: the hook is a DeepSeek-flavored Claude Code, with 2.3k stars, 1M tokens, 16 subtasks, and a 10x cache-miss cost gap. Impact is developer-specific, so it sits in the 72–77 band.

Take

DeepSeek-TUI reached 2.3k GitHub stars in four months and wraps DeepSeek V4’s 1M-token context, prefix caching, and V4 Flash subtasks into a Rust TUI. My read is simple: this is less a “Claude Code clone” than an attempt to turn model pricing mechanics into product behavior. Its future depends on long-session reliability, sub-agent routing, and cache hit rates, not on how closely the README resembles Claude Code.

The feature list is broad: file edits, Shell, Git, web search, MCP, Skills, three control modes, session restore, and Git snapshot rollback. On paper, that matches the terminal-agent shape Claude Code popularized. But Claude Code’s edge is not just tool access. Anthropic has been tightening tool-call reliability, permission boundaries, task state, recovery loops, and the fit between Sonnet’s behavior and the UI. DeepSeek-TUI currently looks like a strong open-source interaction shell built around DeepSeek V4’s low cost and long context. That is a credible angle, but the failure mode is obvious: cheap model tokens do not automatically make cheap agents.

The RLM design is the important bit. A main model can dispatch up to 16 V4 Flash subtasks. That matches DeepSeek’s price profile well. The article says Flash output costs roughly one-third of Pro output, but it does not disclose input price, cache-hit price, context distribution, or a real task cost trace. I have doubts here. Parallel sub-agents can improve coverage and offload shallow work to cheaper models. They also create separate context branches, and those branches can destroy prefix-cache reuse. The article says uncached tokens cost 10 times cached tokens. That number matters more than the star count. It defines the product’s unit economics: savings come from stable prefixes; runaway cost comes from cache fragmentation.

I’ve long thought the post-2025 coding-agent divide is not “can it edit files?” It is whether the system can make state compression predictable. Cursor, Claude Code, OpenAI’s Codex CLI, Aider, and similar tools all hit the same wall: repository context is not better just because it is larger. Long context drags retrieval, attention, cache behavior, and cost into the same bottleneck. Gemini 1.5’s 1M-token window taught developers that long context is raw material, not product quality. DeepSeek-TUI defaults to filling V4’s 1M-token window. I understand the marketing value. I am not sure it is the right default. For many repos, stable indexing, symbol-level retrieval, incremental diff summaries, and disciplined prompt layout beat stuffing the window.

The smart mitigation is its compression strategy. The tool tries to preserve stable prefix content so DeepSeek’s prefix cache keeps hitting. That is a real engineering detail. Anthropic prompt caching, OpenAI cached-input pricing, and DeepSeek prefix caching all reward the same behavior: do not mutate the front of the prompt. A TUI agent naturally pollutes context. Users change goals, run Shell commands, paste logs, and branch tasks. The token stream gets messy fast. If DeepSeek-TUI can separate Git snapshots, session summaries, task plans, and tool output so the stable prefix stays stable, it is more than a UI wrapper. The article does not provide cache-hit curves or a one-hour coding-session cost sample. Without those numbers, the cost advantage remains a mechanism, not proof.

The open-source execution looks healthier. Rust, MIT license, prebuilt binaries for Linux/macOS/Windows, npm install, TUNA Cargo mirror support, Chinese README, and China-specific setup paths all fit DeepSeek’s community distribution pattern. The repo was created on January 19 and reached v0.8.8 after 37 releases. That is not a throwaway demo cadence. v0.8.2 fixed file-handle leakage in long sessions. v0.8.6 and v0.8.7 added retry countdowns for rate limits, input-history search, and running-message queue visibility. Those are user-pain fixes. Toy projects usually do not reach that layer this quickly.

I do not buy the “DeepSeek version of Claude Code” label without caveats. It drives clicks and sets the wrong expectation. Claude Code sits behind Anthropic’s model stack, product team, enterprise sales motion, billing system, and safety model. DeepSeek-TUI is an independent project. The detail that Claude authored more than 150 commits is funny and very 2026, but it also says this is still in the AI-assisted indie-tool category. It has not yet been validated across team workflows, private-repo permissions, audit logging, CI integration, enterprise proxies, or security review. YOLO mode that auto-approves Shell and file operations is great for personal hacking. Enterprise security teams will ask about sandboxing, secret redaction, command allowlists, and audit trails. The article does not disclose those protections.

Hunter Bown’s background makes for a good profile, but it does not carry the product case. Music, patent law, Shannon Labs, and “the Bell Labs of the AGI era” are narrative assets, not moats. What can matter is the depth of DeepSeek V4 adaptation: how it compresses 1M-token sessions, how RLM assigns work, how Flash and Pro switch, how cache misses are surfaced, and how MCP plus Git snapshots reduce damage. If the project ships reproducible benchmarks on the same repository and issue set, with success rate, human approvals, token cost, and cache-hit rate, it moves from GitHub heat to practitioner tool.

My stance is cautious-positive. DeepSeek-TUI is one of the first DeepSeek-native attempts to package cheap long-context models into a real coding-agent workflow. The 2.3k stars show demand, not Claude Code replacement readiness. If it keeps adding surface features, it will hit the same agent-tool swamp everyone else hits. If it treats cache cost and long-session reliability as first-class product metrics, it can become the DeepSeek ecosystem’s Aider-like tool. The key number here is not stars. It is the 10x price gap between cached and uncached tokens.

r/LocalLLaMAMay 4, 11:48

450M On-Board VLM Wildfire Detection Pipeline with Sentinel-2 and LFM2.5-VL

PauLabartaBajo shared a wildfire detection PoC using 450M LFM2.5-VL on Sentinel-2 imagery. It pairs RGB and SWIR tiles, simulates orbit with SimSat, and covers 22 fire-prone sites. The key constraint is bandwidth: on-board inference downlinks only a JSON risk profile.

Why it matters: HKR-H/K/R all pass: the story has a counterintuitive edge-VLM hook and concrete numbers. Single-source Reddit PoC and a narrow wildfire-use case keep it below the 78+ band.

May 3Sunday

r/LocalLLaMAMay 3, 20:12

LLM proxy that lets Claude Code talk to any model

DataNebula released open-source rosetta-llm, letting Claude Code call multiple providers through one gateway. It translates Anthropic Messages, OpenAI Chat, and OpenAI Responses, and round-trips encrypted reasoning via the signature field. The key detail is thinking-block fidelity for multi-turn agent prompt-cache hits.

Why it matters: HKR-H/K/R all pass, but this is a Reddit open-source tool post with no adoption, stars, or benchmark data disclosed. Score stays in the mid-weight tooling band, not 78+.

r/LocalLLaMAMay 3, 19:46

Upskill: skill registry your agent consults before it starts, with 10k+ indexed skills

Autoloops released Upskill, an open-source skill registry with 10k+ indexed skills for agents. Search combines Postgres full-text search, 1024-dim embeddings, and reranking by stars, installs, and feedback. LLM adversarial review blocked hundreds of skills at index time.

Why it matters: HKR-H/K/R pass: a useful open-source agent registry with concrete retrieval and safety mechanics. Source authority is low and adoption is unproven, so it stays in the 72–77 featured band.

Take

Upskill is betting on agent tool discovery, and I buy the direction, not the implied leap. The summary gives 10k+ skills, Postgres full-text search, 1024-dim embeddings, reranking by stars, installs, and community feedback, plus LLM adversarial review that blocked hundreds of skills at index time. That is distribution and filtering, not execution reliability.

MCP already pushed “tool availability” hard over the last year. The failure point moved to post-call verification. An agent finding Shell, browser, or cloud API skills is easy; knowing when arguments are wrong, permissions are excessive, or outputs are poisoned is the hard part. If Upskill lacks runtime sandboxing, permission scopes, and rollback logs, it becomes npm search for agents: useful, noisy, and a clean path for supply-chain risk into automated workflows.

QbitAI · WeChatMay 3, 11:16

GS-Playground Embodied AI Simulation Framework Open-Sourced with High-Throughput 3DGS Rendering

Tsinghua AIR DISCOVER Lab and partners open-sourced GS-Playground, accepted by RSS 2026. On an RTX 4090, it reports 10,000 FPS at 640×480 and 2,048 parallel scenes; a 50-humanoid benchmark reaches 1,015 FPS. The key point is coupling batch 3DGS rendering with parallel physics.

Why it matters: HKR-H/K/R pass: the open-source RSS 2026 work reports concrete RTX 4090 throughput and parallel-scene numbers. The robotics-simulation scope is narrower than a model launch, so it fits the 78–84 band.

r/LocalLLaMAMay 3, 02:11

Built a C++17 transformer from scratch with 0.83M params and CPU training

Reddit user Suspicious_Gap1121 released Quadtrix.cpp, a C++17 GPT-style model with 0.83M parameters. It uses 4 layers, 4 heads, 200d width, and a 128-character context; one CPU core trained on 31.4M characters for 76.2 minutes to 1.6371 nats val loss. The key detail is handwritten backprop for LayerNorm, attention, Q/K/V, dropout, and AdamW without PyTorch, BLAS, or autograd.

Why it matters: HKR-H/K/R all pass: the no-framework C++17 build is clickable, the training setup is specific, and local-LLM builders care about dependency-free control. It stays in the 72–77 band because it is a small personal project.

May 2Saturday

r/LocalLLaMAMay 2, 21:44

I built Semvec: A constant-cost semantic memory for LLMs, looking for testers

A developer released Semvec, replacing unbounded chat history with fixed-size semantic state. Its 48-turn benchmark claims about 76% token reduction, with identical input footprint at turn 10 and 10,000. It supports OpenAI-compatible LLMs, MCP, Claude Code, Cursor, and multi-agent shared state.

Why it matters: HKR-H/K/R all pass, but this is a Reddit self-release with author benchmarks only. Treat it as an interesting indie memory tool, not a same-day industry story.

Take

Semvec is betting against endless context growth by compressing dialogue into fixed-size semantic state. The summary gives two hard hooks: a 48-turn benchmark claims about 76% fewer tokens, and turn 10 has the same input footprint as turn 10,000. The Reddit body is blocked by 403, so the task, model, scoring, and failure cases are missing.

I like the direction, especially the OpenAI-compatible API, MCP, Claude Code, Cursor, and shared multi-agent state. That is closer to developer workflow than another generic vector-memory wrapper. The catch is brutal: fixed state always drops information. Which facts get dropped, when they get dropped, and whether the system can recover them decide whether Semvec is infrastructure or a neat demo. MemGPT, Zep, and LangGraph memory have all hit that wall.

r/LocalLLaMAMay 2, 16:12

Qwen3.6-27B hits 72 tok/s on RTX 3090 with native vLLM on Windows

Reddit user One_Slip1455 released a native Windows vLLM launcher for Qwen3.6-27B, reaching 72 tok/s on an RTX 3090. It reports 64.5 tok/s at ~25k tokens, 53.4 tok/s at 127k ctx on one GPU, and 160k ctx with PP=2 on 2×3090. The key detail is no WSL or Docker, an OpenAI-compatible endpoint, and an INT4 quant path.

Why it matters: HKR-H/K/R all pass: native Windows on an RTX 3090 is the hook, the post gives tok/s and ctx figures, and it hits local-inference cost concerns. Reddit single-source limits it to the lower featured band.

QbitAI · WeChatMay 2, 10:42

Tencent Hunyuan open-sources 440MB offline translation model, claims Google Translate quality lead

Tencent Hunyuan open-sourced Hy-MT1.5-1.8B-1.25bit, compressing a 1.8B translation model to 440MB. It supports 33 languages and 1,056 directions, with an Android demo running offline on Snapdragon 888 and 8GB RAM. The key detail is Sherry 1.25-bit quantization: 3 of every 4 weights use 1 bit and 1 is zeroed.

Why it matters: HKR-H/K/R all pass: the story has a strong offline-phone hook, concrete quantization details, and practitioner relevance around edge inference. It stays below P1 because this is a vertical translation model, not a major foundation-model release.

May 1Friday

r/LocalLLaMAMay 1, 22:53

PFlash: 10x prefill speedup over llama.cpp at 128K on an RTX 3090

PFlash cuts Qwen3.6-27B Q4_K_M 128K TTFT to 24.8s on an RTX 3090, versus 248.4s cold for llama.cpp. It uses a Qwen3-0.6B drafter to score token importance, keeps 5% of spans, and runs C++/CUDA without Python, Triton, or PyTorch. The quality caveat is clear: only NIAH single-needle passes from 32K to 128K; RULER and multi-needle results are not disclosed.

Why it matters: HKR-H/K/R all pass, but this is a single Reddit claim with quality evidence limited to single-needle NIAH 32K–128K. RULER and multi-needle results are not disclosed, so it stays at featured threshold.

Xinzhiyuan · WeChatMay 1, 13:29

Developer Builds WorldX, an AI World Generator, During a 10-Day Wedding Leave

An independent developer built WorldX in 10 days, generating a full AI world from one sentence in about 5 minutes. The system uses a 6-step map pipeline, about 30k–180k tokens per world, Tick loops, layered memory, and two-axis emotion. The key mechanism is overlay labeling plus color-difference localization for deterministic coordinates.

Why it matters: HKR-H/K/R all pass, but this is an indie project rather than a platform release, so it stays in the 72–77 band. The concrete pipeline, token range, and agent memory details justify featured.

Take

WorldX is easy to oversell as a text-to-game demo, but one engineering choice is sharp: let the model draw, then force the fuzzy image back into deterministic coordinates through overlay labels and color-difference localization. The disclosed setup has useful hooks: 10 days of building, about 5 minutes per world, 30k–180k tokens per world, a 6-step map pipeline, Tick loops, three memory layers, and two-axis emotion. That sounds less like a prompt stunt and more like scaffolding for a runnable town simulator.

I don’t buy the “world comes alive” framing yet. The WeChat body is blocked by verification, so there is no visible repo, failure rate, runtime cost, or long-horizon character consistency test here. Stanford’s Smallville was strong because the behavior logs and social loops held together. WorldX has shown coordinate grounding; it has not yet shown stable multi-agent life.

QbitAI · WeChatMay 1, 12:16

Peking University Open-Sources Unified World Model Framework for Synthesis and Reasoning Tasks

Peking University DCAI and Kuaishou Kling open-sourced OpenWorldLib for four task types: video generation, 3D modeling, VLA control, and multimodal reasoning. Its Pipeline coordinates Operator, Reasoning, Synthesis, Representation, and Memory modules, supporting forward and stream execution. The key test is whether unified interfaces cut cross-task reproduction cost.

Why it matters: HKR-H/K/R all pass: the post gives a concrete open-source framework, task scope, modules, and inference modes. It lacks benchmark results, adoption data, or major ecosystem integration, so it stays at 78.

Take

OpenWorldLib should be read as tooling first, not as a unified world model. The visible summary names four task families—video generation, 3D modeling, VLA control, and multimodal reasoning—and five modules: Operator, Reasoning, Synthesis, Representation, and Memory. Its Pipeline supports forward and stream execution. That sounds like a reproduction scaffold, not a capability jump.

I don’t buy the grand framing yet. The WeChat body is blocked by verification, so code layout, dependencies, benchmarks, and license are not disclosed. This sits near the agent-framework pattern we saw everywhere last year: clean interfaces, uneven backend reality. If OpenWorldLib can reliably plug into Kling-like video models, VLA policies, and 3D generators, it earns attention. Until then, it is mostly a bet on lowering experiment friction.

Hacker News front pageMay 1, 04:55

Show HN: Pu.sh – a full coding-agent harness in 400 lines of shell

Pu.sh ships a coding-agent harness in about 400 lines of shell, using only sh, curl, and awk. It supports Anthropic and OpenAI, 7 tools, REPL, auto-compaction, checkpoint/resume, pipe mode, and 90 no-API tests. It excludes TUI, streaming, images, OAuth, and Windows.

Why it matters: HKR-H/K/R all pass, but this is a small Show HN open-source tool, not a model or platform release. HN frontpage plus a reproducible 400-line implementation clears the featured bar.

Apr 30Thursday

r/LocalLLaMAApr 30, 01:19

inclusionAI/Ling-2.6-1T · Hugging Face

inclusionAI open-sourced Ling-2.6-1T on Hugging Face, with 1 trillion parameters. It uses MLA plus Linear Attention and Contextual Process Redundancy Suppression to reduce CoT overhead. The post cites AIME26 and SWE-bench Verified but does not disclose scores.

Why it matters: HKR-H/K/R all pass, but benchmark scores for AIME26 and SWE-bench Verified are not disclosed. A 1T open model with a named architecture mechanism fits featured, not P1.

X · @doteyApr 30, 01:02

Inside Hermes Agent's Memory System and How It Avoids OpenClaw's Pitfalls

Hermes Agent splits memory into 4 layers: prompt files, SQLite session search, skills, and optional Honcho. MEMORY.md is capped at 2,200 chars, USER.md at 1,375; writes apply after a new session or compression. The key design is cache-first: keep system prompts stable and retrieve long-tail history via tools.

Why it matters: HKR-H/K/R all pass: the OpenClaw contrast is clickable, and the memory limits/mechanisms are concrete. Single X-source tutorial, not a product release, keeps it at the featured threshold.

Take

Hermes Agent makes a very unfashionable call: persistent memory should stay tiny because the system prompt is expensive cache territory. MEMORY.md is capped at 2,200 characters, USER.md at 1,375; writes hit disk immediately but only enter the prompt after a new session or compression. That is a production constraint, not a toy limitation.

The stronger part is the split between SQLite session_search and skills. Old conversations go through full-text search, session grouping, and a cheap summarizer; procedural knowledge sits behind a skills index and loads on demand. Plenty of agent projects still dress “long-term memory” up as a vector DB feature. Hermes is colder: keep high-frequency facts resident, push long-tail history into tools. OpenClaw’s Markdown-log style reads nicer in a repo, but it ages into noise once the agent runs for real.

Apr 29Wednesday

QbitAI · WeChatApr 29, 20:44

Avenir-Web Open-Sources Web Agent Harness With 53.7% on ONLINE-MIND2WEB

UCL, Princeton, and Edinburgh open-sourced Avenir-Web, reaching 53.7% success on ONLINE-MIND2WEB. The training-free harness uses EIP, MoGE, checklists, and adaptive memory across 136 sites and 300 live tasks. The key signal: with Gemini 3 Pro, it beats Claude Computer Use 3.7 at 47.3%.

Why it matters: HKR-H/K/R all pass: the story has a sharp SOTA web-agent hook, concrete benchmark numbers, and practitioner resonance around agent reliability. This is a strong open-source research release, not a major lab model launch, so 82 fits the 78–84 band.

r/LocalLLaMAApr 29, 17:55

SenseNova-U1: Unifying Multimodal Understanding and Generation with NEO-Unify Architecture

SenseNova released SenseNova-U1 with 4 MoT multimodal models. The post lists 8B and A3B variants with GitHub and HuggingFace weight links. The key claim is a monolithic architecture instead of adapters; benchmarks are not disclosed.

Why it matters: HKR-H/K/R pass: open weights, 4 MoT multimodal models, and a single architecture are concrete. Benchmarks are not disclosed, and the source is Reddit, so this stays in the 72–77 featured-threshold band.

X · @doteyApr 29, 08:06

Microsoft VibeVoice-ASR tested on Mac for a one-hour podcast

Simon Willison ran 4-bit VibeVoice-ASR on an M5 Max MacBook Pro and transcribed a one-hour podcast in 8m45s. The 9B MIT-licensed model supports 60-minute audio, 50+ languages, and structured speaker output. Memory is the constraint: prefill peaked at 61.5GB, making 32GB laptops impractical.

Why it matters: HKR-H/K/R all pass: Simon Willison’s local test gives speed, parameter size, and memory peak that practitioners can act on. It is a single benchmark, not a fresh model launch, so it stays at the featured threshold.

r/LocalLLaMAApr 29, 02:27

XiaomiMiMo MiMo-V2.5: Sparse MoE with 310B total and 15B activated parameters

XiaomiMiMo shared MiMo-V2.5 with 310B total parameters and 15B activated parameters. The post only links Hugging Face and says it runs on more “human” configs than its larger sibling. It does not disclose VRAM needs, quantization, or benchmarks.

Why it matters: HKR passes: the 310B/15B Sparse MoE hook is concrete and relevant to local deployment. Detail is thin: the post links Hugging Face but gives no VRAM, quantization, or benchmarks, so it stays near the featured threshold.

X · @doteyApr 29, 01:30

AI terminal tool Warp open-sources client code with OpenAI as founding sponsor

Warp open-sourced its client code under AGPL; only the client is open, while server code stays closed. The Rust terminal has 700,000+ developers, and its Oz cloud AI handles coding, planning, and tests. The key signal is its AI-first contribution workflow.

Why it matters: HKR-H/K/R all pass: the OpenAI sponsorship hook, AGPL/client-only detail, and 700K-developer signal are concrete. This is a strong dev-tool open-source update, not a major model or capability release.

Take

Warp open-sourced its client under AGPL, kept the server closed, and disclosed 700,000 developers plus OpenAI as founding sponsor. My read: this is less an open-source conversion than a trust repair job for an AI terminal. A terminal sits next to shell history, secrets, repos, deploy commands, containers, and cloud credentials. Once an agent starts acting inside that surface, a closed client becomes a harder sell.

The AGPL choice is the first tell. If Warp had picked MIT or Apache 2.0, it would be inviting broad commercial reuse. AGPL keeps more pressure on derivative networked services. But Warp only opened the client, while Oz, its cloud AI platform, stays behind the curtain. That boundary matters. Users can inspect the interface, local terminal behavior, and some client logic. They cannot inspect the routing stack, cloud execution path, telemetry handling, account system, or model-call chain. The article does not disclose how much agent code is actually in the repo. It also does not disclose Oz sandboxing, log retention, permissioning, or data isolation. For an AI terminal, those are not footnotes; they are the product’s risk surface.

The closest comparison is VS Code’s split between open-source core and Microsoft-controlled distribution pieces. Cursor sits on the other side as a closed IDE that sells speed and model integration. Warp is trying a middle position: open client, controlled cloud layer, commercial AI workflow. That is a valid model. I just do not buy any framing that treats this as full openness. A forked Warp client without Oz, automatic routing, team sync, and hosted agent execution is not the same product. The article does not show whether those cloud pieces have a reproducible local path.

OpenAI’s sponsorship is the sharpest part. OpenAI has been fighting for the coding surface through Codex, ChatGPT coding workflows, IDE integrations, and CLI usage. Warp is not just another devtool logo in that fight. It sits at the command layer, where builds, tests, git operations, package managers, Docker, Kubernetes, and cloud CLIs already happen. If agentic coding moves from editor chat into shell execution, the terminal becomes a control point. OpenAI sponsoring Warp’s open-source repo gives it a seat in that experiment without needing to own the terminal outright.

Warp also supports Claude Code, Codex, Gemini CLI, and open models including Kimi, MiniMax, and Qwen. The automatic routing mode tells me Warp does not want to be a model company. It wants to be the console between models and command-line work. That makes sense. Continue, Aider, and OpenHands attack the coding loop from different angles: repo-native pair programming, autonomous dev environments, or IDE-adjacent flows. Warp starts from an existing daily habit. The migration cost is low. The ceiling is messy. Once an agent edits files, runs tests, explains failures, and rolls back patches, a plain terminal is not enough. The article says Warp now has diff views and a file tree, which is basically an admission that serious agent work drags the terminal toward IDE territory.

I am skeptical of the “humans set direction, AI does the work” contribution story. Open-source maintenance has never been limited by raw patch generation. The hard parts are architecture taste, saying no, cross-platform bugs, release hygiene, regression control, and review load. AI can increase pull request volume while making maintainer work more painful. The article gives no merge rate, test pass rate, rollback rate, review staffing, or percentage of Oz-authored contributions accepted. Without those numbers, this is a workflow proposal, not proof of a better open-source model.

AGPL also creates enterprise friction. Many company legal teams treat AGPL as higher-risk than permissive licenses because network-use clauses trigger review. Warp’s users often work on corporate machines. Opening the client reduces security anxiety, but AGPL can slow procurement. If Warp wants individual developer adoption and enterprise revenue, it needs crisp rules around binaries, plugins, internal modifications, cloud sync, and commercial licensing. The article does not disclose those terms.

So I would not file this as “Warp finally went open source.” I would file it as: Warp is turning the terminal into an agent workbench, using an open client to lower the trust barrier, and keeping the server closed to preserve leverage. OpenAI’s role makes this a platform experiment. If the May-June roadmap shows external ideas flowing through Oz planning, code generation, test execution, and merged PRs, then the collaboration claim gets stronger. For now, Warp has opened the door far enough to ask developers for shell-level trust.

Apr 28Tuesday

QbitAI · WeChatApr 28, 20:56

Xiaomi open-sources MiMo-V2.5 series; Pro builds a macOS-like desktop in 4 hours

Xiaomi open-sourced MiMo-V2.5 weights, covering Pro Agent, multimodal base, TTS, and ASR models. MiMo-V2.5-Pro built a 54-app macOS-like desktop in 4 hours without human takeover; it scored 233/233 on SysY with 672 tool calls in 4.3 hours. Key details for practitioners are the 1M context, 100T-token program, and free Agent-framework access.

Why it matters: HKR-H/K/R all pass: Xiaomi open-sourced MiMo-V2.5 weights with concrete agent and coding-task numbers. Domestic flagship model release bump puts it in the must-write same-day band.

Take

Xiaomi open-sourced MiMo-V2.5 weights with 1M context, a 100T-token program, and a 4.3-hour SysY run. My read is split: the engineering demos are stronger than a routine Chinese model launch, but the article jumps from demos to “top global model table” far too quickly.

The concrete claims are not small. MiMo-V2.5 includes MiMo-V2.5-Pro, a multimodal base model, TTS, and ASR. MiMo-V2.5-Pro reportedly built a macOS-like desktop in 4 hours without human takeover. The demo had 54 apps, 68 components, React 18, TypeScript, Zustand, Tailwind CSS, and Vite. It also completed the Peking University SysY compiler task in 4.3 hours, using 672 tool calls, and scored 233/233. The article says ClawEval used about 70K tokens per trajectory for a 64% Pass³ rate, while Claude Opus 4.6, Gemini 3.1 Pro, and GPT-5.4 used 120K to 180K tokens. If that holds under outside replication, it matters. Agent cost is not just model pricing; it is tool loops, retries, context growth, and failed trajectories.

The gaps are equally large. The article does not disclose parameter count, MoE layout, training-token count, RL recipe, tool sandbox, sampling settings, failed runs, average pass@k, or repository history for the macOS demo. A 54-app desktop sounds flashy, but static app shells and maintainable software are different artifacts. The claim that the XcodeApp includes a “real browsable web engine” needs inspection. Is that an iframe wrapper, a browser API simulation, or an actual browser implementation? The body does not say. For practitioners, that difference moves the demo from a weekend build to a serious systems result.

The SysY result is the strongest number in the piece. Compiler tasks test long-horizon consistency better than front-end demos. Lexing, parsing, IR generation, RISC-V backend work, and optimization all interfere with each other. A model surviving 672 tool calls without derailing suggests Xiaomi trained or engineered around state management and error recovery. I would compare this to SWE-bench Verified-style agent runs: plenty of models write a good patch for one issue, then start overwriting themselves after 20 to 50 steps when tools, files, and context stack up. If MiMo-V2.5-Pro is reliably stable past 600 turns, that is not copywriting. That is model policy plus agent runtime doing real work.

I care even more about the 70K-token efficiency claim. Agent token reduction usually comes from one of three places: better compressed planning, more aggressive context trimming, or a tool-result summarizer. The first is genuinely valuable. The second hides failure modes. The third depends heavily on the surrounding framework. The article only says “token efficiency.” It does not say whether this comes from MiMo-V2.5-Pro itself or from Xiaomi’s agent framework compressing trajectories. Xiaomi also announced free access for emerging agent frameworks, which makes benchmarking messier. Are we measuring the open model, or a product stack with policy, memory, and tool routing layered around it?

Externally, Xiaomi’s move feels closer to Qwen and DeepSeek distribution playbooks than a pure Claude/GPT benchmark chase. Qwen gained developer mindshare through open weights, many model sizes, and tool coverage. DeepSeek won trust with cheap API economics and reproducible inference cost. Moonshot, Zhipu, and MiniMax have leaned more on products and APIs. Xiaomi has a different asset base: phones, cars, IoT, voice, and OS-level distribution. Shipping TTS, ASR, a multimodal base, and an agent model together makes sense for Xiaomi. The company wants models that can sit inside phones, vehicles, home devices, and developer workflows, not just collect GitHub stars.

The audio claims need caution. The article says MiMo-V2.5-TTS supports text-described voices and zero-shot cloning without reference audio. It says ASR reaches Chinese-English SOTA and handles Cantonese, Sichuanese, Wu, and Minnan. But the “99.999%” recognition number comes from one Cantonese test, with no disclosed duration, noise condition, accent spread, labeling standard, or dataset. ASR is already crowded: Whisper, SenseVoice, Paraformer, and FunASR have made clean speech less impressive. The hard cases are overlapping speakers, far-field audio, music beds, mixed dialects, and low-bitrate telephone speech. The article gives experience notes, not a proper evaluation.

The 100T-token giveaway is the sharpest commercial move. It gives agent builders a reason to test a new base. OpenAI and Anthropic have strong developer habits. Qwen already owns a lot of open-source inertia. A later entrant needs three things at once: good enough quality, low enough cost, and low migration friction. Xiaomi cut Pro credits from 4x to 2x, standard from 2x to 1x, priced 1M and 256K context at the same credit multiplier, and added a 20% night discount from 00:00 to 08:00 Beijing time. Those details matter more than the “global top-tier” language. Agent developers follow invoices faster than slogans.

My biggest problem is the source layer. This is a media experience piece, not a system card and not an independent benchmark report. It mentions Claude Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, but gives no table, benchmark version, evaluator, confidence interval, or reproduction package. The title says the weights are open-sourced, but the body does not disclose the license. Commercial use, acceptable-use limits, redistribution terms, and training-data posture matter more for enterprise adoption than a demo video. Open weights with a restrictive license are downloadable, not freely deployable.

So my stance is simple. MiMo-V2.5 is Xiaomi’s first AI release that looks like a complete platform bet: agent, long context, voice, open weights, and developer subsidy in one package. The article pushes every claim to maximum volume, which makes me wait for third-party replication. I need three things before upgrading my view: public SysY and ClawEval scripts, the full macOS-demo repository trajectory, and clear license terms. If those hold up, Xiaomi becomes a serious player in the Chinese open agent stack. For now, I accept the release has force. I do not yet seat it beside Claude and GPT.

QbitAI · WeChatApr 28, 20:56

Open-source SenseNova-U1 unifies image understanding and generation

SenseTime open-sourced two SenseNova-U1 models: an 8B version and a 38B-total MoE version using NEO-unify. The architecture removes VE and VAE, processes pixels directly, and generates 2048×2048 images in about 9 seconds on one H100/H200 node. The key item is interleaved text-image reasoning; 32K context, long-text rendering, and beta interleaved creation remain limits.

Why it matters: HKR-H/K/R all pass: the architecture hook is concrete, the post gives model sizes and latency, and open multimodal work matters to builders. It stays in 78–84 because it is not a top-tier general-model launch.

Take

SenseNova-U1’s useful bet is not the open-sourced 8B and 38B-total MoE weights; it is the removal of VE/VAE and the attempt to force understanding and generation through one pixel path. The hard hooks are specific: NEO-unify takes pixels in and emits pixels out, one H100/H200 node produces a 2048×2048 image in about 9 seconds, and context is 32K. The WeChat body is blocked by verification, so training data, license terms, and benchmark setup are not available.

I like the direction, but I don’t buy the victory lap yet. Janus-Pro already showed that “unified multimodal” makes a clean headline; the pain lives in text rendering, localized edits, and long interleaved image-text chains. U1 labels long-text rendering and continuous interleaved creation as beta, which is the tell: this is a research-shaped release, not a clean replacement for separate diffusion pipelines.

Hacker News front pageApr 28, 20:16

Xiaomi releases MiMo-v2.5 weights with strong coding and agent benchmarks

Xiaomi released MiMo-v2.5 family weights; the title cites strong coding and agent benchmarks. The RSS body only lists URLs, 13 HN points and 2 comments; the post does not disclose size, license, or scores.

Why it matters: HKR-H/K/R pass because a Xiaomi coding/agent weights release is concrete and practitioner-relevant. Sparse sourcing holds it near the featured floor: no parameters, license, or benchmark numbers are disclosed.

Take

MiMo-V2.5-Pro has the right headline and a thin evidence trail. The article confirms an April 23, 2026 release, open weights, and a coding focus; the feed shows only 13 Hacker News points and 2 comments. It gives no parameter count, license, context length, SWE-bench score, agent benchmark setup, or evaluation harness. Using “right next to Claude Opus 4.6” as the hook borrows frontier-model credibility without reproducible conditions.

Xiaomi does have a plausible reason to ship this: phones, IoT, and cars all need local coding-ish agents and tool use. But the open-model bar is now set by DeepSeek, Qwen, and Llama releases with weights plus usable evals and commercial terms. A weight drop alone is a teaser; the missing license and benchmark recipe decide whether practitioners can use it.

X · @op7418Apr 28, 10:42

Xiaomi open-sources the MiMo-V2.5 model series

Xiaomi open-sourced the MiMo-V2.5 model series under the MIT license for commercial use, retraining, and fine-tuning. It also launched Orbit 100T Token, offering approved AI builders up to 1.6B credits worth 659 yuan. Agent framework teams can apply for free MiMo token access; the post does not disclose model size or benchmark results.

Why it matters: HKR-H/K/R all pass: Xiaomi MiMo-V2.5 open source, MIT terms, and Orbit 100T credits matter to builders. Missing params and benchmarks keep it in the 78–84 band, below P1.

Take

Xiaomi open-sourced the full MiMo-V2.5 series under the MIT license. That is the clearest fact here. MIT allows commercial use, retraining, and fine-tuning without extra permission. For a phone, EV, and IoT company, this reads less like a pure model launch and more like a developer funnel. The post does not disclose parameter counts, context length, API pricing, SWE-bench, Aider, LiveCodeBench, or Chinese evals. The title says the full series is open-sourced; the body does not show the technical receipts.

My read is blunt: Xiaomi is not proving that MiMo-V2.5 beats DeepSeek, Qwen, or Kimi on capability. It is lowering adoption friction first. The Orbit 100T Token plan offers approved AI builders up to 1.6B credits, listed at 659 yuan. That number is catchy, but the body does not define the credit-to-token conversion, input-output split, rate limits, eligible models, or expiry rules. Without those conditions, 1.6B credits only tells us Xiaomi is willing to subsidize usage. It does not tell us whether the serving economics work.

Qwen is the obvious comparison. Alibaba’s open model strategy worked because it paired permissive licensing with parameter tiers, quantized variants, inference integrations, public benchmarks, and a steady community loop. DeepSeek-R1 hit because reasoning behavior, low API pricing, open weights, and distilled models arrived together. Xiaomi’s disclosed package is thinner. It gives the ecosystem an opening, but not enough evidence for a serious team to route production traffic. Agent framework teams care about latency stability, function-calling reliability, long-context cost, concurrency limits, and failure modes. A large token pool does not answer those questions.

Honestly, the agent ecosystem angle is the part I take more seriously. Xiaomi’s advantage is not model-lab prestige. It is distribution across phones, cars, home devices, and HyperOS. If MiMo becomes the model layer for device control, in-car assistants, household automation, and cross-device workflows, Xiaomi has a deployment surface that many standalone model companies lack. But the post leaves the key facts blank. It does not say whether MiMo-V2.5 supports tool use, structured output, multimodal inputs, on-device variants, or multiple model sizes. Without that, the agent story is a recruitment pitch, not an architecture claim.

I do not buy “fully open-source” as a sufficient signal in 2026. The bar has moved. A permissive license without a model card, reproducible evals, inference recipes, and clear API pricing will not move careful builders off their current stack. Xiaomi made a useful move, but the useful part is channel plus subsidy, not demonstrated model superiority. Once it publishes weights, evals, serving terms, and integration details, MiMo-V2.5 can be compared on the same board as Qwen and DeepSeek. Right now, Xiaomi opened the door. It has not shown what is inside.

r/LocalLLaMAApr 28, 04:07

Microsoft Presents TRELLIS.2: Open-Source 4B Image-to-3D Model

Microsoft’s title says TRELLIS.2 is an open-source 4B image-to-3D model. The title lists 1536³ PBR assets, native 3D VAEs, and 16× spatial compression; the Reddit body is blocked by 403 and discloses no license or benchmarks.

Why it matters: HKR-H/K/R pass: 4B, 1536³, 16× compression, and open source are concrete. Reddit 403 leaves no paper, license, benchmark, or official link, so the score sits at the featured floor.

Apr 27Monday

Hacker News front pageApr 27, 21:55

Show HN: Utilyze — an open-source GPU monitoring tool claiming higher accuracy than nvtop

Systalyze open-sourced Utilyze to measure real GPU compute efficiency in production, with negligible overhead claimed. The post says nvidia-smi and nvtop only check whether any kernel runs during the sampling window; an H100 has 132 SMs and 17,424 cores. The key issue is real throughput headroom, not binary utilization dashboards.

Why it matters: HKR-H/K/R all pass: the hook is sharp, the post explains the sampling flaw, and GPU waste is a real practitioner nerve. Unknown vendor and single-tool scope keep it in the 72–77 band.

Hacker News front pageApr 27, 20:35

Show HN: OSS Agent Dirac topped TerminalBench on Gemini-3-flash-preview

Dirac-run released Dirac and says it topped TerminalBench using Gemini-3-flash-preview. The repo claims 50-80% lower API costs via Hash Anchored edits, parallel operations, and AST manipulation; the post does not disclose full scores.

Why it matters: HKR-H/K/R all pass: an OSS coding agent claims a TerminalBench lead with cost and mechanism details. Held to 78 because the post relies on repo claims and lacks full leaderboard scores or reproduction logs.

OpenAI NewsApr 27, 08:00

An Open-Source Spec for Orchestration: Symphony

OpenAI released Symphony, an open-source spec for Codex orchestration. The RSS snippet says it turns issue trackers into always-on agent systems; the post does not disclose spec details, license, APIs, or benchmarks.

Why it matters: HKR-H and HKR-R pass: an OpenAI open-source Codex orchestration spec is relevant to agent workflows. HKR-K is weak because license, interfaces, and reproducible mechanics are not disclosed.

Apr 25Saturday

Hacker News front pageApr 25, 09:24

Open-source memory layer Stash lets any AI agent do what Claude.ai and ChatGPT memory can do

Stash released an open-source persistent memory layer for AI agents, exposing 28 MCP tools and a 6-stage pipeline for long-term memory. The page says it uses PostgreSQL plus pgvector and hierarchical namespaces to separate user, project, and self memory. The real point is a portable memory layer, not the headline claim about matching ChatGPT or Claude.ai.

Why it matters: HKR-H/K/R all pass: the hook is portable long-term memory for any agent, and the page gives concrete architecture details. The score stays in the low featured band because this is an indie OSS infrastructure launch, not a major lab or platform release.

Take

Stash is aiming at the right layer: memory should sit outside the model and travel across agents. The concrete pieces are good: 28 MCP tools, a 6-stage pipeline, PostgreSQL plus pgvector, and hierarchical namespaces like `/users`, `/projects`, and `/self`. That is cleaner than shoving every past session into a larger context window.

I don’t buy the RAG contrast on the page. It paints RAG as a file search box, while many teams already run event logs, summary memory, vector recall, and profile stores together. Stash’s value is the portable protocol and schema, not the “mind that grows” language. The missing parts are the dangerous ones: forgetting policy, contradiction handling, privacy boundaries, and write permissions. Memory failures are worse than retrieval misses because agents reuse bad memories as settled facts.

Apr 23Thursday

QbitAI · WeChatApr 23, 20:43

Qwen3.6-27B open-weights, beats its 397B flagship predecessor on agentic coding

Qwen released Qwen3.6-27B and says it beats Qwen3.5-397B on 4 agentic coding benchmarks with about 1/15 the parameters. The post cites SkillsBench rising from 30.0 to 48.2, GPQA Diamond at 87.8, and AIME26 at 94.1; it uses a dense architecture, Thinking Preservation, and Gated DeltaNet, with weights on Hugging Face and ModelScope.

Why it matters: This is a substantive Qwen open-source model release with concrete agent-coding and reasoning scores, so HKR-H/K/R all pass. I keep it at 84, not higher, because the post gives strong benchmarks but no pricing, context window, or independent reproduction yet.

Take

Qwen3.6-27B beat Qwen3.5-397B on four agentic coding benchmarks with roughly 1/15 the parameters. That fact is already strong. My read is stronger: Alibaba is not just shipping a better open-weight model here. It is publicly conceding that, for a lot of coding-agent work in 2026, training recipe, task targeting, and inference-time behavior now matter more than raw parameter mass.

The post gives a few numbers that are concrete enough to take seriously. SkillsBench goes from 30.0 to 48.2, a gain of 18.2 points. GPQA Diamond is 87.8. AIME26 is 94.1. It also says the model was optimized for repository understanding, cross-file edits, frontend generation, and terminal command execution. That all tracks with where coding models have been improving. But I still have some pushback here: the article does not disclose which four agentic coding benchmarks were used, how tool access was configured, whether pass@k was used, what context length was allowed, or whether the comparison controlled for reasoning budget and agent loop depth. Anyone who has run coding evals knows those settings can move a leaderboard a lot. So I do not read “comprehensively surpasses” as settled. I read it as a promising vendor-reported result.

The part I do buy is the dense architecture choice. Qwen3.5-397B as an MoE made for a great flagship narrative, but open deployment of giant MoE models has had the same practical problem for a while: far fewer people can run them cleanly than can praise them online. Once you put a model into an actual coding-agent loop, with long context, repeated tool calls, multiple diffs, retries, and ranking steps, latency variance and memory management start to matter as much as benchmark scores. A dense 27B model is simply easier to operationalize: quantization is easier, KV cache behavior is more predictable, local serving is less painful, and end-to-end agent runs tend to be more stable. In practice, finishing a 30-minute repo task reliably matters more than winning a single-turn benchmark by a few points.

This is not unique to Qwen. Open models over the last year have kept reinforcing the same pattern: smaller, denser, task-shaped models often beat giant generalist bases once you care about actual developer workflows. DeepSeek helped make that obvious when reasoning and distillation gains started compressing capabilities that used to require much larger systems. On the closed side, Anthropic’s coding workflow and OpenAI’s coding stack have also been optimizing for the same thing: fewer failures inside the tool loop, fewer context drops, less wasted iteration. The “Thinking Preservation” term in Qwen’s post fits that direction. I have not seen enough detail to know whether it is meaningfully new or just a branded way of retaining planning state across turns. The article does not say.

I am less convinced by the multimodal pitch in the snippet. It says native text, image, and video support, then gives a children’s picture book example. For a coding model, that is not the test that matters. What matters is whether it can read UI screenshots, stack traces, dashboards, design mocks, and structured documents, then make grounded code changes. The body gives no evals for OCR-heavy tasks, GUI grounding, or code edits from visual inputs, so I would not count multimodality as proven from this write-up.

There is also a basic but important omission: the snippet says weights are on Hugging Face and ModelScope, but it does not disclose license terms, context window, serving recommendations, latency, throughput, or post-quantization performance. For practitioners, those details are often more important than the release itself. If the license is restrictive, this lands differently from what people call “real open.” If the context and tool-call costs are not well controlled, the deployment advantage of 27B shrinks fast once it sits inside an agent runtime.

So my take is pretty simple. Qwen3.6-27B looks like a pragmatic correction. It does not prove that giant models are obsolete. It proves that for coding agents, a model that is easier to deploy, cheaper to run, and less fragile over long tasks can beat a much larger flagship where it counts. The embarrassing part is not that 397B lost to 27B. The embarrassing part is how long the field kept treating raw parameter size as a sufficient story. I would wait for two things before taking the victory lap: public results on SWE-bench Verified or LiveCodeBench-style setups, and community reports from plugging it into real coding agents for long-horizon tasks. Until then, this is a strong self-reported release, not a closed case.

Xinzhiyuan · WeChatApr 23, 12:10

Zhejiang University open-sources multi-agent evolution system OpenStory: Sun Wukong turns the Grand View Garden into an empty city

Zhejiang University open-sourced OpenStory, a multi-agent narrative system, and inserted a Sun Wukong agent into a 1:1 Dream of the Red Chamber sandbox; within minutes, agents fled the scene. The memory module broadcast “Sun Wukong killed innocents,” fear overrode daily logic, and Wang Xifeng’s physical removal cascaded into an empty Grand View Garden. What matters is the fragility of memory and consensus links; the post does not disclose the base models, metrics, or reproducible setup.

Why it matters: HKR-H/K/R all pass: the stress test is vivid, and the story includes a specific memory-broadcast failure mode with clear agent-safety relevance. Missing model details, metrics, and reproducible setup keep it in the good-featured band, not 85+.

Apr 22Wednesday

Hacker News front pageApr 22, 21:19

Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

Qwen released the open-weight 27B dense model Qwen3.6-27B and made it available in Qwen Studio. It scores 77.2 on SWE-bench Verified vs. 76.2 for Qwen3.5-397B-A17B, and 59.3 on Terminal-Bench 2.0 under a 256K context and 3-hour timeout. The real takeaway is deployment: this is not a larger MoE, but a denser 27B model with stronger coding results.

Why it matters: Qwen3.6-27B is a substantive flagship-model release with open weights, concrete coding benchmarks, and a practical dense-deployment angle. HKR-H/K/R all pass, and per policy a major Chinese model launch should score on par with an equivalent US-lab release.

Take

Qwen shipped Qwen3.6-27B at 27B dense parameters and posted 77.2 on SWE-bench Verified, beating Qwen3.5-397B-A17B at 76.2. My read is that this is less about one more benchmark win and more about Qwen correcting a structural problem in open models: the field spent a year celebrating total parameters and MoE scale, while deployment teams kept eating the routing, memory, and serving mess.

I’ve felt for a while that open-source coding models did not need another “bigger total parameter” story. They needed a model that keeps agentic coding near the top tier without dragging production into MoE-specific pain. A 27B dense model sits right in that gap. The comparison table makes that pretty clear. Against Gemma4-31B, Qwen3.6-27B is up 25.2 points on SWE-bench Verified and 16.4 on Terminal-Bench 2.0. That is not noise. Against Qwen3.6-35B-A3B, a lighter MoE sibling, it also leads across the core coding-agent rows. That pattern usually means the gain did not come from “more total model” alone. It looks like Qwen put serious work into post-training, tool-use trajectories, and long-horizon agent stability.

That said, I’m not fully buying the packaging yet, because the article gives benchmark scores without giving the deployment bill. SWE-bench uses an internal agent scaffold with bash and file-edit tools at 200K context. Terminal-Bench 2.0 uses 256K context, a 3-hour timeout, 32 CPU cores, 48GB RAM, and averages five runs. Those settings are fine for capability extraction. They are not a normal production profile for most teams. If you are building CI agents, IDE copilots, or repository maintenance bots, you usually do not budget three hours per task, and you do not casually run 256K context as the default. The practical questions are latency per successful patch, cost per resolved issue, retry rate, and degradation over long sessions. The excerpt does not disclose those numbers.

I also want to be picky about the phrase “open source.” The post clearly says open weights and links to Hugging Face and ModelScope, which is good. But in the excerpt provided here, I do not see the license terms, commercial-use restrictions, derivative requirements, or a fuller disclosure of training data boundaries. By 2025 this distinction was already a recurring mess. Plenty of companies called something open source when they really meant downloadable weights under a restrictive license. Until the license is visible, I would not treat this as equivalent to fully permissive open-source distribution.

The bigger significance is where this lands against closed coding agents. Closed models still have an edge, but the gap here is no longer huge. Qwen3.6-27B scores 77.2 on SWE-bench Verified, while the table shows Claude 4.5 Opus at 80.9. That is a 3.7-point gap. On Terminal-Bench 2.0, Qwen matches Opus at 59.3. For many teams, that changes the buying decision. Once the capability gap narrows to a few points, the deciding factors become privacy, self-hosting, customization of the agent scaffold, and whether you want to pay closed-model margins for the last bit of success rate.

There is also some useful context outside the article. Over the last year, a lot of open-model teams leaned into MoE because it looked better in training economics and on marketing slides. But serving is where the pain shows up: expert routing, interconnect traffic, KV-cache behavior, continuous batching, and performance collapse on mixed workloads. I have seen teams get excited in controlled evals, then watch throughput fall apart once real long-tail requests hit production. Dense 27B has a very ordinary virtue: it is easier to make stable. You may not get the absolute cheapest token in every setup, but you are much more likely to get predictable behavior. For most developers who are not hyperscalers, that matters more than a giant total-parameter number.

I do have pushback on the benchmark presentation. Qwen mixes public benchmarks with modified and internal ones in the same narrative frame: refined SWE-bench Pro, internal QwenWebBench, and QwenClawBench with a claimed real-user distribution. That is not illegitimate, but those results should not all get the same weight. Publicly reproducible benchmarks deserve more trust than internal task sets and custom harnesses. The hardest evidence here is still the public-facing coding numbers: 77.2 on SWE-bench Verified, 59.3 on Terminal-Bench 2.0, and the fact that it beats Qwen’s own previous 397B total-parameter flagship. The rest needs community reruns.

So my take is simple. This is not a cute “small model punches above its weight” story. It is Qwen shifting the center of gravity from parameter theater back to engineering usability. I buy that direction. I do not yet buy every implication in the blog. Two follow-ups will decide how important this release becomes: real community numbers on throughput, memory, and quantized performance; and a license that does not play word games. If both check out, this becomes one of the most deployable open coding models of the year. If either fails, it stays a very good benchmark post.

Apr 20Monday

X · @Yuchenj_UWApr 20, 23:41

Kimi K2.6 is open-source

Kimi K2.6 is now open source, and the RSS snippet says it scored 58.6 on SWE-Bench Pro. The snippet also says it beat GPT-5.4 xhigh and Claude Opus 4.6 max effort. What matters is reproducibility; the post does not disclose weights, license, or eval setup.

Why it matters: All three HKR axes land: the open-source release is a strong hook, the SWE-Bench Pro 58.6 claim is testable, and the open-vs-closed coding race resonates. I keep it at 81 because the post appears title-level only; weights, license, and eval conditions are not disclosed.

Take

Kimi K2.6 put out two hard claims at once: it is “open source,” and it scored 58.6 on SWE-Bench Pro, ahead of GPT-5.4 xhigh and Claude Opus 4.6 max effort. With only an RSS snippet available, I’m not treating that as settled. My first reaction is not hype but pause: for a release like this, three things decide whether the claim matters at all—weights, license, and eval setup. None of those are disclosed here.

Honestly, code benchmarks have trained the field to be skeptical for good reason. A 58.6 on SWE-Bench Pro is a serious number if it was produced under a standard, reproducible harness. It tells you much less if the model used a custom agent scaffold, heavy test-time search, wide sampling, hidden tool privileges, or a different issue subset. I couldn’t find the repo version, patch-validation flow, run budget, or whether this was single-run versus best-of-N. The snippet names GPT-5.4 xhigh and Claude Opus 4.6 max effort, but effort tiers are budget-sensitive by design. If token spend, tool access, and retries are not aligned, a headline “beat” is not enough.

This is where open-source credibility gets earned. When Meta shipped Llama 3, the community could at least grab weights and start poking holes quickly. When DeepSeek-R1 hit, the release spread because people had artifacts to test the same day: weights, papers, distillation pathways, concrete implementation clues. That is what turns a benchmark post into engineering reality. If Kimi K2.6 is truly open source, I want a weights link, a real license, model card details, context window, tokenizer notes, and enough eval disclosure that another lab can reproduce the 58.6 within a narrow band.

I also don’t fully buy the “keep the open-vs-closed gap at six months” framing. That plays well on X, but developers do not deploy a slogan. They deploy something they can legally use, benchmark under their own constraints, and integrate into CI without mystery behavior. A model that trails a frontier closed model by six months but ships with solid licensing and reproducible evals is often more valuable than a flashier claim with missing artifacts.

So my read is simple: this looks like a strong signal, not a completed proof. The title gives us “open source” and 58.6. The body does not disclose the weight location, license terms, context length, inference cost, or benchmark harness. Until those show up, I’d log this as potentially important, but not yet bankable.

r/LocalLLaMAApr 20, 23:05

Training LoRA adapters for Apple's on-device 3B model on a free Colab T4 and a Mac

The author built a QLoRA pipeline for Apple’s on-device 3B model, cutting training needs from about 24GB to about 1GB RAM and 5GB GPU, enough for a free Colab T4 or a 24GB Mac. The post says A100 LoRA, T4 QLoRA, and Mac QLoRA adapters perform about the same, raising accuracy from about 40% to 75%, or 86% with retrieval; it also reports a confirmed Apple bug that writes a hidden ~160MB cache copy per CLI call, reaching 269GB over ~300 runs.

Why it matters: A named first-person experiment with reproducible memory and accuracy numbers clears HKR-H/K/R and beats routine tutorial posts. The score stays below the 85 band because this is a single Reddit post with limited source authority and a narrow benchmark scope.

r/LocalLLaMAApr 20, 15:10

TRELLIS.2 image-to-3D now runs on Mac (Apple Silicon) with no NVIDIA GPU required

A developer ported Microsoft's TRELLIS.2 to Apple Silicon and reports generating ~400K-vertex meshes from one photo in about 3.5 minutes on an M4 Pro with 24GB. The port replaces five CUDA-only extensions with PyTorch MPS and custom backends; texture baking takes about 18 seconds, removing the NVIDIA and cloud requirement.

Why it matters: This is a community port, not an official release, but HKR-H/K/R all pass: the hook is NVIDIA-free image-to-3D on Apple Silicon, and the post includes testable details (M4 Pro 24GB, ~400k vertices, 3.5 minutes, 5 CUDA-extension rewrites). Reddit-level source authority keeps it in

Take

A developer replaced five CUDA-only dependencies and got Microsoft’s TRELLIS.2 running on an M4 Pro with 24GB, producing roughly 400K-vertex meshes from one image in about 3.5 minutes, with texture baking in about 18 seconds. My take is simple: the point is not “Mac can do it too.” The point is that a CUDA-locked 3D generation stack just got peeled apart, dependency by dependency, and that changes where the barrier really sits.

The interesting part here is architectural, not brand tribalism. TRELLIS.2 originally depended on five CUDA-only compiled extensions: flex_gemm, flash_attn, o_voxel, cumesh, and nvdiffrast. The port swaps those for pure PyTorch sparse 3D convolution, Python mesh extraction with spatial hashing, SDPA attention, and MPS-friendly sampling. That tells you something important about a lot of “GPU-required” open-source AI software: part of the lock-in is not raw compute need, it is the extension stack that assumed CUDA as the operating system for AI. Once someone does the ugly systems work, a surprising amount of capability becomes merely slower, not impossible.

I’ve felt for a while that local multimodal tooling was following the same pattern image generation followed in 2023 and small-code models followed in 2024. First, everything looked data-center-native. Then people started removing hard CUDA assumptions. Then the center of gravity shifted from “best benchmark” to “good enough on hardware people already own.” This port fits that pattern. You can compare it to how Stable Diffusion on Apple Silicon went from novelty to usable after the community stopped waiting for first-party perfection and just rewired kernels, schedulers, and memory paths. Same with llama.cpp on Metal: the strategic value was never top throughput. It was distribution.

That is why I think this matters more than the raw 3.5-minute runtime. For an artist, indie game developer, CAD hobbyist, or robotics tinkerer, 3.5 minutes offline with zero cloud cost is a different product category from seconds on an H100 behind an API. Those are not the same buying decision. One is “do I have budget and infra.” The other is “do I already own a MacBook.” Once image-to-3D crosses into the second category, experimentation rates jump even if throughput stays mediocre.

I do have some pushback, though. The post gives one hardware datapoint and one output datapoint, but not the parts that decide whether this is broadly useful. We do not get side-by-side quality comparisons against the original CUDA path. We do not get memory peak, batch behavior, failure rate across different images, or fidelity metrics for geometry and texture. “~400K vertices” sounds substantial, but vertex count is not quality. A messy mesh can be large and still unusable. The author also says “not as fast as H100,” which is fair, but the actual speed gap is not disclosed. Without that, it is hard to know whether the port is 3x slower, 10x slower, or worse on harder scenes.

There is another reason to be careful: ports like this often work first on the happy path and only later reveal the maintenance tax. Flash attention replacements, sparse ops rewritten in plain PyTorch, and Python-side mesh extraction are all plausible for a strong demo. Keeping them stable across upstream model updates, PyTorch releases, and MPS quirks is a different job. Apple’s Metal stack has improved a lot, but anyone who has shipped serious local inference on MPS knows the long tail: silent fallbacks, memory fragmentation, kernels that regress between versions, and performance cliffs on odd tensor shapes. I buy the accomplishment. I am less ready to declare the stack “portable” in the boring production sense.

There is also a bigger market read here. Microsoft publishing research code that is effectively CUDA-shaped has been normal. The open-source community doing the portability work has also been normal. Nvidia still captures the high-end training and fastest inference layer, but the community keeps eroding exclusivity at the application layer. That happened with diffusion. It happened with LLM inference. Now it is happening in image-to-3D. Apple benefits from that without needing to win the frontier model race, because every successful port turns Apple Silicon into a viable endpoint for creative AI workflows.

So I would not frame this as “TRELLIS.2 on Mac beats Nvidia.” It doesn’t. I’d frame it as the beginning of a more annoying reality for CUDA-centric projects: if the model is valuable enough, someone will eventually reimplement the missing pieces. And once that happens, the moat shifts upward. It stops being “can this run at all” and becomes “how much faster, cleaner, and easier is the Nvidia path.” That is still a strong moat. It is just a narrower one than the ecosystem used to assume.

If the repo holds up across more machines and more scenes, this kind of work pushes image-to-3D toward the same place local image generation already reached: not best-in-class speed, but wide enough accessibility to matter.