Model comparisons · 2026-09-25
Screenshot and error analysis with Ember-1
Sending Ember-1 a screenshot of an error screen along with logs to get observations, likely causes and verification steps: how the image is sent, what to expect from the model, and the hidden information in screenshots.
Short answer
Ember-1 takes image input alongside text and returns text. When a screenshot of an error screen is sent together with log lines and the steps the user took, the model can describe what is on screen, list likely causes and suggest steps to verify them. Because reasoning is on by default, it can do well at connecting clues on screen with the logs.
What the model gives is a list of hypotheses, not a verified root cause. This row is available until 6 October 2026; its successor, moonshot/kimi-k3, accepts images only as base64 data URLs.
How the image is sent
The image is added to the chat message content as an image_url part. Ember-1 accepts two formats: a base64 data URL and an https address. An https address has to be reachable by the provider; an address that needs a session, or opens only from a company network, cannot be read. Sending the image directly inside the request avoids that problem altogether.
Images count as input tokens too, and the number they take depends on the image's size and content; the exact figure is read from the usage field of the response. Because moonshot/kimi-k3, which takes over after 6 October 2026, accepts only data URLs, sending images in that format now makes a change at the move unnecessary.
Image clarity also affects the result. Cropping the image to the part where the error is, rather than shrinking the whole screen, makes small text easier to read and can also reduce the number of tokens the image takes.
What to send with the screenshot
A screenshot shows how the error looks to the user; it often does not show why it happened. Giving the error text itself as plain text next to the image removes the chance of the model misreading small print. Log lines from the relevant time window, the steps the user took before the error and the expected behaviour give the clues in the image their meaning.
Stating the format of the answer up front also helps. Headings such as observations, likely causes and verification steps make the answer ready to hand to the next task. The example below uses that layout.
A request example
In the example the image is sent as a data URL, and the error text and logs are in the text part of the same message. max_tokens is kept generous for a long reasoning trace and a detailed answer; on Ember-1 there is no separate output ceiling below the context window.
Asking for error analysis with a screenshot and logs
import base64, os
from openai import OpenAI
client = OpenAI(base_url=os.environ["LLMTR_BASE_URL"] + "/v1", api_key=os.environ["LLMTR_API_KEY"])
with open("payment-error.png", "rb") as f:
shot = "data:image/png;base64," + base64.b64encode(f.read()).decode()
prompt = (
"The screenshot shows an error on a payment page. The error text and related log lines are below.\n"
"Write under three headings: Observations, Likely causes (ordered by likelihood), Verification steps.\n\n"
f"Error text: {error_text}\nWhat the user did: {user_steps}\nLogs:\n{log_lines}"
)
res = client.chat.completions.create(
model="fireworks/ember-1",
messages=[{"role": "user", "content": [
{"type": "text", "text": prompt},
{"type": "image_url", "image_url": {"url": shot}}, # data URL, also valid on Kimi K3
]}],
max_tokens=4000,
)
print(res.choices[0].message.content)What to expect from the model
The model can read everything on screen: the error message, the state of buttons, missing or overflowing fields, browser warnings. What it cannot see matters at least as much: network requests, state on the server, what happened before the screenshot was taken. So the answer is read as ranked hypotheses, each with a verification step.
The root cause is settled when the suggested steps reproduce the error or a test shows it. A code change the model proposes is likewise not applied without tests and review; the value of a good hypothesis list is that it speeds up where the investigation starts.
Connecting it to a bug-report flow
Screenshot analysis is most useful in a support or bug-tracking flow where users attach images when reporting a problem. When a report arrives, the model reads the image and the description and produces a first assessment; that assessment is attached to the ticket, and the engineer who picks it up starts from a list of hypotheses rather than a blank page.
Having the assessment arrive with fixed fields, such as the affected component, estimated severity and likely cause, makes tickets easier to sort and search. On Ember-1 these fields can be requested with strict json_schema. After 6 October 2026, on moonshot/kimi-k3, the same fields are requested with json_object and the schema is validated on the application side.
Hidden information in screenshots
Screenshots carry information the sender did not notice: customer names, email addresses, session parameters in the address bar, cookies and API keys visible in developer tools, internal system addresses. Because the model can read the writing in an image, everything visible is as exposed as text.
Ember-1 runs on third-party infrastructure abroad, and prompts and completions may be logged by the provider. Cropping the image to the part that concerns the error, covering sensitive areas permanently and, where possible, using screenshots from a test environment reduce that risk.
Frequently asked questions
Can I send the image as an https address?
On Ember-1, yes, as long as the address is reachable by the provider. moonshot/kimi-k3, which takes over after 6 October 2026, accepts only base64 data URLs.
Does Ember-1 generate images?
No. It takes image and text input and returns text only.
Does the model find the cause of the error with certainty?
No. It combines what is on screen with clues in the logs and ranks likely causes. The root cause is settled by reproducing the error or by a test.
How many tokens does an image take?
It depends on the image's size and content, and it counts as input tokens. The exact number appears in the usage field of the response.
Does switching reasoning off help in image analysis?
For simple work such as transcribing what the screen says, results can be good enough with reasoning off. For work that needs clues on screen connected with logs, reasoning can make a difference; comparing both modes on your own examples gives the most accurate answer.