Why is there no GPT 5.5?

Awesome, bedankt 🙏🏻

I manually added it and got it working.

Two reasons, both boring:

GPT-5.5 is out from OpenAI, but it's not in Paperclip's codexlocal model list yet. It's on the to-do list — the curated dropdown in packages/adapters/codex-local/src/index.ts (models[]) hasn't been updated for the 5.5 release. The current list ships gpt-5.4, gpt-5.3-codex (default), gpt-5.3-codex-spark, gpt-5, plus the o3/o4-mini/gpt-5-mini/gpt-5-nano/o3-mini/codex-mini-latest family. You don't have to wait for the dropdown. The adapter's isCodexLocalManualModel() check accepts any string not in models[] and passes it straight through to codex exec. So you can type gpt-5.5 directly into the model field on your agent and it'll route to OpenAI's GPT-5.5 today — no Paperclip release required. Same trick is how people ran gpt-5.4 in fastMode before the dropdown caught up.

The dropdown update will land in a future release; in the meantime, the manual entry is the supported way to use it.

@zicofernandes Good question, and the honest answer is the more reassuring one: Paperclip is much closer to bare metal on models than something like Copilot.

The reason Copilot lags on new models is that it owns the whole inference path — its own system prompts, its own tool-calling scaffolding, its own evals — so every new model means re-tuning and re-testing that scaffolding before it's safe to ship. Paperclip deliberately doesn't sit in that path. For the local adapters (claudelocal, codexlocal, geminilocal, …), Paperclip shells out to the vendor's own CLI — Claude Code, codex exec, the Gemini CLI — and lets that tool own the prompting, tool use, and agentic loop. Paperclip orchestrates around the runtime (issues, heartbeats, delegation, budgets), not inside the model.

That's exactly why, as I mentioned above, you don't have to wait for us to "support" GPT-5.5: the codexlocal adapter passes any unlisted model string straight through to codex exec. The curated dropdown is a convenience list, not a capability gate. So the only "work" a new model creates on our side is cosmetic — adding a label to that dropdown so it shows up without manual typing. There's no per-model system-prompt rewrite, no human-review eval gauntlet that has to clear before a model is usable. If the underlying CLI can run it, your agent can run it today.

Two honest caveats so it's not all rainbows:

Quality still varies by model, and that evaluation falls to you, the operator, per role — which is the right place for it. A cheaper/weaker model on your CEO or a copywriter will produce worse outputs even though it "works" mechanically. We don't pre-bless models for you; you A/B them for your own work. For high-judgment roles it's worth actually testing before switching. The vendor CLI is the dependency. A brand-new model is usable the moment the underlying CLI (and the provider's API) recognizes it. If codex / the Gemini CLI hasn't caught up to a release, that's the gating factor, not Paperclip.

So: appreciate the curiosity, and the short version is that "products like these" don't all carry the same per-model tax — Paperclip's design specifically pushes that cost out to the runtime so model availability isn't bottlenecked on us.

Aron, curious if there there is a lot of evaluations that you need to do that required humans to review for every new model, I am asking as a curios beginner to have a better understanding and appreciation for products like like these..

Like Co-pilot has a delay in adding models .. I am sure there is a lot of testing and fixing of the codex system prompt that needs to go there for every model.

Do you see such complexity with Paperclip or is paperclip more bare metal when it comes to models.