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).
I constantly use a text editor to jot ideas, draft blog posts, or collate documents, but my usual options always felt a bit off. TextEdit is too bare-bones and defaults to a tiny font I can barely read. MacVim takes a few seconds too long to load. VS Code requires me to dismiss plugin updates and changelogs before I can even start typing.
I realized I didn’t want another bloated app from a big tech company. I wanted a personal tool tailored exactly to my workflow.
For the past few weeks, a lot has been written and said about Loop Engineering, and we’re seeing an explosion of Agent Skills out there for various tasks.
These concepts are trendy, but how do they actually translate into day-to-day productivity?
Today, I want to testify with a concrete use case where skills and loops helped me become significantly more productive: authoring Google Codelabs.
About Codelabs
For those who might not be familiar, Google Codelabs are guided, hands-on coding tutorials that walk developers step-by-step through building an application, integrating an API, or learning a new technology.
They are great educational resources, but crafting a high-quality one is far from trivial, and takes time.
Google just announced the launch of some new image and video models:
Nano Banana 2 Lite (the fastest, most cost-efficient Gemini Image model yet)
and Gemini Omni Flash for high-quality video and conversational editing.
You can read all about the announcement on the
Google Blog.
As soon as I saw the news, I couldn’t wait to get my hands dirty.
I wanted to see how easy it would be to generate images and videos using
the Gemini Interactions API Java SDK.
