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

A developer built Hackesh, a local-first AI agent that runs open-weight language models through Ollama and orchestrates tool use via LangGraph, targeting freelancers and small businesses who want automation without per-call API bills. The Python-based agent uses Llama 3.1 for local inference and ships with calculator, YouTube, and Gmail tool integrations, with the developer planning to sell ready-to-run workflows and paid customization rather than chatbot access.

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. 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: 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. My initial target users are: 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. 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. GitHub repository: Hackesh AI Agent https://github.com/24f3003274-RISHABH/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. 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. 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. 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. 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. 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. For Hackesh, open innovation isn't just a preference for open-source software. It changes the economics, privacy model, and extensibility of the product. 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. 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. 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. 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. 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. 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. 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: 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. Add only the partner prize categories for which Hackesh actually qualifies, based on the challenge rules. 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.