Hacker News

When I work on hobby projects, I usually use React or Next.js because they are quick to set up and easy to deploy on Vercel. For production apps, I separate the frontend and backend, then deploy the backend on AWS. But setting up a full backend on AWS can be complex and costly, especially for simple apps.

Pylon is a full-stack, real-time framework that includes server-rendered React, TypeScript functions, entities, policies, real-time sync, built-in authentication, and support for background and scheduled jobs. By default, it uses SQLite, but you can switch to Postgres for production. The authentication system is heavily inspired by better-auth. The runtime is a Rust server that runs TypeScript functions and server-rendered React using Bun.

Pylon itself is inspired by Rails and focuses on convention over configuration, so you have fewer decisions to make before deploying. This approach applies to modern React apps, real-time sync, TypeScript server functions, authentication, job management, and deployment.

One of Pylon’s main goals is agent compatibility. It lets coding agents build and deploy apps with no setup, quick understanding, secure defaults, and easy deployment, all without requiring any third-party services. Pylon works for both quick projects and production apps where performance, observability, ownership, and self-hosting matter.

While it’s easy to self-host Pylon apps, Pylon Cloud provides managed hosting with a developer experience similar to Vercel. You can deploy from git or the CLI, get an instant URL, add custom domains, and go live in seconds. Each app runs on its own server, which can scale to zero, with TLS and global caching enabled.

If you have experience with Next.js, Vercel, Convex, Supabase, Firebase, better-auth, or Rails, I’d love to hear your feedback.

Create your first app: npm create @pylonsync/pylon@latest

Website: https://www.pylonsync.com

Repo: https://github.com/pylonsync/pylon

Docs: https://docs.pylonsync.com/introduction

LLMS: https://docs.pylonsync.com/llms.txt

Skill: npx skills add pylonsync/pylon

Examples: https://github.com/pylonsync/pylon/tree/main/examples

https://deploymentsafety.openai.com/gpt-5-6/gpt-5-6.pdf

https://developers.openai.com/api/docs/guides/latest-model

https://x.com/levie/status/2075287443411222628, https://xcancel.com/levie/status/2075287443411222628

https://www.context.dev/) to make it really easy to integrate web data into your products and agents.

Here’s a demo video: https://www.tella.tv/video/build-faster-with-context-dev-api...

Since it’s an API, here are the docs: https://docs.context.dev/quickstart.

You can send us a URL and get back clean Markdown, rendered HTML, screenshots, extracted images, etc.. You can also send us a domain and get company or brand context: name, description, logos, colors, fonts, social links, screenshots, style information, and related metadata. For more custom use cases, you can send a URL plus a JSON Schema and ask us to extract structured data from the site into that shape. For example, you might ask for pricing plans, product categories, office locations, support links, integration partners, or anything else that is visible on the public site.

The goal is to give developers the output they actually want. Raw HTML is rarely the useful thing; the useful thing is usually Markdown for a model, JSON for an application, a logo for a UI, or a structured company profile for an agent.

Before, I worked at Amazon and Sunrun, and co-founded StockAlarm.io & essense.io, both of which were acquired. Also, I built knifegeek.io, which scraped pocket knives from across the internet and listed them easily. The project is outdated now (coming back soon) but back then it hit the frontpage of hacker news and people seemed to like it: https://news.ycombinator.com/item?id=34604281.

Just before Context.dev, I built Brand.dev. The idea was that your software product should automatically know about your customer if they sign up with a corporate email. The API pulled brand data such as logos, backdrops, name, description, industry, and more from the public web and surfaced it to your product to integrate as part of their onboarding experience. That’s worth doing because conversion rates on onboarding improve dramatically when you go from “enter all this info” to “confirm all this info” (and there was never any privacy concern all the information is public).

That was a nifty niche, but the more customers used it, it became obvious that “brand data” was only one slice of a larger need. People started asking for things like screenshots, structured extraction, and LLM ready data. So I expanded to Context.dev, and applied to YC (got rejected after an interview), then kept going and re-applied at which point I got in as a solo founder.

People use Context.dev in more ways than I can list, but here are some: keeping context up to date on customer websites for chatbots - building beautiful brand assets/ads for customers - enrichment flows using agent harnesses like eve.dev - crawling customer websites into chatbot knowledge bases - turning GitHub repos into branded docs sites - academic journal and PDF crawling. There are a ton more examples at https://www.context.dev/customers.

We know that many crawlers are not behaving like good citizens on the web, and the entire space has a bad reputation as a result. At the same time, customers are not usually trying to buy “scraping”. They are trying to make a support bot work, personalize onboarding, enrich CRM records, generate docs, monitor leads, or let an agent research a company. There are lots of legit use cases. We want to satisfy those while being respectful of everyone involved.

We maintain a caching layer and avoid hammering websites. Customers can configure the cache, but if we find we’re sending too many requests to a url in a certain amount of time, we step in and tone it down. Websites can opt out of our service, and we respect these requests and add them to our block list.

We focus on customers who want to build cool things for their users. Enriching onboarding is a popular use case. So is integrating context about their own websites (things like support bots), and building agents that can automatically reason about complex tasks involving the internet.

We only allow customers to use brand data to identify a specific customer on their software, you cannot use it in your own materials or to imply endorsement.

I'd love to hear your feedback about the product in the comments, thanks!

https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio... [pdf]

https://developer.meta.com/ai/resources/blog/build-with-muse...

https://www.bloomberg.com/news/articles/2026-07-09/meta-star..., https://archive.is/3ccKa

But then I thought, "I wonder how it would work on a normal computer like mine," and above all, "I wonder if it would work without going into OOM on a computer like mine." So I started working with the help of agents to test this possibility.

I started converting the model to int4, understanding MTP usage, and if possible implementing DSA for long context. How it responds in int4 and whether the quality is maintained or not. Until I got to the point, on my computer with 32GB of RAM, I was able to communicate with GLM 5.2 with times that, of course, aren't high in cold start, but even then, we're talking about 0.1 tok/s, but that wasn't important to me. The important thing was the journey to reach this goal. I just wanted it to work at all costs, even slowly.

So I created Colibrì, which was born from a very simple idea, to be honest, but tested in every way, where a 744B Mixture-of-Experts model activates only ~40B parameters per token—and only ~11 GB of those change from token to token (the routed experts). So:

The dense part (attention, shared experts, embeddings—~17B params) stays resident in RAM at int4 (~9.9 GB); The 21,504 routed experts (75 MoE layers × 256 experts + the MTP head, ~19 MB each at int4) live on disk (~370 GB) and are streamed on demand, with a per-layer LRU cache, an optional pinned hot-store, and the OS page cache as a free L2.

The engine is a single C file (c/glm.c, ~1,300 lines) plus small headers. No BLAS, no Python at runtime, no GPU.No GPU or serious hardware because I don't have that hardware so I can't test it on hardware that is more powerful than my computer.Colibrì is a one-person project, written and tested entirely on a 12-core laptop with 25 GB of RAM — the numbers above are the ceiling of what I can measure at home.

Any feedback is welcome! (and if anyone wanted to participate in the project I would be delighted)

Repo: https://github.com/JustVugg/colibri

It started as a project just for papers on arXiv, but after its initial success on Twitter (got like 1.9k views: the most I have gotten for a post), I have now expanded it to include other openly available papers from PubMed Central, bioRxiv, medRxiv, and eLife. These papers have been linked with their genes, proteins, diseases, drugs, clinical trials, 3D protein structures, code, and cited and similar papers.

This project now has four parts:

First, a map. I embedded nearly 8.5M papers (with SPECTER2), ran UMAP for 2D representation, and rendered them as a scatterplot. The dots can be clicked to see brief information about the papers, like an LLM TLDR, key findings, peer reviews, linked entities, and more. The clusters are also labeled, though you might have to zoom in.

Second, I built a detailed paper page for each paper. They give you the paper's full text, images, videos, peer reviews (from OpenReview), GitHub links, Hugging Face dataset/model links, clinical trials, genes, diseases, 3D protein structures, cited papers, and similar papers. You can also copy the whole page, including the full paper text and image URLs, as markdown for your LLM.

Third, I have released an extension so you can read all this information in your sidebar by clicking "open in Tomesphere" that shows up in arXiv, PMC, bioRxiv, Google Scholar, or medRxiv. I have tried to provide as much information as possible in the extension, though for things like viewing all the images or a 3D protein structure, you might still have to go to the paper page using the link provided in the extension.

Fourth, all this data is available for your LLM via MCP. The MCP does have a 50-query free limit (this jumps 10x with signup).

Note: this project is still in beta, so papers might have some mismatched information. I am rolling out feedback forms soon to improve the data quality. Thank you so much for taking the time to read this.

I've been using Claude Code for almost everything lately. Have given one an email account so it can research business leads, draft emails, fact-check them and clear them with me before sending (works really well by the way). I also tend to have a few Claude Code agents running at any one time for coding.

I used to create a split terminal to manage them from there, but found working in the terminal all day pretty depressing and, more importantly, found it hard to follow Claude Code's process and see which agents needed my immediate attention.

I tried Anthropic's VS Code Claude Code extension and it had a great UI (more info on Claude Code's process and easier to read), but it crashed my PC when I ran more than 3 and I couldn't watch multiple agents in parallel (had to constantly switch between them).

So I built a lightweight Tauri desktop app which lets you run multiple Claude Code agents in one window alongside each other. It's easier to read the output and see which agents need your attention than a terminal.

Have been using this all day everyday instead of an IDE and have obsessed over every detail to make sure it's easy-to-use, but also lightweight and fast (so you can manage multiple agents without your PC crashing).

There are some nice features like better usage alerts for when you're going to hit your 5-hour and weekly limits (with sparklines to show when usage peaked, and which agents are the most token-intensive).

It's free to use (you just need to log in with your existing Claude Code account) for up to 4 agents simultaneously. This app doesn't store your Claude Code account details and doesn't store any of your interactions with Claude Code. They remain between you and Anthropic. It's compatible with Windows, MacOS and 64-bit Linux.

Would really appreciate any feedback, so if you have any thoughts, issues or suggestions please let me know.

Thanks, Chris

https://archive.is/LV6Cw