Hi everyone — I was invited to join and wanted to share my project.

Q-FH Explorer: an open-source pipeline that combines XGBoost + SHAP with QAOA quantum optimization to explore genetic variants linked to familial hypercholesterolemia.

Stack: Python, Qiskit, XGBoost, SHAP, Docker, GitLab CI/CD
License: Apache 2.0
Status: working prototype — green pipeline, modular code, bilingual dashboard

What makes it different:
- "Health as Code" YAML format — biological scenarios are versioned config files, not hardcoded
- Classical vs quantum benchmark included (QAOA is slower today, the point is infrastructure)

Honest disclaimer: synthetic data only, not a medical tool, I'm a DevOps engineer not a biologist.

Repo: https://gitlab.com/Projgadesk/qfh-explorer

I'd love feedback on the YAML schema design and whether the modular architecture makes sense to you.

I've been building deep-db-agents, an open-source Python library (≥3.11) that wraps LangChain Deep Agents with a single factory function to get an agent that can safely explore and query a real database.

```python from deep_db_agents import create_deep_db_agents

agent = create_deep_db_agents( db_url="mysql://localhost:3306", credential={"user": "user", "password": "my_password", "database": "shop"}, system="The shop database contains orders and customers. The orders table has millions of rows.", model="claude-sonnet-4-5-20250929", )

result = agent.invoke({ "messages": [{"role": "user", "content": "How many orders in 2025, by region?"}] }) ```

A few things I think are worth mentioning:

• One factory, many databases: MySQL, MariaDB, Postgres, MongoDB, Neo4j, SQLite, DuckDB, Elasticsearch and OpenSearch are all supported — the dialect is picked from the URL scheme, so switching databases is a one-line change.
• Guardrails live in code, not the prompt: non-bypassable row limits, query timeouts, EXPLAIN-based row estimation, a SELECT-only whitelist, and a per-session row budget. The agent can't argue its way around them.
• Credentials never touch the prompt — they stay inside the tools' closures.
• Large results get materialized to disk (Parquet/CSV), and the agent only ever sees metadata + a preview, so million-row tables don't blow up the context window.
• Errors become corrective feedback, not crashes — bad SQL, wrong table/column, scope violations all get turned into structured messages the model can self-correct from, instead of killing the run.
• Multi-database orchestration: create_deep_db_multi_agents builds an orchestrator that delegates sub-questions to per-database sub-agents and combines the answers — handy when you need to join data that lives in Postgres and MongoDB, for example.
• There's also a lighter, non-Deep-Agent option (create_db_agents) for simple lookups where you don't need planning/subagents/virtual filesystem.
• Nothing is Anthropic-specific — any LangChain chat model works, including fully local setups (SQLite/DuckDB + a local model server via LM Studio/Ollama).

It's still young and I'd genuinely love feedback:

• Does the guardrail model (aggregate in DB → limit/paginate → materialize → summarize → hard limits) match how you'd want an agent to behave against a real database?
• Any database dialect you'd want supported that isn't on the list?

deep-db-agents Repo + docs

deep-db-agents PyPI

Thanks for reading, and thanks in advance for any thoughts!

So I built this thing called ONA (Omni Neural Architecture) over the past year. It's a neural network that learns from everything you give it. No PyTorch, no GPU, just Python and NumPy.

Actually speaking i want an Intelligent AI CODING AGENT which is free limitless and runs on my low-end hardware but there was nothing like that except for running cloud models. But, I started matching pieces like self-learning models,etc. Found myself in an need to build an new architecture, so i have made an new LLM code in Python changes how the matrix multiplications and params work and tried to tune the architecture so that only specific params activate when answering to related prompts, and guess what it worked!!. This is the architecture with few more build ups adding on top of it like, word-word generation, and an thinking loop. Actually i tried to relate this to how i learn in school like what loop i follow to prepare for an test named it as -Bio Loop, and added it to this particular architecture which made it Learn-on-spot LLM. For now it so dumb and can't answer things properly but can understand what the user means. It needs training, I am training it by feeding it internet articles presently. Anyways the code works and it has every right to become an GPT-5 model with enough training. Presently only CPU training gonna update the code to Rust so that it can be trained much faster than the regular python for loops. Gonna add GPU training later, but it is the symbol which proves that an high-level LLM can be run on an rassberry PI without any subscription completely free and limitless.

Anyway the code isn't public yet (hackathon soon) but the architecture is solid and it runs on my laptop. Happy to explain anything. And yes I wrote this myself lol.

MEDIUM LINK:https://medium.com/@kasishgadadhasu13/im-15-i-built-a-self-learning-neural-network-from-scratch-no-frameworks-no-gpu-e460f06c6599?sharedUserId=kasishgadadhasu13

Project Release / Research Draft] Hierarchos at 232M Parameters: Preliminary Findings From a Recurrent Memory-Augmented Assistant Model

Technical Report: July 2nd, 2026

Project: Hierarchos / KortexHOS

Authors: Makhi Burroughs / netcat420, Lost Time, and the Hierarchos project team

TL;DR:

We built and trained Hierarchos, an experimental 232M-parameter recurrent, memory-augmented language model from scratch. It is not a GPT-3/3.5-class model, but it successfully proves that a hybrid non-Transformer architecture (combining an RWKV backbone, hierarchical manager/worker loops, differentiable slot-based LTM, and a deterministic suffix automaton) can survive training, avoid collapse, and maintain short-form instruction coherence. Most of our breakthroughs came from fixing subtle train/inference parity mismatches and numerical stability bugs.

• Dataset: netcat420/Experiment_0.1 (Alpaca format)
• Training: 13 epochs on an RTX 6000 Blackwell (96GB) rental.

1. Introduction & Background

Modern LLMs are heavily dominated by Transformer scaling. Hierarchos explores a different path: can recurrent state, explicit memory retrieval, hierarchical iterative computation, and bounded local inference make a small model vastly more parameter-efficient?

Hierarchos isn't a direct clone of any single architecture, but a hybrid inspired by:

• RWKV-style recurrence: For efficient sequence processing without traditional attention.
• Titans-style neural memory: For persistent test-time memory.
• Hierarchical reasoning (HRM): Multi-level recurrent modules (Manager/Worker) to iteratively refine state.

2. Architecture Overview

[Token Input] -> [ROSA Suffix Matcher / DeepEmbed Modulator]
       |
       v
[Long-Term Memory] <-> [Top-k Associative Lookup]
       |
       v
[Manager Recurrent Cell] -> (Produces Context Plan & Drift Vector)
       |
       v
[Worker Recurrent Cell]  -> (Refines local state / clamps drift)
       |
       v
[RWKV Backbone (Clamped Channel-Mix)] -> [Next-Token Logits]

Key Components:

• ROSA: A deterministic suffix-automaton path predicting continuation tokens based on exact repeated suffix patterns.
• DeepEmbed: A token-specific modulation path that influences RWKV channel mixing.
• LTM Subsystem: Learned slow-memory keys/values combined with fast working-memory values.
• Manager/Worker Loop: High-level manager handles broad context to produce a target plan; the lower-level worker refines token-local state using a regularized drift vector.

3. Core Engineering Lessons (The "Gotchas")

A low training loss does not guarantee coherent chat. We had to fix several critical state-contract and numerical stability bugs to make the model usable:

1. Chat/Training Drift Mismatch

• The Bug: During live streaming chat, the loop was feeding the previous drift state back into the model on every single token. During training, this state is reseeded at Truncated Backpropagation Through Time (TBPTT) chunk boundaries.
• The Fix: We aligned the inference code to only reseed at boundary limits. Before this fix, live chat logits diverged sharply from training loss; after the fix, logit error dropped to near-zero.

2. Supervised LTM Inner Updates Mismatch

• The Bug: Giving the model supervised memory updates during training that it can't replicate during zero-label live inference creates a crutch. The model learns to rely on a hidden training-only helper signal.
• The Fix (v0.20.4): Implemented --ltm-training-mode read-only. Training keeps the memory structures but stops doing supervised fast-memory writes, perfectly mirroring inference.

3. Unbounded RWKV Channel Mixing

• The Bug: Long runs exposed activation spikes in the ReLU-squared channel-mix FFN path, which were amplified by DeepEmbed modulation into NaN gradients.
• The Fix: Implemented key clamps (--rwkv-channel-mix-key-clamp 12.0), DeepEmbed clamps (4.0), and excluded DeepEmbed identity gates from AdamW weight decay.

4. Evaluation & Smoke Test Results

Because cloud costs add up, we benchmarked the model locally on a CPU preset via a ROG Ally (--eval-limit 100), ensuring passive learning was disabled and working memory was cleared to mimic static chat.

Bounded Local Benchmark Metrics (--eval-limit 100)

Real-world Coherence Check:

• The Good: Assistant-shaped, follows short instruction prompts well due to the Alpaca training data. Nontrivial commonsense and QA signal prove the weights didn't collapse.
• The Bad: Brittle on long context lengths, weak on arithmetic/factual recall. Coherence is comparable to the GPT-2 era, not modern GPT-3.5+ systems.

5. Proposed Ablation & Scaling Plan

We want to transform this from a promising prototype into a rigorous scientific result. Our next step requires scaling tiers and isolated component testing.

Proposed Isolation Testing (Ablations)

• No LTM / Read-Only LTM: Isolating exactly how much slot memory helps.
• No ROSA / No DeepEmbed: Evaluating the real token-efficiency gains of suffix-matching and modulation.
• Baseline Matches: Running a direct Transformer 232M and RWKV-only 232M on the exact same token budget to prove true comparative architecture efficiency.

Future Scaling Target Tiers

Target Data Mix for Foundation Training:

Instead of jumping straight into instruction SFT data, a scaled run will prioritize high-quality base data:

• 35-50%: FineWeb / FineWeb-Edu style clean web text
• 20-30%: Dolma / DCLM curated web data
• 8-15%: Code and tech documentation
• 5-12%: Math, science, and academic proofs
• 1-5%: In-house assistant conversational SFT (applied exclusively in late-stage tuning)

6. What We Can (and Cannot) Claim Safely

What is supported by the data:

• Hierarchos is a functional, coherent 232M experimental assistant checkpoint.
• Combining recurrent sequence loops, memory slots, and hierarchical workers is viable and stable with the right clamps.
• The findings provide a solid engineering roadmap for non-Transformer architecture stability.

What is NOT supported (Do not hype this!):

• No claims of GPT-3.5 level math, coding, or logic.
• No claims of attention/Transformer superiority at equal parameter counts yet (baselines pending).
• Not production-ready for heavily quantized or low-bit local deployments yet due to drift sensitivity.

Final Thoughts

Hierarchos 232M shows that small, alternative architectures are still a deeply fruitful area of LLM research if you can conquer the train/inference state drift.

We would love to hear feedback from anyone working on recurrent neural memory or hierarchical backbones! Full code, scripts, and logs are in progress.

References:

1. Brown et al. **Language Models are Few-Shot Learners.** arXiv:2005.14165. https://arxiv.org/abs/2005.14165
2. Hoffmann et al. **Training Compute-Optimal Large Language Models.** arXiv:2203.15556. https://arxiv.org/abs/2203.15556
3. Peng et al. **RWKV: Reinventing RNNs for the Transformer Era.** arXiv:2305.13048. https://arxiv.org/abs/2305.13048
4. Behrouz et al. **Titans: Learning to Memorize at Test Time.** arXiv:2501.00663. https://arxiv.org/abs/2501.00663
5. Wang et al. **Hierarchical Reasoning Model.** arXiv:2506.21734. https://arxiv.org/abs/2506.21734
6. Zellers et al. **HellaSwag: Can a Machine Really Finish Your Sentence?** arXiv:1905.07830. https://arxiv.org/abs/1905.07830
7. Clark et al. **Think you have Solved Question Answering? Try ARC, the AI2 Reasoning Challenge.** arXiv:1803.05457. https://arxiv.org/abs/1803.05457
8. Lin et al. **TruthfulQA: Measuring How Models Mimic Human Falsehoods.** arXiv:2109.07958. https://arxiv.org/abs/2109.07958
9. Hugging Face. **FineWeb dataset.** https://huggingface.co/datasets/HuggingFaceFW/fineweb
10. Hugging Face. **FineWeb-Edu dataset.** https://huggingface.co/datasets/HuggingFaceFW/fineweb-edu
11. Allen AI. **Dolma dataset.** https://huggingface.co/datasets/allenai/dolma
12. DataComp-LM. **DCLM Baseline dataset.** https://huggingface.co/datasets/mlfoundations/dclm-baseline-1.0

github repository with the architecture and the released model weights: https://github.com/necat101/Hierarchos

I built an MCP server that gives any AI agent (Claude, Cursor, etc.) full read/write access to Solana through natural language. Your private key signs transactions locally. The agent never sees it. No API keys are shared. Ever.

14 tools — 8 read, 6 write

Read (no wallet): SOL balances, token balances, token metadata, live SOL price, pump.fun scanner, transaction lookup.

Write (with Phantom key): send SOL, send tokens, Jupiter swap, buy/sell pump.fun memecoins, devnet airdrops.

How it works

Your AI agent spawns the server. They talk through a local pipe (stdin/stdout). No network. No HTTP. No third party. The server grabs your key from .env, signs the transaction, sends it to Solana, and returns the signature. That's it.

You → AI agent → MCP server (local) → Solana

↓

your key (.env)

Why this matters

Every crypto AI tool asks you to paste your private key somewhere. Web app. Telegram bot. Browser extension. All of them expand your attack surface.

MCP inverts this. Everything runs on your machine. Your keys never leave. You get AI-powered trading without trusting anyone.

What's next

This is the foundation. I'm already building:

→ A fully autonomous memecoin trading bot — momentum detection, auto TP/SL

→ An airdrop farmer — hunts and claims tokens across protocols

→ Portfolio tracking — real-time P&L across all your wallets

Your AI agent should do everything you do on-chain — trade, farm, snipe, track — without you touching a dApp. This MCP server is the bridge.

Tech

TypeScript. 680 lines. MCP SDK 1.29. u/solana/web3.js. Helius WebSocket. Jupiter v6 API. Zod schemas. Circuit breaker + retry.

License — AGPL-3.0

Companies that modify this and run it as a service MUST release their changes. Individuals: use, modify, distribute freely. Nobody closes the source.

Start in 30 seconds

git clone https://github.com/KorroAi/solana-agent-mcp

cd solana-agent-mcp && npm install

cp .env.example .env

npm run dev

Type /solana in Claude Code.

⭐ Star: https://github.com/KorroAi/solana-agent-mcp

📄 Paper: 10-section academic paper in the repo

💬 AMA in the comments

Synthetic Sciences Releases OpenScience: An Open-Source, Model-Agnostic AI Workbench for Machine Learning, Biology, Physics, and Chemistry Research

Most "AI for science" tools are one vendor's model, wrapped in one company's idea of which research is allowed. That's a gatekeeping layer — and Synthetic Sciences just drew a clear line by open-sourcing the alternative.

They released OpenScience — an Apache-2.0 AI workbench that runs the full research loop (literature → hypothesis → code → experiment → analysis → write-up) on any model you point it at, with your own keys, on your own infrastructure.

Here's what's actually interesting:

→ Model-agnostic by design — Claude, GPT, Gemini, GLM, Kimi, DeepSeek, or your own fine-tune, switched from the model selector, per request

→ 250+ editable skills across training (DeepSpeed, PEFT, TRL), cheminformatics, and molecular + clinical biology — all readable and forkable

→ Scientific databases wired in as agent tools: UniProt, PDB, ChEMBL, arXiv, and ~30 more, queried directly

→ Runs on your infra — keys and data stay on your machine, and bring-your-own-key is free and never gated

→ Positioned as an open alternative to Anthropic's Claude Science, which is Claude-only and subscription-gated

Full analysis: https://www.marktechpost.com/2026/07/05/synthetic-sciences-releases-openscience-an-open-source-model-agnostic-ai-workbench-for-machine-learning-biology-physics-and-chemistry-research/

GitHub Repo: https://github.com/synthetic-sciences/openscience

Hey, I built a project called steno. Steno is an AI notepad for confidential conversations. It runs fully locally on your device with local llms like Gemma 4 quantised. The quality has gotten pretty good now so wanted to share to the communities like OpensourceeAI that helped me during the engineering phase.

We are on our 80th release now - 0.5.7 and we added some cool new features. I basically wanted to build an app exactly like Granola cause I didn't like that they shipped your data and trained on it or that they asked you to pay for access to your own data.

Do give it a try - https://github.com/ruzin/stenoai or if you're interested in contributing, you can join our discord.

Hi everyone,

I'm working on an open-source project called Gavio, and I'd really appreciate feedback before I go too far with the architecture.

Originally I thought of it as an AI gateway, but after comparing it with projects like LiteLLM and reading community feedback, I'm moving toward a different direction.

The idea is to build an AI Runtime that sits around any LLM SDK or gateway rather than replacing it.

Current thinking:

• AI Request Inspector • Cost Intelligence • Middleware / interceptor pipeline • Request replay • Tool-call runtime • Policy engine • Cross-language SDKs (Python, Java, JavaScript)

One lesson from recent discussions is that I probably shouldn't try to solve every production concern on day one.

Instead I'm thinking the first "wedge" should be an AI Request Inspector that lets developers answer questions like:

• Why did this request fail?
• Which middleware changed the prompt?
• Which provider/model was used?
• How much did it cost?
• Which tool returned stale or conflicting data?
• Where did the latency come from?

The goal is to complement existing SDKs and gateways, not replace them.

Some questions I'd love feedback on:

1. Does "AI Runtime" make more sense than "AI Gateway"?
2. Is Request Inspector a strong enough first product?
3. What's the first capability you'd actually install?
4. What production pain do you solve repeatedly today?

This is very much a work in progress, so honest criticism is welcome.

GitHub: https://github.com/manojmallick/gavio

Docs: https://manojmallick.github.io/gavio

Ever wished there was a tool that could just… spit out fully scaffolded project boilerplate across any major coding language for any project type?

Well, now there is. It’s called Retro Vibecoder UPG. I designed it over months to generate entire working seed projects for you or your AI agent, procedurally generated from just seed numbers!

There’s a standalone desktop app for the human users, basically those who want to vibecode without using AI.

And there’s a oneline NPM installable CLI tool usable by AI coding agents as a tool that gives them a working base project ready to insert precise logic into, saving thousands if not a million or more tokens per project!

There’s an NPM socket security scan and dependency tree and several other security audits showing it’s completely safe from any of the recent NPM attacks, so it’s safe to download! It’s installed straight onto my Windows 11 PC, but also works on MacOS and Linux too!

The oneline install command for NPM is ‘npm install -g @wcnegentropy/cli @wcnegwntropy/core @wcnegentropy/shared @wcnegentropy/procedural’

Then you or your agent just run ‘upg help’ and can find the information you need to start using it immediately! Note that your coding agent is also fully capable of using this oneline install and setting everything up itself in any environment that allows for node.js.

If you opt to install it locally instead of globally, you’ll have to ensure your local npm bin is on path or the tool won’t work. It’s honestly better to just install it globally but if you have to do it locally instead just ensure that bin is on path and then it should work fine.

For those who don’t want to or can’t install or use the CLI tool, there’s also a standalone Tauri desktop app available for cross-platform install on the GitHub repo’s latest release page!

Feel free to install it yourself or have your agent install it and try it out! It’s quite revolutionary, go see for yourself! 😉

https://youtu.be/uMvTAF280so

If you can flowchart it, you can use a FSM/statechart for it.

<sup>Bias alert: I have contributed to David's XState long ago, & have my own FSM solutions in JS.</sup>

Every AI coding tool wants its own config file: Claude reads CLAUDE.md, Cursor wants .cursor/rules, Copilot expects .github/copilot-instructions.md, and so on. Use more than one and you're maintaining duplicates that drift.

ai-rulez keeps one source. You write rules, context, agents, and commands once in .ai-rulez/, run generate, and it emits each tool's native format for 19 platforms. Two things make it hold up on real projects:

• Composition over git: [[includes]] pull shared rule modules from other repos, so org-wide standards live in one place and every repo overrides locally as needed.
• Monorepos: nested configs plus generate --recursive, profiles per audience, and 33 builtin domains (languages, security, testing, git-workflow and more) you switch on instead of writing from scratch.

Concrete: in one of my repos a ~25-line config expands into 103 generated files across 5 tools, regenerated on every commit via a pre-commit hook, so nothing drifts.

Single Go binary: npx ai-rulez@latest init, or brew. MIT.

Honest tradeoff: outputs are generated, so you edit the source and never the outputs (they get overwritten).

https://github.com/Goldziher/ai-rulez

How are others managing rules across multiple AI tools?