DEV Community: Rodion Kazennov

Where a code graph pays off: big repositories, small models

Rodion Kazennov — Thu, 01 Oct 2026 14:53:18 +0000

My last benchmark said a code graph did not make my coding agent cheaper. It was too small to say more than that: 24 questions, nothing bigger than 25k graph nodes, no Opus. So I ran it again at a size where the answer could change, and wrote the plan down first. The hypotheses, repositories, budget and analysis are in PLAN-v2.md, committed before any run.

The short version: a graph pays when the model would otherwise keep searching. Haiku on kubernetes and vscode is that case. Sonnet saves a little there and opus nothing, and on a small repository the graph costs sonnet more than plain grep.

The setup

The agent is GitHub Copilot CLI 1.0.90, run headless, one question per session, with two arms:

grep: Copilot's view, grep and glob tools and nothing else;
graph: the same three tools, plus cbm-lean (my thin wrapper around codebase-memory-mcp 0.9.0) and a routing rule at the top of the prompt: the graph for callers, callees and call chains, grep for exact strings.

Four public repositories, each pinned to a commit:

repository	language	graph nodes
full-stack-fastapi-template	Python, TypeScript	1,601
dub	TypeScript	25,023
kubernetes	Go	146,421
vscode	TypeScript	218,883

Each repository has 16 questions. Eight are structural: who calls a function, what it calls, the call path from a CLI command or an HTTP handler down to a named function, and which functions break if a signature changes. Eight are exact: a config value, where an environment variable is read, the line an error is raised on, the line a type is defined on. I checked every answer key by hand at the pinned commit, and an entry counts only as a whole word, so init_db does not pass for init.

Haiku 4.5 answered all 64 questions three times in each arm, and sonnet 5 twice. Opus 5.5 costs 15 premium requests a prompt in Copilot, so it answered twelve structural questions from kubernetes and vscode once. That is 664 runs and about 744 premium requests.

Cost is tokenEquiv, as in the first note: uncached input, plus 1.25 × cache writes, plus 0.1 × cache reads, summed over the model calls of a run.

Results

The graph's cost as a share of grep's: for each question the graph arm's median over repetitions divided by the grep arm's, then the median over questions, with a 95% bootstrap interval. Below 1 the graph is cheaper.

model	repository size	structural	exact
haiku 4.5	small (1.6k nodes)	0.88 (0.65–1.29)	0.92 (0.72–1.15)
haiku 4.5	medium (25k)	0.61 (0.11–1.50)	0.96 (0.75–1.37)
haiku 4.5	large (146k, 219k)	0.29 (0.11–0.70)	1.01 (0.94–1.28)
sonnet 5	small	1.51 (1.45–1.70)	1.42 (1.20–1.71)
sonnet 5	medium	0.94 (0.57–2.00)	1.14 (1.05–1.30)
sonnet 5	large	0.74 (0.62–0.92)	1.13 (1.01–1.29)
opus 5.5	large	0.97 (0.72–1.10)	–

Correct answers on the structural questions, graph against grep:

model	small	medium	large
haiku 4.5	13/24 against 19/24	20/24 against 22/24	38/47 against 33/48
sonnet 5	13/16 against 15/16	16/16 against 16/16	32/32 against 28/32
opus 5.5	–	–	12/12 against 12/12

Cost and accuracy together, as tokenEquiv per correct answer on the structural questions:

What holds up:

On kubernetes and vscode, haiku with the graph spent 0.29 of what it spent with grep on structural questions and was cheaper on 15 of 16 of them. It was also right more often, so per correct answer the gap is 47k against 209k tokenEquiv. This is the only result that survives the Holm correction across the 13 tests (p = 0.006).
Sonnet on the same questions: 0.74, cheaper on 12 of 16, and 32 of 32 correct against 28 of 32. Opus: 0.97, cheaper on 7 of 12, and every answer right in both arms.
On the small repository the graph never paid. Haiku spent about the same and got structural questions wrong more often. Sonnet spent 42 to 51% more.
On exact questions the graph made no measurable difference for haiku, and sonnet paid 13 to 42% more for it.
The graph's tool schemas and the routing rule add a fixed 1.56k prompt tokens to every model call for haiku and 2.07k for sonnet and opus, at every repository size.

Why the small model gains most

Count the model calls. With grep, haiku needed a median of 22 calls per structural answer on kubernetes and 20 on vscode, and one impact question took 114. With the graph it needed 5 and 4. Every call sends the conversation again, so a long search costs far more than its call count suggests: haiku's most expensive grep answer came to 471k tokenEquiv.

Sonnet's searches with grep were shorter, 8 calls against 4 with the graph. Opus took 4 or 5 calls either way, so the graph had nothing to cut, and its fixed overhead ate what little it saved.

My guess, which I did not test directly: a graph replaces search turns, so it pays when the model would otherwise take many of them, which means a weaker model on a larger repository. A strong model already searches efficiently with grep, and on a small repository nobody needs many turns.

Copilot bills premium requests per prompt, whatever the number of calls, so inside Copilot the graph saves no money. It saves time: haiku's structural answers on the large repositories took a median of 71 s with the graph and 157 s with grep. On the small repository the graph arm was slower.

Where each arm went wrong

A field called lines. Asked on which line HorizontalController is defined, the graph arm answered horizontal.go:43 in all five runs, haiku and sonnet alike. The struct starts on line 93 and is 43 lines long. The snippet that codebase-memory-mcp returns carries "start_line": 93, "end_line": 135 and "lines": 43, and the models read the last one as the line number. It happened again with LemonSqueezyClient (client.ts:129 for a class on line 59 that is 129 lines long), and haiku did the same with CursorsController. My first note blamed "line numbers from the graph" for that client.ts:129; this is where it came from. Sonnet with grep got all three right. cbm-lean now passes the field on as line_count.
Holes in the graph, trusted. codebase-memory-mcp 0.9.0 records no call edge for a bare call to a function imported with from x import y. Asked what recover_password calls, the graph arm answered "only get_user_by_email" in all five runs, haiku and sonnet alike, straight from the graph and without a single grep. The function also calls generate_password_reset_token, generate_reset_password_email and send_email, and the grep arm found all four every time.
A missing dash. Copilot's grep tool shows line numbers only when it gets "-n": true, and its view tool returns a file without them. Sonnet passed -n in 508 of its 571 grep calls and opus in all 53. Haiku passed n, without the dash, 920 times and -n 22 times out of 1,949. The tool ignores the unknown key, so haiku got no numbers, counted lines in the viewed file and missed by a few: for an error raised on line 112 it answered 105, 107, 108 and 113. All but one of haiku's 79 wrong answers to exact questions are a wrong line number.
Long searches that still fail. On the call chain from kubeadm token create down to encodeTokenSecretData, haiku with grep took 18 to 22 calls and got the path wrong all three times. It was wrong with the graph too. Sonnet was right in both arms.
Haiku tried to call bash three times in the grep arm. Copilot refused, since the tool does not exist there, so no run used a tool outside its arm.

What changed since the first note

The first note said not to expect token savings from a graph with Claude models on repositories up to 25k nodes. That still holds at those sizes. It missed what happens above them: on kubernetes and vscode the smaller models gain, and the smaller the model, the more.

What I would tell a team wiring a graph into an agent

Measure on your largest repository with your cheapest model first. That is where a graph earns its place.
With a strong model on a small or medium repository, leave it out. You pay for its schemas on every call and get nothing back.
Keep routing exact questions to grep. The graph never won them.
Do not let the model take line numbers or "this is the complete list" from graph output on trust. Drop or rename fields like lines before they reach the model.

Limits

One agent harness (Copilot CLI) and one graph (codebase-memory-mcp 0.9.0 behind my wrapper). Claude Code, another graph or a newer version could give other numbers.
Eight questions per cell on the small and medium repositories. With 13 tests under the Holm correction, a cell of eight cannot reach significance even if the graph wins every question, so only the large-repository haiku result is significant.
Opus answered twelve questions, once each.
tokenEquiv leaves output tokens out. Counting them would widen haiku's gap on the large repositories: its grep answers there produced a median of 7.0k output tokens against 0.9k with the graph.
One haiku run failed before Copilot opened a session and is left out. Three sonnet runs failed to fetch Copilot's model list before any model call and were run again. Both are recorded in the plan.

Reproduce

Everything is in code-graph-vs-grep: the plan written before the runs, the questions with the evidence for every answer key, the driver, all 664 runs with their answers, and the analysis.

node bench/run-copilot.mjs --model claude-haiku-4.5 --reps 3 --out results/v2/claude-haiku-4.5.json
python3 bench/stats-v2.py results/v2/*.json

Japan Life Hub: Net Salary Calculator & Housing Guide

Rodion Kazennov — Thu, 04 Dec 2025 00:00:00 +0000

Just shipped two new features for Japan Life Hub — a Net Salary Calculator with 2025 tax rates and a comprehensive Housing Guide. Both available in English, Japanese, Russian, and Hindi.

This article covers:

Why Year 1 vs Year 2 salary matters
2025 Japanese tax rates and deductions
Apartment rental costs breakdown
Key terminology for foreigners
Lessons learned building multilingual tools

The Year 1 Salary Trap

When I moved to Japan, my first paycheck was surprisingly high. Then Year 2 hit.

The catch: Japan's resident tax (住民税 juuminzei) is calculated on previous year's income and collected the following year. Your first year in Japan? Zero resident tax. Year 2? Roughly 10% of your gross salary disappears.

Nobody told me this. I built the calculator I wish I had.

Net Salary Calculator

The calculator shows both Year 1 and Year 2 take-home pay side by side.

2025 Tax Rates

Spent a day researching current rates from official sources. Here's what's deducted from your salary:

Social Insurance (Employee Share):

Item	Rate	Notes
Health Insurance	4.955%	Tokyo rate, March 2025
Long-term Care	0.795%	Ages 40-64 only
Pension	9.15%	Capped at ¥650k/month
Employment Insurance	0.55%	April 2025 update

Income Tax: Progressive 5-45% across 7 brackets, plus 2.1% reconstruction surcharge until 2037.

Resident Tax: ~10% (6% prefectural + 4% municipal), delayed one year.

Calculator Features

Employment type toggle: Employee vs Self-employed (different deductions)
Age selector: Long-term care insurance kicks in at 40
Dependents & spouse: Affects deductions for employees
Visual breakdown bar: See where your money goes
Salary presets: Junior ¥3M, Mid ¥5M, Senior ¥7M, Manager ¥10M
Share button: Copy summary to clipboard

The "What You Get Back" section explains what you're paying for — 70% healthcare coverage, pension from 65, unemployment benefits. Japanese social insurance is actually good value.

Housing Guide

Finding an apartment in Japan as a foreigner is confusing. Unique fees, guarantor requirements, Japanese-only listings.

The guide covers the entire process in 8 sections.

Key Terminology

Japanese rental vocabulary that confused me:

Japanese	Romaji	Meaning
敷金	shikikin	Deposit, 1-2 months, refundable
礼金	reikin	"Key money" gift to landlord, 0-2 months, gone forever
管理費	kanrihi	Monthly maintenance fee, ¥3,000-15,000
更新料	koushinryo	Renewal fee, ~1 month every 2 years
保証会社	hoshougaisha	Guarantor company, 30-100% of 1 month

Good news: less than 50% of renters now pay key money. Look for 礼金なし (reikin nashi) listings.

Initial Costs Example

For ¥80,000/month rent:

Cost	Amount	Refundable
First month rent	¥80,000	No
Deposit	¥80,000	Yes
Key money	¥80,000	No
Agency fee	¥88,000	No
Guarantor	¥40,000-80,000	No
Insurance	¥15,000	No
Lock change	¥15,000	No
Total	¥398,000-438,000

That's 5-6x monthly rent upfront. Budget accordingly.

Where to Search

The Housing Guide covers all major platforms — from Japanese-only sites like SUUMO with the largest listings, to English-friendly options like Real Estate Japan and GaijinPot, plus government UR Housing with no key money or guarantor requirements.

Pro tip: UR Housing has no reikin, no guarantor requirement, no renewal fees. Limited availability but worth checking.

Timing Matters

Avoid March-April. Everyone moves — new graduates, company transfers. Prices spike, competition fierce.

Best time: May-February. More negotiation room, landlords eager to fill vacant units.

What's Next

Japan Life Hub now has:

Initial Costs Calculator
Net Salary Calculator
Moving to Japan Guide
Housing Guide

Coming soon: Monthly Budget Planner, City Comparison Tool, First Year Timeline.

The goal is one place for everything you need to know about living in Japan — practical tools, not generic advice.

Try It

Built with Next.js, TypeScript, Tailwind CSS. All calculations run client-side, no data collected.

If you're moving to Japan or know someone who is — share the link.

Read on AllKeep →

Build a Chrome Extension with React, TypeScript and Vite

Rodion Kazennov — Wed, 03 Dec 2025 12:13:19 +0000

This article walks through building a Chrome extension from scratch using React, TypeScript and Vite. We'll build a Freelance Rate Calculator that helps developers check their market rate.

This article includes:

Setup React + Vite + TypeScript project for Chrome Extension
Configure manifest.json for Manifest V3
Build calculator UI with Tailwind CSS
Load and test extension locally
Submit to Chrome Web Store

Setup Project

Create new Vite project with React and TypeScript:

npm create vite@latest rate-calculator -- --template react-ts
cd rate-calculator
npm install

Add Tailwind CSS:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Configure tailwind.config.js:

/** @type {import('tailwindcss').Config} */
export default {
  content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
};

Add Tailwind directives to src/index.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

Add Lucide icons:

npm install lucide-react

Add Manifest V3

Create public/manifest.json:

{
  "manifest_version": 3,
  "name": "Freelance Rate Calculator",
  "version": "1.0.0",
  "description": "Calculate your freelance rate based on tech stack, experience, and location",
  "action": {
    "default_popup": "index.html",
    "default_icon": {
      "16": "icons/icon16.png",
      "48": "icons/icon48.png",
      "128": "icons/icon128.png"
    }
  },
  "icons": {
    "16": "icons/icon16.png",
    "48": "icons/icon48.png",
    "128": "icons/icon128.png"
  }
}

Create public/icons/ folder and add extension icons in 16x16, 48x48, and 128x128 sizes.

Add Rate Data

Create src/data/rates.ts with tech stacks, experience levels, and locations:

export interface TechStack {
  id: string;
  name: string;
  baseRate: number;
  demand: "high" | "medium" | "low";
}

export interface ExperienceLevel {
  id: string;
  name: string;
  years: string;
  multiplier: number;
}

export interface Location {
  id: string;
  name: string;
  multiplier: number;
}

export const techStacks: TechStack[] = [
  { id: "genai", name: "GenAI / LLM", baseRate: 175, demand: "high" },
  { id: "rust", name: "Rust", baseRate: 135, demand: "high" },
  { id: "react", name: "React", baseRate: 90, demand: "high" },
  { id: "typescript", name: "TypeScript", baseRate: 92, demand: "high" },
  { id: "nodejs", name: "Node.js", baseRate: 85, demand: "high" },
  { id: "python", name: "Python", baseRate: 90, demand: "high" },
  // add more stacks...
];

export const experienceLevels: ExperienceLevel[] = [
  { id: "junior", name: "Junior", years: "0-2 years", multiplier: 0.55 },
  { id: "mid", name: "Mid-level", years: "3-5 years", multiplier: 1.0 },
  { id: "senior", name: "Senior", years: "5-8 years", multiplier: 1.45 },
  { id: "lead", name: "Lead / Architect", years: "8+ years", multiplier: 1.85 },
];

export const locations: Location[] = [
  { id: "usa", name: "United States", multiplier: 1.0 },
  { id: "uk", name: "United Kingdom", multiplier: 0.85 },
  { id: "germany", name: "Germany", multiplier: 0.82 },
  { id: "japan", name: "Japan", multiplier: 0.62 },
  { id: "india", name: "India", multiplier: 0.32 },
  // add more countries...
];

Rate calculation formula:

const getMarketRate = (
  stack: TechStack,
  exp: ExperienceLevel,
  loc: Location
) => {
  const base = stack.baseRate * exp.multiplier * loc.multiplier;
  return {
    low: Math.round(base * 0.85),
    mid: Math.round(base),
    high: Math.round(base * 1.15),
  };
};

Example: Senior React developer in Germany = 90 * 1.45 * 0.82 = $107/hr

Build Calculator UI

Update src/App.tsx with calculator form:

import { useState } from "react";
import { techStacks, experienceLevels, locations } from "./data/rates";
import type { TechStack, ExperienceLevel, Location } from "./data/rates";

function App() {
  const [stack, setStack] = useState<TechStack | null>(null);
  const [experience, setExperience] = useState<ExperienceLevel | null>(null);
  const [location, setLocation] = useState<Location | null>(null);
  const [myRate, setMyRate] = useState("");
  const [showResult, setShowResult] = useState(false);

  const getMarketRate = () => {
    if (!stack || !experience || !location) return null;
    const base = stack.baseRate * experience.multiplier * location.multiplier;
    return {
      low: Math.round(base * 0.85),
      mid: Math.round(base),
      high: Math.round(base * 1.15),
    };
  };

  const handleCheck = () => {
    if (stack && experience && location && myRate) {
      setShowResult(true);
    }
  };

  // render form or results based on showResult state
  return (
    <div className="w-[400px] h-[600px] p-4 bg-gray-900 text-white">
      {/* form inputs and results */}
    </div>
  );
}

export default App;

Set fixed popup dimensions in src/index.css:

body {
  width: 400px;
  height: 600px;
  margin: 0;
  overflow: hidden;
}

Input form with dropdowns for stack, experience, location:

Results screen showing market rate comparison:

Build Extension

Update vite.config.ts for extension build:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: "dist",
    rollupOptions: {
      input: "index.html",
    },
  },
});

Build the extension:

npm run build

This creates dist/ folder with your extension files.

Load Extension Locally

Open Chrome and navigate to chrome://extensions. Enable "Developer mode" in top right corner.

Click "Load unpacked" and select the dist/ folder.

Click the extension icon in toolbar to test the popup.

Submit to Chrome Web Store

Go to Chrome Web Store Developer Dashboard.

First time requires $5 one-time developer fee.

Prepare assets:

Extension icon: 128x128 PNG
Screenshot: 1280x800 or 640x400
Promotional tile: 440x280

Create ZIP of your dist/ folder:

cd dist && zip -r ../extension.zip . && cd ..

Upload ZIP, fill in description, add screenshots, submit for review.

Review takes 1-3 days. Common rejection reasons:

Keyword stuffing in description
Missing privacy policy (if using permissions)
Incorrect screenshots

After approval:

Conclusion

That's all. We built a Chrome extension with React, TypeScript and Vite, tested it locally, and published to Chrome Web Store.

Final stack:

React 18
TypeScript
Vite
Tailwind CSS
Manifest V3

Live extension: Freelance Rate Calculator

If you liked the article, follow me on Twitter @Nefayran for more #buildinpublic content.

Read on AllKeep →