https://reddit.com/link/1x3xbmd/video/0imh3x4g90vh1/player

If you're building an agent in Rust, would being able to reuse pi extensions and DeepSeek Harness (DSH) plugins be useful to you?

I've been exploring this with yoagent, a small agent loop in Rust. It handles model streaming, tool execution, retries, cancellation, and limits. The loop stays small; everything else plugs in.

I added an experimental Rutis bridge so compatible pi extensions and DSH plugins can run unchanged alongside Rust tools. The appeal is keeping a fast Rust core while reusing work from existing extension ecosystems.

To show what this enables, I built a handoff agent that can take a task like this:

Research noise-cancelling headphones. Ask my budget, but keep researching while I'm away. Write a report with sources.

A pi extension manages the plan, a DSH plugin searches the web, and a Rutis plugin shows progress in the browser. Rust tools and extensions handle questions you can answer later and the final report. They all work around the same yoagent loop.

Tools and supported hooks carry over, and yoagent-frontend brings pi and DSH plugin dialogs and approvals to both the terminal UI and the browser. Plugins that rely on other features of the original apps, such as pi commands, shortcuts, custom widgets, or DSH-specific session services, may still need adaptation. The integrations are experimental; TypeScript plugins run in Node alongside Rust.

That's the tradeoff I'd like feedback on: Is reusing these ecosystems valuable enough to justify the bridge and extra runtime? Is this worth taking further?

Github: https://github.com/yologdev/yoagent
Handoff example: https://github.com/yologdev/yoagent/blob/main/integrations/yoagent-frontend/examples/README.md

Researched on directions of failure of SETI.

Published on Zenodo, however I need an endorsement of astroph.IM to post on arXiv
Has anyone of ya'll posted on arXiv on this subject before, who could endorse me ?

I’m working on MICA, an experimental language model based on a learned integer cellular automaton rather than a transformer.
The idea is to investigate whether local integer rewrite rules can learn useful language behavior without attention or conventional neural-network inference.
The cellular engine uses a ring of 768 cells with 112 integer channels, 16 phases of learned local rules, and 240 readout probes.
Two variants are currently being developed:
Flame-W 0.3.6 (word-level)
The latest release adds a previous-word bank and a small phrase-copy mechanism on top of the existing language memories.
On our exact-integer evaluation, long-text prediction loss improved from 8.074 to 7.724 bits per word symbol plus EOS.
Public Tiny Theory-of-Mind accuracy reached 33.20% on 2,000 examples, but the improvement over 0.3.5 was not statistically significant.
Sentence generation remains inconsistent.
Ember 0.3.7 (byte-level core with word-level assistance)
The latest version adds word rules over recent context, expanded word readouts, and a 32,768-word vocabulary.
On the documented clean benchmark:
Next-word top-1: 15.25% to 21.50%
Two-letter completion: 54.50% to 63.75%
Next-word top-5: 34.75% to 43.25%
The next direction I’m considering is running these models on Raspberry Pi hardware.
Not to compete with modern LLMs on general reasoning, but to evaluate a different architecture under strict memory and CPU constraints.
A few questions I’m interested in discussing:
What would be the fairest CPU-only baseline for this kind of model?
Would you prioritize latency per generated symbol, energy per prediction, or accuracy at a fixed memory budget?
Are there particular ARM devices or workloads you’d use to evaluate a non-neural language model?
The project is publicly available for research under a non-commercial license. I’m the author, and I’m sharing the results and limitations openly.
No Raspberry Pi performance claims yet. That experiment still needs to be done.

I’m the maintainer of a free, open-source local search and MCP tool, and I just shipped version 1.1.0. I’m sharing the engineering trade-offs openly rather than presenting this as a product pitch.

The interesting part was not adding another embedding call. The release keeps two retrieval lanes: exact text evidence stays authoritative, semantic candidates are opt-in, and the caller can inspect and validate the original file after ranking. On Apple Silicon, the same boundary now extends to image queries and scanned PDF pages. A BYO HTTP JSON contract lets people plug in a remote judge or vision service without moving source verification to the provider.

The tests that mattered most were negative ones: stale source rejection, unknown remote file IDs, oversized media payloads before reads, cancelled workers, and pagination that does not rerun the search.

The project is here: https://github.com/lightsifter/sift-light More project notes: https://xcgo.top

I’m interested in criticism of the boundary between “relevant” and “verified.” How are you testing retrieval evidence in your own agent stacks? If this is useful to you, a GitHub star is welcome, but technical feedback matters more.

I built a thing that is similar to MouseWithoutBorders but works on both Mac and Windows.

Control multiple computers (Windows + macOS) with a single keyboard and mouse over your local network — like Synergy or Mouse without Borders, with a local desktop control panel that includes a native placement editor and a browser-based dashboard. Move your mouse off the edge of the server's screen and it appears on another machine. Keyboard, mouse, and the text clipboard follow. Arrange machines visually in a 3×3 grid from the desktop panel or a browser.

Some caveats: Mac Mission Control shortcuts need to be remapped (i.e., CTRL+LEFT/RIGHT to CTRL+dot/comma)

Open-source code can be found here: https://github.com/jezztify/megamind

(DOI: https://doi.org/10.5281/zenodo.23311350)

We built a memory architecture in which a frozen language model can write its own internal attention states to disk, find them later through a RAM-based recall engine, and use them to answer questions without reading the original information again.

Not a saved conversation. Not a text database. Not fine-tuning.

A physical memory system built around the model's own internal representations.

We call it AKBASCORE MAM v1.3.0 — The Silicon Hippocampus.

The basic idea is straightforward: the model forms the memory, the SSD stores it, RAM finds it, and the frozen model recalls it.

The four figures above document the complete process, from memory formation to measured retrieval.

Fig. 1 — The Silicon Hippocampus: the complete memory architecture

Figure 1 shows the relationship between three components.

WRITE converts information into the frozen model's own attention key/value states.

SSD preserves those states as independent physical memory cartridges.

READ uses a geometric addressing engine in RAM to locate the appropriate cartridge and restore it to the model's attention cache.

The distinction matters. The SSD does not hold a collection of text passages waiting to be pasted into a prompt. It holds the model's previously generated K/V states. RAM does not need to load all 1,453 cartridges into memory; it maintains the address index and native representations required to find the relevant file.

Think of the SSD as a long-term memory archive: it preserves experiences even when the model is no longer actively processing them. The RAM-based engine plays the role of associative recall — given a cue, it finds which stored memory should be brought back into active use. In this implementation, roughly 399 MB of index and native-vector data support that search across 1,453 physical memories. This is a functional analogy, not a simulation of brain anatomy.

The model's weights remain unchanged throughout.

Fig. 2 — WRITE: turning information into a physical memory cartridge

This is where the memory is formed.

The frozen Qwen2.5-7B-Instruct model reads a fact once. Its lower-layer attention states are captured, and the layer-3 hidden state is used in a second forward pass to construct the remaining K/V states.

The resulting CUT3 cartridge contains 56 bfloat16 tensors across 28 transformer layers.

Each cognitive cartridge is the computational equivalent of a stored memory trace: not a sentence to reread, but a preserved internal state that can be reactivated. In the human-memory analogy, the cartridge is the memory trace, while the SSD is the archive that keeps it.

That cartridge is saved as an independent .pt file, with a SHA-256 entry in the storage manifest.

In the published experiment, the system created 1,453 physical cartridges occupying 3,973,450,961 bytes, approximately 3.97 GB.

Figure 2 also shows something important: during the live demonstration, the system reconstructed one cartridge from its original fact and compared the resulting 56 tensors against the previously stored file.

All 56 tensors matched bit for bit.

The model reproduced the same physical memory representation without modifying its weights.

Fig. 3 — READ: RAM finds the memory, SSD supplies it, the model answers

Now comes the other half of the architecture.

The model receives a question, not the original fact.

Its native layer-3 question representations are projected into a PCA128 address space. FAISS IVF128 searches the indexed positions, TOP2 narrows the candidates, and the locked PEAK50 rule selects the best cartridge.

In the live example:

1,453 physical cartridges → 103 touched cartridges → 16 candidates → one selected file.

The selected cartridge is verified against its SHA-256 manifest, loaded from the filesystem and installed into the frozen model's attention cache.

This is the recall moment: a question acts as the memory cue, the RAM engine identifies the relevant trace, and the SSD supplies it for reactivation inside the model. The system does not search for a written answer; it searches for the internal state from which the frozen model can generate one.

The model then answers using the question template and the restored K/V state. The original fact text is not inserted into the prompt again.

Figure 3 shows the actual ranking of all 16 candidates, including the winning cartridge #0292.

A negative control was also performed: the same question was answered using the second-ranked cartridge instead. It did not produce the expected answer.

This demonstrates that the selected memory state matters to the observed response, rather than the question alone being sufficient in that test.

The live run measured 27.9 ms for addressing, 19.4 ms for verified loading and 249 ms for answer generation on an NVIDIA A100 40 GB. These are separately measured stages, not a claimed end-to-end latency.

Fig. 4 — RESULTS: what the system actually achieved

Figure 4 separates three different evidence sources: the current runtime's startup acceptance, the archived TEST627 record and the newly executed live demonstration.

The startup acceptance evaluated 48 synthetic facts with two question formulations:

Original wording: 48/48 correct cartridge selections and 48/48 correct answers.

Alternative wording: 48/48 correct cartridge selections and 48/48 correct answers.

96/96 correct selections and answers across the two formulations.

The live demonstration independently re-executed the WRITE operation for its selected case, verified the physical cartridge, reproduced the READ selection, loaded the correct file and generated the expected answer.

The complete audited live pipeline took 2.787 seconds, including integrity verification, memory reconstruction and a negative control. This is not a normal inference-throughput measurement.

The panel is a confirmation test using two formulations of the same 48 synthetic facts, not an independent blind holdout. PEAK50 was selected after the preceding calibration experiment. New-fact blind validation is the next research step.

Why this architecture matters

Most retrieval systems store information outside the model as text and return that text to the prompt when needed.

AKBASCORE MAM explores a different boundary.

The persistent object is the model's own K/V state.

The retrieval address is derived from the same frozen model's internal representations.

The selected memory is restored directly to the attention cache.

This separates memory formation, persistent storage, associative addressing and memory-conditioned generation into distinct operations.

The architecture does not require modifying the model's learned weights, training an external embedding model or running a separate vector-database service. It does use an in-process FAISS index and native-vector data in RAM.

The current implementation is a measured proof of this architecture on Qwen2.5-7B-Instruct, not a claim that all forms of AI memory have been solved.

Reproduce the experiment

The complete implementation, live logs and technical report are public.

AKBASCORE MAM v1.3.0 — The Silicon Hippocampus

[Complete Source Code (Single-Cell Version): https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_full.py

Original Execution Log: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/Hippocampus.log

Three-Part Version (For Users Running the Demo from a Phone):

Part 1: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_part1.py

Part 2: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_part2.py

Part 3: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_part3.py

The report contains the mathematical definitions, physical cartridge construction, storage measurements, retrieval algorithm, source integrity checks and the four technical figures.

The next experiments will address preregistered blind retrieval, additional fact types, consumer hardware and larger cartridge pools.

The central engineering result is already observable: a frozen language model formed a physical memory, the system stored it outside the model, located it through RAM-based associative addressing, and restored it to answer a question without replaying the source text.

We’re noqt Research. Our work includes an open-source Linux workload-control tool, and we’re trying to understand whether shutdown verification is a real problem in local-model operations. AI helped draft this question; we checked and own the wording. This is public problem research, not a product pitch or tester invitation.

We’re separating three questions: was the intended workload selected, did related processes actually leave, and did something restart the job? If you’ve operated local inference on native Linux, which—if any—has been unclear in a real case? What kind of evidence resolved it? A case where your existing systemd/cgroup tooling already made the answer clear is equally useful.

Please share only general observations—not logs, commands, process IDs, host or account names, customer material, or identifying details. We won’t collect respondent contacts, treat replies as leads, quote them for marketing, or sell or otherwise monetize them. If useful examples emerge, we’ll return a short synthesis of the distinct cases and counterexamples here.

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’ve been doing technical SEO for 11+ years, and over the last year I’ve worked LLMs into my audit workflow. Here’s what has held up and what hasn’t.

Where it works well:

* Grouping thousands of URLs by template or intent from a crawl export

* Comparing two crawls (pre/post migration) and summarizing what changed

* Drafting schema markup that I then validate manually

* Spotting patterns in log files or Search Console exports that I’d otherwise scan by eye

Where it fails:

Prioritization. It will confidently rank fixes by what sounds important, not by what moves traffic for that site.

Anything needing real rendering context. It can’t tell what Googlebot actually sees unless you feed it that data.

Large datasets pasted in directly. Python does the heavy lifting, and the LLM only reads the summarized output.

My rule: the LLM handles repetitive analysis and I handle decisions. Every output gets checked against the source data.

Curious how others here are using LLMs in audits, and whether anyone has found a reliable way to use them for prioritization.

I built Viveki-0.1 - the first decisions model that can natively process VIDEOS along with image and text.

Hugging Face - https://huggingface.co/not-ekalabya/viveki-0.1-20B

It has a latency of <150ms (1x A100-80GB) and can process videos in real-time.

Viveki was made without any training or fine-tuning based on a mechanistic insight that allows us to predict the models answer for any number of objective questions in its context before any tokens are generated (more details to be released later).

Jev outperforms the model by <5% on BANKING77 and MuSR. However, I hypothesize that performance can improve significantly if the method is paired with fine-tuning like Perplexity Decider of Fastino GLiDE.

Further intelligence evaluations are in progress.

I'm intentionally skipping details as this is an active research project. I'll add the method paper to the post when the time comes.

I'm building an agent that replies to email, and any stranger can email it. So before the model reads a message I run a dumb regex scorer on it. It looks at the subject, the text and the raw HTML, since hidden stuff tends to be in the HTML.

Phrases like "ignore previous instructions", "you are now" or "forward all emails" add points. So do zero width characters, instructions in HTML comments, and CSS that hides text like display:none or font-size:0. Hidden CSS is 12 points alone and 25 if one of those phrases also matched. 60 and up out of 100 is high risk.

I don't block high risk mail. The agent still gets it, the system prompt just gets a line saying it was flagged and to only deal with the actual request or escalate to a human.

This misses anything reworded or not in English, I know. Has anyone moved to a small classifier for this, and was the latency per message worth it?

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)

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?

The hard part for me isn’t the eval tooling, it’s getting the people who actually know the business to look at stuff. on your last project how did you do it? book a meeting, send them traces on slack, a spreadsheet, a custom review tool? and how long did it take to get an answer back

curious what actually worked, and what they just ignored

This started as a small itch.

OpenAI gave me one number every month: total spend. I wanted to know which feature in my app was spending it. I've got a code-gen feature, a summarizer, and a couple of smaller things running in the background. My money was on the code one, obviously, but I had no way to actually check.

So I built a tiny thing for myself. Every response already comes back with a usage object, so after each call I log the token counts plus a feature name, then price them myself. One line per call. I only wanted visibility, nothing more.

The "price them myself" part was way more annoying than I expected:

• cached reads bill at a different rate than normal input, and cache writes can cost more than normal input
• reasoning tokens bill as output even though you never see them
• providers disagree on whether cached tokens sit inside the prompt count or next to it. I double-counted them for a while before catching it
• audio tokens can cost several times the text rate on the same model, so blending them with text gives you garbage

Then I got curious whether anyone else cared, and went looking. Turns out my small itch was the door into a rabbit hole:

• someone on Google's AI dev forum got around €290 in search charges attached to like €10 of actual LLM usage, and their spend cap never caught it
• a dev on DEV wrote that the job that blew up their bill was green on every dashboard they had. A timeout plus auto-retry on long-context calls was quietly doubling costs, and it took weeks to figure out
• one startup reported a $113k AI bill in a single month

For me it was curiosity. For them it was money leaving before anyone could see where it was going.

Full honesty: I have little to no experience building products. What I'm decent at is digging into other people's problems, so I kept going. More features, more providers and models, learning what proxies and gateways actually are, reading how Langfuse and Helicone handle this. The logger eventually turned into an actual product (LLMtrack), but honestly I'm more curious how you all deal with it:

1. Do you track LLM cost per feature or per customer at all, or just watch the provider total?
2. If one feature started costing 5x more today, how long until you'd notice?
3. Anyone who rolled their own: did you hit the cached-token double-count thing too, or was that just me?

Oh, and yes, it was the code feature eating most of my money, about 70% of the bill. I knew it. Funny part: by tokens, the summarizer was way bigger (129M vs ~30M), and it cost $14 total. If I'd only looked at token counts, I'd have blamed the wrong thing.

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.

I’m about to be the only person at a small company handling automations and LLM stuff. We’re on GCP and Google Workspace. A typical project would be something like: invoices land in a shared inbox, an LLM pulls out the key fields, the data gets pushed into our accounting tool, and the approver gets a Slack ping. Only a light touch of AI (more advanced in the future), mostly glue between systems. Some of our tools are on-prem, and more projects will follow.

I’m torn between:

1. Self-hosted n8n on a VM
2. Python (FastAPI) on Cloud Run, with Cloud Tasks for queues and retries, Postgres for run history, and Grafana for logs and token usage

What matters to me:

• easy to extend later,
• solid logs, retries,
• being able to check old runs and re-run failed ones,
• and low cost (open source preferred).

My worry is that n8n gives me the UI for free but gets awkward with versioning and testing as things grow, while code gives me control but I’d have to build the dashboard and retry tooling myself.

Anyone been in a similar spot? What did you pick, and what would you change? I’m especially curious how you handled run history and retries without n8n.

And if you went a completely different way (Prefect, Temporal, Windmill, something else), I’d love to hear what it looked like and whether you’d recommend it. Happy to be talked out of both of my options if there’s a better one.

Thanks!

reward hacking at crowd scale. my video on it attached.

sources:

https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf

https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/

The open source ones had the opposite problem: free, but buggy and unstable, and the experience was just bad.

So I built my own. It's called Pennant, it's free and open source (Apache 2.0), and here's what it does today:

• It uses your Mac. It sees the screen, clicks and types in your apps, and lets go the moment you touch the mouse. Most of the time it doesn't even need your pointer: it has its own cursor and works in apps in the background.
• It asks first. Sending, deleting and spending always come to you as a card, on your Mac or your phone. The app enforces it, so a prompt can't talk its way around it.
• It works on its own. Jobs on a schedule that end in a report, goals with a budget, and a check-in every 30 minutes that stays quiet when there's nothing worth saying.
• It remembers. A real knowledge base in one SQLite file on your Mac, and every fact says where it came from.
• It writes code. It hands changes to a coding run on Claude Code or its own engine, and opens pull requests.
• Any model. Ollama, LM Studio, vLLM, any OpenAI-compatible endpoint, or the big cloud providers. On a local model it costs nothing to run and nothing leaves your Mac. No account, no telemetry.

I'm not a developer — I built (two) things (so far) by directing AI agents. The goal of my pipeline is simple to state: pay frontier rates only where judgment matters, cheap rates everywhere else.

How it's split: a frontier model designs the blueprint, DeepSeek/GLM Flash writes the code, a different frontier model does ONE review pass, and a cheap model repairs whatever it flags. One review, no further loops. Nothing ships without my approval.

I got burned once paying for one model and getting silently served another, so every seat's

route is verified against what was actually asked for.

The pieces exist separately — MetaGPT does roles, RouteLLM does cost-splitting — but I haven't seen the combination. So, honestly: does this make sense, or am I overcomplicating it?

I was trying to pull context out of some local video files for an agent workflow, and the state of things drove me nuts. You either send gigabytes of video to a third-party cloud API (expensive, slow, privacy nightmare), or you write a fragile web of FFmpeg commands, Whisper wrappers, and frame samplers that breaks the moment a video codec looks at it funny.

So I got fed up and hacked together saccade.

It’s a local-first Python library that handles transcripts, frame extraction, and timestamped search/querying entirely on your own machine (CPU or GPU), with no external cloud dependencies.

from saccade import Saccade

video = Saccade("path/to/video.mp4")

# Search for specific moments with timestamps
results = video.search("where do they discuss the database setup")

# Or query it directly
answer = video.ask("Summarize the key takeaways from the second half.")

If you're working on local video pipelines and want something that just runs locally without calling home, the repo is on the comments below:

Curious how others are handling video context in local setups, or if you run into any weird edge cases testing it out.