DEV Community: Yanng

How I keep faces the same when editing photos with Nano Banana and GPT Image

Yanng — Tue, 03 Nov 2026 13:30:00 +0000

The most common complaint about AI photo editing is not quality. It's "that's not me anymore". You ask for a different jacket and get a different person wearing it.

I build AI Photo Edit, an AI photo editor where you upload a photo and type one sentence, like "dress him in a navy suit". It runs on two image models, Nano Banana 2.1 (Google) and GPT Image 2.5 (OpenAI). Both follow instructions well. Neither knows that for my users the face is the one thing that must not change.

What fixed it was not a model or a face-swap step. It was one paragraph appended to every prompt, plus a check for edits that need more than one photo. Here is how that paragraph is built, the version that broke, and the edits that still don't work.

TL;DR Put a short paragraph of rules after the user's instruction. Protect identity, not appearance, and give every rule a way out for when the user asks for exactly what it protects. Then test it on the edits it might block. A copyable template and an eight-edit test list are below.

Users write the change, the server writes the rules

Users only type what they want changed. They never see the protective wording. The server adds it before the request goes to the model:

// The user's sentence first, our rules after it.
export function editPrompt(userPrompt: string): string {
  return `${userPrompt.trim()}\n\n${RULES}`;
}

RULES is a short paragraph. I'm not going to paste our production wording, because it took a lot of test runs to get right, but each of its sentences has one job:

Apply the change above, and only that change.
Keep every person recognizable as themselves.
Leave everything the instruction doesn't mention where it was.
Say what happens when the user asks for a new art style.
Keep the original light and color unless the user asks otherwise.

Here is a version you can copy. It is not our production text, and I haven't run it through my test set, so treat it as a starting point:

Edit request: {what the user typed}

Rules for this edit:
- Change only what the edit request asks for. People, objects, framing
  and background stay as they are.
- Every person stays recognizable: same face shape, eyes, nose, mouth,
  skin tone and age. Their expression changes only if the request asks.
- If the request asks for an art style (painting, cartoon, sketch),
  apply it to the whole image and keep each person recognizable in it.
- Keep the original lighting, colors and camera look unless the request
  changes them.
- Do not add text, watermarks or extra people.

If you try it, test "make him laugh" and "turn it into a watercolor painting" first. Those are the two edits that broke my first version, as the next section shows. The full test list is near the end. I'd like to know in the comments what you get.

The same function feeds every provider. Nano Banana takes the result as prompt with the photos in image_input, and GPT Image gets the same text with input_urls. Only the body shape changes. The rules are always in English, whatever language the interface is in, so both models get the same instruction.

The user's sentence goes first. The rules come after it and point back to it, so the request stays the main instruction and the rules only limit everything around it.

Version one was too strict

My first paragraph tried to protect everything: the face, the expression, the hair, the pose and the "photographic look". On normal edits it worked. Then I ran my test list, and two edits came back almost unchanged:

"Make him laugh": the expression rule won, so he kept the same polite smile.
"Turn the photo into a watercolor painting": the "keep the photographic look" rule won, so it stayed a photo.

The models weren't failing. They were obeying the rules I gave them over the user's request.

The fix was to protect identity, not appearance. Asking for the same recognizable person still allows a laugh, a beard or a painted version of the same man. Asking for the same expression and the same look does not. Then each rule that could block an edit got an explicit way out:

art style: if the user asks for a new style, the whole image changes style, not just part of it.
lighting and color: kept, unless the user asks to change them.

Every protective rule needs to know what happens when the user asks for exactly the thing it protects. If it doesn't say, the model guesses, and it usually picks the rule.

What it does on one photo

Every edit below starts from the same original. They are not chained, and they are not retouched. The portrait is a test image I generated, not a customer photo.

Instruction	Result
Dress him in a navy suit with a white shirt and a dark tie
Put him in a snowy mountain village in winter, wearing a warm puffer jacket
Give him a full beard and longer, swept-back hair
Turn the photo into a watercolor painting

The watercolor shows the style rule working. The whole frame changes style, and the café, the cup, the people in the background and the man himself all stay where they were.

Tested on both models

Before launch I ran the same instructions through both models with this exact prompt setup, at 2K, keeping the original aspect ratio:

Instruction	Nano Banana 2.1	GPT Image 2.5
New outfit, new background, add an accessory, remove tourists, overcast to sunset, change text on a sign	Works; nothing else moves	Works
Watercolor painting	Works (after the fix above)	Barely changes
Make him laugh	Works (after the fix above)	Works
Time per edit, upload included	about 30–50 s	about 50–70 s

A few things I learned from that run and the ones after it:

GPT Image is weak at full style changes. It edits content well but resists turning a photo into a painting. For a painting, use Nano Banana.
Some instructions barely change anything on either model. "1970s film look" and "make it daytime" on an indoor restaurant photo came back nearly identical to the original. I took them out of the suggested prompts rather than promising something the models don't do.
Each model wins on different photos. When I asked both to make AI-looking images more realistic, Nano Banana gave better skin on portraits (pores, fine lines, natural shine), and GPT Image was clearly better on products and interiors (glass, color, walls). So users can switch models per edit.
Provider timeouts happen. I hit four "generate task timeout" errors in about fifteen Nano Banana runs on one provider. A failed edit is now retried once on a second provider, and if that fails too, the credits go back automatically.

Edits that need a second photo

Some edits reference another image: "put the jacket from the second photo on him". If the user hasn't uploaded that second photo yet, the model doesn't ask. It invents a jacket.

So the editor reads the instruction before sending it and counts how many photos it refers to:

const ORDER: Record<string, number> = {
  second: 2, '2nd': 2, other: 2, another: 2,
  third: 3, '3rd': 3, fourth: 4, '4th': 4,
};
const PHOTO = '(?:photo|picture|image|pic|shot)s?';
const mention = new RegExp(
  `\\b(${Object.keys(ORDER).join('|')})\\s+${PHOTO}\\b`,
  'gi'
);

export function photosInPrompt(prompt: string): number {
  let count = 1;
  for (const match of prompt.matchAll(mention)) {
    count = Math.max(count, ORDER[match[1].toLowerCase()] ?? 1);
  }
  return count;
}

The real version also catches "both photos" and "these three pictures". If the instruction needs two photos and only one is uploaded, the button waits and asks for the other one, and nothing is charged.

With both photos in place, the same paragraph keeps the person intact while the jacket comes from the reference:

Person	Jacket	Result

The same flow, with up to four photos, is what the AI image combiner page does.

A test list for your own prompt

These are the eight kinds of edits in my test list. Use one portrait for every edit that involves a person, so a changed face is easy to spot.

Kind	Example instruction	What a failure looks like
Outfit	Dress him in a navy suit with a white shirt and a dark tie	The face or body changes along with the clothes
Background	Put him in a snowy mountain village in winter	The person is redrawn instead of placed in the new scene
Add something	Give the dog a red scarf and a ball	The dog's breed, color or pose changes
Remove something	Remove all the people in the background and keep the man in the green jacket	The man who stays is changed too, or smudges are left behind
Style	Turn the photo into a watercolor painting	It stays a photo, or only part of the frame changes
Light	Replace the grey sky with a dramatic orange sunset	The sky changes but the light on the scene doesn't
Text	Remove all the writing from the chalkboard sign	Other parts of the photo get cleaned up too
Expression	Make him laugh	The same smile as before (rules too strict) or a different person (rules too loose)

The style and expression rows matter most: they show whether your rules are too strict or too loose. The other six check that the rules keep the rest of the photo in place.

Takeaways

Put the user's instruction first and your rules after it, pointing back to it.
Protect identity (the same recognizable person), not appearance. Expression, hair and style are things people want to change.
Give every protective rule an exit for when the user asks for exactly what it protects.
Test the edits your rules might block (a laugh, a painting), not only the ones they're meant to protect.
Check whether an instruction refers to photos that aren't there before you call the model.
Drop the prompts a model can't do from your suggestions, instead of letting users find out.

If you're building something similar, I'd like to hear how you handle identity: prompt only, like this, or a face-similarity check after generation? And if you ran the template above, which edits did it break? I haven't added a similarity check yet, because in about twenty test edits neither model quietly returned the photo unchanged. That may change as real traffic grows.

Open-source Jev alternatives: System One models you can self-host

Yanng — Fri, 25 Sep 2026 12:55:18 +0000

TypeSafe Jev is the hosted model that introduced System One models on September 15, 2026: you send a state and typed questions, and it returns answers with probabilities instead of generated text. It is generally available and billed per token: $0.042 per million input tokens, with output tokens free.

Within days, open-source Jev alternatives appeared that do the same job on your own hardware. This post lists the ones worth testing, which of them accept Jev API requests unchanged, and what it takes to self-host one.

Why look for a Jev alternative?

Data stays in your infrastructure. Tickets, emails and user messages never leave your servers.
Cost at volume. A self-hosted model costs the same whether you make ten decisions or ten million.
No vendor dependency. Open weights keep working if a hosted API changes its pricing, limits or terms.
Fine-tuning. You can train an open model on your own labelled decisions. Jev's weights are not public.
Offline and edge use. Some models run on a laptop CPU or an Apple Silicon Mac.

Best Jev alternatives to try first

If you already call Jev, start with a model that serves the same POST /v1/systemone endpoint, so existing client code only needs a new base URL:

Model	Size	License	Serves the Jev API	Good first choice when
Laya	322M / 421M	Apache 2.0	Yes, through laya-serve	You want a small model that runs on CPU, or 100+ languages
Kev	0.8B to 27B	Apache 2.0	Yes, the TypeSafe SDK works unchanged	You have a GPU and want the closest drop-in
Decider	2B / 4B / 35B MoE	Apache 2.0	Yes	You serve with vLLM and want many-option choices
Von	395M	Apache 2.0	Yes	You need low latency on modest hardware
OpenThai-SystemOne	0.8B	Apache 2.0	Yes	Your input is Thai

Other open options use their own APIs: Bespoke Nimble (9B), GLiNER2.5-Decide (340M), Together AI's Tev1-4B, and the training-free AnyJev and SemIf. See the full System One model comparison for all twelve.

Jev-compatible API servers

These projects put a Jev-style HTTP API in front of an open model, so you can switch models later without touching client code:

Server	Language	Notes
laya-serve	Python	Ships with the upstream Laya package. See Self-host Laya.
Arbiter	Python	Routing, batching, metrics and a built-in playground
sys1	Rust	candle-based, token batching, CPU, CUDA and Metal
ollaya	Rust	Ollama-style CLI and daemon; pulls models by name
laya-server	TypeScript	Docker image with a web console and API keys

For the two Rust servers side by side, see Run Laya in Rust.

How to switch from Jev to a self-hosted model

Pick a model from the table above and start its server locally.
Point your client at it. With the TypeSafe SDK, change the base URL; ollaya, for example, documents TYPESAFE_BASE_URL=http://localhost:11435. With plain HTTP, the request body stays the same:

curl -X POST http://localhost:8080/v1/systemone \
  -H 'Content-Type: application/json' \
  -d '{"state":{"message":"I was charged twice"},"questions":{"refund":{"type":"noul","instructions":"Does the customer ask for a refund?"}}}'

Compare on your own data. Send the same labelled requests to Jev and to the new model, and compare accuracy and latency before moving production traffic.
Recalibrate thresholds. Probabilities from different models are not interchangeable. If you automate a decision above a confidence cut-off, set that cut-off again on held-out data.

Jev vs open alternatives: what you give up

Hosted Jev still leads out of the box on several published comparisons, especially on tasks with many labels. On Banking77, with 77 intents, upstream Laya reports 0.425 at default settings against Jev's 0.870. Open models close much of the gap after fine-tuning on your own data, and they win on cost, privacy and latency when you run them close to your application. See Laya vs Jev for the details and caveats.

Benchmarks in this space are young and mostly self-reported on different datasets, so treat any single number as a starting point, not a verdict.

FAQ

Is there an open-source version of Jev?

No. Jev's weights are not public. The Jev alternatives above are independent open models, mostly Apache 2.0, that answer the same kind of typed questions. Several of them also accept the same POST /v1/systemone requests.

Which Jev alternative runs on a CPU?

The encoder models are the lightest: Laya (322M and 421M parameters), Von (395M) and GLiNER2.5-Decide (340M). See Laya on CPU for measured latency.

Can I keep using the TypeSafe SDK?

Yes, with a server that speaks the Jev API. Kev and ollaya say the SDK works unchanged, and laya-serve says an existing Jev client only needs a new base URL.

System One models compared: all twelve models side by side
Laya vs Jev: open weights, speed, accuracy and tradeoffs
Self-host Laya: run a Jev-compatible API yourself
Laya on CPU: latency and sizing without a GPU

Last verified: September 25, 2026.

I maintain laya-ai.com, an independent Laya resource site; this article first appeared there as Jev alternatives. The site also keeps an auto-updated list of System One models on GitHub. It was drafted with AI assistance, and every fact was checked against the project pages linked above.

How fast is Laya on a CPU? Reading the 4-core server benchmarks

Yanng — Fri, 25 Sep 2026 08:56:57 +0000

Can you run Laya without a GPU? Yes, and the upstream project now publishes enough CPU measurements to say how fast, what it costs per question, and which settings matter. This guide reads those numbers so you can size a CPU deployment before you buy hardware.

All figures below come from the upstream Laya BENCHMARKS.md. Each is tied to the hardware and setup it was measured on.

The short answer

On a 4-core server CPU, laya-multilingual answers one question in about 193 ms; the English and typed-decisions checkpoints take about 580 ms.
On CPU, cost grows almost linearly with the number of questions. Batching questions into one call saves little, unlike on a GPU.
Thread settings can matter more than the model. On one laptop, fixing torch's thread defaults made calls about 12x faster.
Cold loads take seconds, and several loaded checkpoints can use around 9 GiB of RAM, so preload what you serve.

The server CPU numbers

Measured in-process on an AWS m7a.xlarge (AMD EPYC 9R14, 4 physical cores, no SMT, 16 GiB RAM), Laya v0.3.20, fp32, OMP_NUM_THREADS=4. Each call alternates a 3-option choice and a noul question. Values are p50; p95 was within 2% of p50 on every row.

checkpoint	1 question	5	10	50	cold load
`laya` (English)	580 ms	3,072 ms	6,244 ms	35,969 ms	4.4 s
`laya-multilingual`	193 ms	912 ms	1,842 ms	11,157 ms	2.5 s
`laya-typed-decisions`	584 ms	2,819 ms	6,031 ms	35,653 ms	0.5 s

Two things stand out.

The multilingual checkpoint is about 3x faster on CPU. It is built on mmBERT-base (322M parameters) rather than ModernBERT-large (421M). The upstream write-up does not break down where the rest of the gap comes from, so treat 3x as a measured result on this machine, not a rule.

The p95 is almost the same as the p50. On an otherwise idle server, CPU latency was very predictable. In our reading, that makes capacity planning simpler than on a shared GPU.

Why batching does not help on CPU

Up to 10 questions per call, each extra question costs about 600 ms on the English and typed-decisions checkpoints and about 185 ms on multilingual. At 50 questions the cost per question rises by another 15 to 20%. In other words, ten questions in one call take roughly as long as ten separate calls.

GPUs behave differently:

hardware	1 question	50 questions	cost per extra question
Tesla T4, `laya`	39.5 ms	771.3 ms	about 15 ms
NVIDIA GB10, `laya-typed-decisions` (over HTTP)	100.2 ms	443.1 ms	about 7 ms
EPYC 4-core CPU, `laya`	580 ms	35,969 ms	about 600 ms up to 10 questions, more beyond

On the GB10, roughly 93 ms of every call is fixed overhead, so packing questions into one call is where the speedup is. On CPU there is almost no fixed overhead to amortize, so the design choice is simpler: ask only the questions you need.

Thread settings: the easiest 12x

The upstream project also reports a laptop measurement (Ryzen 9 6900HX, WSL2) that is worth copying before anything else. With torch's default thread settings on a busy host (10 intra-op and 5 inter-op threads on 10 vCPUs), a three-question call over HTTP took 9,396 ms at p50. Setting two lines brought it to 783 ms, about 12x faster with no code change:

import torch

torch.set_num_threads(8)          # about the number of physical cores
torch.set_num_interop_threads(1)  # one forward pass per call: nothing to overlap

On the same laptop, one question in-process took 910 ms with 1 thread, 374 ms with 4, 329 ms with 8, and got worse again at 388 ms when every vCPU was used. The upstream advice is to use the physical core count plus a little, not one thread per vCPU, because SMT siblings contend. If you run the self-hosted server, LAYA_THREADS caps the same setting.

Cold starts and memory

A cold load took 4.4 s for the English checkpoint and 2.5 s for multilingual on the EPYC machine. These figures depend on the OS file cache, so treat them as approximate. Two practical consequences:

Preload the checkpoints you serve (Router(preload=True)) instead of loading on the first request.
Budget memory. The benchmark script peaked at 9.3 GiB with up to five checkpoints loaded at once. Serving fewer checkpoints should need less, but the upstream run does not report a per-checkpoint figure, so measure on your own machine.

When is a CPU enough?

This table is our interpretation of the numbers above, not a benchmark result. It assumes one question per call:

your situation	CPU is fine?
Background jobs, queues, nightly batch classification	Yes. Latency rarely matters; cost does.
Interactive routing or triage in non-English text	Usually. `laya-multilingual` at about 0.2 s is fast enough for many UIs.
Interactive English decisions with several questions per request	Borderline. Five questions on the English checkpoint take about 3 s.
High-throughput, low-latency serving	Use a GPU. A T4 answers one question in 32.8 to 39.5 ms.

These are single-process, in-process numbers. Real deployments add HTTP, queuing, and concurrency effects, so benchmark your own hardware with your own questions before committing. The upstream script is research/scripts/bench_latency.py.

Sources

Laya BENCHMARKS.md: server CPU, laptop CPU, T4, and GB10 sections
Raw EPYC results
Laya benchmarks tracker: upstream and independent results with their test conditions