Frontier: Frontier-Model Reasoning, Local-GPU Execution

I did not build Frontier because I needed another AI agent that could write code. I built it because I did not want the frontier model in my workflow spending its token budget on every implementation step.

I wanted to keep frontier-model reasoning where I value it most: understanding a problem, deciding how a system should work, defining a change, and reviewing whether the result is correct. I also had local A100 GPU resources available to run Qwen3.8-27B. The question was how to connect those capabilities without reducing the workflow to a loose collection of prompts.

In my setup, the frontier tier includes ChatGPT 5.6 with Luna, Terra, and Sol, and ChatGPT 6 with Astra. Those are the model/persona names I use in the workflow. They occupy the architect role; they do not all have to run together. Qwen occupies the local execution role.

That distinction became the basis for SpyderColo Frontier: a private, MCP-based control plane that lets a frontier model delegate bounded coding work to local workers, inspect the returned evidence, and retain the acceptance decision.

The goal is to spend frontier tokens on engineering judgment, not on every cycle of code generation, tool output, and implementation repair.

Move the coding loop, not the architectural responsibility

A coding session involves more than generating a final patch. There is source inspection, editing, test output, failed attempts, and repeated context. Having a frontier model perform that entire loop means using frontier-model context for all of it.

My approach is to move the bounded implementation loop to Qwen on the A100s. The frontier model defines what needs to change and what success looks like. The local model works through the implementation. The frontier model then evaluates the actual diff and validation evidence rather than blindly accepting a worker's answer.

The diagram shows where model work is placed, not a measured savings percentage. Planning and review remain at the frontier tier; implementation iterations move to local inference.

This is not an attempt to make a 27B local model interchangeable with every frontier model. It is an attempt to give each tier a useful job. A bounded task with real source, explicit constraints, and a testable result is a different problem from owning the full engineering conversation.

Local inference still consumes tokens, electricity, and GPU time. Delegation and review still consume frontier tokens. I am not claiming a measured cost reduction or a universal reduction in total tokens across both tiers. The system changes which model has to carry the coding work. Keeping contracts focused and avoiding unnecessary replay of local execution history are important to making that trade worthwhile.

I approached it as a network architect

My instinct with this problem was to define the traffic paths and responsibility boundaries before treating it as an agent prompt.

There is a control path for task requests, policy, ownership, and review. There is a local execution path for model inference and tools. There is an evidence return path for the artifacts the architect needs to inspect. Combining those into an unrestricted remote shell would have been easier to demonstrate, but it would not have produced the system I wanted.

Frontier exposes the engineering operations through Model Context Protocol. Python APIs implement the lifecycle. PostgreSQL stores contracts, leases, events, and review decisions. An OpenHands runtime executes inside a Docker workspace, using the configured model proxy to reach Qwen3.8-27B on my local A100s. An authenticated artifact bridge returns the result for review.¹

The frontier model reaches the private control interface through the secure MCP tunnel. The repeated OpenHands/Qwen coding loop stays on the local execution side. The internal LibreChat access path is another client of the same control plane, not a different execution system.

The deployed server exposes 30 MCP operations covering discovery, project management, task submission, state inspection, evidence, review, and task control. The important part is not the count. It is that the architect can coordinate the workflow through defined operations instead of receiving general-purpose authority over the worker host.²

The model behind the architect role can change without changing the contract the worker understands. That is why the durable role is called Frontier Architect, while Astra, Luna, Terra, and Sol are the identities using it.

How Astra dispatches work over the tunnel

Consider a request to repair a clipped UI element in an already-onboarded repository. I want to tell Astra what is wrong, not manually orchestrate every file edit.

Astra first inspects the available capabilities, project registration, execution profile, and worker state. It then turns the request into a contract: use the registered source, change only the relevant component or stylesheet, preserve the interactions, and satisfy explicit validation and acceptance criteria. For ordinary repository work, the route is registered_project with coding-registered-project.

The call to submit_task_v2 traverses the secure MCP tunnel. The tunnel client on my private control host forwards it to the loopback MCP service, which invokes the task API. The API validates the contract and queues a durable task in PostgreSQL. Astra receives a task ID; it does not hold a connection open while Qwen writes code.

An eligible worker pulls that task from the queue. "Astra dispatches work" describes the overall workflow, not a direct push into the GPU or an SSH session to the host.

This is the intended request, local-execution, and review sequence for an onboarded project. The tunnel client maintains the private-side connection; arrows show logical request and response direction. Local inference does not pass through Astra.

The worker prepares an isolated per-attempt Git clone and worktree, records the resolved source commit, and starts OpenHands. Qwen then works against actual source through the agent's tools. That is where the repeated implementation context belongs.

When execution finishes, the worker checks the change scope, runs the configured deterministic validation, and captures the evidence. Astra calls the inspection and verification tools through the same tunnel path. The API retrieves artifact bytes through the authenticated bridge and checks their recorded hashes and sizes before returning them.

Astra reviews the result. It can approve an acceptable attempt or issue a bounded revision such as: "The title is visible, but the detail line still clips at the specified width. Revise only the existing CSS scope and preserve the node coordinates." Qwen performs that correction locally; Astra retains the final decision.

A contract is what makes the split useful

A local worker cannot repair source it was never given. That sounds elementary, but it was one of the most important lessons from building the system.

An early repair request described files in an existing website while selecting an empty workspace. The worker received an empty directory and spent the run reasoning about reconstructing a baseline. The local model was doing work, but not the work the project needed.

The fix was not another paragraph telling the model to be careful. Frontier makes source an explicit part of the contract: a registered project, a staged snapshot, a verified artifact, or a genuinely empty workspace. Admission rejects incompatible workspace/profile combinations and the observed contradiction between an empty workspace and metadata asserting existing source.

That matters to the token objective. Offloading an incorrectly specified task does not create efficiency; it creates local rework and another frontier review cycle. A good contract is both a correctness boundary and a way to avoid wasting model work.

Persistent project instructions reinforce the same routing. A concise AGENTS.md can point a top-level Codex session toward Frontier and link to the repository's architecture and validation guidance. An explicit anti-recursion rule tells an already-delegated worker to execute its task rather than delegate it again. Documentation establishes the convention; backend checks enforce the parts that cannot safely depend on convention alone.³

Durable state instead of a long-running conversation

PostgreSQL is the operational source of truth. Workers claim eligible tasks using row locking and FOR UPDATE SKIP LOCKED. Each attempt has a worker identity, a lease, a source identity, its own workspace, and recorded events. Required capabilities have to match the worker; the scheduler does not silently weaken the task to find somewhere to run it.⁴

This lets the engineering task survive independently of a particular chat turn. Astra can inspect a task later without reconstructing the local model's entire conversation. A failure remains diagnosable, and a revision can retain the same logical task identity while producing a new attempt.

It also keeps a critical distinction visible: a heartbeat shows that the worker is alive, not that it is making useful progress. The platform has an execution-time limit and a controlled active-termination operation. Termination records the decision to cancel; the worker then requests cooperative interruption. That is deliberately different from giving the architect a generic process-killing tool or claiming that a database update instantly proves cleanup.

I made the lifecycle explicit because failure is normal

I designed the task state as an operational lifecycle rather than a single “running” flag. A task can be queued, preparing source, running, validating, ready for review, approved, cancelled, or failed. Those states are useful because they tell me what evidence ought to exist and which actor is responsible for the next transition.

For example, a task that has been claimed but has not prepared source is a worker or workspace problem; it is not an inference-quality conclusion. A task with artifacts but no completed validation is not ready to approve. A review-ready task represents a completed attempt and evidence boundary, not a deployment. The system records those distinctions so I can diagnose real operational behavior without conflating a worker heartbeat, a model response, and an accepted engineering change.

Leases make the same point in a distributed form. A worker has to maintain ownership of an eligible attempt; a stale lease can be recovered, while an active task is not silently reassigned. That protects against two workers editing the same logical task at once and gives the review layer an unambiguous attempt identity.

The return path is evidence, not confidence

For registered-project coding, Frontier produces six standard artifacts: the diff, Git status, git diff --check output, deterministic validation output, a workspace manifest, and a worker report.

The API recomputes SHA-256 and byte counts on the fetched artifacts. This establishes that the evidence being reviewed matches the recorded output. It does not establish that the implementation is good. That is still the frontier model's review responsibility.

This is also how I avoid erasing the benefit of delegation. Astra needs enough source context and result evidence to make a sound decision; it does not need every intermediate local tool message copied into its conversation. Selective evidence is not permission for superficial review. A narrowly scoped diff is useful precisely because the contract makes it possible to evaluate that diff against a clear objective.

Approval is the delivery boundary I chose for this project. It records that a specific attempt was accepted. It does not merge into main, push a branch, or deploy a website. That separation is intentional: generating and reviewing a change are different responsibilities from landing it in a live system.

The tool boundary is intentionally narrower than the workstation

The Frontier Architect does not receive arbitrary shell, GPU, or SSH control over the private environment. It can discover registered projects, submit a bounded task, inspect state, retrieve the recorded evidence, and register an approval or revision through typed MCP operations. The local worker receives the source and the execution environment appropriate to its attempt; it does not decide its own acceptance criteria.

That design reflects how I think about network and infrastructure automation as well. Observation, proposal, execution, and approval are different capabilities with different consequences. A well-described operation is easier to authorize, audit, and retire than an unrestricted interface. The control plane's job is not to make every action possible. Its job is to make the intended action reviewable and to make unsafe shortcuts harder to take accidentally.

Getting the boundaries right took real systems work

The failures that mattered were not all model failures.

A linked Git worktree passed host-side inspection but failed inside the container. Its .git pointer led to administrative metadata in the private clone, which was still root-owned and inaccessible to the sandbox's non-root identity. I corrected ownership on the per-attempt clone, not on the shared source mirror.⁵

Validation exposed another boundary. A login shell loaded startup files and disturbed the intended Python environment. Switching that path to a non-login shell preserved the supervisor's configured toolchain. Replaying the actual validation command demonstrated the correction.

The SDK required the same attention to concrete behavior. An async-looking arun() method on the remote conversation implementation delegated to synchronous run(). The adapter needed to use the remote runtime's native timeout rather than assume that a method name guaranteed asynchronous execution.

I built Frontier through an AI-assisted implementation process. My responsibility was the architecture, the operational decisions, and following failures across the actual network, process, filesystem, and runtime boundaries. Generated code still had to earn its place through real execution and review.

The delivered result

The successful registered-project acceptance test used a resolved source commit and a strict one-file scope. The local worker produced the requested 47-byte file, the configured unittest passed, all six required artifacts verified, and the frontier-model reviewer accepted the result. Worker execution completed in approximately 83 seconds from claim to completion.²

That is a concrete end-to-end result, not a token-savings benchmark. It demonstrates the path I needed: frontier-model instruction, local execution, deterministic checks, verified evidence, and frontier-model approval.

There are sensible refinements for a broader deployment, including richer token accounting, stronger validation isolation, and more failure-path testing. Those are operating and expansion considerations, not a different definition of this project's outcome. I built this for my private environment and its trusted-workload boundary, rather than presenting it as a general-purpose multi-tenant execution service.

For that purpose, Frontier is complete and operational. It lets me retain the reasoning and oversight of Astra, Luna, Terra, or Sol while assigning the coding loop to Qwen on infrastructure I already control. I no longer have to choose between frontier-model judgment and local-model execution: the system gives them distinct jobs, with a contract and an evidence trail connecting the two.

Evidence and references

Footnotes

1. Model Context Protocol, Streamable HTTP transport specification. The tunnel and execution layout described here are specific to my SpyderColo deployment. ↩

2. SpyderColo build and acceptance records, September 2026. The accompanying verification summary records the successful registered-project smoke task, exact output identity, six verified artifacts, and observed timing. The 30-tool figure is the deployed server surface; clients need its current action registration. No measured token-savings percentage or cost benchmark is asserted. ↩ ↩²

3. OpenAI, custom instructions with AGENTS.md. ↩

4. PostgreSQL 17, SELECT and row-locking behavior. ↩

5. Git, linked worktrees and their administrative metadata. ↩