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

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:

1. Identify one repetitive task that takes them time every week.
2. Configure Hackesh around that task.
3. Let them use it on real work, with their permission.
4. Compare the workflow before and after automation.
5. 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.