The changes brought by GPT-6 are not just that models are smarter, but that we can allocate tasks more granularly, control reasoning investment, and reuse context. For teams working on content and GEO, what is truly worth studying is not “which model is the strongest,” but how to make the workflow of retrieval, writing, verification, and publishing more reliable, while reducing the cost of each qualified piece of content.
¶ I. Models Are Getting Stronger, So Why Is Content Still Not Useful?
If you have used AI to write articles in batches, you have most likely encountered this situation: at first glance, the structure is complete, the sentences are smooth, and even the summary seems quite convincing. But upon careful inspection, you find that the data has no source, the product versions do not match, or after writing two thousand words, it still does not answer the question readers care about most.
At this point, the easiest solution to think of is: switch to a stronger model.
But I would recommend asking one question first: Is the problem really with the model’s capabilities, or with the workflow?
If there are no reliable sources, no clear task boundaries, and no verification stage before publishing, changing models may not solve the root problem.
OpenAI’s GPT-6 Usage Guide does not actually focus only on “capability upgrades,” but discusses model selection, reasoning levels, caching, context compression, and multi-agent collaboration together. What it emphasizes is: make different capabilities serve specific tasks, and measure success rate, latency, and the cost per successful task before launch.
For content teams, this approach is highly practical: do not just think about making AI write more; first make it deliver more reliably.
¶ II. How Should You Choose Astra, Sol, and Luna? Treat Them as Different Roles
According to the positioning in the OpenAI official guide mentioned above, GPT-6 Astra is designed for the most difficult reasoning work; GPT-6.1 Sol is designed for complex coding, research, and computer operations; while GPT-6 Luna is more suited to repetitive tasks with clear objectives that need to be handled at scale, such as field extraction, classification, and structured summaries.
Rather than memorizing parameters, it is better to understand them as different roles within a team.
The following table provides selection recommendations based on content operations, not an official performance ranking:
| Content stage | Model recommended for priority evaluation | Main consideration |
|---|---|---|
| Article classification, field extraction, fixed-format summaries | GPT-6 Luna | The task is clear; first look at format accuracy and unit cost |
| Multi-source research, material organization, article integration | GPT-6.1 Sol | Requires judgment across materials and multi-step execution |
| Controversy analysis, complex argumentation, key content review | GPT-6 Astra | The cost of errors is higher, requiring deeper judgment |
For example, if we are preparing an article on “how enterprises should choose AI APIs,” we do not need to use the strongest model from the start to extract pricing and feature fields from different vendors’ documentation; analyzing the trade-offs among different solutions in complex business scenarios is worth investing more reasoning resources in.
Of course, this does not mean that content handled by “smaller models does not need to be checked.” Information such as prices, billing units, and version numbers can still be wrong, even if it is only being extracted.
A simple task only means the processing approach can be lighter; it does not mean the acceptance standards can be looser.
¶ III. Higher Reasoning Levels Are Not Always Better; It Depends on Whether This Step Is Worth It
After choosing a model, there is another variable that is easy to overlook: reasoning investment.
OpenAI’s guide describes reasoning levels as a trade-off between capability and price: Low corresponds to routine extraction or minor editing, Medium is used for work that requires judgment, and High is used for in-depth analysis and careful review; higher tiers should only be used when the model supports them and when the additional benefits are worth the time and cost.
Put more plainly:
- There is no need to make the model repeatedly deliberate over changing a title.
- When comparing three business solutions, you can give it more room to think.
- Determining whether two pieces of material have a substantive conflict is worth serious analysis.
You can start testing with the following approach:
| Task | Recommended starting point | When to upgrade |
|---|---|---|
| Tag classification, format conversion | Low reasoning investment | Clear ambiguity or rule conflicts appear |
| Article outlines, solution comparisons | Medium reasoning investment | Unable to explain trade-offs or key conditions are omitted |
| Fact conflict analysis, review of important conclusions | High reasoning investment | Key issues remain unresolved; then test higher tiers |
There is an important distinction here: thinking longer does not mean knowing more facts.
If a task requires the latest pricing or newly released product information, the first step is to fill in the sources, rather than simply increasing the reasoning level. When evidence is lacking, the best output may be “this information cannot yet be confirmed,” rather than a smoother guess.
In addition, the table above is a workflow recommendation, not a general API parameter table. The actually available tiers and parameter names should be based on the specific model and integration documentation.
¶ IV. “95% Savings From Caching” Is Attractive, but Do Not Miscalculate
Caching may be one of the optimization points most worth paying attention to in batch content production.
Brand introductions, writing guidelines, fixed terminology lists, review requirements... these materials often appear repeatedly in every request. OpenAI recommends placing stable instructions and reference materials before changing task details, and keeping tool definitions consistent in order to reuse shared context. The official guide notes that the cost of cached input can be reduced by up to 95% compared with uncached input, depending on the model.
But you must clearly understand this:
Cached input being 95% cheaper does not mean the production cost of the entire article decreases by 95%.
Taking the officially published GPT-6.1 Sol standard API pricing as an example: input costs $2 per million tokens, cached input costs $0.10, and output costs $10. What is cited here is OpenAI’s official standard pricing and does not represent the actual quotes of this site or third-party integration channels. For price changes, please refer to the service provider’s latest page. Let's create a demonstration example, not measured results:
Assume one task has:
- 20,000 input tokens;
- 15,000 of them can hit the cache;
- 3,000 output tokens.
| Cost item | All input misses the cache | 15,000 input tokens hit the cache |
|---|---|---|
| Uncached input | $0.0400 | $0.0100 |
| Cached input | $0 | $0.0015 |
| Output | $0.0300 | $0.0300 |
| Total | $0.0700 | $0.0415 |
Based on this assumption, token costs decrease by about 40.7%, not 95%.
Moreover, this does not yet include tool calls, failed retries, human review, and other potentially applicable costs.
Therefore, a more reliable approach is to split the prompt into two layers:
Stable layer: brand guidelines, writing style, output format, review rules.
Dynamic layer: the topic of this session, target readers, newly retrieved materials, current task requirements.
Then observe the cache hit rate in real requests, rather than directly putting the “maximum discount” into the project budget when you see it.
¶ V. Multi-agent systems are well suited for research, but not for dividing work just for the sake of excitement
A research-oriented article often includes several tasks that can be advanced independently:
- Check official documentation;
- Find real cases;
- Collect common questions;
- Verify pricing and features;
- Organize disagreements between different sources.
These tasks have a certain degree of independence and are suitable for parallel processing.
OpenAI’s guide introduces that GPT-6.1 Sol can assign independent tasks to sub-agents in the Responses API and then consolidate the results; this multi-agent capability is labeled as beta in the guide.
However, multi-agent systems are not a free efficiency improvement.
In Anthropic’s engineering retrospective on its research system, it mentions that multi-agent systems are suitable for research that expands in multiple independent directions, but they significantly increase token consumption; in the data they observed, the token usage of multi-agent systems was about 15 times that of ordinary chat. This number is experience from their specific system and cannot be directly applied to all products.
Therefore, I recommend arranging it like this:
Let multiple agents find evidence separately, let one editor organize the article consistently, and then have humans review it.
Do not let five agents each write five sections and then directly stitch them together. This can easily result in repetition, contradictions, and inconsistent writing styles.
Below is a process diagram suitable for content teams getting started:
The illustration is a methodological diagram generated by GPT Image 2 and does not represent measured performance.
To make this workflow truly useful, each subtask should preferably deliver four things:
- Conclusion: What was found.
- Sources: Where the evidence is.
- Limitations: Which situations it does not apply to.
- Items to confirm: What still cannot be concluded.
Pay particular attention: fact-checking is not asking another model whether it “thinks this passage is fine,” but having it compare against the sources again.
Multiple agents agreeing does not mean that a fact has been proven.
¶ VI. Long tasks need saved state, and automated operations need clearly defined permissions
For a short article, putting the materials into the context may be enough. For a series of special topics or ongoing maintenance of product documentation, the situation is different.
OpenAI’s guide introduces context compression, which is used to reduce the context size of long conversations while retaining the state needed to continue the task.
For content work, I recommend maintaining a separate task record regardless of which compression method is used:
- Confirmed facts and their sources;
- The product version currently in use;
- Unresolved conflicts in the materials;
- Completed and incomplete stages;
- Decisions that must be confirmed by humans.
Do not leave only vague summaries such as “we have already researched this issue.” What subsequent writing actually needs is evidence and boundaries.
The same applies to automated operations. Official guidance recommends prioritizing methods that can be completed directly through APIs or connected tools; only consider computer-operation capabilities when screen reading, clicking, or filling out forms is required.
For the blog workflow, AI can be allowed to automatically organize drafts, check links, and generate illustrations, but formal publishing, deleting articles, and modifying online configurations should be placed after human confirmation.
Being able to operate the backend does not mean it should have unlimited permissions.
¶ VII. Back to GEO: writing faster does not mean being more easily cited by AI
At this point, two questions need to be separated:
- Using AI to improve content production efficiency;
- Making content easier to discover and cite in generative search answers.
The former is a workflow issue; the latter is the core concern of GEO.
Early GEO research explored content visibility in generative engines and reported up to approximately 40% visibility improvement under its evaluation settings, while also noting that effects vary across different domains. This result cannot be directly understood as “follow this, and this site’s traffic will increase by 40%.”
Google’s official documentation is more practical: for AI Overviews and AI Mode, no additional special optimization requirements are needed; fundamental SEO, reliable and people-first content, remain important. Pages must be eligible for indexing and snippet display before they have a chance to appear as supporting links.
This does not represent the rules of all AI search products, but it at least reminds us: do not rush to look for a so-called “universal GEO template.”
For this site’s blog, I recommend first doing the following things well.
¶ 1. One article solves one real problem
“Comprehensively analyzing the future of AI” sounds broad, but it may not necessarily be useful.
“How to determine whether caching really saves money when generating product copy in bulk” is instead easier to explain clearly and more convenient for readers to apply directly.
¶ 2. Add applicable conditions to numbers
Do not simply write “a 40% cost reduction.”
Explain which model is used, how it is calculated, whether it includes output, tools, and human costs, and whether this figure is an experimental result or a demonstration example.
¶ 3. Do not hide key content only in images
Google explicitly recommends presenting important content in text form, and structured data should also remain consistent with the visible content on the page.
Therefore, charts can help with understanding, but the main text should still explain the conclusions, data, and conditions.
¶ 4. Separate facts, recommendations, and predictions
“Official documentation supports a certain feature” is one type of information.
“We recommend that the content team use it this way” is another.
“It may bring about certain changes in the future” is yet a third type.
Clearly distinguishing them is more valuable than writing every sentence with absolute certainty.
¶ 5. Observe real results, and do not blindly trust self-evaluation scores
You can establish a fixed set of questions and regularly record whether different AI search products cite this site, which article they cite, and whether the citation is accurate, then combine this with analysis of actual traffic and conversions.
Such tracking will still be affected by differences in time, region, and products, but it is at least more informative than giving an article a “high GEO score” with no publicly available basis.
¶ 8. What should really be optimized is the “cost per qualified article”
Content teams can easily focus on two numbers: how many articles are generated in a day, and how many tokens each article consumes.
But if 100 articles are generated and only 20 can ultimately be published, this efficiency may not be very high.
I recommend looking at this metric instead:
Cost per qualified piece of content = Total production cost ÷ Number of articles that pass review
Among these, total production cost should include model calls, retrieval tools, rework, and human review, rather than only the cost of the first generation.
In actual implementation, you can first select a batch of representative tasks for small-scale testing, rather than rolling it out across the entire site from the beginning.
Focus on recording:
| Metric | Question to answer |
|---|---|
| Factual error rate | Is there any fabrication, outdated information, or version confusion? |
| Source traceability | Can the original basis for key conclusions be found? |
| First-round review pass rate | How much content does not require major rework? |
| Cost per qualified article | After including failed tasks and human effort, how much does it actually cost? |
| Delivery time | From starting retrieval to being ready for publication, how long does it take? |
| Post-publication results | Does it generate effective traffic, citations, or business conversions? |
After testing, then decide: which tasks should be handled at a lower level, which stages should receive more reasoning investment, which research is worth conducting in parallel, and which steps must be handed over to humans.
¶ Final thoughts: Use intelligence where it should be used
GPT-6 gives content teams more choices, but having more choices does not mean the strongest configuration should be used at every step.
More worthwhile directions to try are:
Handle simple tasks lightly, reason carefully about complex judgments, reuse repeated context as much as possible, run independent research in moderate parallel, and retain review before formal publication.
The same applies to GEO.
No model can guarantee that an article will be cited. What we can do is ensure that it answers real questions, provides traceable evidence, and clearly explains its scope of applicability.
Ultimately, what is truly worth pursuing is not “letting AI write a little more,” but:
Making every piece of published content more worth reading and more able to withstand scrutiny.
¶ References
- OpenAI: GPT-6 Practical Guide
- OpenAI: Introducing GPT-6.1 Sol
- Anthropic: How we built our multi-agent research system
- GEO: Generative Engine Optimization (KDD 2024)
- Google Search Central: AI features and your website
This article is a compilation of materials and an application analysis, and does not constitute performance testing by this site. Model capabilities, testing stages, and pricing may change; please refer to the service provider’s latest documentation.