ChaseInTech — Articles https://chaseintech.com/articles Long-form writing on agentic AI, governed automation and systems architecture by Chase (ChaseInTech). en-gb Tue, 28 Jul 2026 00:00:00 GMT Do not change the desktop default because a dev run feels faster https://chaseintech.com/articles/desktop-default-performance-pass https://chaseintech.com/articles/desktop-default-performance-pass One measured local build: cold readiness from ~201s to 52.150s and settled CPU from 23.528% to 5.238% — and why the shortcut only changed after functional and visual evidence agreed. A useful build rule from the latest ChaseOS Studio performance pass: do not change the desktop default because a development run feels faster.

The one-directory package had to pass as the artifact an operator would actually run. On one Windows host, cold readiness moved from about 201 seconds to 52.150 seconds, and settled machine CPU moved from 23.528% to 5.238% over a 90.951-second sample.

The rollback path stayed intact while Home, Chat, Graph, Docs, local voice readiness, and the final package were checked. The shortcut changed only after the functional and visual evidence agreed.

This is not a universal hardware benchmark or a public installer announcement. It is one measured local build, with Studio still in Early Access and installer access marked Soon.

Explore Studio: chaseos.ai/studio

]]> Tue, 28 Jul 2026 00:00:00 GMT Article chaseos performance engineering-discipline Model routing should be visible before execution https://chaseintech.com/articles/model-routing-before-execution https://chaseintech.com/articles/model-routing-before-execution A product boundary from the ChaseOS build: put managed Cloud, provider-owned keys and local models side by side — and show the cost of the managed path before a request is sent. A useful product boundary from this week's ChaseOS build: model routing should be visible before execution, not hidden in configuration.

The newest Studio QA state puts three choices side by side — managed Cloud, provider-owned keys, and local open-source models — and shows the usage context for the managed path before a request is sent.

The important limitation is equally visible. This is a test-account fixture, not a Cloud launch. Managed compute is not publicly available, the gateway plan-context change still needs deployment proof, and Studio sends account changes to the account page rather than purchasing anything itself.

That combination matters: make the convenient route understandable without demoting local models or keys the operator controls.

Current product boundary: chaseos.ai/cloud

]]> Tue, 28 Jul 2026 00:00:00 GMT Article chaseos product-boundaries cloud The part of an agent demo you cannot see https://chaseintech.com/articles/forge-visible-contracts https://chaseintech.com/articles/forge-visible-contracts Why ChaseOS Forge publishes every workflow pack's contract — inputs, steps, approval gates and enforced limits — before you run it. The part of an agent demo I care about most is usually the part you cannot see: the rules behind the run.

Before I trust a workflow, I want to know what it takes in, the steps it follows, where it needs approval, and what it cannot do.

That is the idea behind ChaseOS Forge. The live marketplace publishes first-party workflow-pack previews, and each one publishes its contract up front.

The Software Review Pack makes this concrete. It turns repo context, diffs, tests, and review notes into an approval-ready engineering packet: six visible steps, four approval gates, and four enforced limits. You can inspect all of it before the workflow runs.

Forge is in Early Access. Paid marketplace checkout and direct installation from the public page are not live yet.

I'm building this in public because the trust model matters as much as the demo.

Explore the live contracts: chaseos.ai/forge

If you were reviewing an agent workflow, what would you need to see before letting it run?

]]> Tue, 21 Jul 2026 00:00:00 GMT Article agentic-ai governance chaseos