codexkey currently serves four Opus revisions: 5, 4.8, 4.7 and 4.6. Model choice usually starts with price, but that argument falls away here, because the price is identical across all four. What remains is behavior and stability, and the bill has no say in it.
All four revisions in one table
| Model | Input, $/1M | Output, $/1M | Role in the lineup |
|---|---|---|---|
claude-opus-5 | 0.3 | 0.3 | flagship, default for hard tasks |
claude-opus-4.8 | 0.3 | 0.3 | fallback target for 5, solid workhorse |
claude-opus-4.7 | 0.3 | 0.3 | earlier revision, for pinning |
claude-opus-4.6 | 0.3 | 0.3 | earlier revision, for pinning |
For context, Anthropic's own list price for Opus 5 is $5 per million input tokens and $25 per million output tokens. Through codexkey all four Opus revisions run at $0.3 and $0.3, whichever one you call.
If the price is the same, what do you choose by
If price rose with the revision number, picking one would be a trade between quality and budget. There is no such axis here, so the decision comes down to three questions: do you need the flagship's speed and new capabilities, do you need the predictability of behavior you have already tuned around, or do you need a frozen version that can be reproduced for evals and audits.
When to take the newest one
Opus 5 shipped two clear improvements. It answers noticeably faster on long agentic runs, and it can change its tool set in the middle of a conversation without starting the session over. There is also a built-in fallback to 4.8: if the safety classifier flags a request, the fallback kicks in even when you call 5 directly. You get that safety net without extra code.
For new projects, default to 5 unless you have a reason to hold on to a specific older revision.
When stability matters more than novelty
- Production is already tuned to a specific revision. Prompts, few-shot examples and response parsing are all calibrated to a model's behavior. Swapping revisions without tests carries a regression risk that you get for free and without warning.
- You have a frozen eval dataset. Pinning fixes the baseline for comparison over time. If a pass rate has to be comparable month over month, the model under the hood cannot change.
- You need documented reproducibility. In audits and regulated processes it sometimes matters to know exactly which model version handled a given request.
In these cases 4.8, 4.7 and 4.6 work as well as they did before, and there is no price penalty for not being the flagship.
How to switch revisions in code
One line changes, model, and the rest of the code stays as it is:
from openai import OpenAI
client = OpenAI(api_key="sk_cdx_...", base_url="https://api.codexkey.online/v1")
for model in ["claude-opus-5", "claude-opus-4.8", "claude-opus-4.7", "claude-opus-4.6"]:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": "Draft a migration plan for the service"}],
)
print(model, "->", resp.choices[0].message.content[:80])
The most honest way to see the difference in behavior on your own task, rather than from someone else's description, is to run the same case through all four revisions.
A practical way to choose
- A new project with no legacy constraints: take
claude-opus-5. - Production is tuned and working: keep the current revision until you have a reason to migrate.
- You are comparing before a migration: keep production on the older revision and run your eval dataset against the new one in parallel.
- You need a documented version for audit purposes: pin to a specific id and set up a recurring check on that revision's status with Anthropic.
There is no need to work out the price difference between the options, because there is none. Spend per key and per model shows up in the dashboard, and the calculator on the site estimates a bill for your own token volume.
In short
All four Opus revisions cost the same at codexkey: $0.3 on input and $0.3 on output per million tokens. Opus 5 is faster and can swap tools mid-conversation, 4.8 serves as the fallback and the workhorse, and 4.6 and 4.7 stay for teams that need reproducibility. Pick by task, not by bill: the bill does not move here.