mr-karan
Joined 11 years ago
Karma
926
Submissions
198
Member since
Mar 2
Recent submissions
Comment · 5 days ago
> Throw nine autonomous agents at a single codebase without crystal-clear orchestration, and they will happily rewrite each other's work in a high-speed loop.
This is an easily solvable "problem". Pretty much all harness/agent orchestrators support spawning subagents/threads with different models and get them to work together cleanly. I don't even need any kind of special skills. Inside a vanilla claude session, I sometimes ask it to use `codex` and review the kind and work on the findings it generates.
Comment · 29 days ago
How's this different to https://paseo.sh/ or https://www.onorca.dev/ which seems to be more feature complete? I personally use and like Paseo. I get to connect to my LLM agents even on other machines, remotely via Tailscale and the mobile app UX is quite good.
Comment · 8 months ago
Agreed on SQL being the best exploratory interface for agents. I've been building Logchef[1], an open-source log viewer for ClickHouse, and found the same thing — when you give an LLM the table schema, it writes surprisingly good ClickHouse SQL. I support both a simpler DSL (LogchefQL, compiles to type-aware SQL on the backend) and raw SQL, and honestly raw SQL wins for the agent use case — more flexible, more training data in the corpus.
I took this a few steps further beyond the web UI's AI assistant. There's an MCP server[2] so any AI assistant (Claude Desktop, Cursor, etc.) can discover your log sources, introspect schemas, and query directly. And a Rust CLI[3] with syntax highlighting and `--output jsonl` for piping — which means you can write a skill[4] that teaches the agent to triage incidents by running `logchef query` and `logchef sql` in a structured investigation workflow (count → group → sample → pivot on trace_id).
The interesting bit is this ends up very similar to what OP describes — an agent that iteratively queries logs to narrow down root cause — except it's composable pieces you self-host rather than an integrated product.
[1] https://github.com/mr-karan/logchef
[2] https://github.com/mr-karan/logchef-mcp
[3] https://logchef.app/integration/cli/
[4] https://github.com/mr-karan/logchef/tree/main/.agents/skills...
Comment · 9 months ago
https://mrkaran.dev
Personal blog I update every now and then. Mostly infrastructure, networking, and observability stuff.
Comment · 9 months ago
Just want to say thanks for creating Vector. We use it heavily at Zerodha and wrote about our setup here: https://zerodha.tech/blog/logging-at-zerodha/
It replaced both Filebeat and Logstash for us with a single binary that actually has sane resource usage (no more JVM nightmares). VRL turned out to be way more powerful than we could imagine - we do all our log parsing, metadata enrichment, and routing to different ClickHouse tables in one place. The agent/aggregator topology with disk buffering is pretty dope.
Genuinely one of my favorite pieces of infra software. Good luck with Tero.
Comment · 9 months ago
I've landed on a similar philosophy but with a slightly different approach to orchestration. Instead of managing everything interactively, I built a lightweight bash-based deployment system that uses rsync + docker compose across multiple machines.
The structure is dead simple: `machines/<hostname>/stacks/<service>/` with a `config.sh` per machine defining SSH settings and optional pre/post deploy hooks. One command syncs files and runs `docker compose up -d`.
I could see Claude Code being useful for debugging compose files or generating new stack configs, but having the deployment itself be a single `./deploy.sh homeserver media` keeps the feedback loop tight and auditable.
Comment · 11 months ago
You could perhaps checkout https://garagehq.deuxfleurs.fr/
Comment · 1 year ago
I also quite like Localsend to quickly share files on the same network. Used to send photos/files to myself on Whatsapp/Telegram before but after discovering Localsend, stopped!
Comment · 1 year ago
I've been working on LogChef (https://logchef.app) - a specialized log analytics UI for ClickHouse that focuses on powerful querying and exploration without the complexity of full observability platforms.
The core idea is to leverage ClickHouse's incredible columnar performance for log analytics while providing a schema-agnostic interface that works with any log table structure. It supports both simple search syntax for quick queries and full ClickHouse SQL for complex analytics. Also it has proper RBAC: Team-based access controls for multi-tenant environments.
Off late I have also added some AI features:
- AI-powered SQL generation - write queries in natural language
- MCP (Model Context Protocol) server integration for AI assistants to query your logs
Built with Go + Vue.js + TypeScript. Currently handles millions of log entries daily in production environments at my org. The deployment is just a single binary deployment with a SQLite DB.
Would love feedback from the community! GitHub: https://github.com/mr-karan/logchef
Comment · 1 year ago
It's great to see Typst getting more visibility. We migrated a real-world workload to it a couple of years back: generating and e-mailing 1.5M+ PDFs daily at my org, Zerodha.
Our previous pipeline was LaTeX-based (first pdflatex, then lualatex), but we were constantly fighting cryptic memory errors on large documents and huge Docker image sizes that slowed down boot times of our ephemeral workers.
Switching to Typst was a massive win for us. The single static binary resulted in tiny images and faster boot times. More importantly, the performance gains were huge. Overall compile times were ~3–4× faster than LaTeX. On really large documents (2000+ pages, mostly tables), Typst compiles in ~1 minute vs. ~18 minutes with lualatex.
Beyond performance, the better developer experience and good error messages was a nice bonus too.
We wrote a detailed post about the entire architecture - from the job orchestration with Nomad to the S3 optimizations and the Typst migration in particular. If you're curious, you can read it here: https://zerodha.tech/blog/1-5-million-pdfs-in-25-minutes
https://mrkaran.dev