DEV Community: amdmsz

Your Codex model shuts off July 23 — a 7-day migration map

amdmsz — Wed, 15 Jul 2026 21:19:25 +0000

I pin model IDs on purpose. Floating aliases have burned me before — a silent swap under a -latest tag once changed a tool-calling detail in production and cost me a Saturday with git bisect and a coffee I didn't enjoy. So everything I run points at a dated snapshot. gpt-5-codex was one of them.

Last week I finally read OpenAI's deprecations page top to bottom instead of skimming it, and there it was: gpt-5-codex, retiring 2026-07-23, sitting quietly next to ten of its neighbors. As I write this it's July 16. That's seven days.

If you pinned any of the snapshots below, consider this your heads-up. Here's the full retirement list, how to find out in about ten minutes whether you're exposed, the replacement map with the things I'd actually regression-test, and the one structural change that turned my last forced migration from scary into boring.

The shutdown list (retiring 2026-07-23)

Straight from OpenAI's API deprecations page. I checked each row against the source while writing this — do the same before you act on it, because dates and replacements do get revised.

Retiring model	OpenAI's suggested replacement
`gpt-5-codex`	`gpt-5.5`
`gpt-5.1-codex`	`gpt-5.5`
`gpt-5.1-codex-max`	`gpt-5.5`
`gpt-5.1-codex-mini`	`gpt-5.4-mini`
`gpt-5.2-codex`	`gpt-5.5`
`gpt-5-chat-latest`	`gpt-5.5`
`gpt-5.1-chat-latest`	`gpt-5.5`
`gpt-4o-search-preview-2025-03-11`	`gpt-5.4-mini`
`gpt-4o-mini-search-preview-2025-03-11`	`gpt-5.4-mini`
`gpt-4o-mini-tts-2025-03-20`	`gpt-4o-mini-tts-2025-12-15`
`computer-use-preview-2025-03-11`	`computer-use-preview` (or `gpt-5.4-mini`)

Note the shape of it: the *-codex line collapses into gpt-5.5 — except gpt-5.1-codex-mini, which drops to gpt-5.4-mini — the chat-latest aliases fold into gpt-5.5 too, the two *-search-preview snapshots move to gpt-5.4-mini, and the two preview families (tts, computer-use) just roll to a newer dated snapshot / the undated alias. Once you see the buckets, the migration is less intimidating than the eleven-row table looks.

Find out if you're exposed (about ten minutes)

The trap isn't the model IDs you remember hardcoding. It's the ones you forgot — buried in an .env, a config table, a feature flag, a notebook a teammate ran once. Two passes catch almost all of it.

1. Grep the code. One regex covers every retiring ID:

grep -rniE \
  'gpt-5-codex|gpt-5\.1-codex|gpt-5\.2-codex|gpt-5(\.1)?-chat-latest|gpt-4o(-mini)?-search-preview-2025-03-11|gpt-4o-mini-tts-2025-03-20|computer-use-preview-2025-03-11' \
  --include='*.py' --include='*.ts' --include='*.js' --include='*.go' \
  --include='*.rb' --include='*.java' --include='*.env*' --include='*.y*ml' \
  --include='*.json' --include='*.toml' .

2. Grep what you actually shipped. Code search misses IDs that arrive from a database, a dashboard toggle, or a user-supplied param. If you log outbound requests as JSON lines with a .model field, count what really went over the wire:

jq -r 'select(.model) | .model' requests.log \
  | sort | uniq -c | sort -rn \
  | grep -E 'codex|chat-latest|search-preview-2025-03-11|gpt-4o-mini-tts-2025-03-20|computer-use-preview-2025-03-11'

No structured logs? OpenAI's usage export / dashboard breaks spend down by model — sort by name and look for the eleven above. If a retiring ID shows up there but not in your grep, that's exactly the config-driven caller you'd have missed.

Keep the retiring set around as a constant; it's handy in a CI check that fails a build if any of these strings reappears:

RETIRING_2026_07_23 = {
    "gpt-5-codex", "gpt-5.1-codex", "gpt-5.1-codex-max", "gpt-5.1-codex-mini",
    "gpt-5.2-codex", "gpt-5-chat-latest", "gpt-5.1-chat-latest",
    "gpt-4o-search-preview-2025-03-11", "gpt-4o-mini-search-preview-2025-03-11",
    "gpt-4o-mini-tts-2025-03-20", "computer-use-preview-2025-03-11",
}

The migration map — and what I'd actually test

Swapping a string is the easy part. The replacements are not drop-in twins, so treat each bucket as a behavior change, not a rename.

*-codex → gpt-5.5. This is the biggest jump. The codex snapshots were tuned for agentic coding; gpt-5.5 is a general model. Re-run your coding evals / golden transcripts and watch reasoning depth, patch/diff formatting, and tool-call arguments. If you parse the model's output with anything stricter than "trust me," diff old vs. new on a real sample before you flip prod.
gpt-5.1-codex-mini → gpt-5.4-mini. Different family, not just a smaller codex. Latency and tool-calling shape can differ from the mini you tuned prompts against — re-check timeouts and any few-shot examples that leaned on the old behavior.
gpt-5(.1)-chat-latest → gpt-5.5. You were pinned to a moving alias, which is its own smell. Moving to a concrete model is an improvement; just confirm system-prompt adherence and output format on your top few flows.
*-search-preview-2025-03-11 → gpt-5.4-mini. These preview models had search grounding baked in. A plain gpt-5.4-mini may not ground the same way, so verify the capability you relied on still exists — and if you need live retrieval, wire up the web-search tool on the Responses API rather than assuming the base model does it for you.
gpt-4o-mini-tts-2025-03-20 → gpt-4o-mini-tts-2025-12-15. Same family, newer snapshot — lowest risk. Still, spot-check voice, prosody, and any voice/format params you pass.
computer-use-preview-2025-03-11 → computer-use-preview. Dated snapshot to undated alias. Fine, but you're now back on a moving target; pin the new dated snapshot the moment one is published if you care about reproducibility.

My minimum regression checklist before flipping any of these in production:

Run the existing eval/golden set on the replacement and diff outputs, don't eyeball one prompt.
Re-validate any parser or schema that consumes model output (tool-call JSON, code fences, function args).
Sanity-check token accounting and cost on the new model so a "quick swap" doesn't quietly reprice a hot path.
Confirm capability parity for anything special (search grounding, computer use, TTS voices) — replacements can drop or move a feature.

The next wave is already on the board (2026-12-11)

While you're in the deprecations page, scroll down. A second batch — gpt-5-2025-08-07, gpt-5-mini, gpt-5-nano, gpt-5-pro, o3, and o3-pro — is slated to retire 2026-12-11, moving to gpt-5.5 / gpt-5.4-mini / gpt-5.4-nano / gpt-5.5-pro. Not urgent this week, but if you're touching model config anyway, note it now so December isn't a second scramble.

Pull model IDs into one layer, so the next one is boring

Here's the part I keep relearning. The pain of a forced migration scales with how many places name the model. When gpt-5-codex is a literal string in nineteen files, three services, and a config table, a deprecation is a nineteen-file PR under a deadline. When the model name lives in exactly one routing/config layer, it's a one-line change and a redeploy.

So my rule now: application code never spells a model ID. It asks for a role — "code-agent", "cheap-classifier", "tts" — and a small config maps that role to the concrete snapshot. A forced migration becomes editing that map, re-running evals, shipping. The eleven models above would have been one commit.

In my own setup that routing layer is byesu, an OpenAI-compatible gateway where a single key fronts gpt-5.5/gpt-5.6 alongside Claude, Gemini, and Grok. Because it's OpenAI-compatible, the replacement models in that table are reachable by pointing my existing client at one base URL and changing the model string in one place — the SDK, request shape, and parsing code don't move. You don't need a gateway to get this benefit, to be clear; a plain constants file or a MODEL_ROLES dict buys you most of it. The point is the indirection, not the tool. But having every provider behind one compatible endpoint is what let me treat "gpt-5-codex is gone" as a config edit instead of a cross-repo hunt.

Seven days

Concretely, before July 23: run the two greps, list your exposed snapshots, pick the replacement per the table, diff outputs on real traffic, and ship. If you've got the eleven strings scattered across the codebase, this is also the cheap moment to pull them behind one role→model map — because December's batch is already scheduled, and there will always be another one after that.

Go read the source page yourself and check the dates against your own stack. Deprecation tables are the one kind of doc where "I'll get to it next sprint" has a hard cutoff.

If you pinned gpt-5-codex like I did — the clock's already running.

My "prompt caching" change made the bill go up — here's what I got wrong

amdmsz — Wed, 15 Jul 2026 02:02:56 +0000

I turned on prompt caching for an agent I run all day, watched the next invoice, and the number went up. Not by a rounding error — meaningfully up. This is the write-up of why, because the thing I got wrong is the thing almost every "just add caching" post skips.

The one-sentence version of caching

You send the same long system prompt (plus tool schemas, plus a pasted document) on every call. Without caching you pay full input price to make the model re-read that identical block every single time. Caching stores a prefix of your prompt and, on the next call, charges a fraction to read it back instead of full price.

Sounds free. It is not free. That's the trap.

The part that bit me: writes cost more

A cache entry has two prices, and I only knew about one of them:

Cache read (a hit): billed at as low as 0.1x the input rate. This is the number everyone quotes. ~90% off the cached tokens. Great.
Cache write: billed at a premium — around 1.25x the input rate on the short (5-minute) window. This is the number nobody mentions.

So the first time you send a prefix — or any time it's expired — you don't save 90%, you pay a 25% surcharge to store it. Caching only comes out ahead once that same prefix is read back, not just written. The good news: the write costs ~0.25x more than a normal read (1.25x vs 1x), and a single cache hit saves 0.9x (0.1x vs 1x) — so the very first reuse already earns the premium back, and every hit after that is ~90% off. The catch is you have to actually get the hits.

Which means the failure mode is specific and nasty: write a cache entry, then never read it. You paid extra for storage you never used. Do that on every single call and you've built a machine that pays a surcharge to cache things it immediately throws away.

That was exactly my bug.

What I actually did wrong

My "stable" system prefix wasn't stable. Buried near the top of it was this, which I'd added months earlier and forgotten:

Current session started: 2026-07-14T09:41:07Z

A timestamp. Regenerated every call. Which meant the prefix was different every call, so the provider dutifully wrote a fresh cache entry every single time — full write premium — and never once got to read one back, because no two prefixes matched. I had turned on the expensive half of caching and none of the cheap half.

The tell was right there in the response the whole time, I just wasn't looking:

print(resp.usage)
# cache_creation_input_tokens: 3948   <- writing every call
# cache_read_input_tokens: 0          <- never reading. there's your bug.

cache_creation climbing while cache_read sits at zero is the signature of a busted prefix. If you take one thing from this post: log those two fields and watch them.

The fix is discipline, not more caching

Caching rewards a prefix that is byte-for-byte identical across calls and sits before anything that changes. Two rules:

1. Static content first, dynamic content last. System prompt, tool definitions, the big pasted document — all up front and unchanging. The user's actual turn, the timestamp, the per-request ID — all at the end, after the cached region. Anything that varies must live downstream of the cache breakpoint, never inside it.

2. Keep the prefix stone-cold identical. No timestamps, no reordered JSON keys, no "helpful" per-request injection into the system block. One moving character and the whole prefix misses.

For Claude, you mark where the stable prefix ends with a breakpoint:

resp = client.messages.create(
    model="claude-opus-4-8",
    system=[{
        "type": "text",
        "text": LONG_STABLE_INSTRUCTIONS,        # no timestamps in here!
        "cache_control": {"type": "ephemeral"},  # cache everything up to this point
    }],
    messages=[{"role": "user", "content": todays_question}],  # the only thing that varies
    max_tokens=1024,
)

For OpenAI-family models it's automatic above ~1024 tokens — same discipline, no breakpoint: keep the static stuff at the front and let it match the longest common prefix. One update worth knowing (edited July 15): the billing changed with GPT-5.6. On GPT-5.5 and earlier there's no write premium and a shallower read discount — caching is pure, smaller upside. From GPT-5.6 onward OpenAI moved to the Anthropic-style structure: 1.25x cache writes, 90% off cache reads, plus explicit cache breakpoints and a 30-minute minimum cache life. Which means the timestamp trap in this post now bites on OpenAI too. You'll see it land in prompt_tokens_details.cached_tokens.

I moved the timestamp to the user message, left the system block untouched between calls, and re-ran. cache_read_input_tokens lit up on the second call and the bill for that agent dropped hard — because it loops twenty-plus times over the same head, and now that head is written once and read twenty times instead of written twenty times and read never.

Where caching actually pays (and where it doesn't)

It's amortization, not magic. It wins when a big, identical prefix is read many times:

Agent / tool loops — every step resends the same system prompt and tool schemas. Ideal.
Long-doc Q&A — paste the document once, ask ten questions against it.
Bulk extraction — fat instruction + few-shot block, only the input row changes.

It does nothing for one-shot calls where the whole prompt is different every time — there's no repeated prefix to amortize against. On Claude (and GPT-5.6+, which shares the 1.25x write structure), explicitly caching there just burns the write premium for no return; on GPT-5.5 and earlier the attempt is free, but it won't help either. Match the tool to the workload.

One gateway gotcha, since I run through one

I don't call the providers directly — I route through a gateway (I use byesu, pay-as-you-go across Claude/GPT/Grok on one key). That adds a failure mode worth naming: some aggregators quietly break caching. If a proxy reorders your fields or strips cache_control or injects a per-request header into the prompt body, the prefix stops matching — and you get an answer with zero cache hits and no error telling you. You just silently pay full price.

So test it on your gateway specifically: send the same request twice and confirm cache_read_input_tokens is non-zero on the second. On the one I use, cache_control and the usage fields pass through to the official upstream unchanged, so the cache key I build is the one that actually gets used and the 0.1x reads show up — but "does my proxy preserve caching" is a question you should answer with the usage object, not take on faith from anyone, me included.

The whole lesson in three lines

Caching has a write premium (~1.25x); reads are cheap (0.1x). It's amortization — you need repeat reads.
The prefix must be byte-stable and up front. A timestamp in your system prompt will quietly cost you money.
Watch cache_read_input_tokens. Zero on a repeat call means it's not working, whatever the marketing said.

If you want the reference version — the breakpoint rules, the OpenAI side, the exact usage fields per provider — I wrote it up over here. But the timestamp story above is really the whole lesson.

GPT-5.6 Sol vs Terra vs Luna: which tier should you actually use?

amdmsz — Sat, 11 Jul 2026 22:01:53 +0000

When GPT-5.6 landed as three models instead of one, my first reaction was mild annoyance. Sol, Terra, Luna — great names, zero help when I'm staring at a config file deciding which string to paste into model. So I did the boring thing: I wired all three into the same app, ran a week of real traffic through them, watched the token meter, and wrote down what I learned. This is that write-up — the decision tree I wish someone had handed me on day one.

The 30-second version

Three tiers, same API shape, same features. The only thing that changes is depth vs. cost vs. latency. Official OpenAI list prices, per million tokens:

Tier	Model string	List price (in / out)	My one-liner
Sol	`gpt-5.6-sol`	$5 / $30	The flagship. Reach for it when a wrong answer is expensive.
Terra	`gpt-5.6-terra`	$2.50 / $15	The default that surprised me.
Luna	`gpt-5.6-luna`	$1 / $6	The volume workhorse.

Note the shape of that output column: $30, $15, $6. Output tokens are where the money goes, and they scale 5:1 against input across all three. Keep that ratio in your head — it makes tier choice mostly a question of how much the model talks, not how much you feed it.

Terra is the plot twist

I expected to run Sol everywhere and grumble about the bill. Then I A/B'd Sol against Terra on my actual coding-assistant traffic — diffs, refactors, "why is this test flaky" spelunking. OpenAI's own line is that Terra hits about 97% of Sol's benchmark performance, and honestly? On day-to-day dev work I couldn't feel the missing 3%. Same fixes, same explanations, half the list price.

That reframed the whole exercise for me. The question stopped being "can I afford Sol?" and became "do I have a specific reason to escalate off Terra?" For most requests the answer is no. Terra became my baseline and Sol became the exception I reach for deliberately — not the reverse.

Where Sol still earns its keep for me: genuinely hard reasoning where the cost of being wrong dwarfs the token bill. Architecture reviews, gnarly migrations, research synthesis across a big pile of context. And ultra mode — the 5.6 family can orchestrate parallel sub-agents on complex tasks, and that coordination is exactly the kind of work where the deepest tier pays for itself.

Luna is not a downgrade, it's a different job

Luna is the one people mis-read. It's not "watered-down Sol," it's the tier you point at work where per-token cost dominates and the quality ceiling basically never binds: bulk classification, tagging, extraction, summarizing a firehose of records. When you're doing the same small operation ten thousand times, a dollar of input vs. five dollars of input is the entire P&L. Luna is also the fastest of the three, so it's my pick for anything latency-sensitive — autocomplete, a streaming chat UI — paired with stream: true.

The cache math nobody puts on the slide

Here's the part that actually changed my routing, and it's the reason I'd tell you not to just default to the smallest tier.

GPT-5.6 ships with predictable caching: a prompt prefix is guaranteed to stay cached for at least 30 minutes, and you can drop your own cache breakpoints. Cache reads bill at 10% of the input price. That number quietly rewrites the arithmetic for any prefix-heavy workload.

Think about a RAG setup where every request re-sends the same fat corpus prefix. Without caching you pay full input rate on that prefix every single call. Pin it behind a breakpoint and you pay full rate once per 30-minute window, then 10% on every hit after. Run the numbers on a realistic prefix-to-suffix ratio and Terra-with-cache can land below Luna-uncached on effective per-request cost — while giving you Terra-grade answers. I stopped reaching for the smallest tier reflexively and started modeling the prefix ratio first. Sometimes the "more expensive" tier is the lower-cost system.

My actual routing rules

After all that, here's the decision tree I run in production:

Deep reasoning / high-stakes (architecture, tricky migrations, ultra-mode agent pipelines) → Sol. Output quality wins when a mistake is expensive.
Everyday work (coding assistant, general chat, most product features) → Terra. ~97% of Sol at half the list price; escalate specific request types to Sol only when your evals show the gap is real.
High-frequency / bulk (classification, extraction, summarization, latency-critical UX) → Luna, with stream on where it helps.

The meta-rule: start on Terra, promote to Sol by request-type when evals justify it, route the bulk lane to Luna. Match the workload, not the badge.

Trying all three behind one key (no OpenAI account)

The nice part is that testing this costs almost nothing in effort. I ran all three tiers through byesu — an AI API gateway that speaks the OpenAI-compatible Chat Completions API (and an Anthropic-native /v1/messages endpoint from the same host, same token). One sk- key covers all three GPT-5.6 tiers, so comparing them is a one-string change in a loop, and billing is pay-as-you-go per token — no subscription, no separate OpenAI account to provision.

If you already have OpenAI SDK code, it's a base_url swap:

from openai import OpenAI

client = OpenAI(
    api_key="sk-YOUR_TOKEN",
    base_url="https://byesu.com/v1",
)

prompt = "Refactor this function and explain the trade-offs."

for tier in ("gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna"):
    r = client.chat.completions.create(
        model=tier,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    print(f"{tier:16} in={u.prompt_tokens:5}  out={u.completion_tokens:5}")
    print(r.choices[0].message.content[:200], "\n")

Log usage on every call — that in/out split is the whole game. Once you can see input vs. output tokens per tier on your prompts, the pricing table above stops being abstract and the right tier basically picks itself.

One gotcha worth flagging: when you create the token, put it in the OpenAI GPT group. Wrong group is the usual cause of a "no available channel" error, and the model string has to be exactly gpt-5.6-sol / -terra / -luna.

Bottom line

Default to Terra. Escalate to Sol for the handful of requests where being right is worth $30-per-million output. Push bulk and latency-sensitive lanes to Luna. And before you assume the smallest tier is the lowest-cost one, do the cache math — predictable caching plus 10% reads can flip the ranking entirely. Wire all three behind one key, log your token usage, and let your own traffic settle the argument.

I ran Claude Code on Grok 4.5 — here's the 3-line setup

amdmsz — Sat, 11 Jul 2026 21:27:11 +0000

I've basically lived inside Claude Code for the last few months. Opus 4.8 is my daily driver and I'm not looking to leave it. But when xAI dropped Grok 4.5 on July 8, two things nagged at me enough that I wanted it in the exact same terminal I already had open.

This is the write-up of that afternoon — what pulled me in, the three lines that actually did the job, and where I landed on Grok vs Opus after living with both for a week.

Why I even bothered

Two reasons, and neither of them is "it's the smartest model in the world," because it isn't.

One: it's built for coding. Grok 4.5 is the first xAI model explicitly aimed at coding and agentic work — xAI says it was trained on real developer sessions from Cursor, so the pitch is "long stretches of work inside an actual repo," which is exactly what Claude Code does all day.

Two: the token efficiency number stuck with me. In the third-party write-ups going around, Grok 4.5 finished the same agentic indexing task in roughly 14k output tokens where a frontier flagship burned closer to 67k. When you run an agent that loops and re-reads files for twenty minutes, output tokens are the bill. A model that says the same thing in a quarter of the tokens is interesting even before you look at the per-token rate.

Official rate, for the record: xAI lists Grok 4.5 at $2 / $6 per million input/output, and claims it comes in 60%+ under the current flagship tier. Fewer tokens and a lower rate stacks. That was enough to make me curious.

The thing I kept forgetting

Here's the part that took me embarrassingly long to internalize: Claude Code doesn't actually care what model is on the other end. It's a CLI that speaks Anthropic's /v1/messages protocol to whatever ANTHROPIC_BASE_URL points at. If something answers in that shape, Claude Code will happily drive it.

So I didn't need a Grok-specific client. I needed an endpoint that (a) speaks Anthropic-native and (b) has grok-4.5 sitting behind it. I already had an account on byesu, an API gateway that exposes both an OpenAI-compatible and an Anthropic-native endpoint over a pile of models — pay-as-you-go, and Grok 4.5 was already listed. That's the whole trick: the gateway translates, Claude Code never knows the difference.

The three lines

That's it. Literally three environment variables:

export ANTHROPIC_BASE_URL=https://byesu.com
export ANTHROPIC_API_KEY=sk-your-own-key
export ANTHROPIC_MODEL=grok-4.5

Then, in any project directory:

claude

ANTHROPIC_MODEL=grok-4.5 is the line doing the interesting work — it pins every request to Grok instead of the default Claude model, so you don't have to remember to switch each session. If you'd rather flip between models mid-session, drop that third line and use /model inside the REPL instead.

Two gotchas so you skip my afternoon

No /v1 on the base URL. The Anthropic-native endpoint is the bare root — https://byesu.com, not https://byesu.com/v1. I pasted in a /v1 out of muscle memory from OpenAI-style setups and got a wall of connection errors. Strip it.

If auth won't take, swap the key variable. On one machine my first call kept bouncing on auth. The fix was replacing ANTHROPIC_API_KEY with ANTHROPIC_AUTH_TOKEN (same value) — some Claude Code versions prefer one over the other. Thirty seconds once you know; a genuinely confusing ten minutes if you don't.

Sanity check before you trust it: run claude, ask it something trivial, and confirm the model line in the status bar reads grok-4.5. If it still says a Claude model, your ANTHROPIC_MODEL export didn't make it into that shell — re-source it or reopen the terminal.

The one-line vibe check

It's fast, and it's terse in a way I ended up liking. Grok 4.5 doesn't pad. It reads the files, makes the edit, and moves on with noticeably less "let me explain my reasoning at length" preamble — which, combined with the token-efficiency thing, means the agent loop just feels tighter. For mechanical work — wiring up a route, refactoring a module, chasing a stack trace across a few files — it kept pace with what I'd normally reach for.

Where I actually landed: Grok vs Opus 4.8

I'm not going to tell you Grok 4.5 replaces Opus 4.8, because after a week it clearly doesn't — for me they split by task, not by "better/worse."

Opus 4.8 is still where I go for the gnarly stuff: ambiguous architecture calls, "read this whole subsystem and tell me what's actually wrong," the reasoning-heavy work where I want the model to sit and think. It's the frontier flagship and it feels like it.

Grok 4.5 is where I go for volume. The high-frequency, well-specified, mechanical passes where I know roughly what needs to happen and I just want it done in fewer tokens and fewer words. On independent coding benchmarks it lands in the same neighborhood as the top-tier models at a fraction of the per-task cost, and Artificial Analysis had it at #4 on their intelligence index at launch — which is a lot of "good enough" for the kind of work that eats most of my day.

So it's complementary, not a swap. The nice part of the gateway setup is I don't have to commit: same three env vars, change the model line (or /model), and I'm on whichever one fits the task. Opus for the thinking, Grok for the grinding.

If you want the reference version of the setup — supported models, endpoints, the OpenAI-compatible side — it's documented over at docs.byesu.com. But honestly, the three lines above are the whole story. Export, claude, go.