Most of our conversations around Large Language Models focus on generative chat: you give the model a prompt, and it outputs a sequence of tokens autoregressively.
Recently, Typesafe AI introduced a different paradigm called System 1 models, embodied by Jev. Rather than generating free-form prose token by token, a Jev-style model acts as a high-speed, deterministic decision maker. Given an input state and a series of discrete questions, it runs in a single forward pass and outputs calibrated probability distributions for each question:
In this post, I will explain what these models offer, what was added to the SDK, and show you a complete, practical example of how to design a custom voice and synthesize speech with it.
A few months ago, I introduced the unofficial Antigravity SDK for Java.
My goal was simple: enable enterprise Java developers to build and run autonomous AI agents in Java, backed by the same engine that powers Google Antigravity.
The ability to run models locally on-device without cloud API dependencies, and without paying token costs for high-frequency tasks, sounded very appealing, right? 😃
I rely on Obsidian daily to capture ideas, interesting links & articles, and research clippings.
Because I alternate between different machines (my work computer and my personal laptop) I need my vault synchronized everywhere.
Instead of third-party cloud folders or paying for cloud sync tiers, I back my vault with a private Git repository (hosted on GitHub) and use the community obsidian-git plugin.
Git gives you full ownership, complete version history, granular diffs, and zero vendor lock-in. But if you simply git init your vault and call it a day, you will quickly run into some issues:
Since that release, I have continued using the visualizer to inspect complex agent runs, debug failed tool invocations, and review multi-agent orchestrations.
Over the last few days, I rolled out a series of incremental updates culminating in the v0.6.0 release,
with pre-built binaries available on the GitHub release page.
When Google initially introduced the Interactions API, there was no Java support in the official SDK. Because I wanted Java developers to be able to build with interactions, managed agents, and remote sandboxes right away, I created an unofficial, purpose-built library: the Gemini Interactions API Java SDK.
Now that official support is available under com.google.genai, developers have two ways to interact with this API from Java. In this post, I want to take a technical look at how both SDKs approach the same API, compare their ergonomics, and discuss when you might choose one over the other.
Before heading for well-deserved vacations, I wanted to share something I’ve been cooking on and off for the past few weeks:
an unofficial Java SDK for Antigravity.
If you’re familiar with Antigravity, you’ll know it’s available across different surfaces:
Antigravity 2.0: an agent manager for the Antigravity harness, where you can work across multiple projects and sessions from a rich UI,
Antigravity CLI: a CLI coding agent, where you can interleave running terminal commands, with active agent coding actions,
Antigravity IDE: a VSCode fork, with an integrated Antigravity chat assistant, when you want to be deep into the code,
Antigravity SDK: which is actually a toolkit you can integrate and manage yourself, to create your own Antigravity harness.
The benchmark numbers for Qxotic Jinfer in this article are outdated and abnormally low. At the time of testing, Jinfer had not yet been optimized for macOS and Apple Silicon processors.
A few weeks ago, I wrote about building the Antigravity Brain Visualizer:
a tool to parse raw JSONL transcript logs from Antigravity AI agent sessions
and render them into an interactive web interface with proportional timelines and sequence groupings.
While visual timeline scrubbing and sequence filtering made it easier to inspect what an agent did, diagnosing complex tool failures or creating preventative guardrails still required manual investigation:
Why did a tool call fail at step #38?
What sequence of events led up to a specific error?
Could I automatically turn a failure pattern into an Agent Skill to prevent Antigravity from repeating the mistake?
To address these questions directly within the application, I built the Interactive Session Assistant in v0.4.1 of the Antigravity Brain Visualizer.
It transforms the visualizer from a passive log viewer into an interactive diagnostic co-pilot.
When AI coding agents tackle complex tasks, they often waste time making the same mistakes, running into environment quirks, or retrying failed approaches before finding something that works. If an agent encounters a domain-specific trap in one session, that lesson is lost when the next session starts, forcing the agent to repeat the exact same trial-and-error cycle.
I built the Open Reasoning Format (ORF) to fix this.
ORF is a lightweight, file-based specification that lets AI agents record and retrieve operational learnings across sessions.
With access to playbooks from previous runs, agents facing similar problems can skip known dead ends, reach working solutions faster, and use about half the steps (and tokens).
