AlterEgo claims zero model spend for a Windows agent. The privacy bill arrives at failover

THE SIGNAL IN ONE SENTENCE

Free is a price. It is not an architecture review. AlterEgo is a new open-source personal agent for Windows with a sharp claim: its model spend during development was zero. The project says it achieves that by routing several agent roles across free-tier access from four model providers, then moving to another authorized option when one is unavailable or rate-limited. That is an interesting engineering choice. It is also where the privacy bill arrives. The project appeared publicly on October 18 as a single-author Zenodo preprint and an AGPL-licensed GitHub repository named OpenMuse-Win. The preprint record describes a Windows-native personal agent with a failover router that multiplexes four free-tier providers. In an author post, those providers are named as NVIDIA, ModelScope, Zhipu and Agnes. The plain signal is this: zero model spend can make an agent more accessible, but every extra provider is another boundary that must be authorized, documented and tested. AlterEgo does not send every job to one interchangeable pool. Its documentation describes role chains for a main controller, planner, subagent and background worker. Each role has an ordered list of providers it may use. If the active provider returns a rate limit or becomes unavailable, fallback stays inside that role's configured chain. That is better than silent roaming. The repository says a disabled provider, a provider without a key or a provider outside the role chain is rejected before a network request. It also exposes controls to disable fallback globally or pin a role to one provider. In that strict setting, a rate limit becomes a hard stop instead of a reason to send the task elsewhere. The author added a small test suite after a reader asked how failover interacts with permission. The repository now describes three forced-failure cases: one authorized provider failing with no backup, a sensitive role refusing to borrow another role's backup, and a disabled or keyless provider being rejected before connection. Those tests are useful. They are not an independent privacy audit. The distinction matters because the public discussion reveals the sequence. When first asked about the test, the author said that specific forced-failure test had not yet been run. Later the same day, the author reported adding the tests and said all three cases passed. The code is public, which lets other people inspect and rerun it. The current evidence is still author-created code, author-run tests and author-reported results from a project with three commits and no published release. Treat it as an early implementation receipt, not a safety certificate. There is also a gap between role permission and task permission. Suppose a person allows a general planning role to use Provider B for ordinary travel research. That does not necessarily mean a task containing a medical appointment, private document or screenshot should go to Provider B after Provider A reaches its quota. A role-level whitelist says which destinations are generally allowed. A task-level policy says whether this particular context may cross that boundary. The public materials document the first. They do not demonstrate the second. A stronger design would intersect three things before every request: the role chain, the task's sensitivity label and the provider permissions granted for that task. If the intersection is empty, the agent should stop and explain why. If the destination changes during failover, the interface should name the new provider before sending context, especially when the task includes files, screenshots, browser state or personal memory. This is the cost hidden inside free-tier elasticity. The operator may not pay a model invoice, but somebody must maintain a permission graph. AlterEgo's Windows execution layer makes that graph more important. The repository describes direct use of Windows UI Automation for buttons, fields and other controls, with progressively less precise fallbacks that can include visual location and physical mouse input. Browser automation uses persistent Chromium, live element references and screenshots. Those capabilities are practical. They can also expose the material sitting around a real desktop. A screenshot may contain an email address, account balance, customer name or authentication prompt. A browser profile may already be signed in. The clipboard may hold something unrelated to the current task. A file picker can reveal recent folders. Accessibility trees can expose text that is not obvious in the visible window. Local execution does not mean local inference. The controller, browser profile and automation tools may run on the user's Windows computer while prompts, screenshots or extracted interface state travel to an external model endpoint. A privacy label should describe each leg of that trip, not merely where the Python process starts. The project does include meaningful local controls. Its documentation describes a Windows DPAPI-backed vault that binds stored API secrets to the machine and user. It also describes three action levels: read-only work can run automatically, reversible actions are logged, and high-risk actions such as shell execution or destructive file operations require a one-time human approval. Those are sensible boundaries. They need hostile testing. An approval system should be tested for indirect actions, not just obvious command names. Deleting a file through a shell is destructive. Replacing its contents through a text editor can be just as destructive. Filling a web form may be reversible until the agent clicks Submit. A read-only browser step can still disclose private text if the captured page is sent to a provider. The permission question therefore has two axes. What may the agent do on the computer? What may it disclose to the model that decides what to do next? One L1, L2 or L3 action label cannot answer both. The useful deployment pattern is a two-key system. The local action policy controls read, write, submit, execute and delete. The context policy controls which provider may receive which text, image, file, memory or browser state. Failover must satisfy both before anything leaves the machine. The zero-cost claim also needs ordinary accounting. The author reports zero model spend during development and describes free-tier routing as an existence proof. That does not mean the whole agent costs nothing. A Windows computer, electricity, network access, setup time, maintenance and the operator's attention are real inputs. Free quotas can shrink, terms can change, models can disappear and a provider may require account verification. Rate limits can turn a long workflow into a queue of partial tasks. Even the phrase zero marginal model cost has a boundary. It describes the author's reported bill under the providers and quotas used during development. It does not guarantee that every user, region, workload or future month will receive the same access. Free tiers are policies, not infrastructure. That makes fallback both the product feature and the operational risk. More providers can improve availability. More providers can also produce more variable behavior. Models differ in tool calling, image support, refusal policy, language quality, context limits and output format. A task that succeeds on the first model may fail differently after a fallback, even when both calls are free. A reliable router needs more than a list of endpoints. It needs compatibility tests for every role and provider pair, a stable definition of success, capped retries, a record of the provider actually used and a way to reproduce the decision later. The run receipt should show the planned provider, the provider ultimately used, why routing changed, what context crossed the boundary, what tools were available, which approvals were requested and whether the result passed the same checks after failover. Without that receipt, free routing can become a shell game. The answer arrives, but nobody can say which service saw the prompt or why its behavior changed. The same caution applies to the project's performance language. The repository currently claims fast self-recovery and greater than 99 percent completion for its most elastic topology. The reviewed public material does not provide an independently reproduced workload, sample size, failure distribution or comparison protocol for that number. It should not be treated as an established reliability result. The project is young enough that restraint is a feature. Start with public, low-stakes tasks. Use a separate browser profile. Keep sensitive roles pinned to one approved endpoint or a local model. Turn fallback off until every destination has been reviewed. Use test accounts and disposable files. Confirm that logs and screenshots exclude secrets. Make the agent explain a route change before it sends context. Require a person for submissions, purchases, credential changes, system commands and irreversible edits. Then break it on purpose. Force a 429. Remove a key. Disable a provider. Put a secret in the screenshot. Change a role chain during a run. Close the browser. Move the mouse while the agent is preparing a click. Make a model return malformed tool arguments. Deny an approval. Confirm that the system stops cleanly, preserves the audit trail and does not quietly widen permission. The code being open under the AGPL is valuable here. Researchers can inspect the router, test the gates and publish counterexamples. A small project does not need to arrive with a perfect security program. It does need to label which claims have been demonstrated, which were simulated and which remain design intent. AlterEgo's central idea is worth keeping: a useful personal agent should not require a permanent premium-model meter running in the background. But a personal agent also should not treat a free quota as permission. The real product is not the zero-dollar route. It is the stop sign that still works when the route changes.