DEV Community: Anirudh

I Built a Coding Agent That Runs on a 1.7B Model

Anirudh — Fri, 02 Oct 2026 08:41:29 +0000

I've been interested in local AI for a while, especially running AI models on hardware that isn't exactly a massive AI workstation.

At some point, I started wondering:

How useful could a coding agent be if it had to run on a tiny local model?

So I decided to build one.

That's how MINICODE started.

GitHub — MINICODE

What is MINICODE?

MINICODE is a terminal-based AI coding agent that I built around small local language models.

The default setup uses Qwen3 1.7B through Ollama.

The goal isn't to compete with massive cloud models.

Instead, I wanted to experiment with making a small model actually useful by giving it tools and letting it interact with a coding environment.

It can work with files, run commands, search the web, maintain conversation context, and interact with the project it's being used in.

Why 1.7B?

I don't have some giant GPU server sitting under my desk.

I wanted something that could run locally and be relatively lightweight.

A 1.7B model is obviously limited compared with much larger models, but that's actually what makes the experiment interesting.

Instead of solving everything by throwing a bigger model at the problem, I wanted to see how much I could improve the experience through the agent itself.

The model doesn't have to do everything alone.

MINICODE can give it tools.

Building the agent

One of the first things I learned is that building an AI coding agent is very different from just making a chatbot.

A chatbot can generate a response.

An agent needs to interact with the world.

For example, if I ask MINICODE to modify a project, the model needs to figure out what files it needs, inspect them, make changes, and potentially run commands to test those changes.

That creates a loop something like:

User
 ↓
Model
 ↓
Tool call
 ↓
Tool executes
 ↓
Result goes back to model
 ↓
Model decides what to do next

Getting that loop working reliably was one of the most interesting parts of the project.

I didn't want the AI to have unlimited control

Another thing I cared about was safety.

Giving an AI access to a terminal means it could potentially execute commands that you didn't intend.

So MINICODE asks for confirmation before performing potentially dangerous actions.

Instead of:

AI → execute command

it's more like:

AI → "I want to execute this command"
             ↓
        You approve?
          ↙     ↘
        Yes      No
         ↓        ↓
     Execute    Tell AI

If I reject an action, the model gets that information and can try another approach.

It's a simple system, but I think keeping a human in the loop is important when experimenting with autonomous tools.

I also built memory

I wanted coding sessions to be persistent rather than disappearing when I closed the terminal.

MINICODE can save conversations so I can come back to them later.

That means I can work on something, save the session, and continue working on it another time.

It's not some incredibly sophisticated long-term memory system, but it makes the agent much more practical to use.

Making installation easy

I also wanted someone to be able to try the project without spending an hour setting everything up.

So I made an installer that handles the initial setup.

The basic idea is:

curl -fsSL https://raw.githubusercontent.com/ANIRudH-lab-life/MINICODE/main/install.sh | bash

Then:

minicode --setup

and:

minicode

The default configuration uses Ollama and Qwen3 1.7B, so you can start experimenting with a local coding agent without needing a cloud API.

The funny part: small models are hard

Working with a 1.7B model has actually made me learn more about agents.

With a larger model, you can sometimes get away with a mediocre prompt or imperfect tool design.

With a small model, those problems become obvious.

If the tools aren't designed properly, it struggles.

If the context gets messy, it struggles.

If an error isn't explained clearly, it can get stuck.

That means I have to think much more carefully about how the agent architecture works.

And that's probably been one of the most valuable parts of building MINICODE.

It's still a work in progress

MINICODE is nowhere near finished.

There are still plenty of things I want to improve:

Better tool calling
Better context management
More reliable coding
Better error handling
More model support
Improved terminal UI
Better memory
More autonomous workflows

But I don't really see that as a problem.

The whole point of the project is experimentation.

I want to keep seeing how far I can push small local models.

Why I'm building this

For me, MINICODE is more than just another AI wrapper.

I'm interested in what happens when you take a relatively small model and give it the right environment, tools, and architecture.

Maybe the future of local AI isn't always about running the biggest model possible.

Maybe sometimes it's about making smaller models work better.

That's what I'm trying to find out.

If you want to check it out, the entire project is open source:

GitHub: https://github.com/ANIRudH-lab-life/MINICODE

I'd love to see what other people can do with it.

Under the Hood of JobRadar: 8 Job Sources, a 1.7B Model, Zero Cloud

Anirudh — Sun, 02 Aug 2026 05:28:42 +0000

Job searching is tab hell. You open six boards, re-read the same listings, and pay $30/month for tools that are just feed aggregators wearing an "AI-powered" sticker.

So I built JobRadar — a CLI tool that searches 8 job sources concurrently and scores every listing against your profile using a local LLM that runs on your own CPU. No API keys, no subscriptions, no resume leaving your machine.

The launch post covered the what. This one covers the how.

The pipeline

The whole thing is one linear pipeline:

query + profile.yaml
      │
      ▼
8 source adapters (concurrent) ──► normalized Job objects
      │
      ▼
local LLM scores each job 0-100 (skills, experience, salary, remote fit)
      │
      ▼
seen-jobs cache (SQLite, 7-day)  ──► ranked table + results.csv

In code, the search phase looks like this:

from concurrent.futures import ThreadPoolExecutor, as_completed

def search_all(sources, query, limit, max_pages):
    jobs = []
    with ThreadPoolExecutor(max_workers=len(sources)) as pool:
        futures = {pool.submit(s.search, query, limit, max_pages): s
                   for s in sources}
        for future in as_completed(futures):
            jobs.extend(future.result())
    return jobs

Eight adapters, one interface, all running in parallel. A query that used to take me 20 minutes of tab-hopping finishes in under a minute.

The sources: boards vs. direct ATS

Five of the sources are classic job board APIs:

Remotive — remote jobs
Arbeitnow — worldwide, paginated
RemoteOK — remote, good volume
Jobicy — remote with salary data
Himalayas — remote with seniority levels

The interesting two are Greenhouse and Ashby. These are applicant tracking systems that a huge chunk of tech companies use — and they have public career-page APIs. No auth, no scraping. You just hit their job board endpoint with a company slug:

class GreenhouseSearch(Source):
    def search(self, query, limit, max_pages):
        jobs = []
        for company in self.companies:          # e.g. gitlab, figma, stripe
            url = f"https://boards-api.greenhouse.io/v1/boards/{company}/jobs"
            resp = requests.get(url, timeout=10)
            jobs.extend(normalize_greenhouse(resp.json()))
        return jobs

That means JobRadar pulls roles straight from company career pages — GitLab, Figma, Stripe, OpenAI, Anthropic, Linear — without an account or an API key on any of them. The company list is a YAML file you can edit:

greenhouse:
  - gitlab
  - figma
  - discord
  - shopify
  - stripe

LinkedIn scraping exists but is off by default — it depends on undocumented HTML that breaks constantly, and it might violate their ToS. I'd rather ship without it and be honest about the tradeoff than bundle a ToS risk into the default path.

The rating engine: a 1.7B model on your CPU

This is the part people ask about the most. Every other tool I found uses cloud APIs (Claude, OpenAI) for scoring — your resume and search history go to someone else's server, and you pay per token. JobRadar runs qwen3-1.7b (a 1.1 GB GGUF) on your machine via Ollama or llama.cpp.

The rater auto-detects whatever local LLM server is running by scanning the standard ports:

_DEFAULT_PORTS = [
    ("http://localhost:11434", "Ollama"),    # Ollama default
    ("http://localhost:8080",  "llama.cpp"), # llama.cpp default
    ("http://localhost:1234",  "LM Studio"), # LM Studio default
]

If you have a bigger model installed, it picks that up too — you can override with --llm-model qwen3:8b and scoring gets smarter at the cost of speed.

Each job gets scored 0-100 across four dimensions — skills match, experience fit, salary fit, remote fit — with the model's reasoning captured so you can see why a job scored the way it did. Rating calls run concurrently (3 by default, --max-concurrency to tune) with retry logic for the occasional malformed JSON response.

Honest take: a 1.7B model is a good filter, not an oracle. It catches "this says Python but is actually a sales role" reliably. It does not have your gut feel about company culture, and it shouldn't — that's the point. The score is a starting point, not a verdict.

The cache: don't re-review the same jobs

Job boards republish the same listings constantly. JobRadar keeps a SQLite database of seen jobs (~/.jobradar/seen_jobs.db) with a 7-day window, so every run only surfaces what's new. --cache-days 30 to stretch it, --no-cache to see everything again.

The dashboard: FastAPI + vanilla JS

The CLI is the core, but there's a companion web dashboard — a FastAPI backend, SQLite storage, and a dark-mode SPA with a Kanban pipeline. Jobs flow from Discovered to Reviewing to Applied to Interviewing, cards are color-coded by match score, and there's a live terminal-style activity log showing the LLM scoring progress as it happens. It reads like a terminal because the whole product is terminal-first.

What I'd tell someone building this

Normalize early. Every source returns a different shape. Map everything to one Job dataclass at the boundary and every downstream step gets simpler.
Design for the offline case. Local LLMs are fast enough for filtering, and "no cloud, no cost, no data leaving the machine" is a genuinely defensible product position, not a compromise.
Be honest about limitations. The README says it plainly: the AI is a guide, not a decision-maker. That honesty has been the most effective marketing I've done — people respond to tools that don't oversell.
Direct ATS APIs are underrated. Board aggregators are a race to the bottom; the companies themselves publish better, fresher data through their ATS.

Try it

curl -fsSL https://raw.githubusercontent.com/ANIRudH-lab-life/job-radar/main/setup.sh | bash

Or browse the source: https://github.com/ANIRudH-lab-life/job-radar

Landing page: https://anirudh-lab-life.github.io/job-radar/

MIT licensed. Built with Python, Rich, FastAPI, SQLite, and a whole lot of tabs closed.

Also published: the launch post

I Built a Job Search Agent That Scores 200 Jobs With Local AI -- Zero Cloud, Zero Cost

Anirudh — Mon, 27 Jul 2026 02:36:02 +0000

Job searching is tab hell.

You open LinkedIn, Indeed, RemoteOK, Glassdoor. You re-read the same listings. You copy-paste the same cover letter. You pay $30/month for tools that just aggregate feeds and call it "AI-powered."

I wanted something better. So I built JobRadar.

What It Does

JobRadar is a CLI tool that searches 8 job sources concurrently and scores every listing against your profile using a local LLM running on your machine.

python -m jobradar -q "python developer" -p profile.yaml

That's it. Eight boards searched in parallel. Every job scored 0-100. Results saved to CSV. Total time: under a minute.

The Local AI Angle

Every other job search tool I found uses cloud APIs for scoring -- OpenAI, Claude, whatever. Which means your resume, your search history, your career preferences all go to someone else's server. And you pay per token.

JobRadar runs qwen3-1.7b (1.1 GB) on your CPU via Ollama. No API keys. No subscriptions. No data leaving your machine. The AI scores each job on four dimensions:

Skills match -- do you have what they need?
Experience fit -- does your level match?
Salary fit -- does it meet your range?
Remote fit -- does it match your preference?

Each job gets a score, a rating (Excellent/Good/Fair/Poor), and a reasoning paragraph explaining why.

The 8 Sources

Most job search tools scrape 1-2 boards. JobRadar hits 8 simultaneously:

Remotive -- remote jobs
RemoteOK -- remote-first jobs
Jobicy -- remote jobs with salary data
Himalayas -- global remote jobs
Arbeitnow -- international jobs
Greenhouse ATS -- 15 company career pages (GitLab, Stripe, Figma, etc.)
Ashby ATS -- 15 company career pages (OpenAI, Anthropic, Linear, etc.)
LinkedIn -- opt-in (may violate ToS)

The Greenhouse and Ashby sources pull directly from company career page APIs. No scraping, no auth, no fragility.

How the Scoring Works

You define a profile YAML:

name: Anirudh
title: Backend Engineer
skills:
- Python
- FastAPI
- PostgreSQL
- Docker
experience_years: 5
salary_min: 120000
remote_ok: true

JobRadar sends each job description plus your profile to the local LLM and gets back structured JSON with scores and reasoning. The model runs on your CPU -- no GPU required. On my machine (15GB RAM, no GPU), it processes about 9 seconds per job.

What Makes This Different

Feature	JobRadar	Cloud-based tools
AI scoring	Local LLM (free)	OpenAI API ($$)
Data privacy	Stays on your machine	Sent to cloud
Job sources	8 concurrent	1-3
Web dashboard	Yes (Kanban)	Depends
License	MIT	Varies
Setup time	`bash setup.sh`	Account + API key

The Web Dashboard

Beyond the CLI, there's a FastAPI dashboard with a Kanban-style pipeline to track your applications. Filters, search, config editor -- all running locally on port 3000.

Tech Stack

Python with Rich for terminal UI
Ollama for local LLM inference (or llama.cpp)
FastAPI for the web dashboard
SQLite for caching
requests + BeautifulSoup for scraping

Try It

git clone github.com/ANIRudH-lab-life/job-radar
cd job-radar
bash setup.sh # or setup.ps1 on Windows

# Pick Ollama (recommended)
python -m jobradar -q "python developer" -p profile.yaml

MIT licensed. No vendor lock-in. Your data stays yours.

GitHub: github.com/ANIRudH-lab-life/job-radar

If you find it useful, a star would mean a lot. If you have ideas for improvement, open an issue -- I read every one.