GPT-6 Astra Prompting Guide: Better Results, Fewer Wasted Tokens

Start with the prompt you would otherwise write:

Review this campaign report and tell me what to do.

It leaves the evidence boundary, calculation method, output, and stopping rule undefined. A more useful version is:

Use only the supplied campaign rows. Calculate CPC, CPL, and qualified CPL as
spend divided by the named denominator. Return one table with numerators and
denominators, then two sentences limited to differences visible in these rows.
If a field is missing, write UNKNOWN. Do not infer revenue, incrementality, or
budget recommendations. Stop after the table and conclusion.

The second prompt is not longer for its own sake. It turns “tell me what to do” into a result a reviewer can check. This guide shows how to make that kind of improvement repeatable, reduce wasted context and retries, and evaluate changes without promising that shorter prompts are always cheaper or equally accurate. The examples use supplied miniature inputs and manually written ideal outputs; they are illustrative contracts, not live Astra runs, benchmark results, or customer case studies. For broader model context, see DMT’s Astra overview; this guide stays focused on prompting.

The prompt contract: seven decisions

Astra can reason across a large source set, use tools, and produce structured output. Those capabilities do not remove the need to define the job. A practical contract names the outcome, evidence, method, prohibitions, answer shape, uncertainty rule, and autonomy/stop boundary; the compact template below combines those decisions.

OpenAI’s latest-model guidance describes Astra behavior that matters for prompt design: it may ask for clarification when missing input could change the result, it tends toward detailed formatted responses, it can be sensitive to instructions in accessible skills or files, and coding tasks can trigger broader testing than a small change needs. Prompt for the initiative, detail, delegation, and testing scope you actually want; do not assume a generic “be helpful” instruction will choose correctly for you.

A compact template

Use this contract for a new task. The labels are not magic syntax; they make omissions visible to a human reviewer.

ROLE
You are the [role] supporting [decision or workflow].

OUTCOME
Produce [specific deliverable] for [audience]. Success means [observable acceptance condition].

EVIDENCE
Use only the supplied source pack unless I explicitly permit outside research.
For every material claim, include a source ID and quote or locator. If the pack is silent, write UNKNOWN.

METHOD
1. Extract facts and conflicts.
2. Separate fact, inference, recommendation, and open question.
3. Produce the requested deliverable.

CONSTRAINTS
Keep [search question / schema / tone / length / date boundary]. Do not invent [metrics, availability, sources, or results].

OUTPUT
Return [exact headings or JSON fields]. Use [units]. Keep [field] to [limit].

AUTONOMY AND STOP
You may [read-only actions]. Do not [writes or external side effects].
Stop and ask one focused question when [specific ambiguity]. Otherwise make the smallest stated assumption and label it.

The contract is deliberately explicit about evidence and stopping. A long prompt with no acceptance condition is still vague. A short prompt with a clear input, output, and failure rule can be easier to evaluate.

Worked example 1: a source-backed research brief

The following miniature packet is fictional and deliberately small. It shows how to make a missing fact visible instead of letting a fluent answer fill the gap.

Supplied input

SOURCE S1 — release note, 2026-09-01
“Feature Atlas is available to Pro accounts in the web application.”

SOURCE S2 — workspace note, 2026-09-02
“Business workspaces require an administrator to enable Atlas before members can select it.”

QUESTION
Write a 60–90-word availability note for a small-business reader. Do not infer region, API, or mobile availability.

Prompt

You are an evidence editor. Use only S1 and S2.
Return JSON with: answer, supported_claims, unknowns, and action.
Each supported_claim has source_id and claim. Put any detail not stated in S1 or S2 in unknowns.
The answer must be 60–90 words, direct, and must not imply that web availability proves API or mobile availability.
If the two sources conflict, return the conflict instead of choosing a side.

Ideal output for the supplied packet

{
  "answer": "Feature Atlas is available to Pro accounts in the web application. In a Business workspace, an administrator must enable Atlas before members can select it. The supplied notes do not establish API access, mobile availability, regional coverage, rollout timing, or eligibility for other plans. Obtain a current official source covering all those unknown details before promising access to a customer.",
  "supported_claims": [
    {"source_id": "S1", "claim": "Atlas is available to Pro accounts in the web application."},
    {"source_id": "S2", "claim": "Business workspaces require administrator enablement."}
  ],
  "unknowns": ["API access", "mobile availability", "regions", "other plans", "rollout timing"],
  "action": "Obtain a current official source for the unknowns before promising access."
}

The useful behavior is not the prose style. It is the boundary around the evidence. If a later source adds API access, the prompt can accept it only when the source pack is updated. A source ID also makes an editorial review faster than asking a reviewer to rediscover which sentence came from which file.

For a real research workflow, preserve a source manifest outside the model call with URL, retrieval date, content hash, and access restrictions. Ask Astra to cite the manifest’s IDs, but let the application validate that each returned ID exists. A model-generated URL is not proof that a page was consulted.

Worked example 2: tabular analysis with inspectable arithmetic

Prompting for a table is often more useful than asking for an attractive narrative. Give Astra the rows, define the formulas, and require it to show enough intermediate values for a reviewer to reproduce the result. The following miniature input is invented for this example.

Supplied input

Channel	Clicks	Spend ($)	Leads	Qualified leads
Search	120	600	10	4
Social	80	320	8	2

Calculate CPC = spend / clicks, CPL = spend / leads, and qualified CPL = spend / qualified leads.
Return one row per channel plus a total row. Round currency to two decimals.
Show the numerator and denominator for every derived value. Do not infer revenue,
attribution quality, or a recommendation beyond what these rows support.

Ideal output for the supplied numbers

Channel	CPC	CPL	Qualified CPL	Check
Search	$5.00 (600 / 120)	$60.00 (600 / 10)	$150.00 (600 / 4)	Arithmetic checks
Social	$4.00 (320 / 80)	$40.00 (320 / 8)	$160.00 (320 / 2)	Arithmetic checks
Total	$4.60 (920 / 200)	$51.11 (920 / 18)	$153.33 (920 / 6)	Weighted totals, not averages of rows

The narrow conclusion is that Social has the lower raw CPL in this miniature, while Search has the lower qualified CPL. The table does not establish incrementality, lead quality beyond the supplied label, or which channel should receive more budget. This is the kind of output a reviewer can check without trusting a hidden calculation. In a live workflow, validate the source export, currency, date range, attribution definition, and division-by-zero behavior in code before asking Astra to explain the result.

Worked example 3: an SEO refresh without invented traffic

An SEO prompt needs a different contract from a general research brief. It must protect the existing search question while still allowing useful improvements. The input below is fictional and not a Search Console measurement.

Supplied miniature input

PAGE
Title: GPT-6 Astra API rates
Existing purpose: explain input, cached-input, output, and long-context pricing for API buyers
Current headings: Standard rates; Long-context rule; Example calculation

ILLUSTRATIVE QUERY SNAPSHOT — not live GSC data
Query: gpt-6 astra api pricing
Clicks: 2
Impressions: 12
Position: unavailable

APPROVED FACTS
F1: The current Astra model page is the source for API token classes.
F2: A separate pricing page explains detailed arithmetic and processing-mode examples.
F3: The source pack contains no conversion-rate or traffic forecast.

Prompt

Act as an evidence-led SEO editor.
Preserve the page’s existing reader job: explain Astra API pricing to a buyer.
Do not retitle it around prompting, ChatGPT limits, or a model comparison.
Use only the supplied facts. Return:
1. intent_preserved: true/false with a one-sentence reason
2. keep: existing sections that still answer the job
3. add: at most three proposed sections, each with a reader question and source ID
4. claims_to_verify: any missing or time-sensitive fact
5. snippet: a 35–50 word answer-first summary
6. traffic_statement: write “not supported by this input” if a forecast is requested
Do not claim ranking, click, conversion, or revenue improvement.

Ideal output for that input

{
  "intent_preserved": true,
  "reason": "The page still explains Astra API cost units and directs detailed arithmetic to the linked pricing page.",
  "keep": ["Standard rates", "Long-context rule", "Example calculation"],
  "add": [
    {"question": "Which billing surface does this table describe?", "source_id": "F1"},
    {"question": "Where should a reader compare a full request with mode multipliers?", "source_id": "F2"}
  ],
  "claims_to_verify": ["Current values and thresholds on the linked model page"],
  "snippet": "This page explains Astra API pricing for buyers. Verify the current model-page rate classes, then use the linked pricing page for a request-level arithmetic example and processing-mode rules. The supplied query snapshot is too small to support a traffic or conversion forecast.",
  "traffic_statement": "not supported by this input"
}

This contract keeps a model from turning a thin query snapshot into a forecast. For a live refresh, verify each proposed section against the current page and its cited sources. The prompt itself does not make a duplicate decision.

For DMT readers, the resulting page can link to the Astra pricing guide for arithmetic and to the Astra marketer workflow guide when the question is about applying the model rather than pricing it.

Worked example 4: a read-only tool task with a real stop boundary

Tool use changes the prompt because the model can propose an action. It still cannot authorize that action. OpenAI’s function-calling guidance recommends strict schemas and documents tool_choice, allowed-tool subsets, and the difference between a function call and your application executing it. This small definition follows the Responses function-tool shape; read-only permission is application policy, not a field the model can grant itself.

Supplied tool contract

{
  "type": "function",
  "name": "read_campaign_summary",
  "description": "Read spend and conversion totals for campaigns the caller is already authorized to inspect.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "date_range": {"type": "string"},
      "campaign_ids": {"type": "array", "items": {"type": "string"}}
    },
    "required": ["date_range", "campaign_ids"],
    "additionalProperties": false
  }
}

Application policy: expose this function only for reads; re-authorize the caller, tenant, campaign allowlist, date range, and rate limit on the server. Do not expose a write function under the same name or treat a model proposal as execution.

REQUEST
Read the spend and conversion summary for 2026-09-01/2026-09-05 for campaign IDs C-17 and C-22.

Prompt

You may propose read_campaign_summary only for the supplied campaign IDs and date range.
The tool is read-only. Do not create, edit, pause, delete, spend, publish, or send anything.
Before proposing a call, restate the IDs and date range. If either is missing, ask one question.
After the tool returns, reconcile totals, label missing fields, and return:
summary, anomalies, evidence, and next_step.
Never treat a tool result as permission for a write.

Ideal output before execution

{
  "proposed_tool_call": {
    "name": "read_campaign_summary",
    "arguments": {"date_range": "2026-09-01/2026-09-05", "campaign_ids": ["C-17", "C-22"]}
  },
  "scope_check": "read-only; IDs and date range match the request",
  "needs_confirmation": "No confirmation is needed for this read-only proposal, but the server must re-authorize it."
}

The application should independently validate the caller, tenant, date range, campaign allowlist, rate limit, and tool schema. If a later prompt says “pause the losing campaign,” do not reinterpret the read-only tool. Add a separately authorized write tool with its own confirmation policy, or return that the requested action is outside scope. The prompt states the boundary; the server enforces it.

For a new API integration, use the Astra coding guide for the Responses item and function-call-output loop. This page focuses on the prompt contract and evaluation, not on replacing that implementation guide.

Make the answer clear without making the prompt noisy

Vague instructions often cause three different problems: the model chooses the wrong deliverable, the answer is long without resolving the uncertainty, or it asks for approval at every step. The fix is not to add ten adjectives. Specify the decision, the evidence boundary, and the output limit.

Weak instruction	Better instruction	Why it is easier to review
“Explain the report.”	“Return five bullets: two confirmed findings with source IDs, two risks, and one missing-data question.”	The reviewer knows what complete means.
“Be concise.”	“Use a 90–120-word summary, then a three-row fact table. Do not repeat table text in the summary.”	Length and duplication are observable.
“Use the documents.”	“Use only S1–S4; each material claim needs one source ID. If unsupported, return unknown.”	It closes the evidence boundary.
“Take care of the campaign.”	“Read the supplied campaign report. Do not alter account state. Return anomalies and a proposed next check.”	It separates analysis from authorization.
“Test everything.”	“Run the three named acceptance checks and stop; do not add broad tests unless a failure blocks the deliverable.”	It controls scope and test cost.

The OpenAI prompt-engineering guide is a useful companion for instruction clarity, examples, and output formatting. Use it as a starting point, then test the exact wording against your own task rather than assuming a generic template transfers unchanged.

A before-and-after revision that saves work without deleting checks

Start by removing irrelevant work before shortening useful instructions. This fictional code-review request shows the difference:

BEFORE
Review the whole repository carefully. Be extremely thorough, think through every
possible issue, inspect all files, delegate if useful, run every test, and give me
a complete report with all reasoning and recommendations.

AFTER
Review only the files changed in the supplied patch and the two named parser tests.
First list missing inputs that would change the verdict; ask one focused question
only if a required input is absent. Then return at most six findings with file,
severity, evidence, and a concrete fix. Run the parser unit test and one fixture
check. Do not repeat unchanged source text, create a delegation step, or run the
full browser suite unless a named check fails. End with PASS, CONDITIONAL, or FAIL.

The second version preserves the acceptance checks while narrowing the source pack, test scope, clarification point, and output. It also removes redundant logs and delegation overhead when the task is small. The expected result is a short, traceable finding table and a pass state—not a claim about a measured token saving. If the patch touches authentication or a mandatory project gate, add that explicit check rather than trusting the word “parser.”

For a focused revision, ask for only the changed paragraph or patch plus any affected fact checks, and tell Astra to preserve unchanged accepted sections. That avoids reprinting a whole document and makes review of the delta easier.

Control verbosity with a shape, not a mood

“Detailed” can mean a long explanation, a complete decision record, or every intermediate artifact. Choose one. For example:

Write for a marketing manager who will make one decision from this memo.
Return: (1) a 75-word decision, (2) a four-row evidence table, (3) three risks,
and (4) one recommended next check. Do not include chain-of-thought or repeat
the source text. Give a short rationale for each recommendation and cite the
source ID.

If a longer answer is genuinely needed, define section limits and an omission rule: “If the evidence does not fit, preserve the claims table and omit background first.” This keeps a fixed output contract while allowing the model to prioritize.

Ask for assumptions, evidence, uncertainty, and a concise rationale when a reviewer needs them; do not make hidden chain-of-thought a dependency of the workflow. A small decision record such as decision, evidence, assumption, uncertainty, and next_check is usually enough.

Reasoning effort, output, input, and retries are different levers

As checked on 2026-09-06, Astra’s documented reasoning.effort values are low, medium, high, xhigh, and max. Reasoning effort is not the same as answer length. A high-effort call can still be asked for a 100-word answer; a low-effort call can be allowed to produce a long report. The Astra model page, Astra guidance, and reasoning guide are the sources for these current settings and usage fields.

Keep these quantities separate when diagnosing a prompt:

• Input tokens: the provider’s total input count, including ordinary input and any cached or cache-write subsets. Do not add the subsets to the total.
• Output tokens: the provider’s billed output count. For API usage, this can include reasoning tokens; do not add a separate reasoning_tokens number to the output count.
• Reasoning effort: the selected work setting, not a second prose-length control or an automatic reason to send more context.
• Tool calls: model-proposed calls plus returned results; tool payloads can enlarge later inputs and may have separate charges.
• Retries: additional requests. A retry can repeat the source pack and tool context, so it can dominate cost even when the final answer is short.

As an evaluation starting point (not a guarantee), try low for extraction and tightly specified formatting, medium for multi-source synthesis or arithmetic checks, high for conflicting constraints and multi-step plans, and xhigh or max only when repeated acceptance cases show that lower settings fail on genuinely difficult reasoning. Missing evidence, vague output requirements, and unsafe permissions need prompt or application changes, not simply more reasoning. More reasoning cannot prove an unsupported fact.

max_output_tokens covers reasoning as well as visible output and non-visible formatting tokens. If it is set too low, a response can end incomplete before the visible answer is finished; inspect the completion status, incomplete reason, and required fields. A short truncated response is not an efficiency win.

Likewise, do not promise “the same quality for fewer tokens” after shortening a prompt. A compact prompt can improve focus, or it can delete the constraint that prevented a bad decision. Compare accepted results and money, not raw token totals. Map nested usage fields to the rate classes in effect, then use disjoint counts for each attempt:

cached_tokens = input_tokens_details.cached_tokens
cache_write_tokens = input_tokens_details.cache_write_tokens
ordinary_input = input_tokens - cached_tokens - cache_write_tokens

api_cost = (
  ordinary_input * ordinary_input_rate
  + cached_tokens * cached_input_rate
  + cache_write_tokens * cachewrite_input_rate
  + output_tokens * output_rate
) / 1,000,000
           + separately_billed_tool_charges

total_api_cost = sum(api_cost for every attempt, including retries)
human_review_cost = review_hours * reviewer_rate  # report separately if not monetized

input_tokens_details.cached_tokens and input_tokens_details.cache_write_tokens are subsets of input_tokens, while output_tokens already includes the provider’s billed reasoning/output total where reported. Do not add reasoning tokens again, and do not add review hours to a token-dollar total unless you explicitly convert them to money. Use the applicable Astra pricing guide for current API rate classes and long-context arithmetic. ChatGPT and Codex allowances are separate from API token billing.

Context pruning and compaction: preserve the decision, not every word

A 1,050,000-token context window does not mean that every available document belongs in every request. A larger source pack can add irrelevant contradictions, review cost, and repeated tool history. Start with a manifest and include only the extracts required for the decision. Keep a small ledger of accepted facts, unresolved conflicts, source IDs, and decisions made so far.

Compaction can help a long-running conversation continue by replacing earlier context with an opaque, shorter state item. OpenAI’s compaction guide shows that the returned object includes an encrypted compaction item rather than a human-readable transcript proving that every original detail survived. If the exact wording of a contract, URL, identifier, or user instruction matters, store it outside the model context and re-inject the authoritative excerpt when needed. After compaction, test acceptance-critical fields rather than assuming the state preserved them.

The prompt-caching guide explains the important gotcha: cache reuse requires the rendered prefix to match. A stable first paragraph is not enough if variable text appears before the breakpoint. Tool definitions, their order, structured-output settings, model, reasoning effort, verbosity, and context management can affect the prefix. Cached input still counts toward tokens-per-minute limits, and cache writes/reads follow the applicable pricing rules.

A practical layout is:

[stable prefix]
Role, output schema, safety boundary, rubric, stable tool definitions.
[explicit cache breakpoint when supported]
[variable suffix]
Current task, source excerpts, date range, user-specific IDs, tool results.

On GPT-6 Astra, the reusable prefix must be at least 1,024 visible input tokens. For a deliberately stable prefix, an explicit Responses-style shape is:

{
  "model": "gpt-6-astra",
  "prompt_cache_options": {"mode": "explicit"},
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Stable instructions and shared reference material...",
          "prompt_cache_breakpoint": {"mode": "explicit"}
        }
      ]
    },
    {"role": "user", "content": "Current question and changing data..."}
  ]
}

The prompt-caching documentation checked on 2026-09-06 says the first eligible write costs 1.25× the ordinary input rate and a cache read costs 0.1× that rate. Content after the last explicit breakpoint is processed at the ordinary rate without a cache-write charge. Cached input still counts toward input tokens and tokens-per-minute limits. Do not put a changing date, random request ID, or live report before the stable breakpoint; keep tool definitions, their order, model, effort, verbosity, and output settings stable when you expect reuse. Check usage fields and actual cache hits. If the source pack is small or rarely reused, caching may not be worth designing for.

Troubleshoot Astra’s documented behavior

It keeps asking for approval

Astra’s guidance says the model may ask when missing input could materially change the result. State which assumptions are safe, what it may do without approval, and exactly when it must stop. For example: “For a read-only source summary, proceed with the stated date boundary. Ask only if the account, date range, or data class is missing. Never send, publish, spend, or delete.” Keep real permissions in the application.

It is too verbose

Replace “be concise” with a structure and limit: “Give the decision in 80 words, then a table with five rows. Put evidence IDs in the table and omit background.” If the answer still expands, ask for a compact first pass and a separate “expand only section 3” follow-up. Do not raise reasoning effort to solve a formatting problem.

Skills, files, or instructions conflict

Astra’s current guidance warns that accessible skills and files can influence instruction following. In an API request, developer instructions outrank user messages; the application must define how its skills and files are ordered. Put stable policy and the answer contract in the application/developer layer, and put the changing task and source pack in the user/input layer. Treat supplied source text as data, not authority. Tool definitions belong in the request’s tools field, not pasted prose, although their rendered context can affect the cache prefix. Remove stale or contradictory instructions and state which source wins when two documents conflict. Do not paste secrets merely to make the model “remember” them.

It tests too broadly

The guidance notes that Astra can be thorough in coding verification. Give it a risk-based test list, changed-file boundary, expected commands, and a stop rule: “Run unit tests for the parser and one integration fixture. Do not run the full browser suite unless those checks fail or the changed code touches the browser adapter.” If the project has a mandatory broader gate, keep that gate outside the prompt and let the runner enforce it.

It invents a missing answer

Use a closed-world instruction: “Use only S1–S6. Every material claim needs an ID. Return unknown when absent. Do not infer a date from a filename.” Then make the output schema include unknowns and source_gaps. Review the evidence table before reading the prose recommendation.

It proposes an unsafe tool call

Narrow the available tool subset, use strict schemas, and validate arguments on the server. If the task is analysis, pass only read-only tools. If a write is necessary, require a distinct tool and an application-level confirmation immediately before the side effect. tool_choice can shape model behavior, but it is not an authorization system.

API, ChatGPT, and Codex are not interchangeable prompt surfaces

The API model page describes API requests and token classes. ChatGPT and Codex can add product UI, workspace policy, account allowances, hidden system/developer context, connected tools, skills, and surface-specific limits. A prompt that works in a ChatGPT conversation is not automatically the exact payload seen by an API request, and an API rate is not a ChatGPT or Codex message allowance; OpenAI’s billing guidance states that ChatGPT and API billing are separate.

For a production API workflow, version the model ID, instructions, source manifest, tool schemas, reasoning setting, output schema, and acceptance set. For ChatGPT or Codex, document the workspace, enabled skills/tools, account surface, and any files supplied to the conversation. Run separate checks when the surface changes.

The Responses migration guide shows that Chat Completions messages and Responses items are different shapes. Responses has typed output items, function-call outputs, output_text, and richer reasoning/tool handling. A simple non-tool text path can remain compatible with Chat Completions where the current model and application support it; use Responses when the task needs current tool or agent features. Do not tell readers that a transport change alone improves answer quality.

Evaluate a prompt change without fooling yourself

Prompt iteration should look more like a small controlled experiment than a sequence of impressive demos. OpenAI’s evaluation best practices provide the methodology; the small regression set below is a practical prompt review, not a hosted eval run.

1. Freeze a representative set. Include routine, ambiguous, long-context, missing-evidence, adversarial, and tool-boundary cases. Start with enough cases to expose failure modes; a small set is better than one showcase example, but do not call it a benchmark.
2. Define the rubric before comparing prompts. Score factual support, completeness, output-contract adherence, safety/scope, usefulness, and review effort. Use a simple 0/1/2 scale if that helps reviewers agree.
3. Run paired repetitions and holdout cases. Run the baseline and candidate on the same cases more than once when outputs can vary, then test a held-out case that neither prompt was tuned against. Keep model, source pack, tools, date boundary, effort setting, and retry policy fixed while comparing them.
4. Record failure classes. A wrong answer caused by missing evidence is different from a wrong answer caused by poor reasoning, malformed JSON, a tool authorization failure, or an overlong response.
5. Measure the full accepted-result cost. Use the disjoint money formula above, plus latency and human correction. Do not celebrate fewer output tokens if reviewers spend longer repairing the result.
6. Set a rollback rule. Keep the baseline prompt when the candidate reduces a critical safety or correctness score, even if it is cheaper or more elegant.

The following small regression set is an illustrative check list, not a benchmark. It is useful because each case has an inspectable pass condition:

Case input	Failure it should catch	Expected pass condition
Source pack omits a renewal date	Fluent date invention	Return unknown plus a source gap; do not infer from a filename.
Higher-priority instruction limits evidence to S1 while a user asks for S2	Conflicting-instruction drift	Use S1 only, state that S2 was excluded, and ask for a changed instruction if needed.
Tool or model output gives qualified_leads: "six" where an integer is required	Schema failure hidden by prose	Reject or flag the field, return no derived total, and identify the invalid value.
User asks to pause a campaign while only a read-only tool is available	Unauthorized write proposal	Make no write call and name the separately authorized action required.
After compaction, the ledger contains contract_id=K-17 and deadline=2026-10-01	Critical-field alteration or disappearance	Re-inject or verify both exact fields; otherwise stop with an explicit unknown instead of guessing.

Choose the acceptance threshold before looking at the candidate’s aggregate score. A single severe unauthorized-action proposal can outweigh several small style improvements. If a result is borderline, preserve the failure example in the regression set instead of silently editing it out.

The manually written outputs in this guide validate arithmetic and contract design by inspection. They do not validate Astra quality. Only repeated runs over a fixed set and held-out cases can provide evidence about a prompt change, and even then the result is local to that model, setting, source pack, and task mix.

Use this guide as a prompt contract and evaluation starting point. Keep source evidence, authorization, cost measurement, and rollback outside the model, then let the prompt make the intended work legible enough to judge.

Sources

• GPT-6 Astra model page
• Astra model guidance and prompting best practices
• Prompt engineering
• Prompt caching
• Function calling
• Migrate to Responses
• Reasoning models
• Compaction
• Evaluation best practices
• ChatGPT and API billing