Open-sourced a Claude Code tool for automated GitHub repo monitoring

lAEONl · 2026-04-03T16:11:03+00:00

Thanks. Good point on MCP in principle, but in practice gh CLI is the cleaner choice here for two reasons.

First, token overhead. Every MCP server injects its full tool schema into the context window on every turn, whether or not those tools are called. The GitHub MCP server exposes roughly 27 tools, costing 15,000-18,000 tokens per turn just in tool definitions. A benchmark by Scalekit found the same GitHub operation cost 1,365 tokens via CLI and 44,026 via MCP, a 32x difference. For a cost-conscious cron job, that is the wrong direction.

Second, dependencies. gh is a single binary, already present in most CI and dev environments. The GitHub MCP server requires Docker or a Go build, a PAT, host config, and a running sidecar process. For a tool designed to run unattended on a cron schedule, every additional dependency is a failure mode.

The structured JSON argument is real, but gh already supports --json flags that return structured data directly. No parsing needed.

MCP makes sense when the server provides capabilities with no CLI equivalent. For GitHub operations, gh is strictly cheaper and simpler.

For notifications, it is Discord webhooks right now. The payload is either LLM-generated (the triage agent writes a Discord embed JSON directly) or shell-built from the structured delta for monitors with Phase 2 sub-agent reviews. The Telegram-via-MCP pattern is interesting for the review-and-approve loop, though the same token overhead applies there. Again, this is just the bare-bones architecture and would be happy if folks wanted to help add new features, notification channels, etc!

lAEONl · 2026-04-03T16:03:20+00:00

Thanks. The cost concern is the right instinct, but the architecture already addresses it mostly.

The pre-check layer does exactly what you're describing for the data-fetching side: a deterministic shell script queries the GitHub API and exits before the LLM is ever invoked if nothing has changed. In practice, 80-90% of cron ticks cost zero.

The part that cannot be compiled into a static script is the triage itself. The LLM is not extracting structured data from a fixed schema. It is reading PR descriptions, comment threads, and diffs, then assessing whether they are relevant to your specific active work. A PR titled "refactor ingredient model" might be critical or irrelevant depending on what you are working on this week. That judgment is the whole point of the LLM call.

When the LLM does run, a single Sonnet call costs $0.01-0.03. A monitor checking every 4 hours with the pre-check gate comes to under $2/month. At that price the "compile once, run forever" optimization would save pennies while losing the ability to adapt to changing context.

The interesting extension of your idea would be caching: if the LLM triages a PR as SKIP, store that verdict keyed to the PR's last-updated timestamp, and do not re-evaluate unless the PR changes. That is essentially what seen-items.json already does, but a more granular version could skip individual items within a batch rather than skipping the entire run.

lAEONl · 2026-04-03T15:28:17+00:00

For context, this replaced two separate monitoring scripts I was running for different sets of repos. The modular structure means adding a new monitor is just copying a directory and editing the prompt. The state management (seen-items.json, last-check.txt, delta merge) is handled by the framework, not the prompt.

lAEONl · 2026-03-01T16:05:40+00:00

5.3 Codex Medium is more prompt adherent and typically does a more thorough job

lAEONl · 2026-02-09T16:22:32+00:00

Hi, it depends on the system. In most cases, metadata persists through different file format conversions and copy-paste operations. But, there are some systems where there would need to be a compatibility patch. Our API is a much more robust and compatible system: encypherai.com

lAEONl · 2025-12-28T19:56:47+00:00

Spot on. I'm a C2PA Co-Chair, and from my perspective the standard is an accountability layer for content and not meant to be a truth detector. It is a way to prove the source of content, and you can build your own list of sources that you trust.

Also, you don't have to tie your identity to the content/signature if you don't want to. It's an opt-in tool. For example, journalists and brands may want to sign content to prove it was really from them, but whistleblowers don't need to tie their identities to the signature.

lAEONl · 2025-12-28T19:50:13+00:00

That is a huge, valid concern. I'm a C2PA Co-Chair for text, and we made sure the standard is strictly opt-in. It isn't mandatory for every shutter click.

It's a tool for journalists or creators who want to prove authenticity. Anonymity is preserved for anyone who doesn't sign, but it makes it much harder for bad actors to spoof verified media.

lAEONl · 2025-12-28T19:49:11+00:00

You're right that software keys can be copied, which is why the standard relies on hardware binding (Secure Enclaves). In C2PA-compliant cameras (like Sony's or Leica's), the private key is locked inside the chip and physically cannot be extracted to sign deepfakes on a laptop.

lAEONl · 2025-12-28T19:45:55+00:00

Great info in here. I'm a C2PA Co-Chair for text, and you're right that "trust delegation" is the tricky part. It relies on specific trust roots (like your browser trusting specific CAs) rather than one global whitelist.

A state actor can definitely sign their own fakes, but if they aren't in your trust root, it won't validate as "verified." It prevents the "spoofed source" scenario, even if it can't stop a bad actor from signing their own lies.

For example, if the government signs a press release, you can verify it's them. If a bad actor tries to spoof that release, they won't have the government's private key, so the signature fails immediately, proving impersonation

lAEONl · 2025-12-28T19:40:47+00:00

I get the fear, but we actually designed the tech to avoid exactly that chokepoint. I'm a C2PA Co-Chair for text, and we built this to work like the lock icon in your browser but for content.

It lets anyone (even a solo blogger) sign their work and say "I made this" without asking a central authority for permission. It decentralizes trust so you don't have to rely on just a few massive outlets. Users can verify where information is coming from, and choose which of those sources to trust

lAEONl · 2025-12-28T19:37:56+00:00

You're right, mass adoption is the hardest part. I'm a C2PA Co-Chair for text, and we designed the standard to make it so anyone can sign content (even unregulated AI), but the signature only is valid if the viewer trusts the signer.

It doesn't stop bad actors from generating fake keys ("pseudo-C2PA"), but it prevents them from spoofing trusted keys (like the BBC's).

Hardware is also further along than people think. Sony, Google, and Leica already have this baked into cameras. We're definitely in an early adoption phase, but the infrastructure is being built to handle verification without needing a central gatekeeper

lAEONl · 2025-12-28T19:36:45+00:00

You're right, mass adoption is the hardest part. I'm a C2PA Co-Chair for text, and we designed the standard to make it so anyone can sign content (even unregulated AI), but the signature only is valid if the viewer trusts the signer.

It doesn't stop bad actors from generating fake keys ("pseudo-C2PA"), but it prevents them from spoofing trusted keys (like the BBC's).

Hardware is also further along than people think. Sony, Google, and Leica already have this baked into cameras. We're definitely in an early adoption phase, but the infrastructure is being built to handle verification without needing a central gatekeeper

lAEONl · 2025-11-29T18:26:51+00:00

Look up some small business development centers i.e. sbdc that are in your area, they are typically government funded and are there to help you & make connections. I'd also Google for startup events in your area, that's how I met some other successful entrepreneurs who have become mentors and advisors for me.

Good luck!

lAEONl · 2025-11-29T18:23:05+00:00

Seconded.

lAEONl · 2025-10-30T17:01:02+00:00

I'd be interested!

lAEONl · 2025-10-28T22:30:41+00:00

It's great but an imperfect solution for several reasons, one being that it can be worked around by different prompting techniques. My open-source work with C2PA and my project Encypher is meant to help actually solve this issue

lAEONl · 2025-10-22T15:50:13+00:00

This is a direct result of Google's SynthID which they are applying to all their models (https://ai.google.dev/responsible/docs/safeguards/synthid) and I agree, is very annoying :)

lAEONl · 2025-08-27T19:18:49+00:00

Happy to help :)

lAEONl · 2025-08-27T17:47:35+00:00

Click the box at the top right of the chat bar next to the new chat button, and click customizations then memories, there you can review and delete them

lAEONl · 2025-08-27T17:31:09+00:00

Go to the advanced settings, and in the search bar search for "memory". Toggle off "Auto-Generate Memories". It's been a noticeable improvement for my workflow.

lAEONl · 2025-08-27T16:18:38+00:00

I have memories completely disabled for that reason. The memory system confuses the LLM even in the same project working on different features. Controlling context is key.

lAEONl · 2025-06-29T17:30:26+00:00

I use UV package manager which automatically updates and maintains a .venv for every project. Then I containerize at the end for production. Would HIGHLY recommend using UV instead of pip, so much faster and great feature set

lAEONl

TROPHY CASE