🛠️ Hacker News Tools

Showing 981–1000 of 2497 tools from Hacker News

Last Updated
April 23, 2026 at 04:00 AM

[Other] Show HN: High speed graphics rendering research with tinygrad/tinyJIT I saw a tweet that tinygrad is so good that you could make a graphics library that wraps tg. So I’ve been hacking on a gtinygrad, and honestly it convinced me it could be used for legit research.<p>The JIT + tensor model ends up being a really nice way to express light transport all in simple python, so I reimplemented some new research papers from SIGGRAPH like REstir PG and SZ and it just works. instead of complicated cpp its just a 200 LOC of python.

Found: January 22, 2026 ID: 3084

[IDE/Editor] Show HN: Sweep, Open-weights 1.5B model for next-edit autocomplete Hey HN, we trained and open-sourced a 1.5B model that predicts your next edits, similar to Cursor. You can download the weights here (<a href="https:&#x2F;&#x2F;huggingface.co&#x2F;sweepai&#x2F;sweep-next-edit-1.5b" rel="nofollow">https:&#x2F;&#x2F;huggingface.co&#x2F;sweepai&#x2F;sweep-next-edit-1.5b</a>) or try it in our JetBrains plugin (<a href="https:&#x2F;&#x2F;plugins.jetbrains.com&#x2F;plugin&#x2F;26860-sweep-ai-autocomplete--coding-agent" rel="nofollow">https:&#x2F;&#x2F;plugins.jetbrains.com&#x2F;plugin&#x2F;26860-sweep-ai-autocomp...</a>).<p>Next-edit autocomplete differs from standard autocomplete by using your recent edits as context when predicting completions. The model is small enough to run locally while outperforming models 4x its size on both speed and accuracy.<p>We tested against Mercury (Inception), Zeta (Zed), and Instinct (Continue) across five benchmarks: next-edit above&#x2F;below cursor, tab-to-jump for distant changes, standard FIM, and noisiness. We found exact-match accuracy correlates best with real usability because code is fairly precise and the solution space is small.<p>Prompt format turned out to matter more than we expected. We ran a genetic algorithm over 30+ diff formats and found simple `original`&#x2F;`updated` blocks beat unified diffs. The verbose format is just easier for smaller models to understand.<p>Training was SFT on ~100k examples from permissively-licensed repos (4hrs on 8xH100), then RL for 2000 steps with tree-sitter parse checking and size regularization. The RL step fixes edge cases SFT can’t like, generating code that doesn’t parse or overly verbose outputs.<p>We&#x27;re open-sourcing the weights so the community can build fast, privacy-preserving autocomplete for any editor. If you&#x27;re building for VSCode, Neovim, or something else, we&#x27;d love to see what you make with it!

Found: January 21, 2026 ID: 3083

[CLI Tool] Show HN: Retain – A unified knowledge base for all your AI coding conversations Hey HN! I built Retain as the evolution of claude-reflect (github.com&#x2F;BayramAnnakov&#x2F;claude-reflect).<p>The original problem: I use Claude Code&#x2F;Codex daily for coding, plus claude.ai and ChatGPT occasionally. Every conversation contains decisions, corrections, and patterns I forget existed weeks later. I kept re-explaining the same preferences.<p>claude-reflect was a CLI tool that extracted learnings from Claude Code sessions. Retain takes this further with a native macOS app that:<p>- Aggregates conversations from Claude Code, claude.ai, ChatGPT, and Codex CLI - Instant full-text search across thousands of conversations (SQLite + FTS5)<p>It&#x27;s local-first - all data stays in a local SQLite database. No servers, no telemetry. Web sync uses your browser cookies to fetch conversations directly.

Found: January 21, 2026 ID: 3079

[Other] Show HN: What I learned building a local-only password manager (PassForgePro) Show HN: What I learned building a local-only password manager (PassForgePro)<p>Hi HN,<p>I built PassForgePro as a learning project to better understand password manager design, local-first security, and common cryptographic pitfalls.<p>The goal was not to replace mature tools like Bitwarden or KeePass, but to explore:<p>* how a local-only, zero-knowledge style design can work * key derivation with PBKDF2 and encrypted SQLite vaults (AES-256-GCM) * handling sensitive data in memory and clipboard cleanup * defining a realistic threat model and its limitations<p>This project is experimental and unaudited. I’m sharing it mainly to get feedback on the architecture, crypto choices, and overall approach, and to discuss what I got wrong or could improve (audits, reproducible builds, testing, etc.).<p>I’d really appreciate feedback, especially from people with security or cryptography experience.<p>Repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;can-deliktas&#x2F;PassForgePro" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;can-deliktas&#x2F;PassForgePro</a> Docs &#x2F; demo: <a href="https:&#x2F;&#x2F;can-deliktas.github.io&#x2F;PassForgePro" rel="nofollow">https:&#x2F;&#x2F;can-deliktas.github.io&#x2F;PassForgePro</a>

Found: January 21, 2026 ID: 3077

[Other] Open source server code for the BitCraft MMORPG

Found: January 21, 2026 ID: 3078

[Other] PicoPCMCIA – a PCMCIA development board for retro-computing enthusiasts

Found: January 21, 2026 ID: 3076

[Database] Show HN: S2-lite, an open source Stream Store S2 was on HN for our intro blog post a year ago (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42480105">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42480105</a>). S2 started out as a serverless API — think S3, but for streams.<p>The idea of streams as a cloud storage primitive resonated with a lot of folks, but not having an open source option was a sticking point for adoption – especially from projects that were themselves open source! So we decided to build it: <a href="https:&#x2F;&#x2F;github.com&#x2F;s2-streamstore&#x2F;s2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;s2-streamstore&#x2F;s2</a><p>s2-lite is MIT-licensed, written in Rust, and uses SlateDB (<a href="https:&#x2F;&#x2F;slatedb.io" rel="nofollow">https:&#x2F;&#x2F;slatedb.io</a>) as its storage engine. SlateDB is an embedded LSM-style key-value database on top of object storage, which made it a great match for delivering the same durability guarantees as s2.dev.<p>You can specify a bucket and path to run against an object store like AWS S3 — or skip to run entirely in-memory. (This also makes it a great emulator for dev&#x2F;test environments).<p>Why not just open up the backend of our cloud service? s2.dev has a decoupled architecture with multiple components running in Kubernetes, including our own K8S operator – we made tradeoffs that optimize for operation of a thoroughly multi-tenant cloud infra SaaS. With s2-lite, our goal was to ship something dead simple to operate. There is a lot of shared code between the two that now lives in the OSS repo.<p>A few features remain (notably deletion of resources and records), but s2-lite is substantially ready. Try the Quickstart in the README to stream Star Wars using the s2 CLI!<p>The key difference between S2 vs a Kafka or Redis Streams: supporting tons of durable streams. I have blogged about the landscape in the context of agent sessions (<a href="https:&#x2F;&#x2F;s2.dev&#x2F;blog&#x2F;agent-sessions#landscape">https:&#x2F;&#x2F;s2.dev&#x2F;blog&#x2F;agent-sessions#landscape</a>). Kafka and NATS Jetstream treat streams as provisioned resources, and the protocols&#x2F;implementations are oriented around such assumptions. Redis Streams and NATS allow for larger numbers of streams, but without proper durability.<p>The cloud service is completely elastic, but you can also get pretty far with lite despite it being a single-node binary that needs to be scaled vertically. Streams in lite are &quot;just keys&quot; in SlateDB, and cloud object storage is bottomless – although of course there is metadata overhead.<p>One thing I am excited to improve in s2-lite is pipelining of writes for performance (already supported behind a knob, but needs upstream interface changes for safety). It&#x27;s a technique we use extensively in s2.dev. Essentially when you are dealing with high latencies like S3, you want to keep data flowing throughout the pipe between client and storage, rather than go lock-step where you first wait for an acknowledgment and then issue another write. This is why S2 has a session protocol over HTTP&#x2F;2, in addition to stateless REST.<p>You can test throughput&#x2F;latency for lite yourself using the `s2 bench` CLI command. The main factors are: your network quality to the storage bucket region, the latency characteristics of the remote store, SlateDB&#x27;s flush interval (`SL8_FLUSH_INTERVAL=..ms`), and whether pipelining is enabled (`S2LITE_PIPELINE=true` to taste the future).<p>I&#x27;ll be here to get thoughts and feedback, and answer any questions!

Found: January 21, 2026 ID: 3091

[API/SDK] Show HN: SpeechOS – Wispr Flow-inspired voice input for any web app Hi Hacker News! I’m David Huie. I’m launching SpeechOS, a drop-in voice input SDK for web apps.<p>I was inspired by Wispr Flow and wanted the same workflow inside business apps (CRMs, docs, forms, support tools), not just a standalone tool. It’s saved me a massive amount of time vs typing.<p>How it works: add a couple lines of JS plus an API key, and SpeechOS shows a small mic widget on every text field.<p>Live demo: <a href="https:&#x2F;&#x2F;www.speechos.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.speechos.ai&#x2F;</a><p>(Click a text box and the mic widget appears; click the gear icon to see settings, custom vocabulary, and snippet configuration.)<p>Users can:<p>- Dictate: speak naturally, real-time voice to polished text (punctuation, no filler&#x2F;typos)<p>- Edit: say “make it shorter”, “fix grammar”, “translate...”<p>- Command: define Siri-style app actions (for example, “submit form”, “mark complete”), and we match intent to your commands<p>It also supports:<p>- Custom vocabulary: domain terms and names (product names, acronyms, jargon) so they transcribe correctly<p>- Text snippets: saved reusable blocks of text you can insert by voice (for example, “my signature”, “disclaimer”, “my address”)<p>Why: text entry speed and accuracy still matter for productivity tools. A large-scale text entry dataset with 37,370 participants showed an average typing speed of 36.2 WPM and ~2.3% uncorrected errors. In speech research, speech recognition was about 3× faster than keyboard input and had ~20.4% lower error rate for English text entry. (<a href="https:&#x2F;&#x2F;hci.stanford.edu&#x2F;research&#x2F;speech&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hci.stanford.edu&#x2F;research&#x2F;speech&#x2F;</a>)<p>SpeechOS is currently in beta and free for now. Sign up at <a href="https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;" rel="nofollow">https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;</a> and enter this HN-only beta code: HN-JFc74cVC (please don’t share outside HN).<p>Links:<p>SDK repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;speechos-org&#x2F;speechos-client" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;speechos-org&#x2F;speechos-client</a><p>Demo: <a href="https:&#x2F;&#x2F;www.speechos.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.speechos.ai&#x2F;</a><p>Signup (code: HN-JFc74cVC): <a href="https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;" rel="nofollow">https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;</a><p>I’d love feedback on:<p>1) Where this is most valuable in your stack (notes? docs? CRM entry? support macros?)<p>2) What you’d want from voice commands&#x2F;snippets configuration<p>3) What would make you comfortable shipping this (privacy&#x2F;security, latency, pricing)<p>If you’re building anything in voice AI&#x2F;dictation, I’d be happy to swap notes (david@speechos.ai).

Found: January 21, 2026 ID: 3082

[Other] Show HN: See the carbon impact of your cloud as you code Hey folks, I’m Hassan, one of the co-founders of Infracost (<a href="https:&#x2F;&#x2F;www.infracost.io">https:&#x2F;&#x2F;www.infracost.io</a>). Infracost helps engineers see and reduce the cloud cost of each infrastructure change before they merge their code. The way Infracost works is we gather pricing data from Amazon Web Services, Microsoft Azure and Google Cloud. What we call a ‘Pricing Service’, which now holds around 9 million live price points (!!). Then we map these prices to infrastructure code. Once the mapping is done, it enables us to show the cost impact of a code change before it is merged, directly in GitHub, GitLab etc. Kind of like a checkout-screen for cloud infrastructure.<p>We’ve been building since 2020 (we were part of YC W21 batch), and iterating on the product, building out a team etc. However, back in 2020 one of our users asked if we can also show the carbon impact alongside costs.<p>It has been itching my brain since then. The biggest challenge has always been the carbon data. The mapping of carbon data to infrastructure is time consuming, but it is possible since we’ve done it with cloud costs. But we need the raw carbon data first. The discussions that have happened in the last few years finally led me to a company called Greenpixie in the UK. A few of our existing customers were using them already, so I immediately connected with the founder, John.<p>Greenpixie said they have the data (AHA!!) And their data is verified (ISO-14064 &amp; aligned with the Greenhouse Gas Protocol). As soon as I talked to a few of their customers, I asked my team to see if we can actually finally do this, and build it.<p>My thinking is this: some engineers will care, and some will not (or maybe some will love it and some will hate it!). For those who care, cost and carbon are actually linked; meaning if you reduce the carbon, you usually reduce the cost of the cloud too. It can act as another motivation factor.<p>And now, it is here, and I’d love your feedback. Try it out by going to <a href="https:&#x2F;&#x2F;dashboard.infracost.io&#x2F;">https:&#x2F;&#x2F;dashboard.infracost.io&#x2F;</a>, create an account, set up with the GitHub app or GitLab app, and send a pull request with Terraform changes (you can use our example terraform file). It will then show you the cost impact alongside the carbon impact, and how you can optimize it.<p>I’d especially love to hear your feedback on if you think carbon is a big driver for engineers within your teams, or if carbon is a big driver for your company (i.e. is there anything top-down about carbon).<p>AMA - I’ll be monitoring the thread :)<p>Thanks

Found: January 21, 2026 ID: 3074

[Other] A verification layer for browser agents: Amazon case study A common approach to automating Amazon shopping or similar complex websites is to reach for large cloud models (often vision-capable). I wanted to test a contradiction: can a ~3B parameter local LLM model complete the flow using only structural page data (DOM) plus deterministic assertions?<p>This post summarizes four runs of the same task (search → first product → add to cart → checkout on Amazon). The key comparison is Demo 0 (cloud baseline) vs Demo 3 (local autonomy); Demos 1–2 are intermediate controls.<p>More technical detail (architecture, code excerpts, additional log snippets):<p><a href="https:&#x2F;&#x2F;www.sentienceapi.com&#x2F;blog&#x2F;verification-layer-amazon-case-study" rel="nofollow">https:&#x2F;&#x2F;www.sentienceapi.com&#x2F;blog&#x2F;verification-layer-amazon-...</a><p>Demo 0 vs Demo 3:<p>Demo 0 (cloud, GLM‑4.6 + structured snapshots) success: 1&#x2F;1 run tokens: 19,956 (~43% reduction vs ~35k estimate) time: ~60,000ms cost: cloud API (varies) vision: not required<p>Demo 3 (local, DeepSeek R1 planner + Qwen ~3B executor) success: 7&#x2F;7 steps (re-run) tokens: 11,114 time: 405,740ms cost: $0.00 incremental (local inference) vision: not required<p>Latency note: the local stack is slower end-to-end here largely because inference runs on local hardware (Mac Studio with M4); the cloud baseline benefits from hosted inference, but has per-token API cost.<p>Architecture<p>This worked because we changed the control plane and added a verification loop.<p>1) Constrain what the model sees (DOM pruning). We don’t feed the entire DOM or screenshots. We collect raw elements, then run a WASM pass to produce a compact “semantic snapshot” (roles&#x2F;text&#x2F;geometry) and prune the rest (often on the order of ~95% of nodes).<p>2) Split reasoning from acting (planner vs executor).<p>Planner (reasoning): DeepSeek R1 (local) generates step intent + what must be true afterward. Executor (action): Qwen ~3B (local) selects concrete DOM actions like CLICK(id) &#x2F; TYPE(text). 3) Gate every step with Jest‑style verification. After each action, we assert state changes (URL changed, element exists&#x2F;doesn’t exist, modal&#x2F;drawer appeared). If a required assertion fails, the step fails with artifacts and bounded retries.<p>Minimal shape:<p>ok = await runtime.check( exists(&quot;role=textbox&quot;), label=&quot;search_box_visible&quot;, required=True, ).eventually(timeout_s=10.0, poll_s=0.25, max_snapshot_attempts=3)<p>What changed between “agents that look smart” and agents that work Two examples from the logs:<p>Deterministic override to enforce “first result” intent: “Executor decision … [override] first_product_link -&gt; CLICK(1022)”<p>Drawer handling that verifies and forces the correct branch: “result: PASS | add_to_cart_verified_after_drawer”<p>The important point is that these are not post‑hoc analytics. They are inline gates: the system either proves it made progress or it stops and recovers.<p>Takeaway If you’re trying to make browser agents reliable, the highest‑leverage move isn’t a bigger model. It’s constraining the state space and making success&#x2F;failure explicit with per-step assertions.<p>Reliability in agents comes from verification (assertions on structured snapshots), not just scaling model size.

Found: January 21, 2026 ID: 3081

[Other] Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps) Creator here. I built ChartGPU because I kept hitting the same wall: charting libraries that claim to be &quot;fast&quot; but choke past 100K data points.<p>The core insight: Canvas2D is fundamentally CPU-bound. Even WebGL chart libraries still do most computation on the CPU. So I moved everything to the GPU via WebGPU:<p>- LTTB downsampling runs as a compute shader - Hit-testing for tooltips&#x2F;hover is GPU-accelerated - Rendering uses instanced draws (one draw call per series)<p>The result: 1M points at 60fps with smooth zoom&#x2F;pan.<p>Live demo: <a href="https:&#x2F;&#x2F;chartgpu.github.io&#x2F;ChartGPU&#x2F;examples&#x2F;million-points&#x2F;" rel="nofollow">https:&#x2F;&#x2F;chartgpu.github.io&#x2F;ChartGPU&#x2F;examples&#x2F;million-points&#x2F;</a><p>Currently supports line, area, bar, scatter, pie, and candlestick charts. MIT licensed, available on npm: `npm install chartgpu`<p>Happy to answer questions about WebGPU internals or architecture decisions.

Found: January 21, 2026 ID: 3072

[API/SDK] Show HN: UltraContext – A simple context API for AI agents with auto-versioning Hey HN! I&#x27;m Fabio and I built UltraContext, a simple context API for AI agents with automatic versioning.<p>After two years building AI agents in production, I experienced firsthand how frustrating it is to manage context at scale. Storing messages, iterating system prompts, debugging behavior and multi-agent patterns—all while keeping track of everything without breaking anything. It was driving me insane.<p>So I built UltraContext. The mental model is git for context:<p>- Updates and deletes automatically create versions (history is never lost)<p>- Replay state at any point<p>The API is 5 methods:<p><pre><code> uc.create() &#x2F;&#x2F; new context (can fork from existing) uc.append() &#x2F;&#x2F; add message uc.get() &#x2F;&#x2F; retrieve by version, timestamp, or index uc.update() &#x2F;&#x2F; edit message → creates version uc.delete() &#x2F;&#x2F; remove message → creates version </code></pre> Messages are schema-free. Store conversation history, tool calls, system prompts—whatever shape you need. Pass it straight to your LLM using any framework you&#x27;d like.<p>What it&#x27;s for:<p>- Persisting conversation state across sessions<p>- Debugging agent behavior (rewind to decision point)<p>- Forking contexts to test different flows<p>- Audit trails without building audit infrastructure<p>- Multi-agent and sub-agent patterns<p>What it&#x27;s NOT:<p>- Not a memory&#x2F;RAG system (no semantic search)<p>- Not a vector database<p>- Not an Orchestration&#x2F;LLM framework<p>UltraContext handles versioning, branching, history. You get time-travel with one line.<p>Docs: <a href="https:&#x2F;&#x2F;ultracontext.ai&#x2F;docs" rel="nofollow">https:&#x2F;&#x2F;ultracontext.ai&#x2F;docs</a><p>Early access: <a href="https:&#x2F;&#x2F;ultracontext.ai" rel="nofollow">https:&#x2F;&#x2F;ultracontext.ai</a><p>Would love feedback! Especially from anyone who&#x27;s rolled their own context engineering and can tell me what I&#x27;m missing.

Found: January 21, 2026 ID: 3080

Nested Code Fences in Markdown

Hacker News (score: 75)

[Other] Nested Code Fences in Markdown

Found: January 21, 2026 ID: 3073

[Other] Show HN: Generate animated solar system timelapse videos for any date range A fork of Solar System Live that generates animated videos showing planetary orbits over any date range. Tracks orbital statistics (how many times Earth was lapped by Mercury&#x2F;Venus, or lapped outer planets) and overlays dates&#x2F;ages on each frame.<p>Example: Einstein&#x27;s lifetime (1879-1955) showing 76 years of solar system evolution. Built with Python + Pillow + ffmpeg, runs locally with Lighttpd.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;simondorfman&#x2F;solar_system_live" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;simondorfman&#x2F;solar_system_live</a>

Found: January 21, 2026 ID: 3075

[Other] Show HN: macOS native DAW with Git branching model I am working on building (and have made my first prerelease) for a Digital Audio Workstation with git like branching version control.<p>It&#x27;s free for local use and paid for cloud syncing or collaboration.

Found: January 21, 2026 ID: 3069

[Other] Claude Chill: Fix Claude Code's flickering in terminal

Found: January 20, 2026 ID: 3067

[CLI Tool] Show HN: Fence – Sandbox CLI commands with network/filesystem restrictions Hi HN!<p>Fence wraps any command in a sandbox that blocks network by default and restricts filesystem writes. Useful for running semi-trusted code (package installs, build scripts, unfamiliar repos) with controlled side effects, or even just blocking tools that phone home.<p>&gt; fence curl <a href="https:&#x2F;&#x2F;example.com" rel="nofollow">https:&#x2F;&#x2F;example.com</a> # -&gt; blocked<p>&gt; fence -t code -- npm install # -&gt; template with registries allowed<p>&gt; fence -m -- npm install # -&gt; monitor mode: see what gets blocked<p>One use-case is to use it with AI coding agents to reduce the risk of running agents with fewer interactive permission prompts:<p>&gt; fence -t code -- claude --dangerously-skip-permissions<p>You can import existing Claude Code permissions with `fence import --claude`.<p>Fence uses OS-native sandboxing (macOS sandbox-exec, Linux bubblewrap) + local HTTP&#x2F;SOCKS proxies for domain filtering.<p>Why I built this: I work on Tusk Drift, a system to record and replay real traffic as API tests (<a href="https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;tusk-drift-cli" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;tusk-drift-cli</a>). I needed a way to sandbox the service under test during replays to block localhost outbound connections (Postgres, Redis) and force the app to use mocks instead of real services. I quickly realized that this could be a general purpose tool that would also be useful as a permission manager across CLI agents.<p>Limitations: Not strong containment against malware. Proxy-based filtering requires programs to respect `HTTP_PROXY`.<p>Curious if others have run into similar needs, and happy to answer any questions!

Found: January 20, 2026 ID: 3065

[API/SDK] Show HN: Mastra 1.0, open-source JavaScript agent framework from the Gatsby devs Hi HN, we&#x27;re Sam, Shane, and Abhi.<p>Almost a year ago, we first shared Mastra here (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43103073">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43103073</a>). It’s kind of fun looking back since we were only a few months into building at the time. The HN community gave a lot of enthusiasm and some helpful feedback.<p>Today, we released Mastra 1.0 in stable, so we wanted to come back and talk about what’s changed.<p>If you’re new to Mastra, it&#x27;s an open-source TypeScript agent framework that also lets you create multi-agent workflows, run evals, inspect in a local studio, and emit observability.<p>Since our last post, Mastra has grown to over 300k weekly npm downloads and 19.4k GitHub stars. It’s now Apache 2.0 licensed and runs in prod at companies like Replit, PayPal, and Sanity.<p>Agent development is changing quickly, so we’ve added a lot since February:<p>- Native model routing: You can access 600+ models from 40+ providers by specifying a model string (e.g., `openai&#x2F;gpt-5.2-codex`) with TS autocomplete and fallbacks. - Guardrails: Low-latency input and output processors for prompt injection detection, PII redaction, and content moderation. The tricky thing here was the low-latency part. - Scorers: An async eval primitive for grading agent outputs. Users were asking how they should do evals. We wanted to make it easy to attach to Mastra agents, runnable in Mastra studio, and save results in Mastra storage. - Plus a few other features like AI tracing (per-call costing for Langfuse, Braintrust, etc), memory processors, a `.network()` method that turns any agent into a routing agent, and server adapters to integrate Mastra within an existing Express&#x2F;Hono server.<p>(That last one took a bit of time, we went down the ESM&#x2F;CJS bundling rabbithole, ran into lots of monorepo issues, and ultimately opted for a more explicit approach.)<p>Anyway, we&#x27;d love for you to try Mastra out and let us know what you think. You can get started with `npm create mastra@latest`.<p>We&#x27;ll be around and happy to answer any questions!

Found: January 20, 2026 ID: 3063

[API/SDK] Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

Found: January 20, 2026 ID: 3061

[Other] Workspaces and Monorepos in Package Managers

Found: January 20, 2026 ID: 3096
Previous Page 50 of 125 Next