A scaffold job sat unfinished when a train tunnel dropped the laptop link for several minutes. The editor still held unsaved notes, a private environment file, and a patch from the previous round. A free remote server looked cheaper than another local retry, yet the payload still named a credential path. Seat choice had to protect that path before anyone compared latency or a zero invoice.
Local-first placement keeps the working set on the machine that already holds the files, the secrets, and the editor state. A cloud seat can still win when the payload is non-secret, the laptop is thermally constrained, and the link estimate is honest. The operator describes MonkeyCode as an open-source project and points to free model access plus a free server option.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Those availability notes do not state a token ceiling, a hardware profile, a region, or a promise that the offer remains unchanged. A reader who needs a live number should treat any blog figure as unverified until a primary page is checked. This draft therefore teaches the seat decision, and it leaves allotment arithmetic outside the article on purpose. The seat workflow remains useful to a local-first reader even if every product name is removed.
What the seat decision protects
Latency here means the wait from a tool request to a reviewable diff, including transfer and a human pause. A remote seat can spare a hot laptop, but it adds a round trip that fails when the link drops. Secrets include tokens, private keys, customer samples, and unpublished patches that must not cross the trust boundary. Offline means the same job must resume after sleep, tunnel loss, or a server that is not offered.
A free server wins only when the payload is a public scaffold and the link can last the whole round trip. The same seat loses the moment any secret rides along, even if the invoice stays at zero. Treating a free seat as a default compiler hides the failure that matters most for local-first work. That failure is a published bundle that nobody on the team can recall after the upload completes.
A five-step seat workflow
Step 1 — Inventory the working set
The first step inventories the working set before any remote call is considered for the job. List source files, environment files, prompt text, and tool outputs that the job will actually read. Mark each item as public, internal, or secret, using repository policy rather than a filename guess. Stop the remote path if any secret item is required for a correct and complete result.
Step 2 — Estimate the link and the heat
The second step estimates the link and the thermal budget on the laptop that already holds the files. Record whether the machine is on battery, whether sleep is likely, and whether the last similar trip felt too slow. Keep the job local when sleep or tunnel loss is the likely next event during the wait. A free remote seat cannot reconstruct a local diff that never left the editor in the first place.
Step 3 — Split scaffold text from secrets
The third step separates scaffold text from secret-bearing context before a prompt is assembled at all. Scaffold text covers public boilerplate, published interfaces, and tests that contain neither credentials nor customer samples. Secret-bearing context includes connection strings, private keys, customer samples, and source patches that are still unreleased. Send only the scaffold lane when a remote seat remains under consideration after that split is done.
Step 4 — Record the classifier lane
The fourth step runs the local classifier from the next section and records its lane in the job note. Accept a remote seat only when the lane is remote_ok and a reviewer has confirmed the redaction. Otherwise keep the model loop or the editor loop on the laptop, even when that loop is slower. Re-classify the manifest after every edit that touches environment files, new fixtures, or assembled prompt text.
Step 5 — Replay before apply
The fifth step replays a remote result against the local tree before any hunk is applied. Reject the patch when the local tree changed during the wait, because overlap is a separate defect from seat choice. Store the classification record beside the patch so a later review can see why the seat was allowed. Do not treat a green remote response as permission to skip that local replay check.
Lane table
The table below is a review proposal for the three lanes, not a benchmark collected from a live fleet. It names no model, no token ceiling, no region, and no server size, because those facts were not verified here. Readers should treat the current project documentation as the only source for allotment and hardware claims. A blog note that freezes those numbers will be wrong the week the vendor offer changes.
| Lane | Latency pressure | Secret class | Link assumption | Seat |
|---|---|---|---|---|
| local_required | Any | Secret or unknown | Any, including offline | Laptop only |
| local_preferred | Low or moderate | Internal, no export | Unstable or sleep likely | Laptop first |
| remote_ok | High local heat | Public scaffold only | Stable for the whole trip | Free server may be used |
A local classifier for the drill
The Python sample below is an unexecuted proposal for a repository hook, and it is not a vendor command. It does not call a remote API, and it does not claim to measure MonkeyCode latency or capacity. It only classifies a manifest that the operator already trusts enough to feed into the hook. Suffix rules are a deliberate backstop, not a substitute for an honest human secret label.
#!/usr/bin/env python3
"""Proposed local seat classifier. Not a vendor CLI. Unexecuted sample."""
from __future__ import annotations
import json
import sys
from pathlib import Path
SECRET_SUFFIXES = {".env", ".pem", ".key", ".p12"}
SECRET_NAMES = {".env", ".env.local", "id_rsa", "credentials.json"}
def classify(manifest: dict) -> dict:
files = manifest.get("files", [])
reasons = []
secret = False
for item in files:
path = Path(item.get("path", ""))
name = path.name
if item.get("class") == "secret":
secret = True
reasons.append(f"marked secret: {path}")
if name in SECRET_NAMES or path.suffix in SECRET_SUFFIXES:
secret = True
reasons.append(f"sensitive name: {path}")
if item.get("contains_secret_sample"):
secret = True
reasons.append(f"sample flag: {path}")
offline = bool(manifest.get("offline_required"))
sleep_likely = bool(manifest.get("sleep_likely"))
stable_link = bool(manifest.get("stable_link"))
public_only = bool(manifest.get("public_scaffold_only")) and not secret
if secret or not public_only:
lane = "local_required"
reasons.append("secret or non-public payload stays on the laptop")
elif offline or sleep_likely or not stable_link:
lane = "local_preferred"
reasons.append("link or sleep risk favors local completion")
else:
lane = "remote_ok"
reasons.append("public scaffold and a stable link may use a free server")
return {"lane": lane, "reasons": reasons}
def main() -> int:
manifest = json.loads(Path(sys.argv[1]).read_text())
print(json.dumps(classify(manifest), indent=2))
return 0
if __name__ == "__main__":
raise SystemExit(main())
The sample always exits zero after printing JSON, so a check must read the lane field rather than the process status. A wrapper that fails the build on local_required would turn a classification into a gate, which this draft does not require. Teams that want a gate should add that policy in their own wrapper after reviewing the false-positive cost. The script itself stays a reporter so a laptop drill cannot block an editor session by accident.
Two fixtures and the commands
The secret-leaning fixture belongs in manifest_secret.json, and every stored value in that file should stay fictional. The internal class on the environment file is a trap for reviewers who think a soft label is enough. The sleep flag and the unstable link are present so the fixture fails for more than one reason. A single-reason fixture can hide a logic bug when one condition is edited during a later drill.
{
"files": [
{"path": "src/app.ts", "class": "public"},
{"path": ".env.local", "class": "internal"}
],
"public_scaffold_only": false,
"offline_required": false,
"sleep_likely": true,
"stable_link": false
}
Place the contrasting public fixture in manifest_public.json so the file contains no sensitive filename of any kind. Every flag in that file is set so the proposed hook can reach remote_ok without a special case. Changing any one flag should move the lane away from the free server, which is the point of the contrast. Do not paste a real repository path into either fixture while demonstrating the drill to a teammate.
{
"files": [
{"path": "src/app.ts", "class": "public"}
],
"public_scaffold_only": true,
"offline_required": false,
"sleep_likely": false,
"stable_link": true
}
The first sample manifest should classify as local_required because its environment file matches a sensitive name rule. A human label of internal does not override that sensitive-name rule inside this proposed local hook design. The second manifest should classify as remote_ok only when every flag matches the public and stable case. These checks specify the intended hook behavior, and they were not executed against a live service here.
Create a temporary directory, save the script as seat_classifier.py, and save each fixture under a distinct name. Run the two commands below and confirm the lanes match the specification before wiring the hook into a check. Keep the fixtures free of real credentials, using filenames alone to exercise the sensitive-name rule in the script. Delete the temporary directory when the drill ends so sample names are not mistaken for live secrets.
python3 seat_classifier.py manifest_secret.json
python3 seat_classifier.py manifest_public.json
Consider a manifest where src/app.ts is public and .env.local is marked internal by a hurried reviewer. The name rule still forces local_required, because an internal mark is not a license to upload the file. That outcome is intentional, and it will annoy people who believe a free server should always absorb scaffold work. The annoyance is cheaper than explaining a leaked connection string after a short public demo ends.
A second failure appears when stable_link is copied from yesterday after the laptop has already entered a tunnel. The classifier will trust the flag, so the human who sets stable_link owns the accuracy of that claim. The hook does not ping the network, because a successful ping can still precede a failed later upload. Pair the flag with a fresh observation taken in the same minute as the classification run itself.
What the job note should keep
Each classification run should leave a short note that a reviewer can read without opening the model transcript. Record the lane, the manifest hash, the clock time, and the person who set the public scaffold flag. Omit prompt bodies and secret values from that note, since the note may later be copied into a ticket. A missing note means the remote result should be treated as unreviewed, even when the diff looks plausible.
When the free server is the better seat
A free server is the better seat when the classifier returns remote_ok and the laptop is the scarce resource. Public boilerplate, a long formatting pass, and a test scaffold with no customer data fit that lane. Free model access can cover that pass without a paid local accelerator, if current terms still include the expected seat. The win is heat and cost, not a wider trust boundary than the laptop already provides today.
The free server loses when the job needs files that cannot be redacted without breaking the result. It also loses when the tunnel is the real network, or when the editor will keep changing the tree. It loses again when the team cannot name who is allowed to upload the assembled prompt text. In those cases the slower local loop is the correct result, not an embarrassing engineering fallback.
Limitations and who should skip it
This checklist does not discover secrets hidden inside arbitrary binary fixtures or renamed database dump files. It does not prove that a remote provider retains nothing after the response returns to the client. It does not replace a legal review when the payload includes regulated, contractual, or customer-owned data. It assumes a human can set the public scaffold flag without treating hope as a classification result.
Teams that cannot staff that label should keep every agent loop on the laptop until they can. People who need a guaranteed capacity figure, a named model, or a fixed free period should look elsewhere. Allotment size, hardware, and duration were omitted because they go stale and were not checked against a primary document. Operators should open the current MonkeyCode project page and confirm free model access plus free server terms before use.
Top comments (0)