This startup kept Claude and Codex and moved the paperwork to local AI
Grayhat Developers tried replacing its paid coding agents, then put local models to work on documentation, tickets and handoffs. Its case study shows how to test the split.
A developer asks a coding agent to fix a bug in a service. First the agent has to find the original ticket, retrieve a few product decisions and work out which requirements are current. After the patch, somebody has to turn the remaining work into tickets that a designer or support lead can see. The code change is only one part of the job, yet all of it can land on the same paid model.
Grayhat Developers, a software company of fewer than 40 people, described what happened when it separated those jobs in a November 5, 2026 preprint. Its engineers had tried self-hosted models on development work and found that replacing their commercial coding agents made some repository tasks slower or harder. They kept those agents for complex changes and moved a share of document retrieval, preparation and ticket synchronization to a local service.
The interesting question for another small team is which part to move first. Grayhat's experience offers a concrete starting point, an estimate worth unpacking and an onboarding mistake that can sink a pilot before the team learns anything about model quality.
A bug fix pays a context toll before it touches the code
Grayhat used Outline for documentation, Plane for work tracking and ERPNext for organizational information. The team had already put those services on an office machine and connected its identity setup through Authentik. It hosted the connectors for Model Context Protocol, or MCP, on the same machine. A second machine handled model inference. The point of that separation was practical. The documentation and ticket systems could keep serving their ordinary interfaces while model workers consumed computing resources elsewhere.
The process described in the paper involves human handoffs. A teammate uses the internal model to retrieve and condense material from the wiki or issue tracker. The relevant parts can be placed in a repository file for a coding agent. After working through the repository, a teammate can bring the next steps back to the internal assistant, turn them into ticket drafts and send them to the tracker. The paper presents direct agent-to-agent communication as future work. A human can already see the information at the boundary and decide whether it belongs on the other side.
The handoff points in Grayhat's workflow. Original illustration by Telli.sh, based on the November 5 case study.
Say a customer reports that an export repeats rows. The original report includes a private account reference and a transcript with no bearing on the bug. A local assistant can find the current export rules, the owner of the service and the previous workaround. The engineer can then write a brief containing a synthetic example and the expected row count. The coding agent gets what it needs for reproduction. The sensitive material stays in the internal systems because the person chose what crossed the boundary.
Keep the original links attached to the internal draft. When requirements disagree, the reviewer can see whether a proposed rule comes from a recent decision or an old workaround. A locally generated summary that leaves its sources behind still creates a version of the problem it was supposed to solve. The next teammate is stuck figuring out which description to trust.
The team bought capacity and estimated how much of it was movable
The authors report a commercial AI baseline of about $325 a month, made up of about $175 for seven Claude seats, $140 for seven Codex subscriptions and $10 in credits. They also report more than 25.93 billion recorded tokens across the services. The paper does not establish that those recorded tokens belong to the same billing interval as the $325. Use each number for what it measures rather than dividing one by the other to obtain a token price.
Grayhat's team estimated that context transfer, documentation and project coordination accounted for 30–40% of its commercial AI workload. The authors reasoned that the local system could absorb about 90% of that category. Multiplying the ranges gives 27–36% of the overall commercial workload. Expressing that share as a fraction of $325 yields about $88–117 a month. These are workload and cost-equivalent estimates from the November 5 case study. The paper did not run a controlled before-and-after billing experiment.
Grayhat's estimate starts with a share of work and ends with a cost equivalent. Original illustration by Telli.sh.
| Figure from the preprint | What it represents | How to use it |
|---|---|---|
| $325 per month | Reported baseline commercial subscriptions and credits | Establish an equivalent baseline from your own bills |
| 30–40% | Estimated share of work spent on coordination and context | Track the recurring tasks before installing another service |
| About 90% | Estimated locally addressable share of coordination | Check results task by task with the people who accept them |
| 27–36% and $88–117 per month | Estimated displaced workload and its baseline cost equivalent | Compare against invoices separately from model activity |
| $10–30 per month | Local model operating cost in the authors' table | Account separately for equipment and maintenance time |
The distinction matters when people are billed by seat. If seven developers still need their subscriptions for complex work, a reduction in usage can leave the next invoice untouched. The gain might show up as capacity for another set of patches, less pressure from usage caps or fewer overage purchases. A team billed per request may see an earlier change, but repeated retries and slow queues can replace some of the apparent savings. If the team has to buy a new GPU and pay somebody to keep it available, those costs belong in the comparison too.
Pick a denominator you can review. The number of tickets drafted is easy to count, but a ticket that the project lead rewrites from scratch leaves little evidence of savings. Measure accepted briefs and tickets, and record edits that change a task's meaning. Once reviewers can identify acceptable output consistently, track the effort required to produce it.
The second interface changed who had to do the setup
The first rollout used LobeHub. Engineers received instructions to connect their own interface to the organization's internal tools. The authors report that promising demos did not turn into regular use. People had to know which connector to select, where it lived and how to authenticate. Each extra choice got in the way of the first useful answer.
Grayhat's second interface had its work tools configured centrally. Figure 2 from “Create Your Own Work Stack” by Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz and Abdullah Aamir, CC BY 4.0.
The team switched to a centrally configured LibreChat deployment. Users could see the configured tools and authenticate when accessing them. The authors counted eight setup and onboarding comments from 11 structured interviews about the first version. The second version generated three comments in that category through unstructured Discord feedback. The two numbers describe separate collection methods. They help identify the onboarding problem, but they cannot tell us how much adoption rose or how many employees stopped encountering it.
Design the first session around the smallest real task. A project lead who signs in to look up the acceptance criteria for an issue should be able to see whether the tracker is connected and which account is active. An engineer who wants to draft three tickets should be able to review them before posting. A team that teaches people to configure connectors before they can find their own work risks measuring patience instead of usefulness.
Central setup does introduce a new responsibility. Someone needs to maintain the approved connector list, rotate credentials and explain who can change permissions. A central deployment can otherwise turn one person's bad configuration into everyone's problem. The benefit is that the team can fix a recurring setup issue once and give the same correction to everyone using that service.
Give the local system jobs whose output has a clear owner
Issue triage makes a practical first candidate. The internal assistant can group duplicate reports and propose a summary with source ticket links. The project owner decides whether two reports are actually duplicates and whether a merged description omits a condition. The assistant can draft a comment explaining the grouping. A human knows what has happened because the update has a visible owner.
Documentation maintenance is a different job. Suppose a change moves a setting from one screen to another. The assistant can find the outdated help pages, identify which product editions they cover and prepare proposed edits. An editor verifies the current navigation and publishes the correct changes. A more powerful remote model adds little value if the hard part is accessing the current internal pages and preserving the scope of each article.
Complex coding is the counterexample. A database migration can require inspecting historical data contracts, modifying more than one service and validating a rollback. Grayhat found that its tested local setup struggled on larger repository work, especially when the model needed broad context and timely inference. The study describes the team's hardware, models and experience. It supports testing locally on your own workload before expanding the assignment.
Use a restricted path for a task that mixes simple formatting and sensitive data. Sending a draft outside the network may still expose information even when the original tools run on premises. If a task requires a remote handoff, approve the destination and produce a minimal artifact for that destination. When an internal result lacks approval, keep it in the internal review queue. A timeout deserves a visible error rather than a surprise transfer.
A short pilot can separate useful work from infrastructure chores
- Define three outputs. Pick a linked ticket brief, a documentation edit and a draft issue. Write one sentence for each that says who accepts it and what evidence is required. Keep an example of a failed output alongside a good one, including mistakes that are easy to overlook.
- Measure the current path. For one ordinary workweek, count completed examples, substantive corrections and time spent finding context. Record commercial usage against the workflows where you can. Note whether removing the tasks would actually change billed seats or overages. Keep a separate record of work that the team avoided doing altogether.
- Connect one internal tool. Begin with read access and a named project. Confirm that an authorized employee can retrieve a known issue and that somebody outside the project cannot. Limit the pilot to a small set of people who already do the selected work. Offer a clear way to finish the task manually when the tool fails.
- Compare drafts before allowing writes. Ask the same reviewer to accept or reject outputs using the same criteria. Record links that point to the wrong issue, stale facts and unsupported conclusions. Add a preview, approval and durable record before granting the assistant permission to update a real tracker.
- Inspect what moved. Compare accepted work, time to review, active use and actual invoices. Add the time spent on machine upkeep, downtime and connector changes. Include setup help given directly to users. An application that works after a specialist spends ten minutes coaching each person is still incurring an onboarding cost.
If you already run a local model for developers, try this beside ordinary traffic. Queueing shows up when several people start work at the same time, and a service that handles one prompt quickly can still make three people wait. Give time-sensitive jobs a way to show progress and a way to return to the normal manual path. That makes the pilot usable while the team learns where its workload fits.
Grayhat's appendix gives some scale for this comparison. Its tools machine used 16 GB of system memory, while the separate inference machine had 32 GB and an RTX 4080 with 16 GB of VRAM. The team reports adding network monitoring, scheduling and an uninterruptible power supply as operating needs became clear. Those are useful inputs for budgeting a pilot. They are observations about running a service that colleagues depend on, in addition to the cost of making a model answer.
Decide where the next hour of AI work belongs
The reusable idea is to separate context preparation from specialized reasoning and give each handoff an owner. Start with a job that repeats often and produces an artifact your team already knows how to review. Measure the work it takes to accept that artifact, then decide whether the local route deserves another task. Grayhat's experience gives you a way to make that decision while keeping the coding tools that still earn their place.
Sources
- Grayhat Developers preprint, November 5, 2026
- Full paper, including workload estimates, infrastructure and Figure 2
- Figure 2 original image
- CC BY 4.0 license for the paper's figure
For a searchable record of the discussions behind a handoff, Create a Telli.sh account.