DEV Community: Calvin Sturm

I Built a Local-First Agent Runtime in Rust (and Why Wrapping Existing CLIs Didn’t Work)

Calvin Sturm — Sat, 21 Feb 2026 22:59:29 +0000

I’ve been trying to make local AI workflows reliable for real day-to-day use: coding tasks, browser tasks, repeatable evals, and auditable tool execution.

I first tried adding trust/approval controls around existing agent CLIs. That approach hit a hard limit quickly: when tool execution is deeply native to the host app, external wrappers can’t reliably enforce policy boundaries.

So I built my own runtime: LocalAgent.

GitHub: https://github.com/CalvinSturm/LocalAgent

Why I built this

I kept seeing the same failure pattern with local 20–30B models:

brittle tool behavior
occasional non-answers
inconsistent step execution
hard-to-debug failures without replayable state

The answer wasn’t just “pick a better model.”

The answer was to harden the runtime process:

explicit safety gates
deterministic artifacts
policy + approvals
eval + baseline comparisons
replay + verification

What LocalAgent is

LocalAgent is a local-first agent runtime CLI focused on control and reliability.

It supports:

local providers: LM Studio, Ollama, llama.cpp server
tool calling with hard gates
trust workflows (policy, approvals, audit)
replayable run artifacts
MCP stdio tool sources (including Playwright MCP)
deterministic eval harnesses
TUI chat mode

Safety defaults (important)

Defaults are intentionally restrictive:

trust is off
shell is disabled
write tools are not exposed
file write execution is disabled

You have to explicitly enable risky capabilities.

Architecture (high level)

At a high level, each run does:

Build runtime context (provider/model/workdir/state/settings)
Prepare prompt messages (session/task memory/instructions if enabled)
Apply compaction (if configured)
Call model (streaming or non-streaming)
If tool calls are returned:
- run TrustGate decision first
- execute only if allowed
- normalize tool result envelope
- feed tool result back to model
Repeat until final output or exit condition
Write artifacts/events best-effort for replay/debug

This design keeps side effects behind explicit gates and makes failures inspectable.

Why this is better than wrapper-only trust

External wrappers are useful, but they’re limited when tool execution happens inside another runtime you don’t control.

With LocalAgent:

tool identity/args are first-class internal data
policy and approvals are evaluated before side effects
event/audit/run artifacts are generated in one execution graph
replay and verification use the same runtime semantics

In short: security and reliability controls are part of the execution model, not bolted on.

Quickstart

cargo install --path . --force
localagent init
localagent doctor --provider lmstudio
localagent --provider lmstudio --model <model> chat --tui

One-shot run:

bash localagent --provider ollama --model qwen3:8b --prompt "Summarize README.md" run

Slow hardware notes

On slower CPUs / first-token-heavy setups, retries can create a bad UX (re-sent prompts before completion). During debugging, use larger timeouts and disable retries:

bash localagent --provider llamacpp \ --base-url http://localhost:5001/v1 \ --model default \ --http-timeout-ms 300000 \ --http-stream-idle-timeout-ms 120000 \ --http-max-retries 0 \ --prompt "..." run

What I’ve learned so far

The biggest reliability gains came from process constraints, not model hype:

bounded tasks
strict output expectations
pre-exec arg validation
deterministic evals + baselines
replayable artifacts for root-cause debugging

For high-ambiguity reasoning, I still route to stronger hosted models.
For a lot of productivity helper work, local models are viable when the runtime is disciplined.

Current docs

README: project overview + workflows
CLI reference: complete command/flag map
provider setup guide (LM Studio/Ollama/llama.cpp)
templates, policy docs, and eval docs

Repo: https://github.com/CalvinSturm/LocalAgent

Feedback I’d love

What local model + runtime combos are most stable for tool-calling?
Which prompt/output constraints improved reliability most for you?
What would make local-first coding workflows feel “production-ready”?

If this is useful, I can write a follow-up with concrete eval/baseline workflows and model routing strategy.

Why CRT Displays Felt Easier on the Eyes

Calvin Sturm — Thu, 19 Feb 2026 02:41:04 +0000

Some monitors feel gentle on the eyes, while others strain them. Decades ago, green and amber CRTs were the standard, designed with one goal in mind: endurance. Every photon, every watt, and every phosphor lifetime was a hard limit. Those limits forced designers to optimize for eye comfort, readability, and long sessions. Modern screens removed those constraints. They offer extreme brightness, high refresh rates, and perfect color. But in doing so, they left behind the built-in protections our eyes relied on.

TL;DR

CRTs were engineered around human visual limits, not maximum brightness.
Green and amber phosphors aligned with eye sensitivity and reduced glare.
Phosphor decay created brief light impulses, unlike modern sample-and-hold displays.
Modern screens removed these guardrails, so UI design must add restraint intentionally.

Why Green Was Default: Efficiency Over Style

A lot of monochrome CRTs used green-ish phosphors like P31, a yellow-green phosphor commonly used in CRT applications, with emission centered in the green region. (FH Münster Backend)

The deeper reason green dominated is biological: in photopic (daylight) vision, the standard luminous efficiency function V(λ) is normalized to its peak at 555 nm. (iTech Standards) When you emit light near that band, you get more perceived brightness per unit radiant power. That’s literally how photometry is defined. (iTech Standards)

So while “P31 peaks at 545 nm” is not a safe universal claim, the engineering point is still true: common green CRT/display phosphors were tuned near where eyes are most sensitive. For example, the widely used green phosphor P43 is reported with a peak emitted wavelength around 545 nm, which sits close to the eye’s peak sensitivity band. (APS Link)

Green phosphors offered:

High perceived luminous efficiency, more “brightness” per watt because the spectrum lands near the V(λ) sweet spot. (iTech Standards)
Fast initial decay plus a persistence tail, meaning the light doesn’t behave like a perfectly held pixel. Depending on conditions and how you measure it, P31 can decay quickly in contrast while still remaining detectable for much longer. (PubMed)
Strong operational stability, less drift, longer lifespan (this was practical engineering, not aesthetics). (FH Münster Backend)

Green was not futuristic. It was easy on the eyes and easy on the hardware. It delivered the clearest, most readable signal for minimal cost and wear.

Why Amber Existed: Comfort Over Efficiency

Maximum efficiency is not always maximum comfort. Amber/orange CRT phosphors often sit around ~590 nm (and nearby), pushing output away from shorter wavelengths. (FH Münster Backend)

That matters because disability glare is driven by intraocular scatter (straylight), which casts a veiling luminance over the retinal image and reduces contrast. (PubMed) In plain terms:

More scatter creates more “haze” over text
That haze lowers effective contrast and makes bright elements feel harsher (PubMed)

Amber acts like a soft-focus filter for the eyes, trading some brightness for reduced strain. Green phosphors optimized detection. Amber phosphors optimized endurance. Both were deliberate engineering trade-offs, not stylistic choices.

Diagram of visible light spectrum highlighting green (~545 nm) and amber (~590 nm) CRT phosphor wavelengths relative to peak human eye sensitivity at 555 nm.

The Hidden Variable: How CRTs Handled Light Over Time

CRTs did not just differ in color. They behaved differently over time. When a pixel lit up, it did not switch off instantly. The output is the video signal convolved with the phosphor’s impulse response (afterglow), so the light naturally decays rather than snapping off. (Cambridge Computer Lab)

This natural temporal smoothing helped the eyes:

Softened flicker, light did not jump abruptly (source)
Smoothed brightness changes, sharp edges felt gentler
Eased adaptation, eyes did not constantly adjust to sudden spikes

Modern LCDs and OLEDs mostly hold each frame until the next one. At 60 Hz that’s a 16.7 ms hold per frame, and the temporal behavior is fundamentally different from impulse/decay systems. (PMC) Long sessions can feel harsher.

CRTs had built-in “eye filters.” Modern displays do not. UI must add moderation intentionally.

CRT phosphors emit brief pulses of light that decay naturally (with a fast initial decay plus a persistence tail, depending on phosphor and conditions), while modern LCD pixels are held at a constant brightness for the duration of each frame (16.7 ms at 60 Hz), which contributes to motion blur under eye tracking. (PMC)

Modern Displays Removed Constraints and With Them, Restraint

CRTs forced designers to work within limits. Modern screens can produce extreme contrast and intensity effortlessly. That freedom has a cost: visual fatigue.

Extreme white on black (#FFFFFF on #000000) may maximize contrast, but glare and contrast loss are tightly linked to veiling luminance from intraocular scatter, which can make high-intensity UI feel harsher than its “contrast ratio” suggests. (PubMed) Context matters:

Bright environments: dark text on light backgrounds improves readability
Dark environments: extreme contrast can feel harsh

The lesson is clear. Just because you can push brightness and contrast to the max does not mean you should. CRTs physically limited these extremes, providing built-in visual moderation. Modern UI design requires deliberate restraint to protect the eyes.

Practical Implications for Modern UI

If you are building terminals, dashboards, IDEs, or monitoring systems, the goal is not maximum contrast. It is sustainable perception.

Avoid:

Pure white on pure black in dark environments
Fully saturated neon colors (#00FF00)
Unbounded brightness for non-critical information

Prefer:

Near-black backgrounds (#0A0A0A to #121212)
Moderated green (#00B800)
Moderated amber (#B89200)
Reserve peak luminance for important signals

Think of your interface like a well-tuned lamp. Bright where it counts, gentle everywhere else.

The Central Lesson

When hardware had limits, engineers optimized for endurance.
When hardware removed limits, we optimized for intensity.

CRTs forced designers to work within biological tolerances. Modern displays freed us. In doing so, they removed the natural guardrails that protected our eyes.

Restraint is no longer enforced by hardware. Today it is a deliberate design choice.

Questions for Modern UI Designers

Not:

How bright can this be?

But:

How long can someone look at this without fatigue?

Those are very different optimization targets. CRTs were engineered around physical limits. Modern UI must respect biological limits deliberately.

Have you noticed eye fatigue from modern monitors?
Do you prefer moderated dark terminals like green or amber-on-black, or high-contrast white-on-black?
I would love to hear whether it is spectral, temporal, psychological, or just familiarity. Share your experience below.