TL;DR
AWS and OpenAI announced that GPT‑6 Sol and GPT‑6 Luna are available on Amazon Bedrock. OpenAI positions Sol for higher‑effort developer and multi‑step agent work and Luna for high‑volume extraction, classification, and summarization. OpenAI published vendor-run benchmark results (for example, AutomationBench: “GPT‑6 Sol (xhigh), Score 33.2%, Cost per task $0.27”) and reports improved factuality (“GPT‑6 Sol makes about half as many mistakes as its predecessor”). AWS describes Bedrock hosting with operational controls (prompt caching, IAM/CloudTrail, VPC PrivateLink, zero‑operator access claims, and data‑retention options). Treat those numbers and controls as vendor‑supplied: validate pricing, regional availability, SLAs, and legal terms with your AWS and OpenAI account teams and run a small pilot that measures the total cost per usable result.
“GPT-6 Sol and GPT-6 Luna are now generally available on Amazon Bedrock, giving you more options to match intelligence and efficiency to each workload.”, Tanvi Girinath (Amazon Bedrock, AWS); Chris Dickens (OpenAI); Manish Rathaur (Amazon Bedrock, AWS)
What changed and why it matters
Two GPT‑6 family variants are now offered as choices rather than a single “bigger is better” option. OpenAI frames Sol as the option for complex, multi‑step reasoning, coding, and orchestration. Luna targets large‑volume, focused workloads where predictable output, latency, and cost matter. AWS positions Amazon Bedrock as the managed runtime that hosts these models and provides operational and governance features for enterprise deployments.
This matters because engineering and product teams can match the model to the job: use a higher‑effort model when reasoning and tool use matter, and a lower‑cost, lower‑latency model when throughput dominates. The business question becomes the total cost to a usable result, not which model posts the biggest benchmark number.
What OpenAI reported (vendor figures to verify)
OpenAI published model-level benchmark numbers across community and internal suites and included cost‑per‑task calculations. Representative claims include:
- AutomationBench: “GPT‑6 Sol (xhigh), Score 33.2%, Cost per task $0.27.”
- Agents’ Last Exam: “GPT‑6 Sol at max effort scores 56.4% … at ~60% lower cost per task versus a named competitor.”
- Coding / DeepSWE: Sol at max effort “scores 68.8%, within 1.1 percentage points of Claude Fable 5’s highest score … at approximately 80% lower cost per task.”
- Factuality: “On our internal factuality evaluation… GPT‑6 Sol makes about half as many mistakes as its predecessor, approaching Astra‑level reliability at much lower cost.”
These benchmarks are useful but they are vendor‑run and depend on chosen datasets, settings (for example, AutomationBench “xhigh”), and cost accounting. OpenAI itself notes caveats about dataset selection and competitor cost accounting. Treat these numbers as starting points for evaluation, not as proof that a model will outperform in your environment.
What AWS says about Bedrock hosting (claims to validate)
The announcement presents Bedrock as the production runtime for these models and lists enterprise controls that matter for compliance and operations. The capabilities cited include:
- explicit prompt caching to reduce reprocessing of repeated context;
- access governance through AWS Identity and Access Management (IAM) and invocation auditing via AWS CloudTrail;
- network isolation using VPC endpoints powered by AWS PrivateLink;
- inference on “hardware‑isolated infrastructure with zero‑operator access” and a stated policy that “your inference data isn’t used for model training” and using these models “doesn’t require you to opt into sharing your data with OpenAI;”
- automated abuse‑detection where classifier‑flagged traffic is retained by AWS “for up to 30 days and processed programmatically;”
- an option to request zero data retention through your AWS account team.
Those are meaningful controls if they line up with the contractual, technical, and audit evidence you need. Confirm the exact legal wording, any exceptions (for abuse‑detection or legal obligations), and which AWS Regions and SLAs apply before you roll out sensitive workloads.
How to choose: Sol vs. Luna (decision axis)
Use two axes: reasoning complexity, meaning how much multi‑step thinking, code generation, and tool orchestration you need, and throughput/cost, meaning how many requests per second or documents per day and how cost‑sensitive the pipeline is.
- Pick GPT‑6 Sol when workflows require multi‑step reasoning, reliable code generation or debugging, or agents that coordinate across tools and services. Example: automated PR reviewers that generate and test patches, triage engines that analyze logs and run targeted diagnostics, or agent controllers that sequence API calls across systems.
- Pick GPT‑6 Luna when you need high throughput, stable short responses, and predictable cost for tasks like contract clause extraction, ticket summarization, routing/classification, or indexing, where per‑request latency and cost dominate.
Benchmarks and the real caveats you should test
Vendor benchmarks are helpful but narrow. Before production, run these verification steps and track the listed metrics in any pilot.
- Understand what “cost per task” includes: model runtime fees, token usage, retries, orchestration costs, and any human verification or fallback costs.
- Reproduce vendor scenarios: run the same benchmark suites (AutomationBench, Agents’ Last Exam, FrontierCode, DeepSWE) if relevant, and measure your configuration and dataset versions.
- Measure business metrics, not just scores: accuracy on a domain test set, hallucination rate per 1, 000 responses, p95/p99 latency, cost per successful task (including retries/human review), and FP/FN rates for classifiers.
- Red‑team and stress tests: prompt‑injection attempts, malformed context, adversarial inputs, and high‑concurrency load testing at expected production scale.
- Security and compliance checks: request SOC/ISO attestation, confirm encryption in transit and at rest, and get the written contract language for “no model training” or “zero retention” promises and any abuse‑detection exceptions.
Operational checklist for engineering, security, and procurement
- Confirm regional availability and Bedrock GA details with your AWS account team and request the official AWS Bedrock announcement and documentation.
- Obtain written contractual terms on data usage: does your agreement explicitly prohibit inference data use for training? What are the exceptions and how do abuse logs work?
- Require auditor evidence for “zero‑operator access” claims and for any hardware isolation guarantees (attestation, SOC/ISO reports, or architecture docs).
- Enable IAM roles and CloudTrail auditing from day one so model calls are controlled and logged.
- Configure PrivateLink/VPC endpoints to keep network traffic inside your controlled boundary if needed for compliance.
- Design prompt caching for invariant context to reduce compute and latency; instrument cache hit rates and cost savings.
- Run a 2-4 week pilot that compares Sol and Luna on representative workloads and captures the recommended metrics above.
Short, practical rollout recipe
- Start with a focused pilot mirroring a real pipeline (one dataset, one team). Track total cost per usable result, including retries, fallbacks, and human review.
- Parallel test: route matching workloads to Sol and Luna to compare quality, latency, and cost under identical input distributions.
- Turn on IAM and CloudTrail, configure VPC endpoints if required, and ask your AWS account team for the process to request zero retention where needed.
- Run adversarial and load tests before production, and require an SLA that covers inference latency and availability if the use is business‑critical.
- Measure and gate rollout decisions on business KPIs (cost per resolved ticket, time saved per dev task, error rate reduction) rather than raw benchmark scores.
Key questions, quick, honest answers
-
Are GPT‑6 Sol and GPT‑6 Luna available on Amazon Bedrock?
AWS and OpenAI announced they are generally available on Amazon Bedrock; confirm regional availability and GA timing with your AWS account team and the official Bedrock documentation. -
Will my inference data be used to train the models?
The announcement states your inference data isn’t used for model training and that using these models doesn’t require you to opt into sharing data with OpenAI. Get the exact contractual language from AWS/OpenAI and confirm any exceptions (for example, abuse‑detection flows). -
How accurate and factual are the outputs?
OpenAI reports improved factuality (for example, “GPT‑6 Sol makes about half as many mistakes as its predecessor” on an internal error‑biased dataset), but that was measured on a curated sample. Benchmark on your own data and workflows to validate factuality for your use cases. -
How much will it cost to run at scale?
OpenAI published cost‑per‑task numbers on benchmarks (for example, AutomationBench: $0.27 per task for GPT‑6 Sol at xhigh) and described “significantly lower” pricing versus GPT‑5.6 predecessors. Ask AWS/OpenAI for concrete Bedrock pricing and run pilot measurements of total cost per usable result. -
What governance and network isolation controls exist?
The announcement lists IAM, CloudTrail, VPC/PrivateLink, prompt caching, and data‑retention options including a zero‑retention request process. Verify implementation details, access controls, retention locations, encryption, and auditor attestations with your AWS account and legal teams.
Three action items for leaders
- Run a focused 2-4 week pilot that compares Sol and Luna on representative workloads and measures total cost per usable result, p95 latency, and hallucination/error rates.
- Require signed terms that define data use, retention, and audit rights (get the zero‑retention process in writing and confirm abuse‑log exceptions).
- Instrument and validate: enable IAM/CloudTrail, configure PrivateLink if needed, and demand SLA/throughput benchmarks for any business‑critical deployment before scaling.
Vendors are starting to offer model SKUs tuned to operational tradeoffs rather than raw capability marketing. That’s good for practitioners: it lets you pick the right tool for the job, provided you verify vendor claims, measure real business metrics, and secure the legal and technical assurances your compliance posture requires.