r/LLMDevs

Coding agents run shell commands constantly. I wanted each one checked before it executes, and I didn't want to send every command to a paid API.

laya-guard runs on your machine and answers allow, review, or block for each tool call. Regex policies catch known-dangerous patterns first (rm -rf /, curl … | sh, secrets, auth bypass). Plain commands like ls, git status and npm test skip the model, but only when there's no piping, chaining or redirecting, no -exec-style flag, and no sensitive path. Everything else is judged by Laya (~322M, Apache-2.0) on the CPU in about 85 to 90 ms.

The results are self-reported and the scripts are in the repo. On AgentDojo v1 (judge-level) it blocks 25 of 27 attacks and keeps 92 of 97 benign tasks. On my own 50-command shell set it gets 48 right.

Two caveats. The model is tuned mostly on Korean, so English natural-language prompts get overblocked more often. And if the server is down, the hooks fail open.

It has hooks for Claude Code, Codex CLI, Cursor, Gemini CLI, Copilot CLI and 6 other agents.

Repo: https://github.com/scs0209/laya-guard (install with pip install laya-guardrail)

laya-guard: A local guardrail for coding agents that checks every tool call

I built laya-guard, a local guardrail that checks tool calls made by your coding agent and decides whether to allow, review, or block them.

It runs entirely locally, needs no API key, and takes around 90 ms per command on a CPU.

• Regex rules catch obvious risks like rm -rf /, curl ... | sh, and leaked API keys.
• Simple commands like ls and npm test skip the model entirely.
• Everything else is evaluated by Laya, a ~322M local model.

It supports Claude Code, Codex CLI, Cursor, Gemini CLI, Copilot CLI, and 6 other agents.

I also tested it on AgentDojo at the judge level: it blocked 25 of 27 attacks while allowing 92 of 97 benign tasks. These are my own measurements, and the README documents the current limitations.

It's free and MIT-licensed. Install it with pip install laya-guardrail.

I'd especially appreciate feedback on commands that slip through or cases where legitimate commands get blocked. Those are the areas I'd most like to improve.

We’ve released Levy-1, our first AI model — and we’d love your feedback.

We’re a small team building Toothed AI, and we’ve recently released Levy-1, our first model, with just 124 million parameters.

It definitely makes mistakes and has plenty of limitations, but this is our starting point, not our final goal. We plan to build better models over time and keep learning along the way.

We’d really appreciate it if you gave it a try and shared your honest feedback. If you have experience training language models, we’d also love to hear your advice on what we should focus on for our next model.

Website: https://toothedai.com/

Thanks for checking out our work!

A2A agents publish an Agent Card that lists their skills, inputs and outputs. Other agents and teams decide whether to trust an agent based on that card. Nobody checks whether the agent actually behaves the way the card says, so we built something that does.

How it works:

- The card is fingerprinted (RFC 8785 canonical JSON + SHA-256). Every result is tied to the exact card version that was tested.

- Tests are drafted only from the examples the card itself declares. A human approves the criteria before anything runs.

- A separate runner process is the only part that holds the agent's credentials. It only talks to the approved host and redacts secrets before anything is stored.

- Layer 1 is deterministic: status, schema, media type, required content. Layer 2 is a pinned model (Claude Haiku 4.5) used only for checks that need meaning, like "is this a correct summary". The model, endpoint and rubric version are recorded with every result.

- Results go into an append-only store and the report is signed with Ed25519. Change one byte and verification fails.

Design choices: no single trust score (pass / fail / inconclusive per skill), inconclusive never counts as pass, every report lists what was NOT tested, and the final decision is always "flag for human review".

We ran it against 8 of the official A2A sample agents. Several declare "text" as a media type where the spec expects a MIME type like "text/plain". Small, but it's exactly the kind of card-vs-behavior gap we want to surface.

Caveats:

- A2A 1.0 only, no 0.3 yet.

- Coverage is only as good as the card's declared examples. Thin examples mean thin tests, and the report says so.

- Layer 2 is a model's judgment, not proof. That's why it's pinned, versioned and only runs after Layer 1.

Next up: adversarial probes (undeclared requests, prompt injection, failure handling).

If you're building an A2A agent, we'll test it for free and send you the signed report: https://www.suncly.com

What would you want to see in a report like this before trusting someone else's agent?

I wrote this (aigent-OS, MIT, no paid version), so take it with that in mind.

Most long context agent setups deal with a full window by summarizing. Compact the history and keep going. I wanted the other end of that tradeoff on Claude Code: throw the whole window away on a schedule, but only after the agent has written a checkpoint and confirmed it, then bind a fresh session to that checkpoint.

One cycle looks like this:

context >= threshold

-> send one checkpoint request

-> wait for exactly one acknowledgement line

-> send exactly one /clear

-> confirm a genuinely new session started (new session id from the SessionStart hook)

-> send exactly one resume prompt

Stuff that turned out to matter more than I expected:

At most once. One acknowledgement authorizes one clear. If anything is ambiguous it halts and reports instead of retrying. Losing a cycle is recoverable, a double clear isn't.

Identity comes from the live hook, not from files. Checkpoint text and receipts on disk are just history, never proof of who's running. I learned that when a second headless process wrote the same receipt file.

One writer to the terminal. The runner owns the PTY, my own keystrokes get queued while it's typing a command, and command text and Enter are written separately.

Saved text is untrusted. Anything loaded from memory gets tagged with source, hash, time and no authority, so a checkpoint can't sneak in instructions.

Why I care: I run four of these seats every day and they run my newsletter, The AIgent (close to 9k subscribers). Around the refresh loop there's a layer that suggests the right skill on each prompt, guards what gets written to memory, ranks stale notes below current ones, and checks which model tier a sub-agent gets. When a seat hits a real failure, the fix comes back to the public repo with a test. One example: a check of the live seats found 3 of 4 would have resumed into a checkpoint with no actual next step, so now it refuses to resume into one. That's operating experience, not a measured outcome, and I'm not claiming it grew anything.

Results, kept small on purpose: 11 of 11 cycles on one reference seat, each with one request, one ack, one clear and one fresh session, zero duplicate clears. A sped up test then failed outside the loop. The model wrote several "done" lines inside one session and declared it finished, which threw out a proposed 20 cycle count. So the claim stays at 11. Write up: https://github.com/wrg32786/governed-agent-organizations/blob/main/case-studies/continuity-and-auto-refresh.md

Still open: telling multiline input apart from a submit, recovering when the new session's identity check gets stuck, and not much macOS mileage yet. Known issue in the current release candidate: a long session can stall at the clear step. There's a recall benchmark in the repo but no passing result yet, so no claim about recall quality.

Code: https://github.com/wrg32786/aigent-os (the loop is in daemons/auto-clear-transport.mjs and daemons/pty-runner.mjs)

The thing I'd most like pushback on is halting on ambiguity. For an unattended agent, is that the right default, or would you take a bounded retry?

I built LlamaStash to scratch a personal itch: I run local models through llama.cpp on AMD Strix Halo and got tired of writing the same llama-server wrapper script for the tenth time.

Ollama and LM Studio both wrap llama.cpp but hide too much (and cost real performance). Raw llama-server is fast but tedious. LlamaStash is the middle ground.

What it does:

• llamastash init — first-run wizard. Detects your hardware (CUDA / ROCm-HIP / Metal / Vulkan / CPU), installs llama-server, scans your existing HuggingFace / Ollama / LM Studio model caches, recommends a GGUF that fits your VRAM, downloads it, writes a tuned config, smoke-launches it.
• TUI + CLI + daemon + OpenAI-compatible proxy in one Rust binary. The proxy at 127.0.0.1:11435/v1 lets OpenCode, Cline, the OpenAI SDKs, and llm-cli work as-is. There's also an opt-in --ollama-compat mode that takes port 11434 and answers the byte-exact "Ollama is running" handshake.
• Multi-model concurrency with per-model port allocation, /health-probed state machine, intelligent context auto-fit (sidesteps llama.cpp's --fit collapse on Linux iGPUs).
• Agent-friendly CLI: every TUI capability has a CLI subcommand, --json is a stable agent contract, documented exit codes per failure class.
• In-TUI HuggingFace browser with search, sort, paginate, per-file hardware fit, download with cancel.

On performance — this is the part that matters for this sub.

LlamaStash spawns the unmodified upstream llama-server. So the wrapper should add zero overhead. I measured it. Across AMD APU (Ryzen AI Max+ 395), Apple Silicon, and NVIDIA, on four model sizes (small E2B Q4, mid 31B Q4, large 27B Q8, large MoE 35B-A3B Q8), every cell matches raw llama-server within ≤1%.

Cross-tool numbers on AMD APU (decode tok/s / TTFT ms on chat_turn):

Tool	small	mid	large_dense	large_moe
LlamaStash	86.9 / 51	9.8 / 467	7.4 / 417	42.6 / 181
raw llama-server	86.0 / 51	9.9 / 468	7.4 / 414	42.7 / 186
LM Studio 2.16.0	91.1 / 187	11.6 / 1477	7.9 / 1274	37.0 / 683
Ollama 0.24.0	50.4 / 223	4.8 / 1092	2.6 / 1745	12.1 / 476

LM Studio wins decode on small/mid/large_dense (their Vulkan path is well-tuned on gfx1151) but loses on the MoE and pays a 1-1.5s TTFT tax from its OpenAI shim. Ollama is consistently slower, and its RAG prefill is catastrophic (cold prefill every rep — 4 min on a 31B). Mac and NVIDIA tables are in the benchmarks page.

Methodology, variance gates, fairness rules, and per-cell JSONs are all checked in. The harness is reproducible: make bench-end-to-end. Tear it apart.

What it's not:

• Not an Ollama fork or replacement (though --ollama-compat exists for tools that auto-detect Ollama).
• Not a model hub.
• Not a llama.cpp fork. Same upstream binary.
• Not a hosted service. Loopback-only in 0.0.2. LAN + auth + TLS are on the roadmap.

Install:

curl -fsSL https://llamastash.dev/install.sh | sh   # macOS + Linux one-shot
irm https://llamastash.dev/install.ps1 | iex        # Windows 11 (PowerShell, no admin)
scoop bucket add llamastash https://github.com/llamastash/scoop-llamastash && scoop install llamastash
brew install llamastash/llamastash/llamastash       # Homebrew (macOS + Linuxbrew)
yay -S llamastash                                   # Arch Linux (AUR — source build)
yay -S llamastash-bin                               # Arch Linux (AUR — prebuilt binary)
yay -S llamastash-git                               # Arch Linux (AUR — main checkout)
cargo install llamastash                            # any Rust toolchain

Then llamastash init and you're up.

Platform: Linux (x86_64, aarch64), macOS (Intel, Apple Silicon), Windows 11 (x86_64). aarch64-pc-windows-msvc and Windows AMD GPU detection on the roadmap.

Honest tradeoffs: Single-author project. Bug reports especially welcome on hardware I don't own. The OpenAI-compat surface covers chat/completions, embeddings, rerank; Anthropic /v1/messages shim is coming.

Repo: https://github.com/llamastash/llamastash

Blog post with the full story: https://deepu.tech/introducing-llamastash

Benchmark methodology: https://deepu.tech/benchmarking-llamastash

Happy to answer questions in the thread.

For a furniture maker, a useful Reddit post could explain which measurements a customer should take before ordering a dining table: room size, space to move the chairs, and the delivery route. That gives people something practical to use and a specific question to ask next.

Here is a simple checklist for turning that kind of expertise into a community post:

1. Find a community discussing the actual buying problem. Read its promotion rules and use the designated thread if it has one.

2. Answer one customer question in the post itself. Make the explanation useful before asking anyone to visit a website.

3. Disclose your connection to the business and use a link only where permitted.

4. Save the permalink and check what happened after posting. An entry in your own profile does not by itself prove other readers can see it.

5. Return for real questions. Keep post views, website visits, inquiries and paid orders as separate numbers.

I'm with the ThreadFox team at AMF Indiana. We put the process into a free guide you can follow with a spreadsheet:

https://threadfox.vip/guides/reddit-self-promotion?utm_source=reddit&utm_campaign=tf-businesspromotion

ThreadFox also offers a paid toolkit for your own AI assistant and browser, plus a managed campaign service if you want us to do the research, posting and follow-up. The options and published scope are here:

https://threadfox.vip/?utm_source=reddit&utm_campaign=tf-businesspromotion

I’ve been building Tau for the past 6 months a free, open-source coding agent that runs in your terminal. I wanted an agent that costs less and gives better results, with the tools already built in so you don’t have to go hunting for plugins or struggle with visibility issues. That’s why Tau focuses on optimal path execution to minimize token usage and speed up tasks, plus inline image rendering with diagrams so you can clearly see what the agent is doing at every step.

Here's what it can do:

- Native adapters for 28 providers. It talks to each API directly, no proxy in between. Run `/login`, pick a provider, and start working.

- The full agent loop: tools, skills, subagents, MCP servers, LSP and hooks, all working with every provider

- Core tools are optimized to use fewer tokens. The search tool runs on the latest version of ripgrep and is configured to avoid false positives from files and directories such as node_modules and dist the kinds of files that pollute the context. The file-reading tool starts with a skeleton, then reads only the 50 lines it needs instead of an entire 800-line file, fetching only the information relevant to the task. Bash commands go through a security check based on a Go shell parser and best-practice guidelines.

- LSP built in, so the agent sees real type errors, definitions and references.

- Snapshots of your working tree in a separate git repo. Save, diff and restore any time without touching your branches.

- Web search that works with no API key. Firecrawl is there too if you have a key.

- `/remote` lets you follow and approve from your phone, over your Wi-Fi or a free Cloudflare tunnel. Share the tunnel link and your teammates can join the same session.

- TauCode can make your whole workflow up to mush cheaper than any other agent and I’m not exaggerating. This is because TauCode uses a Python kernel tool, anything Python can do, TauCode can do through this tool. For example, when you want to analyze 20 CSV files and extract insights, other agents might need ~30 turns (one turn per CSV), causing the context window to grow, costs to rise, and more analysis/debugging turns. With this tool, TauCode creates one turn with the full workflow, executes it at once, and returns the result. So the context stays clean from pollution, debugging is clearer, output quality is higher, and cost is lower. This is just one example among millions.

- Most agents treat the terminal as plain text, dumping logs and code instead of showing what they’re working with. Tau renders images inline and draws diagrams directly in replies, using real pixels where supported and Unicode art everywhere else, so you can see the agent view and reasoning without leaving the terminal.

- A fully integrated browser tool that allows Tau to interact with the browser like a human. It gives Tau visibility into your frontend design, enables more automated testing, and handles tasks that would normally require human intervention.

- Subagents that stay alive after they finish, so you can send them a follow-up and they still have their context. Agents working in parallel take turns on the same file so that prevent overlapping .

-TauCode thinks about your money and preferences before anything else. You don’t need skills, agents, or MCP for a normal workflow without enabling them just use cheap mode if you need those capabilities, enable them in normal mode with one command: /mode normal. For tools that free you from basic MCP for diagram production, browser automation, etc. they’re all gated and native to TauCode. You just enable or disable them on demand by pressing /tools, so you pay less, or nothing when you don’t need them Second, Tau focuses more on stabilizing your cache hit rate so every model wired to it uses an optimal cache system, so you don’t need to worry about cold turns that your API pays for, with more context growth optimization and a preflight system that prevents some defective turns, so you will pay only for what you use, not for those external factors .

- `/github` for issues, PRs, labels, changelog notes and release checks through `gh`.

- Fallback to another model or provider when one fails or gets overloaded, with the context window adapting when you

switch.

- Session tree navigation, branching, cloning and resume for long sessions.

- Live usage and session stats, plus a readable report at the end.

- It reads the rules you already wrote for other tools: AGENTS.md, Cursor, Copilot, Cline, Clude Code and Windsurf.

- Self-learning. After a big task it suggests one reusable lesson you can approve, edit or skip, and it remembers it in future sessions.

GitHub: https://github.com/AbdoKnbGit/tau

I’m happy to answer any questions. You can find more details and images in the README, and I’m open to answering any questions you may have.

The more I think about prediction markets, the more useful they seem as real-time probability engines for events such as elections, wars, regulation, tariffs, and broader geopolitical risks.

Is there already a tool where you can upload your stock portfolio and automatically identify relevant Polymarket or Kalshi markets?

For example:

• Which prediction markets are most relevant to my holdings?
• Are current probabilities creating headwinds or tailwinds for my portfolio?
• Which stocks have the highest exposure to a specific event?
• How would my portfolio react if the market-implied probability changed significantly?

Essentially, I am looking for a portfolio risk dashboard powered by prediction-market data.

Does anything like this already exist? And would you actually use it?

EDIT - Found Oracle Markts here via my ChatGPT "research" and user comment: https://oraclemarkets.io/portfolio

I’m Sietse, founder of Corbenic AI

When an AI model reads it uses GPU, my idea it should not always be the case, also for reuse of agents. KV cache. Galahad saves the work and can bring it back when the same comes up. so the model may not need to do the same work twice.

We are launching our beta this afternoon. I am doing some last tests, ( freaking out) I tried to make It work with vLLM, SGLang, and llama.cpp. Galahad has already some extra features build in specially for agents, and we will keep it free for 1 gpu users for non commercial use. As we are in beta, we are open for cluster pilots or Kubernetes.

We’re excited to share what we’ve built and hear what you think. I am sorry for my english, i try my best, But i am a non native speaker. - https://github.com/corbenicai/galahad

Dear LLM developers community,

I have just released four open-source projects today that let an application use the Laya model directly, with no server and no Python.

What Laya is?

If you build agents, this is the step where you ask a big model "should I route this to billing?" and wait a second for one word. Laya answers that kind of question in a fraction of a second, on your own machine, with a probability you can put a threshold on.

Laya is an AI model that does not chat. You give it a text and a question, like "is this customer asking for a refund?", and it answers yes or no with a probability, in a fraction of a second. It can also pick one of several options, or rate something on a scale. Quick decisions, no essays.

What I released

- LibLayaX: a library you load into your own program, like any other. Windows, Linux and macOS, on the CPU or the GPU.

https://github.com/DaragonTech/LibLayaX

- RLaya, for Rust: https://github.com/DaragonTech/RLaya

- LLaya, for Lua: https://github.com/DaragonTech/LLaya

- DLaya, for Delphi and Free Pascal: https://github.com/DaragonTech/DLaya

On a laptop GPU it makes about 670 decisions per second.

Everything is MIT licensed.

Why

On Thursday I wanted to use Laya inside one of my applications and found there was no way to do it. It only came as a Python library and as a separate server program. This kind of AI belongs inside ordinary software, routing a ticket or flagging a message, and for that it has to be something an app can simply call.

How it was built

I did not write the code. Claude did. My job was to decide what we were building, guide Claude and run every version on real machines, and report back what happened.

The first version arrived within an hour and crashed on my PC. A few rounds later it worked. By the end of the first evening it ran on Windows, Linux and Mac, and on the GPU. The worst bug was on Windows on ARM, where the program simply froze. It could not be reproduced anywhere except on my actual machine, so we hunted it by adding log lines and reading where it stopped.

The second day went into the Rust and Lua versions, documentation, and testing on more machines. From my first question to Claude to this post: about 32 hours on the clock.

I could not have built this in two days by myself, and Claude could not have found those bugs without someone running the code on real hardware. It took both.

Status

Tested on five platforms and three GPUs. The docs say plainly what has not been tested yet, and test reports are welcome.

Credit

None of this would exist without two projects by other people:

- Laya itself, the model, by Nandakishor Mukkunnoth of ConvAI Innovations: https://github.com/NandhaKishorM/laya

- laya.cpp, the C++ port this is built on, by Lars Karlslund: https://github.com/lkarlslund/laya.cpp

The code and docs of the four projects above were written by Claude (Anthropic)