LumaByte retweeted
Edge0-145B is a 145B-parameter open-weights model that its makers say runs on a 48 GB laptop: 29 GB peak memory and 80+ tokens a second, because only about 10B parameters work on each step.
Edge0 published the weights and its own inference framework this week. Here is the vendor's own table (Edge0's internal evaluations, not independent) against the two open models it chose to compare:
Edge0-145B / Qwen3.8-Flash-Next / DeepSeek-V4-Flash-0731
DeepSWE 1.1: 64.6 / 58.7 / 54.4
Terminal-Bench 2.1: 86.52 / 83.3 / 82.7
GPQA-Diamond: 90.4 / 91.7 / 90.8
IFBench: 80.6 / 81.3 / 79.2
HLE: 35.4 / 35.9 / 33.8
It leads on both coding-agent rows. It trails Qwen3.8-Flash-Next on GPQA-Diamond, IFBench and HLE, and DeepSeek on GPQA-Diamond.
The memory comparison needs care. 29 GB is Edge0's measured peak. Its figures for the others, about 70 GB for Qwen3.8-Flash-Next and about 87 GB for DeepSeek at standard 4-bit, are estimates it says remain to be measured. The same page also puts an expert library of about 40 GB in system memory and about 48 GB of vocabulary data on the SSD, so read the hardware guide before planning around a 32 GB machine.
Licence: the Edge0 Community Model License 1.0, which is not an OSI open-source licence. Personal, research and internal business use are allowed. You need a separate commercial licence to sell or host access to the model, or to ship a paid coding or office assistant built on it. The text says the Qwen parts keep their own Qwen licence.
No Ollama library page for it exists yet (checked 13 Nov). The weights are on Hugging Face as Edge0-145B-NVFP4.
Which would you rather run for coding: this 145B at 29 GB peak, or Qwen3.8-27B at roughly 18 GB (Edge0's estimate)?
edge0.ai/blog/introducing-ed…
LumaByte retweeted
Rust 1.100 (12 Nov) lets Cargo refuse crate versions that are too new. The Rust team's reason: malicious versions are often caught within hours or days of being published, so waiting a few days avoids most of them.
Opt in, in .cargo/config.toml:
[registry]
global-min-publish-age = "3 days"
Then cargo update skips anything newer and tells you what it held back. In the release notes' example, clap 4.6.9 was published 2 days ago, so Cargo stays on 4.6.7.
Need one version now? CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update clap --precise 4.6.9
Two limits the notes name: a version with no pubtime field in the registry index is never held back, and cargo install ignores the minimum age (pin with cargo install [email protected]). Cooldowns reduce some supply chain risk, not all of it.
blog.rust-lang.org/2026/11/1…
LumaByte retweeted
A number parser can run more than twice as fast if you tell it what your data looks like: Daniel Lemire's fast_float goes from 153 to 345 million numbers per second on an Apple M4 Max for random-sign prices, with one hint.
fast_float turns text like -731.51 into a floating-point value and ships inside GCC's C++ standard library. Every decision it makes (is there a sign, how many digits, where is the point) is a branch. A wrong guess by the processor costs 15 to 20 cycles. With random signs, Lemire measured a mispredict on 60% of numbers on an Intel Xeon Gold 6338.
He is adding three hints, passed as a template argument: unpredictable_sign, short_numbers (up to 8 characters, parsed in one go) and assume_round_to_nearest (you promise nothing changes the rounding mode). Numbers parsed per second, in millions, Intel then Apple:
- Price changes (random signs, short): 73 to 105, and 153 to 345
- Account balances (random signs, long): 61 to 82, and 132 to 199
- Sensor readings (no sign, varied shapes): 67 to 92, and 123 to 250
- Regular prices (same shape every time): best with no hint on Intel (152)
It backfires if the hint does not fit: short_numbers on regular prices drops Intel from 152 to 104, and unpredictable_sign on sensor readings drops it to 57. If you promise round-to-nearest and code in your process changes the rounding mode, some results will be wrong.
The call is one line: fast_float::from_chars<performance_hints::unpredictable_sign>(first, last, value). The hints are still in a pull request, so this is not a release yet.
Does your parsing code know anything about its data that the library does not?
lemire.me/blog/2026/11/10/te…
LumaByte retweeted
Google's new Decisions API returns a probability instead of a paragraph, at $0.10 per million input tokens with zero output tokens billed.
It is built for closed-set choices: routing a query, checking a policy rule, grading content. You send one input (text, images, audio, video or PDFs, up to 256K tokens) plus up to 1,000 questions, and the model scores the options in a single pass instead of writing an answer. Google gives 150 to 250 ms end to end.
Three question types: a yes/no check, a choice from 2 to 255 options, and an ordered rubric score. Each answer carries a confidence from 0 to 1, so your code can send the unsure cases to a person or a stronger model.
The cost claim is Google's own: nearly 5x cheaper than Gemini 3.5 Flash-Lite on its benchmark suite. The client example uses the v1beta API, and the benchmarks are not independent.
blog.google/innovation-and-a…
LumaByte retweeted
AMD's Zen 6 doubles its VNNI units from two to four, and Chips and Cheese's 512-bit VNNI test goes from 1.99 to 3.88 instructions per cycle.
George Cozma published the microarchitecture breakdown on 10 Nov. VNNI instructions do the inner loop of quantized inference (running a model with smaller numbers to save memory) and some video filters. The denser Zen 6c core matches the result.
The trade, from the same article: integer multiply units drop from three to two, because AMD says Zen 5's third unit did not justify its area. L3 latency rises from about 47 cycles on Zen 5 to 55 on Zen 6 and 66 on Zen 6c. And 256-bit vector loads go to four per cycle, so 256-bit and 512-bit loads both reach 128 bytes per cycle.
These are one site's microbenchmarks. No LLM tokens-per-second figure is in the article, so it does not say how much faster a model runs.
If you run models on a CPU, would you rather have more vector throughput or lower cache latency?
chipsandcheese.com/p/amds-ze…
LumaByte retweeted
A CPU without SSE4.2 and POPCNT cannot run .NET 11. Microsoft raised the minimum from x86-64-v1 to x86-64-v2 on Windows, Linux and Apple, and moved the precompiled-code target on Windows and Linux up to x86-64-v3.
This is from Microsoft's 'What's new in the .NET 11 runtime' page, which says it was last updated for release candidate 2 (RC 2), so it describes the candidate, not the final release.
What changes:
- Minimum for JIT and AOT code: v1 to v2. v2 adds CX16, POPCNT, SSE3, SSSE3, SSE4.1 and SSE4.2. Microsoft says the last older chips went out of support around 2013.
- Precompiled (ReadyToRun) target on Windows and Linux: v2 to v3, which adds AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT and MOVBE. A machine with v2 but not v3 still runs, but the page warns of extra startup work.
- Arm64: Windows now requires the LSE instruction set. The Linux minimum is unchanged, so Raspberry Pi class devices stay supported. Apple M1 is unchanged.
- On a CPU that is too old, the runtime prints a message like 'The current CPU is missing one or more of the baseline instruction sets.'
Check a Linux machine before you upgrade it:
grep -o -w -E 'cx16|popcnt|ssse3|sse4_1|sse4_2' /proc/cpuinfo | sort -u
Five names listed means the v2 minimum is met (SSE3 shows up as pni).
grep -o -w -E 'avx2|bmi2|fma' /proc/cpuinfo | sort -u
Three names listed means it has the main v3 features. That is a quick proxy, not the full v3 list.
On a virtual machine, run it inside the VM: the hypervisor decides which flags the guest sees.
learn.microsoft.com/en-us/do…
LumaByte retweeted
Google now has four TPU systems from one chip generation. The two new ones solve two different problems for agents.
TPU 8tx is for confidential inference (running a trained model on private data). Data is normally encrypted when stored and when sent, but sits unlocked in memory while it is processed. Google says 8tx keeps data and model weights isolated even while in use. It runs on the same silicon as TPU 8t with AMD EPYC hosts, and Google puts latency at up to 2x lower than 8t, with a near-zero performance penalty.
TPU 8i Max is for long context: two 8i chips on one package, with double the compute, double the SRAM (on-chip memory) and double the HBM bandwidth (memory speed) of the 8i, in the same rack footprint.
A 3-item check before an agent touches regulated data:
1. Is the data protected while it is being processed, not only stored and sent?
2. Are the model weights covered the same way?
3. What does that protection cost in latency?
All figures are Google's own, from its 9 Nov post, and the page gives no price or date for either system.
For sensitive data, which is the harder part of running agents: the speed, or being able to prove it stayed private?
blog.google/innovation-and-a…
LumaByte retweeted
Meta's Muse Ember matches Claude Haiku 5.5's best index score for about a third of the cost per task: 35.8 at $0.136, against 36.2 at $0.411. That is Meta's chart of Artificial Analysis results, published 9 Nov.
What it is: Meta's smallest Muse model, built for the work agents repeat all day (tool calls, routing, extraction, long documents). 1M-token context, up to 512K tokens of output, $0.10 per million input tokens and $0.50 per million output, on Meta's own API.
Index score and cost per task, from Meta's chart:
- Muse Ember: 33.9 for $0.116, 35.8 for $0.136
- Claude Haiku 5.5: 24.6 for $0.092, 29.6 for $0.159, 34.3 for $0.248, 36.2 for $0.411
- GPT-6 Luna: 21.4 for $0.073, 23.3 for $0.104, 27.8 for $0.152
Where Meta's table has it ahead, at max reasoning: AutomationBench-AA 37.8 against 20.2 for Luna and 13.9 for Haiku. Agents' Last Exam 61.6 against 57.1 and 57.0. Terminal-Bench 4.0 40.9 against 39.2 for Haiku and 16.4 for Luna.
Where it trails: FrontierCode 2.0-AA, real engineering tasks judged on whether the change is mergeable, 27.2 against 34.9 for Haiku. On GDP.pdf-AA, work over long documents, it ties Luna at 22.8.
Limits: Meta picked the benchmarks and the framing, Ember's costs are its own estimates at its proposed price, Agents' Last Exam is Meta's internal run, and the rivals are the two small tiers from Anthropic and OpenAI, nothing bigger.
research.meta.ai/blog/muse-e…
LumaByte retweeted
Kimi K3.1 Pro scores 65.7 on Terminal-Bench 4.0 in its own lab's table: ahead of GPT-6 Astra (58.2) and Claude Fable 5.1 (57.9), 0.7 behind Opus 5.5 (66.4). Open weights, 2.8T MoE, 104B active.
Moonshot's table, where it leads:
- Terminal-Bench 4.0: 65.7 vs 58.2 GPT-6 Astra, 57.9 Fable 5.1
- SWE Marathon v1.1: 51.7 vs 46.3 Opus 5.5
- BrowseComp: 92.1 vs 91.5 GPT-6 Astra
- HLE-Full with tools: 70.0 vs 67.7 Opus 5.5
Where it trails:
- Program Bench: 31.5 vs 65.0 Opus 5.5
- Terminal-Bench-Science 0.1: 38.1 vs 68.1 GPT-6 Astra
- HLE-Diamond: 39.4 vs 65.8 GPT-6 Astra
- ExploitBench: 74.7 vs 100 GPT-6 Astra
Fine print: Moonshot ran its own model with the Claude Code harness; the rival scores are the highest from those labs' blogs or public leaderboards. Not an outside test.
Licence: free to use and fine-tune, but a company selling model-as-a-service with over $20M in 12 months needs a separate deal (section 2). Not OSI. No Ollama page for K3.1 (checked today), and at 2.8T it is rented, not run at home.
For agent work: the open model with the published table, or the closed one that wins on Program Bench and the science test?
huggingface.co/moonshotai/Ki…
LumaByte retweeted
Baidu released the base weights of ERNIE 5.5 Flash on 5 November: 280B parameters in total, 14B active per token, and the checkpoint straight out of pre-training, before any instruction tuning. So it is a starting point to fine-tune, not a chat model.
In Baidu's own table, against three base models of similar size (DeepSeek V4 Flash Base, Hy3 preview Base, MiMo V2.5 Base), it beats the best of the three on MMLU-Pro (78.4 vs 69.2), HumanEval+ (82.3 vs 78.0) and LiveCodeBench (40.1 vs 33.5). It falls behind on ChineseSimpleQA (73.0 vs 75.3), FullStackBench (54.6 vs 56.7) and HELMET-Rerank (56.2 vs 60.0).
Weights are on Hugging Face in FP8 and BF16. There is no Ollama page for it (checked today), and at 280B it is not a laptop model anyway.
The licence is Baidu's own (ERNIE 5.5 Flash Base Model License v1.0), not an OSI licence. Non-commercial use is free. Commercial use is free up to US$50 million a year in related revenue after a one-time notice to Baidu; above that you need written authorisation. And the grant only covers its "Territory": everywhere except the European Union, the United Kingdom and South Korea.
ernie.baidu.com/release/erni…
LumaByte retweeted
Ripple-65B Preview scores 80.5 on Terminal-Bench 2.1 in its own lab's table, level with or ahead of open models 8 to 15 times its size. 65B dense, Apache 2.0, out 4 Nov.
Ricursive's table, where it leads:
- Terminal-Bench 2.1: 80.5 vs 80.1 Reflection Beam 501B, 76.4 Muse Spark Open 816B, 63.8 Inkling 975B, 56.4 Nemotron 3 Ultra 550B
- SWE-bench Pro v2.0 Hard: 79.1 vs 76.5 Reflection
Where it trails:
- SWE-bench Verified: 76.5 vs 81.6 Reflection
- MCP Atlas: 71.7 vs 89.2 Muse Spark Open
- DeepSWE 1.1: 44.3 vs 60.0 Muse Spark Open
- GPQA Diamond: 85.2 vs 90.6 Reflection
Dense means all 65B parameters run on every token; those rivals are MoE. The lab says most models scored lower on Terminal-Bench under the official harness, some rival numbers are its own re-runs, and the release is a Preview with light post-training. 1M context, 12T training tokens, an NVFP4 build it says fits a DGX Spark. No Ollama page (checked today).
For a coding agent, which one do you run: the 65B model that fits on one box, or a 500B+ MoE that wins on SWE-bench Verified and tool use?
huggingface.co/ricursiveAI/R…
LumaByte retweeted
DiffuSpace released Clover-35B-A3B-Preview (28 Oct), an open-weights 35B model (about 3B active) that writes blocks of text in parallel, a diffusion model, instead of one token at a time.
In the lab's own table, against Qwen3.6 35B-A3B:
- SWE-bench Verified 73.6 vs 65.8
- Terminal-Bench 2.1 51.7 vs 43.1
- SWE-Pro 46.5 vs 42.7
- ZebraLogic 95.8 vs 89.2
It trails on HLE text-only (12.8 vs 21.2) and AIME 2026 (83.3 vs 90.4). The baselines are the lab's pick, and the 680 tokens/s speed claim is its own test on a GB300.
Apache 2.0 weights, marked Preview, custom code required, about 69 GB in BF16, no Ollama page (checked today). SGLang and llama.cpp backends are in the repo.
Coding agent or hard maths: which one do you pick, the faster diffusion model that wins on SWE-bench, or the standard one that wins on AIME?
huggingface.co/Diffuspace/Cl…
LumaByte retweeted
SenseNova released SenseNova-Loop-9B-Preview (30 Oct), an open-weights 9B model that runs the same block of layers twice: 32 layers stored, 56 layer-steps per answer.
In the lab's own chart:
- BIRD-Dev 71.38, next model listed 69.84
- WorkBuddy 66.89 vs 61.98
- TeamBench 48.89 vs 44.44
- AutomationBench 13.72 vs 10.17
It trails on Terminal Bench 2.1 (40.45 vs 49.44 for Nanbeige 4.2-3B and 47.19 for Qwen3.5 27B) and tau3-Banking (18.56 vs 19.59). The comparison set is the lab's pick.
Apache 2.0 weights, marked Preview, tech report TBD, no Ollama page (checked today). Runs through Transformers with custom code.
Which is better depends on the job: the looped small model looks stronger on SQL, spreadsheet and team-task benchmarks, the bigger models on terminal work.
huggingface.co/sensenova/Sen…
LumaByte retweeted
Baidu released Unlimited-OCR 2, an open-weights model that reads a 100-page document in one pass.
By the paper's own tables:
- MarathonDocBench (100+ pages): 77.06, next model listed (Kimi-K3) 33.74
- MPDocBench (tens of pages): 84.59 vs 78.30 for Qwen3.8-Max
- Peak KV cache while reading: 1.77 GB vs 47.00 GB with standard decoding
It trails page by page: on OmniDocBench v1.6 it scores 94.02, behind TeleOCR (96.91, 1.2B) and OvisOCR2 (96.47, 0.8B). MarathonDocBench is also Baidu's own new benchmark.
3B parameters, 0.5B active, MIT licence. No Ollama page yet (checked today); the repo targets SGLang on an 80 GB A800.
For parsing long documents locally, would you pick the one built for 100+ pages, or a small specialist that scores higher page by page?
huggingface.co/baidu/Unlimit…
LumaByte retweeted
Microsoft's 41K-star BitNet project is now doing something particularly interesting for RAG and local AI.
It has brought 1.58-bit weights to text embedding models.
And in Microsoft's CPU benchmarks, its 600M-parameter embedding model achieves up to 2.28× the throughput of its FP16 baseline.
This builds on the same BitNet research that produced the 2B-scale language model trained on 4 trillion tokens.
The original idea was to train neural networks whose linear-layer weights take only three values: -1, 0, and +1.
With specialized inference kernels, this can substantially reduce weight storage and memory traffic.
Microsoft has now released two BitNet embedding models:
→ BitNet-embedding-270M, with 640-dimensional embeddings
→ BitNet-embedding-0.6B, with 1,024-dimensional embeddings
Both support sequences up to 32,768 tokens and use ternary weights with 8-bit activations in their quantized linear layers.
The 600M model is especially interesting.
In Microsoft's reported English multilingual embedding benchmark comparison, it achieved an average score of 67.60, compared with 67.95 for its FP16 teacher.
Meanwhile, with 8 CPU threads, the optimized 1.58-bit implementation delivered between 1.42× and 2.28× the FP16 prefill throughput, depending on sequence length.
That performance difference matters for applications that repeatedly encode documents, queries, and other text.
The implementation also reveals an important engineering detail. Its advantage becomes smaller as sequences grow longer, because attention computation starts accounting for more of the workload.
And the project goes beyond embedding models.
Microsoft has also released CPU optimization work, custom GPU inference kernels, and related low-bit speech-recognition infrastructure.
The GitHub repository includes the inference engine, optimized kernels, supported models, and conversion tools.
For engineers working on RAG, local inference, or resource-constrained AI systems, BitNet is a very interesting project to study.
Fully open source under MIT.
GitHub: github.com/microsoft/BitNet
LumaByte retweeted
5 Tips to Master Backend Engineering in the AI Era
1. Master Backend Fundamentals
Build a strong foundation in HTTP, REST APIs, authentication, authorization, databases, caching, message queues, and server-side programming. Understand how modern backend systems communicate and operate.
2. Learn AI Integration & LLM Engineering
Understand how to integrate OpenAI APIs, LLMs, embeddings, RAG pipelines, AI agents, function calling, and Model Context Protocol (MCP) into backend applications.
3. Master Databases & Distributed Systems
Learn PostgreSQL, MongoDB, Redis, Kafka, database indexing, replication, sharding, event-driven architecture, and distributed transactions. Modern AI applications still depend on reliable data infrastructure.
4. Become an Expert in Cloud & Infrastructure
Master Docker, Kubernetes, CI/CD, AWS, serverless computing, Terraform, observability, and microservices. Learn how to deploy, scale, monitor, and secure production-grade backend systems.
5. Build AI-Powered Backend Projects
Move beyond tutorials. Build AI-powered SaaS platforms, RAG applications, AI agents, intelligent search engines, recommendation systems, document-processing APIs, and automated workflows. Focus on scalability, security, reliability, and real-world performance.
Grab Backend Engineering ebook: codewithdhanian.gumroad.com/…
LumaByte retweeted
Recursive released Flint: an open-weights coding model with 39.8B total parameters and about 2.5B active per token, built to run on a laptop.
By Recursive's own chart, it beats Qwen 3.6 (a similar-size MoE, 3B active) on:
- Terminal-Bench 2.1: 54.9 vs 44.9
- SWE-bench Pro v2: 89.7 vs 73.8
- IFBench: 89.2 vs 67.9
It trails the dense Qwen 3.8 (27-31B) on:
- Terminal-Bench 2.1: 54.9 vs 73.0
- SWE-bench Pro v2: 89.7 vs 94.9
- LiveCodeBench v6: 80.3 vs 90.3
Recursive claims more than 5x the speed of dense models with similar coding scores. On Ollama: ollama run flint (23 GB download, 256K context).
Licence: Apache 2.0.
For a local coding agent, would you take the fast small-active model or the dense one that scores higher on the hard tests?
recursive.com/updates/introd…
LumaByte retweeted
Nanbeige released Nanbeige4.3-33B: an open-weights 33B model for coding and office-style agents, with a 512K context window.
By the lab's own table (each model at its highest thinking effort), it beats Qwen3.8-27B on:
- Terminal-Bench 2.1: 80.9 vs 73.0
- DeepSWE: 65.5 vs 42.5
- Toolathlon-Verified: 70.4 vs 68.5
It trails on:
- SWE-Bench Pro: 60.3 vs 61.7 (Qwen3.8-27B)
- GDPval: 84.8 vs 86.4 (Qwen3.8-27B)
- GPQA Diamond: 89.5 vs 91.3 (Gemma4-31B)
17 of the 20 rows go its way. The weights are 66 GB at BF16, so a quantized build is the realistic local route; there is no Ollama library page, only community GGUFs on Hugging Face.
Licence: Apache 2.0.
For a coding agent on your own hardware, would you take the 33B that wins most rows or the 27B that still wins on SWE-Bench Pro?
huggingface.co/Nanbeige/Nanb…
LumaByte retweeted
Harness Engineering from Scratch 🚀
Found this excellent 21K+ star GitHub repo that teaches you how to build reliable AI coding agents, from the ground up.
An entire open-source curriculum with 14 lectures, 8 hands-on projects, and 8 progressive learning phases.
What makes it useful is the approach: instead of just learning concepts, you gradually build the engineering environment around an AI agent, using the same real application throughout the course.
What's inside:
→ Agent instructions and repository structure
→ Context management and persistent memory
→ Multi-session continuity and task handoffs
→ Task planning, scope control, and progress tracking
→ Testing, verification, and observability
→ Automated coding loops and maker-checker workflows
→ Graph orchestration, parallel execution, and rollback
Includes practical projects, reusable templates, a harness-creator skill, and technical breakdowns of how Claude Code, Codex, Pi, and DeepSeek build their harnesses.
Available in 15 languages.
Perfect for software engineers and AI developers who want to move beyond prompting and understand how reliable coding agents are actually built.
Completely free and open source.
Here's the GitHub Repo: github.com/walkinglabs/learn…






