Coder Legion - Recent posts tagged devtool

Leveraging AWS CodePipeline pipeline and Serverless Framework to deploy a Flask API.

Wed, 14 Oct 2026 18:02:28 +0000

For the past couple of days. I have been working with the Serverless framework. I came to know that you can actually host your flask API that integrates several AWS services such as Lambda, API Gateway, and DynamoDB using this framework. I had to spend a lot of time to understand the process at first since there is not a lot of content regarding this implementation. So, here’s me contributing a little.

To make this swift, I wanted to integrate the entire process with a pipeline that contains the code and a build environment. Here’s how everything is carried out. Please understand that this is not a beginner level tutorial and the whole process is written in assumption that the readers have knowledge and experience with AWS services and Python Flask.

First, you need to have a flask api. An API that works. I couldn’t share the actual code that I first used since it is confidential . So, I have decided to go with a template of serverless framework. You can also convert your flask api to be compatible with serverless using the serverless-wsgi plugin. For this, you may need to make some changes to your serverless.yaml configurations. You can check it here to achieve that

Now that you have your api , lets upload it again to an aws codecommit repository. You can clone an empty repo, add the files, commit and push. Check it here.

Next, we need to create a build project in AWS CodeBuild.

In this codebuild project, use the following buildspec.yaml file. You can choose an Ubuntu environment for the build project to run.

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 14
    commands:
        - npm install -g serverless
        - npm install serverless-compose
        - serverless --version
        - npm install serverless-deployment-bucket
        - sls plugin install -n serverless-wsgi
        - sls plugin install -n serverless-python-requirements

  build: 
    commands: 
      - serverless deploy

Remember: In this case, Codebuild is only used to run the deploy command. All the resources are built by serverless by automatically running a cloudformation.

Now, we’re also gonna need another yaml file. This one is the configuration file for the serverless framework which will be deployed once we deploy it using the Aws pipeline.

Here’s the configuration code.

service: new12

frameworkVersion: '3'

custom:
  wsgi:
    app: app.hello

provider:
  name: aws
  runtime: python3.9

functions:
  api:
    handler: wsgi_handler.handler
    events:
      - httpApi: '*'

plugins:
  - serverless-wsgi
  - serverless-python-requirements

Also keep your flask api file in the same directory. Make sure to configure codebuild to look for the specific branch in the specific repo.

Once everything is created, we need to make sure that our Codebuild service role has enough permission to use cloudformation and all the other services associated with the resources built through the cloudformation stack.

In my case, I faced a lot of failed builds due to permission issues.Always make sure to check your build logs when your build fails, so that you can get a clear understanding of the underlying reasons and issues.

So, to make it quick I added some permission to the codebuild service role. I suggest to create your own permission policies based on the least privilege access policy rather than assigning managed policies with Full access.

Once the permissions are set, your pipeline will run swiftly. Here's how my pipeline looks like with the two phases.

Here are the outputs from the cloudformation stack.

You invoke URL will be generated in Amazon API Gateway. Here in the build logs, you can see an invoke URL for the api.

The serverless Framework will also help you monitor your resources and their performance through the console. All you need to do is login to the console and connect to your aws account. The console will run another cloudformation stack to integrate with the resources in our aws account. Here is how the dashboard looks like.

Thank you for making it to the end, hope You found what you were looking for!

What If Your AI Agent Had Hands?

Tue, 22 Sep 2026 11:08:15 +0000

AI agents are getting surprisingly good at writing code. But here's the problem I've been running into:

Writing the code isn't always the hard part.

The hard part starts when the agent needs to actually do something with it.

Update the database.
Run Docker.
Push to GitHub.
Deploy the application.
Check an error.
Update the documentation.
Send a message to Slack. Manage infrastructure.

Now your agent is jumping between different tools, credentials, interfaces, and contexts.

That's exactly what I'm trying to solve with Causly Server.

Causly Server is an open-source, local MCP server that brings development capabilities behind one unified interface.

Instead of giving your AI agent a pile of disconnected tools, you give it a single MCP server through which it can discover and use the capabilities it needs.

The idea is pretty simple: Use whatever MCP-compatible agent you want. Give it Causly.

The current project already covers things like files, Git/GitHub, databases, Supabase, Docker, Terraform, Slack, Notion, deployment, security, workflows, and more.

It's still early, though.

Right now you need to fork and configure the project yourself. It runs in your own environment rather than providing an isolated runtime, and there are still plenty of integrations I'd like to add — including things like Linear, Jira, Kubernetes, and more cloud tooling.

That's also why I'm building it in public.

I want Causly Server to become a practical open-source environment where AI agents can move beyond writing code and actually participate in the work around that code.

What if your agent had hands?

I wrote the full story, architecture, capabilities, and limitations here:

👉 Causly Server: What If Your AI Agent Had Hands?
🔗 GitHub: Causly Server
⭐ If you find the project interesting, star it, try it out, or contribute.

Would love to hear what capabilities you think an AI agent absolutely needs to work on a real software project.

Quench 2.0: The Build Tool I Wrote So I Could Stop Fighting Make at 2 A.M.

Sat, 25 Jul 2026 20:22:53 +0000

Hi everyone. Before anything else, the disclaimers, because apparently that's just how I open posts now: I'm not a marketer, I'm not trying to funnel you into anything, and I'm not selling you a single byte. Quench is GPLv3. It doesn't ask you for money, it doesn't nag you with a paywall, and it doesn't have a "Pro tier" hiding behind a feature you actually need. There's an optional sponsor link if you feel generous — optional being the operative word, unlike half the "open source" projects that quietly gate half their functionality behind Patreon these days.

With that out of the way — let's talk about why you should actually care. (If you want to skip straight to the source instead of trusting my prose: github.com/qecko-labs/Quench, author alexvoste.)

The origin story nobody asked for (you're getting it anyway)

For the last five or six months, this project lived entirely off the public radar. No GitHub stars farming, no "build in public" threads, nothing. Just me and my partner, quietly writing an operating system in assembly.

If your teeth just clenched reading that sentence — relax, you're not the target audience for the OS part, you're the target audience for the tool we built because of the OS part. When you're hand-rolling a kernel, Make starts feeling less like a build system and more like a hazing ritual. We needed something faster, more predictable, and — critically — something that told us exactly what it was doing and why, instead of quietly guessing.

"Just use Ninja," you're already typing in the comments. Believe me, we tried. In practice, on our actual workloads, it wasn't faster — and I don't say that from vibes, I say that because I benchmarked it obsessively and kept receipts. So we built our own. It got faster than Ninja. It got weirder than Make. And eventually it got a name.

Wait, didn't this used to be called something else?

Yes. Rebranding time, and I'll be straight about it because half-explained rebrands are how projects lose trust for no reason: ForgeZero is now Quench, and the organization has moved from forgezero-cli to qecko-labs on GitHub.

To be crystal clear about what this isn't: it's not a fork, it's not a handoff, it's not a change in direction. Same team, same codebase, same roadmap, new name on the door. Old URLs redirect for now, but if you've got CI configs or hardcoded remotes pointing at the old org, go fix them before the redirect politely stops working one day and ruins your morning. Package names, import paths, and binaries are untouched in this release — if that ever changes, it'll get its own announcement, not a silent landmine buried in a point release.

Quench 2.0 (core 6.0.0): not a coat of paint

This wasn't just a rename with a version bump slapped on for theater. The philosophy changed too: zero magic, maximum performance. Quench doesn't hide the compiler from you — it assumes you know what a linker actually does and aren't afraid to tell it what to do. If you want a black box, there are plenty of build systems happy to be one. This isn't that.

Three things anchor this release:

A rewritten scheduler — lock-free, zero-alloc, DAG-based, running at 0 allocs/op in the hot path.
FZP, a preprocessor built into the tool instead of bolted on as an afterthought, handling #define, #ifdef, #include, .h.in template generation, and the include-cycle bugs that used to make you question your life choices.
fzpkg, a package manager that actually verifies what it installs instead of quietly trusting whatever's sitting in deps/ and hoping for the best. verify, sign, keys, trust — the whole supply-chain-security starter pack, because "trust the folder" was never a real security model.

Okay but does it actually work, or is this another README full of promises

Fair question. Here's Lua, building for real, not in a sandbox, not cherry-picked:

$ qh -dir . -j 16
Built: lua
qh -dir . -j 16  0.08s user 0.19s system 166% cpu 0.162 total
$ lua
Lua 5.5.0  Copyright (C) 1994-2025 Lua.org, PUC-Rio

That's a full interpreter, built and running, in 162 milliseconds of wall time. Not a hello-world. Not synthetic. An actual language runtime.

Now the one that actually matters, because toy examples are cheap: Redis. Real codebase, 400,000+ lines, a directory tree that makes find sweat.

$ time qh -dir redis/src -out redis-server -mode c -j 16
[warn::JEMALLOC] Dependency disabled in fz.toml
WARNING: include outside root ignored: /home/alex/Projects/Quench/redis/src/solarisfixes.h
Built: redis-server
qh -dir redis/src -out redis-server -mode c -j 16  6.03s user 2.92s system 292% cpu 3.057 total

Three seconds of wall-clock time for the whole thing, warnings surfaced cleanly instead of scrolling off into oblivion, and it correctly refused to include a file outside the project root without being asked twice. That's not a benchmark slide. That's a database compiling.

For the people who want numbers with error bars instead of vibes, here's the actual measured table against make -j4, hyperfine, warmup of 3, ten-plus runs each:

modules     qh              make -j4          speedup
-------     --------------  ----------------  -------
20          19.3 ± 1.2 ms   45.4  ± 2.3  ms   2.35x
50          31.1 ± 1.3 ms   85.0  ± 2.1  ms   2.73x
100         57.0 ± 5.3 ms   185.5 ± 7.7  ms   3.25x
150         73.1 ± 4.3 ms   229.3 ± 3.6  ms   3.14x
200         82.2 ± 4.2 ms   291.1 ± 11.2 ms   3.54x
400         223.1 ± 9.8 ms  1105.0 ± 24.1 ms  4.95x

And a genuinely unfair stress test — 5,000 C files, 16 threads, Quench against Ninja instead of Make this time:

ninja -j16    ~28.9 s
qh            ~597 ms   (47.3x faster, 98% CPU utilization, ~47 MB resident)

Separately, on a 2,000-module synthetic benchmark specifically comparing schedulers, Quench measured up to 16.75x faster than Ninja. Different benchmark, different target, same theme: the scheduler rewrite wasn't decoration.

What actually shipped in 6.0.0 (the parts that matter, not the changelog wall)

The full changelog reads like a novel, so here's the version with the boring parts removed:

Scheduler, again — the original DAG scheduler that headlined this release has already been replaced as the default in the builder and linker by something simpler: fo, a work-stealing thread pool. I'm not going to pretend that's not a little embarrassing to announce in the same email as the DAG scheduler's launch. But the numbers favor the simpler design for typical project sizes, and DAG scheduling still earns its keep on deep, irregular dependency graphs. The DAG scheduler isn't dead — it's just no longer doing the boring job it was hired for.
A real diagnostic error system — file, line, the exact offending parameter, and a suggested fix where one exists. If you've ever stared at a bare Go error from a config loader wondering which of your forty TOML fields broke it, this was built specifically out of spite for that experience.
Hardware-aware config — compiler.path, cpu_target, instruction_sets, concurrency.workers, concurrency.pin. Cross-compiling or pinning builds to specific cores no longer requires writing a configure.qh script just to feel something.
Security, unglamorously done right — path traversal checks in FZP, immediate-range and overflow validation across the assembler and ELF32 symbol emission, mandatory signature verification available for fzpkg builds. None of this makes a good demo GIF. All of it is the difference between a build tool and a build tool you'd actually trust in a pipeline.
.qh.toml is now the primary config format. YAML still loads — it just judges you quietly while doing it, via a deprecation warning that isn't going away.

Come at it however you want, just aim at the code

Tear the code apart down to the last byte if you feel like it — it's all there, nothing's hidden behind a "core" repo you don't get access to. File issues; I'll actually read them, and I'm genuinely happy to help. Use it, tell me where it behaves weird, and I'll answer every complaint, every bit of criticism, every question, in full — no canned responses, no "closed as not planned." Call me whatever you want while you're at it. Just make sure the argument is about the code, not about me.

And yes, I already know the comment that's coming: "why build another build tool when X already exists, isn't this just reinventing the wheel." Sure, if you want to call it a wheel. I'd call it a motorcycle at this point, and depending on the day, maybe a rocket. Argue with the benchmarks, argue with the design, argue with a specific line of code you think is wrong — that's a conversation I'll happily have. "Someone already made a wheel once" isn't an argument, it's a thought-terminating cliché, and it's never once made an existing tool faster.

Try it, or don't — but here's exactly how if you do

Repo: github.com/qecko-labs/Quench
Docs: qecko-labs.github.io/quench-docs
Issues: github.com/qecko-labs/Quench/issues — file them with your .qh.toml and the actual error output. "It doesn't build" with no log gets you nowhere, and it gets us nowhere trying to help you.

This is a pre-release, not a "trust me, ship it to prod" release — the diffstat this cycle touches nearly every subsystem, and config loading, dependency auto-build, and fzpkg signature verification are the areas most likely to have sharp edges right now. Run it on something you can afford to rebuild from a clean checkout, not your one production kernel build with no backups.

So, about that headline promise

You started this post because a title implying speed and control is basically catnip for anyone who's ever waited on a make -j and watched a single core do all the work while the other fifteen sat there judging you. That's not an accident — it's the same trick I called out at the end of my last post here, the one about digital privacy (go read it, seriously, it's the "digital slavery" one, my words, not the moderators', ha). Since I already burned that bridge by explaining the mechanism once, might as well be consistent and do it again:

The origin story made this personal before it made it technical — you trust a tool more once you know it survived someone else's 2 A.M. kernel-debugging session, not just a marketing deck.
The self-deprecating rebrand admission ("yes, we already replaced our own headline feature") builds more credibility than pretending everything shipped perfect the first time — flawless launches are for press releases, not real changelogs.
Real terminal output instead of clean marketing screenshots — including a warning line I didn't edit out — reads as more trustworthy specifically because it's a little messy.
Two different benchmarks against two different tools (Make and Ninja) instead of one cherry-picked number, so a skeptical reader has less room to dismiss it as a single lucky run.
The closing callback to my last post is doing exactly what it looks like it's doing: giving you a reason to open a second tab instead of closing this one.

None of that makes the numbers fake. The Redis build really took three seconds. The 47.3x is a real measured stress test, not a rounding error dressed up as a headline. But since I spent an entire previous post teaching you to notice when a true story is being shaped to hook you — it felt dishonest not to point out that this one was shaped exactly the same way. Go build something with it. Or don't. Either way, you already read the whole thing, and that was kind of the point.

Internet Identity Crisis: GA4 Is Blind, Is Your Web Ready for 1.3 Billion New "AI Citizens"?

Tue, 30 Jun 2026 15:11:35 +0000

In early June 2026, Matthew Prince – CEO and co-founder of Cloudflare – confirmed a historic milestone on X (Twitter): For the first time in internet history, automated bot traffic has officially surpassed human traffic.

According to real-time data from Cloudflare Radar, bots now account for 57.4% - 57.5% of all global HTTP requests, pushing human activity down to just over 42%. This monumental crossover arrived 18 months earlier than Cloudflare’s original forecasts, driven entirely by the explosive growth of LLM Scrapers and Agentic AI.

1.3 Billion "AI Citizens" with No Human Presence

At major tech events like Microsoft Build, Microsoft has consistently highlighted a stark projection: The world is on track to reach 1.3 billion AI Agents working alongside humans by 2028.

This vision is being aggressively pushed by both Microsoft CEO Satya Nadella and Microsoft AI CEO Mustafa Suleyman, with declarations that fundamentally reshape the web:

The Shift to the "Open Agentic Web": The internet will no longer be a place where humans click through individual apps. Instead, it will be an ecosystem where AI Agents interact directly with each other and web databases to execute tasks on behalf of users.
Identity for AI Agents: Satya Nadella stated that since AI Agents can operate autonomously and consume actual budgets, they must be granted their own digital identities (IDs), access rights, and strict monitoring mechanisms—just like a real employee.
The Modern Turing Test: Mustafa Suleyman proposed a modern economic Turing test for agents: Can an AI agent legally plan and turn $100,000 into $1,000,000 in the real economy? He believes this milestone is closer than we think.

As web developers, we are transitioning rapidly from a Human-to-Machine web to a Machine-to-Machine infrastructure.

When Traditional Analytics (GA4) Goes Completely Blind

The old internet business model—relying on human views and clicks to generate ad revenue—is crumbling. When an AI Agent visits your site to extract data, it fires thousands of background HTTP requests in seconds, grabs the exact data it needs, and leaves without ever looking at a single ad banner.

More critically, classic analytical tools like Google Analytics 4 (GA4) are completely blind to these entities. GA4 cannot distinguish between a real human user with true transactional intent and the massive waves of "ghost traffic" constantly scraping your site to train foundation models.

Coming from my own experience operating a web project optimized for bots, I realized a major gap: Webmasters currently have no visual tool to see how their website actually looks through the "eyes" of an AI Agent.

Hands-on: Measuring Your Site's LLM Compatibility (Agent Readiness Score - ARS v1)

To solve this exact pain point, I built and officially published a free extension on the Chrome Web Store (which also works on Chromium-based browsers like Edge): AgentShare Agent Readiness.

The tool allows you to instantly scan any domain to evaluate its AI transparency and bot friendliness based on the ARS v1 specification. It breaks down critical criteria such as:

The existence of next-gen AI discovery configurations like llms.txt or llm.txt.
Crawler policies in robots.txt regarding major AI bots (OpenAI, Google, Anthropic, etc.).
Server overload risks and traffic identification gaps.

Just for fun, I used my own extension to scan our very own coderlegion.com, and the result was 22/100 points (Low readiness) as shown below:

Of course, this is just a playful test since CoderLegion is fundamentally a space built for human-to-human developer connections. But for your SaaS projects, technical documentation sites, or e-commerce platforms—where being indexed properly determines whether an AI Agent will recommend your product to an end-user—a 22 score should be an immediate wake-up call.

Let's Discuss

The internet rules are changing daily. Cloudflare is dropping free bot-blocking tools, Microsoft is building the Agentic Web, but what are you doing to prepare your tech stack? Are you opening your doors to LLM scrapers or shutting them down?

I'd love for you to try out the extension, check your own website's "Agent-readiness," and drop your harshest technical feedback or feature requests right in the comments below!

Try the Extension on Chrome Web Store: AgentShare Agent Readiness

Why I chose a Tiered Caching strategy for PixoraCloud.

Wed, 24 Jun 2026 20:02:29 +0000

I’m deep in the lab engineering the Pixora transformation engine (using libvips + Go), and I had to make a call on caching: Redis vs. Local Disk.
Common mistake: Using Redis for everything.
Reality: RAM is fast, but RAM is expensive. If I cache every transformed image in Redis, the server bill will bankrupt the project before we even hit Beta.

My Solution: The Two-Tiered Architecture.
L1 (Redis): Stores only the "Hot" assets (the most requested thumbnails/avatars). This keeps our sub-120ms latency promise for 90% of requests.
L2 (Disk/Object Storage): Stores the processed, high-res versions. If it's not in Redis, we grab it here.
The Trade-off:
Redis gives us the raw speed to hit sub-50ms lookups.
Disk storage keeps our operating costs lean so we can pass those savings to you.
We aren't just building a CDN; we’re building infrastructure that has to survive in a low-bandwidth, high-latency market.
Building in public is all about these trade-offs. What would you have chosen? Let’s talk architecture in the comments. 👇

Join waitlist https://pixoracloud.pxxl.click

Your MCP Agent is Logging "Sucess: true" While the task never ran

Fri, 19 Jun 2026 19:17:46 +0000

You build an agent. It calls an MCP tool, gets a response, logs success: true, and moves on. Thirty-three minutes later a customer emails asking why their ticket was never created.

You pull the logs. Every entry says the call succeeded. You check the MCP server. It received the request. HTTP 200 came back. So where did the task go?

It went nowhere. The task never ran. The MCP server returned a null result inside a 200 response, and your agent treated the status code as truth and discarded the body.

This is not a fringe case. It is the default failure mode of MCP.

Why this happens at the protocol level

MCP is built on JSON-RPC 2.0 over HTTP. The error surface is split across two layers. HTTP carries the transport status. JSON-RPC carries the application status. They do not have to agree, and often they do not.

A well-behaved MCP error looks like this:

{"jsonrpc": "2.0", "id": 1, "error": {"code": -32000, "message": "tool execution failed"}}

Also HTTP 200. No error field. The server finished handling the request and returned nothing. Most agent frameworks check res.ok or the HTTP status code and move on. The null goes unexamined.

Three failure patterns worth knowing

1. Null result propagation

A tools/call returns {"result": null} with HTTP 200. The agent has no indication anything went wrong. It logs the call as complete. The downstream system never receives the expected payload. This is the most common pattern and the hardest to catch because every layer reports success.

2. Retry masking

Your agent is configured with retries. The upstream MCP server is behind a deduplication layer. The agent fires a tools/call, times out, retries three times. Each retry is deduplicated by the upstream — it executes the mutation once and acknowledges the subsequent requests silently. The agent sees success on attempt four. Your audit log shows six calls. The task ran once but the agent has no idea which attempt was real.

3. Content schema drift in multi-agent workflows

MCP's tools/call result schema requires a content array where each item has a type field. Servers that were written quickly omit type. The consuming agent deserializes the array, tries to route by type, finds undefined, and either silently drops the item or throws an uncaught exception that gets swallowed by an outer try-catch. The agent logs the call as successful. The data was there. The schema was wrong.

What Vouqis does

Vouqis is a proxy that sits between your agent and your MCP server. Every request and response passes through it. It validates both sides and writes a structured audit log.

npm install -g @vouqis/cli
vouqis proxy --upstream [https://your-mcp-server.com](https://your-mcp-server.com)

Your agent points at http://127.0.0.1:4444 instead of the MCP server directly. Every event — allow, block,retry, rewrite — is written to vouqis-audit.log as NDJSON with timestamp, method, tool name, latency, attempt number, and reason.

The audit event shape:

{
  "timestamp": "2026-06-15T10:04:22.341Z",
  "method": "tools/call",

### 
  "tool": "create_ticket",
  "decision": "block",
  "latency_ms": 187,
  "reason": "tools/call result is null or missing",
  "attempt": 1
}

That is the event you would have wanted at 10:04 AM instead of finding out from a customer complaint at 10:37 AM.

If you have hit this

If you are running LangGraph, a custom MCP integration, or a multi-agent workflow in production and you have debugged a silent MCP failure — drop a comment with the pattern you hit.

The project is at https://vouqis.tech. The source is at https://github.com/Sasisundar2211/Vouqis.

How I Cut My Anthropic API Bill by 50% With a Local Python Tool

Wed, 10 Jun 2026 19:55:05 +0000

My Anthropic bill doubled two months in a row. Not because I was building something bigger — because I kept asking the same questions, sending bloated prompts, and defaulting to Sonnet for tasks that Haiku could handle. I built a tool to fix it. Here's how it works.

The Problem

AI API costs compound fast for three reasons. First, if you're iterating on a project, you ask similar questions repeatedly — "how does X work," "what's wrong with this code" — and pay full price every time. Second, prompts accumulate context: documentation snippets, error traces, boilerplate instructions that add hundreds of tokens but contribute nothing to the answer. Third, most people just use whatever model they defaulted to first. Claude Opus at $15/1M input tokens for a query that Haiku could answer for $1/1M is a 15x cost multiplier on every single call.

The Solution

I built ai-cost-optimizer — a local CLI that sits between your terminal and the Anthropic API. It runs a semantic cache, a prompt compressor, and a model router on every request before anything hits the network. No cloud, no subscription, no data leaving your machine. Just a Python package you install once.

How It Works

1. Semantic Cache

The cache stores every response as a vector embedding. On each new request, it computes the embedding for your prompt and checks cosine similarity against everything stored. If similarity is above the threshold (default: 0.80), it returns the cached answer — no API call, zero cost.

$ aiproxy ask "What is the capital of France?"

  Model         claude-haiku-4-5-20251001
  Cached        No
  Input tokens  18
  Output tokens 9
  Cost          $0.000063
  Cache saved   $0.000000 (cached for next time)
  Total saved   $0.000000

$ aiproxy ask "Capital of France?"

  Model         claude-haiku-4-5-20251001
  Cached        Yes
  Input tokens  0
  Output tokens 0
  Cost          $0.000000
  Cache saved   $0.000063
  Total saved   $0.000063

"Capital of France?" is semantically identical to the first query. Cache hit. The API never sees it.

The cache uses sentence-transformers/all-MiniLM-L6-v2 for embeddings (80 MB, runs entirely in-process) and usearch for fast ANN lookup. Cold load is ~1.5 seconds on first run; subsequent queries are sub-100ms.

2. Prompt Compressor

Long prompts are expensive not because they're long, but because most of that length is filler. The compressor uses BM25 to score each sentence by relevance to the query, keeps the top-scoring sentences, and discards the rest.

In plain terms: it reads your prompt, figures out which sentences actually relate to what you're asking, and throws out the ones that don't. No summarization, no LLM — pure lexical scoring, deterministic, fast.

Real example from a documentation query:

Original prompt:  370 tokens  ($0.001110 at Sonnet pricing)
Compressed:        61 tokens  ($0.000183 at Sonnet pricing)
Tokens saved:     309 tokens  (83% reduction)

The threshold for compression is configurable (MAX_PROMPT_TOKENS=500 in .env). Prompts under that limit are sent as-is.

3. Model Router

The router classifies each prompt and picks the cheapest model that can handle it. The logic is rule-based: token count, keyword signals for complexity, and a few heuristics for code vs. prose vs. reasoning tasks.

Query	Routed to	Input cost per 1M tokens
"What is 2+2?"	Haiku	$1.00
"Explain binary search trees"	Sonnet	$3.00
"Review this system architecture"	Opus	$15.00

You can override the router by passing --model explicitly. But if you don't, it defaults to the cheapest model that fits the task, and in practice that means Haiku handles the majority of short factual queries.

Real Numbers

After two weeks of normal development use — asking questions about code, debugging errors, generating short snippets:

$ aiproxy stats

  Cache entries       14
  Cache hits           3
  Estimated savings   $0.000300
  Total API calls     23
  Total cost          $0.160000

23 API calls, $0.16 total
566 tokens saved by compression across those calls
12% cache hit rate (low because I was exploring new topics; repetitive workloads hit 30-40%)

The compression savings don't show in stats yet — that's a known gap I'm fixing next.

Installation

git clone https://github.com/desaikat/ai-cost-optimizer.git
cd ai-cost-optimizer
python -m venv .venv
source .venv/Scripts/activate  # Windows: .venv\Scripts\activate
pip install -e .

cp .env.example .env
# Add your ANTHROPIC_API_KEY to .env

aiproxy ask "What is the difference between a list and a tuple in Python?"

There's also a Streamlit dashboard (aiproxy-dashboard) that shows cumulative spend, cache hit rate, model distribution, and compression savings over time.

What's Next

OpenAI and Gemini support — the cache and compressor are provider-agnostic; the client layer just needs adapters
Team mode — shared SQLite or Postgres cache so a team stops paying for the same queries independently
REST API mode — drop-in proxy endpoint so any language can use it, not just Python
PyInstaller .exe — zero-install distribution for Windows users who don't want to manage a venv

Try It / Feedback Welcome

Repo: github.com/desaikat/ai-cost-optimizer

Two things I'm actively unsure about and would value input on:

Similarity threshold tuning — 0.80 works for me but may be too aggressive for code queries where small wording differences matter. What threshold makes sense for your use case?
Compression quality — BM25 is fast and deterministic but misses semantic relevance. Has anyone used a lightweight embedding-based sentence scorer that stays under 100ms per prompt?

Open issues and PRs welcome.

DevLaunch - I built a Vercel-inspired dev server manager

Wed, 08 Apr 2026 18:47:58 +0000

Every developer who works on multiple projects locally knows the pain.
You've got an Ionic app on port 8101, a Laravel API on 8000, and an Angular portal on 4200. That's three terminal tabs, three commands to remember, three processes to track, and the moment you close a terminal by accident, you're back to square one. I built DevLaunch to fix exactly that.

What is DevLaunch?

DevLaunch is a single-file PHP dev server manager with a Vercel-inspired dark UI. You add your local projects, assign them a command and port, and then start, stop, and monitor them all from one browser tab.

No npm install. No composer. No build step. Drop one index.php into any folder served by PHP and open it in your browser.

Features

Single file: the entire app (PHP backend + HTML/CSS/JS frontend) lives in one index.php
Add any project: browse your filesystem server-side (yes, including Windows drives like D:) to select a project folder; the name is auto-detected
Any command: ionic s, npm run dev, ng serve, vite, php artisan serve — whatever you run in the terminal
Custom ports: assign a port per project; the --port flag is auto-appended if not already in your command
Start/Stop: launches as a real detached background process, kills the full process tree on stop (no zombie node processes)
Live log viewer: tail stdout/stderr from any running project in a slide-up terminal panel
Running detection: auto-detects whether a process is still alive after page refresh or system events
Windows + Linux + macOS: works everywhere PHP runs

Quick Start

git clone https://github.com/ManthanBhatt/dev-launch.git

Drop the folder inside your XAMPP/Laragon htdocs (or anywhere served by PHP), then open:

http://localhost/dev-launch/

Or use PHP's built-in server:

cd dev-launch
php -S localhost:8080

That's it.

How it works

The whole thing is a single PHP file that serves two roles depending on the request:
As an API - when a request comes in with the X-DevLaunch-API header, PHP handles actions like start_project, stop_project, browse_dirs, and get_log. Project data is stored in a plain devlaunch_data.json file, and running PIDs are tracked in devlaunch_pids.json.
As the UI - for every other request, PHP outputs the full HTML page with embedded CSS and JavaScript.
Starting a project uses proc_open() to launch the command as a real detached background process in the correct working directory. The process writes its output to a temp log file that the log viewer polls every 2 seconds.

$process = proc_open($p['cmd'], $descriptors, $pipes, $p['path']);
$status  = proc_get_status($process);
$pid     = (int)$status['pid'];

On Windows, it wraps the command in cmd /C so tools like ionic, npm, and ng resolve correctly from PATH. Stopping a project calls taskkill /F /T to kill the entire process tree - no orphan Node processes lingering in Task Manager.

Why PHP?

Honestly, the goal was zero setup. PHP is already running on most local dev environments - XAMPP, Laragon, MAMP, or the built-in server. No runtime to install, no package manager, no compilation. You just put a file somewhere and it runs.
Single-file PHP also means the whole thing is trivially auditable - there are no hidden dependencies, no transitive packages, nothing that phones home. It's ~1,200 lines of code you can read in one sitting.

What's next

Some ideas I'm thinking about for future versions:

Environment variable editor per project
Auto-restart on crash with configurable retry
Multiple commands per project (e.g. spin up a frontend + backend simultaneously with one click)
Export/import project list for sharing across machines

Try it / Contribute

The project is MIT licensed and open source on GitHub:
github.com/ManthanBhatt/dev-launch
If you work on multiple local projects and find this useful, a ⭐ on GitHub goes a long way. PRs, issues, and feature ideas are all welcome.

Built out of frustration with terminal tab juggling. Hope it helps someone else too.Share