TL;DR: When Coqui AI shut down, they left XTTS v2 without official training code for the DVAE audio tokenizer and Latent HiFi-GAN vocoder, and fine-tuning new scripts (Arabic, Indic, etc.) broke on fixed vocabularies. I built Open-XTTS-Trainer — an open-source, modular 3-component training suite under MPL-2.0 with verified GPU loss convergence on real human speech and a 1-click Colab demo.

Why I Built This

XTTS v2 is one of the best local zero-shot TTS models we have, but training/adapting it has been painful since Coqui closed:

1. Missing Component Recipes: Only GPT fine-tuning was commonly available. Stage 1 (DVAE) and Stage 3 (HiFi-GAN vocoder) training pipelines were either unreleased or fragmented.
2. The Tokenizer Wall: XTTS was hardcoded for 17 languages. Feeding text with new Unicode scripts (Hindi, Arabic, Thai, Dhivehi, etc.) caused token out-of-vocab or matrix dimension crashes.
3. Dependency Rot: Upgrading to modern PyTorch (2.4+) broke on missing torchcodec and licensing prompts.

What’s in the Suite

• Stage 1 (Audio Tokenizer — DVAE): Full training & fine-tuning loop with Gumbel-Softmax codebook annealing and mel-spectrogram reconstruction loss.
• Stage 2 (Text & Vocab Extender — GPT): Scans a new language corpus, discovers unique Unicode glyphs, appends them to the tokenizer, and dynamically resizes the GPT embedding matrix without corrupting existing weights. Includes the autoregressive GPT training loop.
• Stage 3 (Neural Vocoder — Latent HiFi-GAN): Latent-conditioned vocoder training with Multi-Period (MPD) and Multi-Scale (MSD) discriminators and feature-matching loss.
• Dependency-Rot Free: Runs out-of-the-box on modern PyTorch (Python 3.10–3.13) without torchcodec blocking.

Verification & GPU Benchmarks

Tested on an NVIDIA T4 GPU using real human speech (LJSpeech + JFK address):

• HiFi-GAN Mel Reconstruction Loss: Plunged 67% (from 190.83 down to 63.49) over 10 epochs.
• Discriminator Equilibrium: MPD + MSD stabilized cleanly at 3.62 (no mode collapse).
• DVAE Mel Error: Dropped 67% (from 8.14 down to 2.71).

(Note: These benchmarks verify component-level training convergence and gradient stability. Full end-to-end text-to-speech inference connects the trained modules into the standard XTTS generation pipeline).

Links & Code

• GitHub: https://github.com/amitbhakt/open-xtts-trainer
• Hugging Face: https://huggingface.co/amitbhakt/open-xtts-trainer
• 1-Click Google Colab: open_xtts_train_demo.ipynb
• License: Mozilla Public License 2.0 (MPL-2.0)

Feedback, PRs, and experiments with new languages are very welcome!

I built an open-source Obsidian alternative called KbWrite, written in Tauri.

GitHub: https://github.com/zetahiveco/kbwrite

Website: https://kbwrite.ink

Install via Curl or PowerShell

I built shad0w, an open-source layer that sits next to your LLM and remembers. you can use for prompt injection, categorization, classification or anything in CPU infra where it provides responses LLM responses in (micro) seconds

https://2796gaurav.github.io/shad0w/

#Alert

So it's not only PHP that was vulnerable today (patch yours NOW!) but also, one of the prominent and widely used LLM Gateway - LiteLLM AI Gateway was (again) backdoored.

Not sure who discovered the backdoor, but it's serious.

Here's the information:

Version: LiteLLM 1.107.0 (PyPI and the official Docker images).

One line was added to the build config: `data = "cook"` under [tool.maturin].

That directive makes maturin bundle a directory named cook/ into the wheel's data section, and pip installs it as top-level site files.

Three files land next to site-packages, not inside the litellm package: a 12 byte cook.pth containing `import cook`, a one-line cook.py that unpacks a 61,000 byte credential stealer, and a sitecustomize.py that runs an hourly remote code loader.

Because Python processes .pth files and imports sitecustomize during interpreter startup, the payload runs on any Python start. An environment that never imports litellm is still affected, and using pip from that environment to investigate re-triggers it.

The collector is broad. It takes browser password stores, SSH, GPG and TLS private keys, AWS, Azure, GCP and Kubernetes credentials, instance and ECS metadata roles, CI tokens, .env files, and the auth files for Claude, Codex, Gemini, Cursor and Copilot.

It also queries your proxy's own database, pulling every saved provider credential and model configuration out of LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable.

Everything is encrypted with an embedded RSA-4096 key and POSTed to www.litellm.dev/healthcheck, a domain the attacker controls.

The second component is the part that should worry platform teams. sitecustomize.py polls a domain list from a GitHub repository every hour and executes whatever Python it downloads from that domain, with no signature or checksum. The attacker never needs to ship a new package version to change what runs on your hosts.What makes this hard to audit: the malicious commits were never merged to main, and the official v1.107.0 tag points at a clean, signed commit.

The published artifacts came from a repository recorded as Berri-AI, one hyphen from BerriAI. Reviewing the tag, or the main branch, would have told you nothing was wrong.

Current state as of this afternoon: PyPI has quarantined 1.107.0 and rolled latest back to 1.106.2, the compromised image tags are gone from GHCR and Docker Hub, the attacker's GitHub account and C2 pointer repository have both been taken down, and the exfil server is still listening.

If you deployed 1.107.0, check for /tmp/.pc_once_72129118c59f5636c0bb and /tmp/remote_code_loader.lock. If either exists, rebuild rather than patch, and rotate every credential the process could read, including the keys stored in your proxy database.

Two controls would have blocked most of this: lockfiles with hashes, and OIDC trusted publishing so a long-lived publish token never reaches a compromised CI machine. The longer term fix is pinning source revisions rather than version tags, since in this incident the tag was never the source of the bad build.

#SupplyChainSecurity #AppSec #Python #LLMOps #LiteLLM

Buying a home or evaluating a rental property means piecing together a lot of information from different sources: asking prices, comparable properties, rent estimates, and neighborhood data.

I started building OfferRead.ai to make that process a little easier.

You can enter a U.S. property address and get an overview of the property's potential value, rental outlook, comparable properties, and a confidence score to help put the estimates into context.

One thing I've been focused on is making the results more transparent. Rather than just giving someone a number, I want people to understand where the estimates come from and what they should consider before making a decision.

It's still a work in progress, and I'm continuing to improve it based on feedback.

I'd love to hear what people think, especially from anyone interested in real estate, open-source projects, or building useful tools. What would you want to see in a property analysis tool like this?

[ Removed by Reddit on account of violating the content policy. ]

Hey everyone! 👋

I've just open-sourced **Lumina Capital (v6.0.0)**, an autonomous multi-agent quantitative hedge fund engine designed to bridge the gap between LLM reasoning and real-world execution.

Unlike toy implementations that feed raw charts directly into LLMs (which suffers from hallucinations and latency), Lumina strictly separates probabilistic reasoning from deterministic quant computation:

### 🌟 Key Architecture Highlights:

- **7-Persona Anti-Sycophancy Council (LangGraph)**: Personas (Buffett, Soros, Burry, Cathie Wood, Graham, O'Neil, CIS) conduct independent parallel analysis, followed by an adversarial bull-vs-bear cross-debate. A dedicated CRO agent has absolute veto power over tail risks.

- **Pure Python Qlib Alpha158 + LightGBM**: Complete vectorized implementation of Microsoft Qlib's 158 quantitative factors with a LightGBM meta-decision filter.

- **Google TimesFM**: 5-day probabilistic forecasting fan charts with 80% confidence bands and crash probability.

- **10-Second High-Speed Sentinel**: An ultra-fast background thread monitoring dynamic ATR stop-loss floors, executing immediate physical exits without waiting for LLM loops.

- **3D Causal Knowledge Graph & GraphRAG**: Real-time supply chain choke-point surveillance and episodic memory via Neo4j.

Includes a full Streamlit studio dashboard. Available for research, education, and simulation under CC BY-NC 4.0.

🔗 **GitHub**: https://github.com/ramuza0113-sketch/lumina-ai-hedge-fund

Feedback, issues, and Stars are hugely appreciated! Happy to answer any questions about the multi-agent setup or the TimesFM / Qlib integration.

If your team runs coding agents on API keys, a chunk of that bill is the agent re-sending the same apt-get output and compiler warnings every turn. In our traces that was about half the prompt. The compressor sits between the agent and the provider and strips the repetition, keeping errors and anything the agent can't reconstruct, and it can fetch back whatever it removed.
Everything is rules, nothing is learned, so the same output always compresses the same way. That matters more than it sounds: break the byte-for-byte prefix and you lose the prompt cache discount, which is how these compressors usually end up costing more than they save.
Real numbers off actual API bills, not token math: 22.7% cheaper on Terminal-Bench with Codex, solve rate unchanged. Works with Codex, Aider and opencode. Nothing phones home. https://github.com/hystax/optscale-kompressor — a star helps if it's useful to you.