"Drawing" the Mona Lisa with GPT-5.6, Claude, Gemini, and Grok

“Drawing” the Mona Lisa with GPT-5.6, Claude, Gemini, and Grok

A model can reproduce a recognizable Mona Lisa and still fail your production UI task.

That is the useful tension behind the recent AI Drawing Arena experiment, where GPT-5.6, Claude, Gemini, and Grok were asked to “draw” Leonardo da Vinci’s portrait using a constrained colored-pencil environment. The models were not simply returning images from a diffusion endpoint. They had to translate visual intent into a sequence of drawing decisions: where to place marks, which colors to use, how to layer shapes, and when to stop.

The outputs are interesting as pictures, but the more important result is architectural. A text model can operate a visual tool through structured actions and produce a coherent artifact. For API developers, that is a better test of agent behavior than another isolated reasoning puzzle.

It also exposes the limits of visual demos. Recognition, composition, tool use, and pixel-level fidelity are different capabilities. A single Mona Lisa rendering cannot collapse them into one leaderboard score.

What Actually Happened

The drawing exercise gave several frontier models the same broad objective: recreate the Mona Lisa with colored-pencil-like tools.

That setup tests a pipeline with at least four stages:

1. Interpret the requested subject.
2. Decompose it into drawable regions and features.
3. Convert that plan into valid tool operations.
4. Inspect or reason about intermediate state and refine it.

The quotation marks around “drawing” matter. These systems do not hold pencils, and this is not evidence of human-like artistic perception. They produce instructions that a drawing system executes. Depending on the implementation, an instruction might resemble:

{
  "tool": "draw_stroke",
  "arguments": {
    "points": [[182, 91], [176, 106], [174, 128]],
    "color": "#5b3a29",
    "width": 7,
    "opacity": 0.62
  }
}

A complete drawing may require hundreds or thousands of such decisions. A model that understands the subject but emits invalid coordinates will fail. So will a model that draws valid strokes in the wrong order, exhausts its action budget on the background, or keeps “improving” an already adequate face until it becomes less recognizable.

That makes the arena a mixed evaluation of:

• Spatial planning
• Tool-call reliability
• Long-horizon consistency
• Color and shape abstraction
• Budget management
• Error recovery
• Visual self-evaluation, if rendered frames are returned to the model

It is not a clean test of any one capability. That is a limitation, but it is also why the exercise resembles real agent applications.

Why the Mona Lisa Is a Useful Stress Test

The Mona Lisa is recognizable from a small set of anchors: the centered seated figure, dark hair, folded hands, muted clothing, landscape background, and restrained expression. A model can produce something identifiable without reproducing the original closely.

That creates three distinct success levels:

This distinction matters when reading model comparisons. Humans are generous evaluators of iconic subjects. A dark-haired figure with crossed hands against a green-brown landscape receives substantial recognition credit.

In practice, I see the same effect in UI-generation evaluations. A model can make a page that immediately reads as a dashboard while still producing broken filters, inaccessible controls, and incorrect data wiring. Visual plausibility often arrives before operational correctness.

A stronger drawing evaluation would include less iconic references, multiple styles, adversarial compositions, and hidden target images. It would also separate planning from execution by recording every tool call.

The Developer-Relevant Capability Is Tool Control

The headline result is not that general-purpose models can compete with dedicated image generators. They usually should not. If the requirement is a polished raster image, an image model remains the more direct tool.

The relevant development is that language models are becoming competent controllers for visual and spatial software.

The same pattern applies to:

• Editing a diagram through a canvas API
• Manipulating layers in a design application
• Generating CAD operations
• Building charts from structured data
• Operating a browser by coordinates
• Annotating medical or industrial images
• Creating animation timelines
• Driving game or simulation tools

A drawing action and a browser action have similar engineering properties. Both need a schema, bounded coordinates, state tracking, validation, and feedback.

For example, I would expose a normalized canvas rather than raw device pixels:

from pydantic import BaseModel, Field
from typing import Literal

class Point(BaseModel):
    x: float = Field(ge=0.0, le=1.0)
    y: float = Field(ge=0.0, le=1.0)

class Stroke(BaseModel):
    kind: Literal["stroke"] = "stroke"
    points: list[Point] = Field(min_length=2, max_length=64)
    color: str = Field(pattern=r"^#[0-9a-fA-F]{6}$")
    width: float = Field(ge=0.001, le=0.1)
    opacity: float = Field(ge=0.0, le=1.0)

Normalization makes actions portable across a 512×512 preview and a 2048×2048 final render. Validation also prevents malformed calls from reaching the drawing engine.

A common gotcha is allowing too many points per action. Large tool calls reduce request count, but one bad response can corrupt a substantial portion of the artifact. Smaller operations are easier to validate and retry, although they increase latency and token usage.

Comparing the Current Model Choices

The arena is a snapshot, not a universal ranking. Model behavior changes with prompts, tool schemas, reasoning budgets, feedback images, and retry policy. Even the label “GPT-5.6” should be treated carefully where API catalogs still expose GPT-5.5 as the current generally selectable GPT option. A demo label, preview route, internal alias, and public API model ID are not necessarily interchangeable.

For production selection, I would compare the available models by role:

These are workload hypotheses, not benchmark verdicts. The right model is the one that performs reliably under your schema, timeout, and budget.

AI Prime Tech can be useful here when a team needs cheaper Claude or multi-model API access for repeated evaluations. The practical benefit is not allegiance to one provider; it is being able to run the same harness across Claude, GPT, and Gemini routes without making evaluation cost the limiting factor.

How I Would Evaluate This in Production

Do not score only the final PNG. Preserve the action trace and calculate operational metrics.

A useful run record looks like this:

{
  "model": "candidate-model",
  "task": "mona-lisa-colored-pencil",
  "canvas": [1024, 1024],
  "action_limit": 800,
  "actions_attempted": 463,
  "actions_rejected": 7,
  "repair_requests": 3,
  "input_tokens": 28400,
  "output_tokens": 19750,
  "wall_time_ms": 186200,
  "completed": true
}

Then measure:

• Schema validity: accepted actions divided by attempted actions
• Completion rate: runs producing a render before the action or time limit
• Intervention rate: runs requiring manual correction
• Efficiency: quality per tool call, token, and second
• Stability: variance across five or more identical runs
• Recovery: whether the model repairs rejected actions correctly
• Visual similarity: automated comparison, supplemented by blinded human review

Token cost should include the complete loop, not just the first planning request. Suppose one run consumes 28,400 input tokens and 19,750 output tokens. With hypothetical rates of $3 per million input tokens and $12 per million output tokens:

Input:  28,400 / 1,000,000 × $3  = $0.0852
Output: 19,750 / 1,000,000 × $12 = $0.2370
Total per run                         $0.3222

Five repeated runs across seven models would cost:

5 × 7 × $0.3222 = $11.277

That excludes image-input charges, tool infrastructure, retries, and failed runs. Replace the hypothetical rates with the live prices for the exact API route being tested.

What actually happens in agent evaluations is that retries distort the economics. A model that appears 20% cheaper per request can become more expensive when it needs twice as many repair turns. Cost per successful artifact is the number worth tracking.

What the Demo Does Not Prove

This drawing exercise does not establish that a model has a general internal visual world model. It also does not prove authorship, creativity, or pixel-level understanding.

Several variables can dominate the result:

• Prompt detail
• Access to the source image
• Canvas resolution
• Available colors and tools
• Maximum action count
• Whether the model sees intermediate renders
• Hidden retries or human selection
• Sampling settings
• Model-specific prompt tuning

There is also a memorization concern. The Mona Lisa is one of the most represented images in training corpora. Reproducing its broad composition is different from reconstructing an unfamiliar private image.

The next useful tests should include unseen diagrams, arbitrary object arrangements, and tasks where geometric correctness can be measured directly. “Place the red circle 30 pixels left of the triangle” is less impressive than a portrait, but much easier to evaluate rigorously.

Practical Takeaways

• Treat the Mona Lisa result as a tool-use demonstration, not a definitive visual-intelligence ranking.
• Test the exact public API model ID you can deploy; demo names and production routes may differ.
• Use normalized coordinates, strict schemas, action limits, and deterministic validation.
• Store every tool call and intermediate render so failures can be diagnosed.
• Compare cost per successful completion, including retries and visual-input charges.
• Run repeated trials. One attractive output says little about production stability.
• Use smaller models such as Haiku 4.5 for validation or simple corrections when a frontier model is unnecessary.
• Use long-context models such as Fable 5 only when the workflow genuinely needs extensive scene history; context size does not replace spatial precision.
• Keep dedicated image generation in the stack. A language model should orchestrate visual tools when control and editability matter, not merely because it can produce a recognizable picture.
• Build a provider-neutral evaluation harness. The lasting development is not that one model drew the best Mona Lisa; it is that several model families can now compete as controllers of the same visual system.