Local models are usually presented as a destination: install a runtime, open a new chat, choose a model, and move your work there. That can be useful when the goal is to operate a local model directly. It is a poor fit when the workflow already lives in Claude Code or Codex.
Forjal starts from a different question: what if local execution became one capability of the agent you already use?
The distinction matters. A capable cloud agent and a capable local model do not need to compete for the whole workflow. They can have different responsibilities, with an explicit handoff between them.
Keep one supervisor
The supervising agent should keep the work that depends on broad judgment: understanding the goal, deciding what may be delegated, granting access, applying permissions, and reviewing the result.
Forjal handles the local execution path. It detects the machine, prepares a compatible deployment, publishes a compact capability contract, and runs exactly the model the supervising agent selected. If that selected path is unavailable, the run returns an error instead of silently switching models or devices.
The local model carries the bounded mission. It receives the context and workspace boundary granted for that run, does the work inside that boundary, and returns its result for review.
This keeps the user in one workflow. There is no second chat to monitor and no second tool stack to rebuild.
Delegate work with edges
Local execution is most useful when the task has a clear finish line and enough substance to justify the handoff. Examples include:
- tracing a bug across a defined set of code and tests;
- drafting an implementation, fixtures, or documentation from a clear goal;
- working through logs, transcripts, or documents and returning evidence;
- producing a large, reviewable output that can be written locally.
Short answers and open-ended product decisions often belong with the supervising agent. Delegation has overhead, and a smaller local model should not receive a task merely because it is available.
That is why a capability contract needs to describe more than what a model can do. It also needs to say when not to delegate, which limitations matter, and how much evidence supports each claim.
Make the boundary visible
A local run is useful only if its boundary is understandable.
Workspace access stays inside the directories and permission level granted by the supervising agent. External or effectful tools remain under that agent's control. Forjal does not store third-party tool credentials, and the cloud backend does not run inference.
Content sent to the local run stays on the computer by default. Claude Code and Codex are still cloud agents and continue to follow their own data and network policies, so this does not make the entire workflow local or offline.
The same discipline applies to hardware claims. A model can be a candidate before it is compatible with a hardware cohort, and it can be compatible before it is certified for a named capability. Availability alone is not evidence of quality.
Local where it fits
The most useful future for local AI is not a forced choice between local and cloud. It is a workflow in which the agent can explain why a bounded mission fits a selected local model, run it on an explicit path, and bring the result back for review.
The cloud agent remains responsible for the plan and the final judgment. The machine on the desk becomes part of the work.
That is the loop Forjal is building.