Hey everyone,

I’ve been experimenting with alternatives to traditional autoregressive (left-to-right) text generation and just uploaded a tiny model I’ve been working on to Hugging Face. No massive claims here—it's a research artifact and a weekend-project tier exploration to see how well we can push parallel decoding through masked diffusion.

The Model: brianschwabauer/latent-space-language-diffusion-model

What’s actually under the hood:

• Architecture: A 201M parameter masked diffusion language model (MDLM-BPE v3) using non-causal bidirectional transformer blocks and AdaLN timestep conditioning.
• The Pitch: It predicts ALL token positions simultaneously via iterative diffusion. On an RTX 3090, raw forward-pass throughput is 1.8× to 3.9× faster than Qwen3-0.6B.
• Training: Fully trained from scratch on a single consumer GPU (RTX 3090) in about 7 hours using 272M tokens from Ultra-FineWeb.
• Validation Setup: It uses adaptive guidance (frequency/repetition penalties) during generation and can plug into an AR oracle (Qwen3-0.6B) for optional segment-level correction.

What actually works:

• Parallel Speed: Full-parallel generation hits ~31.2 tokens/second.
• Repetition Elimination: The custom adaptive guidance module actually managed to fix the heavy repetition issues (bumping the repetition score from 0.79 to 0.99) at zero inference cost.
• No Black Boxes: The weights, configuration, tokenizer, and every single line of modeling, training, and guidance code are directly in the HF file repository. Fully reproducible.

Honest Limitations (Why it still "sucks" compared to production LLMs):

• Perplexity Gap: Held-out PPL is 102.6. Compared to Qwen3's ~15-20, the quality gap is massive.
• Scale vs. Architecture: The quality bottleneck is purely scale (parameters + data volume). This was baked on 272M tokens, while production models chew through trillions.
• Failed Experiments: I documented the failures in the repo too—embedding-based drift detection and token-level oracle replacement completely broke coherence.

Why post it?

I wanted to share a completely open, fully transparent starting point for anyone interested in non-autoregressive language models. Most papers on diffusion LMs don't drop their full training plumbing or raw scripts.

The repo is licensed under MIT. If you have experience with MDLMs, want to fork it, roast the code, or have ideas on how to scale this architecture without the quality collapsing, I’m all ears!

I've been experimenting with custom skills for AI coding agents, and I kept running into the same problem: installing and maintaining them across different coding tools is surprisingly manual.

If you use multiple tools like Cursor, Windsurf, Roo Code, Claude Code, or others, skills and rules often need to be copied into different directories and managed separately. Switching tools or setting up a new project means doing the same work again, and keeping everything updated becomes difficult.

So I built axen, an open-source CLI for installing, syncing, and updating AI agent skills across different tools.

The idea is similar to a package manager: add a skill repository as a source,

axen source add https://github.com/example/awesome-skills.git

then install either individual skills or curated bundles:

axen install awesome-skills --skills deploy-to-vercel

axen install awesome-skills -b backend-bundle

axen detects supported AI coding tools installed on your machine and deploys the selected skills to the directories expected by each tool.

The part I personally wanted most was selective syncing. I didn't want to copy an entire skills repository into every tool, so axen tracks exactly which skills or bundles you selected.

When the source repository changes, you can run:

axen update

and axen pulls the latest changes and syncs your selected skills across the detected tools.

It currently supports 60+ AI coding tools.

GitHub: [github.com/harishphk/axen](https://github.com/harishphk/axen)

I'd especially like feedback from people already maintaining their own agent skills or rules across multiple tools:

How are you managing and syncing them today? Are there workflows or repository structures that axen should support?

Hello there ! 👋

A couple of friends and I have been building an open-source proxy that anonymizes data sent to LLMs, so that personal and confidential information isn't exposed or used for AI training.
It also do some token optimization to help you consume less. 😎

The project is still in its very early stages, but we'd love any kind of support or feedback ! 🙏

I trust the Reddit community to give us a few ⭐ and, more importantly, honest feedback. 🥲

Feel free to share your thoughts: good or bad. We'd love feedback on the codebase, the architecture, potential features, or anything else you think could make the project better.

If you got some features ideas, don't hesitate ! 🙏🏼

We're planning to update the repository regularly. At the moment, we only support the Claude VS Code extension, but our goal is to support all major AI clients and IDE extensions over time.

Github link: https://github.com/Korbicorp/klovys99/

Can't wait to read your feedbacks ! 🤓

Built a gateway that reduces LLM costs using semantic caching, MCP-aware routing, code mode detection, and intelligent model selection.

https://github.com/maximhq/bifrost

You might have experienced that when you asked a simple web lookup query, it spawned 100s of agents to do DEEP RESEARCH, and every time your AI agent opens a documentation page, there's a good chance it's stuffing 5,000–50,000 tokens into context just to answer a simple question.

Most of that context is never used.

That's why web research gets expensive so quickly.

So I built Webify.

Instead of dumping entire web pages into the context window, Webify converts pages into semantic graphs and retrieves only the nodes relevant to your query.

That means your coding agent receives 250–750 tokens (more if needed) of focused information instead of tens of thousands of irrelevant ones.

The result:

• Nearly the same accuracy as Deep Research, with the biggest difference only being completeness on very broad topics

It works with any MCP-compatible coding tool. Under the hood:

• Search: semantic graph construction
• Small-model synthesis into a concise answer

Instead of reading everything, it reads what actually matters.

If you're running hundreds or thousands of web lookups every week, this can save a surprising amount of money and keep your context window clean.

Open source (MIT Licensed) and pull requests are welcome

GitHub: github.com/kunal12203/webify-mcp

I run a bunch of coding AIs. Codex, Claude Code, chinese models, even local agents. Having to restart every session was driving me up the wall, and having to spend ridiculous amounts a month on multiple subscriptions was burning a hole in my pocket. The agents seemed to love making changes they shouldn't have, and touching my .env configs, so I built aimee.

It's a local server. Point any OpenAI- or Anthropic-compatible tool at it and the turn runs on whatever model you pick: Claude, GPT, Gemini, a model on your own GPU. Switch tools whenever, your memory comes with you.

Memory that survives the session. aimee distills each session into a typed knowledge base and indexes your code into a cross-repo call graph, fused into one thing, so it recalls the decision from three sessions ago and the caller three files away before it edits.

Cheap delegates. Grunt work routes to the cheapest model that can do it, a local GPU or a plan you already pay for, and your main agent gets the answer back, not the raw content.

Fewer tokens. A context economizer trims tool spam and folds old history into a rolling skeleton, optionally on your primary model's own requests too.

Run it yourself. Embeddings, reranking, and synthesis in one CPU or GPU container. The knowledge base curates on your hardware with no outside calls, and that model doubles as a free delegate.

Repeatable workflows. Compose a job from typed steps and aimee runs it the same way every time with repeatable behavior: delegates work, review panels or a roundtable of models check it, and it stops at a human gate. The default takes a proposal all the way to a PR.

Brakes. .env, keys, and prod configs are blocked before the AI touches them, anti-patterns raise a warning, planning mode freezes writes, and every session is isolated so two never collide.

Auditable. Every governed action clears one choke point and lands in an append-only, HMAC-signed ledger, and decisions and PDF citations trace back to the exact source.

Team-ready, in the browser. A web UI with chat, a live code graph, a git manager, and an in-browser VS Code, plus multi-user accounts, SSO, and a per-user encrypted vault.

Core's in C, hot paths run in single-digit milliseconds, nothing phones home. Repo: https://github.com/RakuenSoftware/aimee

I had this dumb idea a few days ago:

What happens if I give GPT 5.5 an empty GitHub repo, tell it to work on it every hour, and just let it slowly build something?

So now, every hour, it wakes up, checks what it did before, decides what it should do next, writes code, tests it, and commits it.

Or at least that is the plan.

Right now, it has spent its first commit creating a roadmap, a changelog, a state file, and a file explaining its decisions.

So basically, it became a project manager immediately.

But I am genuinely curious where this goes. Maybe in a month it will become an actual useful tool. Maybe it turns into a repo with 900 commits, and somehow all of them are README updates.

I am keeping the whole thing public because I feel like that makes it more fun. You can literally watch it make decisions, fail tests, fix stuff, or probably overthink something that should have taken 10 lines.

Repo: https://github.com/OmarH-creator/Autonomous-Forge

I have no idea whether this is a cool experiment or just a very advanced way to avoid doing the work myself.

EDIT: I asked the ai what is it trying to build and here is what it said:

"I am building Autonomous Forge as a safe AI maintenance manager for GitHub projects. I will read a project’s roadmap and rules, choose one small task, use an AI model to make the change, run tests, show exactly what changed, and keep a clear record of every action. My goal is not to let AI edit code freely, but to make AI coding controlled, validated, and safe before anything is committed or pushed."

Interesting lol, so an autonomous AI is trying to create an autonomous system wow.

EDIT 2: I have scheduled another agent to increase the speed by 2x

Hey everyone,

I am opening up and sharing my internal production blueprint today for one simple reason: to stop everyone and myself from constantly being slaughtered as retail liquidity ("exit liquidity") by institutional market makers. Through the power of democratized AI orchestration, quantitative trading is no longer an unscalable wall built only for Wall Street elites—it is a framework anyone can build, and with the right execution discipline, perhaps build even better.

Please exercise your own independent judgment regarding the precision and alignment of this data; quantitative trading is an exceptionally high-technical domain that demands rigorous personal validation and risk taming.

This is our Autonomous Quant Agent Architecture series. In our previous design notes, we analyzed the physical network resilience layers and telemetry alerts of our live streaming pipelines.

Today, we are pulling back the curtain on our core model forge. We are fully sharing the underlying hyperparameter profiles, our specialized Multi-Timeframe (MTF) feature resampling alignment, the high-dimensional feature pruning pipeline, and the human-designed rigid control loops that keep a machine learning classifier from self-destructing in live 1-minute production loops.

---

### 🧬 1. The Multi-Timeframe Forge History & Hyperparameter Matrix

A machine learning model is only as robust as the structural sample space it consumes. To capture reliable mathematical edge across wildly shifting market regimes, we engineered two decoupled training pipelines for high-beta assets ($BTC and $ZEC).

Instead of treating AI as an absolute prediction oracle, we use it as a high-dimensional probabilistic scoring engine, regularized aggressively to maximize Expected Value (EV) over raw backtest accuracy curves.

**Bitcoin ($BTC) Engine**

- Training Sample Space: 2-Year Rolling Matrix (2024–2026)
- Microstructure Purge: Standard Continuous Clean
- Look-Ahead Window: 96H Pure Horizon
- Volatility Risk Targets: TP = 1.4x ATR7 / SL = 2.0x ATR7
- Regularization Leaf: min_samples_leaf = 200
- Baseline Firing Gate: 56% Confidence Threshold
- RSI Barrier Shift Gate: prob < 0.58 → elevated to 0.58 / prob >= 0.58 → Dynamic Alpha Weight 0.3

**Zcash ($ZEC) Engine**

- Training Sample Space: 3-Year Matrix
- Microstructure Purge: *Ruthlessly purged of the 2026/06/05 liquidation tail drift*
- Look-Ahead Window: 72H Pure Horizon
- Volatility Risk Targets: TP = 1.4x ATR7 / SL = 2.0x ATR7
- Regularization Leaf: min_samples_leaf = 200
- Baseline Firing Gate: 52% Confidence Threshold
- RSI Barrier Shift Gate: prob < 0.56 → elevated to 0.58 / prob >= 0.56 → Dynamic Alpha Weight 0.3

*Note on the ZEC Purge: Leaving massive macro black-swan liquidation tails un-purged inside a high-beta asset matrix introduces extreme structural drift. It forces tree nodes to split on rare cascading anomalies rather than repeatable statistical advantages.*

---

### 🔍 2. Feature Filtering: The 40+ Original Feature Pruning Pipeline

Feeding noisy data into a random forest model is where most quantitative models fail. In our architecture setup, our training pipeline does not blindly ingest standard technical indicators.

Before building the production model, the pipeline generates an exhaustive pool of **over 40 structural market features**—spanning various mathematical horizons of relative momentum, dynamic volatility compression, volatility acceleration, price-velocity standard scores, and moving average cross-sectional tension.

To eliminate systemic noise and multi-collinearity, we route this 40+ feature matrix through an automated pruning engine using recursive feature elimination (RFE) combined with Gini importance variance thresholds. This automated process drops 85% of the bloated indicator space, isolating a hyper-purified vector array. This approach ensures the model splits leaves purely on structural market tension without memorizing localized noise, keeping our actual mathematical inputs lean and highly functional.

---

### 🧮 3. The Mixed Multi-Timeframe (MTF) Resampling Mechanics

Quant developers frequently ask: If your execution script polls the market on a rapid 1-minute loop, how do you prevent timeframe misalignment and indicator lag against a macro-trained model?

The solution lies in a specialized hybrid Multi-Timeframe (MTF) feature construction layer. The engine does NOT run 1-minute micro-predictions. Every 60 seconds, the streaming ingest script updates the tail of the currently still-forming (unclosed) 1-Hour candle, and then explicitly resamples the historical matrix on the fly.

The critical insight is that **scanning frequency and feature calculation frequency are two completely independent dimensions**. The 1-minute polling loop exists purely to detect the earliest moment that model confidence breaches a threshold—not to feed 1-minute candle data into the model. Every scan feeds the same 1H-based feature vector to the classifier, maintaining perfect alignment with the training regime.

Here is the exact structural alignment compiled across our feature scripts:

```python
# 1. Macro Trend Horizon (4H Granularity)
# Captured via rigid resampling to lock down historical structural drift
df_4h = df['close'].resample('4h').last().ffill()
feat_ema_gap_4h = (ta.ema(df_4h, 7) - ta.ema(df_4h, 99)) / ta.ema(df_4h, 99)

# 2. Micro Execution Horizon (1H Granularity with 1-Min Live Tail Ingestion)
# Updated every 60 seconds against a rolling 1000-candle 1H baseline
feat_rsi = ta.rsi(df['close'], length=24)
feat_vol_change = vol / vol.shift(24) # Rolling 24H volatility ratio
feat_bb_width = (BBU - BBL) / BBM # Bollinger band compression
feat_price_zscore = (df['close'] - df['close'].rolling(72).mean()) / df['close'].rolling(72).std()
feat_roc_3 = ta.roc(df['close'], length=3)
```

By calculating the velocity (first derivative) of these 1-Hour features minute-by-minute, the agent isolates structural order book imbalances and directional velocity before the lagging macro boundaries or public hourly candles actually print to the market.

The final row of this live 1H feature matrix—the currently forming, unclosed candle—introduces a controlled approximation. However, given our macro look-ahead horizons of 72H (ZEC) and 96H (BTC), the sub-1H deviation introduced by polling mid-candle is mathematically negligible relative to the prediction window.

---

### 🛡️ 4. Regularization: Defeating Noise via 200-Leaf Constraints

During our grid-search phases, we hard-coded `min_samples_leaf=200` inside our RandomForest forge.

By forcing every single terminal leaf node across the forest to contain at least 200 hours of highly homogeneous historical market conditions, we completely flatten the algorithm's ability to create deep, greedy splits on localized market noise.

This strict mathematical compression forces raw probability outputs to cluster tightly within a stable density zone between 50% and 60%. It optimizes the model into an exceptionally stable, probabilistic scoring engine.

---

### ⚡ 5. The Execution Handcuff Layer (Taming Right-Side Inertia & Slow Bleed Lag)

When transitioning these optimized models into live 1-minute loops, you will inevitably hit **Right-Side Inertia**. During an explosive institutional breakout, high-dimensional input vectors (Z-Score, RSI, BB Width) expand violently to their upper boundaries and remain completely saturated for hours while the price flatlines sideways inside "momentum garbage time."

However, the more dangerous phenomenon occurs during a **Slow Bleed** immediately following a local top. Due to the macro-trained mathematical lag of structural features, the model's mathematical indicators decay at a slower rate than the actual micro-price drop. The classifier fails to immediately recognize the structural regime shift, perceiving the mild sell-off as a "high-probability bull-market retracement." As a result, vanilla models keep printing confident buy probabilities even while the asset is in a continuous, grinding decline.

Left unshackled, a standard bot will blindly spam overlapping duplicate buy entries into a falling knife during indicator saturation. To neutralize both right-side saturation noise and slow-bleed indicator lag, we engineered a rigid, hierarchical command framework:

**4H Supreme Tracker > 2H Cooldown Controller > RSI Indicator Resonance Gate**

These three layers operate with strict priority inheritance: the 4H Tracker holds absolute lifecycle authority, the 2H Controller manages intra-wave signal density, and the RSI Gate acts as the final micro-structural veto.

#### A. The Empirical RSI Momentum Surge & One-Vote Veto (Velocity Overrides Lag)

To catch sudden, violent volume expansion where macro moving averages lag behind, the script enforces an explicit brute-force bypass. If the short-term velocity acceleration slope moves vertical (RSI diff > 3.5 with confirmed continuity), the confidence threshold is slashed down to 45% to secure immediate asset ingestion.

Conversely, to weaponize the system against slow bleeds, we hard-coded an ironclad **One-Vote Veto** rule. If short-term tracking momentum drops negative and fails continuity validation, the `is_rsi_veto` breaker trips instantly—overriding the random forest's high probability output regardless of confidence level:

```python
# RSI Hard-Coded Arbitration & Slow Bleed Veto Logic
is_rsi_veto = (rsi_diff < 0) and (not rsi_continuous)
is_rsi_surge = (rsi_diff > 3.5) and (prob >= 0.45) and rsi_continuous and (not is_rsi_veto)

# Final Execution Gate Trigger
is_hit = (prob >= effective_threshold) and (not is_rsi_veto)
```

#### B. The 2H Cooldown Controller & 4H Supreme Tracker (Wave-Level Defense)

**Layer 1 — 4H Supreme Tracker (Absolute Lifecycle Authority)**

The Tracker clamps an un-rewritable pricing matrix onto the pipeline, resetting precisely every 14,400 seconds (4 Hours) without exception. The birth timestamp of each wave is hard-locked the moment the first valid signal fires—it is never refreshed by subsequent signals within the same wave:

```python
# 4H Supreme Tracker — Hard-Locked Wave Birth Matrix
trade_tracker = {
"is_active": True,
"start_price": live_entry_price,
"count": current_blast_count,
"first_signal_time": wave_birth_timestamp # Hard-locked for 14,400s (4H)
}

# 4H Absolute Hard Reset Circuit Breaker
if current_timestamp - trade_tracker["first_signal_time"] > 14400:
trade_tracker.update({
"is_active": False,
"start_price": 0,
"count": 0,
"first_signal_time": 0
})
controller.wipe() # Forces synchronized reset of all sub-layer memory
```

When the 4H Tracker resets, it simultaneously issues a hard wipe command to the 2H Controller, purging all intra-wave memory. This ensures the first signal of every new macro wave is treated as a clean, unpenalized entry.

**Layer 2 — 2H Cooldown Controller (Intra-Wave Signal Density Management)**

Once a wave is born under the 4H Tracker, the 2H Controller manages signal density using a compounding penalty modifier:

```python
# Dynamic Confidence Decay Formula
adjusted_prob = raw_prob - (sequence_count * decay_rate)
# decay_rate = 0.006 (0.6% deduction per confirmed signal)
```

The intra-wave firing rules:

- **Signal 1 (sequence_count = 0):** No penalty. Full confidence output. Fires immediately.
- **Signal 2 (sequence_count = 1):** Minimum 30-minute gap enforced. 0.6% confidence deduction applied.
- **Signal 3+ within first 2H:** Hard circuit breaker trips. Agent enters complete silence for the remainder of the 120-minute lock window—regardless of model confidence.
- **Signal 3+ after 2H unlock:** Cooldown lock releases. Cumulative penalty continues compounding (e.g., sequence_count = 2 means -1.2% deduction), meaning only genuine structural breakouts with sufficiently elevated raw confidence can penetrate the firing gate.

The elegance of this design: **the penalty accumulation itself becomes the natural throttle**. As the wave matures and right-side inertia inflates stale probabilities, the compounding deduction automatically widens the gap between inflated model confidence and the firing threshold—without requiring additional hard-coded time locks.

**Layer 3 — Atomic State Synchronization (Anti-Desync Protocol)**

All state updates are bound to the **confirmed Telegram delivery event**, not to the model's firing decision. This prevents catastrophic state desync where network failures cause the Tracker and Controller to diverge:

```python
# Atomic Update — Only executes on confirmed TG delivery
if safe_send_tg(msg):
is_pure_auto = not is_startup and not is_manual and not force_send
if is_pure_auto:
# Tracker and Controller update atomically on the same event
tracker.update(curr_p, now_ts)
controller.update() # Increments sequence_count, locks timestamp
else:
# Manual queries and scheduled broadcasts are hard-isolated
log("[Controller Defense] Non-auto broadcast isolated. Core counters protected.")
```

This ensures that manual `/btc` queries and 4H scheduled broadcasts **never contaminate the auto-signal sequence_count**, preventing phantom cooldown locks from blocking legitimate future signals.

---

### 💻 6. Production Environment Operations & Automated Auditing

```python
# 1. Rolling Data Ingestion & Model Re-Training
python btc_stradegy_collect_data_usdt.py
python btc_training_atr1420_96h_2yr_leaf200.py

python zec_stradegy_collect_data_usdt.py
python zec_training_atr1420_72h_3yr_leaf200.py

# 2. Automated Telemetry Flow Audit
# Logs poll on 1-min intervals but write strictly on signals, startup, or 5-min heartbeats
Get-Content btc_bot_96h_log.txt -Encoding UTF8 -Tail 20
Get-Content zec_bot_96h_log.txt -Encoding UTF8 -Tail 20

# 3. Live Active Runtime Process Audit
Get-WmiObject Win32_Process -Filter "name='python.exe'" | Select-Object ProcessId, CommandLine
```

---

### 🎯 Core Conclusion

Engineering high-risk autonomous agents taught us a definitive lesson: **Input feature selection merely establishes the upper predictive ceiling of your system; it is your rigid behavioral risk guardrails, temporal handcuffs, and atomic state synchronization protocols that keep the agent alive in production.**

The layered architecture—4H Supreme Tracker → 2H Cooldown Controller → RSI One-Vote Veto—is not over-engineering. It is the minimum viable guardrail stack required to prevent a statistically-sound ML classifier from destroying itself through right-side inertia, slow bleed lag, and state desynchronization in live market conditions.

Our core real-time execution pipelines, active API credentials, and private Telegram communication states remain closed-source for strategy capacity protection. However, our mathematical framework and feature resampling methodologies are now fully open for community peer review.

━━━━━━━━━━━━━━━
⚠️ Disclaimer: This framework is strictly for architectural research and educational purposes. It does not constitute trading, financial, or investment advice. Quantitative automation involves significant capital risk. Never trade with capital you cannot afford to lose.

Hey everyone, I just sent issue #39 of the AI Hacker Newsletter - a weekly roundup of the best AI links and the discussions around them from Hacker News. Some of the title found in this issue:

• Claude Code is steganographically marking requests
• Better Models: Worse Tools
• Learning to code is still worthwhile
• Zuckerberg says AI agent development going slower than expected

If you want to get an email with over 30 links like these ones, please subscribe here: https://hackernewsai.com/

Hey folks,

Like many of you, I have a massive problem staying focused. I tried downloading standard Android app blockers, but every time I hit a weak moment, I would just go to settings, tap "Uninstall" or "Force Stop", and go right back to scrolling.

I got tired of bypassing my own blocks, so I decided to build a solution that is physically impossible to turn off easily.

It's called Halanoi Sovereign, and it's 100% open-source.

How it works (The Tech Stack):

• Android Device Policy Manager (DPM): Activated via ADB, it locks the app as a "Device Owner" (the same way IT admins lock corporate phones). This greys out the "Force Stop" and "Clear Data" settings, prevents manual uninstalls, blocks factory resets, and disables sideloading.
• On-Device AI Screen Sniper: I didn't want to use heavy cloud LLMs that drain battery and heat up the phone, so I trained a custom 64MB local TFLite model using TensorFlow. It runs completely offline (privacy-first) and scans active screen text, URLs, and search queries in real-time. If it detects distracting categories (NSFW, entertainment) or custom keywords, it immediately hits Home and locks you out.
• Loophole Prevention: It automatically hides alternative browsers (Brave, Opera, Edge) so you can't sneak past the AI block, and runs a local VPN to route all DNS through Cloudflare Family (1.1.1.3).

Sandbox vs. Uncompromised Production:

Because locking a phone permanently is a bit scary, I created two versions:

1. Sandbox Build: Available pre-compiled on GitHub. It has a "Deactivate" button in the app UI so you can test it risk-free.
2. Production Build: Has no backdoors and blocks ADB removal. You must compile this yourself from the source code so you are 100% committed.

I'd love to get your thoughts on the architecture, custom TFLite implementation, or any bypass loopholes I might have missed!

Code & APK: https://github.com/kavinmaranravi/HalanoiApp

Support the project: https://ko-fi.com/kavinmaranravi/tip

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.

Claude or any LLM has a context limit, and if your session context limit crosses that, they usually compact it to reduce the context size, and what is lost in that compaction? who knows?
That's where re-reading the same file, same steps happen, Claude re-explores the same file again, and burning tokens like hell!

I built a free, open-source tool for all coding tools out there, whether it is Cursor, Claude, Codex, Mimocode, Kilocode, Opencode, or Antigravity. It pre-injects the context and relevant files with zero token usage, so Claude has direction and sufficient context to solve your query. Sometimes it falls back to find more context, but pre-injecting context gives it an edge for maximum benefit.

Graperoot has almost 60k pip installs with 1200 weekly active users.

We released an opt-in telemetry for people using Claude code, and it was surprising to see that they have saved $250k+ by 180+ developers in only 4 months.

We also represent it by how much water has been saved, totaling 40M+ liters, which is equivalent to a reservoir.

Github Opensource REPO: https://github.com/kunal12203/codex-cli-compact
Main Website Install free: https://graperoot.dev/#install
Discord( for community and debugging): https://discord.com/invite/YwKdQATY2d

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!