Hi everyone,

I’m Marvel, a computational neuroscientist at Cambridge and founder of a robotics startup.

I’m spending the next few weeks speaking with robotics engineers, researchers, and founders to better understand the biggest challenges in deploying robots outside the lab.

Whether you’re working on manipulation, humanoids, industrial automation, or teleoperation, I’d love to hear:
What’s the biggest technical bottleneck your team is facing today?

If you had a magic wand, what problem would you eliminate?

I’m here to learn first. If it’s useful, I’m happy to share what we’re building and get your thoughts.

Looking forward to the discussion.😁

If you are running local LLMs, your hard drive is likely bleeding gigabytes without you realizing it. Between default model weights, duplicate quantization formats, and forgotten vector embeddings, local AI setups are silent storage hogs.

Here is how you can systematically track down and clean up the clutter directly from your terminal:

• Locate hidden Hugging Face and Ollama model weights: By default, Hugging Face caches everything in ~/.cache/huggingface/hub and Ollama stores models under ~/.ollama/models. Run du -sh ~/.cache/huggingface/ to see how much space is currently locked up.
• Prune redundant quantization formats and unused embedding databases: Review your downloaded models and delete redundant variations (like keeping both Q4_K_M and Q8_0 when you only use one). Clear out stale Chroma, FAISS, or Pinecone local vector database caches residing in your project directories.
• Automate routine garbage collection: Set up a lightweight shell script to periodically check cache growth and alert you before your drive hits capacity.

Fore More Information

I put together the complete, production-ready automated cleanup script along with an interactive storage calculator to help map out your directories.

Direct links to the complete article.

drop a comment below

So for context, I've been working on this research project comparing federated learning algorithms (FedAvg, FedProx, FedNova) against a centralized baseline for network intrusion detection, using the CICIDS2017 dataset split across four simulated "silos" by attack type. Three of the silos have tons of data, but one silo (Web Attacks) only has about 3k samples out of 3 million total, so it's a pretty extreme imbalance.

The thing that got me was how good the global accuracy numbers looked while completely hiding what was actually happening underneath. FedAvg was hitting like 96% global accuracy, which sounds great, but when I broke it down by silo, the minority silo was sitting at like 49% accuracy with literally 0.00 recall on the attack class, meaning it missed every single attack in that category. The global number just averages that out because the big silos are doing fine and there's so much more data in them, so the failure basically gets buried.

Even weirder, I reran the centralized model (the "gold standard" baseline that gets to see all the data at once, no federation at all) across 10 different random seeds just to sanity check things, and its performance on that same minority silo swung from about 57% to 99.5% depending purely on the seed. Same model, same data, same everything except the random seed, and it either completely nails the rare attack class or completely whiffs on it. That kind of instability in a "centralized is the safe baseline" model was not what I expected going in.

FedNova (which normalizes updates by local step count instead of just averaging) ended up being way more consistent across all silos, staying in the high 90s no matter which silo or seed, without giving up any global accuracy either. So the actual conclusion of the paper is basically: global accuracy is not a trustworthy metric on its own in federated intrusion detection, you have to look at per-client performance, and picking your aggregation method actually matters a lot more for rare attack detection than the global number would ever suggest.

Currently rewriting this for a conference submission and happy to answer questions if anyone's curious about the setup or findings.

Title:

Show Reddit: MSE-GLM – A Deterministic Zero-Weight Graph Language Model

Author: Clifford Chivhanga

https://github.com/fodokidza/mse_glm

https://tonlexianert.com/pages/blog.php

https://aircityshops.com/index.php?url=city/mse_blog

Post:

Hi Reddit,

I've been working on a new language model architecture called MSE-GLM (Matrix Semantic Engine – Graph Language Model). Instead of learning billions of neural network weights, it stores knowledge in explicit graph structures and performs deterministic inference.

The architecture currently consists of several cooperating components:

• Edge Matrix – local token transitions
• Bridge Matrix – structural substitution discovery
• Relationship Matrix – complete sequence memory
• Experience Matrix – graph expansion
• Cluster Interpreter – semantic interpretation of discovered clusters
• Context Trigger Matrix – deterministic context-aware token selection

One design goal is to make every inference explainable. Rather than relying on hidden activations or attention weights, the model traces decisions through explicit graph relationships and structural evidence.

Some of the ideas I'm exploring include:

• Zero learned neural weights
• Deterministic inference
• Explainable reasoning paths
• Graph-based semantic interpretation
• Context-aware token selection without neural attention
• Explicit, inspectable knowledge structures

The project is still under active development, and I'm looking for technical feedback on both the architecture and the implementation.

I'm particularly interested in discussion around:

• Scalability to very large corpora
• Context handling compared with transformer attention
• Graph indexing and storage efficiency
• Potential strengths and weaknesses of deterministic graph-based language models
• Benchmark ideas for evaluating the architecture

The source code and documentation are available on GitHub.

I'd really appreciate any feedback, criticism, or suggestions from the HN community.

We spent the last months consolidating seven separate sequence classifiers into one multi-head model, our apex model, so to speak, and since the weights are now public, I wanted to share what worked and what surprised us.

Setup: a shared mmBERT-small encoder with seven task heads, binary injection (BCE), document class (7-way), tool type (14-way), tool operation (6-way), tool data-flow tags (3× BCE, multi-label), intent routing (5-way), and threat type (7-way).

The part that needed care: our training rows only carry labels for a subset of tasks, so absent tasks are masked out of the loss entirely. We ended up writing a self-test that asserts absent-task gradients are exactly zero, which caught two subtle bugs, and I'd recommend it to anyone doing similar masking. About 5k synthetic/real multi-task rows help the heads co-train; the test sets stay 100 % real data.

Held-out results per head: injection F1 0.962, documents 0.980, tool type 0.957, tool operation 0.945, tool tags 0.958, routing 0.916, threat 0.952.

Quantization: both the unified model and the dedicated single-task variants ship quantized -edge builds (ONNX INT8 + INT4 embeddings, from 96 MB) with measured parity benchmarks in the repos, the worst head loses 0.012 against FP32.

Was it worth it vs. seven dedicated models? We released both variants, so you can judge for yourself, the dedicated models score marginally higher on most tasks, but the unified one does one encoder pass instead of up to seven.

Our weak spot: routing, at 0.916. The intent classes overlap semantically ("write code that analyzes my data" is that code or analytics?), and I suspect the ambiguity is genuinely in the data. If you have ideas beyond relabeling, let me know :)

Weights and per-head metrics: https://huggingface.co/patronus-studio

Hi everyone! 👋

I'd like to share an open-source side project I've been developing called AnvilAI — a native Android client designed to run Large Language Models (LLMs) completely on-device without relying on cloud APIs or external servers.

Most mobile AI wrappers require cloud subscriptions or send user data to remote servers. I wanted to build something native, fast, private, and secure for Android devices.

Key Features:

Vulkan GPU Acceleration: Built with a C++ NDK engine layer to leverage mobile GPUs for real-time token generation.

100% Offline & Private: Zero cloud dependency and zero telemetry. Your prompts and outputs never leave your device.

Encrypted Storage: All local chat history and settings are encrypted at rest using SQLCipher.

Modern UI: Built 100% in Jetpack Compose (Material 3) with clean architecture (Hilt, Coroutines, Flow).

Source Code & Download:

The project is 100% open-source! You can check out the source code, inspect the architecture, or download the pre-built APK from the GitHub Releases tab here:

https://github.com/denizaydogan1902/AnvilAI

I would love to get your thoughts, UI/UX feedback, or ideas for future updates. Feel free to leave a star ⭐️ on GitHub if you find it useful!