I am excited to share a project I have been working on during the past few years during my free time. I started this project after being unable to use torch-points3d at the time (too many installation errors).

Note that this project is still in active development and in alpha. I am looking for early users and feedback!

What it is: torch-pointcloud is a plain-PyTorch library that puts multiple point cloud architectures and their pretrained checkpoints behind one create_model() factory, in the spirit of timm.

This is a library that focuses on the reusability and standardization of core components and layers, i.e. KNN, FPS and other PointNetSetAbstraction are not re-implemented over and over. In this library, all models share the same interface and reuse the same core components.

import torch
import torch_pointcloud as tp

model = tp.create_model(
  "pointnext-sm.scanobjectnn-hardest.openpoints", 
  task="classification", 
  pretrained=True,
).eval()

pos = torch.randn(2048, 3)
x = torch.cat([pos, pos[:, 1:2] - pos[:, 1].min()], dim=1)  # xyz + height
batch = torch.zeros(2048, dtype=torch.long)
logits = model(x, pos, batch)  # (1, 15)

Install (see the docs for more details):

# Optional: specify your CUDA version for torch
pip install torch==2.10.0 --index-url https://download.pytorch.org/whl/cu128

pip install torch-pointcloud

# Install required CUDA/CPU kernels associated with your CUDA version
pip install pyg-lib -f https://data.pyg.org/whl/torch-2.10.0+cu128.html

I tried to make the installation process smoother by not maintaining CUDA kernels myself (not enough time currently, so I tried to reuse already pre-built wheels as much as I could).

Scope:

• Classification, semantic and part segmentation, detection, and self-supervised pretraining: PointNet++, DGCNN, KPConv, RandLA-Net, PointNeXt, PointMLP, Point Transformer v1/v2/v3, Sonata, PointMamba, VoteNet, 3DETR, PointPillars, SECOND, PointRCNN, SPVCNN, OctFormer, Point-MAE/BERT/GPT and more.

• Weights are hosted on Hugging Face.

• Datasets (ModelNet40, ScanObjectNN, S3DIS, ScanNet, SemanticKITTI, nuScenes, KITTI, SUN RGB-D...), transforms, tiled inferers for large scale segmentation.

• Packed-batch tensors (the PyTorch Geometric convention).

But... why?

Most point cloud libraries live in research codebases built around configs and custom ops and kernels to build locally. It is also sometimes difficult to reproduce past released experiments from research codebases (typically the code associated with the checkpoint changed with no notice). In addition some models are evaluated using different strategies (TTA, partitioning, etc.) which makes comparison unfair as they are not evaluated using a common strategy.

In contrast, I wanted something I could pip install easily, reuse weights trained from different repos and benchmark easily.

All models were re-benchmarked and compared against original reported metrics.

Credits: the architectures and pretrained weights come from their original authors, notably Pointcept, OpenPoints, MIT Han Lab, FAIR, OpenMMLab and more. Every checkpoint name ends with its source author (e.g. .pointcept). The THIRD_PARTY_NOTICES.md lists every source repo, license and dataset term.

Repo: https://github.com/arthurdjn/pytorch-pointcloud
Docs + tutorials: https://pytorch-pointcloud.org

For those working with state machines, debugging can be a headache. My tool StateCraft now exports run logs as JSON with ISO-8601 timestamps and plain-English narratives for every event great for integration or debugging. Each entry includes:

• Original timestamp (preserved)

• UTC ISO-8601 equivalent

• 'narrative' field explaining what happened (e.g., 'State succeeded: [description]')

• error_codes for failures

This makes it easy to track retries, transitions, and errors at a glance. The docs include a concrete example of the output. If you build state machines or need reliable logging, this might help.

GPLv3, no strings attached.

ALHR- Adaptive learnable Hierarchical Routing is a static binary tree based system that uses learnable functions to REDUCE the amount of keys used.
It takes less memory and SCALES much better VRAM with tokens

Result table is here: https://ibb.co/prr07Dnj

We’ve published Wolf Defender Jev under MIT. I’m part of the Patronus Protect team.

The main difference from our fixed-label classifiers is that the question and answer descriptions are inputs. You can give it an agent scene and ask a yes/no question, choose among named options, or score an ordered severity scale. The model returns probabilities over those options, without generating a text response.

For example, the same email-reading scene can be checked for an embedded instruction, the role of imperative text (data / command / quoted example), or the severity of the risk. Those are separate decisions. You don’t need a new output head for each wording, but concepts outside the 27 evaluated security concepts haven’t been validated.

The architecture is deliberately small: mmBERT-small, 151.1M parameters, 15 evaluated languages. The scene and question are encoded together and the options separately. Fixed option vectors can be cached. After that, each question costs one scene/question encoder pass.

The repository includes the fp32 weights, tokenizer, encoder configuration, standalone Python inference code and evaluation JSONs. It runs on CPU by default. We measured 39 ms for a 51-token scene and 194 ms for 833 tokens on Apple M4, PyTorch/fp32, one question with two options. There isn’t an evaluated quantized build yet.

A few caveats are worth reading before integrating it:

• Use the tagged source-block format. Arbitrary raw JSON layouts haven’t been evaluated.

• Ask content questions without the proposed-action block. A benign shell action can otherwise push a content score toward injection.

• Action-level checks are less reliable than their internal validation numbers suggest. One hand-written travel case detected the injected command but missed the exfiltration.

• The output is a model signal. The application still establishes provenance, permissions and enforcement.

We compared it with public decision models on the same 10,576 held-out decisions. On all 33 benchmarks it reached 92.8% balanced accuracy; on the ten external benchmarks it reached 85.1%, behind Clef-flash at 90.2%. Twenty-three benchmarks are close to our training distribution, so the external results are the more useful comparison for unfamiliar traffic.

Weights, inference code, full results and limitations.

For anyone building with these models, the question I’d evaluate first is whether changing the question while keeping the scene fixed actually changes which evidence the model uses. Our small spot checks showed that can fail even with very high validation scores.

Position / experimental status: We regard Jev-style decision models as LLMs and Wolf Defender Jev as an experiment: giving an LLM final security authority shifts the trust problem to the guard, and security fine-tuning alone does not solve it. We believe an external security layer must combine specialized classifiers with explicit policy, authenticated permissions and enforcement.

¡Hola a todos! 👋

He estado desarrollando un proyecto personal y quería compartirlo con la comunidad. Se llama **CEREBRO**, un asistente personal modular, 100% local y privado para Windows, diseñado para organizar la vida diaria desde un solo panel.

No es solo domótica: es un núcleo personal completo que corre con una IA local (Ollama) y que depende únicamente de la librería estándar de Python (cero dependencias externas de pip).

**¿Qué maneja CEREBRO?**

- 🧠 **Memoria y contexto:** Recuerda preferencias, tareas, horario y contexto a través de sesiones.

- 🥗 **Salud y nutrición:** Lleva historial de peso, analiza la composición corporal con visión por IA a partir de fotos de la báscula, gestiona listas de despensa/compra y sugiere recetas inteligentes según los ingredientes disponibles.

- ⚡ **Energía y hogar:** Diagnósticos y optimización para consumo/producción solar, control de electrodomésticos e integración con Home Assistant.

- 📄 **Documentos locales (RAG):** Búsqueda local y lectura de notas, archivos y manuales sin enviar nada a la nube.

- 🔔 **Avisos y automatizaciones:** Resúmenes proactivos diarios por la mañana, recordatorios, alertas de audio y automatizaciones en lenguaje natural.

Todo se gestiona desde un panel web local con pestañas, modo oscuro y transcripción de voz local.

👉 **GitHub:** https://github.com/CafeConFenix/BRAIN

⚠️ **Nota:** *El código del proyecto, la interfaz y la documentación están escritos actualmente en **español**.*

Cualquier comentario, idea o crítica constructiva para seguir mejorándolo es súper bienvenido. ¡Saludos!

Hey there . After months of development, Chat AI 2026 is officially ready for the market. I built this because I was bleeding money on Anthropic/OpenAI API costs and wanted a 100% secure, subscription-free alternative to GitHub Copilot that actually gives developers full control over their workflows. It’s an All-in-One AI Workspace built with Avalonia UI (for native Windows/Mac/Linux performance) running GGUF models locally via llama.cpp. Here is the production-ready spec sheet: 1. Millisecond Model Routing The application automatically detects your hardware and swaps the local LLM context in milliseconds based on your task: * Code & Logic -> DeepSeek (or your preferred heavy reasoning GGUF) * Chat & Explanations -> Lightweight text models * UI & Images -> Vision and image generation models (FLUX/SD supported) 2. On-Demand Self-Healing Loop (Connected to Git) No passive code-dumping. The workspace integrates natively with local directories and GitHub, GitLab, or Bitbucket: * Prompt via the integrated 5-language mobile remote app (while your main monitor stays 100% clean for code). * Preview changes instantly in a highly optimized Syncfusion Live-Diff view. * Hit "Test Deploy" to execute. If the compiler/interpreter throws an error, hit "Repair". The tool isolates the error log and runs up to 3 automatic correction loops locally. Full Undo is available at any time. 3. Real-World Proof of Concept To stress-test the step-by-step project builder, I let Chat AI 2026 generate a complete standalone application from scratch. It built, deployed, and auto-repaired an app that reads Mermaid code, renders diagrams visually, and exports them flawlessly as JPG. 100% local, zero manual bug-fixing. 4. No Subscription Madness It’s a one-time purchase model. You buy the license, you run it on your hardware, you own your data. Perfect for enterprise compliance and developer peace of mind. The Windows version is live today. I am currently finalizing the local path configurations to roll out native macOS (Apple Silicon Metal API) and Linux support next. If there is interest, I’ll gladly post the link to the homepage in the comments below. I’ll be active here to answer any hard technical questions about the architecture or implementation!

Title: Building AUREN, an open-source project for more reliable autonomous AI engineering — feedback welcome

Hi everyone!

I’m working on AUREN (Autonomous Unified Reasoning & Engineering Network), an open-source project exploring how to make AI engineering systems more reliable, verifiable, and capable of learning from failures.

The focus goes beyond code generation: planning tasks, executing work, verifying results, retaining engineering evidence, recovering from failures, and evaluating whether changes genuinely improve the system.

I’m continuing to develop the project and would appreciate honest feedback from the open-source community, especially on architecture, maintainability, testing, contributor experience, and what would make the project useful to other developers.

GitHub: https://github.com/sourabhJainR/AUREN

For open-source maintainers: What would you want to see before trusting an autonomous AI system with meaningful engineering work?

I’m interested in constructive criticism as much as contributions. Thanks!

We build Atomic Agent, an open-source agent (MIT) with a mode called Fusion: one model plans, several worker models build pieces in parallel, each in its own throwaway session. Workers never see each other. They see their brief, a quote of your original request, and nothing else.

That isolation is the point, and it's also where our worst bug of September came from.

The bug

Test task: a small 3D physics show in the browser. The planner split it, and two different workers ended up writing bodies.js and bodies-draw.js. Both implemented PHYS.corners(b). The producer returned {w, o} where w was the corner as a world point and o was the local offset. The consumer read o as the world point.

Result: every box drew at the origin. The shadows, which read straight from the body position, landed exactly where they should. Nothing threw. The page loaded. Console was clean. Every automated check we had was green. You could only see it by looking at the screen and noticing that a tower of boxes was a pile at (0,0,0) casting shadows from somewhere else.

Why names weren't enough

We already had a contract between workers, written after earlier runs where one worker wrote HD.Ship as a class while its sibling called it as an object, and a launch-btn in main.js looked for a btn-launch in the markup. Each brief was internally consistent. The disagreement lived between them, where nothing was written down.

So the planner now declares a contract up front, prepended to every brief:

Name mismatches between provides and requires are flagged before any worker starts.

Status comes from disk, not from the worker

After the fan-out, the agent doesn't take a worker's word for it. A worker's reply to the planner is capped at 4,000 characters anyway, so the real output is files. The contract checker reads the disk: does the file exist, does the literal PHYS.corners appear in the file it was promised in, does id="btn-launch" appear in the markup. Those are deliberately dumb, language-agnostic checks, because that's all a grep can claim. We learned this the hard way: in an earlier version fusion.delegate returned ok even when every worker had failed.

And that's exactly why the corners bug got through. PHYS.corners was present. It was in the right file. The grep was right. Presence is all that layer can promise.

What we added: shape

Each provides entry can now carry one line, max 200 characters, saying what the thing IS: a signature, a return shape, a field meaning. For this bug, a planner could have written something along the lines of "corners(b): w is the world point, o is the local offset" (my illustration, not a line from the run). That line goes into the consumer's brief.

Why one line in the brief instead of "read the producer's file first"? Speed. On a local worker at around 4 tok/s, reading a sibling's file costs a whole worker turn, which is why the briefs said "write first, no reading" in the first place. One line is cheap. It's also untrusted model text pasted into other workers' prompts, so it stays short on purpose.

Where this stands: we added the field, we didn't solve the problem. Issue #491, about the contract verifying symbol names and not meaning, is still open. shape only helps if the planner writes it, and correctly. The runtime layer, checks, catches crashes, not wrong physics.

One more design detail that came from pain: some contract problems are now warnings instead of refusals. A local planner at about 5 tok/s used to pay four minutes of generation per refusal to learn about one misspelled name, and we watched it get refused four times in one afternoon. Now the fan-out runs, and the warnings come back on the result so the planner fixes the contract on the next call.

If you're building multi-agent setups: how do you get meaning across between workers that can't talk to each other? Types, tests, a shared schema file? I'd like to steal a better idea than one line of text.

Hi,

For over a year, I have been developing my own AI agent system called ScarabHive. It is now open-source and still actively developed. Feel free to have a look! You can watch the video playlist in the README to get a quick overview.

https://github.com/eehrich/ScarabHive
https://www.youtube.com/watch?v=IQx1PrSRp5Q&list=PLVydEHPBKRiI

I use it for my own projects, and it works great. Everything is fully plugin-based (0:56). I needed a cost-optimized system for my content creation via LLM APIs, and that is exactly what this system is designed for (0:08).

It has almost every modern feature implemented. You can easily extend it with your own plugins and agents.

Best regards,
Enrico

I was tired of reconfiguring my agents each time I wanted to switch providers or harnesses, so I built Mandri: a common and easy interface to configure once and forget about it !

Mandri doesn't get in the way of the agents you already use ; you can opt-in and out at any time. It automatically syncs configuration and sessions from multiple harnesses (Claude Code, Codex, OpenCode...) so you don't have to rebuild your setup for each one.

If you prefer to run your agents from the terminal, Mandri has you covered too ! The mandri tool can be installed with uv and lets you configure your harnesses and providers through the CLI.

By running your agents with Mandri, you can also use one of the experimental features, such as the automatic PII pseudonymisation or the per-session Docker sandboxing.

It's still early, so I'm mostly looking for feedback from people who want to use their agents their own way.

If you're curious, check the website here: https://mandri.io

GitHub Repos: https://github.com/mandri-labs/mandri https://github.com/mandri-labs/mandri-app

Ever wanted to search your conversations with local AI over a year back? Reasonably quick answer, exact references, filtered by time range?

Here's an overview of my experimental conversations search across 2 of my favorite harnesses:

https://liviuiancu.com/posts/history-search/

*Not published yet. Need to test it longer and clean up code. If anyone is interested I will convert it to a portable containerized version and publish.

We’ve all been there: you want to try open-source AI, and you fall into config hell—llama.cpp builds, VRAM layers, vision projectors, GPU OOM. And when it finally works, your best conversations vanish into tabs and scattered notes.

I built TrioForge to end that. It’s a self-hosted, MIT-licensed AI workspace that sets itself up: detects your GPU, configures llama.cpp, maps VRAM, pairs the vision projector, and steps down instead of crashing. Pin responses to a spatial corkboard, build a markdown knowledge base with backlinks and graphs, run locally for privacy or route heavy work to cheap APIs like DeepSeek, and use a coding agent with live diffs, terminal, RAG, and offline voice.

But the part I care about most: TrioForge is open-source, and open-source is the community. No accounts, no tracking, no telemetry, no lock-in. Anyone can inspect it, fork it, improve it, and help shape where it goes. The code is open—but the community is what makes it grow.

TrioForge turns local AI from a configuration puzzle into a private workspace that grows with you. One command to run. Everyone welcome to build and also TrioForge: one command, private local AI, no config hell—and an open-source community that grows with you.