DEV Community: Rishabh Kharyal

Building a Bit-Accurate Fused QKV + RoPE Kernel for Qwen 2.5 in Triton

Rishabh Kharyal — Thu, 23 Apr 2026 16:27:23 +0000

How to replace 10+ PyTorch operations with a single GPU kernel while keeping the output identical to the original model – down to the last decimal.

If you’ve ever profiled a small Transformer on a consumer GPU, you know the pain: every decode step launches a swarm of tiny kernels, and Python dispatch overhead eats away your token rate. The solution is kernel fusion – but getting it right, especially with Rotary Position Embeddings, isn’t trivial.

This post walks through triton_fused_attention_v3.py, a self‑contained Triton kernel that fuses QKV projection + RoPE + KV cache write into a single launch for Qwen 2.5‑0.5B. It delivers a 4.5–5× speedup while maintaining cosine similarity = 1.000000 against the reference HuggingFace output. No special hardware needed – this runs on an RTX 3050 laptop GPU.

We’ll cover:

Why the kernel exists

The two design rules that guarantee bit‑perfect output

A line‑by‑line walkthrough of the kernel

The benchmark setup that proves both speed and accuracy

Why Fuse? The Death‑by‑a‑Thousand‑Kernels Problem

Here’s what happens when you call a standard PyTorch attention block:
python

q = linear(hidden, W_q) # kernel launch 1
k = linear(hidden, W_k) # launch 2
v = linear(hidden, W_v) # launch 3
q, k = rope(q, k) # 2 more launches (reshape + complex op)

then KV cache write, SDPA, O projection...

For Qwen 2.5‑0.5B (24 layers), that’s 240 separate GPU kernel launches per token. Each launch costs ~80 µs of CPU–GPU handshaking – not much alone, but 240 × 80 µs = 19 ms of pure overhead. The RTX 3050 can theoretically process a token in under 6 ms; we were spending over 30 ms because the GPU sat idle waiting for work.

The fix is to pack as many of those operations as possible into one kernel. And that’s exactly what fused_qkv_rope_v3 does.
What the Kernel Does (In One Shot)

Inside a single Triton program we do:

Tiled matrix‑vector multiply against a concatenated weight matrix [W_q ; W_k ; W_v] → Q, K, V

Apply RoPE on the Q and K heads using the local accumulator (no separate store‑reload)

Write rotated K and V directly into the persistent KV cache

Write rotated Q into an output buffer

After that, only two more operations remain: the attention softmax (done with PyTorch’s scaled_dot_product_attention) and the output GEMV. The whole decode step collapses from 10+ kernels to just 3.

And we don’t stop there: the script captures all three into a CUDA Graph, so subsequent tokens are fired with a single graph.replay() – virtually zero dispatch overhead.
The Two Critical Design Rules

Fusing RoPE inside a projection kernel is where things get slippery. RoPE rotates pairs of elements (2k, 2k+1) within each attention head. If you break those pairs across thread blocks, or let the partner value get rounded to FP16, you introduce numerical drift. This kernel uses two clean rules to avoid that completely.
Rule 1: BLOCK_M = head_dim – Never Split a RoPE Pair

Qwen 2.5‑0.5B has a head dimension of 64. So we set:
python

BLOCK_M = hd # 64

This ensures that every Triton program instance processes one entire attention head (or one head‑sized chunk of V). All 32 RoPE pairs inside that head are adjacent in the same local accumulator – zero cross‑block reads.

The grid is simply M_total // BLOCK_M = 18 blocks, which maps beautifully onto the GPU’s SMs.
Rule 2: Use an FP32 Scratchpad for RoPE Partner Values

To compute a rotation for element 2k you need the partner value at 2k+1 (and vice versa). In Triton you can’t just index acc[i+1] directly – you have to shift the data. The naive approach stores the accumulator to an FP16 buffer and reloads a shifted version. That FP16 round‑trip adds a small error that grows with sequence length.

Instead, the kernel uses a tiny FP32 temporary buffer allocated before the kernel launch:
python

fp32_tmp = torch.empty(q_dim + k_dim, device='cuda', dtype=torch.float32)

Inside the kernel, after computing QKV values into the FP32 accumulator, we store them without rounding:
python

tl.store(fp32_tmp_ptr + rows, acc, mask=mask) # Full FP32

Then we compute the partner indices (even reads rows + 1, odd reads rows - 1) and load from that FP32 buffer:
python

partner_rows = tl.where(is_even, rows + 1, rows - 1)
partner = tl.load(fp32_tmp_ptr + partner_rows, mask=mask) # FP32 load

Now both acc and partner are in full precision for the rotation:
python

roped = tl.where(is_even,
acc * cos_val - partner * sin_val,
partner * sin_val + acc * cos_val)

Only the final rotated value is cast to FP16 when written to the output or KV cache. This eliminates the precision loss entirely.
A Walk Through the Kernel Launch Parameters

The kernel is annotated with @triton.jit and takes a long list of parameters, but here’s what matters:

W_ptr: The concatenated QKV weight matrix of shape (q_dim + k_dim + v_dim, d).

x_ptr: The input hidden state of size d.

b_ptr: Concatenated bias of the same shape as the output rows.

q_ptr, k_cache_ptr, v_cache_ptr: Output buffers for Q and the KV cache.

cos_ptr, sin_ptr: Pre‑computed RoPE frequencies for the current position.

fp32_tmp_ptr: The FP32 scratchpad used only for RoPE partner access.

M: Total number of Q+K+V rows (1152 for this model).

head_dim: 64. half_hd: 32.

BLOCK_M: Set to 64 (head‑aligned).

BLOCK_K: Tile size along the input dimension (128).

The kernel iterates over the input dimension in chunks of BLOCK_K, accumulating the dot‑product results into registers.

After the accumulation, it checks whether the current block of rows belongs to Q, K, or V, applies RoPE if needed, and writes to the appropriate destination. The code uses masks (is_q, is_k, is_v) to steer the output without branches that diverge heavily.
How the Script Benchmarks and Proves Correctness

The main block in the file runs a thorough comparison for four cache lengths: 64, 128, 256, 512. For each length it:

Runs a standard() function that implements the exact HuggingFace attention logic in pure PyTorch. It times this over 300 iterations after 30 warmup runs, reporting the median kernel time in milliseconds.

Runs triton_v3() in eager mode – the three separate kernel launches – and times it identically. It computes the speedup and, crucially, calculates the cosine similarity between the standard output and the Triton output. The result is 1.000000 at every tested length.

Captures a CUDA Graph with the same three operations. After a few warmup replays, it times 500 graph replays and reports the even lower latency.

A representative output snippet:
text

--- cache_len=64 ---
Standard PyTorch: 2.123ms
Triton V3 (eager): 0.468ms
Speedup: 4.54x | cos: 1.000000
Triton V3 + Graph: 0.393ms (5.40x)

The graph‑captured version consistently adds an extra 15–20% improvement over the eager mode, because it eliminates the remaining Python transitions between the three fused kernels.
Key Takeaways for Triton Developers

Tile alignment is a correctness concern, not just a performance one. Setting BLOCK_M = head_dim ensured RoPE pairs were never split, which was the foundation for bit‑perfect output.

A tiny FP32 buffer (a few KB) can save you from silent precision drift. When the correctness of a rotation depends on a partner value, don’t let that value pass through FP16 – keep it full precision until the final write.

CUDA Graphs amplify the benefit of fusion. After fusing from 10 kernels to 3, a graph capture removes the last bit of Python overhead, squeezing out every bit of memory bandwidth.

Try the Code Yourself

The file is self‑contained. Install the dependencies and run:
bash

pip install torch triton transformers
python triton_fused_attention_v3.py

It will download Qwen 2.5‑0.5B (if not already cached), print the model dimensions, and run the four‑length benchmark. No other setup needed.

The full repository – including a CuPy‑based Windows kernel and a batched throughput exploit – is on GitHub, but the script we’ve explored here is the beating heart: a clean demonstration of how to fuse attention with RoPE while preserving 100% of the reference model’s output.

Did you spot an optimisation I missed? Or have your own fused‑kernel war story? Drop a comment – I’d love to hear what the dev.to GPU community is building.

Skills03 / triton-fused-attention

I Built a 4.75 Faster Qwen 2.5 Engine for a $200 GPU – Here’s How

Rishabh Kharyal — Thu, 23 Apr 2026 16:10:58 +0000

My RTX 3050 laptop GPU was crawling at 30 tokens per second with Qwen 2.5‑0.5B. So I tore apart the attention block, wrote some custom Triton kernels, and got it to 140 tok/s – completely lossless. No paid APIs, no datacenter hardware required.

Local AI agents need sub‑second responses. When you hit 30 tok/s on a machine that can theoretically process one token in 5.88 ms, something is wrong. That was my starting point: Qwen 2.5‑0.5B, HuggingFace Transformers, an RTX 3050 6 GB laptop GPU – and terribly sluggish generation.

I didn’t want to sacrifice quality, quantise aggressively, or switch to a smaller model. So I dived into the GPU execution model, fused a pile of kernels, and ended up with a 4.75× lossless speedup. This post walks through exactly what I built and what every developer can learn from it.
The Baseline: Why HuggingFace Leaves Speed on the Table

A naive forward pass of a single Transformer attention block launches 10+ separate GPU kernels:
text

Q projection → K projection → V projection →
RoPE on Q → RoPE on K →
GQA expand → SDPA → reshape → O projection → residual add

For Qwen 2.5‑0.5B (24 layers), that’s over 240 kernel launches per token. Each launch wastes about 80 µs on Python‑side dispatch. Multiply that through 24 layers and you’re burning 13.4 ms per token just waiting for the GPU to start working.

The RTX 3050’s memory bandwidth (168 GB/s) sets a hard physics ceiling of 5.88 ms/token (170 tok/s). At 33 ms/token we were using only 18% of the hardware.

The fix is clear: fewer kernel launches. That’s exactly what this engine does.
The Tech: 3 Kernel Launches and a CUDA Graph

I wrote a single custom Triton kernel that replaces all the pre‑attention operations. Then I capture the whole decode step in a CUDA graph. The final pipeline is:
text

Fused QKV+RoPE+KV Cache (1 kernel)
→ SDPA (1 kernel)
→ O projection (1 kernel)

Everything else – residual adds, RMS normalisation, and the entire next‑token loop – happens inside the CUDA graph without Python ever regaining control.

Result: 140 tok/s, 4.75× the baseline, with exactly the same output as HuggingFace (cosine similarity = 1.000000).
How the Fused Kernel Works

The core is triton_fused_attention_v3.py. In one kernel we:

Load the input activation vector.

Perform tiled matrix‑vector multiplies to compute Q, K, and V simultaneously.

Apply Rotary Position Embedding (RoPE) inline – the kernel sees both elements of each RoPE pair.

Write K and V directly into the persistent KV cache.

Store Q ready for the attention softmax.

All intermediate values live in GPU registers and shared memory. No trips to global memory, no separate torch.roll, no torch.cat for KV cache updates.

The SDPA kernel is still off‑the‑shelf (PyTorch’s scaled_dot_product_attention), but because it’s launched directly from the graph with zero dispatch lag, the overhead is negligible.
Three Key Optimisations That Made It Lossless

Getting speed is one thing. Getting perfect numerical fidelity is harder.

Head‑Aligned Block Size (BLOCK_M = 64)

Qwen 2.5‑0.5B uses a head dimension of 64. RoPE rotates pairs of elements (2k, 2k+1). If our Triton block size didn’t align with 64, some pairs would be split across thread blocks, requiring cross‑block reads that introduce tiny errors.

Setting BLOCK_M = 64 guarantees that all RoPE pairs stay within a single block. This single tweak eliminated quality degradation at longer sequences.

FP32 RoPE Accumulation Buffer

The standard FP16 approach stores pre‑rotation values, reloads the partner, and applies the rotation. That store‑reload cycle in FP16 accumulates rounding error.

I introduced an FP32 temporary buffer: Q and K values are cast to FP32 before rotation, the rotation is computed in full precision, and only the final result is stored back as FP16. With this fix, cosine similarity hit 1.000000 at all sequence lengths (it had been 0.998 at L=512).

CUDA Graph Capture

Even with only 3 kernels per step, Python dispatch still adds latency. By capturing the entire decode loop (the sequence of 3 kernel launches) into a CUDA graph, we pay the dispatch cost only once. Subsequent tokens are submitted to the GPU with a single graph.replay(), effectively eliminating CPU‑GPU sync jitter.
Batched Mode: 211× Throughput (When You Have Many Prompts)

If you need to process many prompts at once, the engine also includes batched_inference.py. By batching 256 sequences together, the matrix‑vector multiplies (GEMV) become matrix‑matrix multiplies (GEMM), engaging the Tensor Cores. Model weights are loaded only once and reused across the whole batch.

On the same RTX 3050, aggregate throughput jumps to 2,659 tok/s – a 211× improvement over the single‑stream naive baseline. It’s not a continuous‑batching server, but it’s great for offline batch jobs.
Quick‑Start: Run It Yourself
bash

git clone https://github.com/Skills03/qwen-2.5-inference-engine
cd qwen-2.5-inference-engine
pip install torch triton transformers # Linux/WSL
python triton_fused_attention_v3.py

Windows users can use the CuPy path (fused_attn_block.py). No special hardware beyond an Ampere+ NVIDIA card with ≥6 GB VRAM.
How It Stacks Against vLLM

vLLM is a brilliant production‑grade serving engine with PagedAttention, continuous batching, and support for hundreds of models. On the same hardware, if you configure vLLM with FlashAttention and CUDA graphs, you might see 100–140 tok/s for this model. So does this custom engine beat it? Marginally, but not dramatically – the true win is the bit‑identical output and the educational value of a minimal, hackable codebase. For single‑user, local‑only use, this engine gives you an extra 10–20% latency reduction while staying dead simple.

If you need a multi‑user serving API, stick with vLLM. The two approaches are complementary, and in principle this fused kernel could even be plugged into vLLM’s custom‑attention backend.
What I Learned (And You Can Too)

Kernel launch overhead is the enemy on small models. The less work the GPU does per token, the more Python‑side dispatch dominates. Fuse ruthlessly.

Alignment matters for correctness, not just speed. A simple BLOCK_M = head_dim removed silent numerical errors.

Mixed precision isn’t free. An FP32 scratchpad gave back full fidelity with almost no performance cost.

Physics always wins. Our 140 tok/s is 73% of the memory‑bandwidth ceiling; the rest is irreducible compute and scheduling. That’s okay – you can only optimise so far.

The entire project is open‑source and ready to hack on. If you’ve got a budget GPU and a desire for snappy local AI, clone it and see how far you can push your own model. I’d love to hear what you build.

Skills03 / qwen-2.5-inference-engine

Qwen 2.5 Inference Engine

4.75x lossless inference speedup for Qwen-2.5 on RTX 3050 (6 GB VRAM).

Built so local AI agents get sub-1s response time on consumer GPUs instead of paid APIs.

Results

Method	tok/s	Speedup	Quality
HuggingFace baseline	30	1.0x	-
Triton fused + CUDA Graph	140	4.75x	cos=1.000000 (lossless)
Batched (batch=256)	2,659	211x throughput	lossless

Measured on RTX 3050 6GB Laptop GPU, Qwen2.5-0.5B, Nsight-verified.

What's Inside

qwen-engine/
  triton_fused_attention.py      # Triton fused QKV+RoPE+Attention kernel (WSL)
  triton_fused_attention_v3.py   # V3: head-aligned BLOCK_M=64 + FP32 RoPE fix
  fused_attn_block.py            # CuPy fused attention block (Windows)
  batched_inference.py           # 211x batched throughput benchmark
  benchmark.py                   # End-to-end lossless speed benchmark

Key Techniques

Triton Fused QKV+RoPE (4.75x lossless)

Fused QKV projection + RoPE + KV cache write in ONE Triton kernel
Replaces 10+ PyTorch operations with 3 kernel launches
CUDA Graph captures all 3 for zero Python dispatch overhead

Head-Aligned BLOCK_M = 64

RoPE pairs elements (2k…

View on GitHub

I Built a Desktop GUI for Claude Code in One Day — Here's How

Rishabh Kharyal — Thu, 15 Jan 2026 13:41:45 +0000

I Built a Desktop GUI for Claude Code in One Day — Here's How

Claude Code is amazing. But I got tired of the terminal.

So I built this:

raw.githubusercontent.com

TL;DR:

🚀 Run 3 AI tasks in parallel
📝 See live diffs before files change
💾 115MB portable — works offline
🖥️ Windows + Mac + Linux from one codebase

⬇️ Download | 📦 GitHub

💡 What I Learned (The Short Version)

Electron isn't dead — shipped to 3 platforms in 6 minutes
Zustand > Redux — for apps this size, simplicity wins
Ship broken, fix fast — users find bugs faster than you

Want the technical deep-dive? Keep reading. Want to try it? Download here.

🤔 The Problem: Terminal-Only AI

If you've used Claude Code, you know it's incredibly capable. It can read your codebase, write files, run commands, and reason about complex problems.

But it runs only in the terminal.

For quick tasks, that's fine. But when you're:

Running multiple AI tasks simultaneously
Reviewing file changes before approving them
Context-switching between different projects
Showing work to non-technical stakeholders

...the terminal becomes a bottleneck.

I wanted something that felt more like pair programming with a colleague than typing into a black box.

🛠️ The Solution: Claude Cowork

Claude Cowork is a desktop application that wraps the official Claude Agent SDK with:

Feature	What It Does
Parallel Task Queue	Run up to 3 AI tasks simultaneously
Live Diff Visualization	See file changes before they happen
Session Management	Persist conversations in SQLite
Plugin System	Auto-discover MCP servers and skills
Cross-Platform	Single codebase → Win/Mac/Linux installers

Let me walk you through how I built each piece.

🏗️ Architecture Overview

┌─────────────────────────────────────────────────────────┐
│                    Electron Main Process                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │
│  │ IPC Handler │  │ Session DB  │  │ Settings Manager│  │
│  │             │  │  (SQLite)   │  │  (MCP + Skills) │  │
│  └──────┬──────┘  └──────┬──────┘  └────────┬────────┘  │
│         │                │                   │           │
│         └────────────────┼───────────────────┘           │
│                          │                               │
│              ┌───────────▼───────────┐                   │
│              │  Claude Agent SDK     │                   │
│              │  (Task Runner)        │                   │
│              └───────────────────────┘                   │
└─────────────────────────────────────────────────────────┘
                           │
                           │ IPC Bridge
                           ▼
┌─────────────────────────────────────────────────────────┐
│                   React 19 Frontend                      │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌─────────┐  │
│  │ Sidebar  │  │ Chat View│  │ Progress │  │Settings │  │
│  │          │  │ + Diffs  │  │  Panel   │  │  Modal  │  │
│  └──────────┘  └──────────┘  └──────────┘  └─────────┘  │
│                                                          │
│                    Zustand Store                         │
└─────────────────────────────────────────────────────────┘

Tech Stack:

Electron 39 — Cross-platform desktop framework
React 19 — UI with latest features (Suspense, transitions)
Zustand — Lightweight state management
better-sqlite3 — Session persistence
@anthropic-ai/claude-agent-sdk — The AI brain

⚡ Deep Dive #1: Parallel Task Queue

The killer feature. Most AI coding tools process one request at a time. Claude Cowork can handle three.

The Problem

Claude Agent SDK runs tasks synchronously. If you start a task, you wait until it completes.

The Solution

I implemented a task queue manager that:

Accepts unlimited tasks into a queue
Runs up to MAX_CONCURRENT_TASKS (3) simultaneously
Broadcasts status updates via IPC

// src/electron/ipc-handlers.ts

const MAX_CONCURRENT_TASKS = 3;
const taskQueue: QueuedTask[] = [];
const runningTasks = new Map<string, { task: QueuedTask; sessionId: string }>();

async function processTaskQueue() {
  while (runningTasks.size < MAX_CONCURRENT_TASKS) {
    const nextTask = taskQueue.find(t => t.status === "queued");
    if (!nextTask) break;

    // Start task in background
    nextTask.status = "running";
    nextTask.startedAt = Date.now();

    const session = await createSession(nextTask.cwd);
    runningTasks.set(nextTask.id, { task: nextTask, sessionId: session.id });

    // Run Claude (non-blocking)
    runClaude({
      sessionId: session.id,
      prompt: nextTask.prompt,
      cwd: nextTask.cwd,
      onEvent: (event) => broadcast(event)
    }).then(() => {
      completeTask(nextTask.id);
      processTaskQueue(); // Check for more tasks
    });
  }
}

The UI

Users see a collapsible panel showing:

🟢 Running tasks (with stop button)
🟡 Queued tasks (with cancel button)
Toast notifications when tasks complete

// TaskQueuePanel.tsx
<div className="task-queue-panel">
  {runningTasks.map(task => (
    <div key={task.id} className="task-item running">
      <span className="pulse-dot" />
      <span>{task.prompt.slice(0, 40)}...</span>
      <button onClick={() => cancelTask(task.id)}>Stop</button>
    </div>
  ))}
</div>

Result: Queue "write tests for auth module", "update README", and "fix TypeScript errors" — they all run in parallel.

📝 Deep Dive #2: Live Diff Visualization

When Claude edits a file, you should see exactly what changed before it happens.

The Implementation

I intercept Edit and Write tool calls and render inline diffs:

// EventCard.tsx

function DiffView({ oldContent, newContent, filePath }: DiffProps) {
  const changes = diffLines(oldContent, newContent);

  return (
    <div className="diff-container">
      <div className="diff-header">
        <span className="file-icon">📄</span>
        <span className="file-path">{filePath}</span>
      </div>
      <pre className="diff-content">
        {changes.map((change, i) => (
          <span
            key={i}
            className={
              change.added ? 'diff-added' :
              change.removed ? 'diff-removed' :
              'diff-unchanged'
            }
          >
            {change.value}
          </span>
        ))}
      </pre>
    </div>
  );
}

Before vs After

Terminal (Claude Code):

Editing src/utils.ts...
Done.

Claude Cowork:

// src/utils.ts
  export function formatDate(date: Date) {
-   return date.toString();
+   return date.toISOString().split('T')[0];
  }

You see the change, approve it, and move on. No guessing.

🔌 Deep Dive #3: Plugin System (MCP + Skills)

Claude Cowork auto-discovers capabilities from two sources:

1. MCP Servers

Model Context Protocol servers extend Claude's abilities. I built a settings manager that:

// settings-manager.ts

const BUILT_IN_MCP_SERVERS: MCPServer[] = [
  {
    id: "filesystem",
    name: "Filesystem",
    description: "Read and write files",
    enabled: true,
    builtIn: true,
    config: { command: "npx", args: ["-y", "@anthropic-ai/mcp-filesystem"] }
  },
  {
    id: "fetch",
    name: "Web Fetch",
    description: "Fetch URLs and web content",
    enabled: false,
    builtIn: true,
    config: { command: "npx", args: ["-y", "@anthropic-ai/mcp-fetch"] }
  }
];

// Also loads external servers from ~/.claude/settings.json

2. Skills Auto-Discovery

Skills are markdown files with instructions. Claude Cowork scans ~/.claude/skills/ and presents them in the settings modal:

function discoverSkills(): SkillInfo[] {
  const skillsDir = join(homedir(), ".claude", "skills");
  const skills: SkillInfo[] = [];

  for (const folder of readdirSync(skillsDir)) {
    const skillPath = join(skillsDir, folder, "SKILL.md");
    if (existsSync(skillPath)) {
      const content = readFileSync(skillPath, "utf-8");
      const { name, description, triggers } = parseSkillFrontmatter(content);
      skills.push({ id: folder, name, description, triggers, enabled: true });
    }
  }

  return skills;
}

Result: Install any Claude Code skill → it automatically appears in Claude Cowork.

🚀 Deep Dive #4: Cross-Platform CI/CD

One codebase should produce installers for all platforms. Here's my GitHub Actions workflow:

# .github/workflows/build.yml

name: Build & Release

on:
  push:
    tags: ['v*']

jobs:
  build:
    strategy:
      matrix:
        include:
          - os: windows-latest
            platform: win
          - os: macos-latest
            platform: mac
          - os: ubuntu-latest
            platform: linux

    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci
      - run: npm run dist:${{ matrix.platform }}

      - uses: actions/upload-artifact@v4
        with:
          name: claude-cowork-${{ matrix.platform }}
          path: |
            release/*.exe
            release/*.dmg
            release/*.AppImage
            release/*.deb

Push a tag → Get installers for 3 platforms in ~6 minutes.

Output Sizes

Platform	Format	Size
Windows	NSIS Installer	129 MB
Windows	Portable EXE	115 MB
macOS	DMG	147 MB
Linux	AppImage	131 MB
Linux	.deb	89 MB

🐛 Challenges & Solutions

Challenge 1: Native Modules on Windows

better-sqlite3 requires native compilation. electron-builder handles this, but I hit symlink permission errors on Windows.

Solution: Add signAndEditExecutable: false to skip code signing during development.

Challenge 2: State Sync Between Processes

Electron has two processes (main + renderer). They need to stay in sync.

Solution: Zustand store in renderer + IPC event broadcasting from main:

// Main process
function broadcast(event: ServerEvent) {
  BrowserWindow.getAllWindows().forEach(win => {
    win.webContents.send("server-event", event);
  });
}

// Renderer process
useEffect(() => {
  window.electron.onServerEvent((event) => {
    handleServerEvent(event); // Updates Zustand store
  });
}, []);

Challenge 3: Stopping Running Tasks

Claude Agent SDK doesn't expose a clean abort mechanism.

Solution: AbortController pattern:

export async function runClaude(options: RunOptions): Promise<RunnerHandle> {
  const abortController = new AbortController();

  // Pass signal to SDK (if supported) or handle manually
  const promise = claude.run({
    ...options,
    signal: abortController.signal
  });

  return {
    promise,
    abort: () => abortController.abort()
  };
}

🎓 What I Learned

Electron is still viable — Despite the "Electron bad" memes, it ships fast and works everywhere.
React 19 is nice — Suspense boundaries and transitions make async UI smoother.
Zustand > Redux — For apps this size, Zustand's simplicity wins.
CI/CD is table stakes — Automated builds save hours and catch platform-specific bugs early.
Ship early — The first version had bugs. Users found them faster than I would have.

🔮 What's Next

[ ] GUI settings for API keys — Remove dependency on Claude Code CLI
[ ] Multi-agent orchestration — Spawn specialized agents for different tasks
[ ] Git integration — Auto-commit checkpoints during long tasks
[ ] Project memory — Remember context across sessions

🎮 Try It Yourself

Download: GitHub Releases

Requirements:

Claude Code installed and authenticated
Node.js 18+ (for development)

Run from source:

git clone https://github.com/Skills03/Claude-Cowork.git
cd Claude-Cowork
npm install
npm run dev

💭 Final Thoughts

Claude Code changed how I write software. Claude Cowork makes that experience visual, parallel, and shareable.

If you're building AI-powered developer tools, the playbook is:

Wrap existing SDKs (don't reinvent)
Add the UX layer users actually need
Ship cross-platform from day one
Open source everything

The best tools feel like extensions of your brain. That's what I'm building toward.

Thanks for reading! If you found this useful:

Star the repo on GitHub
Follow me on LinkedIn for more builds
DM me if you want to collaborate

Built with Claude Code + Claude Cowork (yes, recursively) 🔄

DEV Community: Rishabh Kharyal

Building a Bit-Accurate Fused QKV + RoPE Kernel for Qwen 2.5 in Triton

then KV cache write, SDPA, O projection...

Skills03 / triton-fused-attention

I Built a 4.75 Faster Qwen 2.5 Engine for a $200 GPU – Here’s How

Skills03 / qwen-2.5-inference-engine

Qwen 2.5 Inference Engine

Results

What's Inside

Key Techniques

Triton Fused QKV+RoPE (4.75x lossless)

Head-Aligned BLOCK_M = 64

I Built a Desktop GUI for Claude Code in One Day — Here's How

I Built a Desktop GUI for Claude Code in One Day — Here's How

💡 What I Learned (The Short Version)

🤔 The Problem: Terminal-Only AI

🛠️ The Solution: Claude Cowork

🏗️ Architecture Overview

⚡ Deep Dive #1: Parallel Task Queue

The Problem

The Solution

The UI

📝 Deep Dive #2: Live Diff Visualization

The Implementation

Before vs After

🔌 Deep Dive #3: Plugin System (MCP + Skills)

1. MCP Servers

2. Skills Auto-Discovery

🚀 Deep Dive #4: Cross-Platform CI/CD

Output Sizes

🐛 Challenges & Solutions

Challenge 1: Native Modules on Windows

Challenge 2: State Sync Between Processes

Challenge 3: Stopping Running Tasks

🎓 What I Learned

🔮 What's Next

🎮 Try It Yourself

💭 Final Thoughts

Building a Bit-Accurate Fused QKV + RoPE Kernel for Qwen 2.5 in Triton

I Built a 4.75 Faster Qwen 2.5 Engine for a $200 GPU – Here’s How