Stop Treating Mixed Prompts Like One Task: Why I Built RouteSmith

Siddharth Rathore — Thu, 07 May 2026 14:24:28 +0000

I built RouteSmith because mixed prompts are workflows, not single tasks. It routes coding-agent work across real host constraints instead of pretending every environment works the same way.

TL;DR

I built RouteSmith because coding agents still make users do too much manual routing.

If a prompt says, "plan this feature, implement it, add tests, and write docs," that is not one task. It is a workflow.

RouteSmith detects the current host, decomposes the prompt into task types, maps those tasks to capability classes, and routes them using what the host can actually support. If the host supports switching, RouteSmith can suggest concrete models. If it does not, RouteSmith falls back honestly instead of pretending switching happened.

It is especially useful for:

people starting with coding agents
vibe coders who do not want to learn model tradeoffs first
solo builders doing mixed-task prompts
advanced users who want measurable, configurable routing

The Problem That Kept Annoying Me

I kept running into the same moment.

I would open a coding agent and give it one big prompt:

"Plan this feature, implement it, add tests, write docs, and review the result."

At first it felt smooth.

Then the flow broke.

I stopped thinking about the feature and started doing routing in my head.

Questions like:

should planning use a stronger reasoning model?
should coding use something different?
why am I spending the heaviest model on docs and formatting?
does this host even support switching the way I think it does?

That was the real problem.

The prompt was never one task. It was several different jobs bundled together.

What RouteSmith Is

RouteSmith is a host-aware routing layer for coding agents.

It is not another coding agent.

It is not an API gateway.

It sits between a mixed prompt and the host's real capabilities.

The basic flow looks like this:

detect the current host
classify the prompt into task types
map those task types to capability classes
resolve those capabilities against host-native models or strategies
preserve dependency order
track outcomes and improve routing over time

Why "Host-Aware" Is the Important Part

This is the part I care about most.

Too many conversations about multi-model workflows flatten away the host and act like every environment exposes the same control surface.

They do not.

Claude Code, Cursor, Copilot, Codex, Gemini CLI, and Aider do not all behave the same way. Some support real model switching. Some expose model choice differently. Some are much more host-controlled.

So RouteSmith is built around a simple rule:

the host is the source of truth.

If the host supports dynamic switching, RouteSmith can route tasks to concrete models.

If the host does not, RouteSmith does not fake it. It keeps the routing logic and applies prompt strategy instead.

That honest behavior matters more than a fake universal abstraction.

Who This Is For

This project is not just for people who already know the difference between reasoning models, coding models, fast utility models, and cost-optimized routing.

It is also for people who are new to all of that.

1. People starting with coding agents

If you are using agent tools but still do not know when to switch models, RouteSmith is meant to help reduce that decision burden.

2. People doing vibe coding

If your style is to describe the outcome in plain English and keep moving, RouteSmith helps because it treats the prompt like a workflow rather than a blob.

3. Solo builders and founders

If you are doing planning, implementation, tests, docs, and review yourself, task-aware routing becomes immediately useful.

4. Advanced users

If you care about policy overrides, plugins, telemetry, performance-aware routing, and host constraints, RouteSmith has room for that too.

The short version:

RouteSmith is for people who want the benefits of multi-model workflows without having to become experts in model routing first.

A Concrete Example

Say a beginner types this:

Build me a simple expense tracker with authentication, add tests, and write a README.

What that usually means is something like:

planning the feature structure
implementing the app
writing tests
documenting the result

Those are different kinds of work.

RouteSmith can treat them that way.

A conceptual route might look like this:

planning      -> deep_reasoning
coding        -> coding
testing       -> coding
documentation -> balanced

Then the host adapter decides what that means in practice.

If the host supports switching, RouteSmith can suggest concrete models for each step.

If the host does not, it still preserves the task-aware strategy without lying about model control.

How It Works Under the Hood

Deterministic planning

RouteSmith classifies prompts into task types such as:

planning
analysis
coding
testing
refactor
documentation
formatting
review

That planning is deterministic. It does not need live API calls just to understand the shape of the request.

Capability classes

Instead of hardcoding routes directly to model names, RouteSmith maps tasks into capability classes like:

deep_reasoning
coding
balanced
fast

That makes the system portable across hosts.

Dependency-aware execution

Mixed prompts are not just lists. Tests often depend on implementation. Docs usually follow the change. Review comes later.

RouteSmith keeps that order intact.

Performance-aware routing

RouteSmith also records local telemetry such as:

model used
host name
task type
capability class
success or failure
duration
telemetry source

That data is not just for display.

If enough evidence shows that a default model is weak for a capability and a better host-available option exists, RouteSmith can de-prioritize the weaker model.

That turns performance tracking into an active routing signal.

How It Compares to Other Tools

I do not think the useful framing here is "RouteSmith vs everything else."

The useful framing is that adjacent tools solve different layers.

Agent products

Claude Code, Cursor, and Aider are agent products. They are the tools doing the coding work.

RouteSmith is not trying to replace them.

API and gateway infrastructure

LiteLLM and Portkey solve a different problem: multi-provider routing, control, and observability at the API layer.

That is useful, but it is not the same layer RouteSmith lives in.

Rules, skills, and instructions

Instruction surfaces help shape behavior, but they are not routing brains on their own.

RouteSmith sits between these layers as a host-aware routing layer for coding-agent workflows.

If I had to summarize it simply:

use Claude Code, Cursor, or Aider when you want a coding agent
use LiteLLM or Portkey when you want API-layer routing or gateway control
use RouteSmith when you want mixed-task coding prompts routed more intelligently inside real host constraints

What It Actually Gives You

The main benefit is not novelty. It is leverage.

RouteSmith helps by:

reducing model micromanagement
making mixed prompts more structured
respecting host-specific constraints
helping beginners benefit from better routing without needing deep model knowledge
giving advanced users telemetry, policy, and performance-aware adaptation

Try It

pip install routesmith
routesmith detect-host
routesmith explain "Plan this feature, implement it, add tests, and write docs"
routesmith run "Plan this feature, implement it, add tests, and write docs"
routesmith stats

And if you want to use it as a tool inside larger workflows:

routesmith serve-stdio

Final Thought

The interesting part of coding-agent workflows is no longer just the model.

It is the routing layer around the work.

If a prompt contains planning, coding, testing, documentation, and review, then treating it like one undifferentiated request is a bad fit for how software work actually happens.

That is the gap RouteSmith is trying to close.

Github link: github.com/sidrat2612/routesmith
PyPI link: pypi.org/project/routesmith

How a small misconfiguration cost me $10000 in AWS Bill!!

Siddharth Rathore — Mon, 05 Jan 2026 06:39:18 +0000

This was the time when I was just starting with AWS. I came from a background where I worked on bare-metal servers and knew little about Cloud Platforms. I joined a startup, and there I started working on AWS, where the company's entire production environment had only two EC2 instances - one hosting the web application and the other running the database.

Being a startup, after some time, they started getting traction, and with growing users, the database started growing at a rapid pace. To ensure data protection and business continuity, I was asked to design and implement a backup and disaster recovery (DR) strategy.

At the time, AWS did not offer a secondary region within the same country for our geography. Due to strict data compliance requirements, storing data outside the country was not an option - effectively ruling out cross-region DR within AWS. So, after much discussion, I finalised the following plan

Primary Hosting would remain on AWS.
Cold Disaster Recovery would be hosted on Google Cloud Platform (GCP), solely for worst-case scenarios.

To achieve the above I created 3 types of backup jobs–

Full Backup - Once every Friday night
Differential Backup - Every night
Transactional backup - Every 30 min

I uploaded the backups to AWS S3 and then synced them to GCP. In GCP, I retained only two weeks of data to keep storage costs under control.

For the first few months, everything appeared to work as expected. However, after roughly 4 months, I started seeing our AWS bill rising. When I looked closely at the bill, the cost spike was primarily due to data transfer charges running into terabytes. This was puzzling. Our database size was around 200 GB, and even with regular backups, my calculations suggested that monthly transfer costs should not exceed $500.

We raised a support ticket with AWS. After reviewing the case, AWS confirmed that the data transfer charges were legitimate and advised us to inspect our S3 buckets more closely.

After more investigation, I found terabytes of broken multipart uploads - incomplete files that had never been cleaned up. These broken multipart uploads were being picked up by the S3-to-GCP sync process and transferred repeatedly, massively increasing data transfer costs.

With the root cause found, the solution was simple. I applied S3 lifecycle policy to automatically delete incomplete multipart uploads. Once this rule was applied, the unnecessary data transfers stopped, and the AWS bills came down to normal in subsequent months.

From that point onward, every new S3 bucket I created included a default lifecycle rule to clean up incomplete multipart uploads. This costly lesson not only taught me to include this in our best practice but also to check and verify small configurations for Cloud setup and its governance, which we often overlook.

Forem: Siddharth Rathore