Skip to content

Conversation

@tnsardesai
Copy link
Contributor

@tnsardesai tnsardesai commented Jan 28, 2026

Summary

Adds 1280x800 viewport support to the CLI and updates Yutori computer-use templates to use this resolution as the default, per Yutori's recommendation for optimal grounding accuracy.

Changes

  • Added 1280x800@60 viewport option to browsers create and browsers update commands
  • Updated Yutori computer-use templates (TypeScript & Python) to default to 1280x800 viewport instead of 1200x800
  • Updated help text and documentation to reflect the new viewport option
  • Fixed test to expect 7 viewports instead of 6

Context

Yutori n1 recommends a 1280×800 (WXGA, 16:10) viewport for best grounding accuracy. This change aligns the CLI and templates with this recommendation.

Related Issues

Related to kernel-839

TODO

  • Add testing sections

Note

Low Risk
Primarily adds a new supported viewport enum value and adjusts template defaults/documentation; functional risk is limited to potential layout/coordinate-scaling differences at runtime.

Overview
Adds 1280x800@60 as a supported viewport for kernel browsers create/update, including interactive selection and updated flag help text, plus test coverage updates for the expanded viewport list.

Aligns computer-use templates to 1280×800 defaults. Anthropic computer-use templates (TS/Python) now pass viewport dimensions through the session/sampling loop into ComputerTool params, and Yutori templates (TS/Python) switch defaults from 1200×800 to 1280×800, move to n1-latest, and update docs/QA invoke commands (including switching magnitasks URLs to https://www.magnitasks.com).

Written by Cursor Bugbot for commit 871d173. This will update automatically on new commits. Configure here.

- Add 1280x800@60 viewport option to browser create/update commands
- Update Yutori computer-use templates (TypeScript & Python) to use 1280x800 as default viewport
- Update documentation and help text to reflect new viewport option
@github-actions
Copy link

🔧 CI Fix Available

I've pushed a fix for the CI failure. The test expected 6 viewports but 7 were added after including 1280x800@60.

👉 Click here to create a PR with the fix

@tnsardesai tnsardesai marked this pull request as ready for review January 28, 2026 08:13
…d Python templates

- Removed the `refresh_rate` property from the viewport configuration in both TypeScript and Python templates for the Anthropic and Yutori computer use sessions.
- This change simplifies the viewport settings and aligns with the current requirements.
Updated comments in SamplingLoopOptions and SessionOptions to remove references to default viewport width and height values, clarifying that these fields are for coordinate scaling and viewport size without specifying defaults.
Introduces viewportWidth and viewportHeight parameters to both Python and TypeScript anthropic templates, allowing the viewport size to be set when initializing sessions and tools. Updates default values to 1280x800 and ensures these values are used throughout session creation and tool instantiation.
@dprevoznik
Copy link
Contributor

dprevoznik commented Jan 28, 2026

@tnsardesai looks good from my review (one outstanding cursor bugbot callout). I'd like to test this once it's merged into the API before merging to CLI, since changes to the templates are being updated here too (added Anthropic template viewport changes as well to try out). Sound good?

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

Copy link
Contributor

@hiroTamada hiroTamada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ALLOWED_VIEWPORTS_JSON

[
	{"width":1024,"height":768,"refresh_rate":60},
	{"width":1920,"height":1080,"refresh_rate":25},
	{"width":2560,"height":1440,"refresh_rate":10},
	{"width":1920,"height":1200,"refresh_rate":25},
	{"width":1440,"height":900,"refresh_rate":25},
	{"width":1200,"height":800,"refresh_rate":25}
]

We need to update this on railway env to allow the new configuration.

https://github.com/kernel/kernel/blob/main/packages/api/openapi.yaml#L290-L295
We should change this for stainless doc.

https://github.com/kernel/kernel-images/blob/main/images/chromium-headful/xorg.conf

lets double check if the configuration is even allowed on the images side.

Did you test this change?

Copy link
Contributor

@Sayan- Sayan- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

noice

@tnsardesai
Copy link
Contributor Author

ALLOWED_VIEWPORTS_JSON

[
	{"width":1024,"height":768,"refresh_rate":60},
	{"width":1920,"height":1080,"refresh_rate":25},
	{"width":2560,"height":1440,"refresh_rate":10},
	{"width":1920,"height":1200,"refresh_rate":25},
	{"width":1440,"height":900,"refresh_rate":25},
	{"width":1200,"height":800,"refresh_rate":25}
]

We need to update this on railway env to allow the new configuration.

planning to do this before merging the api PR

https://github.com/kernel/kernel/blob/main/packages/api/openapi.yaml#L290-L295 We should change this for stainless doc.

yea this is changed in https://github.com/kernel/kernel/pull/1071

https://github.com/kernel/kernel-images/blob/main/images/chromium-headful/xorg.conf

lets double check if the configuration is even allowed on the images side.

hmm, I didn't change this but my test still ran fine 🤔

Did you test this change?

yep here is the test https://github.com/kernel/kernel/pull/1071#issuecomment-3813297895

@tnsardesai
Copy link
Contributor Author

https://github.com/kernel/kernel-images/blob/main/images/chromium-headful/xorg.conf
lets double check if the configuration is even allowed on the images side.

in addition to other tests this also shows that screen dimensions are correct.

lkernel browsers process exec ea0wje32nuoolrwbrj1xv4i7 'xdpyinfo | grep dimensions'
Property      | Value
Exit Code     | 0
Duration (ms) | 4
 INFO  stdout:
  dimensions:    1280x800 pixels (339x212 millimeters)

Docs say In most cases this isn’t necessary because the built−in set of VESA standard modes will be sufficient. so maybe thats why.

I did some more digging and seeing lkernel browsers process exec ea0wje32nuoolrwbrj1xv4i7 'xrandr --query' returns

lkernel browsers process exec ea0wje32nuoolrwbrj1xv4i7 'xrandr --query'
Property      | Value
Exit Code     | 0
Duration (ms) | 5
 INFO  stdout:
Screen 0: minimum 64 x 64, current 1280 x 800, maximum 32767 x 32767
DUMMY0 connected primary 1280x800+0+0 0mm x 0mm
   3840x2160_25.00  25.00
   2560x1440_30.00  30.00
   2560x1440_25.00  24.96
   2560x1440_10.00  10.72
   2048x1536     60.00
   1920x1440     75.00    60.00
   1856x1392     75.00    60.01
   1792x1344     75.00    60.01
   2048x1152     59.90
   1920x1200_60.00  60.03
   1920x1200     59.88
   1920x1200_30.00  30.75
   1920x1200_25.00  26.37
   1920x1200_10.00  11.08
   1920x1080     59.96
   1920x1080_60.00  60.00
   1920x1080_30.00  30.00
   1920x1080_25.00  25.00
   1920x1080_10.00  10.56
   1600x1200     85.00    75.00    70.00    65.00    60.00
   1680x1050     59.95
   1400x1050     74.76    59.98
   1600x900      59.95
   1600x900_25.00  24.97
   1280x1024     85.02    75.02    60.02
   1440x900_60.00  59.90
   1440x900_30.00  30.10
   1440x900_25.00  26.08
   800x1600_30.00  30.00
   800x1600_25.00  24.92
   1400x900      59.96
   1280x960      85.00    60.00
   1368x768      59.88
   1368x768_30.00  30.00
   1368x768_25.00  24.89
   1280x800      59.81*
   1152x864      75.00
   1200x800_60.00  60.00
   1200x800_30.00  29.99
   1200x800_25.00  24.99
   1200x800_10.00  10.57
   1280x720      59.86
   1280x720_60.00  60.00
   1280x720_30.00  30.00
   1024x768      85.00    75.03    70.07    60.00
   1024x768_60.00  59.92
   1024x768_30.00  31.15
   1024x768_25.00  26.73
   1152x648_60.00  60.00
   960x720_60.00  60.00
   960x720_30.00  30.00
   1024x576_60.00  60.01
   1024x576      59.90
   832x624       74.55
   960x540       59.63
   800x600       85.14    72.19    75.00    60.32    56.25
   800x600_60.00  60.01
   864x486       59.92
   640x480       85.01    75.00    72.81    59.94
   720x405       59.51
   720x400       85.04
   640x400       85.08
   640x360       59.84    59.32
   640x350       85.08
DUMMY1 disconnected
DUMMY2 disconnected
DUMMY3 disconnected

soo looks like this happened to be supported by our image already... @hiroTamada @Sayan- should I still add 1280x800_<rate> to kernel-images?

@hiroTamada
Copy link
Contributor

https://github.com/kernel/kernel-images/blob/main/images/chromium-headful/xorg.conf
lets double check if the configuration is even allowed on the images side.

in addition to other tests this also shows that screen dimensions are correct.

lkernel browsers process exec ea0wje32nuoolrwbrj1xv4i7 'xdpyinfo | grep dimensions'
Property      | Value
Exit Code     | 0
Duration (ms) | 4
 INFO  stdout:
  dimensions:    1280x800 pixels (339x212 millimeters)

Docs say In most cases this isn’t necessary because the built−in set of VESA standard modes will be sufficient. so maybe thats why.

I did some more digging and seeing lkernel browsers process exec ea0wje32nuoolrwbrj1xv4i7 'xrandr --query' returns

lkernel browsers process exec ea0wje32nuoolrwbrj1xv4i7 'xrandr --query'
Property      | Value
Exit Code     | 0
Duration (ms) | 5
 INFO  stdout:
Screen 0: minimum 64 x 64, current 1280 x 800, maximum 32767 x 32767
DUMMY0 connected primary 1280x800+0+0 0mm x 0mm
   3840x2160_25.00  25.00
   2560x1440_30.00  30.00
   2560x1440_25.00  24.96
   2560x1440_10.00  10.72
   2048x1536     60.00
   1920x1440     75.00    60.00
   1856x1392     75.00    60.01
   1792x1344     75.00    60.01
   2048x1152     59.90
   1920x1200_60.00  60.03
   1920x1200     59.88
   1920x1200_30.00  30.75
   1920x1200_25.00  26.37
   1920x1200_10.00  11.08
   1920x1080     59.96
   1920x1080_60.00  60.00
   1920x1080_30.00  30.00
   1920x1080_25.00  25.00
   1920x1080_10.00  10.56
   1600x1200     85.00    75.00    70.00    65.00    60.00
   1680x1050     59.95
   1400x1050     74.76    59.98
   1600x900      59.95
   1600x900_25.00  24.97
   1280x1024     85.02    75.02    60.02
   1440x900_60.00  59.90
   1440x900_30.00  30.10
   1440x900_25.00  26.08
   800x1600_30.00  30.00
   800x1600_25.00  24.92
   1400x900      59.96
   1280x960      85.00    60.00
   1368x768      59.88
   1368x768_30.00  30.00
   1368x768_25.00  24.89
   1280x800      59.81*
   1152x864      75.00
   1200x800_60.00  60.00
   1200x800_30.00  29.99
   1200x800_25.00  24.99
   1200x800_10.00  10.57
   1280x720      59.86
   1280x720_60.00  60.00
   1280x720_30.00  30.00
   1024x768      85.00    75.03    70.07    60.00
   1024x768_60.00  59.92
   1024x768_30.00  31.15
   1024x768_25.00  26.73
   1152x648_60.00  60.00
   960x720_60.00  60.00
   960x720_30.00  30.00
   1024x576_60.00  60.01
   1024x576      59.90
   832x624       74.55
   960x540       59.63
   800x600       85.14    72.19    75.00    60.32    56.25
   800x600_60.00  60.01
   864x486       59.92
   640x480       85.01    75.00    72.81    59.94
   720x405       59.51
   720x400       85.04
   640x400       85.08
   640x360       59.84    59.32
   640x350       85.08
DUMMY1 disconnected
DUMMY2 disconnected
DUMMY3 disconnected

soo looks like this happened to be supported by our image already... @hiroTamada @Sayan- should I still add 1280x800_<rate> to kernel-images?

yeah xorg.conf behavior is not trivial for me. Did you test again headless browsers as well?

Changed the model parameter in the Yutori computer use template from "n1-preview-2025-11" to "n1-latest" to ensure the latest model is utilized for tasks.
Replaced HTTP links with HTTPS in various kernel invoke commands within the QA documentation to ensure secure connections. This includes updates for the Yutori and Anthropic tasks related to the Magnitasks website.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants