🎇🎇 SpiceGrinder Beta 2 is out! 🎇🎇 SpiceGrinder is a deterministic synthetic data engine. You describe the shape of your data in a plain-text model, and the same model plus the same seed gives you the same rows anywhere. No production data, no telemetry, runs entirely on your own machine. Free tier has no row limit. What's new: 🖥 A real desktop app. The model editor is now its own app for macOS (Apple Silicon and Intel), Windows and Linux. Graph, tree and raw views of your model, click-or-drag to add and wire nodes, a live sample preview from any node, undo/redo, and syntax errors pointed out as you type. Compare with Sample checks how close your model's output is to a real CSV. 🧰 More command-line tools: compare (model output vs a real sample, column by column), format (one standard layout, so diffs show only real changes), library (list every component and its parameters), and mcp (a server so AI agents can discover components, validate, analyze and generate). 📈 Components that fit real data better. Copula gives you correlated columns that keep their own distributions. Pool makes rows share entities (many claims per provider). Switch lets later columns depend on earlier ones. New fast modes for Binomial, Hypergeometric, NegativeBinomial and Skellam. 🛡 Fewer silent mistakes. A misspelled parameter is now an error that names the closest match, instead of being ignored. Bug fixes take care of some improbable edge cases in statistical generators. ⚡ Faster. Up to 2.38 billion rows/hour on a t8i.micro (SixStats, one instance, Free tier), and 24% to 70% faster than our last published numbers on the same instance types. All eight AWS free-tier instance types, plus a MacBook, a Linux box and a Windows mini PC, are measured on the site, with the model file so you can reproduce it. 🤖 Optional agent skills. Six skills for Claude Code and similar tools: draft a model from a description, fit one to a data sample, explain, audit for PII, tune performance, extend. They're optional, and SpiceGrinder itself has no AI in it. Pro adds business objects (such as addresses, SSNs, credit cards, ACH and FHIR formats), external data sources, custom components and more. Canadian addresses are new. It's a beta and the installers aren't signed yet, so macOS and Windows will warn you the first time you open one. It's expected; the download page links to the steps for getting past it. Get it (Free): obsvra.com/get-spicegrinder Benchmarks: obsvra.com/benchmarks If something confuses you or breaks, tell us at support@obsvra.com. That's what the beta is for.

All videos will be living over at YouTube. Follow the link below to see the channel. youtube.com/@obsvra-q9m?si=N…

This is the introduction to a new series of videos on showing how SpiceGrinder will help with specific use cases. SpiceGrinder is a deterministic stochastic simulation engine for Monte Carlo and time-stepped models. Don't let the techncial speak scare you off though, it just means you can use the tool to model and simulate data, and then you can use that data for analysis, forecasting, and testing. SpiceGrinder itself has no AI in it at all, but does come bundled with agent skills you can add to your workflow to help you build and evaluate your models. Video by Claude Opus Music by Suno Voice by Obsvra founder Kevin Krom (edited with Adobe Podcast Enhance) obsvra.com

A quick teaser about using simulations in SpiceGrinder 1.0. This is a simple but quite useful example that will work on SpiceGrinder Free. In the official 1.0 release, you'll be able to run experiments like this through a built-in harness; for now you can collect results and compute it in a spreadsheet. Video created by Claude Opus 5.5 Music By Suno V6 obsvra.com/get-spicegrinder

Playing around with motion graphics on Opus to put together promo materials and how cow it's way easier and less costly than I ever expected.

"When's the last time you touched code yourself?" Bro, I'm a senior software engineer/architect, I haven't "touched code" in YEARS. I tell programmers what to do, I don't do it myself. And the LLM actually does what I tell it to do.

Prompting With Purpose Using LLMs to create software isn’t just “vibe coding”. That term implies a very informal approach to software: “hey Claude, make me an app that does X”. Sure, Claude (or whatever agent you use) will do that, but the less you specify, the more guesses it has to make. You can iteratively make changes, but it’s essentially building on shifting sand, and that is why more complex systems tend to have difficulty with that type of approach. Instead, you should be very deliberate about what you’re trying to do, and yes, this takes some skill and knowledge of how software should work. Programming and software engineering aren’t dead, they’re just disciplines that need to evolve to new tools. Start by putting your LLM aside for a minute. Write a short document describing what your actual goal is. List out the features that are vital, which ones are optional but nice to have, and even features that might normally be associated with the overall idea that aren’t wanted or needed. Figure out your constraints. Are there performance metrics you have to hit? Specific platforms and configurations that must be supported? What TYPE of program is it — phone app, SaaS, standalone application, etc? Are you ok with incorporating existing open source projects or not, based on licenses? Write these constraints down, too. If the material you’ve collected so far indicates a clear decomposition into smaller parts, do it now. Otherwise, the next phase will help with that. Now pull up your LLM. Start by instructing it that you want to develop a plan to create a new application and feed it the document you created. Include instructions that you want to construct a roadmap on how to break the project up into smaller pieces with a sensible order in constructing them so they build off of each other. If you allow for the inclusion of open source projects or libraries, ask for the LLM to evaluate which ones exist and can be useful. The first phase should focus on the project environment: setting up any tooling, revision control systems, processes, etc. REVIEW THE PLAN. Especially look at any assumptions the LLM makes, and make sure you agree with them. Suggest changes to order or ask it to explain decisions it made if you don’t immediately agree with them. Refine the plan until you’re happy with it. Optionally, iterate the break the plan down into smaller sub-plans across the board, but I’d recommend skipping that, and instead… Pick up the first phase of the plan. Break it down into sub-plans until you reach a granularity that lends itself to individual tasks, reviewing the plans at each stage. Once you have things down to the task level, that’s when you should let the LLM start coding. And if you’ve done your plans coherently enough, you should be able to have the LLM go from one task to the next quickly, making corrections to the plan as real experience lets you revisit previous decisions and assumptions and make necessary changes. (Note that this is why I suggest against breaking down the entire project plan into fine-grained sub-plans before starting. Those sub-plans will inevitably require changes anyway, better to fold int he learned experience at the time you break the phase down into sub-plans.) Think big, design smaller, refine smaller still. Implement in small, testable chunks. Incorporate lessons learned back into the plan. Ok, maybe you’re slower than the vibe coder, but the vibe coder has a program. You have a working product.

Ok, that's funny.

Brief aside here... I've been going on a lot about how SpiceGrinder will help you out with testing, but test data is just one use case for the engine. SpiceGrinder really is a deterministic stochastic simulation engine for Monte Carlo and time-stepped models. And will become even more sophisticated at general simulation as development continues. That takes use cases far beyond "does my system work" to doing true analysis and forecasting as well. We'll be publishing some blog entries and learning track modules on simulation soon, some of it previewing the final 1.0 release and some examples that can already be done today using the Free tier beta version available at obsvra.com/get-spicegrinder (runs on pretty much any computer). If you're a game or simulator developer and are interested in incorporating SpiceGrinder into your own engine, contact us at sales@obsvra.com and we can talk.

Ah, the final 10% of my Claude limit before reset and a little bit of time to still use it. Time to tackle the low-priority to-do items in my queue I've been putting off.

Just saw that SpiceGrinder's agents skills plugin package was accepted and published by Anthropic. It's not showing up in search yet, but I'm sure it will soon. You can use the agent skills package without even installing SpiceGrinder -- it will help you figure out exactly how to model what you need so you can determine exactly how SpiceGrinder will help you with your testing or simulation needs. A skills package install without SpiceGrinder installed won't be able to perform a few steps (notably validating and running models) but it will tell you that and what would still need to be done after download. If you don't want to wait for the skills to be available in Anthropic's catalog, they're available on GitHub as well: github.com/obsvra/spicegrind…

Now that beta 2 is out, we've spent a little time examining one of the mysteries that shows up on obsvra.com/benchmarks, namely, why do we have an odd discrepancy in total run time vs. complexity score on the smallest models while the rest of the graph tracks roughly linearly (log(run time) vs. log(complexity)) as expected? We think we've found it now, but we're running tests to verify. The complexity score tracks the time spent generating the data very well (as expected), but not the time spent writing it out. Writing costs a roughly constant amount per output column, regardless of number of bytes. Output generation was previously considered a fixed overhead cost, not one that varied by row width. When a model's generation is cheap and its rows are wide, as in one of our smallest test models, writing multiple columns can be most of the run time. When generation dominates, it's a small share. This explains why we only really notice the effects on the left edge of the graph -- these are smaller models where the output width overhead can dominate runtime -- even though the other models are also affected, just by less on a relative scale, so not noticeably visible on the graph. Pending testing, the plan is to add an output-cost figure to the analyzer's report, separate from the complexity score, so that we (and you) can estimate total run time as well as raw generation cost.

Love love love Sonnet 5.5 Currently preparing my beta 2 release and it's plowing through the whole release management pipeline: app builds, package, test installs, documentation updates, updated skills package, and website updates. I'll be able to push it all with one command.

Quick update - Beta 2 will be a few days later than expected. Why? Well, we have agent skills (optional to use) that are meant to help you create and improve your models. One of those skills is called fit-sample-to-model, and the idea is you point it to a good-sized sample of the data you want to model, and your agent will follow a set of guidelines to analyze that data to find the best fit it can with what's available in SpiceGrinder. Unless your agent knows you have SpiceGrinder Pro, it will attempt to generate your model using only Free-tier components and within the Free-tier 20 node limit. If it can't it will tell you why and proceed to tell you how to model it using Pro. Since we made several improvements to the analysis instructions, we decided to test it out on some real world complex data sets we were able to find on the internet as reference data. And while we got good results, we knew they could be better, so we want about adding a few new features and making a few bug fixes along the way. The biggest new feature, available at all tiers, is Copula. Previously, the only mechanism we had to simulate correlated data columns was MultivariateNormal, which works great as long as the individual columns can be modeled as Normal distributions. When they can't... that's where Copula comes in. With Copula, correlated columns each keep their own distribution, such as a skewed Gamma claim amount that moves with a Poisson claim count. The fit-sample-to-model skill is great, but it isn't perfect, and we include documentation on how to evaluate what it comes up with. It gives you a strong starting point and, perhaps more importantly, the power to refine it further manually or with your agent's help. Because you can read the output model (either as plain text or using the improved SpiceGrinder GUI), you can see exactly what your agent decided on, and can ask it additional questions such as "why did you use Gamma here instead of Lognormal?" You can edit the models. Once your agent is done generating it, it's a regular model file that can be used, modified, and stored just like any you came up with by hand. Anyway, to make a long story short (yes, we know, too late), this push, along with some performance tuning work, put us behind a few days so it's delaying Beta 2 accordingly. We hope the improvements will make the wait worthwhile.

Hot take: the practical upshot of agentic coding and who is successful with it vs. who isn't is actually exposing how much the process of being "an elite coder" has been fetishized over shipping good products.

We're also removing the Drop filter in favor of a new, far more flexible Arrange filter that will let you drop, duplicate, and/or rearrange the order of inputs. Big improvements in the (optional) agent skills and MCP as well.