Desktop runtime
Rust foundation for the Windows workspace
The preview is built around a native desktop shell rather than a browser-only experience. The Rust layer carries the local frame for the app window, shell access, capture, logging, and the pieces that make Implaced feel like software installed on the machine.
Tauri-based Windows desktop app with Rust-side runtime components.
Local server bridge for desktop-to-workspace communication.
Native shell, input, capture, logging, and startup paths for the preview build.
Installer and release flow prepared for first public Windows testing.
Workspace state
Projects, chats, files, and artifacts now have a product shape
Implaced has moved beyond a single prompt surface. The app keeps project work, standalone chats, local files, terminal output, generated artifacts, and workspace context in one environment so a user can return to work without losing the thread.
Project and chat surfaces separated so work stays scoped.
Local workspace folders, scratch files, generated artifacts, and file review paths.
Editor, terminal, file tree, browser preview, and message timeline inside the same product frame.
Workspace artifact handling for files created or changed during an agent run.
Runtime toolchain
The platform can inspect, run, and verify work instead of only replying
The runtime includes the pieces needed for software work: repository inspection, command execution, provider calls, workspace synchronization, tool receipts, and verification-oriented outputs. The goal is a working loop, not a static answer.
Runtime toolchain modules for commands, tools, execution, and workspace artifacts.
Repository and file-context workflows for understanding real codebases before changing them.
Cloud workspace sync for isolated execution when local-only work is not the right fit.
Receipts around commands and artifacts so work can be inspected after the model responds.
Provider gateway
Model routes are first-class product settings
Provider selection is now part of the workspace rather than a hidden environment variable. Users can bring the route they trust, compare cost and capability, and keep third-party risk visible before sending work to a model provider.
Provider configuration for OpenRouter, Vercel AI Gateway, IYH, and FreeModel.
Usage and cost visibility through the Control Center.
Provider trust labels, cache classification, and route-aware usage reporting.
Dedicated provider page explaining caching, credits, testing routes, and provider-request flow.
Protocols
User rules can be injected into the engineering run
Protocols give teams a way to add standing rules without retraining the system. They can define engineering standards, architecture constraints, project-specific expectations, or runtime instructions that should apply when the product works on a task.
Engineer Protocols inside Control Center.
Global, project-specific, and OS-focused application scopes.
Runtime instruction injection for standards such as TypeScript rules, architecture preferences, or release discipline.
Squad configuration for assigning model routes to different specialist lanes.
Preview operations
The preview now has the operational surfaces a real product needs
The release is prepared for real users: sign-in, setup expectations, support diagnosis, changelog, legal pages, provider guidance, and a download path that explains the realities of an unsigned early Windows build.
GitHub or Google sign-in for a specialized workspace.
Download guidance for Windows preview warnings and WebView2 expectations.
In-app Support and website Support for cases that need screenshots, logs, or product-state diagnosis.
Terms, Privacy, Download, Providers, Agents, Support, and Changelog aligned into one public product surface.