GPT-6.1 Sol for architects: features and workflows

01

What is GPT-6.1 Sol?

OpenAI's 29 September 2026 changelog announces GPT-6.1 Sol in Codex and ChatGPT Work. The company positions it for complex work across code, apps, and documents, describing performance close to Astra at a lower cost. That is OpenAI's product positioning; it does not establish accuracy on an architecture drawing set.

The model accepts text and image inputs and produces text. Its documented capabilities include structured outputs and tools for searching files, browsing, running code, and computer use through supported integrations. These capabilities suggest several studio experiments, but the application and its connected tools determine what a particular session can do.

• Source: 29 September 2026: GPT-6.1 Sol in Codex and ChatGPT Work
• Source: GPT-6.1 Sol model capabilities and supported tools

02

Where might it help an architecture team?

The strongest first candidates are tasks with a clear source and a checkable result. An architect could compare a revised room schedule with agreed brief requirements. A coordinator could organize potential discrepancies from a supplied review pack. A practice lead could reconcile meeting actions with the next project milestone.

For teams developing office automation, a later pilot could ask Sol to explain an existing script, propose a change, and document the test needed before anyone runs it. The document-review example below is an archiPrompt evaluation proposal. We have not benchmarked the model on these architecture tasks.

03

Begin with a small coordination pack

Choose a completed review whose issues your team already understands. Supply a small set of current drawing exports, a schedule, and the relevant meeting note in readable formats supported by your chosen client. Include revision dates and identify which source governs if documents disagree.

Confirm the exact model is GPT-6.1 Sol in the available model controls. OpenAI lists launch access across Plus, Pro, Business, Enterprise, and Edu in supported Codex and Work clients. Enterprise and Edu administrators must enable it. Standard and Fast modes are available at launch; Sol Ultrafast is planned for later.

• — 1. Pick a known review with several confirmed issues.
• — 2. Supply the same files and revision information for every comparison.
• — 3. Ask for potential discrepancies with page, sheet, or row references.
• — 4. Check each finding against the source before classifying it.
• — 5. Record missed issues, false findings, and time spent correcting the output.

• Source: GPT-6.1 Sol: launch availability and model controls

04

Use a prompt that exposes the evidence

Paste the following into your Work or Codex conversation after adding the test files. Replace the placeholders with actual document names and the scope of your review. The instruction asks for candidate findings that a coordinator can inspect.

Review [named documents and revisions] for potential coordination discrepancies within [specific scope]. Use [governing document] when sources conflict and explain the conflict. For each finding, give an ID, issue category, both source references where applicable, the observed discrepancy, its possible consequence, and the person who should check it. Separate supported observations from assumptions. If a page, dimension, or schedule entry is unreadable, say so. Do not infer missing measurements or declare compliance. Return a concise issue register and a list of information needed to complete the review. Leave all source files unchanged.

05

Match the task to the tools available

A model's tool support matters when the job involves more than reading supplied text. A workflow that creates files or works inside another application needs the appropriate client capabilities, connections, and permissions. Choosing Sol alone does not establish a working connection to Revit, Rhino, or another design tool.

For an image-based check, remember that Sol's native output is text. Image generation is a separate tool. A drawing screenshot may support a question about visible information, but it cannot establish hidden model properties or replace a reliable extraction of dimensions and quantities. Use the smallest input that actually supports the review question.

• Source: GPT-6.1 Sol model capabilities and supported tools

06

Judge the result against your existing method

Use the same prompt and pack with your current workflow. Where available, include Astra as a comparison, consistent with OpenAI's recommendation to compare the models on your own tasks. Keep the review scope and available tools consistent, and record the settings you used.

A lower model cost can disappear into extra checking time. Count how many reported findings are supported, how many known issues were missed, and how long the coordinator spent verifying them. One good run is a reason to continue testing. Try another pack containing an unreadable source or conflicting revision to see whether the model handles uncertainty sensibly.

• — Traceability: can a reviewer find every cited source?
• — Accuracy: how many findings survive verification?
• — Coverage: which known issues were missed?
• — Efficiency: what was the total review time and usage?
• — Uncertainty: did the output expose gaps and conflicting evidence?

• Source: GPT-6.1 Sol model capabilities and supported tools

07

Keep the review method when the model changes

If Sol performs well on the pilot, preserve the input requirements, output fields, and review checks as an office method. Retest it when the model, source format, or connected tool changes. A consistent method makes it easier to tell whether an upgrade improves the work.

The related Drawing Set Coordination Review is an archiPrompt Agent skill for producing an evidence-linked coordination register from a PDF drawing set. The Project Lessons Learned Brief is a Template bundle for capturing lessons and actions. Check installation and compatibility on each listing before adapting its method to a Sol workflow.