opentraces

You can use OT data to surface families of tasks emerging around a community or ecosystem to share on @huggingface. If you are intermediated by a closed source agent users and services are missing out, data flows into closed harnesses and models. We need to open that loop up.

Re: turning agent traces from logs into training data. Today I’m experimenting with how to slice a trajectory and expose the trail of a trace to an agent or user, so they can construct useful datasets from real coding sessions. The basic shape looks like this: intent → interactive trajectory → trace patch → git commit (+ message) → commit survivorship The first hard question is: how do you slice a trace? A single agent session is noisy. It may contain several attempts, reversals, tangents, tool calls, user corrections, and partial ideas. Treating the whole thing as one training example is usually wrong. A better anchor is the agent patch: an attributable diff tied to a specific trace step. That is one of the primitives OT 0.4 introduces. If a patch makes it into a commit, and that commit is usually organised around an intent, you can use the patch to slice the trace around the relevant trajectory. Then you can use the commit message, tests, prompts, and nearby user steps to walk backwards and infer the intent. The why usually appears before the how. So each slice becomes a smaller, more useful unit: intent → trajectory → patch → commit, if available → what happened next, if available That last part matters. The signal is not only whether code entered git history. It is what happened after it entered. Did it survive? Was it rewritten? Repaired? Reverted? Deleted? Did later commits reveal that the original intent was incomplete? That is the beauty of VCS-anchored traces. You can take a later commit that affected the original patch and repeat the same process. Why did this later commit redact, repair, or remove the patch? Is that a useful signal for the dataset you are trying to build? This gives you an outcome layer. Not perfect, but grounded. The OT CLI then lets you, or your agent, move in both directions: 1/ walk backwards through the trace map to reconstruct why a change happened 2/ walk forwards through git history to see what survived, changed, or disappeared 3/ use ot blame to pull in related commits traces & use it to label the reason of the change Note: Commit hygiene helps, but it is not strictly required. If commits are messy (or your patch don't land), you can still fall back to semantic diffs and patch clustering to separate trajectories. TLDR: raw traces are logs. Patches give you anchors. Git gives you outcomes. Useful training data starts to emerge when you tie the trace, the patch, the commit, and its survivorship together, then use that chain to label the dataset.

OT 0.4 coming soon - trace patch trail => tracking survivorship of agent edits to and through git history - datasets & workflows =>your agent can now turn traces into focused datasets around a skill, library, service according to your own workflow ...and maybe, a desktop app 👀

🙋‍♂️ if this is you 👇

"a pre-IPO company just priced a live experiment to figure out whether real developer traces are the scarce input in coding agents" Traces are the commodity we are all sleeping on, they help companies build their own harnesses, or model developers build better models in the open

OT 0.3.3 • Dataset schema auto-generates from TraceRecord (no more CastError on new fields) • ot push refuses to overwrite a newer remote; clear upgrade hint instead • website is now agent-legible: Agent Skills, WebMCP, sitemap 👉 ot setup upgrade github.com/JayFarei/opent…

Traces are not black magic, write only read never, they are action trajectories with or without lasting impact in the environment they operate within. Capturing and making that data useful across agents is our goal 🫡

Have you noticed how CC & Opus 4.7 have started producing better summaries after turns on what was accomplished? The latest build of @opentraces now captures it and makes it searchable, you already spent those tokens why not resurface them as you pick up that project again?

@rauchg @nicoalbanese10 open agents should have open traces @rauchg, would love for vercel to sign up to a shared standard. Software is not the source anymore, and the harness is only part of it. Open source now is down to open data, if we can make that safely available, we can spur a lot of innovation

Today we're open sourcing open-agents.dev, a reference platform for cloud coding agents. You've heard that companies like Stripe (Minions), Ramp (Inspect), Spotify (Honk), Block (Goose), and others are building their own "AI software factories". Why? 1️⃣ On a technical level, off-the-shelf coding agents don't perform well with huge monorepos, don't have your institutional knowledge, integrations, and custom workflows. 2️⃣ On a business level, the moat of software companies will shift from 'the code they wrote', to the 'means of production' of that code. The alpha is in your factory. Open Agents deploys to our agentic infrastructure: Fluid for running the agent's brain, Workflow for its long-running durability, Sandbox for secure code execution, AI Gateway for multi-model tokens. (Because of our focus on Open SDKs and runtimes, this codebase is a gem even if you're not hosting on Vercel.) TL;DR: if you're building an internal or user-facing agentic coding platform, deploy this: vercel.com/templates/temp…

@opentraces 0.3 is out! Big update: a stronger security pipeline with TruffleHog and LLM review, generation-aware ingest for living traces, line-level attribution + inverse blame with a @gitbutler-style graph, and a full rebuild of both the local web viewer and TUI. The goal: make traces easier to inspect, safer to share on @huggingface, and more useful over time, both for yourself and for others. NB: If you are on 0.2.x, run `ot upgrade && ot setup` Feedback welcome! cc @ClementDelangue @julien_c 🙏

Tomorrow 👀

Final tweaks for 0.3 on the local viewer. In 0.3 the security pripeline will look like this: - To land in the inbox => 2 layers scanning & automatic redation - Your review => Manual + custom project or global level redaction - Before push to @huggingface, an optional local LLM for a final pass. No reason not to share traces anymore. Testing & documenting, out tomorrow 👀

With @opentraces graph you can see who's to blame for the last commits as you resume work, you can pull up which agent session designed a given feature (cross files) and extract the why with very little tokens. A surprising good way to "catch up" for you and your agent

From trace blame & semantic diff to a useful ROI to compare how far your token go in your feature work and even the key metrics you track on what that feature work brings you?

From trace blame & semantic diff to a useful ROI to compare how far your token go in your feature work? E.g. how much did feature A cost?

And here’s the local web viewer for your @opentraces (ot web), following the same familiar “lazy” terminal workflow. It now includes the new blame and graph features, so you can see which traces contributed to which commit changes. How great would it be to explore a popular open source repo by reading the maintainer traces, not just commits and code? Seeing other people traces gives me the vibes of early open source, where it was a way to learn how the greats did it! Bonus: experimenting with semantic entity-level diffs to label partial contributions from traces using the sem library by @Palanikannan_M and @rs545837 🙏

Who wrote this line of code? 👀 Which session made it to a commit, which one got disregarded? Which one produced a bug?

Last day of dev for 0.3, in the 📦: - 'ot review-llm', local LLM semantic sec scans before a public @huggingface push - 'ot blame' where you can pull up the sessions that contributed to a commit - 'ot resume' where you can resume the session (in any ACP compatible agent!)

you can set a cron job to review them regularly, skillify them, be the seed for a RL dataset. with a git integration & full traces commits, you can replay a scenario with different models, different harness, and have a personalised eval just for you more on that coming soon 👀

A trace commit to a @huggingface dataset can be your immutable audit trail that explains actions at runtime (why did you openclaw do that?) and becomes the intent trail behind your code changes (what did your ralph do?) It is increasingly a way to debug. 👉 ot init