DEV Community: Gentrit Biba

Claude Code Is My Favorite Dev Tool — I Was Flying Blind Until I Found Cogpit

Gentrit Biba — Sun, 01 Mar 2026 14:58:07 +0000

I've been using Claude Code daily for months. It writes code, runs tests, manages git branches, spawns sub-agents — the whole deal. On a good day, I'll have multiple sessions running across different projects, background agents churning through tasks, and a team of sub-agents coordinating work.

The problem? All of this happens inside a terminal. A single, scrolling terminal.

You don't know how many tokens you've burned until you check the billing page. You can't see what a background agent decided to do three minutes ago without scrolling through walls of JSONL. And if you're running six agents in parallel? Good luck keeping track.

I started looking for something better. That's when I came across Cogpit.

What Cogpit Actually Is

Cogpit is a real-time dashboard that reads your Claude Code session files and turns them into something you can actually navigate. It's a desktop app (macOS and Linux) or a browser-based dev server — no API keys, no separate login. It uses your existing Claude CLI and reads the JSONL files that Claude Code already writes to ~/.claude/projects/.

You install it, open it, and immediately see every project and session you've ever run. Live sessions show up with status indicators — green for running, blue for tool use, amber for thinking. The kind of stuff that's invisible in a terminal.

The Session Timeline Changes Everything

This is where Cogpit clicked for me. Every session renders as a structured conversation timeline:

User messages and assistant responses with rendered Markdown and syntax highlighting
Thinking blocks — expandable, so you can see Claude's reasoning without it cluttering the view
Tool calls with color-coded badges — Read is blue, Write is green, Edit is amber, Bash is red. Each one expandable with full input/output
Edit diffs — actual line-by-line diffs with syntax highlighting, not raw JSON
Sub-agent activity — color-coded panels showing what each spawned agent is doing

There's also a full-text search that filters across everything — user messages, assistant text, thinking blocks, tool names, tool output. Case-insensitive, real-time.

When you scroll past a turn's prompt, a sticky header keeps showing it so you always know which turn you're reading. Small thing, massive quality-of-life improvement when you're debugging a 40-turn session.

Live Streaming and Chat

Cogpit connects to active sessions via Server-Sent Events. New turns appear as Claude works — no refreshing, no polling on your end. The UI coalesces rapid updates so it stays smooth even when the agent is making 10 tool calls in a row.

You can also send messages to running sessions directly from Cogpit. Pick a model override per message (Opus, Sonnet, Haiku), use slash commands with autocomplete, drag-and-drop images, or even use voice input powered by Whisper running locally in WASM. There's a plan approval bar when the agent enters plan mode, and a question bar when it asks for input.

Basically, I stopped switching back to the terminal.

Token Analytics and Cost Tracking

This one caught me off guard. Cogpit breaks down every session with:

Per-turn token usage — input, output, cache creation, cache read
Model-aware cost calculation across Opus, Sonnet, and Haiku
A visual bar chart of token usage per turn
Context window usage as a percentage with color coding (green to red)
API rate limit tracking — 5-hour and 7-day utilization with time-to-reset

I had a session that burned through $7.57 in 10 turns. Cogpit showed me exactly where: most of it was cache creation from large file reads in the early turns. Without this visibility, I would've kept repeating the same pattern.

Undo/Redo with Branching

This feature alone is worth the install. You can rewind any session to a previous turn, and Cogpit handles the branching:

Create branches from any point in the conversation
Switch between branches via an SVG graph visualization
File operations (Edit/Write) are reversed on undo and replayed on redo
Ghost turns show archived content with hover-to-redo

I've used this to backtrack when an agent went down a wrong path — instead of starting over, I just branch from the last good turn and try a different prompt.

Teams and Multi-Agent Workflows

If you use Claude Code's team features (multiple agents coordinating via shared task lists), Cogpit gives you a dedicated dashboard:

Member cards with status indicators
A kanban-style task board (pending, in-progress, completed)
Color-coded message timeline showing inter-agent communication
Jump directly to any team member's session

Running a team of agents without this is like managing a distributed team over text files. Cogpit makes it visual.

The Details That Add Up

A few smaller things that show this was built by someone who actually uses Claude Code daily:

MRU session switching — Ctrl+Tab cycles through recently used sessions, Firefox-style
Process monitor — lists all system-wide claude processes with PID, memory, and CPU usage; detects orphaned processes
Worktree management — list active worktrees, see dirty/clean status, create PRs directly, bulk cleanup stale ones
File changes panel — tracks every Edit and Write operation in a session with +/- line counts
Todo progress tracking — when Claude uses TodoWrite, Cogpit shows a sticky progress bar with completion percentage and currently active task
Three themes — dark (default), deep OLED, and light. The dark theme uses OKLCH color space with hue-matched shadows. Not just "dark gray background."
Network access — enable it in settings, set a password, and access Cogpit from your phone on the same LAN. Full functionality, not a stripped-down mobile view
Terminal integration — open a terminal at any session's working directory; auto-detects Ghostty, iTerm, Warp, Alacritty, kitty

Who Is This For

If you use Claude Code casually — one session at a time, quick questions — you probably don't need this. The terminal is fine.

But if you're running long sessions, spawning background agents, managing costs across multiple projects, or using team workflows — Cogpit fills a gap that the CLI simply doesn't cover. It's the difference between flying a plane with instruments and flying by feel.

Try It

Cogpit is free and open source. Desktop app for macOS and Linux, or run it in the browser:

cogpit.gentrit.dev

You need Claude Code installed — Cogpit reads your existing sessions, it doesn't replace anything. Install it, open it, and you'll immediately see every session you've ever run.

I write about dev tools and performance on my blog. If you found this useful, check it out.

Compiling C in Bun with TypeScript: Fast, Native, and Simple

Gentrit Biba — Sat, 25 Jan 2025 01:13:39 +0000

I used to think compiling C code with TypeScript would be complex. Thanks to Bun's FFI feature, it's surprisingly simple and blazingly fast. Here's how to do it:

Setup First: Avoid TypeScript Errors

Run bun init to initialize a project. This creates the scaffolding for TypeScript support:

bun init -y  # Skip prompts

Why Compile C in TypeScript?

Need C's raw performance in JavaScript? Bun v1.2's bun:ffi lets you compile C code directly in TypeScript. No WebAssembly sandboxes, no node-gyp builds—just native speed.

Hello World in TypeScript

Create hello.c:

#include <stdio.h>
void hello(const char* name) {
  printf("Hello %s from C!\n", name);
}

Write TypeScript (main.ts):

import { cc } from "bun:ffi";

// Type-safe FFI definition
const { symbols: { hello } } = cc({
  source: "./hello.c",
  symbols: {
    hello: {
      args: ["cstring"],
      returns: "void"
    }
  } as const,
});

// Create a CString from TypeScript string
const name = "World";
const cString = Buffer.from(name);

hello(cString); // Output: "Hello World from C!"

Run it:

bun run main.ts

Performance & Use Cases

Speed: ~6.26ns/call (2ns Bun overhead).

Practical uses:

Access system APIs (macOS Keychain, Windows Registry)
Optimize math-heavy logic (e.g., prime checks, video encoding)

Gotchas

TinyCC limitations: No GCC/Clang optimizations
Experimental: Thread safety and async callbacks are WIP
String encoding defaults to UTF-8

Quick Start

Install Bun and initialize:

curl -fsSL https://bun.sh/install | bash
bun init -y  # Critical for TypeScript support

Add the hello.c and main.ts examples.

Like this post? Share it or follow me on my blog for more guides.

References: Bun FFI Docs, Bun Blog.

Setting Up Jest Testing in Your Node.js Application: A Complete Guide

Gentrit Biba — Fri, 08 Nov 2024 00:55:34 +0000

Jest is a popular testing framework maintained by Facebook that makes it easy to write and run tests for JavaScript applications. This guide will walk you through setting up Jest in your Node.js project from scratch.

Prerequisites

Node.js installed on your system
An existing Node.js project or a new one

Step 1: Initialize Your Project

If you don't have an existing project, create a new directory and initialize it:

mkdir my-node-project
cd my-node-project
npm init -y

Step 2: Install Jest

Install Jest as a development dependency:

npm install --save-dev jest

Step 3: Configure Jest in package.json

Update your package.json to add Jest configuration and test script:

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch"
  },
  "jest": {
    "testEnvironment": "node",
    "coveragePathIgnorePatterns": [
      "/node_modules/"
    ],
    "moduleFileExtensions": ["js", "json"],
    "testMatch": ["**/__tests__/**/*.js", "**/?(*.)+(spec|test).js"],
    "verbose": true
  }
}

Step 4: Create a Sample Function to Test

Create a new file called math.js:

// math.js
function sum(a, b) {
  return a + b;
}

function multiply(a, b) {
  return a * b;
}

module.exports = {
  sum,
  multiply
};

Step 5: Write Your First Test

Create a test file called math.test.js:

// math.test.js
const { sum, multiply } = require('./math');

describe('Math functions', () => {
  test('adds 1 + 2 to equal 3', () => {
    expect(sum(1, 2)).toBe(3);
  });

  test('multiplies 3 * 4 to equal 12', () => {
    expect(multiply(3, 4)).toBe(12);
  });
});

Step 6: Additional Jest Configuration (Optional)

Create a jest.config.js file for more detailed configuration:

// jest.config.js
module.exports = {
  // Automatically clear mock calls and instances between every test
  clearMocks: true,

  // Indicates whether the coverage information should be collected while executing the test
  collectCoverage: true,

  // The directory where Jest should output its coverage files
  coverageDirectory: "coverage",

  // An array of regexp pattern strings used to skip coverage collection
  coveragePathIgnorePatterns: [
    "/node_modules/"
  ],

  // The test environment that will be used for testing
  testEnvironment: "node",

  // The glob patterns Jest uses to detect test files
  testMatch: [
    "**/__tests__/**/*.[jt]s?(x)",
    "**/?(*.)+(spec|test).[tj]s?(x)"
  ]
};

Step 7: Running Tests

You can now run your tests using npm:

# Run all tests
npm test

# Run tests in watch mode
npm run test:watch

# Run tests with coverage report
npm test -- --coverage

Common Jest Matchers

Here are some commonly used Jest matchers:

// Exact equality
expect(value).toBe(2);

// Object matching
expect(data).toEqual({id: 1});

// Truthiness
expect(value).toBeTruthy();
expect(value).toBeFalsy();

// Numbers
expect(value).toBeGreaterThan(3);
expect(value).toBeLessThan(5);

// Strings
expect(string).toMatch(/pattern/);

// Arrays
expect(array).toContain(item);

// Exceptions
expect(() => {
  throw new Error('Wrong!');
}).toThrow('Wrong!');

Testing Asynchronous Code

Jest handles async code testing gracefully:

// Testing Promises
test('async test', () => {
  return fetchData().then(data => {
    expect(data).toBe('data');
  });
});

// Using async/await
test('async test with async/await', async () => {
  const data = await fetchData();
  expect(data).toBe('data');
});

Best Practices

File Organization: Keep test files close to the code they're testing

   src/
     ├── math.js
     └── __tests__/
         └── math.test.js

Test Isolation: Each test should be independent and not rely on other tests
Meaningful Descriptions: Use clear test descriptions

   describe('User authentication', () => {
     test('should successfully log in with valid credentials', () => {
       // test code
     });
   });

Setup and Teardown: Use Jest's lifecycle methods when needed

   beforeAll(() => {
     // Setup before all tests
   });

   afterEach(() => {
     // Cleanup after each test
   });

Conclusion

You now have a fully configured Jest testing environment in your Node.js application. Remember to:

Write tests as you develop new features
Aim for high test coverage
Run tests frequently
Keep tests maintainable and readable

Your tests will help catch bugs early, serve as documentation, and make refactoring easier.

This was fun! I write about stuff like this all the time on my blog. Swing by if you're into coding, math puzzles, and that kind of thing: blog.gentrit.dev

PartyTown: Offloading Third-Party Scripts Away From the Main Thread 🚀

Gentrit Biba — Sun, 27 Oct 2024 21:11:43 +0000

We all love JavaScript libraries. They sprinkle magic onto our websites, adding interactivity, analytics, and a whole lot of pizazz. But let's face it, some of these libraries can be real party animals, hogging the main thread and leaving our website feeling sluggish. That's where PartyTown comes in – it's the bouncer that ensures these lively scripts have their own space to party without crashing the main event.

What is PartyTown?

PartyTown is a clever JavaScript library that allows you to relocate resource-intensive scripts into a web worker. Think of it as creating a separate room at your party where the loud music and enthusiastic dancers can let loose without disturbing those enjoying a quiet conversation in the main hall.

The Magic of DOM Access

Here's where PartyTown truly shines: even though these scripts are partying in their own thread (the web worker), they can still access and manipulate the DOM! PartyTown cleverly uses proxies and asynchronous communication to make this happen, ensuring your scripts can interact with your website as needed.

Why Use PartyTown?

Improved Performance: By offloading heavy scripts to a separate thread, you free up the main thread to focus on what matters most: rendering your website and responding to user interactions. This leads to a smoother, more responsive user experience.
Reduced Blocking: Third-party scripts can often block the main thread, delaying the rendering of your website. PartyTown helps prevent this by allowing these scripts to run in the background.
Simplified Development: You can use your favorite libraries without worrying about their impact on your website's performance.

How it Works (in a Nutshell):

PartyTown Setup: You include PartyTown's scripts on your website. These scripts set up the "party zone" (the web worker) and handle the communication between the main thread and the party thread.
Script Relocation: You tell PartyTown which scripts should be moved to the party zone. This is typically done through some configuration (which we've removed for simplicity here).
DOM Access Magic: When a script in the party zone needs to access or modify the DOM, PartyTown intercepts those requests and uses asynchronous communication to relay them to the main thread. This allows the scripts to interact with your website without directly blocking the main thread.

Setting Up the Party

Let's get this party started! This example will show you how to set up PartyTown on your Next.js website.

Step 1: Install PartyTown

You can install PartyTown via npm:

npm install partytown

Step 2: Import PartyTown

In your JavaScript file, import PartyTown:

import { Partytown } from "@builder.io/partytown/react";

Step 3: Add PartyTown Component

In your layout.tsx file, add the PartyTown component to the <head> tag:

<Head>
  <Partytown forward={["dataLayer.push"]} />
</Head>

Step 4: Relocate Your Scripts

In your <script> tag, add the type="text/partytown" attribute to scripts you want to offload to the party zone:

 <script type="text/partytown"  src="https://example.com/heavy-script.js"></script>

Here is an example of how you can use PartyTown to offload an inline script:

<script
  type="text/partytown"
  dangerouslySetInnerHTML={{
    __html: '/* Inline Script*/',
  }}
/>

Party On!

PartyTown makes it incredibly easy to improve your website's performance without sacrificing the functionality provided by your favorite JavaScript libraries. By giving those resource-intensive scripts their own space to party, you can ensure your website remains fast, responsive, and ready to impress.

This was fun! I write about stuff like this all the time on my blog. Swing by if you're into coding, math puzzles, and that kind of thing: blog.gentrit.dev

Understanding and Resolving npm Dependency Conflicts: A Developer's Guide

Gentrit Biba — Fri, 25 Oct 2024 21:52:51 +0000

The Problem

Have you ever encountered an error like this?

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found: package-a@2.0.0
npm ERR! node_modules/package-a
npm ERR!   package-a@"^2.0.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer package-a@"^1.0.0" from package-b@3.0.0
npm ERR! node_modules/package-b
npm ERR!   package-b@"^3.0.0" from the root project

This error occurs when there's a mismatch between package versions in your project. Let's understand why this happens and how to fix it.

Understanding Version Conflicts

Common Causes

Pre-release Versions: Using alpha, beta, or release candidate versions
Peer Dependencies: Package requirements for specific versions of other packages
Version Mismatches: Incompatible version ranges between different packages
Breaking Changes: Major version updates that introduce incompatibilities

Solutions and Best Practices

1. Use Stable Versions (Recommended)

The safest approach is to stick with stable versions:

{
  "dependencies": {
    "package-a": "^2.0.0",
    "package-b": "^3.0.0"
  }
}

Install using:

npm install package-a@2.0.0 package-b@3.0.0

2. Match Pre-release Versions

If you need to use pre-release versions, ensure they're compatible:

{
  "dependencies": {
    "package-a": "2.0.0-beta.1",
    "package-b": "3.0.0-beta.2"
  }
}

3. Override Dependency Checks

Using --legacy-peer-deps

npm install --legacy-peer-deps

This flag tells npm to ignore peer dependency conflicts and use a less strict version resolution algorithm.

Using --force

npm install --force

Forces npm to fetch remote resources even if a local copy exists.

⚠️ Warning: Both these approaches should be used cautiously as they might lead to runtime issues.

Best Practices for Dependency Management

Version Control
- Keep track of your dependencies in package.json
- Use package-lock.json for consistent installations
- Regularly update your dependencies
Version Specification
- Use exact versions for critical dependencies
- Use caret (^) for minor updates
- Use tilde (~) for patch updates
Pre-release Versions
- Avoid mixing stable and pre-release versions
- Test thoroughly when using pre-release versions
- Stay updated with release notes and breaking changes
Documentation
- Document any special version requirements
- Keep track of why specific versions are needed
- Document any workarounds used

Preventive Measures

Regular Updates

   npm outdated
   npm update

Dependency Audits

   npm audit
   npm audit fix

Clean Installations

   rm -rf node_modules
   rm package-lock.json
   npm install

Approaches to Resolving Dependency Conflicts

Stable Versions

When to Use: Production environments
Risk Level: Low

Matching Pre-release

When to Use: Development/Testing
Risk Level: Medium

--legacy-peer-deps

When to Use: Legacy projects
Risk Level: High

--force

When to Use: Last resort
Risk Level: Very High

Conclusion

Dependency conflicts are a common challenge in modern JavaScript development. While there are various ways to resolve these issues, it's important to understand the implications of each approach. Always prioritize stability and compatibility, especially in production environments.

Remember:

Start with stable versions
Match pre-release versions carefully
Use override flags as a last resort
Document your decisions
Keep your dependencies updated

By following these guidelines, you can maintain a healthy and stable dependency tree in your Node.js projects.

Additional Resources

This was fun! I write about stuff like this all the time on my blog. Swing by if you're into coding, math puzzles, and that kind of thing: blog.gentrit.dev

Delving into Gaussian Integers: Cracking Project Euler Problem 153

Gentrit Biba — Fri, 25 Oct 2024 21:52:14 +0000

Project Euler Problem 153 presents a fascinating challenge involving Gaussian Integers, complex numbers of the form a + bi where a and b are integers. The problem asks us to find the sum of all divisors with positive real parts for every integer up to a large limit (10^8). This requires a deep dive into number theory and clever optimization to arrive at an efficient solution.

Understanding the Problem

The core concept lies in identifying the divisors of a rational integer within the realm of Gaussian Integers. For instance, 5 has the following divisors with positive real parts: {1, 1 + 2i, 1 - 2i, 2 + i, 2 - i, 5}. The challenge is to compute the sum of these divisors for all integers up to 10^8.

Initial Approach and Optimization

A naive approach would involve iterating through all possible Gaussian Integers and checking for divisibility. However, this quickly becomes computationally infeasible for the given limit.

The optimized solution utilizes several key insights:

Exploiting Conjugates: If a + bi divides n, so does its conjugate a - bi. This allows us to consider only divisors with positive imaginary parts and double their contribution to the sum.
GCD Optimization: The greatest common divisor (GCD) is crucial. If gcd(a, b) != 1, the Gaussian Integer a + bi can be simplified, and its divisors are already accounted for by smaller integers.
Iterating Efficiently: Instead of brute-force checking, we iterate through possible values of a and b, ensuring a is always greater than or equal to b to avoid redundant calculations.
Mathematical Derivation: For a given a + bi, we can derive a formula to directly calculate the sum of its multiples that are less than or equal to the limit. This eliminates the need for further iterations.

Code Breakdown

Here's the JavaScript code that implements the optimized solution:

function customSeriesSum(a, b) {
  return a === b ? a + b : (a + b) * 2;
}

function gcd(a, b) {
  return !b ? a : gcd(b, a % b);
}

function calculateResult(limit) {
  let result = 0;
  const secondLimit = Math.floor(Math.sqrt(limit));

  for (let i = 1; i <= limit; i++) {
    result += Math.floor(limit / i) * i;
  }

  for (let real = 1; real <= secondLimit; real++) {
    for (let i = 1; i <= real; i++) {
      if (gcd(real, i) === 1) {
        const denominator = i * i + real * real;
        const value = customSeriesSum(real, i);
        let j = 1;
        while (denominator * j <= limit) {
          result += j * value * Math.floor(limit / (denominator * j));
          j++;
        }
      }
    }
  }

  return result;
}

const startTime = performance.now();
const limit = 10 ** 8;
const result = calculateResult(limit);
const endTime = performance.now();

console.log(result);
console.log(`Elapsed time: ${((endTime - startTime) / 1000).toFixed(2)} seconds`);

customSeriesSum(a, b): This function efficiently calculates the sum of a + bi and a - bi, accounting for the case where a = b.
gcd(a, b): A standard recursive function to compute the GCD.
Main Loop: The code iterates through possible values of a and b, checks for gcd(a, b) = 1, calculates the denominator (a^2 + b^2), and then uses the derived formula to directly sum the contributions of the corresponding Gaussian Integer and its multiples.

Performance Considerations

Even with optimizations, the code deals with a large limit. The use of efficient mathematical formulas and GCD calculations significantly reduces the runtime, making the solution feasible. In fact, executing this code takes approximately 2.96 seconds.

This was fun! I write about stuff like this all the time on my blog. Swing by if you're into coding, math puzzles, and that kind of thing: blog.gentrit.dev