DeepSeek MIT Vision Weights: Price Screenshot Agents

Your screenshot agent is choosing between a metered API and a GPU you own. The trade-off is arithmetic. A hosted vision API prices each screenshot step by image tokens plus text tokens. Self-hosting prices it by active parameters, image tokens, GPU utilization, and outage exposure. If a step uses I image tokens and T text tokens, the API cost is (I + T) × P, where P is the per-token API price. The self-hosted cost is (I + T) × S, where S is the per-token serving cost for active parameters, plus fixed GPU cost divided by utilization, plus expected outage cost. Run the arithmetic before you choose.

The API bill is a token count, not a screenshot

The model was offered through its API from August 21 to August 30, 2026, before its open weights appeared on August 31, 2026, leaving a ten-day gap. That window matters because it lets you compare the same model under different billing regimes.

The hosted API bills each image at up to 384 tokens, at standard V4-Flash rates. For screenshot understanding, a dense UI can consume a large share of the step before any text is generated. The token count is the lever. You can reduce it by cropping, downscaling, or sending only the relevant region, but the API still prices every token it accepts.

Self-hosting moves the cost to active parameters

The published checkpoint is a 305B-parameter, vision-enabled sparse MoE model released under MIT terms, and it uses DFlash attention, Hyper-Connections, and DSpark speculative decoding so that only part of the 305B parameters runs for each token. The vision path uses a 32-layer, 1,024-dimensional encoder with 16 attention heads that splits images into 14-by-14-pixel patches, then passes the resulting visual features through an aligner into the 4,096-dimensional language backbone.

Per token, the router chooses six routed experts from a pool of 256, and it also keeps one shared expert active. Routing explains why the bill is not the full parameter count. What you pay for is the active slice, the image tokens, and the GPU time needed to keep that slice busy.

Build the cost model from completed steps

Build the comparison from the step, not from the model card. A screenshot agent step usually has a prompt, an image, and a short output. The image drives the bill. The prompt and output are often small compared with the visual payload. The model card describes the weights. The serving stack sets the machine cost. The API prices accepted tokens. Self-hosting prices the machine, the active slice, and the time the machine is busy.

• Unit cost per completed step: API price times image and text tokens versus self-hosted active-parameter serving cost times tokens plus fixed GPU cost.
• Reliability: hosted uptime versus your own failure domain, including GPU faults, image preprocessing errors, and capacity gaps.
• Operational burden: vendor dependency versus serving, batching, monitoring, and rollout work.

Use the list to force a decision. If the step is cheap and rare, the API is the lower-risk default. If the step is frequent and image-heavy, self-hosting can become the lower-cost default. When latency matters, measure both paths under the same load. The open weights let you run the experiment on the same model.

The experiment should compare completed steps, not raw tokens. A step that fails and retries is more expensive than a step that succeeds once. A step that blocks the agent is more expensive than a step that queues. Track retries, queue time, and blocked steps in US dollars per completed step.

The verdict favors self-hosting when utilization is high

For high-volume, cost-sensitive screenshot-reading steps, the open weights eliminate the token-by-token charge and the reliance on a single vendor keeping its API terms stable. Operation is the cost. You now own serving, batching, image preprocessing, failure handling, and capacity planning. The API gives you a metered line item. Self-hosting gives you a fixed-cost curve with utilization as the multiplier.

If your traffic is steady and your steps are image-heavy, the self-hosted formula can beat the API because the active-parameter serving cost can be lower than the per-token API price. If your traffic is spiky, the API can be cheaper because you do not pay for idle GPUs. Outage cost is the part most teams underprice. A hosted API outage is a vendor incident. A self-hosted outage is your incident, and it can stop the agent loop. Price that outage in the model.