Architecture

Core Constraint

Invariant LLM Connect exists to run configured LLM web applications with less browser overhead than a normal browser. Architecture decisions are judged by their effect on:

1. browser-controlled RAM
2. idle CPU
3. idle network activity
4. GPU and VRAM use
5. incremental tab cost
6. LLM-platform compatibility
7. security
8. maintainability
9. upstream patching burden

Engine Direction

Gecko is the required base. Chromium, WebView2, CEF, and Electron are excluded from the product runtime.

The final product should not simply be a stock browser with preferences changed. Unneeded browser surfaces and background systems should be removed from the compiled product wherever practical.

Electron is outside the initial architecture direction because it conflicts with the central resource objective.

Performance evaluation should compare equivalent LLM workloads and record browser-controlled memory, CPU, network activity, GPU use, and incremental tab cost.

Application Model

Connect hosts configured LLM-platform destinations. It does not provide arbitrary address-bar navigation.

The main shell should contain:

• a compact tab strip
• a minimal navigation row for back, forward, and reload
• a platform-opening + control
• restrained settings/about access
• the hosted LLM platform as the dominant visual surface

The + control opens configured platforms. It does not open an unrestricted blank browsing tab.

The application shell uses the Invariant product identity while keeping the chrome restrained and tool-focused so the hosted platform remains the dominant working surface.

Platform Records

A platform record requires only the information Connect needs:

Name
URL

Known-platform presets may be added later to simplify setup, but user-defined endpoints are mandatory and must remain the universal path.

Public builds use neutral example endpoints and exclude non-public infrastructure details from bundled configuration and documentation.

Navigation Boundary

Configured LLM applications are Connect destinations. Ordinary arbitrary web navigation is not.

Internal navigation within the configured LLM origin stays inside Connect. External websites opened from hosted content should be handed to the operating system's default browser.

External authentication providers may use controlled temporary authentication flows when required for the hosted LLM platform to function.

This boundary preserves product purpose. It is not intended as DRM against a user deliberately configuring an endpoint.

Tabs And Resource States

Tabs are mandatory. Inactive tabs remain loaded by default because they may contain active generation, uploads, downloads, application state, or work the user intends to preserve.

Supported tab states:

ACTIVE
BACKGROUND ACTIVE
IDLE
SUSPENDED

Manual suspension is required. Optional automatic suspension may later be configurable. A tab performing active work must not be automatically suspended.

Resource management must not assume an invisible tab is idle merely because it is not displayed.

Explicitly Excluded Browser Systems

Inherited browser functionality should eventually be removed rather than merely hidden where practical:

• conventional web search
• unrestricted address-bar navigation
• normal bookmarks
• browser news/content pages
• general browsing history UI
• browser accounts
• sync services
• extension marketplace
• consumer browser profiles
• shopping features
• sponsored recommendations
• browser experiments
• translation suites
• reader mode
• browser-specific content services
• normal new-tab pages
• default-browser prompts
• import-from-other-browser wizards
• browser promotional surfaces

Security Requirements

Connect is optimized, not intentionally weakened.

TLS validation, certificate validation, origin isolation, sandboxing, site isolation, and other required web-security mechanisms remain unless a replacement provides equivalent protection.

No benchmark win justifies removing critical protections from the runtime.

Performance Measurement

The relevant comparison is:

Invariant LLM Connect vs. the same LLM interface in a conventional browser

Not:

Invariant LLM Connect vs. no browser

Development targets:

• browser-controlled RAM materially below stock Firefox/Chrome
• idle CPU approximately zero when the hosted platform itself is idle
• no Connect-generated background network traffic while idle
• no unnecessary continuous GPU activity
• lowest practical incremental resource cost for additional tabs
• no measurable model-performance regression caused by Connect

A roughly 25% browser-controlled memory reduction compared with the equivalent stock-browser workload is the minimum worthwhile target. Approximately 40% or greater is a strong success target. These are development goals, not published promises.

Development milestones are evaluated against the product constraints, security requirements, and performance targets documented here.

First-Launch UX

First launch should be minimal:

Invariant LLM Connect

A lightweight browser for LLM platforms.

Open WebUI is ready under Platforms.

[ Open Platform ]

No account creation, cloud registration, advertisements, telemetry wizard, marketing carousel, or personalization flow.

About UX

The About screen should remain restrained:

Invariant LLM Connect

Version X.X.X

A lightweight browser for LLM platforms.

Part of the Invariant product family.

[ Licenses ]
[ Project Information ]
[ Check for Updates ]

Publisher/legal attribution should remain easy to replace once the parent identity is finalized.

Update Architecture

Invariant LLM Connect uses a Connect-owned, on-launch update subsystem rather than Firefox's updater. Application packages carry shell and Gecko/security changes; small signed declarative packages carry known-platform compatibility definitions. No updater service, tray process, scheduler, telemetry, or idle polling process is permitted. Platform installation is behind provider classes so Windows standalone, Invariant OS, and other Linux package systems can use their native replacement semantics.