Autoprompt Skill pushed DeepSeek V4 Flash from 67.42% to 82.02% (with the OpenCode Harness) on Terminal-Bench 2.1.

Same effect comes with all models- not just deepseek.

The skill closes much of the manual coding loop by planning, building, testing, reviewing, and repairing autonomously, but expect longer runs and higher token costs.

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

Any feedback would be awesome. If you like the project, a star would genuinely help.

After about a year of building, testing and constantly finding things to improve, Nyx AI is finally out. It is available in 240 markets and 6 languages.

Nyx AI is a local first AI workspace for Windows for chat, coding, documents, previews and automation.
You can run models locally through Ollama or connect OpenAI, Anthropic, Ollama Cloud or your own compatible endpoint. No Nyx AI account is required for local use.
One area I spent a lot of time on was agent safety.

In Nyx AI Lab the model can work with files, run shell commands and Python, use Git, run builds and tests, and preview PDF, DOCX, XLSX and PPTX files.
Locked execution uses Windows AppContainer isolation where supported, alongside workspace file controls, command risk checks, approval controls and native Windows confirmations for certain higher risk actions.

There is also a built in privacy sanitiser designed to detect and redact recognised sensitive information before messages are sent to non local models. It is best effort and cannot guarantee that every sensitive value will be detected.

No sandbox is completely secure and these controls reduce risk rather than eliminate it. The limitations and residual risks are documented in the public threat model, and the legal and technical documents are available inside the app.

Would genuinely appreciate anyone trying it and telling me what you think.

Website
[https://nyxai.uk
Microsoft Store
)Microsoft store nyx ai

Wir bauen seit ein paar Monaten zu zweit an Scibly.

Die Idee ist eigentlich relativ simpel. In Unternehmen gibt es schon unglaublich viel Wissen in PDFs, Dokumentationen oder irgendwelchen internen Wikis.

Das Problem ist eher daraus etwas zu machen mit dem Mitarbeiter wirklich lernen können.

Genau dafür bauen wir Scibly. Man gibt bestehende Inhalte rein und erstellt daraus kurze interaktive Lernerfahrungen.

Wir haben uns jetzt auch entschieden Scibly komplett Open Source zu stellen und Self-Hosting anzubieten.

Hier sieht man in 54 Sekunden ganz gut was wir bauen: https://www.youtube.com/watch?v=TcpLUNBRhQw

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

Wir sind gespannt auf euer Feedback

I've been building TokenMizer, a local proxy that sits between your editor/CLI and whatever model you're using (Claude, GPT, Ollama) and handles two things I kept re-solving by hand: session checkpoint/resume, and a graph-based memory instead of a flat transcript.

The problem: once a long agent session hits the context limit, the usual fix is summarization, and summaries lose the reasoning behind a decision, not just the decision itself. I'd see a summary saying "switched to Argon2" with no trace of why bcrypt was rejected, so the agent would re-litigate the same tradeoff two sessions later. Flat transcripts have the opposite problem: everything is kept, but nothing is prioritized, so retrieval is just recency-biased keyword luck.

What TokenMizer does differently: instead of one growing text blob, decisions, constraints, and open questions are stored as nodes with edges (this decision depends on that constraint, this question was resolved by that decision). Checkpointing snapshots that graph plus a resumable session state, so you can kill a session and pick it back up without replaying the whole history through the model again.

Where it's rough: there's no eval harness yet comparing retrieval quality against a naive flat-transcript baseline, so right now my evidence is anecdotal (my own sessions), not benchmarked. I also learned the hard way that benchmarking your own memory system by asking it questions only it can answer is circular, so I'm holding off on publishing numbers until I have an honest comparison.

Repo: github.com/Shweta-Mishra-ai/tokenmizer (I'm the author). It's a Python project, MIT licensed. If you've hit the same summarization-loses-reasoning problem, I'd be interested in how you're handling it, and PRs/issues on the eval-harness gap would genuinely help.

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:

Model	Benchmark	v1	v2
Wolf Defender	Hard benign specificity	81.57%	96.23%
Wolf Defender	Real-world benign specificity	66.85%	96.63%
Wolf Defender Small	Hard benign specificity	82.12%	96.67%
Wolf Defender Small	Real-world benign specificity	73.60%	94.38%

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

Model	Qualifire F1	Jayavibhav F1
Wolf Defender	95.14%	97.84%
Wolf Defender Small	95.21%	97.68%

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.

Frontman is for a specific problem: AI coding agents often edit frontend files without seeing the running app, built for technical people.

Why try it:

- select/click UI before asking for edits

- agent gets DOM, screenshot, logs, routes, source mappings

- works with Astro, Next.js, Vite, WordPress

- open source

Latest release added Astro content collections support.
And it's fully OSS, self hostable etc

Repo: https://github.com/frontman-ai/frontman

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.

https://www.youtube.com/watch?v=-UbYdRgwRWE

I've been building CortexAgent as a personal project for a while, and I finally got it to a place I'm happy to share. It's a private, local AI coding agent — everything runs on your own machine via llama.cpp. No cloud, no account, no API key, and no data ever leaves your computer. It binds to 127.0.0.1 only.

It's MIT licensed at https://github.com/greyok00/cortexagent.

One terminal interface, one local stack — the only interface you talk to is a single clean TUI (cortex). A 35B MoE does the heavy lifting on your GPU (16 GB+ VRAM recommended), with a small "overseer" model for planning and routing. Nothing else to juggle.

The processing pipeline you can watch — every request animates live through its stages, with real percentages (it never fakes a determinate number):

- 🧠 preparing — organizes your request and checks the context it needs.

- 🗜️ slimtoken — minifies your context before it reaches the model, so you fit more into the window.

- 📤 sending — the request goes to the big model.

- ✨ generating — streamed output builds in place.

- 🔧 tool wait — when the model calls a tool mid-request.

Overseer routing — a dedicated small model plans and routes each request to the big model, instead of one model trying to do everything.

Memory that actually remembers — hot working memory for the current session plus curated cold knowledge, distilled automatically from what you've already said, so you don't re-explain yourself across sessions.

Domain memory — recalled context from your own notes is injected automatically when it's relevant, no prompting needed.

Talk instead of type — speech-to-text as a floating popout you control with the mouse and your voice only (no keyboard), transcribed locally with faster-whisper. Open it from the system tray under STT Controls.

Tools & integrations

- 🌐 browser control — drive Brave over Chrome DevTools Protocol, exposed as 9 brave_* tools registered directly in the tool registry.

- 🔌 MCP client + lazy proxy — talk to MCP servers, spawning the real server only on first use instead of holding every socket open.

- 🔎 Firecrawl — web research and page parsing routed through a proxy.

- 🎨 image & video generation — SD 1.5 / SDXL / LTX run in-process through HuggingFace diffusers on the GPU the daemon already manages — no separate GUI server.

- 📄 PDF & document knowledge — ingest PDFs and documents into a queryable knowledge base.

See the whole thing — a web UI with a three.js 3D cortex scene (gold neural cortex + glass chat), a system tray dashboard, a session bridge so the TUI, web UI, and overseer all agree on context, and a live status ticker.

Under the hood

- ⚙️ Daemon lifecycle — the model + proxy run as an always-on service (systemd); VRAM-aware fallback swaps models when GPU memory gets tight.

- 📅 Scheduler + worker pool + heartbeat — background jobs run and recover cleanly.

- 🛡️ Reliability layer — pre-flight gate, anti-hallucination + post-response verification, a doctor that repairs settings drift, loop guard, chain diagnostics, and observability.

- 🛤️ Pathway capture — records each run's processing chain (frame → domain check → route → generate) as replayable runs.

- 💾 Snapshot / backup scripts — easy state backup.

Privacy isn't a feature, it's the baseline — everything binds to 127.0.0.1, and there's no cloud account to leak to. The honest caveat: the processing animation shows real percentages only; if a stage is a wait, it says so instead of pretending to progress.

What I'm asking for:

- Recommendations — what would make this a daily driver for you? Better docs, packaging/installers (pip/Homebrew/AUR), more model backends, UI polish, more tools?

- Contributors — it's a solo project; help with docs, testing, packaging, and hardening is very welcome. Issues, PRs, and "your docs confused me here" all help. Even a quick honest "here's where it breaks" is hugely useful. Thanks for reading! 🙌

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!

Hi everyone,

I’d like to share an open-source systems project I’ve been working on called Olivia (named after my cat!).

It’s an enterprise-grade infrastructure harness written from scratch in Rust, specifically designed to run agentic LLM workflows safely. The core philosophy is to execute AI-driven actions and tools within strictly sandboxed environments using WebAssembly (Wasm/WIT).

I wanted a robust, native infrastructure to handle LLM agent workflows without compromising on security or relying on bloated software layers. Olivia ensures that the agent's interactions with databases or external scripts happen within a secure, controlled boundary.

You can check out the repository here: https://github.com/helloIAmPau/olivia

I would love to get some feedback from this community on the architecture, or hear what other sandboxed tools you'd find useful. Contributions, code reviews, and suggestions are more than welcome.

Link

https://github.com/ynqa/convey

Description

I released Convey v0.1.0.

Convey is a macOS TUI that collects input through a YAML-defined workflow, renders it as Markdown, and sends the result to a selected Ghostty or iTerm2 pane.

For example, when asking a coding agent to investigate Kubernetes, I need to specify which resource to inspect, along with its context and namespace, in every prompt. Each time the target changes, looking up those values with kubectl and copying them into the prompt is tedious.

Convey lets me define this kind of investigation request as a reusable YAML workflow. It loads candidate contexts, namespaces, and resources from kubectl, so at runtime I can select the required values from the TUI in sequence.

A SKILL.md can also instruct an agent to ask the user for these values, but following that instruction is still left to the model. Convey does not send the prompt until the required selections are complete, ensuring that decisions I do not want to delegate remain under my control.

The attached GIF shows a Kubernetes investigation workflow. After choosing the destination pane, I select a context, namespace, resource kind, and resource discovered through kubectl, then enter a multiline request. Pressing Ctrl+S renders the collected values as Markdown and sends it to the coding agent in another pane.

The main features are:

• Define input forms with select fields and multiline textarea fields.
• Load select candidates from static values or the stdout of a local command.
• Insert upstream values into command arguments and automatically reload dependent candidates.
• Render structured Markdown from Handlebars templates.
• Search Ghostty and iTerm2 windows, tabs, and panes in a tree and choose a destination.
• Navigate with either the keyboard or mouse.
• Prevent submission when required values are missing and move focus to the relevant field.
• Reset the form after submission so another prompt can be composed immediately.

A workflow can look like this:

name: incident-investigation

inputs:
  environment:
    type: select
    candidates:
      values: [development, staging, production]

  request:
    type: textarea
    allow_empty: false

output:
  template: |
    # Incident investigation

    - Environment: `{{ inputs.environment }}`

    {{ inputs.request }}

It is available through Homebrew:

$ brew install ynqa/tap/convey

It currently supports Ghostty and iTerm2 on macOS. I would appreciate feedback on use cases for workflows, input types you would like to see, and additional terminal integrations.

I've been curious whether you can kill an Claude's text watermark just by editing (not "rewriting/rephrasing") what it wrote. And so I built a Claude/OpenAI/Gemini text-watermark generator plus a detector and threw a bunch of attacks at gpt-oss-20b and Qwen outputs to find out. The technique relies on the famous Tournament Sampling built upon standard Gumbel-max sampling.

It turns out almost everything people assume works, doesn't. Swapping em-dashes for hyphens, stripping markdown, converting AmE to BrE spellings... none of it moved the needle. Across nearly 300 test runs only one attack crossed the detection threshold, and that was deleting 40% of every word, which just wrecks the text.

After rigorous benchmarking, the only method that consistently beat 10/10 times was inserting invisible Unicode variation selectors (the same characters used for emoji and CJK rendering) throughout the text. Performed that to about 30% of characters and the watermark score dropped from 45 down to under 1. And unlike every other invisible character trick I tried, this one survives normalization, because these are real meaningful codepoints that a normalizer can't safely strip.

Interesting finding: Code is barely watermarked to begin with. Watermark strength tracks how uncertain the model is about the next token, and code is low entropy, so some code samples come out basically unwatermarked with zero attack at all.

Not the first repo doing this kind of attack, I know, but I wanted to actually spend the weekend testing it properly across a few different open models instead of rushing something half-baked out.

Repo with all the code and results: https://github.com/aloshdenny/claude-awm

Interactive demo where you can try the attack yourself: https://aloshdenny.com/claude-awm/

Check it out and let me know what you think!

When the AI wave started, we wanted to build real practice into our courses: a student talks to an AI counterpart, gets evaluated, and improves. We tried a lot of approaches, and eventually, after seeing OpenAI's Agent Builder, we decided to build our own version with multi-provider support instead of betting everything on one vendor.

Why our own and not an off-the-shelf tool: we needed to self-host it, and we needed control over our own scoring loop, the part that evaluates how a conversation actually went. That loop is the core of the whole thing for us, and we did not want it locked inside someone else's platform.

The way it works: you build workflows visually by dragging nodes onto a canvas (agents, conditions, HTTP calls, knowledge bases), then run and debug them live. Multi-LLM, self-hostable with a single docker compose, source-available. Your infra, your keys.

After talking to a few other schools, we realized this could be useful beyond us, so we pulled the engine out into a standalone product and added self-hosting.

Would you self-host something like this? And if you do spin it up, I would really like to know where you get stuck, in the setup or in building the first workflow. That is the feedback I need most right now.

https://github.com/nmamizerov/assemblix

Aquifer is an open-source local control plane for AI workloads and MCP infrastructure. It provides durable queues, bounded concurrency, fairness controls, and dynamic pacing for bursty traffic patterns common in agent systems.

It also experiments with the Aqueduct Protocol, a stream and webhook-based coordination protocol that dynamically communicates flow state through headers, allowing clients to scale traffic up or down at a controlled pace instead of relying solely on static rate limits. The project also includes an encryption and identity protocol that uses public-key verification, reducing the need to store shared secrets in a database. The goal is to make agent and MCP traffic more resilient to overload, retries, and traffic spikes.

Repo: https://github.com/rjpruitt16/aquifer