Feyn's SQRL-35B model edges Claude Opus by inspecting databases before writing SQL

Most text-to-SQL systems treat the task like translation: turn a question into a query and hope for the best. The problem, as any data analyst who’s inherited a messy database knows, is that perfectly valid SQL is often perfectly wrong. Joining the wrong tables or filtering on a value that doesn’t exist in the data won’t throw an error—it just silently returns garbage. YC-backed startup Feyn AI is betting the cure is curiosity, not better translation. They’ve released SQRL, a family of models that can inspect the database first to resolve ambiguity before committing to a final answer. The flagship, SQRL-35B-A3B, hits 70.6% execution accuracy on the BIRD benchmark’s dev set, just nudging past Claude Opus 4.6 at 68.77% under the same evaluation.

Training a model to look before it leaps is the hard part. Feyn didn’t just give the model database access; they used reinforcement learning to teach it when to inspect. A method called CISPO, borrowed from MiniMax’s M1 work, clips importance-sampling weights to preserve gradient signals from rare but decisive tokens. The team trained only on a ‘mixed zone’—cases where some of the model’s eight attempts at a question succeeded and others failed. That contrast is what teaches the model that inspecting the database is a good idea. This approach lets SQRL combine the cheap, single-shot speed of smaller models with the costly, multi-step reasoning of frontier pipelines, but only when a question actually stumps it.

The three open-weight checkpoints—SQRL-4B, 9B, and 35B-A3B—are now on Hugging Face. The system’s reasoning is refreshingly legible. It uses <sql> blocks to request read-only observations and <answer> blocks to commit to the final query, making its fact-finding process visible. The model can inspect up to five times, though Feyn notes most questions finish in fewer steps. This isn’t just about raw benchmark scores; it’s a model that can check if a county is stored as ‘Alameda,’ ‘Alameda County,’ or ‘ALAMEDA’ before it writes a query that filters for the wrong one.

Feyn’s core wager is that the missing information needed to write a correct query already lives inside the database. Schema alone can’t tell you which join path creates duplicate rows, but a quick SELECT DISTINCT can. Cleverly, the team also cleaned their training data by throwing out reference SQL that didn’t actually answer the question, preventing the model from being rewarded for replicating mistakes. It’s a pragmatic fix for a messy problem, and it signals a shift from treating text-to-SQL as a language problem to treating it as a reasoning one. The real test will be whether this inspection-first approach holds up when faced with the sprawling, undocumented schemas of the real world.