TypeSafe Raised $870M. Can Jev See? 408 Calls on 48 Real Photos
TypeSafe just raised $870 million, and with the 1.14 release Jev takes pictures too. You can put a photo in a request and get back a probability, a label, a level, or a box. I sent 48 openly licensed photos through both Jev versions, twice each, and checked every answer against labels I could verify. The 384 calls, plus 24 more to test question wording, cost less than four cents. This is what typed answers look like on images, and where they break.
An $870 million bet on short answers
On October 9, 2026, TypeSafe AI announced an $870 million round at a $7.5 billion valuation. Andreessen Horowitz led it, with Sequoia Capital, the earlier backer DCVC, and a group of angel investors. Martin Casado joined the board. The post calls it a Series A, and it is short on purpose. It says the money goes to more machine-native models, enterprise features, and hiring.
The numbers around the round are company claims. TypeSafe told Bloomberg that Jev passed one million users within days of its September 15 launch. It also says about a third of the Fortune 500 use Jev, and it names none of them. TechCrunch and SiliconANGLE reported the same figures on the same day. I have no way to check the customer count, so I treat it as a claim.
Developers were less sure than the investors. The Hacker News thread on the round drew 357 comments, and the top worry was the moat. Within days of the launch, other labs shipped models with the same shape: text in, typed probabilities out. A shape is easy to copy. Calibration, latency, and price on real work are harder to copy, and those are what a test can measure.
The CEO, Diogo Almeida, frames the product with a story about Einstein and Mr. Bean. The company quoted him on an AI that "responds like Einstein 95% of the time and Mr. Bean 5% of the time." His question is how anyone could automate anything with it. TypeSafe sells a model that flags the 5% it is unsure about. That is a claim you can test, and images are a hard place to test it.
What the 1.14 release changed
At an event it called JevDay, TypeSafe published the release post. It shipped jev-1.14.0 under the alias jev-preview, and it turned on image input for both 1.13 and 1.14. Image input and the 1.14 model first reached the public on the same day. The post says the older model "was multimodal all along," and TypeSafe had kept that path switched off.
The same post adds a fourth answer type, Box, which returns one rectangle around a target. Box needs 1.14. TypeSafe calls images and Box "dreamer-ready," which means not ready for production. It also gives a plain warning. In its words, "all models (Jev included) perform worse on multimodality over pure text." Its advice is to break questions into the simplest pieces you can.
That advice shaped my test. I did not ask Jev to describe a photo. I asked narrow questions with checkable answers. Is there a dog? Which of six things is the main subject? How much of the frame does it cover, and where is it? Every one of those has a right answer in a public dataset, so every probability can be scored.
A System One call, in one paragraph
If you have not used Jev, the Laya and Jev essay covers the model class in depth. The short version follows. You send a state and a set of typed questions to one endpoint. Jev reads the state once and answers every question in parallel. It writes no text. Each answer is a type your code can branch on. A Noul is the probability that a statement is true. A Choice picks one option from a set, a Score picks a level on an ordered scale, and a Box returns four edges.
Choice and Score answers carry a confidence. For a Choice it comes from a simple formula over the probabilities: n times the largest probability, minus one, divided by n minus one. A Noul carries only its probability, so the distance from 0.5 is its confidence. Price is $0.042 per million input tokens, and output tokens are free. My personal RAG harness used the same endpoint for text, and nothing in that code changes for images except the request body.
How a picture gets into a request
An image does not get a new field of its own. You list each image once in a top-level assets map under a reference string. Then you write that reference wherever the image belongs: in the state, in a question's instructions, or in a question's criteria. The API replaces each reference with the image before the model reads it. You also send one header, TypeSafe-Danger-Zone-Images: true, on every request that carries an image or a Box question.
This is a trimmed copy of the request I sent for every photo. One photo sits in the state. Eight Nouls, one Choice, and one Score refer to it by name, and the 1.14 requests add two Box questions.
{
"model": "jev-1.14.0",
"state": {"photo": "img-6f1c..."},
"assets": {"img-6f1c...": {"type": "image", "format": "jpg", "data_base64": "..."}},
"questions": {
"has_dog": {"type": "noul", "instructions": "Is there a dog in `photo`?"},
"subject": {"type": "choice", "instructions": "What is the main subject of `photo`?",
"criteria": {"dog": "A dog.", "cat": "A cat.", "horse": "A horse.",
"bus": "A bus.", "pizza": "A pizza.", "bicycle": "A bicycle."}},
"box_target": {"type": "box", "instructions": "the dog in `photo`"},
"box_absent": {"type": "box", "instructions": "the cat in `photo`"}
}
}Use a long random reference such as a UUID. References match as plain text anywhere in the request. A short key like cat would also match inside the word "category." The Python and JavaScript SDKs create references for you. Without an SDK, the images docs recommend multipart uploads, because base64 makes each file about a third larger.
The limits are strict and the API does not resize for you. Images must be still PNG or JPEG files, between 280 and 1568 pixels on each side, and at most 16 MiB each. The whole request has a 32 MiB ceiling. The API strips EXIF data and does not apply the orientation tag, so rotate the pixels yourself before you send a phone photo.
Images cost the same per token as text. My photos were mostly 640 pixels on the long side. A request with one photo and ten short questions used between 1,147 and 1,728 input tokens, depending on the photo's size. At list price that is about six thousandths of a cent per request.
The photos and the labels
A test is only as good as its labels, so I did not label pictures by eye and call it truth. I took photos from the COCO 2017 validation set, which comes with human-drawn boxes for 80 kinds of object. I kept only photos whose Flickr license allows reuse with credit: CC BY or CC BY-SA. The credits for every photo sit at the end of this post.
I picked six targets: dog, cat, horse, bus, pizza, and bicycle. For each target I chose eight photos with exactly one labeled instance of it. That instance covers at least 4 percent of the frame, and none of the other five targets appear. That gives 48 photos where the main subject is clear and its box is known. I also asked about people and cars, which appear in the background of many of these photos.
Then I looked at all 48 photos myself. COCO labels are good, but they are not complete. Two photos show a second pizza or a second bicycle that has no label. I kept them and report the box results with and without them. One photo shows a red traffic light with a horse and rider painted on it, next to a small bus. That photo became the most useful one in the set.
Each photo got one request per model, per run. I sent every request twice to jev-1.13.0 and twice to jev-1.14.0. A second request type asked the picture question you will meet in step seven. In total that is 384 calls, all answered with HTTP 200, and every request and response is saved with the image data stripped out.
Every answer here is a recorded Jev response. Pick a photo, a model, and a run, then switch between question types. The dashed green box is the COCO label. The solid box is Jev's answer.
Step 1: Ask yes or no about a photo
The Noul is the simplest question and the one most code will use. "Is there a dog in photo?" returns one number between 0 and 1. I asked eight of these per photo, for the six targets plus person and car. Over two runs that is 768 answers per model, each with a known right answer.
Both versions did well. At a cut of 0.5, jev-1.13.0 was right on 98.4 percent of answers and jev-1.14.0 on 99.1 percent. The Brier score, the mean squared gap between the probability and the truth, was 0.0105 and 0.0088. A model that guessed 0.5 every time would score 0.25. Small objects did not hurt much. Six labeled people or cars covered less than 2 percent of their photo, and both versions found all six on both runs.
The wrong answers are the interesting part. On jev-1.13.0, run 1 had six of them, and none sat near 0 or 1. They scored between 0.55 and 0.81. One said there was a car in a horse photo, and the photo shows a white van at the edge of the frame. Another gave 0.59 to a dog in an oven photo, where the pizza box on the stove carries printed art. The traffic light scored 0.59 for horse, because it shows one.
Those are not random failures. They are cases where the question is honestly unclear, and the model put them in the middle of the scale. A label set says "no horse" because no living horse stands in the frame. The model saw a horse and hedged. "Is there a living horse in photo?" is a different question. Step 2 tests exactly that.
Calibration is the claim behind the whole product, so I checked it directly. A calibrated model's 0.8 should be right about 80 percent of the time. The figure below sorts all 768 answers into ten bins by probability and plots how often each bin was true. Tap a bin to see the photos and questions inside it.
Each dot is one probability bin. Its size is the number of answers in it, its height is how often those answers were true. Dots on the diagonal are calibrated. Tap a dot to list what is inside.
Two things stand out. First, almost every answer sits at the ends of the scale. On jev-1.13.0, 573 of 768 answers fell below 0.1 and 152 above 0.9, and every one of those was right. Second, the two versions spread their middle differently. jev-1.14.0 puts more true negatives between 0.1 and 0.2 than 1.13 does. Its negatives average 0.057, against 0.032 on the older model.
That difference matters more than the accuracy gap. If you tune a threshold on one version and move to the other, the same threshold routes a different share of work. You will see this again in the router at the end. The release post says jev-latest moves to 1.14 a week after release, so pin the version you tuned against.
Step 2: Fix the question, not the threshold
The middle answers in step 1 pointed at questions with two fair readings. So I sent six of those photos back with each question asked three ways. One was the original, one was stricter, and one named the other reading. Each version ran twice on both models, in 24 more calls.
The traffic light split cleanly. "Is there a living horse in photo?" scored 0.03 on jev-1.13.0 and 0.09 on jev-1.14.0. "Does photo show a picture, sign, or symbol of a horse?" scored 0.99 and 0.98. The original question sat near 0.6 because it was two questions in one.
The van did the same. "Is there a passenger car" scored between 0.23 and 0.32 on both versions. "Is there a van" scored 0.98 on 1.13 and 0.88 on 1.14. On the oven photo, 1.13 gave 0.93 to "a printed picture or drawing of a dog." It had seen a dog in the box art. The newer model gave that question 0.40 and 0.50, and it had already put the plain dog question near 0.1.
One middle answer was right where the label was wrong. The pizza photo shows fingers holding a knife in the top corner, cut off by the frame. COCO marks no person in it. "Is any part of a person, such as a hand, visible" scored 0.95 on 1.13 and 0.92 on 1.14. The model had been hedging on a real hand.
Two cases did not resolve. In the cat photo, a cartoon figure printed on a box kept 1.13 near the middle for every wording. In the bus photo, 1.13 saw a bicycle at about 0.8 and 1.14 at about 0.2, and I could not find one either. Rewording does not fix every case. It fixes the ones where the question was ambiguous, and it shows you which ones those are.
The habit is cheap. When answers pile up between 0.3 and 0.7 on some inputs, look at those inputs before you move a threshold. Often the model is reporting that your question has two meanings. Ask both meanings as separate Nouls in the same request. The image sits in the state once, so the extra Noul adds only its own short text.
Step 3: Pick one label from a set
The Choice asked "What is the main subject of photo?" with six options described in words. Both versions picked the COCO target on 47 of 48 photos in both runs, which is 97.9 percent. Mean confidence was 0.995 on 1.13 and 0.993 on 1.14.
The one miss was the same photo on every run: the traffic light. The label says bus, because a small red bus sits in the bottom corner. Jev said horse with 0.96 confidence, because the largest thing in the frame is a lit horse and rider. I think Jev has the better reading. That is a useful lesson about ground truth. A label set is a set of decisions made by people, and some of them are arguable.
High confidence on a wrong label is the failure that hurts in production. Here it happened once in 96 answers per model, on a photo where a person might also say horse. On cleaner photos the Choice never wavered. I would trust it for a first sort of uploads into a few known kinds. Add a confidence floor and a review lane for the rest.
Step 4: Place a photo on a scale
The Score asked how much of the photo the target covers, on four levels. Tiny is under 5 percent, small is up to 15, medium is up to 40, and large is above that. I computed the true level from the area of the COCO box. A Score answer returns a probability for each level, and its score field is the expected level, so it can land between two levels.
This is where the versions split. Rounded to the nearest level, jev-1.14.0 matched the box level on 80 percent of answers and jev-1.13.0 on 60 percent. The mean distance from the true level was 0.32 levels on 1.14 and 0.45 on 1.13. The newer model is better at judging size, and that matches what Box needs from it.
Part of the remaining error is mine. A box around a bicycle or a horse in motion holds a lot of empty space. The model reads coverage as what the object fills, and I scored it against the box. Define each Score level with the same quantity you will check it against. Otherwise the test blames the model for your ruler.
Step 5: Find where it is
Box is the new type, and it only runs on jev-1.14.0. You name the target and the image, as in "the dog in photo." The answer gives top, bottom, left, and right as fractions of the image. Fractions mean the same answer works at any image size. Multiply each edge by the width or height in pixels to crop or draw it.
I scored each box by intersection over union, or IoU. It is the overlap between Jev's box and the label box, divided by the area they cover together. An IoU of 1 is a perfect match, and 0.5 is the usual line for a correct detection. Across 96 target boxes, the mean IoU was 0.85 and the median 0.90. 93.8 percent of boxes cleared 0.5. Without the two photos that hold an unlabeled second object, that rises to 95.7 percent.
The misses had a pattern. The worst box, with an IoU of 0.16, came from the photo with two pizzas. Jev boxed the pizza with no label and gave it a confidence of just 0.13. A bicycle half hidden behind a man scored about 0.34, with confidence near 0.3. The blurred slice of pizza scored 0.32. The docs say a Box finds one target per question, so describe the one you want, such as "the pizza nearest the camera."
Box confidence also tracked quality. Mean confidence on the target boxes was 0.76, and two of the three worst boxes sat near 0.3 or lower. That number becomes useful in the next step, where the target is not there at all.
Step 6: Ask for something that is not there
A Box answer is always a box. There is no "not found" type, and the Box docs say so plainly. To see what that means, I asked every photo for a target it does not contain. A dog photo got a request for a cat, and a pizza photo got one for a bus. All 96 answers came back as valid boxes with four edges.
A quarter of those boxes landed on the real subject. Asked for a cat in a photo of a dog, Jev boxed the dog, with an IoU above 0.5 against the dog's label. The rest landed on some other region. If your code crops whatever comes back, a quarter of absent requests would hand you a confident-looking crop of the wrong animal.
The fix the docs recommend is a Noul in the same request: "Is there a cat in photo?" Ignore the box when the Noul is low. In my set that pair caught all 96 absent targets, because every one of those Nouls scored below 0.5. Box confidence alone also helps. Absent boxes averaged 0.23 confidence, against 0.76 for real targets. A cut at 0.6 rejected 92 percent of the absent boxes, but it also drops some real ones. The figure lets you try both guards.
Each tile shows the box Jev returned when asked for something the photo does not hold. Choose a guard and a threshold. The same rule runs on the real target boxes, so you see what each guard costs.
The Noul pair wins on this set. At a 0.5 cut it rejected every absent box and kept 47 of 48 real ones on each run. The one it lost was the blurred pizza slice, whose own Noul scored 0.23. Box confidence alone trades one error for another. Set it high enough to reject the absent boxes and you start losing real targets that the model found but felt less sure about. The extra Noul costs a few tokens in a request that already carries the image, so there is no reason to skip it.
Step 7: Use pictures as the answer options
The most unusual part of the image support is that pictures can be criteria. A Choice option can be an example image instead of a sentence. The docs show a gesture classifier where "thumbs up" is defined by a photo of a thumb. This matters when you have no good words for your categories. Think of a part number, a shelf layout, or a defect you can show but not name.
I built the same subject question with pictures only. For each of the six targets I cut one example from a separate COCO photo, so no test photo could match its own crop. The options were named option_1 to option_6, so the option names carried no meaning. The question was "Which option shows the same kind of thing as the main subject of photo?"
"match": {
"type": "choice",
"instructions": "Which option shows the same kind of thing as the main subject of `photo`?",
"criteria": {"option_1": "img-a19e...", "option_2": "img-7c02...", "option_3": "img-e4d1...",
"option_4": "img-0b6f...", "option_5": "img-93aa...", "option_6": "img-5d27..."}
}Picture options scored almost as well as words. The older model matched on 96.9 percent of answers and the newer one on 95.8 percent. Word options scored 97.9 percent on both. The misses are the useful part. Both versions missed the same two photos, a slice of pizza held in a blur and a bicycle half hidden behind a man. Every time they chose the horse example, with confidence between 0.26 and 0.47.
That is low confidence doing its job. Mean confidence on picture options was 0.88 on 1.13 and 0.91 on 1.14, against 0.99 for words. Every miss sat far below that. On jev-1.14.0, a floor of 0.5 sends all four misses to review, along with only two right answers. You pay for the pictures in tokens. Six reference images raised each request from about 1,400 to about 3,100 input tokens, which is still about thirteen thousandths of a cent.
Step 8: Two versions and two runs
The table pulls the headline numbers together. Each row counts both runs, and the Box rows apply to jev-1.14.0 only. Latency is the full round trip from my laptop over home internet, so read it as an upper bound.
| Measure | jev-1.13.0 | jev-1.14.0 |
|---|---|---|
| Noul right at 0.5 (768 answers) | 98.4% | 99.1% |
| Noul Brier score | 0.0105 | 0.0088 |
| Choice, word options (96) | 97.9% | 97.9% |
| Choice, picture options (96) | 96.9% | 95.8% |
| Score on the right level (96) | 60.4% | 80.2% |
| Box IoU, mean and median (96) | no Box type | 0.85 and 0.90 |
| Absent boxes caught by a Noul pair | no Box type | 96 of 96 |
| Median latency, one photo, 10 to 12 questions | 848 ms | 950 ms |
| Input tokens, 192 calls | 432,455 | 434,962 |
| Cost of 192 calls at list price | $0.018 | $0.018 |
Jev is not fully deterministic, and that is worth knowing before you set thresholds. I compared each Noul between run 1 and run 2. On jev-1.13.0, 84 percent of pairs came back identical and the largest move was 0.08. On jev-1.14.0, 59 percent were identical and the largest move was 0.06. Only one answer crossed 0.5 between runs: the van in the horse photo on 1.14, read as a car once and not the other time. Leave a margin of about a tenth around any threshold you set.
At list price, one photo with ten questions costs about six cents per thousand photos, or about $60 per million. The two versions cost the same per token and used almost the same tokens. The newer one added Box and better size judgment, and it took about 100 milliseconds longer per call. For text work the release post says the main gain is in languages other than English, which this test does not cover.
Step 9: Build an intake router
Now put the pieces into the kind of small system the product is meant for. Picture a pet adoption site that accepts listing photos. It wants every photo to show a dog or a cat, and it wants a tight crop for the thumbnail. A person reviews only the photos the model is unsure about.
One request per upload carries the photo and three questions: a Noul for dog, a Noul for cat, and a Box for the animal. The code takes the larger of the two Nouls. Above a high threshold the photo is accepted and cropped to the box. Below a low threshold it is rejected. Anything between goes to a person. The Box only matters for accepted photos, and the Noul has already confirmed the animal is there.
def route(answers, accept_at=0.9, reject_at=0.1):
pet = max(answers["has_dog"]["noul"], answers["has_cat"]["noul"])
if pet >= accept_at:
return "accept", answers["box_target"]["box"]
if pet <= reject_at:
return "reject", None
return "review", NoneThe figure runs that function over all 48 photos with the recorded answers. Sixteen photos hold a dog or a cat, and the other 32 are buses, horses, pizzas, and bicycles. Drag the thresholds and watch photos move between lanes. Accepted photos show the crop Jev's box would produce.
Accept when the larger of the dog and cat Nouls reaches the accept line. Reject when it falls to the reject line. A person sees the rest. A red outline marks a wrong automatic decision.
accept and crop
person reviews
reject
With the accept line at 0.9 and the reject line at 0.1, jev-1.14.0 handles 45 of 48 photos on its own. It makes no wrong decision, and three photos go to a person. Pull both lines inward to 0.8 and 0.2 and it handles all 48, still with no errors on this set. Push them out to 0.95 and 0.05 and the review lane on 1.14 jumps to 20 photos, because its true negatives sit just above 0.05.
Run the same thresholds on jev-1.13.0 and the lanes shift. At 0.95 and 0.05 the older model sends only six photos to review, because its negatives sit closer to zero. Neither version is wrong. They place their uncertainty in different spots, and a router tuned on one is not tuned on the other. That is the practical meaning of pinning a version.
Forty-eight photos is a small set, and a real intake queue has blurry phones, screenshots, and dogs in costumes. The router shape still holds. Ask narrow questions and put a Noul next to every Box. Act only at the ends of the scale. Measure the middle on your own uploads before you trust any threshold.
Where it breaks
TypeSafe says images and Box are not ready for production, and my results do not change that. They show a model that is strong on clear photos of common objects. They do not show how it handles your data. Each limit below came up in this test or in the docs.
The test set is small and clean. Forty-eight photos with one clear subject each is close to the easiest case for a vision model. Small, cluttered, or unusual targets will do worse. The docs suggest cutting large images into tiles and asking a Choice over the tiles first, then a Box on the chosen tile.
Box has no "not found" answer and returns one box per question. Pair it with a Noul every time. When a photo can hold several of the same thing, describe the one you want. You can also add a Choice with none, one, and several as options.
Labels disagree with reasonable readings. The traffic light showed how a question like "is there a horse" splits on a painted horse. Write questions that say what you mean, such as a living horse or a horse on a sign. Test the wording on edge cases before you ship it.
Thresholds belong to a version. At 0.95 and 0.05, the review lane held 6 photos on 1.13 and 20 on 1.14. Pin the model ID in code, log the model field of every response, and retune when you upgrade.
Answers move a little between identical calls. The largest Noul move I saw was 0.08, so a threshold placed exactly on an answer's value will flip some of the time. And the business claims around the round, the user count and the Fortune 500 share, remain claims with no public customer list behind them.
What to build first
Start where a picture already decides a branch in your code and a person makes that call today. Upload checks are the obvious case: does this receipt show a total, does this listing photo show the product, is this screenshot an error page. Each of those is a Noul or a short Choice with a checkable answer, and the cost per check is a rounding error.
Picture options are the less obvious win. If your categories are easier to show than to name, give the model one example image per category. Let confidence decide what a person sees. In my test the misses on picture options were the least confident answers in the set, which is exactly where you want them.
The docs list a few more patterns that fit the same shape, and each one keeps the questions narrow. To spot what changed, put a short history of frames in the state, oldest first, and ask about arrivals or motion. To search a large image, cut it into tiles and ask a Choice with the tiles as options, then repeat on the chosen tile. To save tokens, ask about a small copy first and send a larger crop only when the answer needs detail. Each of these turns a vague vision task into a few typed questions you can score.
Measure each one the way this post did. Pick 50 inputs you can label with certainty, run every question twice on the pinned version, and plot the reliability bins. If the middle bins hold real errors, rewrite the question first. Move the threshold only after the question reads the way you mean it.
Box is the newest piece and the one to treat with most care. Use it to crop, highlight, or point a reviewer at a region, and keep a Noul beside it. Do not let a box alone prove that something is in a photo.
What the round buys
The $870 million is a bet that software wants short, typed, calibrated answers more than it wants paragraphs. Images widen what those answers can be about. On 48 photos, both versions gave probabilities that meant what they said. They picked labels a careful person would pick, and they put their doubt on the photos that deserved it. The new model found objects with a median overlap of 0.90 and never claimed an absent one when a Noul stood next to it.
None of that proves the valuation. It does show the product claim holding on a modality TypeSafe itself calls experimental. The useful habit is the same one from the text essays. Label a set of your own inputs and run every question twice. Read the middle of the scale, and let the model act only where your own data says it is right.
Photo credits
Keep reading