GPT-6 Astra Behind Claude Code: Treat the Gateway as Part of the Agent

I’d split an Astra integration into two separate projects: calling the model from an application, and putting it behind Claude Code. The first is an SDK integration. The second is a protocol-translation system that needs its own tests.

For a chatbot, I’d start with /v1/responses. For Claude Code, I’d put an Anthropic-compatible gateway in front of that endpoint—and verify more than text generation before letting it modify a repository.

The specifications, prices, and benchmark numbers below are the published figures cited in the source documentation, not results from my own repository evaluation.

Pick the execution environment first

Claude Code is the developer-agent interface, not the model itself. It handles repository inspection, file edits, terminal commands, tests, and the surrounding tool loop. A gateway can potentially route those requests to a different model provider.

That makes three architectures worth distinguishing:

What I need	Starting point
An Astra chatbot or application backend	Responses API
Astra inside an existing Claude Code workflow	Claude Code plus a translation gateway
Native Astra-specific coding features	Codex
A custom production agent	Responses API plus application-owned orchestration
Multiple models evaluated through one coding interface	Claude Code plus a gateway

Codex matters here. OpenAI’s launch material describes an Astra mechanism for preserving notes across context windows and searching earlier context instead of repeatedly compressing an entire coding session into summaries. A translated Claude Code integration should not be assumed to expose those native features.

I’d use the gateway approach when keeping CLAUDE.md, permissions, hooks, commands, and existing developer habits is itself valuable—not because translation is inherently better.

The protocol boundary is the main integration problem

Changing ANTHROPIC_BASE_URL to an arbitrary OpenAI-compatible endpoint is not enough.

The Claude Code gateway documentation lists these client-facing API families:

Gateway format	Required routes
Anthropic Messages	/v1/messages and /v1/messages/count_tokens
Amazon Bedrock	InvokeModel endpoints
Google Vertex AI	rawPredict endpoints

An OpenAI-compatible /v1/responses endpoint is not on that list. Meanwhile, OpenAI’s model guidance recommends Responses for Astra tool calling.

The resulting architecture is:

Claude Code
  → Anthropic-compatible gateway
  → Responses API
  → GPT-6 Astra

The gateway has to translate more than role names. Tool schemas, tool results, streaming events, token counting, reasoning metadata, errors, and caching behavior can all cross this boundary.

Plain text is the easy case. Streamed tool arguments, MCP tools, parallel operations, and deferred results are where I’d expect compatibility testing to earn its keep.

A unified multi-model API such as CometAPI can consolidate upstream access, but it does not remove the need for a Claude Code-compatible client-facing protocol.

What Astra brings to the experiment

The published model specification describes this profile:

Specification	GPT-6 Astra
Model ID	gpt-6-astra
Context window	1,050,000 tokens
Maximum output	128,000 tokens
Knowledge cutoff	April 30, 2026
Input / output	Text and images / text
Reasoning effort	Low, Medium, High, XHigh, Max
Streaming	Supported
Structured outputs	Supported
Function calling	Supported
Fine-tuning	Not currently supported
Standard input price	$10 / 1M tokens
Standard output price	$50 / 1M tokens

The documented tool surface includes web search, file search, code interpreter, hosted shell, Apply Patch, computer use, MCP, and tool search.

OpenAI also describes async tool calling, mid-turn steering, and changing reasoning effort during a conversation without discarding the cached prompt prefix. Those are relevant to long-running agents: external operations need not always be treated as completely blocking steps.

But model support and gateway support are different things. I would not infer that every capability in this table survives a cross-provider translation layer.

Benchmarks justify a trial, not a deployment

The published evaluation gives the following comparison:

Benchmark	GPT-6 Astra	GPT-5.6 Sol	Claude Fable 5.1
Terminal-Bench 4.0	57.9%	37.3%	55.8%
DeepSWE v1.1	74.1%	72.7%	67.4%
FrontierCode 1.1 Extended	64.5%	60.6%	63.6%
AutomationBench	41.4%	18.1%	31.4%
BenchCAD	95.9%	83.3%	84.3%
Artificial Analysis Intelligence Index	61.2	60.9	65.7
FrontierMath Tier 4	97.6%	83.0%	87.8%
Humanity’s Last Exam with tools	57.2%	—	65.0%

For a terminal-driven coding agent, Terminal-Bench is a useful signal: it covers software engineering, system configuration, and data-analysis tasks. Astra’s 57.9% is ahead of Fable’s 55.8%, but that is not a universal win. Fable remains ahead on the Intelligence Index and Humanity’s Last Exam with tools.

The retrieval figures are also relevant to repository work:

Long-context benchmark	GPT-6 Astra	GPT-5.6 Sol
MRCR v2, 8-needle, 256K–512K	100.0%	91.5%
MRCR v2, 8-needle, 512K–1M	96.3%	73.8%

A large context window only helps if the model can recover an earlier constraint, test result, or implementation decision. These numbers are a reason to evaluate Astra on large repositories—not a reason to feed every session a million tokens.

Wire up Claude Code without pretending the YAML proves compatibility

Establish a working client first

A typical npm installation is:

npm install -g @anthropic-ai/claude-code

I’d verify Claude Code works before introducing the gateway. Otherwise, authentication, client configuration, and protocol translation become one debugging problem.

Map a Claude-visible alias

Anthropic documents LiteLLM as a possible third-party gateway, while explicitly noting that Anthropic does not maintain or audit it.

A minimal model mapping can look like this:

model_list:
  - model_name: claude-astra
    litellm_params:
      model: openai/gpt-6-astra
      api_base: os.environ/ASTRA_BASE_URL
      api_key: os.environ/ASTRA_API_KEY

This is a model mapping, not a complete gateway deployment or a guarantee of Responses translation.

The claude- prefix has a purpose: Claude Code’s automatic gateway discovery only surfaces discovered model IDs beginning with claude or anthropic. Gateway discovery is documented for Claude Code v2.1.129 or later.

Before proceeding, check that the selected gateway version sends Astra’s agentic requests through Responses rather than silently turning them into an incompatible Chat Completions workflow.

Configure both sides of the connection

For the upstream service used in these examples:

export ASTRA_API_KEY="your-api-key"
export ASTRA_BASE_URL="https://api.cometapi.com/v1"

export ANTHROPIC_BASE_URL="http://localhost:4000"
export ANTHROPIC_AUTH_TOKEN="local-gateway-token"

The local gateway must be running and configured to accept that token. These exports do not start it or configure its authentication.

Once it is available:

claude

Then select the gateway model:

/model

For a manual custom-model entry instead of discovery, Anthropic also provides ANTHROPIC_CUSTOM_MODEL_OPTION for a model ID accepted by the gateway.

Test the wire before the repository

Start with an Anthropic-format request:

curl http://localhost:4000/v1/messages \
  -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-astra","max_tokens":256,"messages":[{"role":"user","content":"Reply with gateway-ok"}]}'

A successful response establishes basic connectivity. It does not establish agent compatibility.

I’d then walk through this sequence in an isolated working tree:

1. Plain text response
2. Read-only tool call
3. Repository search
4. Dry-run file patch
5. Approved file edit
6. Test command with expected output
7. Rollback or clean working tree

Include streaming and tool-result handling in the regression suite. The gateway is now part of the agent runtime, so upgrading it deserves the same scrutiny as changing the model.

Pin the gateway—and check the security advisory

The source cites Anthropic’s warning that LiteLLM PyPI versions 1.82.7 and 1.82.8 were compromised with credential-stealing malware. Do not install those versions. If either was installed, remove it and rotate affected credentials.

For current compatibility details, consult the LiteLLM documentation. Its Anthropic-compatible Messages endpoint and Responses support do not, by themselves, prove that every advanced Claude Code feature translates correctly.

My production rule would be simple: pin a known-good version, run repository-level regressions, and do not auto-upgrade the gateway.

For a chatbot, skip the translation layer

The simpler application architecture is:

Web or mobile client
  → Your backend
  → /v1/responses
  → GPT-6 Astra

The upstream service in these examples documents both /v1/chat/completions and /v1/responses. Chat Completions can be sufficient for a basic FAQ bot, but I’d start a new Astra application on Responses because that is where the documented agent-oriented workflow is centered.

Python

Install the SDK:

pip install openai

With ASTRA_API_KEY and ASTRA_BASE_URL set as above:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ASTRA_API_KEY"],
    base_url=os.environ["ASTRA_BASE_URL"],
)

response = client.responses.create(
    model="gpt-6-astra",
    input="Review this function and suggest a safer implementation.",
)

print(response.output_text)

This is an API smoke test. An actual code-review request also needs the function or relevant repository context in its input.

JavaScript

Using the OpenAI JavaScript SDK:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.ASTRA_API_KEY,
  baseURL: process.env.ASTRA_BASE_URL,
});

const response = await client.responses.create({
  model: "gpt-6-astra",
  reasoning: { effort: "medium" },
  input: "Review this pull request and identify the highest-risk change.",
});

console.log(response.output_text);

Again, supply the actual diff or retrieved context before expecting a useful review.

Reasoning effort is a migration concern

Astra documents five effort levels: low, medium, high, xhigh, and max. It does not support none.

I’d start routine conversational turns at a lower effort and evaluate high or xhigh for difficult debugging, architecture work, and changes where another reasoning pass might prevent an expensive mistake.

With the Python client above:

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "high"},
    input="Trace the root cause of this intermittent test failure.",
)

print(response.output_text)

Do not blindly carry older generation settings into the migration. The model guidance says temperature, top_p, and top_logprobs are not supported in the same way for Astra.

# Legacy settings to remove or review before migration:
legacy_settings = {
    "temperature": 0.2,
    "top_p": 0.9,
    "reasoning": {"effort": "none"},
}

# Astra-compatible Responses API request:
response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "medium"},
    input="Analyze the repository and propose a migration plan.",
)

print(response.output_text)

Check gateway defaults too. A valid application request can still fail if middleware injects legacy parameters.

Keep tool execution behind an application-owned boundary

The reason I prefer Responses for a new application is not the initial text call. It is the likely next step:

User
  → Application server
  → Responses API
  → Model tool request
  → Permission and schema validation
  → Approved tool execution
  → Responses API
  → Final answer

Order lookup, repository search, web research, and local-file access turn a chatbot into an agent quickly.

I’d keep the production responsibilities separated:

Client
  ↓ HTTPS
Application server
  ├─ Authentication and rate limits
  ├─ Conversation state
  ├─ Responses client
  ├─ Tool permission layer
  └─ Audit logs and metrics
       ↓
Approved tools and data stores

The API credential belongs on the server, not in browser code. The backend determines which operations a user is authorized to request; a model-generated tool call is not authorization.

For coding agents, that means:

• Narrowly scoped credentials and repository permissions.
• Isolated development environments.
• Review before destructive commands.
• Protected production credentials.
• Explicit approval before deployment or infrastructure changes.
• Task-specific access to MCP servers and shell tools.

OpenAI’s safety overview describes Astra as its first broadly deployed model to reach the Critical cybersecurity capability level under its Preparedness Framework. I read that as another reason to take capability boundaries seriously, not as a reason to relax them.

Route expensive work deliberately

Not every turn needs the premium model. A lightweight model can handle intent detection and routine questions while Astra handles difficult execution.

The source’s example routing heuristic is:

def choose_model(task: dict) -> str:
    requires_astra = (
        task.get("requires_computer_use", False)
        or task.get("tool_count", 0) >= 3
        or task.get("estimated_steps", 0) >= 8
        or task.get("failure_cost") == "high"
    )
    return "gpt-6-astra" if requires_astra else "gpt-5.6"

Those thresholds are a policy example, not measured optimal cutoffs. I’d tune them against completed-task cost and verify that both model IDs are available through the selected provider.

Budget for the whole agent session

The published standard Astra rates apply to inputs up to 272,000 tokens. Beyond 272K, the higher long-context tier applies to the entire request.

The source’s upstream pricing comparison is:

Pricing item	Example upstream service	OpenAI standard
Short-context input	$8 / MTok	$10 / MTok
Short-context output	$40 / MTok	$50 / MTok
Short-context cache read	$0.80 / MTok	$1 / MTok
Short-context cache write	$10 / MTok	$12.50 / MTok
Long-context input	$16 / MTok	$20 / MTok
Long-context output	$60 / MTok	$75 / MTok
Long-context cache read	$1.60 / MTok	$2 / MTok
Long-context cache write	$20 / MTok	$25 / MTok

That is a published 20% difference across the rows.

The bigger operational issue is session growth. Repository context, compiler output, test logs, and repeated tool results can push a coding session into a different pricing tier.

Token price alone is also incomplete. OpenAI reports cases where Astra achieves stronger benchmark results at a lower estimated API cost per completed task despite its higher nominal token price. I would test that claim on the actual workload rather than assume it transfers.

For comparison:

Dimension	GPT-6 Astra	GPT-5.6 Sol	Claude Fable 5.1
Context	1.05M	1.05M	1M
Maximum output	128K	128K	128K
Standard direct input	$10 / MTok	$4 / MTok	$10 / MTok
Standard direct output	$50 / MTok	$20 / MTok	$50 / MTok
Claude Code integration	Gateway required	Gateway required	Native ecosystem

Astra’s nominal input and output prices are 2.5× Sol’s. That premium needs to buy something measurable: fewer repair turns, better completion rates, less review work, or a task the cheaper model cannot reliably finish.

What I would measure before switching models

I would run the same repository tasks through each candidate and record:

• Task completion against explicit acceptance criteria.
• Retries and repair turns.
• Latency.
• Review corrections.
• Actual API cost.
• Tool and streaming failures attributable to the gateway.

That last category matters. A model can be capable while the integration is unreliable. Conversely, a clean protocol implementation cannot compensate for weak task performance.

I’d choose Astra for hard terminal work, long-context retrieval, autonomous debugging, computer use, and difficult end-to-end tasks when the measured gain justifies the price. I’d consider Sol for cost-sensitive workloads and Fable for the cleanest Claude-native path.

For an application backend, I would leave Claude Code out entirely. For an existing Claude Code team, I would treat Astra as another backend to evaluate—not a drop-in Claude replacement. The useful question is not whether the first request succeeds. It is whether the complete edit-test-review loop finishes more reliably, at an acceptable cost, with the permissions still intact.