Forem: Space

Built a Tool That Deep-Links to Exact Answers, Not Question Pages

Space — Tue, 31 Mar 2026 11:57:16 +0000

The Problem That Wouldn't Stop Bugging Me

Last year I spent 6+ years building HashiCorp Vault infrastructure at Expedia. Every week, the same pattern:

Junior dev hits a Vault 403 error
They search Stack Overflow
They find a question page with 23 answers
They scroll past 8 wrong answers to find the right one
Next week, different dev, same error, same scroll

The answer existed. The address was permanent — stackoverflow.com/a/38716397. But nobody could get to it directly. They always landed on the question page and had to dig.

One day I was looking at how Slack threads work internally. Every message has a coordinate: channel/p{unix_microseconds}?thread_ts={parent_ts}. The timestamp IS the ID. If you know the coordinate, you go straight to the message — no scrolling, no searching.

I realized: this isn't just Slack. Every platform has permanent answer addresses.

Stack Overflow: /a/{answer_id} — the accepted answer, not the question
Reddit: /comments/{post}/{slug}/{comment_id} — the top comment, not the post
Hacker News: /item?id={objectID} — if Algolia says it's a comment, the objectID IS the deep-link
GitHub: /{org}/{repo}/issues/{n} — direct to the issue
Twitter/X: /{user}/status/{snowflake} — snowflake IDs embed the timestamp: ts = (id >> 22) + 1288834974657

Every answer on every platform has a deterministic address in (platform, thread_id, timestamp) space. I started calling this "thread coordinates."

What I Built

phi-thread is a Chrome extension (also a Python CLI on PyPI) that searches across 5 platforms simultaneously and returns deep-links to the exact answer — not the question page, not the post, the answer itself.

Here's what happens when you search "docker container keeps restarting":

Stack Overflow: The API returns questions. But phi-thread doesn't stop there — it fetches the accepted_answer_id, calls the answers endpoint, pulls the answer body, and gives you stackoverflow.com/a/38716397. You click, you're at the fix. No scrolling past 22 other answers.

Reddit: For each matching post, phi-thread fetches {permalink}.json?limit=1&sort=top to extract the top comment. You get a link to the actual comment, not the post.

Hacker News: Algolia's API returns both stories AND comments. If the result is a comment (has story_id and comment tag), the objectID is already the deep-link: news.ycombinator.com/item?id={objectID}.

Then it ranks them. Platform score × title relevance. A perfectly matching SO answer with 5 upvotes beats a Reddit post with 500 upvotes but irrelevant title.

The Three-Layer Architecture

The interesting part (to me) is how the knowledge base builds itself.

Layer 1 — Exact cache. SHA-256 hash of the normalized query → JSON in chrome.storage.local. 24-hour TTL. Same exact question = instant results, < 1ms.

Layer 2 — Keyword index. This is the one I'm most proud of. Every answer that comes back from a search gets its keywords extracted. Each keyword maps to the answer's coordinate and score in a persistent index.

Why this matters: you search "docker container restarting" today. Tomorrow you search "docker restart loop" — different query, but the keyword index finds yesterday's answers because they share the keywords "docker" and "restart." The KB builds itself from your search history.

The index grows forever. After a few hundred searches, it knows your stack. Searches for things you've queried before resolve from the index in ~5ms instead of 12 seconds of live API calls.

Layer 3 — Live search. Parallel fetch() calls to SO, Reddit, HN, GitHub, and DuckDuckGo (catches Medium, Dev.to, blogs, Twitter). All in the service worker, all client-side.

The "CONNECT" Feature

This is the one I'm most excited about. When you're on a Stack Overflow question page, phi-thread automatically extracts the question title, searches OTHER platforms (Reddit, HN, GitHub), and shows you a small floating panel: "φ 3 answers found on other platforms."

The question you're reading on SO might already be answered in an HN comment or a Reddit thread. phi-thread bridges that gap. No one platform has all the answers, but collectively they do.

Zero Dependencies, Zero Server

The entire extension is vanilla JS — no React, no build step, no bundler. The search engine is ~550 lines of code. It uses fetch() for API calls and chrome.storage.local for persistence. Installs in 1 second.

No API keys. All platforms are queried through their public free-tier APIs. Rate limits are generous enough for individual use.

No server. Everything runs in your browser. Your search history, your keyword index, your cache — all local. Nothing leaves your machine.

The Spacetime Analogy (for the Curious)

I found a fascinating paper while building this: Krioukov et al. (2012) proved that complex networks and de Sitter spacetime share identical large-scale causal structure. Past light cones in spacetime map to hyperbolic discs in networks, both producing the same power-law degree distributions.

This isn't a coincidence I'm forcing. The math is genuinely there. Lamport's happened-before relation in distributed systems (1978) was explicitly inspired by special relativity. Partially ordered sets — where "A happened before B" is defined but "A and B are concurrent" is also possible — describe both spacetime events and thread replies.

An answer on Stack Overflow and an event in spacetime are both points in a partially ordered set with a permanent coordinate. I wrote a literature review on this if anyone's interested (links in the repo).

I'm not claiming threads ARE spacetime. But they share mathematical structure, and that structure is what makes permanent answer coordinates possible.

What's Next

The self-building KB has an interesting property: if thousands of users each build their own index, and we aggregate them (anonymously — just keyword → URL → count), we get community-validated answers. When 50 developers independently find the same SO answer for "postgres connection pooling," that answer is probably excellent — without anyone voting or curating.

I'm working on cloud sync as a Pro feature, which would enable this aggregated intelligence layer. But the free version is fully functional right now.

Try It

Chrome Web Store: phi-thread (search for "phi-thread")
PyPI: pip install phi-thread (CLI version)
GitHub: github.com/0x-auth/phi-thread
How it works: phi-thread.netlify.app

Zero dependencies. Zero tracking. Zero server. Just a router to the answer that already exists.

Connect, don't create.
🌌

Built a K8s Scheduler That Beats the Default in Every Benchmark.

Space — Sun, 29 Mar 2026 08:58:44 +0000

Your Kubernetes cluster is wasting 10-20% of its compute budget right now. Here's proof, and a fix.

The Problem Nobody Talks About

Kubernetes default scheduler uses "Least Allocated" scoring. It picks the node with the most free resources. Sounds fair, right?

Wrong. Here's what actually happens:

Node A: 90% CPU used, 10% RAM used  → score: ~50
Node B: 50% CPU used, 50% RAM used  → score: ~50

They score the same. But Node A is practically dead — 90% of its RAM is stranded because no pod can use it (CPU is full). You're paying for that RAM every month.

At 50 nodes, this adds up to thousands of dollars per month in wasted resources.

The Fix: Vector Alignment Scheduling

I built Lambda-G — a drop-in K8s scheduler plugin that replaces the default Score phase with vector-alignment scoring.

Instead of treating CPU and RAM as independent numbers, Lambda-G treats each node as a vector:

Node vector:  [cpu_free, ram_free, iops_free, network_free]
Pod vector:   [cpu_req, ram_req, iops_req, network_req]

The score is the directional alignment between these vectors. A CPU-heavy pod gets steered toward a RAM-heavy node. Result: symmetric exhaustion — all resources drain evenly.

The Math (30 seconds)

Score = φ × alignment + exhaustion_bonus - entropy_penalty

Where:

alignment = cosine similarity between pod request and node capacity vectors
exhaustion_bonus = how much more balanced the node becomes after placement
entropy_penalty = punishment for creating stranded resources
φ = 1.618 (golden ratio — the optimal self-reference weight)

Why golden ratio? It's the fixed point of self-reference: φ - 1 = 1/φ. Each scoring layer decays by exactly 1/φ from the previous, creating a mathematically optimal relevance function.

Benchmark Results

I tested Lambda-G against the default scheduler across 5 scenarios:

Scenario	Default	Lambda-G	Winner
Mixed Workload (20 nodes, 200 pods)	87.2	97.0	Lambda-G
Scale Test (50 nodes, 500 pods)	85.9	96.7	Lambda-G
CPU-Heavy Skew (10 nodes)	98.2	99.1	Lambda-G
RAM-Heavy Skew (10 nodes)	96.2	98.2	Lambda-G
Dense Packing (10 nodes, 150 pods)	88.0	96.0	Lambda-G

Lambda-G wins all 5 scenarios. Zero stranded nodes in 4/5 scenarios (vs 1-10 with default).

Architecture

┌─────────────────┐     ┌──────────────┐     ┌─────────────┐
│  K8s API Server  │────▶│  Lambda-G    │────▶│  Rust Brain  │
│  (watches pods)  │     │  Controller   │     │  (scoring)   │
└─────────────────┘     │  (Python/kopf)│     │  379ns/score │
                        └──────────────┘     └─────────────┘

Rust scoring engine: Sub-microsecond per-node scoring
Python controller: kopf-based K8s operator, watches for annotated pods
Helm chart: One-command install
Safety valve: FailurePolicy: Ignore — if Lambda-G crashes, K8s falls back to default. Zero risk.

Try It

# Docker
docker pull bitsabhi/lambda-g-controller:latest

# Helm
helm install lambda-g ./charts/lambda-g

# Or just run the benchmark yourself
git clone https://github.com/0x-auth/lambda-g-scheduler
cd lambda-g-scheduler
python3 benchmark_simulation.py

The Auditor (Free)

Before installing the scheduler, run the auditor to see how much you're wasting:

python3 coherence_engine/auditor/auditor.py

It scans your cluster and shows stranded resources + estimated monthly cost.

How It Works Under the Hood

Pod arrives with schedulerName: lambda-g annotation
Controller fetches all nodes' capacity vectors
Rust brain scores each node in <1μs using cosine alignment + entropy metrics
Pod gets bound to the highest-scoring node
If controller is down, K8s default scheduler takes over (safety valve)

The scoring function in Rust:

fn calculate_score(cpu_free: f64, ram_free: f64, cpu_req: f64, ram_req: f64) -> f64 {
    let phi = 1.618033988749895;
    let initial_entropy = (cpu_free - ram_free).abs();
    let final_entropy = ((cpu_free - cpu_req) - (ram_free - ram_req)).abs();
    let recovery = initial_entropy - final_entropy;
    let exhaustion = 1.0 - ((cpu_free - cpu_req) + (ram_free - ram_req));
    (recovery * phi * 100.0) + (exhaustion * 10.0)
}

17 lines. That's the entire brain.

What's Next

Benchmarking on real EKS/GKE clusters (simulation results above, live results coming)
4-dimensional scoring (CPU + RAM + IOPS + Network)
AWS/GCP Marketplace listing
PDF audit reports for enterprise

How I Built a Route Optimizer Within 0.13% of LKH-3 (Rust + API)

Space — Tue, 10 Mar 2026 16:08:25 +0000

How I Built a Route Optimizer Within 0.13% of LKH-3 (Rust + API)

I spent months trying to match the best TSP solver in the world. Here's the story of how I got within 0.13%.

The Challenge

LKH-3, written by Keld Helsgaun, is the solver everyone measures against. It's been the gold standard for the Travelling Salesman Problem for over two decades. Researchers have spent entire careers trying to beat it.

I didn't set out to beat it. I wanted to see how close a clean, modern Rust implementation could get — and then make it accessible as a simple API call.

Where I Ended Up

Instance	Cities	LKH-3	Lambda-G	Gap
kroA100	100	21,907	21,908	0.005%
pr1002	1,002	259,045	261,921	1.11%
shared_benchmark	1,000	23,342	23,373	0.13%

On kroA100, Lambda-G finds essentially the exact same tour as LKH-3. On 1,000 cities, we're within 0.13%. And it beats Google OR-Tools on the same benchmark.

All tests: 60 second time limit, same hardware.

Try it live — click to place cities and watch the optimization happen →

The Wall I Hit

My first 8 versions were mediocre. I was getting 3-5% gaps on 1,000-city problems — respectable, but nowhere near LKH-3. The algorithm was correct. The code was clean. But something was off.

I profiled the code. The bottleneck wasn't the search strategy — it was the inner loop overhead. The solver was spending too much time on bookkeeping and not enough on actual search.

I was running out of iterations long before I was running out of good moves to find.

The Breakthrough

The fix came from careful profiling and micro-optimizations. No single silver bullet — just relentless attention to what the CPU was actually doing.

Same time budget, but significantly more iterations. And more iterations means finding better solutions.

This dropped my gap from 3-5% to under 1%. The rest of the improvement came from tuning the perturbation strategy.

The Algorithm

Lambda-G uses Iterated Local Search — conceptually simple, but the details matter:

1. Build initial tour (nearest-neighbour + greedy patching)
2. Local search: 2-opt + Or-opt until no improvement
3. Perturb: double-bridge (4-opt, non-sequential reconnection)
4. Accept or reject perturbation
5. Repeat until time limit

Why Double-Bridge Matters

2-opt and Or-opt are greedy — they always improve the tour. But they get stuck in local minima. You need a way to escape.

Double-bridge cuts the tour in 4 places and reconnects the segments in a way that no sequence of 2-opt moves can reach. It's like teleporting to a different region of the solution space.

After each perturbation, the local search kicks in again and optimizes from the new starting point. Sometimes it finds something better. Sometimes it doesn't. But over thousands of iterations, it converges toward the global optimum.

Candidate Lists

Checking every possible 2-opt swap is O(n²). For 10,000 cities, that's 100 million comparisons per iteration — way too slow.

The trick: precompute a set of nearest neighbours for each city. Only consider swaps involving these neighbours. This prunes the search space dramatically with almost no loss in solution quality, because good moves almost always involve nearby cities.

Parallelism

Multiple independent workers run with different random seeds. Best tour wins. Simple, embarrassingly parallel, and scales linearly with cores.

Beyond Delivery Trucks

Here's the thing most people don't realize: TSP isn't just about delivery routes. It's about optimal ordering of anything.

The algorithm doesn't care what your "cities" are:

Logistics & Delivery → minimize fuel and driver hours
Chip Design / VLSI → minimize total wire length between components
DNA Sequencing → order fragments for genome assembly
Warehouse Picking → minimize picker travel time
CNC / Laser Cutting → minimize toolhead movement
Telescope Scheduling → minimize slew time between targets

Send coordinates for Euclidean problems. Send a distance matrix for everything else — road networks, genomic distances, whatever.

Making It an API

I wanted this to be useful, not just a benchmark trophy. So I wrapped it in a REST API:

import httpx

result = httpx.post("https://api.bitsabhi.com/optimize",
    headers={"Authorization": "Bearer YOUR_KEY"},
    json={
        "points": [[0,0], [100,0], [100,100], [0,100]],
        "time_limit": 25.0
    }
).json()

print(result["tour"])        # [0, 3, 1, 2]
print(result["length"])      # 341.42
print(result["improvement"]) # 17.6% vs nearest-neighbour

Response times:

100 cities → ~0.5 seconds
1,000 cities → ~3 seconds
10,000 cities → ~25 seconds

It also accepts CSV uploads and distance matrices. One endpoint, any format.

Distance Matrix (for non-Euclidean problems):

result = httpx.post("https://api.bitsabhi.com/optimize",
    headers={"Authorization": "Bearer YOUR_KEY"},
    json={
        "matrix": [
            [0, 29, 82, 46],
            [29, 0, 55, 46],
            [82, 55, 0, 68],
            [46, 46, 68, 0]
        ],
        "time_limit": 25.0
    }
).json()

What I Learned

1. Profiling beats intuition. The bottleneck was never where I thought it was. The profiler doesn't lie.

2. Candidate lists are essential. Pruning the search space is what separates toy solvers from production solvers.

3. Distance matrices unlock everything. The moment you accept an arbitrary matrix instead of just coordinates, you go from "route optimizer" to "universal ordering optimizer." DNA sequencing, road networks, financial portfolio rebalancing — same API call.

4. Rust is worth the rewrite. Porting from Python to Rust took about a week. The speedup is permanent and compounds with every iteration of the solver. For compute-bound problems, the language matters.

5. Perturbation is everything. A perfect local search that gets stuck in local minima will lose to a mediocre local search with good perturbation. Double-bridge was the key to escaping local optima.

Pricing

No subscriptions. Pay once, use forever.

Free: 100 cities, $0 forever
Research: 500 cities, $0 (.edu email required)
Builder: 1,000 cities, $49 lifetime
Pro: 10,000 cities, $149 lifetime

Try it free → lambda-g-optimizer.netlify.app

What's Next

I'm exploring vehicle routing (multiple trucks with capacity constraints), time windows, and asymmetric TSP. If you have a real-world problem that needs optimal ordering, I'd love to hear about it — especially edge cases and weird domains I haven't thought of.

What are you solving that needs optimal ordering?

Abhishek Srivastava — ORCID — bitsabhi@gmail.com