blog

How to set up Astra in Codex without wasting your usage allowance

Neaptide · September 20, 2026 · 11 min read

Choose Astra’s reasoning level, review project instructions and give Codex a clear task. Practical prompts, context limits and ways to track usage.

On this page

Diagram of Astra reasoning levels for typical coding tasks.

You ask Codex to fix an enquiry form. It reads through half the project, runs checks, suggests a few more improvements, then asks whether it should continue. The form still isn’t ready, and some of your allowance is already gone.

Before changing models, look at the instructions. Old project rules, an overly broad request or an unclear definition of “done” may be sending the agent off course. A more capable model still needs a clear brief.

Start with three changes: match reasoning effort to the task, remove mandatory steps that don’t serve that task, and describe a result you can verify. Then compare usage and rework on your own projects.

This article draws on the GPT-6 Astra walkthrough by Edvard Grishin, whose channel covers AI and business automation. The video is in Russian. We selected practical questions from it and checked the technical details against OpenAI’s documentation. The examples below are illustrative, not results from Neaptide client projects.

Know which settings belong to the model and which belong to Codex

Astra is the model. Codex is the environment that gives it access to files and tools. Whether the agent can open a website, edit a project or run a check depends on that environment, its settings and its permissions.

Advice about the API therefore doesn’t always translate into an equivalent setting in the app. The model’s advertised context window also doesn’t tell you how much context is available in your current session.

If you’re new to Codex, start with our getting-started guide. Our GPT-6 Astra overview covers model capabilities and published benchmarks. This guide focuses on day-to-day work.

Match reasoning effort to the task

The Astra API supports five `reasoning.effort` levels: `low`, `medium`, `high`, `xhigh` and `max`. This setting controls how much effort the model spends reasoning. The controls available in a particular interface may differ. Source: OpenAI’s model page.

Source: OpenAI’s model page

There’s no need to select the maximum for every request. Start with familiar tasks whose results you can assess yourself. The table below is a suggested starting point for comparison, not a quality guarantee.

Task
Task	Setting to try first	What to check
Fix a typo or replace approved copy	Low	Every intended instance changed; layout still works
Add a field to an existing form	Low or Medium	Validation, submission and storage all work
Diagnose an intermittent bug	Medium, then High if needed	The cause can be reproduced and the fix has been checked
Plan a data migration	Include High in your comparison	Data loss, compatibility and rollback are addressed; a specialist reviews the plan

Low isn’t necessarily cheaper over the whole job. If the first attempt needs three rounds of corrections, the initial saving may disappear. Higher effort doesn’t remove the need for verification either: a longer reasoning process is not proof of a correct answer.

Compare the cost of a completed, accepted task. Include waiting time, usage and your own involvement: how often did you need to explain the request again, find mistakes or send the work back?

For developers, Astra’s Responses API supports changing effort between responses with `configuration_update` while preserving the original prefix for caching. Restrictions apply, including support only in standard single-agent mode. That doesn’t establish how every effort selector in an app behaves. Documentation on changing reasoning effort.

Documentation on changing reasoning effort

Starting reasoning levels for a small edit, a new feature and difficult diagnosis. — Choose a starting level and compare results on your own task. This is guidance, not a quality guarantee.

Check whether old rules are creating unnecessary work

Your project may have accumulated instructions such as “read the entire architecture before every edit” or “run every check after any change.” They may once have helped. Now the same requirement applies to a new integration and a heading change.

OpenAI specifically recommends auditing `AGENTS.md` and skill files when using Astra, because the model is sensitive to their instructions. Conflicting rules can cause pauses and unnecessary approval requests. OpenAI’s Astra guidance.

OpenAI’s Astra guidance

A useful rule explains when and why an action is needed. For example:

Overly broad rule
Overly broad rule	More precise rule for an example project
Read all documentation before every edit	Before changing the form, read its field and submission documentation
Always ask before taking the next step	Make and check local changes independently; ask separately before publishing
Run every test after each change	When changing pricing logic, check calculations and checkout; run the project’s required checks before release

Don’t remove testing requirements on the assumption that a newer model “checks everything anyway.” Keep mandatory product checks and access restrictions. Revise rules that impose the same amount of work regardless of the task.

Use a request like this to review them:

Review the current project instructions and the skills in use.
Find repeated or conflicting rules and requirements that create
unnecessary work on small tasks.

For each issue, identify the file and rule, give an example of the
problem, and suggest revised wording.
Preserve requirements for security, data handling and mandatory checks.
Show your recommendations first. Do not change the rules yet.

There’s also a technical reason to keep instructions concise. Codex combines them from several files, with a default combined limit of 32 KiB. If you have extensive rules, check which ones actually loaded. How Codex reads AGENTS.md.

How Codex reads AGENTS.md

Define what finished work looks like

“Make the form easier to use” leaves too many decisions open. The agent might redesign it when the real problem is that enquiries aren’t reaching the sales team.

As a business owner, describe the customer journey and an outcome you can check. For example:

Add an optional “Company” field to the enquiry form on the service page.
Include its value in the email sent to the sales team.

The work is complete when:
1. The form submits with the field filled in or left empty.
2. The test email contains the company name entered.
3. The field and submit button fit within a mobile screen’s width.
4. Existing required fields are still validated as before.

Make local changes and run checks independently.
Use test data. Do not publish changes or email real customers.
Show the result and state what you checked and what you could not check.

You don’t need to prescribe the code. The purpose of the change and the acceptance criteria are clear. If the email service is unavailable, the agent should say so. Checking the form’s appearance doesn’t establish that an email was delivered.

Keep this structure as a reusable brief: task, expected behaviour, constraints, checks and the result to deliver. Fill in the details for each job.

Three form checks: submission, data in the test email and the mobile layout. — Illustrative example: a good-looking screen does not prove the form works. The prompt above contains the full acceptance criteria.

Expand context only when you have a reason

Context is the information the model works with in a request: conversation history, instructions, documents and tool results. A large window helps when the task genuinely requires comparing a lot of material. It doesn’t make irrelevant files useful.

Astra’s official model page lists a context window of 1,050,000 tokens. In the API, requests with more than 272,000 input tokens cost more: input and cache rates are multiplied by 2, and output rates by 1.5, for the entire request. These are API terms, not a formula for deducting your subscription allowance. Astra specifications and pricing conditions.

Astra specifications and pricing conditions

Before increasing context, review what you’re including. A form change needs the form’s code, validation rules and submission details. Old proposal drafts and a complete archive of working notes are unlikely to help.

For work spanning several days, maintain a short handover document: decisions made, files changed, checks completed and remaining tasks. When starting a new session, include the current source files alongside it. A summary doesn’t replace the evidence behind its conclusions.

Use subagents when the work can be split

A subagent is a separate helper assigned part of the main agent’s task. In a website review, one could inspect the enquiry form, another the catalogue search and a third the mobile menu. Each returns findings with steps to reproduce them.

OpenAI advises considering whether tasks are independent and being careful with simultaneous file edits, which can conflict. Each agent also consumes tokens for its own work. Adding more agents doesn’t guarantee lower costs. Subagent documentation.

Subagent documentation

Several helpers are usually hard to justify for a small edit. For a larger review, give each a clear scope and expected output. Instead of “check the site,” try “check these three form-submission scenarios, list failures and reproduction steps, and do not edit the code.”

Once the findings are combined, check the complete journey. Three successful component reviews don’t establish that everything works together.

Track usage rather than relying on a budget prompt

The video suggests describing a budget in natural language. That can express a preference, but “stop when 25% remains” is not a guaranteed spending control. The agent would need current usage data and a way to stop in time.

Codex usage depends on the model, task complexity, context, tools and caching. OpenAI explicitly says prompt length alone is not a reliable estimate. Check the usage interface for current allowances and reset times. How Codex usage limits work.

How Codex usage limits work

Start a simple log for a few typical tasks:

Task
Task	Model and effort	Usage shown in available data	Revisions	Result accepted
Replace copy	…	…	…	Yes / no
Change a form	…	…	…	Yes / no
Diagnose a bug	…	…	…	Yes / no

This is a recording template, not a Neaptide benchmark. If other tasks are running concurrently, you can’t attribute the entire change in your remaining allowance to one job. With the API, record usage per request. With a subscription, use the available detail and note its limitations.

Change one setting at a time. If you shorten the rules, change models and add helpers together, you won’t know which change made the difference.

Task cost includes the first run, checks and revisions, and your time. — Compare costs through to an accepted result. This diagram contains no measured values or promised savings.

Turn repeatable work into a regular automation

Suppose you receive a file of enquiries each week, standardise its column names and prepare a summary. An agent can help understand the format and write the processing script initially. If the rules are stable, subsequent runs can use that script.

Decide in advance what should happen when there’s a new column, an empty file or an invalid date. Preserve the original file and report failures. Otherwise, the automation may produce incorrect reports faster.

This doesn’t make the process free: running it, using external services and maintaining it still have costs. It does remove the need to ask a model to devise the same processing steps every week. Bring the agent back when the data or requirements change.

Start with one familiar task

Choose something you’ve done recently, such as changing a form or updating a service page. Write down acceptance criteria, check the relevant instructions and choose an initial effort level. Assess the actual result, not just the agent’s explanation.

If it works, compare a similar task under another setting. If it doesn’t, find the cause first. Missing access, a conflicting rule and insufficient reasoning call for different fixes. Turning everything up to maximum won’t solve all three.

Technical information checked on 20 September 2026. Available settings and usage terms may change.

faq

The short version

Should Astra always run on Low?

No. Try Low for a small, well-defined task that is easy to verify. For difficult diagnosis, compare higher levels. Choose based on the accepted result and the total cost of revisions.

Can I remove all testing rules from AGENTS.md?

Keep the project’s mandatory checks. Revisit overly broad instructions that demand the same steps for correcting a typo and changing business logic.

Is a maximum budget in the prompt enough?

No. It doesn’t guarantee a spending cap. Check the usage tracking and spending controls available in your product. Instructions can supplement those controls, not replace them.

Will several agents do the job more cheaply?

Not necessarily. They may save time on independent tasks, but each does its own work and combining results takes effort. Measure any saving in the actual workflow.

Should I move all work to Astra?

Start with tasks that previously needed substantial rework. For simple, recurring operations, compare a less expensive model or an existing automation. You don’t have to use one model for every job.