Persistent machinery around a local LLM

The Saient agent works inside your local project

Choose a project and local GGUF model. The dev.6 Linux beta adds tools, saved state, checks and bounded recovery around the model's proposals. Review its separate terminal, Planner and Long Project permissions before allowing changes.

Dev.6 Linux beta: Saient can inspect files, execute approved tools, keep project state and check results. Its controller now retains verified repair history and exact command output. Coding reliability is still uneven: review changes and run independent checks before relying on the result.

Updated · Beta feature scope; historical screenshots are labelled below.

Real interface

Historical agent workspace: v1.0.9

The screenshot shows a local project tree and the Files, Terminal, Planner, Memory and Checkpoints tabs. The top-right Write OFF control belongs to the editor/Planner surface; it does not describe every terminal permission.

Saient agent screen with a local project file tree and Files, Terminal, Planner, Memory and Checkpoints tabs

Saient agent workspace

Captured from the installed desktop app. The project path is local; no cloud IDE is shown or implied.

Architecture boundary

What Saient supplies vs what the host model supplies

LayerResponsibility
Local LLM hostProduces candidate plans, tool-call content, explanations and other generated text. Different models or sampling settings can change those proposals.
Saient stateStores drives/goals, persistent agent state, episodic/semantic/procedural memory, checkpoints and provenance.
Saient controlArbitrates proposals, selects actions, runs the autonomous loop, handles refusal/repetition recovery and records verification feedback.
Saient desktop bridgeConnects the runtime to the chosen project, file tools, PTY terminal, permission controls and local model server. Host shell execution is not an OS sandbox.
Both layers can fail. The model proposes actions; Saient decides what context to supply, which actions may run and what evidence is retained. Dev.6 fixes include controller feedback that previously hid a correct newline repair and prompted regressions. A failure should be checked against the trace, not automatically blamed on the model.
Execution controls

Three separate permission surfaces

  • Planner and file editor: Write mode controls their write-capable operations. Planner checks actual command exits and declared result evidence; “Plan checks passed” is not independent proof that a coding goal is solved.
  • Terminal agent: normal confirmations and /yolo govern its tool execution. Authorised commands run as your account; file-tool boundaries do not confine the shell.
  • Long Project: an opt-in saved-goal loop with its own write/shell permissions, time and call budgets, pause/resume state and explicit acceptance command. It does not inherit Planner Write mode or /yolo.
A workspace is not an operating-system sandbox. Shell commands can reach files, services and networks available to your account. Conscience checks, an Internet toggle and permission prompts are application controls, not OS containment.
Workflow

Give it a verifiable local task

  1. Select a project. Saient scopes file tools and project state to the chosen workspace.
  2. Load a local GGUF model. Choose a model that can follow structured instructions and tool schemas.
  3. State the goal and checks. Name the expected outcome, constraints and command/test that will prove completion.
  4. Grant only needed authority. Choose permissions for the surface you are using. Inspect proposed commands; keep backups before authorising modifications.
  5. Review evidence. Inspect changed files, terminal output, verification feedback, memory/provenance and checkpoints.
Goal: fix the failing health-endpoint test. Scope: inspect the route and its test first. Constraint: preserve the current API shape. Verification: run the smallest relevant test command. Finish: list changed files and paste the test result.
Models and hardware

The agent uses the local LLM you load

The desktop agent uses the local GGUF engine. Check the beta manifest requirements for the packaged engine and hardware scope. Model choice, prompt format, controller behavior and inference implementation all affect results; a larger model alone does not establish reliability.

Evidence and limits

What the dev.6 checks establish

Two recovered local tasks

A Qwen2.5 7B newline correction and a Qwen2.5-Coder 14B Long Project normalization task passed their checks and reached completion after controller fixes. These were individual trials, not a success-rate or speed benchmark.

Known coding failures

Harder configuration work still failed on the tested local 14B in an independent control. Broad coding reliability and sustained unattended projects remain open.

Controller and package checks

Dev.6 regression and exact package-resource audits passed. A fresh-profile native smoke covered setup, terminal and a text workflow; it did not repeat image/video inference.

Historical evidence

The v1.0.9 screenshot and August local-host smoke remain evidence of those older builds. They are not fresh dev.6 measurements.

Completion needs recorded work and the applicable checks. Failed, denied or interrupted checks cannot stand in for a pass. This reduces false success paths; it does not make any chosen checker a complete specification.

Use a local model with persistent agent machinery.

Saient is free and does not require a Saient licence or hosted inference key. You remain responsible for the project, model and permissions you select.