DEV Community: RISHABH KESHARI

I Built Hackesh: A Local-First AI Agent for Freelancers Who Want Automation Without API Bills

RISHABH KESHARI — Fri, 16 Oct 2026 21:46:59 +0000

Hackesh: Your AI Assistant, Your Machine, Your Rules

What if a freelancer could use an AI assistant to automate repetitive tasks without sending every request to a third-party AI provider or paying for every API call?

That question inspired me to build Hackesh, a local-first AI agent designed to make AI-powered automation more accessible to independent developers, freelancers, and small businesses.

My goal is simple: build an AI assistant that people can run, customize, and eventually use to automate the boring parts of their work.

Instead of treating AI as a remote API that my application depends on, I'm exploring what becomes possible when the model, agent logic, and tools are under the developer's control.

And I want to turn that idea into something people can actually pay for.

What I Built

Hackesh is a local-first AI agent built around open-weight language models and tool integration.

Many freelancers spend hours switching between applications, looking up information, and performing repetitive tasks. They often need automation but don't necessarily have the budget, infrastructure, or technical expertise to build sophisticated AI workflows.

Hackesh explores a different approach: an AI assistant that can reason about a request and use tools to accomplish useful tasks.

The project uses a locally running language model as its foundation, with an agent architecture that can be extended with additional tools.

The current development work includes:

Local AI inference: Running Llama 3.1 through Ollama instead of requiring a hosted model API for every interaction.
Tool integration: Connecting the agent to external capabilities so it can do more than generate text.
Calculator tool: Giving the agent access to a dedicated calculation tool.
YouTube integration: Exploring tool-assisted access to video-related information.
Gmail integration: Implementing OAuth-based email functionality, including a test of sending email.
Extensible agent architecture: Using LangGraph to organize the agent's execution and tool-calling workflow.

The interesting part isn't simply having a chatbot that answers questions.

It's building an assistant whose capabilities can grow through tools, workflows, and different models.

Who Would Pay for It?

My initial target users are:

Freelancers who want to automate repetitive administrative work.
Independent developers who want a customizable AI assistant.
Small businesses that need affordable workflow automation.
Privacy-conscious users who prefer keeping AI processing on their own machines whenever possible.

Rather than charging people for access to another generic chatbot, I want to explore selling practical automation: tools and workflows that save users time on specific tasks.

The long-term business direction is to offer useful, ready-to-run workflows, with optional paid customization and setup assistance.

The product must earn its place by saving users more time and money than it costs them.

Demo

Project: Hackesh AI Agent

[Add your working demo or a short screen-recording link here.]

The demo should show the actual application running, a request being processed by the local model, and at least one tool being invoked successfully.

I also want to demonstrate that the model is running through Ollama rather than relying on a hosted LLM API for the core inference workflow.

Code

GitHub repository: Hackesh AI Agent

The project is being developed with Python, Ollama, LangGraph, and tool integrations.

I want Hackesh to remain understandable and extensible, so developers can inspect how the agent works, experiment with its tools, and adapt it to their own workflows.

If you are interested in local AI agents, open-weight models, or practical AI automation, I'd love your feedback and contributions.

How I Built It

I built Hackesh around a simple architectural principle:

The language model should be replaceable, and the agent's capabilities should be extensible.

Here is the basic architecture:

User
  |
  v
Hackesh Agent
  |
  v
LangGraph Workflow
  |
  v
Ollama
  |
  v
Local LLM
  |
  v
Tool Execution
  |
  +---- Calculator
  |
  +---- YouTube Integration
  |
  +---- Gmail Integration

The model handles language understanding and helps determine how to respond to a request. The agent framework organizes execution, while tools provide specific capabilities.

1. Local Inference with Ollama

I use Ollama to run Llama 3.1 locally.

This allows the application to perform model inference on the user's machine instead of requiring a remote inference API for every prompt.

Local inference also gives me greater control over model selection, runtime configuration, and the development environment.

2. LangGraph for Agent Orchestration

I use LangGraph to structure the agent's workflow.

This makes it possible to build a more organized execution flow than a simple prompt-and-response loop.

As the project grows, I can introduce additional tools, routing logic, and multi-step workflows without tying every capability to a single hardcoded interaction.

3. Tools That Turn Responses into Actions

A language model that can only generate text has limited usefulness when a user wants something done.

Tools extend the agent beyond text generation.

For example, a calculator can handle calculations, while integrations can connect the agent to other services.

This separation also makes the application easier to test: the model, workflow, and individual tools can be examined independently.

4. A Foundation for Practical Automation

My next focus is moving from individual tool integrations toward complete workflows that solve specific problems.

For example, a freelancer-focused workflow could eventually help organize incoming requests, prepare email drafts, summarize project information, and assist with routine administrative tasks.

These are planned extensions, not capabilities I am claiming are already complete.

The objective is to make Hackesh useful for a real customer before adding unnecessary complexity.

Why Does Open Innovation Matter?

For Hackesh, open innovation isn't just a preference for open-source software.

It changes the economics, privacy model, and extensibility of the product.

1. No Mandatory Per-Request LLM API Bill

Hosted AI APIs can be convenient, but recurring inference costs can become a concern when building a product for freelancers or small businesses.

With local inference, Hackesh can run on hardware the user already owns, subject to the model's hardware and performance requirements.

Once the model is downloaded, ordinary inference does not require a separate hosted LLM API charge.

There are still costs: electricity, hardware, storage, maintenance, and development. Local inference is not free in an absolute sense.

However, it gives me another way to build an affordable product without making every interaction dependent on a metered inference service.

2. More Control Over Private Information

Freelancers regularly handle client correspondence, project details, business documents, and other sensitive information.

When inference happens locally, prompts sent to the local model do not need to be transmitted to a remote LLM provider.

That can reduce unnecessary exposure of sensitive information.

There is an important distinction, though: Hackesh also integrates with external services such as Gmail. Those integrations may transmit data to their respective providers, so the entire application cannot automatically be described as fully offline or completely private.

My goal is to make data flows explicit and keep processing local wherever practical.

3. Freedom to Experiment with Models

I don't want the entire product to depend on one AI provider's pricing, API limits, or model availability.

Using an open-weight model through Ollama gives me a practical way to experiment with locally supported models and evaluate their performance against my use cases.

Different models have different hardware requirements, response quality, and tool-calling capabilities. Being able to test alternatives is valuable when optimizing for a particular machine or workflow.

4. More Control Over How the Agent Behaves

The agent's workflow is part of the product.

Using LangGraph and modular tools lets me inspect and modify how tasks are executed rather than treating the entire system as an opaque remote service.

I can change the workflow, introduce new tools, add validation, and test different execution strategies.

That flexibility matters when moving from a general-purpose assistant toward a specialized product for a specific group of customers.

5. Building Something Sustainable

The most important business question isn't whether a model is open or closed.

It's whether I can deliver enough value for someone to pay for the result.

Open-weight models and local inference give Hackesh another way to control operating costs. That could make certain low-cost automation products more viable, especially for users who already have suitable hardware.

Open innovation gives me the freedom to experiment with that business model.

The real test is whether Hackesh can solve a sufficiently painful problem that someone chooses to use it regularly.

My Agent Session

I am documenting the development process as I build Hackesh.

[Add your DevRelay agent session here if available.]

I want people to see not only the final result but also how the project evolves: the architecture, tool integrations, debugging process, and decisions involved in building a local-first agent.

My First User

The next milestone is getting Hackesh into the hands of a real freelancer or small-business owner.

I want to start with a simple experiment:

Identify one repetitive task that takes them time every week.
Configure Hackesh around that task.
Let them use it on real work, with their permission.
Compare the workflow before and after automation.
Ask whether they would pay for the solution and what would make it more useful.

I am particularly interested in whether users value local inference, workflow customization, reduced dependence on hosted LLM APIs, or simply the time saved.

I don't want to assume that people will pay just because a product uses AI.

I want to find out what they actually need.

[After your first trial, add what the user tried, what worked, what failed, and whether they paid.]

Prize Categories

[Add only the partner prize categories for which Hackesh actually qualifies, based on the challenge rules.]

What's Next?

I started Hackesh to explore local AI agents, open-weight models, and tool-based automation.

Now I want to push it toward a more practical question:

Can a developer build an AI assistant that is affordable enough for freelancers, customizable enough for technical users, and useful enough that someone will pay for it?

The next step isn't adding more tools just to make the project look impressive.

It's finding one real problem, solving it reliably, and learning from the first person who uses it.

If you're building with Ollama, LangGraph, or open-weight models, I'd love to hear what you're working on.

And if you're a freelancer who spends too much time on repetitive tasks, tell me which one you'd want an AI assistant to handle first.

Let's build useful AI, not just another chatbot.

Benchmarking AI for Code Optimization: Which LLM Actually Writes the Most Efficient C/Rust Code?

RISHABH KESHARI — Sun, 11 Oct 2026 19:44:47 +0000

This is a submission for the Kaggle Benchmarking Challenge (https://dev.to)

## What I Benchmarked

As a third-year Computer Science and Data Science student, I frequently work with lower-level system operations where runtime efficiency is everything. While many public leaderboards evaluate LLMs on whether their code simply functions or passes a basic test suite, they rarely measure the structural efficiency, compilation overhead, or algorithmic complexity of the generated output.

For this challenge, I wanted to scratch a specific itch: How well do modern language models optimize low-level tasks like custom memory management, basic OS kernel loops, and heavy data sorting arrays in C and Rust? I created a suite of 15 tasks testing complex pointer arithmetic, memory allocations, and loop unrolling strategies to see which model generates execution-ready code with the lowest CPU overhead.

## Models Tested

I ran my evaluation across a diverse lineup of four models that represent distinct approaches to automated software engineering:

DeepSeek-Coder-V2-Instruct: Chosen for its massive open-source popularity and high specialization in deep contextual code logic.
Claude 3.5 Sonnet: The current industry gold standard for complex reasoning, multi-file software construction, and code architecture.
GPT-4o: Included as the baseline benchmark heavyweight to see how generalized logic handles aggressive compiler-level structural problems.
Gemini 1.5 Pro: Selected due to its massive context window capability, allowing me to feed complex hardware architecture specs directly into the prompt constraints.

## Findings

The results completely changed how I think about utilizing these models for low-level systems programming:

The Semantic vs. Performance Gap: While all four models achieved over a 90% pass rate for syntax and compiling cleanly, their execution performance diverged wildly. On complex C pointer manipulation tasks, DeepSeek-Coder-V2 generated code that executed up to 18% faster than GPT-4o because it successfully avoided redundant stack-to-heap copies.
Rust Safety Overhead: When generating Rust code, Claude 3.5 Sonnet consistently found optimal, zero-cost abstractions that pleased the borrow checker on the first try. Gemini 1.5 Pro, while structurally sound, frequently fell back on using unsafe blocks to force compilation when dealing with complex data ownership nodes.
The Big Surprise: The generalized reasoning model (Claude) slightly edged out the code-specialized model (DeepSeek) in code readability and commenting, but failed to match DeepSeek's micro-optimization flags.

If I were to expand this benchmark next, I would measure the models' ability to successfully optimize code specifically targeted at ARM vs. x86 assembly architectures.

How I Bypassed Server Costs to Build a High-Traffic Web App

RISHABH KESHARI — Sun, 11 Oct 2026 19:42:10 +0000

As a student developer, building an application that needs to handle thousands of concurrent users usually means one thing: a massive, terrifying bill from AWS or Google Cloud.
When I set out to build my latest project—a test series website designed to handle 2,000 to 5,000 concurrent students—I had a budget of exactly $0.
Here is the exact "Indie Hacker Architecture Stack" I used to build and deploy a high-traffic app completely for free:

⚡ 1. The Symmetrical Split (Frontend)

Instead of hosting everything on a single server, I decoupled the layers. I deployed the entire user interface to Vercel / Cloudflare Pages. Because they use global CDNs, thousands of students can load the landing pages, assets, and UI components simultaneously without costing a single cent or touching my backend infrastructure.

🏗️ 2. Distributed Compute (The Backend Engine)

To process quiz answers without crashing, I leveraged the Oracle Cloud Free Tier. They offer an incredibly generous 4 ARM CPUs and 24 GB of RAM for free. By making the architecture completely stateless and using JSON web tokens (JWT) for user sessions, requests can be balanced across instances seamlessly.

🌐 3. Bypassing Network Barriers (Development)

During local testing, my laptop was stuck behind strict campus Wi-Fi and mobile CGNAT firewalls. I used Cloudflare Tunnels (cloudflared). It established a secure outbound bridge from my local machine to the internet, giving me a public HTTPS URL without needing a public IP or touching router port forwarding.

🗄️ 4. High-Speed Database Pooling

A standard database locks up under thousands of rapid simultaneous writes. By pairing the stack with Supabase (PostgreSQL) and leveraging its built-in connection pooler, incoming quiz submissions are safely queued and written without hitting performance ceilings.
The Takeaway: You don't need a massive budget to build production-ready, scalable applications. You just need to leverage modern free-tier ecosystems and smart architectural design.