• Ask about your timeline in plain language. The search field now understands natural-language questions, and a new chat view answers back in plain prose and handles follow-ups. It’s opt-in, and an early foundation we’ll keep building on. (BIG-304)
• Search now includes your saved places, alongside visits, trips, and notes. (BIG-547)
• Better recording underground. In metros, subways, and tunnels where the phone loses GPS, Arc now recognises the situation and does a better job of following your actual route instead of stalling at the station entrance. (BIG-150)
This release cycle ran a bit longer than we intended! So we’ve ended up shipping it without a bunch of things we’d planned/hoped to get in, rather than delay it longer. The plan now is to rectify those omissions by quickly cycling through to 1.3.1 and possibly 1.3.2.
So if all goes to plan this time, we should be seeing 1.3.1 within the next week, including hopefully several smaller but high value fixes and improvements that have been discussed on the forum.
Oh a note on the new search chat in 1.3: We’ve intentionally kept the AI’s tools and capabilities limited for this first pass. The goal was to build out a solid foundation first, then add in more tools and capabilities over time, based on feedback here on the forum.
So please do let us know what things you asked that the AI wasn’t able to answer! That’ll give us strong signal for where to focus the improvements. Thanks!
I’ve tested the AI assistants, and there still seem to be issues with how they understand dates.
When I ask about time segments like “the past month” or “the past 30 days,” the system only uses the previous full calendar month. For example, if today is June 6th and I ask for coffee shops I’ve visited in the last 30 days, it only shows results from May. It completely misses the data from June 1st through June 5th.
Additionally, when I ask about coffee shops I’ve visited, the system only searches for the specific keyword “coffee.” I noticed this because when it claimed I had only visited one location, I told it that was impossible since I go to Starbucks all the time. The assistant then admitted it had only been searching for the word “coffee” and didn’t include Starbucks because the brand name doesn’t contain that specific keyword.
Yeah Haiku’s been given only limited tools for date ranges so far. It can only do whole months, not “past 30 days” etc. We’ve filed a ticket now for improving that! Ticket number is BIG-582.
Currently it can only search for the place names, not categories. Which is a definite gap! We’ve got a cluster of place system improvements already filed, which overlap nicely with that one. Ticket number BIG-512.
I tested the underground recording and it is indeed much improved compared to earlier versions of Arc Timeline 4. It still needs a little bit of manual adjustment in the individual segments view but the raw recorded data is much better! Kudos to Matt for resolving this.
Yeah there’s still often a bit of manual cleanup required. We had plans for improving that too, but stopped short once we’d greatly improved the underlying recorded data. The 1.3.0 release was already running too long.
But we might file something for that just now, to remind us to come back to it. I think there’s still some more wins to be made there…
Ah, looking back through our dev logs, there’s not any specific clear bits we can continue work on. Can’t really file anything new yet, because it’s too ambiguous where we should focus the efforts.
If you start to spot any consistent failure patterns, definitely let us know! Screenshots and details of what kinds of cleanup were required, would be super helpful. Thanks!
Currently the cleanups required are just manually changing Walking to Metro and vice versa. Interestingly sometimes walking is assigned as Metro and I have to change it. I hope this is something that resolves itself when the activity classifier model updates and there will be no need for more code changes.
I think both of these fall into a trap of Haiku not having appropriate tools/filters to answer. Claude’s just doing a research dive on the code now, to get a clear sense of the shape of it. But I think the answer will be … well, heh, I’ll wait for Claude’s research results.
Hah. Agree. the “technically correct” approach is not the desired one in that case I think again this will be a limitation in what Haiku can achieve with its current tools. I suspect we’ll end up filing a couple of tickets for these - they might not be all resolvable with the same kind of tools improvement.
Doubtful. Haiku even manages itself well enough in Thai! Though in general I do still find almost all AIs sometimes require a language reminder: “Did you search for that in Thai/Japanese? English language results will probably miss the best answer”. Not really an Arc specific thing, just an observation that there’s often a tendency to do searches in the conversation language rather than the language that would’ve been more appropriate.
Though in these cases I think Haiku’s just cornered into not being able to see a clear path to answering well with its current tools.
Ok Claude’s research is back:
Root cause: Haiku has no trip-geographic / country query capability at all. That’s the whole story. Every one of his four failures traces to this one gap:
aggregate_timeline’s groupBy is only place / activityType / month / year — no country or locality dimension.
The only geographic thing Haiku can touch is the query_placesname-match against saved Places (which does resolve country names → ISO codes) — but that’s saved places, not trips, and has no “last / most-recent / outside-X” semantics.
GeoReportsManager — the Visit->country/locality rollup that powers the Places tab’s country view — is wired only to the Places tab. Haiku can’t reach it. So the data plainly exists (his trips, and his own Places-tab country list prove it); Haiku just has no tool that gets there.
And turns out we do have something filed for this already: BIG-565. I’ve bumped up the priority of it now.
It’s filed under the 1.4.0 project, so hopefully it won’t be too far off. Would be nice to keep the momentum going with Haiku’s tool improvements!
Yeah I hope so too. Will have to see how it plays out! The models will be learning from the new data shapes, but given that underground train trips are still inherently data sparse, it might take the models a good handful of trips before they start to do better. Uncertain territory…
I think again this will be a limitation in what Haiku can achieve with its current tools. I suspect we’ll end up filing a couple of tickets for these - they might not be all resolvable with the same kind of tools improvement.