I have released version 2.1.0 for tablo today !!
by•
You can either restart the app manually, or the auto-updater will do the job for you in a few hours :)
(FYI: The auto-updater polls every 6 hours, and it has been made opt-in)
The Changelog is as follows:
Please note: I have hot-fixed the app to version 2.1.1 after I noticed it did not receive Fable context windows properly. It should work properly now.
Reason: Fable's context is set to a default of 1 million by Anthropic, so it does not report any context window data. Tablo does not find a context field for fable's session and falls back to the default value of 200k.
159 views
Replies
I appreciate that you explained how the updater works. it saves users from guessing what's happening. Looking forward to trying v2.1.0.
@tessa_lynch
Yeah ! Hope you like the new features : )
Dial
the notification sound flipping to on-by-default for existing installs is the one detail I'd keep an eye on - people forget they never opted into that until it chimes mid-meeting after a background auto-update. did you consider keeping that opt-in too, or was making the update visible worth the risk of an unexpected sound for people who upgrade quietly? the jump-to-session re-resolve fix is a nice catch too, stale window targeting after a move/close is an easy bug to miss until someone hits it mid-session.
@galdayan
Yes, notification sounds are opt-in along with auto-updater.
Making the update visible will help me communicate the features better along with conveying any new features. This is because people rarely bother to open the settings section and flip the notifications on.
Hope you liked the update and thank you for being a part of tablo !!
Dial
@m1tul5 good to hear both stayed opt-in, that was my only real concern. makes sense re: visibility, most people really don't dig into settings unless something breaks. congrats on the quick 2.1.1 hotfix too, catching the fable context thing same-day is a good look.
@galdayan
Haha, yeah that was a close one :)
The Fable fallback in your note is the part worth pulling on. Falling back to 200k when the real window is a million does not just lose data, it reports the opposite. The widget says you are at eighty percent context when you are actually at sixteen, and someone compacts or restarts a session that had plenty of room left. For a monitor, a wrong number is worse than no number, because people act on it. Absent data is visible. Wrong data is invisible and confident. So when the context field is missing I would show unknown rather than a default. Grey the ring out, break the cat's stare, whatever reads as "I cannot see this right now". A monitor should fail loudly. Which is the same instinct as making the auto-updater opt-in, honestly. You made that opt-in so it could not surprise anyone. This is the same call pointed at the data instead of the behaviour. Does 2.1.1 still fall back to 200k, or does it report unknown now?
@m1tul5 Dropping the meter for ambiguous sessions is the better call than any default. A safety net value is indistinguishable from a real reading at a glance, so it does not degrade, it lies quietly. Blank is honest and people learn what blank means in about a day. Separately, your pane mapping writeup is the clearest description of that problem I have read. Re-tracing live at click time rather than trusting anything stored is the right shape, since every stored id goes stale the moment someone moves a pane. Where does it break for you today, detached tmux sessions or something earlier in the chain?
@rabnoor_s
I agree with the blank decision. The re-tracing breaks in many cases, one of them being is that if the tab is moved or sometimes when we open the tmux session in another window/terminal-in-editor. And yes terminal-in-editors behave weirdly
@m1tul5 Tab moved and tmux reattached elsewhere are the same failure underneath: the identity you resolved against stopped being stable, and nothing told you. Which is the argument I have been making all week about session memory generally, so I should disclose the obvious. I hunted Atuin on here today, which is the shell history side of exactly this: history that keeps the directory, the exit code and the duration instead of a flat file that forgets which session it belonged to. Relevant to you rather than a plug, because if a tool like tablo could read that, "which pane was this" becomes answerable from the history rather than re-derived live every time. Not asking you for anything. If you think that is the wrong layer to solve it at, that is more useful to me than agreement. Does tablo read shell history at all today, or strictly live session state?
Mitul, straight admission first: I told you I would run tablo for a week and come back with the mapping change as a PR. I have not, and I have said a version of that more than once now, so rather than say it a fourth time I am going to just put the change here and you can take it, bin it, or tell me it is wrong. Give every mapping entry three fields instead of one: value, source, verified_at. Source is either reported (the session actually told you the window) or default (you guessed). On read, if source is default, or verified_at is older than whatever you decide stale means, do not draw a percentage at all. Grey the ring, break the cat's stare, whatever your unknown state is. Only a real reported value is ever allowed to write verified_at, so a fallback can never refresh its own freshness and quietly look current. That is the whole change. It is small, and it means the widget can no longer tell you eighty percent when it does not actually know.