jpau

The iteration cycle is becoming very quick. Gemini 3.8 Flash arrived just 20 days after 3.7 Flash.

Similarly Qwen3.8-Max was updated in just 30 days (to the 0902 release) and Muse Spark in just 28 days (to the 1.3 release).

A year ago iterative releases were every 3-6 months. At what point will they reach nightly candidates?

You can also customize Gemini Flash. It's a niche thing benefitting few, but you can tune gemini-3.7-flash in Google Vertex (now named "Agent Platform"?)

Standard pricing is showing for me as $1.50 / $9.

(I suspect you're viewing the "flex" pricing).

> For venue recommendations [...] we do not rely purely on the language model. We embed both user requirements and venues into vector representations and retrieve candidates using similarity search. Hard constraints such as capacity and dates are applied first, and results are ranked before being presented.

Huh this surprised me as a forgone opportunity.

I heard second-hand about the process for organizing our last offsite. Searching for venues was not the time-consuming part.

The time-consuming part was actually engaging with the venues to confirm specific details not available online. Our teammate who did this engaged with _hundreds_ of venues. It was a lot of work on their part ... and probably not the most fun part of their job.

That seems like an ideal agent scenario?

Interesting that this was released without a prior GPT-5.3 release. I wonder if that means we won't see a GPT-5.3?

Hey we're also a Vertex tuning customer in a similar spot. We're seeing other capacity issues, although not a leap in latency. Can you DM me? I'd love to trade notes. https://x.com/hellofromjames

I love Cerebras. I also love that they've started to scale rate limits to useful levels (which is relatively new).

I still don't know how long they'll support our chosen model.

On Oct 22 I got an email saying that

```

- qwen-3-coder-480b will be available until Nov 5, 2025

- qwen-3-235b-a22b-thinking-2507 will be available until Nov 14, 2025

```

That's not a lot of notice!

I don't want to spend all my time benchmarking new models for features I already built. I don't want my users' experience to be disturbed every few months.

> A URL shortener that runs a lightweight model (gemini-1.5-flash)

I think gemini-1.5-flash is EOL'd from tomorrow (Sep 25th) https://cloud.google.com/vertex-ai/generative-ai/docs/learn/...

RIP gemini-1.5

Google[1] also has a "long context" pricing structure. OpenAI may be considering offering similar since they do not offer their priority processing SLAs[2] for context >128K.

[1] https://cloud.google.com/vertex-ai/generative-ai/pricing

[2] https://openai.com/api-priority-processing/

Interesting!

Is there anything to read into needing twice the "Avg Attempts", or is this column relatively uninteresting in the overall context of the bench?

Seems to be a nod to each size being treated as their own product.

Claude 3 arrived as a family (Haiku, Sonnet, Opus), but no release since has included all three sizes.

A release of "claude-3-7-sonnet" alone seems incomplete without Haiku/Opus, when perhaps Sonnet is has its own development roadmap (claude-sonnet-*).

Sorry to hear the challenge.

You and your friends should email me with your resume and anything you're proud to have built. I'll extend that to any MIT senior/recent grad who wants to discuss moving to SF and helping us apply LLMs to build product features that solve interesting customer problems.

I'm at james.peterson@fathom.video. Include "[responding to HN thread 43614795]" in the title. I'd love to chat.

I am grateful for GCP's quotas that help us prevent similar own-goals.

While this specific error is something we know to avoid, I'm sure quotas have helped us avoid the pain of other errors. So I'm somewhat sympathetic.

I think it's important to read the language of and judgements in the post in the context of someone who just got a large unexpected bill (expensive lesson).

I use screen.studio

I noticed Anthropic updated their prices, but haven't seen this posted anywhere.

Claude Instant is now 10% of Claude 2's pricing: $0.80 per million input tokens, and $2.40 per million completion tokens (down from I think $1.63 and $5.51 respectively).

Altman mentioned[1][2] earlier that they were working on a "stateful" API for release this year.

> 2023: A stateful API — When you call the chat API today, you have to repeatedly pass through the same conversation history and pay for the same tokens again and again. In the future there will be a version of the API that remembers the conversation history.

Maybe it's an RAG-based thing, but that'd be underwhelming given the promise.

Wizard of Oz, or true magic?

(In the same interview, Altman also claimed progress toward releasing million-token context windows this year. Wowzers)

[1] https://humanloop.com/blog/openai-plans, removed at OAI's request

[2] Archived at https://web.archive.org/web/20230531203946/https://humanloop...

Replacing them with null seems like a weird decision (that hopefully they will iterate on).

Can anyone suggest why they might have chosen null and not a wkt/text cast?

I was seeing 500s, but it seems back for me now (Melbourne, Australia)

Inflation means tomorrow’s money is worth less; it impacts cashflows more when they are further out.

When the cost of money is near-zero, today’s values of near and distant cashflows are similar. When the cost is high, they are very different.

I’m not sure if you mean in your question that a project shown to track inflation will be unaffected. This is somewhat true — we see this in inflation-adjusted bonds etc. But inflation is far from a uniform effect, and I’ve never seen a pitch include inflation in its estimates…

I'd start with goals. Take some time (you have it available!) to think about what you'd like to achieve at different levels, such as: - In your career - In this field - At this company

Then break them down, and then break them down again. What can you do, in bite-sizes pieces, to move towards them?

But I wouldn't stress too much. Remember back to when you were busy, and how much of that became growth. If you're like most people, it wasn't very much.

Use the time to achieve what _you_ want, but don't forget to enjoy it too :)

I really enjoyed reading the fiction-reflecting-reality novel "The Shipping Man" [0]. It's a fun read (though the story is better than the writing).

In particular the author (IIRC a shipping financeer) addresses: Sea freight is a strictly price-sensitive industry that has used _centuries_ to find grey areas in which to shave a penny. Newcomers are chewed up and spat out. The story's protagonist, in their attempt to become a "shipping man", declines from being a wealthy fund manager to a broke divorcee.

My day job is at a freight-related SaaS. There is a lot of opportunity in freight outside of running your own asset-heavy line. We help optimise allocation. It's lucrative for us and for our customers.

But if I were to start such a thing, I'd find some "logistic managers" on LinkedIn and interview them about their pain. I expect finding a ship to send cargo would not usually be at the top of their list ...

... but it actually might be, right now, in the short term. Sea freight prices have soared over COVID, and are now 7+ times higher than before[1]. For someone determined to follow the romance of shipping, today might be a better time than most.

[0] https://www.amazon.com/Shipping-Man-Matthew-McCleery/dp/0983...

[1] https://fbx.freightos.com/

Small note: Python's standard dict has been ordered since ~3.7

E.g. https://mail.python.org/pipermail/python-dev/2017-December/1...

The first that came to my mind are media apps — Figma, Canva, ... .

That might just be my laptop though.

Consider how inserts, updates, single-point lookups, indexes etc work with your analytical system.

You use SQLite to back and operate an application. SQLite is a wonderfully lightweight transactional database; it compares more to e.g. MySQL than with OLAP systems like Spark.

SQLite isn't competing for analytical use cases :)

You sure can :)

I see it as why the article supports Databricks as an RDBMS; it offers something others do not.

You can't currently* do the same extensive UDFs in Snowflake or BQ and, sometimes, they are important. But with SnowPark coming, hopefully you won't have to make such a large sacrifice to SQL users' experience for it.

* Currently you can do JavaScript UDFs and external functions in Snowflake, and BigQuery ML is worth mentioning here too. Those cover some, but not all, of what you might use a Spark UDF for in SQL.

Databricks is good as a managed Spark platform.

They have thought about how they can improve the DS experience. Inconsistent storage? DeltaLake. Slow Spark queries? Databricks Delta. Model management? MLFlow (I haven't adopted this, but can't pin down why -- on face value it seems great). Development environment? Databricks Connect. Cluster management? Core.

But the same is not true for SQL analysts. Today's offering does not empathise with them. I'm unsure integrating Redash is a genuine reply to their needs.

The upside here is that (1) Databricks (or at least, Databricks' marketing) appears to be prioritising this need, and (2) A lot of people are betting a lot money that they can do this well.

Tomorrow looks sunny.

They use DeltaLake + Spark 3.0, and are mostly careful to partition well.

Their datasets are small. Most tables are ~50GB, the odd table up to ~2TB. The clusters typically are nothing shabby for this size, defaults to ~[4-12]x32GB.

The queries that I have seen are typically not written well. Think view-on-view-on-view (there's a BigCo policy against them materialising data..), and where the filter is applied in the last step. The stuff of horrors, but something I've seen in more-than-one-BigCo.

But we have compared some of those same queries on BigQuery vs. Databricks, and, I don't know if BigQuery's execution optimiser is better? Or if the BigQuery storage is better organising the data? Or if BigQuery is simply throwing more resource their way?

I'm deeply disappointed in Databricks as an RDBMS.

As a DS/DE, there's a lot to love (not all, but a lot). The easy provision of Spark clusters. The jobs API. DeltaLake (mostly). Easy notebooks (please don't create a prod system from these..). And Spark itself continues to improve, albeit in an increasingly crowded field.

But I've worked closely with BigCo SQL analysts on Azure Databricks, and their experience was terrible. For example:

  - You cannot browse the data structure without an active cluster
  
  - Starting a cluster can take ~5 minutes and, since you missed that moment, you may not submit your first query until 10-15 minutes.
  
  - The SQL error messages are often (perhaps usually?) nonsense, so you have to operate without them.
  
  - An unfortunate amount of downtime, followed by bizarre excuses.
  
  - It's so darn slow, relative to equivalent queries on BigQuery or Snowflake.
  
  - Even submitting a query can take a weird amount of time.

If Databricks-as-an-RDBMS were competing against Teradata, sure, let's have a chat.

But we're in 2021, and there's just no comparing the experience of the SQL analyst on Databricks-as-an-RDBMS vs. Snowflake/BigQuery.

I'm excited for the potential of Snowflake's SnowPark (though know little about it). Calling UDFs from SQL means you can create great features for SQL analysts, provided that they can build the momentum to need it.

Well no, unfortunately.

Remember that "data is a team sport". Together, we try and make better decisions (in manual or automated ways). A DE can produce great data but it's only useful if it helps the DA/DS. There's a lot of friction there.

Most of that friction disappears with SQL-based orchestration tools (I mean specifically dbt here, but there are others). Suddenly the analyst can create the data they need! With minimal guidance from a DE.

That can be with Spark SQL (+ DeltaLake / Iceberg), or some warehouse. That's not the issue.

The issue is around keeping orchestration simple when you're not just doing simple stuff anymore. Keeping that DAG logical, clear, and smooth is difficult once you include non-SQL items.

This isn't solved by Spark UDFs unfortunately :)

Snowflake's `Snowpark` product that they recently announced, which is to bring Spark-like APIs to Snowflake.

Having a DS background, I love what SQL-orchestration tool dbt (and peers) have enabled: data consumers to rapidly create our own safe data pipelines. There's easily a 10x productivity improvement for most of my transformation pipelines vs. when I write them in Python or PySpark.

But batch ML and SQL are not that friendly (even BigQuery ML is too limiting). I end up butchering dbt's value (simplicity and iteration speed), splitting the DAG into pieces and orchestrating them with Airflow so that I can wedge in other non-dbt parts (like feature engineering, inference, logging, detecting stale models, ...). This isn't what the future looks like.

I've tried switching to Databricks, but do not see this as the path forward for unioning the warehouse + batch ML.

Hopefully Snowpark is a step forward :)

-------------------

Separately, https://materialize.com/ is something I'm paying attention to! Being able to implement all of my SQL-based pipelines as materialized views would be immensely valuable. They recently raised capital and they could become huge.