Introducing Pivot.
A 357M bidirectional decision model built on @liquidai’s LFM2.5 Encoder.
→ scores options directly instead of generating text
→ 15.8ms p50 on H200
→ 545 decisions/sec at batch 32
→ open weights + reproducible evals
Now on @huggingface:
https://t.co/Am7JgH4RCm
saw a repo with 68 subagents.
that’s not an engineering org.
that’s a group chat with commit access.
half of them are just there to decide
whether the other half should speak.
saw a repo with 68 subagents.
that’s not an engineering org.
that’s a group chat with commit access.
half of them are just there to decide
whether the other half should speak.
@Butterflya1x Yes. The expensive part is rarely the plan.
It’s the 20 times per run you ask a generator:
route / retry / stop / escalate.
That’s the wrong shape of model for a loop.
@mikeydsoftware Permissions are necessary.
They’re not sufficient.
If the model deciding “should I act?” is a chatbot,
the guardrail is sitting on top of a slow, fuzzy switch.
The decision itself needs a tighter interface.
@codewithkhalil Valid JSON is the easy part.
The painful part is paying a generator to make a choice
your code then has to parse, validate, and retry.
Schema-shaped output still isn’t the same thing as a decision.
@imryven This matches what we see.
The tax isn’t just the serial 5%.
It’s using a chat model for every micro-decision inside the loop.
More agents on a slow decision primitive still leaves you with a slow graph.
@BeerBicepsGuy The missing split is inside the agent.
Planning can be generative.
The next action usually shouldn’t be.
Most “agents” still pay for an essay every time they only needed a decision.