Show HN: Trifle – Open-source analytics that stores answers, not events https://ift.tt/g25lyxM

Show HN: Trifle – Open-source analytics that stores answers, not events Trifle is an open-source time-series analytics library that aggregates nested counters instead of storing raw events. All in the database you already have. After rebuilding it twice over 10 years, it now tracks ~1B events a day at my day job. It started in 2015 as my own Rails APM. I plugged into ActiveSupport::Notifications, got a few small users, and one bigger one whose scraping app broke everything. That sparked the core idea: aggregate counters into pre-defined time buckets, so a single write increments multiple buckets at once. The APM eventually faded away without much traction. Later in 2021 I needed analytics at my day job. Instead of going for something out there I revised the idea of Trifle as a more generic analytics library, borrowing some data warehouse ideas. First used Redis, then Postgres, eventually MongoDB. Hence why Trifle::Stats comes with multiple drivers that keep the DSL unified while storage layer changes with your needs. In our case (huge write volume, some reads) PG read faster but slowed on large writes. The nested values are the whole trick here. Single: Trifle::Stats.track( key: 'requests::aws::s3_uploads', values: { count: 1, status: { request.response_code => 1 }, size: payload.bytes, duration: { sum: request.duration, count: 1 } } ) builds up counts for requests, success rate, result status codes, duration for multiple time buckets at once. Single bucket from 2am then looks like: { count: 14, status: { 200: 12, 500: 2 }, size: 5628341, duration: { sum: 43, count: 14 } } If request.duration is in seconds, then sum stored under duration would be in seconds as well. Success rate is never stored, but it is calculated by dividing 200s over total number of requests. Same with average duration: sum over count. You ask for a metrics key, granularity and timeframe and you get back aggregated values at each point. Ready for charts or to answer "Average response time over last 30 days". There's a Series wrapper for aggregating and formatting values for charts in a simple call. And as building dashboards is not as much fun for other devs as I thought, I built Trifle App - a visual layer with dashboards, scheduled digests and alerts. It's written in Elixir, so I ported the library to Elixir too. And later to Go for a CLI. All three are compatible, write in one and read in another. Today we track activity from over 100M background jobs a day which turns into about 1B events. It runs surprisingly cheap when you're willing to trade some safety away (turn off journaling and write concerns in Mongo). 3-node Hetzner MongoDB cluster where the primary does 20% utilization costs us around $1k/month. It has its limitations. Payloads can't hold tens of thousands of keys. Documents becomes too large to update efficiently. Some planning ahead is needed. And then there are no dimensions. Sometimes you can nest them (country - there are only so many countries), sometimes it's better to have dedicated metrics key per dimension (customer - growing forever). That multiplies tracked events, hence 1B events from 100M jobs. The libraries are MIT. The App is source-available under ELv2 - free to self-host and paid cloud if you want it managed. I build this on the side with no investor money to burn on a free service. Happy to answer anything about architecture, storage models, my failures or why I didn't give up on this yet. https://trifle.io/ July 22, 2026 at 08:09PM

Show HN: Szr: A safer command output reduction for coding agents https://ift.tt/RauUi6B

Show HN: Szr: A safer command output reduction for coding agents https://ift.tt/6mw2clB July 22, 2026 at 11:33PM

Show HN: Millwright – Rust-based, self-hosted LLM router https://ift.tt/t1jR6DT

Show HN: Millwright – Rust-based, self-hosted LLM router Hey HN, With the news of OpenRouter possibly being acquired and proliferation of hosted LLM routers (i.e. Ramp Router, Vercel’s AI Gateway), I saw the need for a self hosted solution focused on cost savings, transparency, and performance. So, I built an open sourced router with a simple CLI interface that can easily sit between coding agents and GenAI workloads. For the curious and lazy, at the moment, Millwright has the tools for, - Providers: OpenAI-compatible APIs, Anthropic, Amazon Bedrock - Routing: policy-controlled model roles (cheap, mid, frontier), cheapest healthy route selection - Protocols: OpenAI Chat Completions, Anthropic Messages, text and tool translation - Cache Affinity: role-scoped session lanes without serializing concurrent agent traffic - Spend Tracking: per-team costs, cache usage, model/provider mix, request traces - Cost Analysis: measured usage and modeled candidate economics (HTML, Markdown, JSON) - Reliability: bounded failover, circuit breakers, timeouts, concurrency limits - Setup: interactive provider, model, and pricing configuration without storing provider secrets - Deployment: one Rust binary, Docker, SQLite or PostgreSQL Full disclosure: parts of the codebase were built with AI coding agents. All feedback is welcome, I’d especially value feedback on the routing policy, provider coverage, and anything that would block you from self-hosting it. Feel free to open feature/request and/or contribute as well. https://ift.tt/WD7vn09 July 23, 2026 at 12:33AM

Show HN: Onus – self-hostable vuln scanner combining 8 tools into one report https://ift.tt/1hKCLdE

Show HN: Onus – self-hostable vuln scanner combining 8 tools into one report https://ift.tt/FuLSzfh July 22, 2026 at 10:24PM

Show HN: CodeAlmanac – Karpathy-style codebase wiki from your conversations https://ift.tt/nkwGsO9

Show HN: CodeAlmanac – Karpathy-style codebase wiki from your conversations Hey HN! This is Divit from Almanac (YC S26). We built CodeAlmanac, a wiki for your coding agents that updates as you talk to them. It is open-source, local, and free. Here’s a demo: https://www.youtube.com/watch?v=XNQWV3TFBWM Your CC/Codex conversations contain a LOT of knowledge that is forgotten because it was never documented. People have their own methods of documenting their chats. We used to make Markdown files like MANUAL.md and DESIGN.md, and would prompt Claude to keep them updated. The problem is that these files quickly become outdated and messy, and there’s only so much you can put in a single file. So we set out to build CodeAlmanac. We wanted something that was 1) maintained automatically, 2) lived inside our repository, and 3) used our existing Codex/Claude Code subscriptions. CodeAlmanac maintains an almanac/ folder inside your repository. It contains connected Markdown pages that cover things not documented in the codebase, including decisions you have made and why the codebase is shaped this way. The pages are indexed in SQLite and are queryable through a CLI. We add instructions to AGENTS.md or CLAUDE.md so future sessions automatically search the wiki before they start coding. Every five hours, CodeAlmanac uses the Codex/CC SDK to spin up an agent that reads your new conversations and updates the relevant pages. We went with a time-based trigger instead of commits because we saw people commit very frequently, which would lead to high token costs. We originally made CodeAlmanac for individual developers, but the team use case has become much more obvious to us while using it ourselves. We are a team of three, and each of us works with our own coding agents. Before this, I would make some change after a lot of thinking and then later have to call my cofounders and explain why it looked this way. There is almost a sense of relief now knowing that the decisions I made are written down somewhere their agents will actually read. It’s live today for everyone to try. Please let me know your feedback and I’ll be here to answer any questions. Would also love to hear how you all maintain context across conversations today! https://ift.tt/gn3dyWt July 21, 2026 at 10:42PM

Show HN: Framesmith 1.9 – charts as a node type for AI-designed UIs https://ift.tt/DnWyGIL

Show HN: Framesmith 1.9 – charts as a node type for AI-designed UIs https://ift.tt/M1684TP July 20, 2026 at 11:23PM

Show HN: A free lever-based puzzle game https://ift.tt/2PxvCXE

Show HN: A free lever-based puzzle game I made Lever Labyrinth for a final project in my uni's game engine development class and recently ported it to the browser. Check out today's daily! You can then share your result here. Enjoy :) https://ift.tt/izBIRLN July 20, 2026 at 11:20PM