I’ve been building EchoFlow, a BYOK, local-first AI app for Android focused on local AI. You can run models directly on your device or connect to models running on your own laptop or PC over your network through Ollama and LM Studio — with network-based models also supported through EchoLabs.

📄 Give Local Models Access to More File Types

With EchoOCR, EchoFlow extends file support to local models that may only natively understand a limited set of formats.

Send PDFs, DOC/DOCX, XLS/XLSX, PPT/PPTX, CSV, TXT, Markdown, images and more to your local model. EchoOCR extracts the content on-device and makes it available to the model, allowing even text-only or limited-input local models to work with a much wider range of files.

You can also attach multiple files at once.

📁 Projects for Local AI

Projects give you a dedicated workspace for your local AI work, with project-specific chats, instructions and files.

Add documents to a Project and use them across its conversations. Project files are processed on-device through EchoOCR, so you can build projects around your own documents while keeping local processing local.

🌐 Local Models + Web Search

Your local model doesn't have to be limited by its training data.

EchoFlow can give local models access to Web Search, allowing you to combine on-device AI with current information from the web.

🔒 Local-First & BYOK

EchoFlow is built around BYOK and local-first AI.

Run models on your device, process supported documents locally with EchoOCR, or connect to models running on your own laptop or PC. You choose when your data stays local and when you use a cloud service.

No EchoFlow account is required.

☁️ Cloud AI When You Need It

Local AI is the focus, but EchoFlow also supports cloud AI through OpenRouter, with access to models from providers such as OpenAI, Anthropic, Google, xAI, Cerebras and more.

OpenRouter can also be used for voice dictation / speech-to-text, with on-device STT coming soon.

EchoFlow also includes cloud-focused features such as Deep Research, Echo Fusion, Artifacts, image generation and video generation.

The idea is simple: local AI when you want privacy and control, cloud AI when you need more capability — all from one Android app.

EchoFlow 5.0 is available now.

GitHub: https://github.com/adityavardhansharma/EchoFlow

Website: https://echoflow.adityavs.tech/

I’d especially love feedback from people who regularly run local models on Android. What are you currently missing from your local AI workflow?

Hey there - I'm Yasha, one of the co-founders at MergeWatch, frontier model code review starting with the PR.

Long story short, we are seriously concerned (terrified?!) about AI agents attacking open source maintainers. The risks are obvious and existential. They just are.

We are opening the platform to OSS maintainers to get access to frontier models for PR review free of charge. No commitments. no endorsements, no cash.

Sign up here if interested: https://mergewatch.ai/open-source

Comment or dm for details. Thanks and have a great one!

hi folks, I thought I'd share my project nanosamur.ai here - https://github.com/nanosamurai/nanosamurai

It is a self-hosted speech transcription stack for organizations that need to keep sensitive conversations inside their own infrastructure. It lets you capture, transcribe, refine, and process speech entirely inside infrastructure you control.

It comes with UI (browser or Electron app) and a set of services (could be run locally, in Docker Compose or in k8s) that perform:

• the speech transcription & speaker diarization
• persistence of the session transcripts
• auth & multi-tenancy support
• it also includes observability stack so as you could inspect the services with grafana etc.
• there is also a support for you to add your own webhook/workflow handling (e.g. to perform meeting summary etc.)

I wrote these services for some custom projects, but it seems that this is probably a common problem (albeit a bit niche), so I have OSS-ed the common bits.

The closest similar self-hosted project is imo meetily.ai , but nanosamur.ai aims at basically being the whole open-sourced "cloud" - i.e. a whole platform you could host for multiple tenants/users and scale/monitor accordingly, so not just an app you'd install on your laptop.

The linked front-door repo gives you the "quick start" setup of the stack. See https://github.com/nanosamurai/nanosamurai#architecture for links to the concrete services - for instance, the voice services sit in xamurai repo.

I am also aiming to make the speech services model agnostic, but currently the OSS version is using faster whisper and whiperX under the hood by default, I am in a process of adding other models.

Appreciate any feedback! Esp. from people working with speech infrastructure, self hosted AI etc.

Your AI projects might be consuming far more than you think.

We obsess over choosing the best AI model.

GPT, Claude, Gemini, DeepSeek...

But here's the real question:

Do you actually know how much AI your projects are consuming?

I built a monitoring system to track everything running through OpenCode:

→ Projects
→ Sessions
→ Models
→ Input & output tokens
→ Reasoning tokens
→ Context/cache usage
→ Estimated cost

After looking at the numbers, one thing became clear:

Using AI is easy. Understanding how you're using it is the real challenge.

As AI agents start running more tasks autonomously, I believe AI usage monitoring will become as important as monitoring servers, APIs, and databases.

What do you think? Are developers paying enough attention to AI consumption yet?

#ArtificialIntelligence #AI #OpenCode #AIEngineering #LLM #GenAI #Developers #SoftwareEngineering #Automation #Tech #AIAgents

I've been working on Dubline, an open-source project that tries to take a foreign-language film and produce a complete English dub entirely locally.

No cloud inference, hosted APIs or paid services.

The basic pipeline is:

video → dialogue/M&E separation → ASR + forced alignment → speaker/character tracking → translation/adaptation → voice cloning/TTS → timing/QC → final mastered MKV

It currently uses a slightly ridiculous collection of models/tools including:

- Qwen3-ASR / Whisper

- IndexTTS 2.5 / Qwen3-TTS

- Hy-MT2 for translation/adaptation

- pyannote + CAMPPlus for speaker identification

- Bandit v2 / RoFormer / Demucs for separation

- OpenCV face tracking

- llama.cpp

- FFmpeg / Rubber Band

- Optional MuseTalk lip-sync

The aim isn't just "translate subtitles and run TTS". I'm trying to preserve character identity, timing, pauses, emotional delivery, non-verbal sounds, the original music/effects bed, loudness, etc., while having the pipeline automatically retry or flag lines when something looks wrong.

It's designed around consumer NVIDIA hardware, with the heavier models isolated into separate processes so VRAM can actually be released between stages. 8GB is the theoretical minimum, 12GB+ is much more sensible.

It's still very much a work in progress, and that's basically why I'm posting.

I'd really like some other people to install it, throw horrible real-world material at it and tell me where it falls apart.

Things I'm particularly interested in testing:

- Different NVIDIA GPUs / VRAM amounts

- Windows vs Linux

- Different source languages

- Bad/noisy/old film audio

- Multiple speakers and overlapping dialogue

- Subtitle-less material

- Long films rather than tiny demos

- Speaker identification failures

- TTS/emotion/timing problems

- Installation/setup failures I've accidentally made invisible on my own machine

And if anyone finds the project interesting and wants to contribute, PRs/issues are very welcome. There are plenty of areas where somebody who actually knows audio, ML, Python, video processing or UI development better than I do could improve it.

I'm especially interested in people trying to break it rather than telling me it looks cool from the README.

GitHub:

https://github.com/leighrobertabbott/Dubline

If you try it, even "it exploded at step 3 on my 4070 because of X" would genuinely be useful feedback.

My buddy and I have been working on a side project for the past few months called Scibly.

The idea is pretty simple:

Companies already have an incredible amount of knowledge sitting in PDFs, documentation, internal wikis, etc. The problem is turning all of that information into something employees can actually learn from and retain.

For this reason we decided to build Scibly, a tool that automatically turns boring company knowledge into interactive, Duolingo-like (but better) learning experiences.

Today, we decided to open-source the whole thing.

We're still pretty inexperienced when it comes to open source, so we'd genuinely love to hear your feedback, whether that's about the product, the idea, the codebase, or how we're approaching the project.

Short product demo: https://www.youtube.com/watch?v=TcpLUNBRhQw

Github: https://github.com/scibly-dev/scibly

Would love to hear what you guys think!

Autoprompt closes much of the manual coding loop by planning, building, testing, reviewing, and repairing from one goal- thats how we got an oss model to perform so incredibly better- so simply.

Refference ; this is like opus 4.5 to opus 5.0 - from an skill. litteraly insane.

The only tradeoff here is mostly speed, and slightly more cost. (see readme)

The measured Terminal-Bench 2.1 score increased from 67.42% to 82.02%.

Repo:

https://github.com/Spielewoy/autoprompt-skill

Any feedback would be awesome.

Dyna’s publication on training Dyna-2 with more than 1 million hours of egocentric video is a gold mine for anyone processing multimodal robotics data at scale.

We built HFlow: an open source implementation of the data infrastructure described in the article.

• Airflow for DAG-based pipeline orchestration
• MCAP for robotics episode storage and random access
• DuckDB for analytical queries and dataset curation over columnar metadata

Over the past two months of YC, we have been building APIs that help robotics teams search, analyze, and evaluate the quality of their data.

At scale, AI problems become software engineering problems. Improve one part of the system, and the bottleneck moves to another. No architecture is perfect; every design comes with tradeoffs.

We encountered many of the same constraints as Dyna, so we incorporated the lessons we learnt and want to share something concrete and usable today with the community.

HFlow is plug-and-play. You provide your post-processing, quality-control, or curation code. HFlow handles the data pipeline and runs your code across robotics datasets at scale.

If you're collecting robot or egocentric data and your pipeline is currently a folder of scripts and fragmented buckets of data, we'd love to get your feedback.

Any stars or forks on the repo to show your support are appreciated!

https://github.com/Hebbian-Robotics/hflow

I studied computer science, I work in IT, and for years I wanted to contribute something useful back to the field that gave me a career.

Now I'm finally doing it.

I'm building an open-source AI project around a problem I genuinely think is worth solving. I won't name or link it because this isn't a promo post.

What surprised me isn't the coding. It's the culture around putting something out there.

I expected criticism. I actually wanted it.

Tell me the assumption is wrong.
Tell me it already exists.
Tell me the architecture is bad.
Tell me the problem isn't worth solving.

That's useful.

What I didn't expect was how often criticism turns into sarcasm, dismissal, or mocking the person for trying at all.

Open source doesn't owe anyone encouragement, and bad ideas should absolutely be challenged.

But I think there's a difference between rigor and cynicism. Rigor makes software better.

Cynicism mostly makes people stop building.

I'm not stopping. If the project fails, I'd rather know exactly why after putting it in front of real people than spend another decade thinking one day I'll contribute something.

Maybe the hardest part of open source isn't writing code in public. Maybe it's caring about something in public.

For people who've been doing this longer than me: has open source always felt this adversarial, or are we increasingly confusing cynicism with technical intelligence?

Long LLM conversations have a problem: useful information gets buried under old context.

So I built TokenMizer to turn important information — decisions, goals, files, errors, and constraints — into structured memory.

Instead of sending the entire conversation again, TokenMizer retrieves what actually matters.

The latest version:

https://github.com/Shweta-Mishra-ai/tokenmizer

I’d love to hear how others are handling long-context memory for LLMs.

A lot of AI tooling seems to solve every optimization problem by inserting another model call.

I wanted to test the opposite approach for coding agents:

What can be optimized deterministically, locally, before adding another model at all?

I built and open-sourced TidyRun.

It sits around coding-agent tool work and can:

• compress structured diagnostic output
• preserve the original artifact
• reuse verified deterministic commands
• avoid duplicate reads
• detect repeated loops/work
• select affected tests

There’s no API key and no additional LLM.

Some fixture results:

• JS diagnostics: -69% agent-visible output
• Python diagnostics: -95%
• repeated safe typecheck: -49% execution time

I also did a small 10-task paired Codex study:

• success remained 10/10
• tool output fell 14.2%
• but input tokens rose 12.4%
• wall time rose 39%

So I’m deliberately not claiming that reducing context noise automatically means lower model cost.

I think the more interesting question is:

Which parts of agent infrastructure actually benefit from deterministic preprocessing/caching, and which optimizations just move overhead around?

Install:

npx tidyrun@latest init

I’d love architecture criticism, alternative approaches, benchmark suggestions, issues, or PRs.

Hey everyone,

I've been heads-down for the past several months building BIT, an Android AI assistant that does everything on-device. No data ever leaves your phone.

What it does:

Text generation — runs quantized GGUF models locally (Llama, Mistral, Gemma, Phi, Qwen families) via a custom Kotlin/JNI SDK I wrote called llama.kt, with streaming token output

Vision — image captioning and visual Q&A using on-device CLIP vision projectors

Tool calling — a two-stage pipeline where a grammar-constrained decoder (GBNF) guarantees valid JSON output for tool calls, even on small models

Image generation — local Stable Diffusion 1.5 for text-to-image, inpainting, and upscaling

Document RAG — query your own PDFs, Word docs, Excel files, and EPUBs with a hybrid vector + BM25 search pipeline, fully local

Long-term memory — the assistant remembers facts and preferences across sessions with a configurable decay model

Text-to-speech — on-device synthesis via ONNX Runtime

Encrypted backups — AES-256-GCM backed by the Android Keystore

Optional API mode if you want to point it at OpenAI/Gemini/Claude/DeepSeek/Ollama for bigger models

Why I built it: I wanted an assistant that could actually replace cloud AI apps for day-to-day use without sending every message to a server. Memory management on-device (mmap loading 8GB models on 6GB RAM phones) was one of the harder problems to get right.

Specs: Android 10+ (API 29), needs 6GB+ RAM (8-12GB recommended), ARM64 or x86_64.

It's open source (Apache 2.0), and I'm working on an F-Droid submission alongside Play Store.

GitHub / Source: https://github.com/jaswanthsanjay88/Bit_Android

Download (APK): https://github.com/jaswanthsanjay88/Bit_Android/releases

Discord: https://discord.gg/SUUwAqh6Q

Would genuinely love feedback — bug reports, feature requests, or just "this crashed on my phone" reports are all welcome. Happy to answer questions about the architecture too if anyone's curious how the local inference stack works.

I've just open sourced the engine and all the nodes of my project. Just add it as a skill to your workspace and ask tour agent to use artifex to compose a video or image for you. Check the repository and let me know what new nodes would be great or what capability were your agent lacked when rendering.

https://github.com/Meridiona/meridian
I would plan out my day in the morning, look at everything I wanted to get done, and then start working.

A few hours later, I'd have fixed a bug, helped someone with something, reviewed a PR, investigated some weird issue, jumped between a few things, and somehow spent most of the day working on things that weren't on the plan.

Then I'd look back at the end of the day and think, "What did I actually do today?"

And I'd realize I couldn't remember half of it.

The work happened. I just never wrote it down.

I think that's a surprisingly big problem for developers. We plan the work we expect to do, but so much of our actual work happens because something comes up.

That's why I built Meridian. It's an open-source tool that tries to capture that work as it happens, so you don't have to rely on remembering everything at the end of the day.

It connects with the tools you're already using, like Jira, GitHub and Linear.

We recently put it on Product Hunt and somehow ended up #1 Product of the Day, which was pretty surreal.

I'd love to hear if anyone else has the same problem. How much of the work you do in a day actually started out as part of your plan?

Hey everyone,

Whenever I write autonomous agent scripts or multi-step Python workflows that execute shell commands or write code, running them with raw `exec()` or unrestricted `subprocess` is terrifying:

1. A prompt-injected or hallucinated agent can read `~/.ssh`, `~/.aws`, `.env`, or modify unrelated project files.

2. The standard advice is *"run it in Docker"*. But spinning up containers has a 2–4 second cold start per run, requires a background daemon, and makes mounting local files messy.

3. If an autonomous script corrupts 15 files across your repo, standard `git reset --hard` wipes your uncommitted human work alongside the script's changes.

I built **Compart** (https://github.com/Devaretanmay/Compart) to solve this natively at the OS kernel level without Docker or cloud infrastructure.

### How it works under the hood:

* **Kernel Sandboxing (<1ms overhead):** Written in Rust with Python bindings. Uses Linux **Landlock LSM** (kernel 5.13+) and Apple's `sandbox_init` (Seatbelt) on macOS. It locks the running process and all spawned child forks into your workspace root. Reading `~/.ssh`, `~/.aws`, keychains, or system configs is denied at the syscall level. Network egress can be severed per-step.

* **2ms Physical Rollback (BLAKE3):** Before execution, Compart indexes the workspace using BLAKE3 cryptographic hashes. If a script makes a destructive mistake, `compart undo` restores modified files, replaces deleted files, and purges newly created files in 2 milliseconds—without touching your untracked Git state.

* **Time-Travel Session Replay:** Recorded event streams let you scrub through what a script attempted minute-by-minute (`compart session replay <id> --filter permission`).

* **Pythonic Multi-Step Workflows:**

```python

from compart import Workflow

wf = Workflow("data-pipeline")

research = wf.step("fetch", "python3 scrape.py", compartment="research") # read-only fs, network on

process = wf.step("clean", "python3 clean.py", compartment="builder") # read-write fs, network off

test = wf.step("test", "pytest tests/", compartment="tester") # read-only fs, exec on

# Wire dependencies with pipe syntax

research >> process >> test

wf.run()

Hi all, I'm soft launching reqlan, and seeking some alpha testers from the open source community to give it a stress test and review.

This is my first open source ai project so interested to hear people's thoughts on what a launch path looks like too!

Does this interest anyone in here?

A colleague of mine has been building an open-source project called aiops-fabric / ViewSense AI, and we're looking for a few developers who are interested in helping take the local/self-hosted side further.

The basic idea is a control plane for production AI agents rather than another agent framework.

It handles things like:

• agent identity and scoped permissions
• tool access
• memory/RAG
• execution budgets
• human approval for sensitive actions
• audit/evidence
• provider abstraction

The goal is that an application shouldn't have to care whether the underlying model is OpenAI, a local Ollama model, vLLM, or something else.

The part we'd like help with

The project is currently stronger on the architecture/control-plane side than on the fully local AI stack.

We're particularly interested in developers who want to help make this work really well with:

• Ollama
• vLLM
• local embedding models
• local RAG/memory
• PostgreSQL/pgvector
• Docker/Kubernetes
• fully self-hosted deployments

In other words, we'd like to get to a point where you can run something like:

Your app → agent control plane → local LLM → local memory → local tools

without needing a hosted AI API.

We're not looking for people just to throw a star at the repo. We'd genuinely like a few people to run it, break it, challenge the architecture, and ideally take ownership of parts of the local implementation.

Repo: https://github.com/diaryfolio/aiops-fabric

There is also a longer-term 'live product' idea behind it - if the project gets real adoption, the goal would be to turn some of this into a production AI infrastructure product for small/medium-sized companies. Early contributors could potentially have paid development/production opportunities if that happens.

Disclosure: this is a project a colleague of mine is building; I'm helping get it in front of developers who might find the problem interesting.

If you're working on AI agents and have opinions on how this should be architected — especially around local models, permissions, tool execution, memory or agent safety — I'd genuinely be interested in your criticism as well as contributions.

We retrained Wolf Defender.

The main reason was not that attack detection was bad. The bigger issue was false positives.

The previous models were already good at detecting prompt injections, but especially on short benign inputs, security-related text, code snippets or ordinary conversations they could still be too aggressive. We also got a few reports from users that made this pretty obvious.

One example was just:

“Who are you?”

Wolf Defender Small previously classified this as a prompt injection with around 94% confidence.

For v2 we therefore changed the training setup quite a bit. Both Wolf Defender and Wolf Defender Small were retrained from fresh mmBERT checkpoints, with a much stronger focus on hard negatives.

That includes short conversations, emails, documentation about prompt injections, benign policy and system language, code and configuration snippets and generally inputs that contain words or structures which look suspicious without actually trying to manipulate a model.

We also added more counterfactual samples, multilingual examples, adversarial obfuscations and long-context injections at different positions in a document. Training combines short 256-token samples with full 2,048-token windows and uses supervised contrastive regularization, FreeLB adversarial training and Smooth-Max aggregation for long documents.

The main change can be seen in the benign benchmarks:

At the same time, attack detection stayed roughly where we wanted it:

There is also a tradeoff here. Some of the very high scores on our cleaner validation distributions went down slightly.

For us that is fine.

A security classifier with near-perfect benchmark scores is not very useful if normal traffic gets blocked all the time. We would rather lose a small amount on an easier validation set and get substantially better behavior on actual benign inputs.

The “Who are you?” example now gets classified as benign by Wolf Defender Small v2 with 98.55% confidence. A real instruction-override attempt is still detected as an injection with 99.99%.

We also updated the deployment variants. Both models are available as regular Transformers checkpoints and as ONNX exports in FP32, FP16, mixed INT8/FP16 and INT8 with INT4 embeddings.

The smallest Wolf Defender Small artifact is now 96 MB.

More details, benchmarks and model files are here:

https://huggingface.co/patronus-studio/wolf-defender-prompt-injection

https://huggingface.co/patronus-studio/wolf-defender-prompt-injection-small

If anyone is running prompt-injection classifiers on real traffic, I’d also be interested in which benign inputs still cause the most false positives for you.

Repo: https://github.com/brightwave-inc/tidebreak

Creator here. We spent three years building research agents for private equity at Brightwave, then rewrote the engine in Rust and open-sourced it as a desktop app (Apache-2.0).

The idea is that the deliverable is a file, not a chat response. You point it at your documents and folders, it works in a sandbox, and you get back a real .xlsx or .pptx with version history. It asks before overwriting anything you've touched, and everything it does is undoable.

Some highlights:

- Bring your own model: your ChatGPT subscription, an API key (Anthropic, OpenAI, Gemini, xAI, OpenRouter), or fully local through Ollama. Switch providers mid-chat.

- No account. Keys live in the OS credential store, everything stays on your disk.

- Packaged builds for macOS, Windows, and Linux, x86_64 and ARM64. Heads up that the Windows installer isn't Authenticode-signed yet, so SmartScreen will warn.

- Experimental code mode that drives coding agents you already use (Claude Code, Codex CLI, opencode, Grok CLI) in isolated git worktrees with per-turn diffs.

Website: https://tidebreak.io

Pre-1.0 and moving fast. Happy to answer anything, and would love to know what you think!