Golf Forem

What's New At Releem - WHM/cPanel integration is available

Roman Agabekov — Thu, 30 Apr 2026 22:00:13 +0000

We spent March focused on expanding query optimization, building out partner integrations, continuing PostgreSQL testing, and improve the overall experience for hosting providers and teams using Releem.

We also had the chance to connect with the hosting community at CloudFest. There, we met with hosting providers interested in partnering with Releem to offer Database Advisor to their customers. I gave a talk on Database Advisor for teams running databases without a DBA.

Gabriel presented a deep technical session at Scale23X titled The Hidden Lives of Temp Tables: Unraveling MySQL Internal Management.

Community Contributions

We're always collecting issues and feature requests on our GitHub. Here's where you can contribute:

Issues – If you encounter any problems or bugs, report them here.

Feature Requests – Have an idea to make Releem even better? Share your suggestions here.

Product Updates

Batch SQL query analysis and recommendations

You can now see recommendations for all queries directly in Query Analytics without any additional clicks, and save them to the Query Optimization tab for further review and optimization.

If no issues are found, the result shows that the query was analyzed along with the timestamp of the latest check, so you can clearly see what was reviewed and when.

Releem continues to automatically identify the most impactful queries based on workload and adds them as discovered opportunities in the Query Optimization tab.

Custom SQL query optimization

You can now analyze and get recommendations for your own SQL queries, not just the ones Releem detects automatically. Developers can review and optimize queries before they reach production. In Queries & Schema plate go to Query Optimization tab and press + Add Custom Query

WHM/cPanel integration

Releem also integrates with WHM/cPanel, simplifying the installation process and providing access to the Releem dashboard directly from WHM. During installation, Releem disables cPanel auto-tuning rules to ensure compatibility.

Learn more in the documentation.

API and WHMCS integration for hosting partners

We released an API for hosting partners, enabling programmatic integration of Releem into hosting platforms and making it possible to offer Database Advisor to VPS, dedicated, and cloud server customers.

Releem also integrates with WHMCS, allowing providers to sell and manage Database Advisor as an add-on through their existing billing workflows.

Get the partner deck to learn more about integration and partnership options.

AWS Aurora Serverless support

We added support for AWS Aurora Serverless, bringing Releem’s performance analysis and recommendations to these environments (Feature request #477).
The installation process is the same as for AWS RDS.

Deadlock export to CSV

Detected deadlocks can now be exported to CSV for external analysis and reporting (Feature request #503).

Improved data collection performance

We fixed an issue in how Releem queried table_io_waits_summary_by_index_usage reducing unnecessary full table scans on servers with many databases (Issue #500).

Uninstallation dependency fix

The agent no longer downloads unnecessary dependencies during uninstallation (Issue #466).

Duplicate index detection improvement

We improved duplicate index analysis to account for foreign key-backed indexes, helping prevent unsafe recommendations during index optimization (Issue #478).

Expanded query parser support

Releem now supports optimization for queries that start with '(' instead of 'SELECT' (Issue #427).

Offline agent apply-task fix

We fixed an issue that allowed configuration apply tasks to be scheduled while the agent was offline (Issue #311).

Virtualizing SteamOS with QEMU/KVM: The Steps Nobody Tells You

Abdullah Musa — Thu, 30 Apr 2026 21:43:20 +0000

SteamOS is not a standard Linux distribution. It ships as a recovery image for the Steam Deck, not a generic ISO. That fact explains every strange requirement you face when you try to run it in a virtual machine. The file you download is a .bz2 archive, not an installer. The VM must present the virtual drive as NVMe. And if you let the system reboot right after installation it will launch into Gaming Mode, which cannot work without the Deck's custom AMD GPU.

I have a full in-depth walkthrough on my blog. This post gives you the reasoning and the exact commands to get a working VM, plus the one intervention that saves you from a permanent black screen.

The .bz2 Archive Hides a Raw Disk Image

Head to Valve's official SteamOS page and you get a steamOS-recovery-image.bz2 file. Decompress it with:

tar -xjf steamOS-recovery-image.bz2

Inside you'll find a .img file. It's a raw block-level copy of a full SteamOS installation, not a live environment. It contains a GPT partition table, the bootloader, and the A/B root partitions used for atomic updates. Valve compresses it with BZIP2 to keep the download small. That's fair.

Why You Must Use an NVMe Virtual Drive

The Steam Deck uses an NVMe SSD. The recovery image's installer scripts look for a block device at /dev/nvme0n1. If you attach the virtual disk as a SATA or IDE drive, the kernel sees /dev/sda and the installer will say no valid target is found. It's not a bug. It's what the script expects.
In QEMU you emulate an NVMe controller. First create a virtual disk:

qemu-img create -f qcow2 steamOSDrive.qcow2 16G

Then map it in the launch command. The crucial flags are:

-drive if=none,id=nvme0,file=steamOSDrive.qcow2
-device nvme,drive=nvme0,serial=badbeef

The serial number is required and can be any string. The moment the recovery environment sees an NVMe namespace, the install option lights up.

UEFI Firmware Is Not Optional

SteamOS boots via UEFI with a GPT partition layout. Legacy BIOS won't work. QEMU provides UEFI through the OVMF firmware. You need two files:

OVMF_CODE.fd (read-only firmware code)
OVMF_VARS.fd (persistent NVRAM for boot variables)

On most distros these live in /usr/share/ovmf/x64/. Pass them as pflash drives:

-drive if=pflash,format=raw,unit=0,file=OVMF.fd,readonly=on
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd

Without these, the VM tries BIOS mode, finds nothing on a GPT disk, and halts.

The Full Installation Command

With all pieces in place, the complete QEMU command for the installation phase looks like this:

qemu-system-x86_64 \
  -cpu host -enable-kvm -smp 2 -m 8G \
  -drive if=pflash,format=raw,unit=0,file=OVMF.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
  -drive file=SteamOS.img,format=raw \
  -drive if=none,id=nvme0,file=steamOSDrive.qcow2 \
  -device nvme,drive=nvme0,serial=badbeef \
  -display "gtk,gl=on" \
  -device usb-tablet -usb

It boots the recovery image with the empty NVMe drive ready. Inside the VM, open the Wipe Devices & Install SteamOS option and click Proceed. The installer will write the A/B partitions to your virtual NVMe.

The Gaming Mode Trap (Cancel the Reboot)

Once the installation finishes, the wizard asks you to restart. If you click Proceed, SteamOS boots into Gaming Mode, which expects AMD GPU hardware. Inside a VM you get nothing but a black screen.

Do not reboot. Instead, press Ctrl + Alt + T inside the VM to open a terminal. From there you force SteamOS to boot into the KDE Plasma desktop. Run these chroot commands on both partition sets:

sudo steamos-chroot --disk nvme0n1 --partset A --no-overlay
steamos-readonly disable
echo '[Autologin]' > /etc/sddm.conf.d/zz-steamos-autologin.conf
echo 'Session=plasma.desktop' >> /etc/sddm.conf.d/zz-steamos-autologin.conf
steamos-readonly enable
exit

Repeat the same block for --partset B. Then type reboot. The VM will now start directly into a working KDE Plasma session.

Why All This Matters

SteamOS is a locked-down appliance OS built for one device. Running it in a VM reveals the assumptions baked into the installer and teaches you a lot about how Valve's immutable filesystem and A/B update scheme work. And once you have a working desktop session, you can use it almost like any Arch-based system.

For a deeper dive that covers additional configuration, GPU passthrough notes, and troubleshooting, check out the full original guide on MusaBase:

How to Virtualize SteamOS: Test Its Power Within QEMU/KVM (2026 Updated)

That's it. No magic, just an OS that wants to be on real Deck hardware. With a few QEMU tricks, you can convince it to run anyway.

How I built the fastest color manipulation library in TypeScript and the optimization techniques I learned

Dmitry Kryaklin — Thu, 30 Apr 2026 21:40:00 +0000

Introduction

In 2025, I started building a color manipulation library called colordx. The frontend ecosystem is moving towards CSS Color 4: OKLCH, OKLab, Display-P3, Rec.2020. Most existing libraries were designed for the sRGB era and bolted modern color spaces on top. I wanted to build something that treats the modern stuff as a first-class citizen.

But the goal I cared about most was performance. Not just "faster than colord" fast. I wanted colordx to be the fastest option in the benchmarks I cared about, and I wanted to actually understand why.

This article is a short list of the optimization techniques that mattered the most. If you are working on a hot-path JavaScript library, I hope at least a few of these are useful.

Results first

Benchmark	colordx	colord	culori	chroma-js	color
Parse HEX → toHsl	38 ns	99 ns	151 ns	294 ns	382 ns
Parse HEX → lighten → toHex	64 ns	176 ns	206 ns	850 ns	1010 ns
Mix two colors	102 ns	759 ns	1230 ns	870 ns	1900 ns
Parse HEX → toOklch	271 ns	—	287 ns	916 ns	534 ns
inGamutP3	202 ns	—	1030 ns	—	—

Now let's get into how.

1. Keep one canonical internal representation

Every Colordx instance stores exactly one thing: an RgbColor object { r, g, b, a }. All conversions go through it.

The reason is V8 monomorphism. The class has a fixed shape, so V8 always sees the same two fields on every method call. A library that stores different color models in different instances ends up with polymorphic inline caches everywhere, and JIT performance drops.

2. Don't use Object.create to skip the constructor

This was the single biggest win. My first version used Object.create(Colordx.prototype) in the internal factory to skip parsing:

private static _make(rgb: RgbColor): Colordx {
  const inst = Object.create(Colordx.prototype);
  inst._rgb = rgb;
  inst._valid = true;
  return inst;
}

It looks clean but it is a trap. ES2022 classes with field declarations have a specific V8 hidden class transition chain. Object.create bypasses the constructor, so the field initialization transitions never fire. The resulting instance has a different hidden class than one created with new Colordx(). V8 sees two shapes flowing into every hot method, ICs go polymorphic, performance dies.

Fix: use a sentinel symbol so the constructor can skip parsing while still going through the proper field transition chain.

const _SENTINEL: unique symbol = Symbol();

constructor(input: AnyColor | typeof _SENTINEL, _direct?: RgbColor) {
  if (input === _SENTINEL) {
    this._valid = true;
    this._rgb = _direct!;
  } else { /* parse */ }
}

private static _make(rgb: RgbColor): Colordx {
  return new Colordx(_SENTINEL, rgb);
}

Around 330 ns → 270 ns on Parse HEX → toOklch. Just from how the object is constructed.

3. Precomputed lookup tables for hex output

toString(16).padStart(2, '0') allocates a string every call. Precompute all 256 possibilities:

const HEX_BYTE = /* #__PURE__ */ Array.from(
  { length: 256 },
  (_, i) => i.toString(16).padStart(2, '0')
);

Three array lookups instead of three string allocations. Borrowed from color-bits.

4. Bitwise hex parsing

parseInt('ff', 16) is slow because it is a general-purpose parser. Exploit the ASCII layout to decode a hex character with two integer ops:

const hexNibble = (c: number): number => (c & 0xf) + 9 * (c >> 6);

Based on Lemire's technique.

5. Reuse a module-level buffer when callers always destructure

rgbToHslRaw is the hot path for lighten, darken, saturate, etc. Every call would allocate a fresh { h, s, l, a } object. But all internal callers immediately destructure the result, so there is no aliasing. So I reuse a single object:

const _hslBuf: HslColor = { h: 0, s: 0, l: 0, a: 0 };

export const rgbToHslRaw = (rgb) => {
  // ...
  _hslBuf.h = hDeg;
  _hslBuf.s = clamp(s * 100, 0, 100);
  _hslBuf.l = clamp(l * 100, 0, 100);
  _hslBuf.a = clamp(round(a, 3), 0, 1);
  return _hslBuf;
};

This works only because the function is internal and I control all callers. I would not expose this pattern in a public API.

6. Avoid closure allocation by hoisting helpers to module level

If a helper function is defined inside another function, V8 creates a new closure object on every call. Hoist it to module level and it is allocated once.

// at module level, not inside hslToRgb
const _hueToRgb = (p: number, q: number, t: number): number => { ... };

7. Inline conversions to avoid intermediate object allocation

rgbToOklch used to call rgbToOklab and destructure the result. The intermediate OklabColor object is pure overhead. Inlining the math saves one allocation per call.

I usually hate duplicated code, but for short, well-tested math the allocation savings are real.

8. Provide *Into siblings for per-pixel work

For 500×500 OKLCH gradient renders (250k pixels per frame), the natural API allocates 500k–1M short-lived 3-tuples per frame. Wall-clock cost is modest, but the GC pressure causes frame hitches during interactive drag.

So every channel function has a sibling that writes into a caller-provided buffer:

export const oklabToLinearInto = (
  out: Float64Array | number[],
  l: number, a: number, b: number
): void => { /* writes out[0/1/2] */ };

On a 250k-pixel chained OKLCH→P3 bench, allocations drop from ~9 MB/iter to ~500 kB/iter. Wall-clock is only ~5% better, but interactive renders become visibly smoother.

I rejected the alternative of a shared module-level buffer (slightly faster in micro-bench, around 10%) because it is non-reentrant and a sharp edge in a public API. gl-matrix and three.js use the out-param pattern for the same reason.

9. DRY the data, not the structure

Once I had both oklabToLinear and oklabToLinearInto, the obvious refactor was to make the allocating version delegate to the *Into version. Looks great. Regressed the *Into path by ~20%.

The reason was V8 polymorphism. External callers pass a Float64Array. The new wrapper passes a plain [number, number, number]. The *Into call site went from monomorphic to polymorphic, V8's speculative optimizations got disabled.

The compromise: keep the math duplicated, but extract the matrix coefficients into module-level consts.

const M1_LR = 0.4122214708, M1_LG = 0.5363325363, M1_LB = 0.0514459929;
// ... 20+ named coefficients ...

export const linearSrgbToOklabInto = (out, lr, lg, lb) => {
  const lv = Math.cbrt(M1_LR * lr + M1_LG * lg + M1_LB * lb);
  // ...
};

export const linearSrgbToOklab = (lr, lg, lb) => {
  const lv = Math.cbrt(M1_LR * lr + M1_LG * lg + M1_LB * lb);
  // ...
};

V8 constant-folds module-level consts, so there is no runtime cost vs inline literals. One source of truth for the data, two monomorphic call sites.

The textbook DRY refactor was wrong here. Sometimes you DRY the data and duplicate the structure.

What didn't help

Equally important: things that looked like they should help but didn't. Save yourself the time.

A 256-entry LUT for toLinear was slower on M4. The FP unit executes Math.pow(x, 2.4) fast enough that array lookup overhead is not worth it. Result is architecture-specific.
Manually inlining toLinear inside rgbToOklch made things worse (~270 ns → ~530 ns). The function got too large for V8 to optimize the body as a single unit.
Inlining normalizeHue as an expression instead of a function call: also slower. V8 optimizes named function call sites independently.

The pattern: V8 is smarter than you about inlining small functions. Trust it until you have a profile that says otherwise.

Lessons

The biggest wins came from understanding V8's hidden class model, not from clever algorithms. Monomorphism is a feature you preserve, not a thing you add later.

Allocations matter more than CPU time on hot paths in modern JavaScript. Wall-clock differences are often small, but GC pressure shows up as frame hitches and unpredictable latency.

DRY is a tool, not a rule. V8 cares about call site shape consistency more than your engineering aesthetics.

Always measure on the hardware you care about. The LUT result on M4 might be different on a Cortex-A53 phone or an older Intel laptop.

If you want to play with the library, there is a playground at colordx.dev, and the source is at github.com/dkryaklin/colordx.

AI Agent Orchestration & Applied LLMs: Code Search, Workflow Optimization, Document Processing

soy — Thu, 30 Apr 2026 21:36:33 +0000

AI Agent Orchestration & Applied LLMs: Code Search, Workflow Optimization, Document Processing

Today's Highlights

Today's top stories highlight practical advancements in AI agent orchestration and applied LLM capabilities for real-world workflows. We feature innovations in efficient code search for Claude, strategic agent usage techniques, and multi-agent document processing.

[Open Source] We built a local code search MCP for Claude Code that uses ~98% fewer tokens than grep+read (r/ClaudeAI)

Source: https://reddit.com/r/ClaudeAI/comments/1szvo7t/open_source_we_built_a_local_code_search_mcp_for/

This open-source project introduces a "local code search MCP" (Multi-Context Pointer) designed to enhance interaction with large codebases using AI models like Claude Code. The primary motivation was to address the inefficiencies and high token consumption that arise when AI agents fall back to generic tools like grep or reading entire files for code lookup. By implementing a specialized, context-aware search mechanism, the tool achieves significant token savings, reportedly reducing usage by approximately 98% compared to traditional methods. This optimization is crucial for managing costs and improving the speed of AI-assisted code generation and refactoring tasks, making LLMs more viable for complex development work.

The solution provides a more intelligent way for AI to navigate and retrieve relevant code snippets without incurring excessive token costs. This approach demonstrates a practical application of AI frameworks to augment developer workflows, specifically in the domain of code understanding and generation. It represents a concrete step towards making large language models more efficient and cost-effective for complex software development tasks by integrating smart, context-aware search capabilities directly into the AI's operational loop.

Comment: This is a game-changer for anyone doing serious code work with LLMs, directly tackling the context window and token cost limitations by making code search intelligent and efficient.

How to be better than 99% of Claude Code users while doing less, imo: (r/ClaudeAI)

Source: https://reddit.com/r/ClaudeAI/comments/1szn9b0/how_to_be_better_than_99_of_claude_code_users/

This discussion outlines a strategic approach to maximizing efficiency and quality when using AI agents like Claude Code, focusing on leveraging "success criteria" and "subagents" to achieve superior results with less effort. The core idea is to move beyond simple prompting by defining clear, measurable success criteria for each task, allowing the AI to self-evaluate and iterate more effectively. This methodology encourages users to think about the desired outcome in a structured way, guiding the AI to understand what constitutes a successful completion rather than just generating code, thereby reducing wasted iterations.

Furthermore, the emphasis on using "subagents" intentionally points towards a sophisticated form of AI agent orchestration. By breaking down complex tasks into smaller, manageable sub-tasks handled by specialized (or contextually configured) subagents, the overall workflow becomes more robust and capable of tackling intricate problems. Incorporating "skills" and .md documentation for repeatable processes further streamlines the interaction, transforming basic AI interaction into a systematic, agent-orchestrated process for enhanced code generation and development workflows.

Comment: Defining clear success criteria and utilizing subagents for complex tasks is the secret sauce for effective AI-driven development and a core principle for building robust AI agent workflows.

Absolutely blown away by the utility of the Claude Word add-in (r/ClaudeAI)

Source: https://reddit.com/r/ClaudeAI/comments/1szm5l3/absolutely_blown_away_by_the_utility_of_the/

This user testimonial highlights the transformative power of a Claude Word add-in for processing multiple, dense legal documents. The add-in facilitates sophisticated workflow automation by enabling "agents syncing, pushing and pulling information between them, pinging each other." This capability is particularly impactful in fields like legal analysis, where extracting, comparing, and synthesizing information across numerous lengthy documents is a common, time-consuming task. The described functionality goes beyond simple summarization, suggesting an intricate system of interconnected AI agents collaboratively working on document understanding and knowledge synthesis.

This represents a practical application of AI agent orchestration and RPA (Robotic Process Automation) principles within a familiar office environment. By embedding AI agents directly into a document editor like Word, it provides a seamless interface for users to leverage advanced AI for complex document processing, search augmentation, and knowledge management. The ability for agents to "ping each other" implies an underlying multi-agent system coordinating to achieve a higher-level goal, demonstrating how AI frameworks can be applied to significantly enhance real-world, document-intensive workflows, potentially saving immense time and reducing manual errors in tasks involving large data volumes.

Comment: This Word add-in illustrates excellent applied AI, showing how orchestrated agents can revolutionize document processing workflows, especially for complex tasks like legal analysis.

GPU Hardware, VRAM Optimization & Next-Gen Driver Updates

soy — Thu, 30 Apr 2026 21:35:31 +0000

GPU Hardware, VRAM Optimization & Next-Gen Driver Updates

Today's Highlights

This week features a deep dive into VRAM efficiency with a new Triton-based KV-cache compression engine, a look at DLSS 4.5 and Path Tracing's potential on the rumored RTX 5080, and a critical review of ASUS's 12VHPWR power delivery solution.

[P] I built a Triton KV-cache compression engine: 3.37x compression, 0.69ms P99 on an A10 (r/CUDA)

Source: https://reddit.com/r/CUDA/comments/1szeh3m/p_i_built_a_triton_kvcache_compression_engine/

The developer, OmniStack-RS, has unveiled a novel KV-cache compression engine built on NVIDIA's Triton framework, specifically targeting LLM-style recommendation systems. This project aims to address the significant VRAM consumption of Key-Value (KV) caches, which are crucial for maintaining context in large language models. By implementing a compression scheme, the engine achieved an impressive 3.37x compression ratio for the KV-cache, directly translating to more efficient memory usage on the GPU.

Benchmarking on an NVIDIA A10 GPU revealed a P99 latency of just 0.69ms for the compression operations. This indicates that the technique not only saves VRAM but does so with minimal performance overhead, making it practical for real-time inference scenarios. The use of Triton, a domain-specific language for writing highly efficient custom kernels, underscores the project's focus on low-level optimization and performance. This work is particularly relevant for deploying larger LLMs on GPUs with limited VRAM, or for enhancing throughput in data centers by allowing more concurrent users or larger context windows per GPU.

Comment: This KV-cache compression technique is a game-changer for VRAM-starved LLM inference, particularly on consumer GPUs or older data center cards like the A10. It means we can run larger models or achieve longer context windows without breaking the bank on new hardware.

Dark Souls 2 Path Tracing and DLSS 4.5 - One of the Most Impressive Path Tracing Mods | RTX 5080 (r/nvidia)

Source: https://reddit.com/r/nvidia/comments/1szx733/dark_souls_2_path_tracing_and_dlss_45_one_of_the/

A new mod brings full Path Tracing to Dark Souls 2, showcasing remarkable visual fidelity enhancements for the classic title. This implementation demonstrates the growing capability of modern GPUs to render incredibly realistic lighting and reflections, transforming the game's aesthetic. The mod's impressive performance is reportedly achieved with the aid of NVIDIA's Deep Learning Super Sampling (DLSS) 4.5, a rumored upcoming version of their upscaling technology.

The mention of "RTX 5080" suggests that this mod, or its implied performance benchmarks, are being tested or are highly performant on NVIDIA's next-generation GPU architecture. This points towards the anticipated performance uplift and new features that the RTX 50-series GPUs and their accompanying driver updates (like DLSS 4.5) will bring. For developers and enthusiasts, this highlights the continued advancement in real-time ray tracing and the crucial role of AI-powered upscaling in making such demanding graphics playable, hinting at what's possible with future GPU launches and driver optimizations.

Comment: Seeing Path Tracing in an older title like Dark Souls 2, powered by rumored DLSS 4.5 and the RTX 5080, really pushes the boundaries of graphical immersion. It's exciting to anticipate how these advancements will impact future game development and what performance gains we can expect from upcoming NVIDIA hardware.

[Der8auer] ASUS Equalizer - The 12VHPWR Solution? (r/nvidia)

Source: https://www.youtube.com/watch?v=GNy_FBt-FZg

Renowned hardware overclocker Der8auer has conducted a thorough review of the ASUS Equalizer, a device purported to solve the controversial 12VHPWR connector issues prevalent in high-end NVIDIA GPUs. The 12VHPWR connector has been a source of concern due to reports of melting and poor contact, leading to calls for more robust power delivery solutions. ASUS's Equalizer was marketed as a potential remedy to distribute power more effectively across the connector's pins.

However, Der8auer's technical analysis revealed that the ASUS Equalizer lacks active circuitry, meaning it's primarily a passive adapter. More critically, testing showed that the device performed worse than expected, failing to deliver on its promise to significantly improve power distribution or mitigate the risks associated with the 12VHPWR design. This finding is a crucial insight for anyone considering third-party solutions for GPU power delivery and underscores the complexities and challenges in designing reliable high-wattage connectors for modern graphics cards. It prompts users to remain cautious about solutions that don't fundamentally address the underlying mechanical or electrical design issues of the problematic connector.

Comment: Der8auer's deep dive confirms what many suspected: the ASUS Equalizer isn't the magic 12VHPWR fix. It's a reminder that true power delivery solutions need more than passive components, emphasizing the need for robust GPU power and cooling designs from manufacturers.

When Monitoring Becomes “Wrong”: The Limits of Watching Only Ping and Disk in Zabbix

Nicholas Broch — Thu, 30 Apr 2026 21:35:03 +0000

Monitoring systems like Zabbix are often introduced with a clear promise: visibility, control, and early warning. In theory, if something starts to fail, you should see it before users notice. In practice, however, monitoring can quietly shift from being a tool for understanding systems to something that merely confirms they are still technically “alive.” This is where it starts to go wrong.

A common pattern in many environments is to reduce monitoring down to a small set of indicators, often because of time constraints or lack of clarity about what actually matters. Ping checks and basic disk usage are typical examples. They are easy to set up, easy to understand, and they produce clean green or red states in a dashboard. A host is either reachable or it is not. A disk is either above a threshold or below it. On the surface, this looks like responsible system oversight.

The problem is that these signals say very little about whether a system is actually healthy.

A server can respond to ping perfectly while the application running on it is completely broken. Services can be degraded, queues can be backing up, authentication can be failing, and yet from a monitoring perspective everything appears fine. Ping only confirms network reachability, not usability. It is the equivalent of checking whether a building’s front door can open, without ever looking inside to see if anything is on fire.

Disk usage has a similar limitation. Knowing that a disk is 70 percent full does not tell you whether performance is degrading, whether logs are spiraling out of control, or whether a sudden spike is about to cause a critical outage. More importantly, it does not reflect the actual user experience or business impact. A system can have “healthy” disk levels and still be functionally unusable due to database locks, slow queries, or application-level failures.

The deeper issue is not the choice of metrics themselves, but the illusion of completeness they create. When monitoring is reduced to a handful of system-level checks, it becomes very easy to assume that “green” means “healthy.” This shifts attention away from what monitoring is supposed to achieve: understanding system behavior in a meaningful, contextual way.

Zabbix, like many monitoring tools, is not the problem. It is capable of deep observability if it is used that way. The issue lies in how it is often configured to reflect infrastructure states rather than service states. Infrastructure tells you what is happening at the machine level. Services tell you what is happening for users. The gap between those two is where incidents hide.

A more mature approach to monitoring focuses less on whether individual components are responding and more on whether the system as a whole is delivering its intended outcome. That means looking at request success rates instead of just server availability, latency instead of just CPU load, and error rates instead of just disk space. It means treating infrastructure metrics as supporting evidence rather than the main story.

When monitoring is limited to ping and disk, it becomes reactive and shallow. It can tell you that something has already failed, but rarely why it is about to fail or how it affects real usage. Over time, teams begin to trust dashboards that are technically correct but operationally misleading.

Good monitoring should introduce doubt, not false certainty. It should make it harder to assume everything is fine when it is not. And it should reflect the system as users experience it, not just as machines report it.

In that sense, monitoring does not become “wrong” because it is inaccurate. It becomes wrong when it is too narrow to tell the truth that actually matters.

Cursor 3 shipped parallel agents and the community can't agree on whether that's good

1p — Thu, 30 Apr 2026 21:33:59 +0000

Cursor rebuilt from scratch around managing fleets of AI agents instead of writing code. The demos look very convincing. The HN thread is a mess. And someone spent $2,000 in two days. Here's what actually matters.

Quick context if you haven't been following the AI tooling space: Cursor is the VS Code fork built by Anysphere that became the de facto AI coding tool for a huge chunk of the dev community, hit $2B ARR earlier this year, and raised over $3 billion from NVIDIA, Google, and others. It's the tool people recommend when someone asks "should I just use Copilot."

On April 2, 2026 they shipped Cursor 3, internally codenamed Glass. It's not a point release. They rebuilt the interface from scratch.

The pitch: you are the architect, agents are the builders. The IDE is still there, but the default experience is now managing a fleet.

Thirty minutes after the announcement hit Hacker News, the top comment wasn't about a feature.

What actually shipped

The headline change is the Agents Window -- a full-screen workspace running alongside the IDE where you manage multiple AI agents in parallel. Previously: one chat, one agent, one task at a time. Now you can run as many as you want across different repos, local machines, worktrees, SSH environments, and cloud VMs from one place.

A few things worth knowing about specifically:

Cloud agent handoff is the feature that makes the rest of it real. Start a session locally, hand it to a cloud VM, close your laptop, come back to a finished PR. This is the part that shifts "AI coding assistant" into something closer to "asynchronous engineering team." Whether that's what you want is a different question.

Composer 2 is Cursor's in-house coding model -- runs locally, no per-use cloud charges, higher usage limits. There's a story here about how they disclosed it (or didn't) that we'll get to.

/multitask, shipped in 3.2 on April 24, breaks a large task into chunks and fires them at a fleet of subagents simultaneously. Cross-repo too. This is where the "agent execution runtime" framing starts to feel accurate rather than just aspirational -- and where Cursor starts looking less like an IDE and more like a CI/CD layer you interact with conversationally.

The MCP Marketplace rounds it out. Cursor is quietly becoming a platform. That matters for lock-in reasons as much as feature reasons.

The philosophy shift, and why half the community isn't happy about it

Cursor's co-founders framed this release around "three eras of software development." Era one: you edit files manually. Era two: agents write most of the code while you direct. Era three: fleets of agents ship improvements autonomously while you review.

They're betting we're in era two right now, and building toward three. The interface reflects that.

The top HN comment the day it launched:

"I wish they'd keep the old philosophy of letting the developer drive and the agent assist. I still want to code, not vibe my way through tickets."

A Cursor engineer responded within minutes -- the IDE still exists, the Agents Window is a separate surface, you can have both open simultaneously or ignore agents entirely. Both things are true. But they're not actually disagreeing about features, they're disagreeing about what the job is supposed to be.

That disconnect is the real story here. Not what features shipped, but what Anysphere believes about where software development is heading, and whether developers agree with that framing. A lot of people who use Cursor are there precisely because they want to stay close to the code. The agent-first pitch reads to them as the tool choosing a direction they didn't ask for.

And they're not wrong to push back -- because what Cursor 3 is really proposing isn't more automation on top of your existing job. It's a different job. Writing code and managing outputs from multiple semi-autonomous systems running in parallel are not the same skill. They use different mental models, different review instincts, different debugging approaches. One is authorship. The other is closer to code review at scale with partial information and no single source of truth.

"Orchestrating a fleet" is not a more productive version of "writing systems software." It's a different mode of working. Cursor 3 has a strong opinion on which mode matters more. You might not share it.

The Composer 2 situation

Cursor didn't disclose what model Composer 2 is built on in their initial announcement. An external developer spotted the identifier kimi-k2p5-rl-0317-s515-fast in system responses and traced it back to Kimi K2.5 from Moonshot AI.

Co-founder Aman Sanger called the omission "a miss" and said they'd disclose the base model upfront for future releases. Moonshot AI confirmed it was an authorized commercial partnership through Fireworks AI. About 75% of Composer 2's total compute came from Cursor's own continued pre-training and reinforcement learning on top of the base -- so it's not just a reskin. But the lack of upfront disclosure did not go over great.

On benchmarks: Composer 2 scores 61.7 on Terminal-Bench 2.0 vs Opus 4.6's 58.0. GPT-5.4 sits at 75.1. Google's Antigravity scores 76.2 on SWE-bench Verified. Cursor is competitive but not leading -- which matters more now that they have an in-house model to defend.

The upside is real though. Local execution, no per-use cloud charges, higher usage limits than routing everything to frontier models. For people who were burning through Claude credits in Cursor, it's a meaningful cost relief for standard tasks.

The cost thing is not a footnote

This is the part most people are going to ignore until they get billed.

Cursor's pricing page lists four tiers: Free, Pro at $20/month, Pro+ at $60, Ultra at $200. Those numbers look fine. The issue is that cloud agents aren't metered the way the pricing page implies.

Early adopters on Hacker News reported spending $2,000+ running cloud agents. Not $2,000/month. Two days. One user switched from $1,800/month on Cursor to roughly $200/month on Claude Code, calling it "WAY better value for money." Another reported "$2k a week with premium models" before switching.

The per-minute VM charges for cloud execution are not disclosed on the pricing page. You find out when the bill arrives.

Compare: Claude Code Max runs at a flat $100-200/month with parallel execution via worktrees. If you're doing heavy agentic work, the math is not subtle.

Local agents via Composer 2 have no per-use charges -- that's the intended use case for standard tasks. Cloud agents are where the real power is (overnight runs, mobile-triggered tasks, multi-repo parallelism) and that's also where the costs are opaque. Track your spend for a full week before assuming the listed tier is what you'll actually pay.

The feature is real. The value is real for the right workload. But the pricing model is designed around the demos, not around what happens when you actually run it for a week.

Where it sits in the landscape

The AI IDE space consolidated fast this year. Three distinct philosophies, worth knowing the difference:

Cursor 3 -- IDE-native, GUI-first, now agent-first. If you want visual tooling, parallel agents with a management UI, and the ability to annotate a browser and tell an agent to fix that exact thing, Cursor is where that workflow is most mature. Cost: $20/month listed, variable in practice.

Claude Code -- terminal-native, stays out of your way. No GUI, runs in your existing terminal, integrates with whatever editor you already use. Still ahead on fully autonomous agentic work for people who don't want an IDE wrapper around everything. Flat $100-200/month at Max tier.

Google Antigravity -- the wildcard. Built from scratch (not a VS Code fork) by the team Google acquired for $2.4B, shipped free in November 2025, 76.2% on SWE-bench Verified which is one of the highest published numbers for a coding agent right now. Free. Worth a weekend if you haven't looked.

ForgeCode -- open source, terminal-based, bring your own API keys, topped Terminal-Bench 2.0 at 81.8%. Their blog post about hitting number one is titled "benchmarks don't matter," which is either a good sign or a bad sign depending on your priors. Worth a weekend too.

What this actually means

The "you're the architect, agents are the builders" framing is going to keep coming up. Cursor 3 is the most explicit statement of that direction from a major tool yet, but it's not the only one heading there. Antigravity, Claude Code, Codex -- they're all converging on the same mental model.

The question worth sitting with if you build systems software, CLI tools, or anything requiring you to stay close to the metal: does agent orchestration actually help that workflow, or does it mostly help the "generate a CRUD app from a prompt" workflow and kind of work for everything else as a side effect?

My honest read: parallel agents are genuinely useful for tasks with clear boundaries and independent surface area. Spin up three agents on three separate features, review the PRs, merge what works. That's real. For deep systems work where the whole point is that you're carefully reasoning through one gnarly problem -- handing that to a fleet isn't faster, it's noisier. You spend the time you saved writing code on reviewing agent output that's plausible-looking but wrong in ways that only show up later.

It'll get there. The benchmarks are moving fast enough that "this doesn't work for systems work" is probably a 2026 statement, not a permanent one. But right now, parallel agents are mostly useful for bounded tasks where correctness is verifiable and the problem decomposes cleanly. That's a real category of work. It's just not all the work.

The more interesting shift is the one underneath all of this. Cursor 3 isn't really about parallel agents as a feature. It's about what the tooling assumes the job looks like. And if the tools all converge on "you manage agents, you don't write code," the developers who push back aren't being resistant to change -- they're noticing that nobody asked whether that's actually the job they signed up for.

Where to dig in

Cmd+Shift+P -> Agents Window -- try the parallel agents UI in Cursor 3
cursor.com/changelog -- they ship fast, worth following
ForgeCode on GitHub -- bring-your-own-keys, open source, worth a look if you're skeptical of the closed tooling direction
Google Antigravity -- free, agent-first, no VS Code fork baggage

What's your current setup? Cursor, Claude Code, something else entirely? And if you've actually run parallel agents in production -- how'd the costs shake out? Drop it in the comments, genuinely curious where people land on this.

Zero-config Golang Heap Profiling

Coroot — Thu, 30 Apr 2026 21:28:59 +0000

Coroot is an Apache 2.0 open source platform that simplifies observability with no-code configuration. The Coroot node-agent already collects CPU profiles for any process on the node using eBPF, with zero integration from the application side. For Java, we dynamically inject async-profiler into the JVM to get memory and lock profiles. But Go processes were still a blind spot for non-CPU profiling unless the app exposed a pprof endpoint and the cluster-agent scraped it.

We wanted the same zero-config experience for Go heap profiles. This post is about how we got there.

The runtime already profiles

Go's runtime has a built-in memory profiler. On every allocation, the runtime samples with probability size / MemProfileRate and records the call stack. The default rate is 512 * 1024, or about 1 sample per 512KB allocated. Samples are aggregated into a linked list of "buckets", where each bucket represents a unique (stack trace, size class) combination and accumulates four counters: total allocations, total frees, bytes allocated, bytes freed.

This is what runtime.MemProfile() returns and what go tool pprof http://.../debug/pprof/heap renders. The overhead is negligible and it's been production-grade since forever.

There's one catch. The Go linker has an optimization: if no code in the binary references runtime.MemProfile, it sets an internal disableMemoryProfiling flag, and the runtime sets MemProfileRate = 0 on init. No samples, no buckets, nothing to read. A binary that doesn't import runtime/pprof or net/http/pprof (directly or transitively) has no heap profile available, even though the runtime fully supports it. We'll come back to this.

This list is what runtime.MemProfile() walks when pprof asks for a heap profile. It's literally the global variable runtime.mbuckets:

// runtime/mprof.go
var (
    mbuckets atomic.UnsafePointer // *bucket, memory profile buckets
    ...
)

So the data is already there, being collected continuously, for free. The only question is how to read it from outside the process.

Reading process memory from outside

Linux exposes every process's virtual address space via /proc/<pid>/mem. With the right permissions (our node-agent already has CAP_SYS_PTRACE), you can pread() arbitrary addresses. It's read-only, it doesn't suspend the process, the target doesn't even know you're there.

The plan:

Find the virtual address of runtime.mbuckets in the Go binary's symbol table.
Read the pointer value at that address from /proc/<pid>/mem.
Walk the linked list, reading each bucket's header, stack PCs, and memRecord.
Convert to pprof format and upload.

Finding runtime.mbuckets without loading the symbol table

The first gotcha: Go binaries embed their own symbol table (pclntab) for runtime use, but runtime.mbuckets is not a function. It's a variable, which lives in the ELF .symtab section. On a stripped binary (go build -ldflags="-s"), there's no .symtab and we can't find the symbol. We skip those.

On an unstripped binary, .symtab can be huge. For k3s, it's ~11MB. Using debug/elf.File.Symbols() loads all of it into memory at once. For a node-agent that profiles dozens of Go processes, that's not OK.

So we wrote a streaming scan that reads one Elf64_Sym entry at a time and reads only the bytes we need from the string table:

func findSymbolValue(ef *elf.File, sectionName, symName string) (uint64, error) {
    section := ef.Section(sectionName)
    strtab := ef.Sections[section.Link]

    symReader := section.Open()
    entry := make([]byte, 24) // Elf64_Sym
    target := []byte(symName)
    nameBuf := make([]byte, len(target)+1)

    for {
        if _, err := symReader.Read(entry); err != nil {
            break
        }
        nameIdx := ef.ByteOrder.Uint32(entry[0:4])
        value := ef.ByteOrder.Uint64(entry[8:16])

        n, _ := strtab.ReadAt(nameBuf, int64(nameIdx))
        if n > len(target) && nameBuf[len(target)] != 0 {
            continue
        }
        if string(nameBuf[:len(target)]) == symName {
            return value, nil
        }
    }
    return 0, fmt.Errorf("%s not found", symName)
}

Peak memory: a 24-byte buffer plus a 17-byte buffer (len("runtime.mbuckets")+1), regardless of binary size.

Before doing this expensive scan we also check if the binary is Go at all via the .go.buildinfo section: one section header lookup, zero allocations.

The bucket layout, and two traps

The bucket struct itself is just a 48-byte header:

type bucket struct {
    _       sys.NotInHeap
    next    *bucket
    allnext *bucket
    typ     bucketType
    hash    uintptr
    size    uintptr
    nstk    uintptr
}

But the runtime allocates extra space after it and stores two more things in the same contiguous region: the stack trace (nstk program counter addresses, 8 bytes each) and a memRecord struct holding the alloc/free counters.

So from our point of view, each bucket is a variable-sized blob: 48 bytes header + nstk*8 bytes of PCs + 128 bytes of memRecord. We read the header first to get nstk, then the rest.

Two traps we fell into:

Trap 1: the first field, _ sys.NotInHeap, looks like 8 bytes of padding. It's zero bytes. Sizing the header at 56 bytes gave us nicely parsed garbage: valid-looking pointers that turned out to be hash values, and typ values in the quintillions. Go 1.17 through 1.19 used a //go:notinheap comment directive instead; Go 1.20 switched to the typed marker, but the binary layout didn't change. The real header is 48 bytes.

Trap 2: there are two pointer fields, next and allnext. They are not the same list. next is the hash table chain within a size class. allnext is the global list of all memProfile buckets. We want allnext.

The delta problem

The counters in memRecord are cumulative: they grow monotonically over the lifetime of the process. If we want an allocation rate, we need to compute the delta between two collection cycles.

We keep a map per PID of bucket address -> previous counters and subtract on each cycle to get the delta. We key by bucket address rather than stack hash: the Go runtime never frees mprof buckets, so the address is a stable unique identifier, and it's a single uint64 instead of a variable-length string, which avoids a huge amount of allocation churn in the hot path.

Too many syscalls

Early profiles showed our collector spending 30-40% of its CPU in syscall.Pread. Each bucket needs at least 2 reads: one for the header (to get nstk), then one for the variable-length stk[nstk] | memRecord block. With 1000+ buckets per process and a dozen Go processes on a node, that's thousands of syscalls per minute.

We tried a read-ahead cache: on a miss, pull 256KB centered around the requested address. The idea was that Go's persistentalloc places buckets in large arenas, so consecutive buckets in the allnext chain might be physically close.

We instrumented jump distances between consecutive buckets for one process with 1230 buckets. 40% of jumps are >16MB. Buckets are scattered across the entire process address space, not clustered.

A 256KB cache hits ~20% of the time: better than nothing, but the best we could do without multi-MB buffers that cost more than they save.

The linker-disabled profiling problem

After deploying, we saw some Go processes return an empty bucket list (runtime.mbuckets pointer was 0x0) even though they were clearly allocating memory (tens of MB RSS, actively running).

Turns out the Go linker has an optimization: if no code in the binary references runtime.MemProfile, it sets a disableMemoryProfiling flag, and the runtime sets MemProfileRate = 0 on init. No profilealloc() calls, no buckets ever created.

This hits any Go binary that doesn't import runtime/pprof or net/http/pprof, directly or transitively. In our case it was a small load generator: no pprof, no HTTP server, no dependencies that would drag pprof in. The profile endpoint the runtime would serve is dead code, so the linker dropped it.

The fix: we can write to /proc/<pid>/mem too. If we detect MemProfileRate == 0, we write 524288 (the default) back to the runtime.MemProfileRate address. The runtime checks this variable on every allocation, so the change takes effect immediately: no restart, no signal, nothing. Just a single atomic 8-byte write to a known address in the data segment.

This is gated behind a --go-heap-profiler=force flag for users who want the "always on" behavior:

--go-heap-profiler=disabled  # off
--go-heap-profiler=enabled   # default, passive only
--go-heap-profiler=force     # write MemProfileRate if zero

The overhead of re-enabling profiling is whatever the Go default overhead is: ~1 sample per 512KB. For any workload where this matters, you'd want it on anyway.

Allocation rate metrics

Since we already compute per-bucket alloc deltas, exposing total allocation rate as Prometheus counters is free:

container_go_alloc_bytes_total    # total bytes allocated
container_go_alloc_objects_total  # total objects allocated

Summed across all buckets in the process. Coroot uses them to draw the allocation rate chart alongside the flamegraph.

Limitations

Stripped binaries are skipped. No .symtab, no runtime.mbuckets address, nothing we can do externally.
The active cycle updates on GC. Between GCs, new allocations go into future[0..2] and we don't see them. Same limitation as runtime.MemProfile().
Go-internal struct layout. If the bucket struct changes in a future Go release, we'll need to update. The layout has been stable since Go 1.17, but there's no API guarantee.
Goroutine, block, and mutex profiles are not yet exposed. Block and mutex use the same infrastructure (bbuckets, xbuckets), but both are disabled by default and have real overhead if enabled (checks on every mutex/channel op), so we're not force-enabling them.

In Coroot

Profiles are already in the Coroot UI. Every memory chart has a link to the heap flamegraph for that service, so you can jump from "memory is climbing" to "here's the call stack eating it" in one click.

What's new is that profiles are now plugged into RCA. If Coroot sees a service's CPU or memory go up at the same time as an issue, it pulls up the profile and compares two windows: the one during the issue, and a healthy one from just before. The flamegraph you see in the RCA is a diff, not a snapshot. Functions that got hotter pop out, the rest fade away.

So now RCA can give you a different kind of answer. Instead of "p95 is up, allocations are up", you get "this function is allocating twice as much as it was before the deploy." The metric tells you something is off. The diff tells you which code is off.

Chaos experiments

To see this in action, we set up a small demo and broke it on purpose. There's a product-catalog service backed by Postgres, sitting behind an api-gateway. We bolted a chaos middleware onto product-catalog so we can flip on different kinds of bad behavior with a single API call, then we watched what showed up in Coroot.

GC pressure

For the first experiment, we flipped on the gc_pressure switch. That sends every request through a function called inefficientEnrichProducts, which is exactly as bad as the name suggests. For each of 30 fake products in the request, it:

Marshals and unmarshals the product 10 times in a row.
Builds a "search index" by lowercasing, uppercasing and title-casing every word and generating every 2 to 4 character n-grams.
Builds 20 nested "related products" maps, each with three sub-maps.
Marshals and unmarshals the whole result one more time "for caching".

That's about 2 MB of throwaway memory per request. The service still answers, but the garbage collector barely gets a break.

The pain shows up one hop away. api-gateway talks to product-catalog on every page render, so as soon as the switch flips, its p95 latency jumps from 0.16s to 3.76s:

Coroot's RCA traces the spike back to product-catalog and pulls up its CPU profile:

Look at the right side of the flamegraph. There's a fat column of runtime.gcBgMarkWorker, runtime.systemstack, runtime.scanobject, runtime.gcDrain. The garbage collector is burning real CPU. That's a clear sign the runtime is under allocation pressure, but the CPU profile can't tell you which line of your code is responsible for it.

The heap profile can:

There it is. main.inefficientEnrichProducts sits at the top of alloc_space, with the JSON encoders, map growth, and bytes.Buffer operations stacked underneath. That's the exact set of things the function does inside its loop. Same function the CPU profile already flagged, but now you can see directly that it's the one driving the GC.

Without the heap profile, you'd see the GC running hot and the JSON encoder eating CPU, and you'd still have to guess which call site to fix. With it, the guess is gone. Cache the marshalled output, drop the redundant rounds, or both, and the alloc band and the GC band shrink together on the next collection.

Memory leak

For the second experiment, we flipped the memory_leak switch. Now every request calls appendToProductCache, which builds a small chunk of pointer-heavy data (a product map, a search index of fifty terms, cross-references to recent entries) and appends it to a global slice. Nothing ever evicts. The cache grows about 200 KB per request, forever.

The symptom is the obvious one. product-catalog memory just keeps climbing. After a few minutes, both replicas are growing at over 640% per hour and on track to OOM-kill themselves.

What's interesting is what RCA does next. It pulls up the heap profile for the anomaly window and compares it against a healthy window from before the leak started:

The diff narrows it down to a single function. main.appendToProductCache accounts for 99.6% of the in-use memory that wasn't there before, and the full call path from the HTTP entrypoint down to it sits right above the flamegraph. There's almost nothing left to investigate.

A plain heap snapshot would have shown appendToProductCache near the top too, but mixed in with everything else the service legitimately allocates. The diff drops the noise and keeps only what changed, which is exactly what you want when you're chasing a leak that started somewhere in the last hour.

Summary

Heap profiles for your Go services no longer require pprof endpoints, scraping configuration, or a deploy. Coroot picks them up automatically from whatever is already running on your nodes, with no code changes, no annotations, and no restart.

The payoff shows up in incidents. A memory leak comes down to one function in a diff'd flamegraph. GC pressure stops being a vague "the runtime is busy" and becomes a specific call site. And you get this code-level accuracy without needing access to the code itself, which matters for SRE and platform teams running services they didn't write. Because the profiles sit right next to the metrics and the RCA that surfaced the issue, you go from "something is wrong" to "here is what to fix" without ever leaving the page.

Want to try Zero-config Go heap profiling on your setup, completely open source? Visit out our Github to quickly get set up.

React + fetchstream-js: Render JSON as It Arrives

CODING IN BLOOD — Thu, 30 Apr 2026 21:26:25 +0000

Most React apps still wait for the full JSON response before showing anything. That means a loading spinner, a blank table, and slower perceived performance. fetchstream-js solves this by parsing JSON progressively, so your UI can update as data arrives.

Install

npm install fetchstream-js

Basic React example

import { useEffect, useState } from "react";
import { fetchStream } from "fetchstream-js";

export default function Users() {
  const [snap, setSnap] = useState({ data: null, chunks: 0, done: false });

  useEffect(() => {
    fetchStream("/api/users")
      .live(({ data, chunks, done }) => {
      setSnap({ data, chunks, done });
      })
      .catch(console.error);
  }, []);

  return (
    <div>
      <h2>Users</h2>
      <pre>{JSON.stringify(snap.data, null, 2)}</pre>
      <p>{snap.chunks} chunks received {snap.done ? "• done" : ""}</p>
    </div>
  );
}

Why this works well in React

With fetchstream-js, your component does not need to wait for the entire payload. The UI can render partial data early, which improves perceived performance and makes the app feel faster.

When to use it

Use fetchstream-js for:

large JSON lists
dashboards
tables
any UI where early feedback matters

Final thought

If your React app spends too long on a spinner, fetchstream-js is a simple upgrade. One install, one hook, and your UI starts showing data sooner.

🔗 Links

NPM: https://www.npmjs.com/package/fetchstream-js
Live Example: https://fetchstream-js.vercel.app
Getting Started: https://eklavya-raj.github.io/fetchstream-js/guide/getting-started

Announcing the Winners of the DEV Weekend Challenge: Earth Day Edition 🌍

Jess Lee — Thu, 30 Apr 2026 21:25:40 +0000

The time has come! We are thrilled to announce the winners of our second DEV Weekend Challenge: Earth Day Edition.

We were blown away by the creativity, craftsmanship, and care that went into your submissions. You gave the planet a voice through dashboards, AI tools, immersive simulations, and stories that made us think differently about our relationship with the natural world.

Thank you to everyone who participated. Now, let's celebrate our winners! 🎉

🏆 Congratulations To...

Overall Winners

Unearthed

@anchildress1 took us deep underground to examine the fossil fuel systems quietly powering our homes and cities. The post weaves together personal narrative and technical research to reveal the environmental cost hidden behind every flipped light switch. It's a sobering reminder of how much remains out of sight.

DEV Weekend Challenge: Earth Day

Ashley Childress

Apr 20

Unearthed—The Coal Mine Behind Every Light Switch

#devchallenge #weekendchallenge

Comments 3

11 min read

Last Breath

@_boweii built an app that uses sound to detect which species are vanishing from your local green spaces. The project combines audio recognition with ecological data to surface biodiversity loss in a way that's immediate and personal. It's a unique approach to environmental storytelling through audio.

DEV Weekend Challenge: Earth Day

Tombri Bowei

Apr 17

I Built an App That Listens to Your Garden and Tells You What's Disappearing. 🌍

#devchallenge #weekendchallenge

Comments 8

5 min read

Energy Leak Scout

@afreen_hossain_16f9999ebc built a home energy auditing tool that helps users identify where they're losing energy and money. The app is polished and well-documented, with a clear focus on making sustainability actionable for everyday people. We loved how it encourages positive changes with real financial incentive.

DEV Weekend Challenge: Earth Day

Afreen Hossain

Apr 20

Energy Leak Scout: Find the Waste. Cut the Bill.

#devchallenge #weekendchallenge

Comments

3 min read

CrowdCommand

@aashitanegii tackled a problem that doesn't get nearly enough attention: the enormous resource waste generated by large-scale events. CrowdCommand uses AI to model crowd movement and reduce inefficiencies in real time, from energy use to physical waste. It's an ambitious, well-executed project with clear potential for real-world deployment.

DEV Weekend Challenge: Earth Day

Aashita

Apr 18

CrowdCommand — AI Powered System to optimize crowd flow and reduce large-scale event waste

#devchallenge #weekendchallenge #ai #hackathon

Comments 2

3 min read

Prize Category Winners

Best Use of Backboard - Terra Triage

@arqamwd built an app where you snap a photo of an injured animal and the right licensed wildlife rehabilitator gets paged within 60 seconds. The secret is in the memory: every accept, decline, and "at capacity" response is written to Backboard, and that data directly re-ranks who gets contacted next — it's the core mechanism that makes the dispatcher smarter with every case.

DEV Weekend Challenge: Earth Day

Arqam Waheed

Apr 20

Terra Triage: I Built a 3-Agent Wildlife Dispatcher That Learns From Every Referral

#devchallenge #weekendchallenge #ai #backboard

Comments 2

9 min read

Best Use of Auth0 for Agents - GreenGate

@jtorchia built a sustainability auditing tool that puts the human firmly in the loop by requiring phone-based approval before any agent action is taken. The project makes clever use of Auth0's CIBA flow to create a secure and accountable agentic system. It's a compelling proof of concept for responsible AI agent design.

DEV Weekend Challenge: Earth Day

Juan Torchia

Apr 20

GreenGate: the agent proposes, the phone decides — building an Auth0 CIBA + Gemini audit for embodied carbon

#devchallenge #weekendchallenge #auth0 #agents

Comments

20 min read

Best Use of Google Gemini - EcoScan

@temiloluwavalentine built a tool that scans your devices and surfaces exactly which ones are consuming the most energy and driving up your bills. Gemini powers the analysis, turning raw usage data into clear, actionable insights for users. The result is a sharp, focused tool that makes energy waste visible in a way that actually motivates change.

DEV Weekend Challenge: Earth Day

Temiloluwa Valentine

Apr 19

# ⚡ EcoScan— See Which Device is Drinking Your Money

#devchallenge #weekendchallenge #earthday #gemini

Comments 1

3 min read

Best Use of Snowflake - SQLgo

@mohammad515253 approached sustainability from an unexpected angle: the carbon footprint of inefficient database queries. With Snowflake at the core of the data layer, SQLgo analyzes query patterns and redundant storage to help developers reduce computational waste. It's a clever reframe that makes sustainability relevant to anyone who writes code.

DEV Weekend Challenge: Earth Day

Mohammad Tejabwala

Apr 20

SqlGo🌱 - Save CO2 by optimizing queries and removing redundant storage

#devchallenge #weekendchallenge #gemini #webdev

Comments

3 min read

Best Use of GitHub Copilot - Planetary Pulse

@mamoor_ahmad built a sweeping Earth monitoring dashboard that pulls together environmental data from multiple sources into a single, unified view. Copilot handled Express route scaffolding, the animated CSS globe, the SVG health ring, the IPCC-calibrated carbon calculator logic, and responsive layout breakpoints, shaving an estimated 8.5 hours off the total build time. The post makes a compelling case for Copilot as a genuine force multiplier on ambitious solo builds.

DEV Weekend Challenge: Earth Day

Mamoor Ahmad

Apr 18

🌍 Planetary Pulse — AI-Powered Earth Dashboard with 6 Prize Tech Integrations

#devchallenge #weekendchallenge #hackathon #earthday

Comments 6

7 min read

Best Use of Solana - EcoLens

@arya_koste_5845807df94776 created a system for recording carbon reduction pledges on-chain, making climate commitments transparent and verifiable. An AI layer backs up each pledge with research and accountability tracking, so the promises people make are grounded in real data. It's an inventive use of blockchain for something that goes well beyond speculation.

DEV Weekend Challenge: Earth Day

Arya Koste

Apr 19

I Put Carbon Pledges on the Solana Blockchain for Earth Day (And Built the AI to Back It Up)

#devchallenge #weekendchallenge #solana

Comments

6 min read

Prizes

All ten winners will receive:

$100 USD
DEV++ Membership
Exclusive DEV badge

All participants with a valid submission will receive a completion badge. 🏅

What's Next?

Stay tuned for upcoming challenges by following this tag:

#devchallenge Follow

This is the official tag for submissions and announcements related to DEV Challenges.

We hope you had fun, felt challenged, and maybe added a thing or two to your professional profile.

See you next time!

LLM needs to generate/search in order to compare. Silently answer my question is a lie.

gitdexgit — Thu, 30 Apr 2026 21:23:04 +0000

LLM works by generating words out of nothing. If context window is 0 then it can't guide to to something it doesn't have. So it needs something prior in the context window. makes sense, you need something to compare something you can't compare nothing to something.

So Our goal is to use LLM to learn.

I see and saw people share their prompts:

"silently answer my question first then find where I'm wrong. Don't give me the answer/hints unless I tell you to. Only tell me where I'm wrong"

The problem is people think their LLM acts as a teacher that guides student to the answer without tell the user the answer.

That's just absurd, silently generate my answer is a concept only for humans.

LLM doesn't have a memory where it stores the correct answers. It only generates. If it's not in the context window LLM generates it from scratch.

Let's analyze the prompt silently generate answer, and only guide user to the correct answer

Let's think about this scenario from the perspective of the user and LLM where user's goal is learning and using LLM to guide his thoughts:

What people expect/want:

User:
"Q: Here is the question the user is trying to answer"
--> A: The user answers his own question.

LLM:

Ok user did my job, I don't need to answer his question.
Let me generate in my head silently the correct answer.
Now let me compare it.

4. Now let me guide the user to the correct answer using socratic method. I'll only ask him questions and never give him hints unless he asks me to. And only when I see user give up then I'll give him the answer.

What actually happens:

User:
"Q: Here is the question the user is trying to answer"
--> A: The user answers his own question.

LLM:

Ok user did my job, I don't need to answer his question.
Now let me compare it.

4. Now let me guide the user to the correct answer using Socratic method. I'll only ask him questions and never give him hints unless he asks me to. And only when I see user give up then I'll give him the answer.

As you see 2nd step is missing. It never happens. why?

Here is why: LLM is unable to silently generate correct answer. LLM model has to physically generate output, example CoT; they call it thinking. Before it gives you the answer. <- Why did they not tell it "Silently think before you give me answer?"

So LLM needs to have some preliminary context before it gives you the answer.

So what is it comparing? IDK. It just generates what most likely fit. You could say It generated the answer in CoT. Probably, who knows I'm not sure. But we want to be sure. No matter what model we use, model has thinking or no thinking or only has certain tokens for thinking. We must make sure it generates the answer first.

In our Scenario, there are 3 ways that an LLM generates an answer

1) It could happen in it's own CoT. (Unrealaible. No one reads CoT anyways/ could be small)

2) You just tell LLM "Find where I'm wrong" and just answer. LLM finds where you are wrong. Repeat Until LLM doesn't find anything wrong. (That is so rigorous)

3) Tell LLM to generate correct answer first OR copy paste correct answer after you finish answering. Then tell LLM to compare with your own answer and find where you are wrong.

Option 1: Is all about luck

Option 2: Takes too much time and disrupts your learning process but eventually after some enough time you will get to LLM says Correct. It's so rigorous and it will find exactly where you are wrong word by word. If you make a mistake in technicality not using the exact word then you are wrong.

Option 3: It already has the answer. It's just comparing it until comparison is 100% complete. You can also tell it compare only the intent if the mental model matches even if the exact words are not correct it's still a solid answer.

the 3rd option is the winner for learning. I tested both option 2 and 3. Option 2 is very good for a skeptical assistant, but 3 is the go to because it only matches the answer it generates or the answer you give it (yesterday you learned something you copy paste the answer for tomorrow's llm)

So LLM with prompt just generating what someone might say when they don't know the answer. Just extra bloat words to read anyway.

How to implement option 3

We need some rules:

Either LLM generates an answer at the start of output, but puts it in <- Similar to how most people don't read CoT. OR you copy paste answer from yesterday without reading it then tell LLM to compare but never give you the answer until you reach 100% same answer to your specific question.
LLM now will compare your previous and see where you got it wrong and where you got it write. Find the gap.
Now it can act as a guide. Tell you where you are wrong but provides no answer. Preferably no hints only when you give up then it hints. <-- or just read what you are not supposed to read to find the answer.

If the LLM has access to google it would improve the ability to compare correct answer a lot. Giving LLM access to google or search Will hopefully provide more context as well. But keep it simple because LLM google search is expensive.

Silently generate answer for learning doesn't work. There is no silent answer when dealing with LLM. You need a contract between the user and the LLM. The user will not read the correct answer.

Why God Kit? A Lightweight Vue 3 UI Library and Design System for Admin Apps

Parsa Jiravand — Thu, 30 Apr 2026 21:22:25 +0000

Why God Kit? A Lightweight Vue 3 Component Library Built for Real Dashboards

If you are evaluating Vue UI libraries, Vue component frameworks, or a complete design system for Vue 3, you have strong options—from full design-language suites with hundreds of primitives to minimal headless kits. God Kit sits in a different niche: admin and internal tools that need consistent design tokens, small bundles, and a steady path away from legacy UI—including dense data tables and dashboard chrome—without carrying a massive runtime.

This post explains what God Kit is, why teams choose it over heavier Vue component libraries, and where to find documentation, source, and npm. We also share where the project is going: a visual UI builder and a growing ecosystem around Vue 3 and Nuxt 4.

Quick links (docs, code, package)

Resource	URL
Documentation & live component docs	https://godkit.godplans.org/
GitHub (source, issues, contributing)	https://github.com/god-plans/god-kit
npm package	https://www.npmjs.com/package/god-kit
Sponsor / fund the project	https://github.com/sponsors/god-plans

What is God Kit?

God Kit is an open source Vue 3 UI kit and design system for teams building dashboards, back-office tools, and Nuxt 4 apps. It ships:

Typed Gk* components (forms, containment, navigation, data table, feedback, layout)
Semantic design tokens (--gk-* CSS variables) for light/dark, density, and theming
Subpath exports so you import only what you need—friendly to tree-shaking and smaller bundles than “install everything” suites
createGkKit-style global configuration for theme, display, locale, and defaults
A CLI to scaffold components (npx god-kit add …) aligned with kit conventions
Accessibility coverage on key primitives (e.g. axe-based specs in the repo)
Optional bridge stylesheets in the repo for incremental migration from older component layers when you cannot rewrite every screen at once

It is MIT-licensed and aimed at developers who want simple, lightweight Vue components with a token-first workflow—not necessarily every marketing-site block in a single package.

Why God Kit? (The classic “why this framework?”—for a focused kit)

Many popular guides follow the same recipe: open community, deep component catalogs, layouts, tooling, and long-term support. That pattern works beautifully when you want the fullest possible surface area and a single-vendor design language end to end.

God Kit takes the same spirit—clarity, docs, ecosystem—but narrows the product:

If you are searching for…	God Kit emphasizes…
Lightweight Vue UI library	Smaller surface area; admin-first components; subpath imports
Vue 3 component library with design tokens	Semantic tokens and themes, not scattered one-off colors
Nuxt 4 UI components	Documented CSS order, SSR-minded usage, explicit imports
Incremental migration from a legacy UI stack	Bridge + cookbook mindset: replace screens in phases, not one risky big bang
Best Vue UI framework (for your dashboard)	Predictable TypeScript APIs, `Gk*` prefix, changelog discipline—not the widest marketing-site catalog

So if your keywords are Vue component library, design system Vue, admin dashboard Vue 3, lightweight Vue components, or Nuxt 4 component kit, God Kit is meant to match that intent honestly: a complete enough design system for internal products, not a contest for the longest feature grid on npm.

Key features (SEO-friendly summary)

Vue 3 + TypeScript — Composition API components with exported types.
Design system that works — Tokens, themes (presets + registration), RTL-aware documentation.
Lightweight by design — Import from god-kit/vue/form, god-kit/vue/layout, and related subpaths instead of the whole barrel.
CLI for components — Scaffold files that follow project conventions (god-kit CLI).
Data-heavy UI — GkDataTable and patterns aligned with admin and data-dense screens, with migration-oriented docs in the repo.
Free and open source — MIT, issues and PRs on GitHub, docs at godkit.godplans.org.

Who should use God Kit?

Teams shipping internal admin or SaaS dashboards on Vue 3 or Nuxt 4
Engineers who want a Vue design system with governed tokens and component authoring docs
Projects that need a practical migration path from an older UI layer rather than a single frozen rewrite
Developers comparing best UI library for Vue for their use case—not only total download volume

Roadmap: UI builder and a growing ecosystem

We are actively working on a visual UI builder and continuing to improve documentation, components, and tooling so the Vue community has a simple, lightweight option that stays maintainable over time. Sponsors and feedback help prioritize Nuxt, a11y, data components, and developer experience—see the sponsors page and the roadmap in the docs.

Get started

Read Getting started and Why God Kit on the official site.
Install from npm: npm install god-kit (see the package page for the current version).
Star and watch god-plans/god-kit for releases and discussions.

Meta cheatsheet (for dev.to and Google)

Suggested title tag (≤ ~60 characters):

Why God Kit? Vue 3 UI Library, Design Tokens & Nuxt 4

Suggested meta description (≤ ~155 characters):

God Kit is a lightweight Vue 3 component library and design system for admin dashboards—design tokens, CLI, Nuxt 4, and incremental migration from legacy UI. Docs, npm, and GitHub links inside.

Primary keywords (use naturally in headings and first paragraphs):

Vue 3 UI library, Vue component library, design system Vue, lightweight Vue components, Nuxt 4 UI, admin dashboard Vue, design tokens CSS, Vue TypeScript components, open source UI kit

Secondary / long-tail:

Vue 3 component framework, scaffold Vue components CLI, tree-shaking Vue UI, migrate legacy Vue UI, accessibility Vue components, semantic CSS variables UI

This article reflects the God Kit project as published in the repo’s docs and package.json; versions and features evolve—check godkit.godplans.org and npm for the latest.