HN user

ammario

122 karma

Co-founder & CTO @ Coder[.com]

contact: ammar@coder.com

Posts19
Comments20
View on HN

Lol, this is my PR. That cost is misleading. That workspace did far more than that change. In reality I spend ~$1000/week in tokens for all of my development work, and I'm quite happy with the exchange.

Author of Mux here:

I started building it out that way but found it very challenging to create parity between the models. E.g. they have different tools, system prompts, interruption semantics, cost tracking etc. The spirit of the product is decoupling the LLM from the UI, so we went with a custom loop / tools that can perform decently across all models.

I meant read-only there in the sense of mutability, not exfiltration.

Of course, some websites may permit mutations through GET so it’s probably only sensible to use alongside known hosts.

I've been recording every trade across the platform for the past 3 months, which is when I began my operation.

Median Daily Volume (M$)

Dec 2024 - 10.2

Jan 2025 - 5.04

Feb 2025 - 5.89

So, in short, my data is inconclusive. I've been impressed with their marketing and business development though. They seem to be cozy with the new administration and I imagine any headwinds they had from the CFTC are disappearing.

Cool to see. I'm currently #1 on the Kalshi volume leaderboard (https://kalshi.com/social/leaderboard) with a proprietary market making algorithm.

There is plenty of money to be made on Kalshi, but I had to rethink the math from the ground up as most of the literature describes highly liquid, somewhat stable markets.

One small change you could make to your algorithm is to calculate the skews/spreads in log-odds space. A change in price from 50c to 49c represents a very small delta in expected return whereas 2c to 1c is a doubling. Dealing with probability contracts in log-odds controls for this effect.

I think this post overhypes the issue. So many writes we do just aren’t that important (e.g. logs, cli config, blah), Close fails rarely, and it’s pretty standard for casually developed application software to misbehave once the disk is full or breaking.

This is a classic safety / performance trade off that was properly selected in favor of performance.

The defer Close() is still quite useful as a way to avoid fd leaks.

It makes them better, up to a point. Many commits (esp in private repos or WIP branches) are barely descriptive and of the form "stuff broke" "i got test to pass" "yay", etc. These commits don't make it into mainline, and I don't really want to spend time carefully writing them. In this case, a tool like this may be useful.

Also, the `aicommit` tool has a -c flag for accepting context and the "why". I have only been playing with it for a couple of days so I'm not sure how effective it will be.

Good catch.

From inspecting the Ruedis API, they are allocating in the same way as the other popular libaries. There is no way (that I can tell) to stream a large blob from Redis into a Writer of your choosing, so you're always going to allocate the size of the object + miss out on concurrency.

Edit: clarified that I'm referring to ruedis and not redjet

Hey Matt,

Context: I’m a co-founder at a B staged startup and not sure how broadly this applies.

Our employees ask their manager for approval before they submit an expense request. If it’s less than a few hundred dollars a year and clearly aids their productivity, the answer is yes 99% of the time.

It’s important that the product bills yearly, because our system (Ramp) has no support for recurring reimbursements.

So: long trial, yearly billing and price <$300 is best.