Use the AI assistant

Applies to SiliconForge 0.1.2 · Updated 2026-09-30. Check platform limits.

Before this task: Know the project before sharing context →

The assistant proposes engineering work. You choose the access route, disclose project context, approve scope and decide whether a candidate belongs in your project.

New AI requests require active paid application access regardless of provider route. Managed AI additionally uses your managed allowance; personal provider billing is separate. The offline desktop lease does not make a network AI service work offline.

Set up the external AI runtime#

1. Open the application menu's AI runtime setup… command, or Settings → Assistant & models and its runtime setup control.
2. Choose Install reviewed runtime… to download the supported, integrity-checked Codex runtime after confirming. If you already have that supported executable, use Choose installed executable… instead.
3. Read installation progress. You can cancel; a failed or cancelled download must not replace a working runtime. Refresh runtime status rechecks the selected executable.
4. Select and connect your AI account, then choose Check AI connection. Runtime installation alone does not sign you in, activate the application or start a model request.

A missing runtime, unsupported version, isolation failure, account problem and unavailable model have separate remedies. Read the reported condition before changing credentials. On Ubuntu with restricted unprivileged user namespaces, ask an administrator to install the reviewed Codex runtime in a root-owned, non-user-writable location and configure the supported permission for that exact executable. Select it in AI runtime setup and refresh. Do not grant broad, wildcard or home-directory exemptions. Local project viewing does not need this AI setup; on Windows, follow the isolated WSL setup. Never disable the sandbox or substitute an unrestricted shell.

Choose access before sending#

You need an open project and access entitled to the selected route. Managed SiliconForge access and your own external provider access have separate allowances and billing. A developer account visible in a development environment is not a customer entitlement.

1. Open Settings → Assistant & models. Under Codex access, choose My Codex account or My OpenAI API key when using that external route, then Use selected access.
2. Use Set API key… for the dedicated credential flow. Never paste a key into chat, HDL, terminal logs or a support form. Remove API key removes that configured key; it is not cancellation of a provider subscription.
3. For managed access, complete the secure activation handoff. Check Settings → Usage & cost for the active provider route and available usage information.
4. Select a model and thinking level available on that route. The composer is the availability authority; an unavailable model must not be silently substituted.

Expected result: the active route is identified before dispatch. Selecting a route alone does not send a model request. Windows native execution requires the supported isolated WSL route; sandbox failure is not permission to run an unrestricted shell.

Choose a model deliberately#

Model availability and thinking effort are separate controls. Use the route's available choices for the next request; more thinking is not verification evidence. If a selected profile is unavailable, inspect the reported state instead of assuming a different model performed the work.

Disclose the minimum context#

1. Read the context control before sending. Use Browse project files… to pin only needed files; Clear pinned files removes those pins.
2. Check the current engineering selection. Under Settings → Context & privacy, decide whether to Include the current engineering selection automatically.
3. Review file paths, access mode and the recorded context disclosure. A model needs relevant design context, not unrelated source trees or account credentials.
4. Keep files you are not authorized to disclose out of the request. Private project state and secrets are not appropriate chat attachments.

Start with a read-only question: “Explain the reset behavior in this selected module. Cite the source lines; do not modify files.” Check the answer against source before widening scope. Local settings include a pinned-file limit; increasing it is not a substitute for reviewing disclosure.

Ask → Plan → approve → Execute → Review#

1. Ask: state the behavior and uncertainty you want investigated. Distinguish a question from permission to edit.
2. Plan: use Plan mode for affected interfaces/files, assumptions and checks. For example, request a test that holds output not-ready while input remains valid, without changing the public interface.
3. Approve: review the exact proposed scope. Do not approve an unexplained dependency, credential request or unrelated change.
4. Execute: inspect progress and real tool results. Approved candidate work is separate from explicit application to your working project.
5. Review: open the actual candidate in Changes, compare it to the expected base and read current evidence. Apply or reject explicitly. Changed source or candidate contents require a fresh review.

A successful model response is neither a passing simulation nor an applied project change. See candidate review for state and approval details.

Interruption and recovery#

Authentication or entitlement error

Confirm the selected route and reconnect through its credential flow. Do not repeatedly purchase or switch accounts blindly.

Model unavailable

Choose an actually available profile; a model label alone does not establish access.

Stop, timeout or network interruption

Inspect the request and candidate state before retrying. Stop interrupts work; it does not apply a proposal or undo previously applied changes. Preserve the run identifier and last concrete result.

Sandbox/setup failure

Retain the exact error and platform/release details. Do not disable isolation or expose extra host directories to force execution.

Stale candidate

Compare the base with current project changes. Re-plan/re-review rather than approving a mismatched diff.

Related: evidence, cost and activation, safe diagnostics, data handling.

Reopen a saved AI proposal#

1. Open the original project, then choose Changes → Saved AI proposals…. The same command is available in the application menu.
2. Select the proposal you intend to inspect and choose Open. Nothing is selected or applied automatically. Its retained state distinguishes a staged candidate from an already applied or rolled-back one.
3. Read Source to compare the original candidate change, then open its recorded tool output where available. These are retained candidate results, not a fresh check of your current project.

This history survives an application restart and does not depend on an active chat. Opening it does not contact an AI provider, restore a plan approval or apply source changes. A staged candidate needs fresh explicit review before any further permitted action. If its original card or evidence is missing or cannot be verified, SiliconForge reports it as unavailable rather than inventing it or substituting a newer run. The current-session Jobs view and a saved conversation are not substitutes for this durable proposal history.

Need help? Report an issue. Include your application version; never include credentials.