Hazumi News

We built optimize_anything, an API that optimizes any artifact representable as text — code, prompts, agent architectures, configs, even SVGs. It extends GEPA (our prompt optimizer, discussed here previously: https://arxiv.org/abs/2507.19457) far beyond prompts.

The API is deliberately minimal. You provide what to optimize and how to measure it:

import gepa.optimize_anything as oa

def evaluate(candidate: str) -> tuple[float, dict]: result = run_my_system(candidate) return result.score, {"error": result.stderr, "runtime": f"{result.time_ms}ms"}

result = oa.optimize_anything( seed_candidate="<your artifact>", evaluator=evaluate, )

The evaluator returns a score plus diagnostic feedback (we call it "Actionable Side Information" — stack traces, rendered images, profiler output, whatever helps diagnose failures). An LLM proposer reads this feedback during a reflection step and proposes targeted fixes, not blind mutations. Candidates are selected via a Pareto frontier across metrics/examples, so a candidate that's best at one thing survives even if its average is mediocre.

Two ideas distinguish this from AlphaEvolve/OpenEvolve/ShinkaEvolve-style LLM evolution: (1) diagnostic feedback is a first-class API concept rather than a framework-specific mechanism, and (2) the API unifies three optimization modes — single-task search (solve one hard problem), multi-task search (solve related problems with cross-transfer), and generalization (build artifacts that transfer to unseen inputs). Prior frameworks only express mode 1.

We tested across 8 domains. Selected results:

Coding agent skills: Learned repo-specific skills push Claude Code to near-perfect task completion and make it 47% faster Cloud scheduling: Discovered algorithms that cut costs 40%, topping the ADRS leaderboard over expert heuristics and other LLM-evolution frameworks Agent architecture: Evolved a 10-line stub into a 300+ line ARC-AGI agent, improving Gemini Flash from 32.5% → 89.5% Circle packing (n=26): Outperforms AlphaEvolve's published solution Blackbox optimization: Generated problem-specific solvers matching or exceeding Optuna across 56 EvalSet problems CUDA kernels: 87% match or beat baseline; multi-task mode outperforms dedicated single-task runs

``` pip install gepa ```

Blog with full results and runnable code for all 8 case studies: https://gepa-ai.github.io/gepa/blog/2026/02/18/introducing-o...

GitHub: https://github.com/gepa-ai/gepa

Hey HN! Arjun and Sid here.

Fostrom is an IoT Cloud Platform designed for developers to make it really easy to get started and scale fleets. We have Device SDKs (in Python, JS, Elixir, more coming soon), Typed Schemas, Per-Device Mailboxes, Programmable Actions, 4 Global Regions for lower-latency connections, and much more.

We've built Fostrom to solve a real need we faced in our previous startup, building a fully automated indoor vertical farm. We spent more time figuring out IoT infrastructure than writing automation logic. Fostrom is the platform we wished existed back then.

Over the last few years we've experimented with a lot of interesting tech and architectures, and settled on an architecture that we believe is quite elegant. We wrote a Go<->Elixir bridge to execute JS code in WASM for Actions, implemented a DuckDB library for Elixir, and wrote a Device Agent in Rust that our SDKs run in the background (https://github.com/fostrom/devicekit).

The most interesting realization we had was about the data architecture. For years, we tried using distributed databases and built complex layers on top of them, but all approaches had significant limitations specifically around consistency and querying. We want to provide operational correctness, rich insights, and reliability. Finally, we came to the conclusion that to achieve this we really need a SQL database for fleet data. So we built a DuckDB-based replicated multi-tenant data layer. We're still improving it (hence the Technical Preview badge) but we're quite proud of this decision. It simplifies the rest of the codebase, while keeping operational complexity in just a few places.

Our vision is to make a powerful IoT platform that enables you to build correct, secure, and reliable connected systems without dealing with any of the plumbing or infrastructure.

Next up, we're gonna launch our CLI, add automatic device monitoring to our Device SDKs, and improve the debugging experience. We have some pretty cool ideas to make Fostrom and the experience of developing connected systems better. We're also going to write more about our architecture and journey soon.

We also published our launch blog post which goes into more detail about our vision, what we've built, and our future plans: https://fostrom.io/blog/introducing-fostrom

Would love for you to try out Fostrom and give us your feedback and thoughts.